요청이 조용히 사라질 때 — 침묵하는 외부 장애를 지난주와 비교해 감지하기
에러 지표 옆에 요청량을 놓다
외부 서비스에 의존하는 기능은 에러 수나 지연 시간만으로 상태를 충분히 설명하기 어렵다. 요청 자체가 줄어들면 에러 수가 함께 늘지 않을 수도 있다. 나는 이런 변화를 알아채기 위해 Datadog에 요청량 급감 알람을 구현하고 운영에 적용했다.
알람의 목적은 평소보다 요청이 크게 줄었을 때 확인할 계기를 만드는 것이었다. 요청량 감소만으로 외부 서비스의 장애를 확정할 수는 없다. 사용자 활동 변화나 내부 기능 문제, 지표 수집 이상도 원인이 될 수 있다. 알람이 울리면 다른 지표와 함께 원인을 조사해야 한다.
기준선: 지난주 같은 요일·시간대
요일과 시간대에 따라 요청량이 달라지는 서비스에서는 고정된 숫자 하나를 임계치로 정하기 어렵다. 낮에 맞춘 기준은 새벽에도 알람을 울릴 수 있고, 새벽에 맞추면 낮의 급감을 놓칠 수 있다. 절대 임계치도 최소 요청량을 지키는 데 쓸 수 있지만, 이 작업에서는 평소와 비교해 얼마나 줄었는지를 기준으로 삼았다.
비교 대상은 지난주 같은 요일·시간대였다. 어제와 비교하면 월요일의 요청량을 일요일과 비교하게 된다. 주중과 주말의 이용 패턴이 다르다면 이 차이가 알람에 섞인다. 한 주 전을 기준으로 잡으면 요일을 맞출 수 있다. 다만 공휴일이나 지난주의 일시적인 급증까지 보정되는 것은 아니다.
Datadog의 이상 탐지(anomaly detection) 모니터도 대안이다. 이 기능은 과거 데이터로 예상 범위를 계산하며, 알고리즘에 따라 계절성을 반영할 수 있다. 한 주 전 값 하나와 비교하는 규칙보다 넓은 이력을 사용한다. 알고리즘과 주기성 설정, 예상 범위를 확인할 수 있으므로 판단 근거가 전부 감춰진 기능으로 볼 수는 없다. Datadog 이상 탐지 문서
나는 수동으로 비교 기준을 정하는 방식을 택했다. “지난주 같은 시간보다 얼마나 줄었는가”라는 질문을 그대로 판정 조건으로 만들 수 있었기 때문이다. 알람이 울렸을 때 이번 주와 지난주의 값을 나란히 확인하기도 쉬웠다. 당시 선택은 운영자가 확인할 기준을 명시하는 데 무게를 둔 결정이었다. 이 경험만으로 이상 탐지보다 성능이 좋다고 평가할 수는 없다.
판정: 두 구간의 합을 비교한다
당시 설계 기록에 남은 방식은 최근 2시간의 요청량 합을 지난주 같은 2시간의 합과 비교하는 것이다. 아래는 계산 의도를 재구성한 의사 코드다. 당시 배포한 모니터의 원본 쿼리나 그대로 실행할 수 있는 Datadog 설정은 아니다.
A = 최근 2시간의 요청량 합
B = 지난주 같은 요일·시간대 2시간의 요청량 합
두 구간의 수집 상태와 비교 범위가 유효하고 B > 0일 때:
비율 = A / B
비율 < 0.6이면 급감 조건 충족
그 외에는 급감 조건 미충족
그 외에는:
비율로 판정하지 않고 기준선·수집 상태 확인
두 구간은 같은 지표와 집계 대상을 사용해야 한다. 가령 이번 주에 집계 대상이 줄었다면 서비스 이용량의 변화가 없어도 비율이 내려갈 수 있다. 시간대도 맞춰야 같은 요일·시간대라는 비교 의도가 유지된다.
또한 구간별 합을 먼저 구한 뒤 나누는 것과 각 시점의 비율을 먼저 구해 합하거나 평균 내는 것은 다르다. Datadog에서도 .as_count() 사용 여부에 따라 모니터의 집계·나눗셈 순서가 달라질 수 있다. 실제 설정에서는 선택한 모니터 유형의 지원 문법과 평가 결과가 이 계산 의도에 맞는지 확인해야 한다. 모니터의 as_count 평가 순서
예시의 < 0.6은 40% 초과 감소를 뜻한다. 지난주 1,000건에서 이번 주 600건이 됐다면 정확히 40% 감소했으므로 이 조건을 충족하지 않는다. 599건이면 충족한다. 40% 감소까지 포함하려면 ≤ 0.6이어야 한다. 당시 임계치를 40%로 조정한 경험과 별개로, 위 예시의 경계는 이렇게 읽어야 한다.
분모가 0이거나 수집 상태가 불명확하면 같은 식으로 판정할 수 없다. 특히 실제 요청이 0건인 것과 지표가 들어오지 않은 것을 구분해야 한다. Datadog의 누락 데이터 처리에는 쿼리에 따라 0으로 평가하거나 이전 상태를 유지하는 등의 선택지가 있다. 이 글의 의사 코드는 확인할 조건을 드러낸 것이며, 당시 누락 데이터 설정을 복원한 것은 아니다. Datadog 누락 데이터 설정
2시간 창은 짧은 변동을 완화하는 대신 급감을 늦게 드러낼 수 있다. 요청이 끊겨도 창 안에는 그 이전의 요청이 남아 있다. 따라서 2시간 창을 쓴다는 사실만으로 한두 시간 안에 반드시 감지한다고 말할 수는 없다. 감소 폭과 지속 시간, 기준선의 모양에 따라 조건을 충족하는 시점이 달라진다.
조정: 공휴일 오탐과 민감도
처음에는 지난주 대비 20% 감소를 임계치로 잡았다. 하지만 공휴일 등을 고려하지 않아 오탐이 잦았다. 지난주에는 평일이었던 요일이 이번 주에는 공휴일이면, 이용량의 자연스러운 감소도 알람 조건에 들어갈 수 있다. 요일을 맞추는 것만으로는 달력의 차이를 다루지 못했다.
나는 감소 임계치를 40%로 올렸다. 더 큰 하락에만 반응하도록 민감도를 낮춘 것이다. 이 조정이 공휴일 효과를 계산해 없애 주지는 않는다. 공휴일의 감소 폭이 새 임계치를 넘으면 여전히 알람이 울릴 수 있다. 공휴일 보정이나 여러 주의 기준선 같은 대안도 있지만, 이 작업에서는 임계치를 조정하는 데까지 적용했다.
그만큼 놓치는 범위도 생긴다. 예를 들어 지난주보다 요청이 30% 줄어든 상태라면 위 비율은 0.7이므로 급감 조건을 충족하지 않는다. 서비스 영향이 크더라도 요청량 감소 폭이 작거나 기준선이 이미 낮다면 이 알람은 반응하지 않을 수 있다. 임계치를 높인 결정을 큰 장애를 반드시 잡는다는 보장으로 해석해서는 안 된다.
결과와 학습
운영에 적용한 뒤 알람이 실제로 울린 경험이 있다. 요청량 비교 알람을 구현·배포하고, 공휴일 오탐을 겪으며 임계치를 조정했다. 오탐 감소율이나 탐지 시간의 정량 기록은 남아 있지 않지만, 평소 대비 요청량 변화를 확인할 수 있는 알람을 운영에 추가했다.
이번 작업에서 얻은 기준은 세 가지다.
- 요청량 감소도 조사할 신호다. 에러 수·지연 시간과 함께 보되, 감소만으로 장애 원인을 확정하지 않는다.
- 지난주 비교는 요일·시간대 패턴을 기준선에 반영하는 간단한 방법이다. 지난주에 장애나 일시적인 급증이 있었다면 그 영향도 이어받으므로 비교 대상 자체를 확인해야 한다.
- 임계치 조정에는 놓치는 변화가 따른다. 20%에서 40%로 올린 선택은 감지 범위를 줄여 오탐에 대응한 것이었다. 다음에 같은 알람을 만든다면 오탐과 누락 사례를 함께 기록해 기준을 조정하겠다.
알람을 운영하면서 필요한 것은 임계치 하나보다 그 조건의 의미를 공유하는 일이었다. 어떤 데이터를 비교하는지, 어디부터 알람을 울리는지, 어떤 상황은 판단할 수 없는지까지 설명할 수 있어야 후속 조사와 조정으로 이어진다.