서론: "왜 안 되지?"에 대답하기
과거의 모놀리식 시스템에서는 서버가 죽으면 로그 파일 하나만 열어보면 원인을 알 수 있었습니다. 하지만 수십, 수백 개의 마이크로서비스가 얽혀 있는 현대의 분산 시스템에서는 "어디서" 문제가 발생했는지 찾는 것조차 모래사장 위에서 바늘 찾기입니다.
단순히 "서버가 살았나 죽었나"를 보는 **모니터링(Monitoring)**을 넘어, "왜 그런 상태가 되었나"를 설명할 수 있는 **관측 가능성(Observability)**이 필요한 이유입니다.
1. 관측 가능성의 3가지 기둥 (The Three Pillars)
A. 메트릭 (Metrics)
- 정의: 시간에 따라 측정된 수치 데이터입니다. (예: CPU 사용량 80%, 초당 요청 수 100)
- 용도: "무슨 일이 일어나고 있는가?"를 파악하는 데 쓰입니다. 대시보드를 구성하고 알람을 설정하는 기본 데이터입니다.
- 도구: Prometheus, Grafana, Datadog
B. 로그 (Logs)
- 정의: 시스템에서 발생한 이벤트의 기록입니다. (예: "Error: Connection timeout at 10:00:01")
- 용도: "구체적으로 어떤 에러가 발생했는가?"를 확인하는 데 쓰입니다. 가장 상세한 정보를 담고 있지만, 양이 방대하여 검색과 분석이 어렵습니다.
- 도구: ELK Stack (Elasticsearch, Logstash, Kibana), Loki
C. 트레이스 (Traces)
- 정의: 하나의 요청이 여러 서비스를 거쳐가는 전체 경로를 추적한 데이터입니다.
- 용도: "어느 구간에서 느려졌는가?"를 파악하는 데 필수적입니다. 각 서비스 구간(Span)별 소요 시간을 시각화하여 병목을 찾아냅니다.
- 도구: Jaeger, Zipkin, Tempo
2. 상관관계(Correlation)의 마법
진정한 관측 가능성은 이 세 가지 데이터를 따로 보는 것이 아니라, 연결해서 볼 때 완성됩니다.
이상적인 디버깅 시나리오:
- 알람 수신: "결제 서비스의 응답 시간이 2초를 넘었습니다." (Metric 기반)
- 대시보드 확인: 특정 시간대에 Latency가 튀는 것을 확인합니다.
- 트레이스 추적: 해당 시간대의 Trace ID를 클릭하여, 결제 서비스가 호출한 '재고 서비스'에서 지연이 발생했음을 발견합니다. (Trace 기반)
- 로그 분석: 재고 서비스의 해당 파드(Pod) 로그를 조회하여 "DB Connection Pool Exhausted" 에러를 찾아냅니다. (Log 기반)
이 모든 과정이 하나의 플랫폼에서 유기적으로 연결되어야 합니다.
3. CODEBLACK의 Observability 구축 전략
CODEBLACK은 오픈소스(OpenTelemetry)와 상용 솔루션(Datadog, New Relic)을 아우르는 폭넓은 경험을 보유하고 있습니다.
- OpenTelemetry 도입: 벤더 종속성을 피하기 위해 표준화된 데이터 수집 표준인 OpenTelemetry를 적용합니다.
- 비용 효율적인 설계: 로그와 메트릭은 쌓일수록 비용입니다. 샘플링(Sampling) 전략과 데이터 보관 주기(Retention) 정책을 최적화하여 비용을 통제합니다.
- 대시보드 커스터마이징: 개발자용, 운영자용, 경영진용 등 역할에 맞는 직관적인 대시보드를 구성합니다.
결론
"측정할 수 없으면 개선할 수 없다." - 피터 드러커
관측 가능성은 시스템의 블랙박스를 투명한 유리 상자로 바꾸는 작업입니다. 복잡한 시스템 속에서 길을 잃지 않도록, CODEBLACK이 여러분의 내비게이션이 되어드리겠습니다.