다음 내용은 Google SRE 문서에서 정의하는 <The Four Golden Signals>를 번역한 것이다.
문서링크: https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals
4개의 골든 시그널
모니터링에서 네 개의 핵심 시그널은 지연(latency), 트래픽(traffic), 에러(errors) 그리고 포화 상태(saturation)이다. 시스템에서 딱 4가지 메트릭만 측정 가능하다면 이 4가지에 집중하라.
Latency
요청을 처리하고 응답하는 데 소요되는 시간을 말한다. 성공적으로 처리된 요청의 지연시간과 처리에 실패한 요청의 지연시간을 분리해 볼 수 있어야 한다. 예를들어, 데이터베이스 커넥션이 끊기거나 다른 치명적인 백엔드 이슈로 인해 발생한 HTTP 500 에러는 매우 빠르게 처리되어 응답이 반환될 수도 있다. 그러나 HTTP 500 에러는 요청 처리가 실패했다는 것을 의미하며, 500 에러들도 전체적인 지연시간 측정에 포함시키는 것은 지연시간의 계산값을 오염시킨다. 한편, 요청 처리가 느린 에러는 빠른 에러보다 더 나쁘다! 그러므로 에러를 단순히 필터링하는 것이 아니라, 에러의 지연을 추적하는 것이 중요하다.
Traffic
고수준의 시스템 특정 메트릭으로, 대해 얼마나 많은 요청이 발생하고 있는지에 대한 측정 지표다. 웹 서비스라면 보통 초당 발생하는 HTTP Request의 숫자를 의미하며, 경우에 따라서는 요청의 특성에 따라서 분류도 가능하다(예를 들어 static인지 dynamic 컨텐츠인지). 오디오 스트리밍 시스템이라면 네트워크 I/O rate나 동시 세션으로 표현될 수 있다. key-value 저장소 시스템이라면 초당 트랜잭션(transaction)이나 read 수로 표현될 수도 있다.
Errors
요청이 명시적으로 실패(HTTP 500) 하거나, 암묵적으로 실패( HTTP 200 성공이 반환되었지만, 잘못된 응답이 반환)했거나, 정책에 의해 실패(예를들어, “1초 내 응답을 약속했다면, 1초 이상 지연은 모두 오류가 된다”)한 비율이다. 프로토콜 응답 코드가 모든 형태의 실패 조건을 설명하긴 어렵기 때문에, 부가적인 (내부적으로 정의한) 프로토콜을 통해 부분 에러 모드를 표현해야 할 수도 있다. 이런 케이스들을 모니터링하는 것은 매우 다른 결과를 가져온다. 로드 밸런서에서 HTTP 500을 잡는 것은 완전히 실패한 요청을 감지하는 데 좋지만 잘못된 컨텐츠(응답)을 내려주고 있는지 여부를 확인하려면 end-to-end 테스트에 의존해야만 한다.
Saturation
서비스가 얼마나 포화상태인지에 대한 정보다. 시스템의 사용률에 대한 지표로, 가장 제약이 많은 리소스(예를 들어, 메모리 제약이 큰 시스템이라면 메모리를, I/O 제약이 큰 시스템이라면 I/O를)를 중점적으로 모니터링한다.
복잡한 시스템에서 포화 상태는 보다 고수준의 부하 지표로 보완해 측정할 수 있다. 당신의 서비스가 두 배의 트래픽도 정상적으로 처리 가능한가? 딱 10%만 더 처리 가능한가? 혹은 현재 처리 가능한 트래픽보다 작은 트래픽만 처리 가능한가? 매우 간단한 서비스라서 파라미터에 따라 요청 처리의 복잡도가 올라가지 않고 설정이 변경되지 않는 경우(예를 들어 “잠시만 기다려 주세요”, “Global하게 고유한 단순 정수를 달라”), static 값을 이용한 부하 테스트로도 충분할 수 있다. 그러나 위에서 설명한 것처럼 대부분의 서비스는 CPU 사용률이나 네트워크 대역폭 같은 상한선이 정해진 간접적인 시그널을 참고해야 한다. 지연 증가는 종종 포화 상태임을 나타내는 핵심 지표가 되기도 한다. p99 응답 시간을 짧은 시간 단위로 측정하는 것을 통해 포화 상태를 일찍 포착할 수 있다.
마지막으로, 포화 상태는 “당신의 데이터베이스가 4시간 안에 하드디스크가 꽉 찰 것 같다”와 같이 곧 포화상태에 다다를 것을 예측하는 것에도 관계가 있다.
결론
만약 당신이 네개의 골든 시그널 모두를 측정하고 있고, 한 시그널에서 문제가 발생했을 때(혹은 문제가 발생하기 직전까지 포화상태가 올라갔을 때), 사람에게 경고를 해줄 수 있다면, 당신의 서비스는 최소한 어느정도는 모니터링에 의해 보장된다고 할 수 있다.