처음 NAS를 구매했을 때는 파일을 저장하고 사진을 백업하는 것이 목적이었다.
그런데 Docker를 사용하기 시작하면서 WordPress를 만들고, Vaultwarden과 Jellyfin을 설치하고, AdGuard Home까지 추가하게 됐다.
여러 서비스를 하나의 NAS에서 운영할 수 있다는 것이 재미있었다.
하지만 서비스가 늘어나면서 새로운 고민이 생겼다.
지금 실행하고 있는 서비스들이 정상적으로 작동하고 있는지 어떻게 확인할 수 있을까?
이전에는 문제가 생기면 해당 컨테이너를 찾아보고 직접 접속해보면 됐다.
그런데 서비스가 하나둘 늘어나니 매번 확인하는 것도 번거로운 일이 되어갔다.
그래서 사용하기 시작한 것이 Uptime Kuma였다.
컨테이너가 실행 중이면 서비스도 정상인 걸까?
Docker를 처음 사용했을 때는 컨테이너가 실행 중이면 서비스도 정상적으로 작동한다고 생각했다.
하지만 여러 서비스를 운영하다 보니 이 둘은 다른 문제라는 것을 알게 됐다.
컨테이너가 실행 중이더라도 실제 웹사이트가 제대로 열리지 않을 수 있다.
애플리케이션 내부에서 오류가 발생할 수도 있고, 네트워크 연결이나 도메인 설정에 문제가 생길 수도 있다.
예를 들어 WordPress 컨테이너가 실행되고 있다고 해도 방문자가 실제로 웹사이트를 이용할 수 있는지는 별도로 확인해야 한다.
이전에는 문제가 생겼을 때 직접 접속해보는 방식으로 확인했다.
하지만 서비스가 늘어나면서 모든 서비스를 계속 직접 확인하는 것은 효율적이지 않다는 생각이 들었다.
그때부터 서비스 상태를 확인할 수 있는 방법을 찾아보기 시작했다.
Uptime Kuma라는 서비스를 알게 됐다
Uptime Kuma는 웹사이트나 네트워크 서비스가 정상적으로 응답하는지 확인할 수 있는 모니터링 도구다.
내 NAS에는 이미 여러 Docker 서비스가 실행되고 있었기 때문에, Uptime Kuma 역시 같은 환경에서 운영해보기로 했다.
새로운 모니터링 서버를 따로 마련하는 대신 기존 NAS에 서비스를 하나 더 추가하는 방식이었다.
설치를 마치고 나니 NAS에서 실행되는 서비스들의 상태를 한곳에서 확인할 수 있는 기반이 마련됐다.
처음에는 단순히 프로그램 하나를 추가한 것처럼 보였다.
하지만 생각해보니 이 서비스는 기존에 설치했던 WordPress나 Vaultwarden처럼 무언가를 제공하는 서비스와는 역할이 달랐다.
다른 서비스가 정상적으로 동작하는지 확인하는 역할을 담당하기 때문이다.
서비스를 만드는 것과 관리하는 것은 달랐다
NAS 구축 초기에는 새로운 서비스를 설치하는 데 관심이 많았다.
WordPress를 만들고,
새로운 도메인을 연결하고,
Docker 컨테이너를 추가하고,
필요한 기능을 하나씩 구현하는 과정이 재미있었다.
그런데 서비스가 늘어나면서 관점이 조금 달라졌다.
이제는 새로운 기능을 추가하는 것뿐 아니라 이미 만들어놓은 서비스가 정상적으로 동작하는지도 중요해졌다.
사이트가 열리지 않는다면 어디에서 문제가 생겼는지 확인해야 했다.
컨테이너가 중지된 것인지, 웹서비스가 응답하지 않는 것인지, 외부 연결 경로에 문제가 있는 것인지 구분할 필요가 있었다.
Uptime Kuma는 이런 상황에서 서비스의 상태를 파악하는 데 도움을 줄 수 있었다.
서비스를 많이 만드는 것과 서비스를 안정적으로 운영하는 것은 서로 다른 일이었다.
이 부분을 직접 경험하면서 NAS를 바라보는 관점도 조금씩 바뀌기 시작했다.
모니터링은 무엇을 확인할 것인지 정하는 것부터 시작했다
모니터링 도구를 설치했다고 해서 모든 문제가 자동으로 해결되는 것은 아니다.
무엇을 감시할 것인지 먼저 정해야 한다.
웹사이트의 응답 상태를 확인할 수도 있고, 특정 네트워크 서비스가 응답하는지 확인할 수도 있다.
서비스마다 확인해야 하는 대상과 방식이 다를 수 있다.
예를 들어 웹사이트가 정상적으로 열리는지 확인하고 싶다면 실제 웹 주소를 기준으로 상태를 확인하는 방법을 사용할 수 있다.
반면 컨테이너의 실행 여부나 내부적인 오류까지 모두 확인하려면 Docker 상태와 서비스 로그 등을 별도로 살펴봐야 한다.
그래서 모니터링은 단순히 화면에 정상 표시가 나타나게 만드는 작업이 아니었다.
내가 중요하게 생각하는 서비스가 어떤 상태일 때 정상이라고 판단할지 정하는 과정이기도 했다.
모든 문제가 모니터링 화면에 나타나는 것은 아니다
Uptime Kuma를 사용하면서 구분해야 할 부분도 있었다.
서비스가 정상으로 표시된다고 해서 모든 기능이 완벽하게 작동한다는 뜻은 아니다.
예를 들어 WordPress 홈페이지가 정상적으로 열리더라도 관리자 로그인이나 글 작성, 데이터베이스의 모든 기능까지 정상이라고 보장할 수는 없다.
모니터링은 설정해둔 방식으로 서비스의 응답을 확인하기 때문이다.
반대로 문제가 생겼을 때도 모니터링 결과만 보고 원인을 단정해서는 안 된다.
필요하다면 실제 웹사이트에 접속해보고, Docker 컨테이너 상태와 로그도 확인해야 한다.
결국 Uptime Kuma는 모든 문제를 해결하는 도구라기보다, 문제가 있는지 파악하고 원인을 조사하는 데 도움을 주는 도구에 가까웠다.
AI와 함께 서비스를 하나씩 만들어온 과정
Uptime Kuma를 사용하게 된 과정도 이전과 크게 다르지 않았다.
Docker를 처음 시작했을 때부터 지금까지 새로운 서비스를 만들고 문제가 생기면 AI에게 질문하는 방식을 반복해왔다.
처음부터 모든 기술을 알고 시작한 것은 아니었다.
필요한 서비스를 찾고, 내 환경에서 어떻게 실행할 수 있는지 알아보고, 실제로 적용하면서 이해하는 방식이었다.
Uptime Kuma 역시 기존 NAS 환경에 새로운 역할을 추가하는 과정이었다.
예전 같았으면 모니터링 도구를 찾고, 설치 방법을 비교하고, 설정을 하나씩 검색하면서 시작했을 것이다.
지금은 내가 사용하는 NAS와 Docker 환경을 기준으로 질문하고, 필요한 부분을 확인하면서 진행할 수 있었다.
물론 AI가 알려준 방법을 적용하는 것만으로 끝나는 것은 아니었다. 실제로 실행한 뒤 정상적으로 동작하는지 확인하는 과정도 필요했다.
이런 과정을 반복하면서 새로운 기술을 접하는 부담이 조금씩 줄어들었다.
NAS가 커질수록 관리도 함께 필요했다
처음 NAS를 설치했을 때는 서비스를 몇 개만 사용하면 충분할 것이라고 생각했다.
그런데 지금은 여러 웹서비스와 데이터베이스, DNS, 모니터링 도구 등이 함께 실행되고 있다.
각 서비스가 맡은 역할도 다르고, 서로 연결된 부분도 있다.
이런 환경에서는 단순히 컨테이너가 많다는 사실보다 전체적인 상태를 이해하고 관리하는 것이 중요해졌다.
Uptime Kuma를 추가한 이유도 여기에 있었다.
새로운 서비스를 실행하는 데서 그치지 않고, 이미 운영 중인 서비스가 정상적으로 작동하는지 확인할 방법을 마련하고 싶었다.
서비스가 늘어날수록 관리 방법도 함께 발전해야 한다는 것을 조금씩 배우고 있었다.
이제는 새로운 기능만큼 운영에도 관심이 생겼다
돌이켜보면 NAS를 처음 구매했을 때와 지금은 생각하는 방식이 많이 달라졌다.
처음에는 좋은 NAS를 구입하고 필요한 프로그램을 설치하면 충분하다고 생각했다.
Docker를 사용하면서 서비스를 직접 만들게 됐고, 외부 접속을 구성하면서 네트워크도 알아가게 됐다.
이제는 만들어놓은 서비스를 어떻게 유지하고 관리할지도 생각하게 됐다.
서비스가 정상적으로 작동하는지 확인하고, 문제가 생기면 어디부터 살펴봐야 하는지 정리하는 일도 NAS 운영의 일부였다.
NAS를 구축한다는 것은 서비스를 설치하는 것으로 끝나는 일이 아니었다.
계속 사용하는 환경이라면 운영과 관리까지 함께 생각해야 했다.
다음에는 Docker 자동 업데이트를 살펴보려고 한다
서비스가 많아지면서 업데이트도 신경 쓰이는 일 중 하나였다.
컨테이너가 하나둘일 때는 직접 업데이트하면 됐지만, 실행 중인 서비스가 늘어나면 매번 확인하는 과정도 번거로워질 수 있다.
그래서 이전에 사용하기 시작한 것이 Watchtower였다.
자동 업데이트는 편리했지만, 모든 컨테이너를 같은 방식으로 자동 관리해도 괜찮은지 생각해볼 필요가 있었다.
다음 글에서는 Watchtower를 사용하면서 자동 업데이트를 경험하고, 일부 컨테이너는 별도로 관리하도록 구성했던 이야기를 정리해보려고 한다.
NAS를 하나씩 확장하다 보니 이제는 새로운 서비스를 만드는 것만큼, 이미 운영하고 있는 서비스를 어떻게 안정적으로 유지할 것인지도 중요한 과제가 되어가고 있었다.