모니터링, 관찰 가능성, 관리 용이성

프로덕션 시스템을 운영하는 건 세 단계야. 모니터링이 "뭔가 잘못됐어"를 알려주고, 관찰 가능성이 "왜 잘못됐는지"를 파악하게 해주고, 관리 용이성이 코드 변경 없이 고칠 수 있게 해줘. 이 셋이 운영의 삼위일체지.

모니터링부터 보자. **메트릭(metrics)**은 시간 간격마다 수집되는 숫자 측정값이야 — 요청 비율, 에러 비율, 지연 시간 퍼센타일, CPU/메모리 사용률. 근데 메트릭만으로는 "좋다"가 뭔지 모르잖아. **SLI(Service-Level Indicator)**가 서비스 수준의 정량적 측정값이고, **SLO(Service-Level Objective)**가 그 SLI의 목표값이야 — "30일 롤링 윈도우에서 99.9%의 요청이 200ms 이내에 완료" 같은 거지. SLO가 있어야 서비스가 건강한지 판단할 수 있어.

**알림(alert)**은 메트릭이 임계값을 위반할 때 트리거되는데, 핵심은 actionable해야 한다는 거야. 실행 불가능한 알림이 많으면 **알림 피로(alert fatigue)**가 생기고, 진짜 중요한 알림을 놓치게 돼. 대시보드는 시스템 건강의 시각적 표현이고, 핵심 지표에 집중해야 해. 그리고 온콜(on-call) — DevOps 시대에는 만든 팀이 운영도 하거든. 시스템의 부족한 점을 발견하는 가장 좋은 방법이야.

모니터링이 "언제"를 알려줬다면, 이제 "왜"를 찾아야 해. **로그(logs)**는 시스템 내부의 타임스탬프 기록인데, 분산 시스템에서는 여러 서비스에 걸쳐 집계되고 검색 가능해야 해. 구조화된 로깅(structured logging) — JSON 같은 형식 — 이 자유 형식 텍스트보다 훨씬 나은 쿼리를 가능하게 하지. **분산 추적(distributed tracing)**은 단일 요청이 여러 서비스를 통과하는 경로를 기록해. 핵심은 Trace ID를 로그에 주입해서 트레이스와 로그를 연결하는 거야. 디버깅 순서는 메트릭 -> 트레이스 -> 로그 — 메트릭이 이상 감지, 트레이스가 위치 특정, 로그가 원인 설명이야.

마지막으로 관리 용이성. 관찰해서 문제를 찾았으면 고칠 수 있어야 하잖아. 애플리케이션의 **설정(configuration)**은 코드에서 분리하고 전용 저장소(AWS AppConfig 등)에 보관해야 해. 런타임에 설정 변경에 반응하려면 애플리케이션이 주기적으로 설정을 다시 읽어야 하고, 이게 가능해지면 **피처 플래그(feature flags)**를 쓸 수 있어 — 새 기능을 비활성 상태로 배포하고 점진적으로 활성화하는 거지. 같은 메커니즘으로 A/B 테스트도 가능해. 다만 설정 변경은 치명적 장애의 주요 원인이기도 하니까, 점진적 롤아웃 + 강력한 관찰 가능성이 전제야 — 변경의 효과를 관찰할 수 없으면 안전하게 변경할 수도 없거든.

---

정리

18장 읽고 기억할 거 세 가지:

1. SLI -> SLO -> Alert 체인이 모니터링의 뼈대야 — 무엇을 측정하고, 목표를 정하고, 위반을 감지하는 구조지. 알림은 반드시 actionable해야 해.
2. 메트릭 -> 트레이스 -> 로그 순서로 디버깅해 — 세 신호를 Trace ID로 상관시키는 것이 분산 시스템 디버깅의 핵심이야.
3. 관리 용이성은 관찰 가능성 위에 세워져 — 런타임 설정 변경과 피처 플래그로 코드 배포 없이 행동을 바꿀 수 있지만, 변경의 효과를 관찰할 수 없으면 안전하게 변경할 수도 없어.