¶ 13권 — 모니터링·관측(Observability) 체계 도입하기
"장애가 나면 사용자가 문의를 준다"는 방식은 문제 발견과 원인 파악 모두를 지연시킨다. 관측(Observability)은 시스템 내부 상태를 외부에서 질의 가능하게 만드는 능력이다.
목표는 예쁜 그래프가 아니라 장애 시 팀이 스스로 "지금 무엇이 문제인가"를 빠르게 답할 수 있게 만드는 것이다.
¶ 왜 모니터링이 필요한가 — 구축 시점 판단 기준
구축 시점은 다음 세 가지다.
- 프로덕션에 실사용자가 붙는 시점(최소한의 헬스체크·에러 로그는 첫 배포부터)
- 온콜 체계가 생기는 시점
- 장애 원인 파악에 반복적으로 오래 걸리는 시점
¶ 메트릭·로그·트레이스: 관측의 3요소
OpenTelemetry는 이 세 신호가 서로 연관(correlate)되도록 설계된 벤더 중립적 표준이다.
- 메트릭 — 시간에 따라 기록되는 숫자 데이터로, Prometheus가 클라우드 네이티브 생태계의 사실상 표준이다
- 로그 — 서버가 여러 대로 늘어나는 순간 중앙화가 필요해진다
- 트레이스 — 하나의 요청이 여러 서비스를 거치는 흐름을 추적해 마이크로서비스 전환 시점부터 가치가 커진다
메트릭 선정 기준으로 Google SRE Book의 "4대 골든 시그널"이 널리 쓰인다.
- Latency(지연)
- Traffic(트래픽)
- Errors(에러)
- Saturation(포화도)
초기 단계라면 트레이스보다 메트릭·로그 정비가 투자 대비 효과가 크다.
¶ 대시보드·알림 설계
대시보드의 목적은 "이상을 빠르게 알아채는 것"이며, 4대 골든 시그널을 서비스 단위 기본 골격으로 삼는다.
알림 설계의 가장 흔한 실패는 "너무 많아서 무시하게 되는 것"이다. 증상(symptom) 중심으로 알림을 걸고, 원인이 아니라 RED 방법론(Rate·Errors·Duration)에 따라 설계할 것이 권장된다.
임계치는 다음 절차를 권한다.
- 2~4주간 베이스라인을 관찰
- 명백히 비정상적인 구간에만 알림을 걸기
- 사후 검토로 정기 조정
¶ SLO·SLI로 알림 기준을 정교화하기
작은 조직은 다음 순서로 도입할 것을 권한다.
- 핵심 사용자 여정 1~2개 선정
- 그에 대한 SLI 하나 정의
- 현실적 목표치 설정
- 목표를 벗어나는 추세(에러 버짓 소진 속도)에만 알림 걸기
SLO는 도입보다 개발팀·비즈니스팀 간 합의가 더 어려운 부분이다.
¶ 온콜 프로세스와 연결하기
대시보드·알림이 아무리 좋아도 "누가, 무엇을, 어떻게" 대응할지 정해져 있지 않으면 무용지물이다. 작은 조직은 다음 단계로 점진 확장할 수 있다.
- 비공식 당번제
- 알림 라우팅 도입
- 정식 온콜 툴 도입
¶ TodoBox의 능동적 점검 체계 — 두 층위의 자동화
TodoBox는 두 층위의 점검을 함께 운영한다.
- 매일 아침 실행되는 점검 스케줄러 — 헬스체크·DB 커넥션 상태·전일 에러율 요약을 Slack으로 보고
- 1~10분 주기로 임계치 초과를 감지해 재시작·스케일아웃 같은 자동 조치를 먼저 시도하고 결과를 알리는 촘촘한 점검
느리지만 넓은 시야와 좁지만 빠른 시야를 함께 두어, 사람이 상주하지 않아도 이상을 놓치지 않는 체계를 구현한 사례다.
¶ 핵심 포인트 — "관측 가능성 없는 시스템은 블랙박스다"
관측 체계가 없는 시스템은 겉으로 잘 작동하는 것처럼 보여도 내부에서 무슨 일이 일어나는지 아무도 모르는 블랙박스다.
중요한 것은 창문의 개수가 아니라 위치이며, 모든 것을 계측하려는 완벽주의는 오히려 신호를 잡음에 묻히게 한다.
¶ 참고할 만한 사례
리디(RIDI)의 시스템 엔지니어 없이 시작해 점진적으로 갖춘 모니터링·온콜 체계, Google SRE의 4대 골든 시그널 철학, Netflix의 카오스 엔지니어링(정상 상태 정의 후 의도적 장애 실험)이 소개된다.
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.