대규모 환경에서 안정적으로 모니터링하기

Airbnb는 observability 스택이 장애 시스템과 같은 기반 위에 올라가 있으면, 정작 장애 때 대시보드와 알림이 함께 꺼진다는 문제를 짚었다. 메트릭 파이프라인이 자신이 관측해야 할 인프라에 의존하는 순환 의존성이 핵심 리스크였다.

해결책은 내부 고객별로 중복된 고가용성 경로를 주는 것이었다. 다만 외부 장애 도메인 전체에 대한 중복성은 책임지지 않고, 사내 고객에게 관측 신호를 안정적으로 전달하는 범위로 역할을 분명히 했다.

컴퓨트 계층에서는 제품/인프라 애플리케이션과 분리된 전용 Kubernetes 클러스터로 옮겼다. 클라우드 팀이 운영과 유지보수를 계속 맡아 운영 부담을 줄였고, 변경은 한 번에 하나씩 낮은 우선순위 클러스터에서 먼저 검증해 리스크를 낮췄다.

네트워크 계층에서는 Istio 서비스 메시에서 벗어나 Envoy 기반의 커스텀 L7 ingress를 구축했다. 이 계층은 읽기·쓰기 요청을 적절한 백엔드로 라우팅하고, 서비스별 tenant header로 1,000개가 넘는 서비스를 단일 글로벌 사용자 공간에서 분산 처리한다.

• 관측 트래픽을 비즈니스 트래픽과 분리해 충돌을 줄였다.
• 메트릭 미러링, 세분화된 접근 제어 같은 커스텀 기능을 넣을 수 있게 됐다.
• 공유 데이터 플레인이 막혀도 관측 경로는 독립적으로 유지된다.

마지막으로 meta-monitoring을 위해 별도 Prometheus와 Alertmanager를 각각 HA 세트로 운영했다. 이들은 관측 스택과 다른 노드와 AZ에 배치되고, 알림은 AWS SNS로 흘러간 뒤 CloudWatch alarm이 들어오는 메시지율을 감시한다. 신호가 끊기면 Dead Man's Switch가 발동해 온콜이 즉시 호출된다.

핵심은 모니터링 자체를 또 하나의 프로덕션 시스템으로 보고, 장애 시에도 살아남을 독립 경로를 끝까지 확보하는 데 있다.