분석 대기열이 12배로 부풀었을 때, 4단계로 흘려보낸 기록

발행: 2026-05-09 · 태그: incident-recovery, throttle, queue, scheduling

새벽 — 평소와 흐름이 달랐다

새벽 시간대 분석 대기열이 평소 흐름에서 벗어났다. 평시에는 등록하자마자 분석이 시작되어 대기 항목이 한 자릿수 수준에 머무는데, 그날은 분석 대상이 한꺼번에 대량 등록되면서 대기가 빠르게 쌓였다. 처리량은 그대로인데 입력만 쏠리면 대기 시간은 그만큼 단순 비례로 늘어난다. 지금은 이런 대량 등록 경로 자체를 운영에서 빼두었지만, 그 시점에는 한 차례 부하가 정통으로 들이쳤다.

평시 대기열 깊이

~10건분당 처리량과 비슷한 수준

사건 정점 깊이

~12배평시 대비 정점 비율

회복까지 시간

~36시간단계적 안정화 끝난 시점까지

문제의 본질은 분석 자체가 무거워서가 아니었다. 새로 들어오는 흐름과 이미 밀린 항목이 같은 차선에서 경쟁 하는 구조가 진짜 원인이었다. 그대로 두면 평소처럼 한 건씩 들어오는 자발적 등록자의 분석 결과도 같은 줄 뒤에 서서 함께 늦어진다.

오전 — 줄을 갈라 흐름부터 살렸다

가장 먼저 한 결정은 밀려 있던 항목을 뒤로 미루는 것 이었다. 누적 대기가 깊을 때 가장 큰 위험은 "지연이 지연을 부르는" 패턴이다. 한 번 밀린 항목을 먼저 처리하려고 들면 새로 들어오는 일반 분석이 그 뒤로 다시 쌓이고, 평시 사용자 경험이 더 깊게 무너진다.

이 결정의 대가는 분명했다. 밀린 일부 대상의 결과 갱신은 더 늦어진다. 그래도 그날 오전 새로 등록한 사용자들의 분석은 평소 속도로 마무리되었고, 운영 화면의 대기 시간 분포는 같은 시간대에 두 갈래로 갈라졌다 — 평시 흐름은 평시처럼, 밀린 분은 밀린 분대로.

오후부터 다음날 — 조금씩 흘려보내기

흐름이 나뉘어 살아난 다음에는 쌓여 있던 대기열을 작은 묶음 단위로 천천히 흘려보내는 일 이 남았다. 한꺼번에 다 처리하려고 들면 그 자체가 새로운 정점이 되어 같은 사건이 반복된다. 그래서 분석 처리 주기를 부하에 따라 늦췄다 당겼다 하는 식으로 바꾸고, 한 주기에 흘려보내는 건수에 명확한 상한을 두었다.

같은 시점에 분석 자체의 판정 기준을 조금 느슨하게 풀었다. 정점 부근에서는 회색 지대에 걸친 항목들이 평소보다 더 자주 재분석을 요청하면서 대기열을 다시 끌어올리는 패턴이 보였기 때문이다. 기준을 살짝 풀어두면 재분석 빈도가 떨어져 대기 압력도 함께 내려간다. 측정 정확도와 시스템 흐름을 잠깐 맞바꾼 셈으로, 회복이 끝난 뒤에는 평시 기준으로 되돌렸다.

후속 — 끝난 대상은 자동으로 빠지게

마지막 단계는 끝난 분석 대상을 대기열에서 자동으로 빼는 흐름 이었다. 같은 사건이 또 들이쳐도 처리할 일감의 절대량이 줄어 있으면 정점이 같은 높이까지 올라가지 않는다. 같은 입력에도 더 작게 반응하는 구조로 바꿔둔 것에 의미가 있다.

회복이 끝난 뒤 평시 대기열 깊이는 사건 이전보다도 살짝 더 얕은 자리에 안착했다. 같은 사건이 다시 와도 같은 높이까지 부풀지는 않을 거라 보고 있고, 다음 정점이 왔을 때 어느 단계가 가장 먼저 효과를 냈는지는 그때 다시 측정해 기록해 둘 생각이다.