플랫폼 엔지니어링 09 - 플랫폼 엔지니어를 위한 관측 가능성

모니터링과 관측 가능성의 차이

모니터링과 관측 가능성은 비슷해 보이지만 근본적으로 다른 질문에 답하는 것이다. 모니터링은 "시스템이 살아 있는가?"를 확인하는 데 초점을 맞추고, 관측 가능성은 "시스템이 왜 이렇게 동작하는가?"를 파악하는 데 초점을 맞춘다.

모니터링은 무언가 잘못되었다는 사실을 알려주는 역할을 한다. 반면 관측 가능성은 구체적으로 무엇이 왜 잘못되었는지를 추적하고 이해할 수 있게 해주는 것이다. 장애 패턴이 예측 가능한 단순한 시스템에서는 모니터링만으로 충분할 수 있지만, 마이크로서비스 환경처럼 예상치 못한 방식으로 장애가 발생하는 시스템에서는 관측 가능성이 필수적인 셈이다.

세 가지 기둥

관측 가능성은 세 가지 신호를 기반으로 한다.

로그는 개별 이벤트를 기록하는 역할을 한다. "사용자 123이 14:32:01에 토큰 만료로 인증에 실패했다"와 같은 정보가 이에 해당한다. 메트릭은 시간에 따른 수치 데이터를 집계하여 보여주는 것이다. "p99 지연이 450ms이다", "에러율이 2.3%이다"와 같은 형태로 시스템의 전반적인 상태를 파악하는 데 유용하다. 트레이스는 하나의 요청이 여러 서비스를 거치는 여정을 추적한다. "서비스 A를 거쳐 서비스 B로 전달되었고, 데이터베이스에서 800ms를 대기했다"와 같은 흐름을 보여주는 것이다.

이 세 가지를 조합하면 "뭔가 느리다"라는 막연한 증상에서 "서비스 B의 특정 쿼리가 X 리전 사용자에게 느리다"라는 구체적인 원인으로 좁혀갈 수 있다. 각각의 신호만으로는 부분적인 그림밖에 보이지 않지만, 세 가지가 결합되면 시스템의 동작을 입체적으로 이해할 수 있게 되는 것이다.

OpenTelemetry

OpenTelemetry(OTel) 이전에는 벤더마다 자체 SDK, 에이전트, 데이터 포맷을 사용했다. 이러한 환경에서 벤더를 교체하려면 모든 서비스의 계측 코드를 전부 다시 작성해야 했다. 통합이 깊어질수록 벤더 종속이 심해지는 구조였던 것이다.

OTel은 이 문제를 해결하는 벤더 중립 표준이다. 한 번 계측하면 원하는 백엔드로 데이터를 보낼 수 있다.

앱 (OTel SDK) --> OTel Collector --> 백엔드 (Grafana/Datadog 등)

플랫폼 팀이 Collector를 인프라로 제공하고, 골든 패스 템플릿에 SDK를 미리 설정해두면 개발 팀이 별도의 작업을 하지 않아도 모든 서비스가 기본적으로 관측 가능성을 갖추게 되는 것이다.

관측 가능성을 서비스로 제공

각 팀에게 로깅, 메트릭, 트레이싱을 알아서 구축하라고 맡기면 어떻게 되는가? 6개월이 지나면 절반은 트레이스가 아예 없고, 나머지 절반은 의미 없는 데이터를 보내는 상황이 발생한다. 팀마다 기술 수준과 우선순위가 다르기 때문에 당연한 결과이다.

플랫폼 접근 방식은 이와 근본적으로 다르다. 중앙화된 컬렉터, 저장소, 대시보드를 플랫폼 팀이 운영하고, 베이스 이미지나 사이드카를 통해 자동으로 계측이 이루어지도록 구성한다. 즉시 동작하는 기본 대시보드도 함께 제공하여, 각 팀은 이 기반 위에서 자신의 서비스에 맞는 커스터마이징만 추가하면 되는 것이다.

새로운 서비스가 배포되면 아무런 설정 없이도 첫날부터 로그, 메트릭, 트레이스를 갖추고 있어야 한다. 이것이 관측 가능성을 서비스로 제공한다는 것의 의미이다.

SLI, SLO, 그리고 알림

관측 데이터가 아무리 풍부해도 맥락이 없으면 소음에 불과하다. 데이터에 의미를 부여하는 것이 SLI와 SLO의 역할이다.

SLI(Service Level Indicator)는 서비스의 건강 상태를 측정하는 구체적인 메트릭이다. "200ms 이내에 응답한 요청의 비율"과 같은 형태로 정의한다. SLO(Service Level Objective)는 해당 SLI의 목표값을 정의하는 것이다. "30일 기준으로 99.5%가 200ms 이내에 응답해야 한다"와 같이 설정한다. 플랫폼 팀은 이러한 도구를 제공하고, 각 팀은 자신의 서비스에 맞는 SLI를 정의하고 목표를 설정하면 자동으로 알림을 받는 구조이다.

알림을 설정할 때 중요한 원칙이 있다. 원인이 아닌 증상에 알림을 걸어야 한다는 것이다. "CPU 사용률이 80%를 초과했다"가 아니라 "에러율이 1%를 초과했다"에 알림을 거는 것이 올바른 접근이다. CPU 사용률이 높더라도 사용자에게 영향이 없다면 긴급하게 대응할 필요가 없기 때문이다. 그리고 모든 알림은 수신자가 취할 수 있는 구체적인 조치가 있어야 한다. 취할 조치가 없는 알림은 알림이 아니라 소음인 것이다.

모든 서비스에는 요청률, 에러율, 지연 시간을 보여주는 기본 대시보드가 제공되어야 하며, 각 팀이 전체를 포크하지 않고도 커스텀 패널을 추가할 수 있어야 한다.

다음 내용

보이지 않는 것은 고칠 수 없다. 관측 가능성이 옵트인 방식이 아닌 기본값으로 제공되면, 장애 대응과 디버깅의 양상이 근본적으로 달라지는 것이다.

다음 포스트에서는 골든 패스에 녹여내는 보안과 거버넌스를 다룬다.