도입 — 새벽의 호출을 줄이는 관측의 힘
새벽 3시, 갑작스러운 스마트폰 알람 소리에 눈을 떴어요. 확인해 보니 운영 중인 서버의 핵심 서비스가 응답하지 않고 있어요. 급하게 터미널을 열어 docker ps를 입력하지만, 컨테이너 상태는 분명히 Up이라고 나와요. 하지만 실제 서비스는 먹통인 상태죠. 이런 상황에서 운영자는 극심한 스트레스와 함께 무엇이 잘못되었는지 찾아내기 위한 막막한 사투를 시작하게 돼요.
단순히 컨테이너가 켜져 있는지 확인하는 것만으로는 부족해요. 컴포즈 services 모니터링이 제대로 구축되어 있지 않다면, 서비스 내부에서 발생하는 미세한 성능 저하나 논리적 오류를 놓치기 쉬워요. 컨테이너는 살아있지만, 내부의 애플리케이션이 좀비 상태가 된 경우를 잡아내지 못하는 것이죠. 이는 결국 사용자의 불편으로 이어지고, 운영자의 휴식을 방해하는 원인이 돼요.
우리가 원하는 것은 단순히 장애가 났을 때 알람을 받는 것이 아니에요. 장애가 발생하기 직전의 전조 증상을 포착하고, 문제가 발생했을 때 어떤 서비스의 어떤 지표가 문제인지 즉시 파악할 수 있는 체계를 갖추는 것이 핵심이에요. 관측 체계가 잘 잡혀 있다면, 장애 대응 시간은 비약적으로 단축되고 불필요한 야간 호출도 현저히 줄어들 수 있어요.
이 글에서는 도커 컴포즈 환경에서 services 블록을 중심으로 어떻게 하면 견고한 관측 시스템을 만들 수 있는지 실무적인 관점에서 다뤄볼게요. 단순히 도구를 나열하는 것이 아니라, 운영자의 시각에서 무엇을 어떻게 구성해야 하는지 단계별로 안내해 드릴게요.
- 컨테이너의 실질적 상태를 판단하는 헬스체크 설정법
- Prometheus와 cAdvisor를 활용한 지표 수집 구성
- 로그 통합 관리와 효율적인 검색 전략
- 알람 피로도를 줄이는 스마트한 알림 규칙 설계
사전 준비 — 기본 이해와 체크리스트
본격적으로 모니터링을 구축하기 전에, 우리가 무엇을 관측할 것인지 명확히 정의해야 해요. 모든 데이터를 다 수집하려고 하면 시스템에 과부하가 걸리고, 정작 중요한 정보는 노이즈에 묻혀버릴 수 있어요. 컴포즈 services 모니터링의 목표는 ‘가시성 확보’와 ‘빠른 대응’ 사이의 균형을 잡는 것이에요.
먼저, 모니터링의 대상을 세 가지 계층으로 나누어 생각해야 해요. 첫 번째는 컨테이너 자체의 자원 사용량(CPU, Memory, Network, Disk I/O)이고, 두 번째는 서비스 내부의 애플리케이션 지표(Request per second, Error rate, Latency 등)예요. 마지막 세 번째는 컨테이너가 남기는 로그 데이터예요. 이 세 가지가 유기적으로 연결되어야 장애의 원인을 입체적으로 파악할 수 있어요.
또한, 현재 운영 환경의 규모와 요구되는 가용성을 고려하여 도구를 선택해야 해요. 소규모 프로젝트라면 가벼운 스택으로도 충분하지만, 마이크로서비스로 확장될 예정이라면 확장성이 검증된 오픈소스 조합을 선택하는 것이 현명해요.
| 모니터링 방식 | 장점 | 단점 | 추천 대상 |
|---|---|---|---|
| 단순 로그 기반 | 구축이 매우 간편함 | 트렌드 파악 및 예측 불가 | 개발 단계 프로젝트 |
| 지표(Metrics) 중심 | 자원 사용량 및 성능 추이 분석 탁월 | 초기 설정 및 학습 비용 발생 | 실서비스 운영 환경 |
| 통합 관측(Full Stack) | 장애 원인 파악이 매우 빠름 | 높은 리소스 소모와 복잡성 | 엔터프라이즈급 인프라 |
준비 단계에서 반드시 체크해야 할 사항들이 있어요. 네트워크 가용성, 로그 저장 공간의 충분함, 그리고 모니터링 도구 자체가 장애를 일으키지 않도록 하는 리소스 격리 전략이에요. 특히 도커 컴포즈로 여러 서비스를 띄울 때는 각 서비스가 사용하는 네트워크 브릿지가 모니터링 에이전트와 잘 통신할 수 있는지 미리 확인하는 것이 좋아요.
모니터링 도구가 너무 많은 리소스를 점유하면, 오히려 모니터링 때문에 서비스 성능이 떨어지는 ‘관측자 효과’가 발생할 수 있어요. 에이전트의 CPU와 메모리 사용량 제한(Limit)을 반드시 설정하세요.
핵심 본문 — 단계별 실행
이제 실제로 컴포즈 services 모니터링을 구축하는 구체적인 단계를 살펴볼게요. 이 과정은 크게 상태 점검, 지표 수집, 로그 통합, 그리고 알림 설계로 나뉩니다. 각 단계는 유기적으로 연결되어 하나의 거대한 관측 체계를 완성하게 돼요.
STEP 1. 서비스 생존을 증명하는 헬스체크 설정
가장 기초적이면서도 중요한 단계예요. 단순히 컨테이너가 running 상태라고 해서 서비스가 정상이라고 믿어서는 안 돼요. Healthcheck 기능을 사용하면 서비스 내부의 실제 응답을 기반으로 상태를 판단할 수 있어요.
예를 들어, 웹 서버 서비스라면 단순히 프로세스가 떠 있는지 보는 게 아니라, 특정 엔드포인트로 HTTP 요청을 보내서 200 OK가 돌아오는지 확인해야 해요. docker-compose.yml 파일에 다음과 같이 설정할 수 있어요.
services:
web-app:
image: my-web-app:latest
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
여기서 start_period 설정이 정말 중요해요. 애플리케이션이 초기 구동되는 데 시간이 걸린다면, 그 기간 동안은 헬스체크 실패로 간주하지 않도록 여유를 주어야 해요. 그렇지 않으면 부팅 중에 서비스가 계속 재시작되는 무한 루프에 빠질 수 있거든요. 또한, interval 주기를 너무 짧게 잡으면 서비스에 부하를 줄 수 있으니, 서비스 특성에 맞춰 30초에서 1분 사이로 조절하는 것을 추천해요.
STEP 2. 지표 수집을 위한 Prometheus와 cAdvisor 구성
상태 점검이 ‘생사 확인’이라면, 지표 수집은 ‘건강 검진’이에요. 컨테이너가 얼마나 힘들어하고 있는지 수치로 알아내야 하죠. 이를 위해 가장 많이 쓰이는 조합은 Prometheus와 cAdvisor예요.
cAdvisor는 Google에서 만든 도구로, 도커 컨테이너의 CPU, 메모리, 네트워크 사용량을 자동으로 수집해서 Prometheus가 읽을 수 있는 형태로 노출해 줘요. 컴포즈 파일에 cAdvisor 서비스를 추가하기만 하면 됩니다. 이렇게 수집된 데이터는 시계열 데이터베이스에 저장되어, 과거의 패턴과 현재를 비교할 수 있게 해 줘요.
지표를 수집할 때는 반드시 골든 시그널(Golden Signals)을 기준으로 삼으세요. 서비스의 지연 시간(Latency), 트래픽(Traffic), 오류(Errors), 포화도(Saturation) 이 네 가지를 우선적으로 수집해야 해요. 예를 들어, 메모리 사용량이 급격히 상승하는 ‘포화도’ 지표를 보면, 메모리 누수(Memory Leak)가 발생했음을 사전에 예측할 수 있어요.
STEP 3. 로그 통합 관리와 효율적인 검색 환경 구축
지표가 ‘언제 문제가 생겼는가’를 알려준다면, 로그는 ‘왜 문제가 생겼는가’에 대한 결정적인 단서를 제공해요. 컨테이너는 수시로 생성되고 삭제되기 때문에, 로그가 컨테이너 안에 남아있으면 안 돼요. 반드시 외부 저장소로 로그를 보내는 로그 어그리게이션(Aggregation)이 필요해요.
가장 권장하는 방식은 Loki나 ELK Stack을 사용하는 거예요. 특히 최근에는 리소스 효율이 좋은 Loki가 인기가 많아요. 각 컨테이너의 로그를 중앙 서버로 모으고, 서비스명이나 컨테이너 ID별로 태그를 달아두면 나중에 특정 시점의 로그를 검색하기가 매우 수월해져요.
로그를 설계할 때는 구조화된 로깅(Structured Logging)을 지향하세요. 단순히 텍스트를 찍는 게 아니라, JSON 형식으로 로그를 남기면 나중에 특정 에러 코드나 사용자 ID로 필터링할 때 검색 속도가 압도적으로 빨라져요. “Error occurred”라고 남기기보다는 `{“level”: “error”, “service”: “auth”, “user_id”: 123, “msg”: “invalid token”}` 처럼 남기는 습관을 들여보세요.
STEP 4. 알림 피로도를 줄이는 스마트한 알림 규칙 설계
모니터링 시스템이 구축되었다고 해서 모든 지표에 알람을 걸면 안 돼요. 모든 알람이 울리기 시작하면 운영자는 결국 알람을 무시하게 되는 알람 피로도(Alert Fatigue) 현상을 겪게 돼요. 진짜 중요한 장애만 알람으로 오도록 설계하는 기술이 필요해요.
알람 규칙을 설계할 때는 다음의 원칙을 지켜보세요.
- 심각도 분류: 즉시 대응이 필요한 ‘Critical’과 업무 시간에 확인해도 되는 ‘Warning’을 엄격히 구분하세요.
- 임계치 설정: 단 한 번의 튀는 수치(Spike)에 알람을 울리지 마세요. 예를 들어, CPU 사용량이 5분 동안 지속적으로 90%를 넘었을 때만 알람이 울리도록 설정해야 해요.
- 중복 제거: 동일한 장애로 인해 여러 서비스에서 동시에 알람이 올 경우, 이를 하나로 묶어서 전달하는 기능을 활용하세요.
최종적으로는 Slack이나 PagerDuty 같은 도구와 연동하여, 팀원들이 즉시 인지할 수 있는 채널로 메시지를 보내도록 구성하세요. 알람 메시지에는 장애 발생 시간, 대상 서비스, 현재 지표 값, 그리고 대응 가이드(Runbook) 링크가 포함되어야 해요. 그래야 당황하지 않고 바로 대응을 시작할 수 있어요.
1. 상황: API 서비스의 응답 속도가 평소보다 3배 느려짐.
2. 감지: Prometheus 지표를 통해 Latency 임계치 초과 알람 수신.
3. 분석: Grafana 대시보드에서 확인하니 특정 컨테이너의 CPU 사용량이 급증함.
4. 추적: Loki 로그를 검색하니 DB 커넥션 풀이 가득 찼다는 에러 메시지 발견.
5. 해결: DB 커넥션 설정을 조정하고 서비스를 재시작함.
자주 하는 실수와 해결법
실제 운영 환경에서 모니터링을 구축하다 보면 예상치 못한 난관에 부딪히곤 해요. 많은 운영자가 반복하는 실수와 그 해결책을 정리해 보았어요.
❌ 실수: 컨테이너의 ‘Running’ 상태만 믿고 헬스체크를 생략함
왜 발생하는가: 설정이 귀찮거나 서비스가 단순하다고 판단하기 때문이에요. 하지만 앱 내부가 멈춘 ‘좀비 컨테이너’는 이 방법으로 잡아낼 수 없어요.
✅ 해결법: 반드시 애플리케이션 엔드포인트를 활용한 헬스체크를 설정하세요.
❌ 실수: 모든 지표에 대해 알람을 설정함
왜 발생하는가: 혹시 모를 장애를 놓칠까 봐 불안해서 모든 수치에 임계치를 걸기 때문이에요. 결과적으로 중요하지 않은 알람이 쏟아져 진짜 장애를 놓치게 돼요.
✅ 해결법: ‘사용자 경험에 직접적인 영향을 주는 지표’부터 우선순위를 정하세요.
❌ 실수: 로그 로테이션 설정을 하지 않음
왜 발생하는가: 초기에는 로그 양이 적어 문제가 안 보이기 때문이에요. 하지만 서비스가 커지면 로그 파일이 디스크를 가득 채워 서버 전체가 다운되는 대참사가 발생해요.
✅ 해결법: Docker의 log-driver 설정을 통해 최대 파일 크기와 개수를 반드시 제한하세요.
❌ 실수: 모니터링 도구의 리소스를 제한하지 않음
왜 발생하는가: 모니터링 도구가 원활하게 돌아가게 하려고 시스템 자원을 다 내어주기 때문이에요. 정작 서비스가 자원을 써야 할 때 모니터링 도구가 방해를 해요.
✅ 해결법: Compose 파일의 deploy/resources 섹션을 통해 모니터링 에이전트의 CPU와 메모리 상한선을 설정하세요.
❌ 실수: 알람 메시지에 정보가 부족함
왜 발생하는가: 단순히 “Error occurred”라는 메시지만 보내기 때문이에요. 알람을 받고 나서 무엇을 해야 할지 몰라 다시 검색하는 데 시간을 허비하게 돼요.
✅ 해결법: 알람 메시지에 해당 장애를 해결하기 위한 체크리스트나 문서 링크를 포함하세요.
자주 묻는 질문
Q. 소규모 프로젝트인데 Prometheus까지 써야 할까요?
프로젝트의 성장 가능성을 고려하세요. 만약 향후 서비스가 늘어날 예정이라면 처음부터 Prometheus와 Grafana 조합을 익혀두는 것이 나중에 고생을 덜 하는 방법이에요. 아주 작다면 단순히 로그 수집기만 잘 갖춰도 충분해요.
Q. 헬스체크가 계속 실패해서 컨테이너가 무한 재시작돼요. 어떻게 하죠?
가장 흔한 문제예요. start_period가 너무 짧지는 않은지, 혹은 헬스체크에 사용하는 명령어(예: curl)가 컨테이너 이미지 안에 설치되어 있는지 확인해 보세요. 가벼운 이미지를 쓰다 보면 curl이 없는 경우가 많거든요.
Q. 모니터링 지표 수집이 서비스 성능을 저하시키지는 않나요?
네, 영향을 줄 수 있어요. 그래서 수집 주기(Scrape Interval)를 너무 짧게 잡지 않는 것이 중요해요. 보통 15초~60초 사이가 적당하며, 지표 수집량이 너무 많다면 필요한 지표만 골라서 수집하도록 필터링해야 해요.
Q. 컨테이너가 삭제되면 로그도 사라지는데 어떻게 관리하나요?
그래서 로그를 컨테이너 외부로 보내야 해요. Docker의 logging driver를 사용하여 syslog나 fluentd, 혹은 loki로 로그를 즉시 전송하도록 설정하면 컨테이너가 사라져도 기록은 안전하게 남아요.
Q. 알람을 어디로 받는 게 가장 효율적인가요?
업무용 메신저(Slack, Discord, Teams)가 가장 좋아요. 별도의 페이지 호출 서비스(PagerDuty 등)를 결합하면 야간에도 긴급한 장애를 확실히 인지할 수 있어요.
핵심 요약과 다음 단계
오늘 배운 내용을 바탕으로 안정적인 컴포즈 services 모니터링 체계를 구축해 보세요. 처음부터 완벽할 필요는 없어요. 하나씩 단계를 밟아 나가는 것이 중요해요.
- 단순한 ‘Running’ 상태가 아닌 실제 앱 응답을 확인하는 헬스체크를 구현하세요.
- cAdvisor와 Prometheus를 활용해 골든 시그널(지연, 트래픽, 오류, 포화도)을 수집하세요.
- 로그는 반드시 외부 저장소로 통합하여 구조화된 형태로 관리하세요.
- 알람 피로도를 줄이기 위해 심각도와 임계치를 세심하게 설계하세요.
- 모니터링 도구 자체의 리소스 사용량도 반드시 통제하세요.
지금 당장 모든 것을 바꿀 수는 없어요. 하지만 아래의 순서대로 실행해 본다면 분명히 변화를 체감할 수 있을 거예요.
🚀 오늘 할 일: 현재 운영 중인 서비스 중 가장 핵심적인 서비스 하나를 골라 healthcheck 설정을 추가해 보세요.
📅 이번 주 할 일: Prometheus와 Grafana를 설치하여 기본적인 CPU, 메모리 지표를 시각화해 보세요.
🛠️ 실행 직전 할 일: 장애 발생 시 팀원들이 즉시 확인할 수 있는 Slack 알림 채널을 생성하고 테스트 메시지를 보내 보세요.
가장 중요한 것은 핵심 지표 3가지만 먼저 정하고 알림을 거는 것이에요. 처음부터 거창한 대시보드를 만들려다 포기하지 마시고, 작은 성공부터 쌓아가시길 응원해요.
관련하여 더 깊은 내용이 궁금하다면, 도커 컴포즈 기본 개념 완벽 정리 — 개념부터 실무 활용까지 한눈에 보는 가이드를 먼저 읽어보시는 것을 추천드려요.
