Kubernetes 운영 팀에는 CPU와 메모리 사용량, 오류율을 보여주는 대시보드 이상의 것이 필요합니다. 클라우드 네이티브 환경의 복잡성 때문에 하나의 요청이 인그레스 게이트웨이, 서비스, 큐, 스토리지, 백그라운드 작업을 거치는 동안 워크로드가 계속 이동하고 버전도 지속적으로 변경됩니다. 따라서 Deployment 수준에서는 배포가 정상적으로 보이더라도 이후 단계의 종속성, 재시도 루프 또는 컨트롤 플레인 경로의 부하로 인해 지연 시간이 증가할 수 있습니다.
CNCF 블로그에 게시된 자료에서 Stackgen의 Neel Shah는 전통적인 모니터링이 “CPU 사용량이 특정 한도를 넘었는가?”, “오류가 증가하고 있는가?”와 같이 미리 정해진 특정 질문에 답한다고 설명합니다. 반면 해당 자료의 설명에 따르면 관측 가능성은 팀이 예상하지 못했던 문제를 조사하고, 증상을 관찰하는 단계에서 원인과 범위를 이해하는 단계로 나아가도록 돕는 것을 목표로 합니다.
메트릭은 조사를 시작하게 하지만 끝내지는 않는다
메트릭은 수치화되어 있고 저장과 조회에 효율적이며 알림과 추세 분석에 적합하기 때문에 여전히 자연스러운 출발점입니다. Kubernetes에서는 노드 압박, 컨테이너 재시작, 요청 지연 시간 증가, API 서버 성능 저하 또는 큐 항목 누적을 보여줄 수 있습니다.
이 자료는 서비스에 RED 방식, 즉 요청률·오류·지속 시간과 인프라에 USE 방식, 즉 사용률·포화도·오류를 활용할 것을 제안합니다. 이러한 지표는 사고의 초기 상황을 그리는 데 도움이 됩니다. 요청률이 증가하면서 지연 시간이 안정적인 경우는 트래픽이 일정한데 지속 시간과 포화도가 증가하는 경우와 다릅니다.
하지만 모든 세부 정보를 메트릭의 레이블로 바꾸면 cardinality 문제가 발생합니다. 고유한 조합이 많아지면 비용이 증가하고 조회 속도가 느려지기 때문입니다. 자료는 특히 요청 ID나 사용자 ID, 또는 준고유 값을 메트릭에 넣지 말라고 경고합니다. 이러한 세부 정보는 로그나 트레이스에 더 적합합니다.
각 신호는 서로 다른 질문에 답한다
로그는 일반적으로 그래프에 저장되지 않는 로컬 컨텍스트를 추가합니다. 로그가 구조화되어 있고 시간, 심각도, 서비스 이름, 네임스페이스, 컨테이너 ID, 요청 경로, 트레이스 컨텍스트와 같은 일관된 필드를 사용하면 특정 이벤트를 생성한 서비스나 작업과 연결하기가 쉬워집니다. 메트릭은 결제 서비스가 영향을 받았음을 나타낼 수 있지만, 로그는 시간 초과, 예외 또는 종속성 실패를 드러낼 수 있습니다.
분산 트레이스는 또 다른 질문에 답합니다. 하나의 요청이 시스템을 어떻게 이동했으며 시간이 어디에서 소비되었는가? Kubernetes에서 장애는 여러 서비스, 재시도, 큐 한도 또는 데이터베이스 호출에 분산될 수 있기 때문에 분산 트레이스의 중요성이 두드러집니다. 트레이스 컨텍스트를 전달하면 서로 다른 구간을 하나의 요청 컨텍스트로 연결할 수 있으며, 공통 시맨틱 규칙은 메트릭·로그·트레이스 간 필드와 속성 이름을 통일하는 데 도움이 됩니다.
이 자료는 프로파일링도 전체 그림에 포함합니다. 메트릭이 느린 서비스를 식별하고, 트레이스가 영향을 받은 요청 경로를 지정하며, 로그가 로컬 이벤트를 설명한 후에는 profiling 데이터가 CPU나 메모리를 소비하는 함수 또는 코드 경로를 식별하는 데 도움이 될 수 있습니다.
사고 중 실제로 무엇이 달라지는가?
이 자료는 새로운 배포 이후 checkout 서비스가 지연 시간 목표를 초과하기 시작하지만 CPU와 메모리 지표는 정상적으로 유지되는 사례를 제시합니다. 메트릭이 문제의 존재를 드러낸 다음, 느린 요청의 트레이스는 대부분의 지연이 결제 승인 단계에서 발생한다는 것을 보여줍니다. 이어서 로그에는 동일한 요청 컨텍스트와 연결된 반복적인 시간 초과 메시지가 나타납니다.
이 순서는 팀을 “결제 서비스가 왜 느려졌는가?”라는 일반적인 질문에서 종속성 변경을 되돌리거나, 재시도 증폭을 줄이거나, 조사 중에 트래픽을 일시적으로 전환하는 등 보다 구체적인 운영 선택지로 이동시킵니다. 또한 자료는 더 나은 알림이 단순한 인프라 리소스의 원시적인 이상이 아니라 서비스 품질이나 신뢰성 목표에 대한 위험을 반영해야 한다고 강조합니다. 예로 10분 동안 응답 지연 시간의 p99 값이 1초를 초과하면 발생하는 알림을 제시합니다.
적용 가능한 설계 규칙
- 모든 것을 목적 없이 수집하기보다 사용 가능한 메트릭과 로그에서 시작해 점진적으로 범위를 확장합니다.
- 메트릭 내부에서는 지나치게 고유한 레이블보다 서비스 및 워크로드와 관련된 차원을 우선합니다.
- 메트릭·로그·트레이스 간에 일관된 메타데이터 구조를 사용합니다.
- 신호 간 이동을 쉽게 하도록 로그에 요청 ID 또는 트레이스 ID를 추가합니다.
- 리소스 압박만이 아니라 신뢰성 위험과 서비스 품질을 중심으로 알림을 구성합니다.
- 관측 가능성을 배포 후 추가하는 요소가 아니라 애플리케이션과 플랫폼 설계의 일부로 간주합니다.
certi.news의 편집자 해석: 여기서 핵심적인 가치는 특정 도구를 구매하거나 하나의 구현 방식을 채택하라는 권고가 아니라 관측 가능성의 목표를 재정의하는 데 있습니다. 실제로 달라지는 것은 데이터를 사용하는 방식입니다. 메트릭은 이탈을 포착하고, 트레이스는 경로를 지정하며, 로그는 이벤트를 설명하고, 프로파일링은 코드 수준에서 원인을 식별할 수 있습니다. 실무적인 제약도 분명히 남아 있습니다. 더 많은 신호를 수집한다고 해서 더 나은 이해가 보장되는 것은 아니며, 통일된 이름과 필드가 없으면 연결이 취약해질 수 있습니다. 반면 고유한 세부 정보는 메트릭 비용을 높이고 조회 성능을 약화할 수 있습니다. 따라서 효용은 대시보드의 수가 아니라 설계의 품질과 신호 간 연결에 달려 있습니다.