05 · Four Golden Signals로 사용자 영향과 한계 읽기

주문이 느리다는 신고를 받았다면 요청의 지연과 실패부터 확인합니다. CPU 그래프만으로는 사용자가 겪는 지연과 실패를 놓칠 수 있기 때문입니다. 들어오는 요청량과 자원의 여유를 함께 살피면 어느 구간을 조사할지 좁히기 쉬워집니다.

Google SRE Book은 사용자에게 제공하는 서비스에서 지연 시간·트래픽·오류·포화도를 우선해서 살피라고 권합니다. Rob Ewaschuk이 쓰고 Betsy Beyer가 편집한 Monitoring Distributed Systems에서 설명하는 Four Golden Signals입니다. 서비스마다 요청의 종류와 실패의 의미, 먼저 한계에 닿는 자원이 다르므로 각 신호를 나타낼 지표도 서비스에 맞게 골라야 합니다.

게이트웨이에는 요청이 정상적으로 들어오지만 주문 서비스가 데이터베이스 응답을 오래 기다리고, 일부 요청은 시간 초과로 끝나는 가상의 사례를 살펴봅니다. 아래 그림은 사용자에서 게이트웨이와 주문 서비스를 거쳐 데이터베이스로 이어지는 요청 경로를 보여 줍니다.

이 사례에서 지연 시간으로는 성공·실패한 주문 요청이 얼마나 기다렸는지, 트래픽으로는 앞단에서 거절돼 주문 서비스에 도착하지 못한 요청이 있는지 살핍니다. 오류로는 주문 생성이 누락되거나 잘못 처리됐는지, 포화도로는 연결 풀과 데이터베이스에 대기와 용량 압박이 있는지 확인합니다.

오류를 정의하고 성공·실패의 지연을 구분한다

주문 생성 API에서 확인하려는 결과는 주문이 만들어졌는지입니다. HTTP 500은 명시적인 실패입니다. HTTP 200을 반환했어도 주문 결과가 비어 있거나 잘못된 내용을 보여 줬다면 암묵적인 실패에 해당합니다. 약속한 응답 시간을 넘긴 요청을 서비스 정책에 따라 실패로 세는 경우도 있습니다.

오류 신호는 이런 실패가 요청에서 차지하는 비율을 나타냅니다. 상태 코드만으로는 실패 여부를 판단하기 어려울 때가 있습니다. 사용자가 기대한 결과까지 확인하기 어려운 부분은 애플리케이션 계측이나 외부에서 실제 동작을 확인하는 검사로 보완할 수 있습니다.

성공과 실패의 구분은 지연 시간을 읽을 때도 이어집니다. 지연 시간은 요청을 처리하는 데 걸린 시간인데, 백엔드 연결이 끊겨 HTTP 500을 빨리 반환하는 요청이 늘면 전체 평균은 오히려 짧아질 수 있습니다. 이 평균으로는 성공한 주문이 느려졌는지 알기 어렵습니다. Google SRE Book이 성공과 실패의 지연을 나누라고 설명하는 이유입니다.

실패 요청을 측정에서 빼서도 안 됩니다. 실패하기까지 사용자가 오래 기다렸는지는 별도로 살펴야 합니다.

평균만으로는 느린 요청의 분포도 알기 어렵습니다. p95는 관측한 요청의 약 95%가 그 시간 이내에 끝나는 지점으로, 평균이 평소와 비슷해도 일부 요청이 오래 걸리는 상황을 살피는 데 쓰입니다. 앞서 든 가상의 사례에서는 주문 API에서 성공한 요청의 p95도 평소보다 높아졌다고 가정합니다. 느린 요청이 어느 사용자와 기능에 영향을 주는지도 함께 확인합니다.

응답 결과와 지연 조건을 모두 실패 기준으로 삼는다면 집계 기준도 맞춰야 합니다. 잘못된 결과를 반환하면서 시간도 초과한 요청을 중복해서 세지 않도록 정합니다.

요청량과 처리 여유를 함께 읽기

오류 건수가 늘었다면 요청량부터 대조합니다. 요청이 많은 시간에는 실패 건수가 늘어도 실패 비율은 그대로일 수 있습니다. 요청이 적은 시간에는 한 번의 실패가 큰 비율로 보일 수 있습니다. 건수와 비율을 함께 봐야 변화의 크기를 해석하기 쉽습니다.

트래픽은 시스템에 걸리는 수요를 나타냅니다. Google SRE Book은 그 단위를 시스템의 성격에 맞게 고르도록 설명합니다. 웹 API에서는 초당 요청 수가 출발점이 될 수 있고, 스트리밍 서비스에서는 동시 세션 수나 전송량이 더 적절할 수 있습니다. 큐에서 작업을 받아 처리하는 서비스라면 유입된 작업 수와 처리량을 살핍니다.

합계 안에서 요청의 구성이 바뀌기도 합니다. 가벼운 조회와 무거운 주문 처리를 나누어 보면 어느 기능의 부하가 늘었는지 확인하기 쉽습니다. 요청량이 줄었을 때도 원인을 살펴야 합니다. 앞단의 장애로 요청이 도착하지 않으면 뒤쪽 서비스는 한산해 보일 수 있기 때문입니다.

측정한 위치도 맞춰 봅니다. 사용자의 요청 한 번이 여러 내부 호출이나 재시도로 이어질 수 있으므로 서비스별 요청 수를 단순히 더해 사용자 수로 읽어서는 안 됩니다. 요청량을 비교할 때는 위치와 단위, 요청 종류를 함께 확인합니다.

들어오는 수요를 확인했다면 서비스가 이를 감당할 여유를 살핍니다. 포화도는 가장 제약이 큰 자원을 중심으로 서비스가 얼마나 차 있는지 보는 신호입니다. 메모리가 제약이라면 사용 가능한 메모리와 압박을, I/O가 제약이라면 대기와 처리 여력을 확인합니다.

한 자원만으로는 판단하기 어렵습니다. 연결 풀은 이미 차서 요청이 기다리는데 CPU에는 여유가 있을 수 있고, 높은 사용률이 곧 장애를 뜻하지는 않습니다. 자원의 특성과 제한을 대기·오류·사용자 지연에 연결해서 봐야 합니다.

포화도에는 고갈 예측도 포함됩니다. 서비스는 자원이 완전히 소진되기 전부터 느려질 수 있으므로, 현재 사용률뿐 아니라 여유가 줄어드는 추세도 살핍니다. 디스크가 가득 차기 전에 증가 속도를 확인하는 일이 여기에 해당합니다.

연결 풀 대기가 늘었다면 원인을 조사한다

가상의 주문 장애에서 연결 풀 대기가 늘었다면 그 사실은 조사할 단서입니다. 풀 크기를 늘리기 전에 데이터베이스의 처리 시간과 연결 상태, 최근 변경 사항을 함께 조사합니다. 풀이 찬 이유가 느린 쿼리나 데이터베이스의 자원 부족이라면 연결만 늘려서는 해결되지 않을 수 있습니다.

이 조사에서는 시간을 잰 위치가 단서가 됩니다. 게이트웨이에서 측정한 시간에는 뒤쪽 서비스의 응답을 기다린 시간이 들어갑니다. 주문 서비스가 기록한 데이터베이스 호출 시간과 데이터베이스가 직접 기록한 처리 시간을 비교하면 네트워크 구간이나 대기를 조사할 단서를 얻을 수 있습니다. 어느 한 지점의 측정값만으로 정확한 원인을 확정할 수는 없습니다.

사용자가 보는 결과도 따로 확인합니다. 외부에서 주문 절차를 시험하는 블랙박스 모니터링은 현재 나타나는 증상을 확인하고, 내부 메트릭과 로그를 보는 화이트박스 모니터링은 조사할 곳을 좁히는 데 도움을 줍니다. Google SRE Book도 이 관점을 구분해 설명합니다.

외부 검사 한 번의 성공이 모든 사용자의 경험을 대표하지는 않습니다. 내부 지표가 정상 범위여도 외부 경로에 문제가 생길 수 있습니다. 주문이 만들어졌는지 확인하는 검사와 내부의 지연·대기 측정은 서로를 보완합니다.

경보가 울리면 무엇을 할 것인가

네 신호를 수집했다고 네 개의 경보를 똑같이 만들어야 하는 것은 아닙니다. 주문 성공률과 응답 시간은 고객이 겪는 문제를 살피는 데 쓰고, 연결 풀과 디스크의 여유는 원인 조사나 고갈 예측에 씁니다. 서비스에 따라서는 자원 고갈이 임박했다는 사실 자체가 긴급 대응 사유가 되기도 합니다.

01편의 SLO 설명처럼 성공 조건과 기간을 먼저 정하면 오류와 지연을 목표에 비춰 볼 수 있습니다. Google SRE Workbook의 SLO 경보 장은 오류 예산의 소진 속도와 여러 관찰 구간을 함께 활용하는 방법을 설명합니다. 요청이 적은 서비스에서는 한 번의 실패가 비율을 크게 흔들 수 있으므로, 경보를 정할 때 트래픽 특성과 서비스 영향을 함께 고려합니다.

대시보드는 사용자 영향과 대응 필요성을 판단하는 데 도움을 줘야 합니다. 같은 시간대의 요청량, 성공·실패별 지연, 실패 유형, 가장 제약이 큰 자원을 나란히 놓으면 숫자 하나만 볼 때보다 상황을 좁히기 쉽습니다. 어떤 변화가 즉시 담당자를 호출할 사유이고 어떤 변화는 업무 시간에 확인해도 되는지는 사용자 영향과 대응 가능성에 따라 팀이 정합니다. 경보를 받은 사람이 언제 무엇을 해야 하는지 분명해야 합니다.

USE·RED로 이어지는 조사

RED에서 살피던 오류와 지연은 Golden Signals에서도 다룹니다. Golden Signals의 포화도를 조사하다가 USE의 자원별 점검으로 이어갈 수도 있습니다. 세 방법은 서로 다른 질문에서 시작하며 함께 사용할 수 있습니다.

포화도라는 용어의 범위는 구분해서 읽어야 합니다. Brendan Gregg의 USE Method는 자원이 당장 처리하지 못해 대기하는 작업량을 중심으로 봅니다. Google의 네 신호는 가장 제약이 큰 자원을 중심으로 서비스가 얼마나 차 있는지와 고갈 가능성까지 살핍니다. USE 원문과 Google SRE Book이 같은 용어를 쓴다고 해서 두 방식의 지표가 항상 일대일로 대응하는 것은 아닙니다.

대시보드의 이름보다 지금 확인하려는 대상이 먼저입니다. 사용자 영향인지, 서비스의 요청 상태인지, 특정 자원의 병목인지 구분하면 다음에 볼 지표를 고르기 쉬워집니다.

참고 자료

• Monitoring Distributed Systems — Google SRE Book, Chapter 6 — 네 신호와 블랙박스·화이트박스 모니터링
• Monitoring — The Site Reliability Workbook, Chapter 4 — 서비스 모니터링과 계측의 고려 사항
• Alerting on SLOs — The Site Reliability Workbook, Chapter 5 — 오류 예산, 경보 구간, 낮은 트래픽에서의 고려 사항
• The USE Method — Brendan Gregg · The RED Method — Grafana Labs — 자원과 서비스 요청을 살피는 관점