Backpressure를 조기에 발견하기 위해 만든 대시보드

시스템의 병목 현상을 미리 막아주는 백프레셔 대시보드 활용법

Backpressure를 조기에 발견하기 위해 만든 대시보드

시스템 운영을 하다 보면 장애는 갑자기 발생하는 것처럼 보입니다. 하지만 실제로는 대부분의 장애가 몇 분, 몇 시간 전부터 작은 신호를 보내고 있습니다.

제가 운영하던 자동화 플랫폼에서도 비슷한 경험이 있었습니다. 어느 날 특정 워크플로우의 처리 속도가 급격하게 느려졌고, 결국 Queue에 작업이 수만 건 이상 쌓였습니다. 당시 운영팀은 Queue 길이만 보고 있었기 때문에 문제가 발생한 뒤에야 대응할 수 있었습니다.

하지만 장애가 발생한 이후 데이터를 분석해 보니 Queue가 증가하기 훨씬 이전부터 여러 지표들이 경고 신호를 보내고 있었습니다.

• Consumer 처리 속도 감소
• Thread Pool 사용률 증가
• Database Connection Pool 포화
• 외부 API 응답시간 증가
• Retry 작업 증가

문제는 이런 신호들을 한눈에 볼 수 있는 화면이 없었다는 점이었습니다.

그 이후 저는 Queue 길이 자체보다 Backpressure가 발생하는 과정을 보여주는 대시보드를 새롭게 설계하게 되었습니다.

Queue가 늘어났다는 것은 이미 늦었다

많은 운영팀이 Queue 길이를 핵심 지표로 생각합니다.

물론 Queue는 중요합니다.

하지만 Queue는 후행 지표입니다.

Queue가 증가한다는 것은 이미 처리 속도가 유입 속도를 따라가지 못하고 있다는 의미입니다.

예를 들어 초당 1,000건의 작업이 들어오는데 Consumer가 초당 900건만 처리할 수 있다면 Queue는 계속 증가합니다.

이 상황에서 Queue가 눈에 띄게 증가하기 시작했다는 것은 이미 수분 전부터 처리 능력이 부족했다는 뜻입니다.

즉 Queue는 원인이 아니라 결과입니다.

그래서 제가 만든 대시보드의 목표는 Queue를 보여주는 것이 아니라 Queue가 증가하기 시작하는 원인을 보여주는 것이었습니다.

Backpressure는 장애가 아니라 보호장치다

Backpressure라는 단어를 처음 접하면 많은 사람들이 “시스템이 느려지는 현상” 정도로 이해합니다.

하지만 실제로는 조금 다릅니다.

Backpressure는 시스템이 스스로를 보호하기 위한 안전장치입니다.

자동차 엔진이 과열되면 출력을 제한하는 것처럼 시스템도 처리 능력을 초과하는 요청이 들어오면 스스로 속도를 조절하려고 합니다.

대표적인 예가 다음과 같습니다.

• 메시지 소비 속도 제한
• 요청 Rate Limit
• Thread Pool 제한
• Queue Size 제한
• Circuit Breaker 동작

이러한 메커니즘이 없다면 순간적인 트래픽 증가만으로도 시스템 전체가 붕괴될 수 있습니다.

따라서 Backpressure 자체는 나쁜 것이 아닙니다.

문제는 Backpressure가 언제, 왜 발생했는지 모르는 상태입니다.

대시보드에서 가장 먼저 배치한 지표

제가 만든 대시보드에서 가장 위에 배치한 것은 CPU 사용률도 아니고 Queue 길이도 아니었습니다.

첫 번째는 처리량(Throughput)이었습니다.

처리량은 시스템이 실제로 얼마나 많은 작업을 완료하고 있는지를 보여줍니다.

그 아래에는 다음 지표를 배치했습니다.

Processing Throughput

초당 처리 건수

실제 시스템 생산성을 보여줍니다.

Incoming Rate

초당 유입 건수

들어오는 작업량을 의미합니다.

Throughput Gap

유입량과 처리량 차이

이 수치가 커지기 시작하면 Queue 증가가 예상됩니다.

Consumer Lag

Kafka나 메시지 큐를 사용하는 경우 가장 중요한 지표입니다.

Consumer가 Producer를 얼마나 따라가지 못하는지 보여줍니다.

Retry Rate

재시도 비율

외부 API 장애나 일시적 오류를 조기에 발견할 수 있습니다.

실제 장애를 예방했던 사례

한 번은 새 기능을 배포한 직후 Backpressure 대시보드가 경고를 발생시킨 적이 있습니다.

당시 Queue 길이는 정상 범위였습니다.

CPU도 여유가 있었습니다.

메모리 역시 문제없었습니다.

하지만 Throughput Gap 그래프가 점점 벌어지고 있었습니다.

유입량은 초당 1,200건인데 처리량은 1,050건 수준으로 감소하고 있었던 것입니다.

원인을 추적해 보니 신규 기능에서 호출하던 외부 API 응답시간이 평소보다 3배 이상 증가해 있었습니다.

만약 Queue만 보고 있었다면 수십 분 후 실제 장애가 발생했을 것입니다.

하지만 대시보드가 조기에 신호를 보내준 덕분에 사용자가 문제를 인지하기 전에 대응할 수 있었습니다.

이 경험 이후 저는 Queue보다 Throughput Gap을 더 중요하게 보게 되었습니다.

좋은 대시보드의 조건

대시보드는 정보를 많이 보여주는 것이 목적이 아닙니다.

빠르게 판단할 수 있어야 합니다.

제가 현재 사용하는 원칙은 다음과 같습니다.

첫째, 3초 안에 상태를 파악할 수 있어야 한다.

둘째, 원인과 결과를 한 화면에 배치한다.

셋째, 운영자가 무엇을 해야 하는지 즉시 알 수 있어야 한다.

넷째, 과거 동일 시간대 데이터와 비교할 수 있어야 한다.

다섯째, 알림과 연결되어야 한다.

실제로 수십 개의 그래프를 띄워 놓은 대시보드보다 10개의 핵심 지표만 보여주는 대시보드가 훨씬 효과적인 경우가 많습니다.

추천하는 모니터링 구성

Backpressure 조기 감지를 위해 다음 항목은 반드시 모니터링하는 것을 추천합니다.

• Incoming Rate
• Processing Throughput
• Queue Depth
• Consumer Lag
• Retry Rate
• Error Rate
• P95 Response Time
• P99 Response Time
• Database Connection Pool
• Thread Pool Utilization
• External API Latency

특히 Queue Depth와 Consumer Lag을 함께 보면 대부분의 병목 현상을 빠르게 발견할 수 있습니다.

결론

많은 운영팀이 Queue 길이가 증가하면 대응을 시작합니다.

하지만 안정적인 시스템을 운영하는 팀은 Queue가 증가하기 전에 대응합니다.

Backpressure는 갑자기 나타나는 현상이 아닙니다.

처리량 감소, 응답시간 증가, Consumer Lag 확대, Retry 증가 같은 여러 신호가 먼저 나타난 뒤 최종적으로 Queue 증가라는 결과가 발생합니다.

따라서 좋은 대시보드의 목적은 현재 상태를 보여주는 것이 아니라 미래의 장애를 예측하는 것입니다.

제가 만든 Backpressure 대시보드도 같은 목표로 시작되었습니다. Queue를 보기 위해서가 아니라 Queue가 증가할 이유를 가장 먼저 발견하기 위해서 말입니다.