CPU 지표만으론 부족한 잡 큐 최적화, PWQD와 Time Decay 알고리즘으로 해결하다
대규모 B2B 서비스에서 필연적으로 발생하는 스파이크성 벌크 트래픽을 안정적으로 처리하기 위한 기술적 여정을 담고 있습니다. 단순 큐 깊이가 아닌 워커당 부하를 계산하는 새로운 지표를 정의하고, TCP 혼잡 제어 알고리즘에서 영감을 얻은 스케일링 로직을 구축한 사례입니다. 이를 통해 리소스 낭비 없이 대량의 비동기 작업을 효율적으로 처리하는 실무적인 아키텍처 개선 과정을 보여줍니다.
비동기 잡 큐 기반의 처리가 많거나, 일반적인 HPA 지표만으로는 작업 부하를 정밀하게 제어하기 어려운 환경의 백엔드 엔지니어에게 이 아키텍처를 추천합니다.
채널톡의 벌크액션 기능은 수백만 건의 요청을 한꺼번에 처리해야 하며, 이 과정에서 워커 부족으로 인한 잡 큐(Job Queue) 지연과 리소스 고갈 현상이 발생했습니다. 기존의 Pod 단위 수평 확장(HPA)은 CPU 및 메모리 지표 중심이라 실제 작업 처리 지연을 민감하게 반영하지 못하는 한계가 있었습니다.
워커 수 대비 대기 작업 수를 나타내는 PWQD(Per-Worker Queue Depth)를 핵심 메트릭으로 도출하고, 이를 기반으로 한 동적 스케일링 알고리즘을 도입했습니다. 급격한 부하에 대응하기 위해 지수적 증가(Exponential Scale Up)를 적용하고, 불필요한 진동 현상을 방지하기 위해 시간 기반 감쇠(Time Decay) 방식의 보수적 축소 로직을 결합했습니다.
10만 건의 작업을 처리할 때 워커 스케일링 적용 전 25분 소요되던 시간이 적용 후 14분으로 약 44% 단축되는 성과를 거두었습니다. 또한 스파이크 트래픽 발생 시 개발자의 수동 개입 없이도 워커 수가 자동으로 조정되어 운영 안정성이 향상되었습니다.
Trade-off
동적 스케일링 도입으로 처리 속도는 개선되었으나, 단일 큐 공유 구조에서 발생하는 헤드 오브 라인 블로킹(HOL Blocking) 문제는 완벽히 해결되지 않아 후속 조치가 필요합니다. 또한 스케일링 오판을 막기 위해 '지속성' 조건을 추가함에 따라 아주 짧은 순간의 초미세 스파이크에는 반응 속도가 제한적일 수 있습니다.
현재 대기 중인 전체 작업 수를 가용한 워커 수로 나눈 값으로, 각 워커가 실질적으로 부담해야 하는 작업의 밀도를 나타내는 지표입니다.
특정 수치가 감소할 때 즉각적으로 반영하지 않고 시간의 흐름에 따라 점진적으로 줄여나가는 방식입니다.
큐의 맨 앞에 위치한 무거운 작업이 처리가 늦어지면서 뒤에 있는 모든 작업이 불필요하게 대기하게 되는 현상입니다.