분산 시스템에서 모니터링과 옵저버빌리티의 차이

전통적인 모니터링은 미리 알고 있는 질문을 중심으로 구성됩니다. 서버가 살아 있는지, CPU가 80퍼센트를 넘는지, 디스크가 차고 있는지, 야간 작업이 끝났는지 같은 질문입니다. 운영자는 신호를 고르고, 임계값을 정하고, 그 값을 넘으면 알림을 보냅니다. 모놀리식 애플리케이션을 실행하는 소수의 서버라면 잘 작동합니다. 문제가 생길 수 있는 경우가 적고, 당직자가 이를 훤히 알고 있기 때문입니다.

한계는 모든 점검이 하나의 예측을 담고 있다는 점입니다. 느려진 하위 의존성, 재시도 폭주, 기술적으로는 살아 있지만 오래된 데이터를 반환하는 캐시처럼 아무도 예상하지 못한 장애가 발생하면, 고객이 불만을 제기하는 동안에도 대시보드는 정상으로 표시됩니다. 모니터링은 여전히 필요하지만, 시스템이 한 사람이 머릿속으로 파악할 수 있는 규모를 넘어서면 더 이상 충분하지 않습니다.

같은 비즈니스 기능을 메시지 큐를 사이에 둔 십여 개의 서비스로 나누면 세 가지가 달라집니다. 첫째, 하나의 사용자 요청이 여러 호스트의 여러 프로세스를 거치므로 어느 한 로그 파일도 전체 상황을 보여 주지 못합니다. 둘째, 장애가 부분적으로 발생합니다. 전체 지표는 정상으로 보이는데 특정 리전, 특정 테넌트, 특정 코드 경로만 느려집니다. 셋째, 시스템이 하루에도 여러 번 바뀌므로 어제의 기준선이 더 이상 유효하지 않습니다.

옵저버빌리티는 새로운 질문을 하기 위해 새 코드를 배포하지 않고도 시스템이 내보내는 데이터로 내부 상태를 이해할 수 있는 특성입니다. 실무에서는 어떤 고객, 어떤 엔드포인트, 어떤 버전, 어떤 리전인지 같은 풍부한 고카디널리티 텔레메트리를 수집하고, 필요할 때 이를 원하는 기준으로 나누어 볼 수 있다는 뜻입니다. 질문은 시스템이 살아 있는지에서, 어떤 사용자가 언제부터 느려졌고 무엇이 바뀌었는지로 옮겨 갑니다.

서비스 수준 목표는 사용자가 체감하는 지표에 대한 목표입니다. 예를 들어 30일 기준으로 결제 요청의 99.9퍼센트가 500밀리초 이내에 성공적으로 완료되는 것입니다. 비율과 기간은 조직이 정합니다. 핵심은 SLO가 호스트가 보고하는 내용이 아니라 사용자가 경험하는 내용을 나타낸다는 점입니다.

SLO는 기간 내에 감당할 수 있는 실패의 양인 오류 예산을 정의하고, 이에 따라 다른 알림 모델을 가능하게 합니다. CPU가 기준선을 넘을 때 호출하는 대신, 예산이 기간 끝까지 버티지 못할 만큼 빠르게 소진될 때 호출합니다(소진 속도 알림). 천천히 소진되면 다음 근무일의 티켓이 되고, 빠르게 소진되면 당직 엔지니어를 호출합니다. 이 변화 하나만으로 아무도 조치할 필요가 없는 알림 대부분이 사라집니다.

SLO는 엔지니어링과 비즈니스에 공통의 언어도 제공합니다. 예산이 여유 있으면 팀은 더 빨리 배포할 수 있고, 예산이 소진되고 있으면 안정성에 투자합니다. CPU 그래프로는 이런 대화를 할 수 없습니다.

모니터링 체계의 가장 흔한 실패는 알림이 부족한 것이 아니라 지나치게 많은 것입니다. 당직 순번에 일주일에 수십 건의 호출이 오고 대부분 조치가 필요 없다면, 사람들은 더 이상 알림을 읽지 않고 정작 중요한 알림은 소음 속에 묻힙니다. 모든 알림은 간단한 기준을 충족해야 합니다. 받은 사람이 즉시 무언가를 할 수 있어야 한다는 것입니다. 그렇지 않다면 호출이 아니라 대시보드 패널이나 일일 보고서에 들어가야 합니다.

알림 세트를 리뷰 대상 코드처럼 다루십시오. 모든 알림에는 책임자, 런북 링크와 존재 이유가 있어야 하며, 한 달 동안 조치 없이 발생한 알림은 삭제하거나 등급을 낮춥니다. 당직 순번 자체도 측정하십시오. 주당 호출 수, 업무 시간 외 호출 수, 확인까지 걸린 시간입니다. 건강한 온콜 순번은 건강한 시스템의 징표이며, 그렇지 않은 순번은 어디에 투자해야 하는지 분명히 알려 주는 신호입니다.

분산 시스템에는 요건이 하나 더 있습니다. 알림에 맥락이 담겨야 한다는 것입니다. “payments-api 오류율 높음”이라고만 적힌 호출은 조사 과제가 되지만, 영향을 받는 SLO, 최근 배포, 가장 많이 실패하는 엔드포인트로 연결되는 호출은 곧바로 결정을 내릴 수 있게 합니다.

옵저버빌리티 데이터에는 비용이 들며, 청구서는 대개 습관이 굳어진 뒤에 도착합니다. 비용을 좌우하는 요인은 두 가지입니다. 볼륨(요청당 로그와 스팬의 바이트 수에 트래픽을 곱한 값)과 카디널리티(메트릭의 고유한 레이블 조합 수)입니다. 사용자 ID나 요청 ID를 레이블로 붙인 메트릭은 값마다 새 시계열을 만들어 어떤 메트릭 저장소든 감당할 수 없게 만듭니다.

합리적인 기본값만으로도 상당한 효과를 거둘 수 있습니다. 카디널리티가 높은 식별자는 메트릭 레이블이 아니라 트레이스와 구조화된 로그에 담으십시오. 트레이스는 샘플링하되, 오류와 느린 요청은 모두 보존하고 정상 요청은 일부만 보존합니다. 보존 기간은 신호별로 정합니다. 메트릭은 해상도를 낮춰 1년, 로그는 수 주, 트레이스는 수일간 보관하고, 컴플라이언스상 필요한 데이터는 아카이브 계층에 둡니다. 로그를 가장 많이 발생시키는 원천은 매월 검토하십시오. 자주 실행되는 경로에 남겨 둔 장황한 디버그 구문 하나가 비용의 상당 부분을 차지할 수 있습니다.

목표는 모든 것을 수집하는 것이 아니라, 아직 예상하지 못한 다음 질문에 조직이 계속 감당할 수 있는 비용으로 신속하게 답하는 것입니다.