Backpressure는 왜 한 서비스에서 끝나지 않았을까

Backpressure는 어디서 시작되는가

Backpressure는 왜 한 서비스에서 끝나지 않았을까

Backpressure는 생각보다 단순한 곳에서 시작됩니다.

데이터를 생산하는 속도보다 처리하는 속도가 느려지는 순간입니다.

예를 들어 다음과 같은 구조를 생각해볼 수 있습니다.

사용자 요청 → API 서비스 → Workflow Engine → Queue → Worker → Database

평소에는 각 단계가 균형을 유지하며 동작합니다.

하지만 특정 시점에 Database 응답 속도가 평소보다 느려지기 시작하면 상황이 달라집니다.

Worker는 작업을 완료하지 못하고 대기하게 됩니다.

Worker 처리량이 감소하면 Queue에는 작업이 쌓이기 시작합니다.

Queue 적체가 증가하면 Workflow Engine도 작업 완료를 기다리게 됩니다.

결국 API 서비스의 응답 속도까지 느려집니다.

이 시점부터 Backpressure는 더 이상 특정 서비스의 문제가 아닙니다.

전체 시스템이 영향을 받기 시작합니다.

가장 위험한 것은 대기 상태의 전파다

많은 운영자가 CPU 사용률이나 메모리 사용량만 모니터링합니다.

하지만 실제 장애 상황에서는 자원 고갈보다 대기 상태가 먼저 전파되는 경우가 많습니다.

예를 들어 Worker가 데이터베이스 응답을 기다리는 동안 스레드를 점유합니다.

Workflow Engine은 Worker 완료를 기다립니다.

API 서비스는 Workflow 결과를 기다립니다.

사용자는 API 응답을 기다립니다.

모든 구성 요소가 살아있지만 서로를 기다리고 있는 상태가 만들어집니다.

겉으로 보기에는 서버가 정상입니다.

그러나 실제로는 아무 일도 진행되지 않습니다.

운영자 입장에서는 가장 진단하기 어려운 장애 유형 중 하나입니다.

재시도가 문제를 더 크게 만들 수 있다

장애 당시 가장 많이 발견되는 실수 중 하나가 공격적인 재시도 정책입니다.

예를 들어 외부 API 호출이 실패했다고 가정해보겠습니다.

Worker는 3회 재시도합니다.

Workflow Engine도 재시도합니다.

상위 서비스도 재시도합니다.

사용자 역시 새로고침을 반복합니다.

원래 한 번 처리되어야 할 요청이 수십 번의 요청으로 증폭됩니다.

결국 느려진 시스템에 더 많은 부하를 가하게 됩니다.

실제 장애 분석을 해보면 최초 문제보다 재시도 트래픽이 더 큰 비중을 차지하는 경우도 적지 않습니다.

이 현상을 흔히 Retry Storm이라고 부릅니다.

Queue는 문제를 숨기기도 한다

Queue는 매우 유용한 기술입니다.

하지만 Queue가 있다고 해서 문제가 해결되는 것은 아닙니다.

오히려 장애를 늦게 발견하게 만드는 경우도 있습니다.

초기에는 Queue가 버퍼 역할을 수행합니다.

처리하지 못한 작업들을 계속 저장합니다.

운영자는 서비스가 정상이라고 생각합니다.

하지만 Queue 적체는 계속 증가합니다.

어느 순간 Queue 길이가 임계치를 넘어가면 지연시간이 급격하게 증가하기 시작합니다.

이 시점부터는 Worker를 몇 개 더 추가하는 것만으로 해결되지 않습니다.

이미 수십만 개의 작업이 대기 중일 수도 있기 때문입니다.

Queue는 장애를 막아주는 도구이지만 동시에 장애를 가려주는 도구이기도 합니다.

실제 운영에서 효과적이었던 대응 전략

장애 상황에서 가장 효과적이었던 방법은 무조건 처리량을 늘리는 것이 아니었습니다.

오히려 유입량을 줄이는 것이 더 효과적이었습니다.

1. 불필요한 Workflow 중단

통계 수집

알림 발송

배치 작업

비핵심 기능을 우선 중단했습니다.

핵심 트래픽을 위한 자원을 확보할 수 있었습니다.

2. 재시도 제한

재시도 횟수를 줄였습니다.

특히 즉시 재시도 대신 지수 백오프를 적용했습니다.

시스템이 회복할 시간을 확보할 수 있었습니다.

3. Queue 길이 기반 보호 정책

Queue 길이가 특정 수준을 넘으면 신규 작업을 거부했습니다.

짧은 장애를 허용하더라도 전체 시스템 붕괴를 막는 것이 중요했습니다.

4. 서비스별 격리

모든 Workflow가 동일한 Worker Pool을 사용하지 않도록 분리했습니다.

특정 서비스의 장애가 다른 서비스로 확산되는 것을 줄일 수 있었습니다.

흔한 오해

오해 1. 서버를 늘리면 해결된다

반드시 그렇지는 않습니다.

병목이 데이터베이스나 외부 API라면 Worker를 늘려도 상황은 좋아지지 않습니다.

오히려 더 많은 요청이 병목 지점으로 몰리게 됩니다.

오해 2. Queue가 있으면 안전하다

Queue는 완충 장치일 뿐입니다.

처리 속도 문제가 해결되지 않으면 결국 Queue도 포화됩니다.

오해 3. 재시도는 많을수록 좋다

잘못된 재시도는 장애를 복구하는 것이 아니라 확대합니다.

운영 환경에서 가장 먼저 봐야 하는 지표

Backpressure가 의심될 때 가장 먼저 확인하는 지표는 다음과 같습니다.

• Queue Depth
• Queue Age
• Worker Utilization
• Processing Latency
• Retry Count
• Connection Pool Usage
• Database Response Time

특히 Queue 길이보다 Queue Age를 중요하게 봐야 합니다.

Queue가 1만 건 쌓여 있어도 빠르게 처리된다면 문제가 아닐 수 있습니다.

반대로 Queue가 100건밖에 없어도 대기 시간이 수십 분이라면 심각한 장애의 시작일 수 있습니다.

마무리

Backpressure는 특정 서비스 하나의 문제가 아닙니다.

시스템 전체의 처리 균형이 무너졌다는 신호입니다.

실제 운영 환경에서 위험한 것은 느려진 서비스 자체가 아니라 그 지연이 다른 서비스로 전파되는 과정입니다.

한 번 발생한 Backpressure는 Queue를 거쳐 Workflow Engine으로, Workflow Engine에서 API 서버로, 다시 사용자 요청으로 이어지며 연쇄적인 장애를 만들어냅니다.

안정적인 시스템은 모든 요청을 처리하려고 하지 않습니다. 감당할 수 있는 만큼만 받아들이고, 필요할 때는 과감하게 거절합니다.

Backpressure를 제어하는 능력은 결국 시스템을 오래 살아남게 만드는 능력과 같습니다.