Worker를 늘려도 지연시간이 줄지 않았던 원인
워커가 느린 것이 아니라 다른 곳이 막혀 있었다
Worker를 늘려도 지연시간이 줄지 않았던 원인
많은 사람들이 “처리 속도가 느리다 = 워커가 부족하다”라고 생각합니다. 하지만 실제로는 워커가 대기 상태에 있거나, 작업을 처리하는 과정에서 외부 자원을 기다리는 경우가 더 많습니다.
예를 들어 워커가 다음과 같은 작업을 수행한다고 가정해보겠습니다.
- 데이터베이스 조회
- 외부 API 호출
- 파일 저장
- 캐시 조회
- 메시지 전송
이 과정 중 하나라도 느려지면 워커는 대부분의 시간을 기다리는 데 사용하게 됩니다.
워커를 10개에서 50개로 늘려도 데이터베이스가 초당 처리할 수 있는 요청 수가 그대로라면 병목은 여전히 데이터베이스에 남아 있게 됩니다.
결국 처리량은 거의 증가하지 않고 지연시간만 유지되거나 오히려 악화됩니다.
Queue 적체가 이미 발생한 상태였다
운영 중 자주 발생하는 상황 중 하나는 이미 큐가 과도하게 적체된 이후에 워커를 증설하는 경우입니다.
예를 들어,
- 워커 처리 속도 : 초당 100건
- 유입 속도 : 초당 500건
인 상태가 30분 이상 지속되었다고 가정해보겠습니다.
이미 수십만 건의 작업이 큐에 쌓여 있는 상황에서 워커를 추가하더라도 사용자가 체감하는 지연은 즉시 줄어들지 않습니다.
왜냐하면 신규 요청도 처리해야 하고 기존 적체도 동시에 해소해야 하기 때문입니다.
이 경우 중요한 것은 워커 개수가 아니라 다음과 같은 지표입니다.
- Queue Depth
- Queue Age
- Oldest Message Age
- Consumer Lag
실제 장애 상황에서는 워커 수보다 큐 적체 정도를 먼저 확인하는 것이 훨씬 중요합니다.
데이터베이스가 병목이 된 경우
가장 흔한 원인 중 하나입니다.
워커가 늘어나면 데이터베이스에 전달되는 요청 수도 함께 증가합니다.
처음에는 처리량이 증가하지만 어느 순간부터 데이터베이스가 감당할 수 있는 한계에 도달합니다.
이때 나타나는 현상은 다음과 같습니다.
- 쿼리 대기시간 증가
- Lock 경합 증가
- Connection Pool 고갈
- CPU 사용률 급증
- 디스크 I/O 병목
결국 워커는 일을 하지 못하고 데이터베이스 응답만 기다리게 됩니다.
특히 업데이트가 많은 시스템에서는 워커를 늘릴수록 오히려 성능이 나빠지는 경우도 흔합니다.
외부 API가 처리 속도를 결정하고 있었다
많은 워크플로우 시스템은 내부 작업보다 외부 API 호출 시간이 더 오래 걸립니다.
예를 들어 다음 작업이 있다고 가정해보겠습니다.
- CRM 업데이트
- Slack 알림 전송
- OpenAI API 호출
- 결제 승인 요청
워커는 CPU를 사용하는 시간이 아니라 API 응답을 기다리는 시간이 대부분일 수 있습니다.
외부 API 응답이 평균 2초라면 워커를 늘려도 API 공급자의 처리 속도를 넘어설 수 없습니다.
오히려 너무 많은 워커를 추가하면 상대 서비스의 Rate Limit에 걸리면서 더 큰 문제가 발생할 수 있습니다.
Worker Context Switching 비용 증가
워커 수를 무작정 늘리는 것도 비용이 있습니다.
운영체제는 수많은 프로세스와 스레드를 번갈아 실행해야 합니다.
워커 수가 지나치게 많아지면
- Context Switching 증가
- CPU Cache Miss 증가
- 메모리 사용량 증가
- 스케줄링 오버헤드 증가
등이 발생합니다.
결과적으로 실제 작업 처리보다 시스템 관리 비용이 더 커질 수 있습니다.
그래서 “워커를 많이 띄우는 것”과 “효율적으로 처리하는 것”은 전혀 다른 문제입니다.
메시지 재시도가 병목을 만들고 있었다
실제 운영 환경에서는 실패한 작업이 반복적으로 재시도되면서 시스템을 압박하는 경우도 많습니다.
예를 들어 특정 작업이 실패하면
- 1차 재시도
- 2차 재시도
- 3차 재시도
를 수행하도록 구성되어 있다면,
실패 작업이 많아지는 순간 워커는 정상 작업보다 재시도 작업을 처리하는 데 더 많은 시간을 사용하게 됩니다.
이 경우 워커를 추가해도 실패 메시지가 계속 시스템 자원을 소비하기 때문에 지연시간 개선 효과가 크지 않습니다.
백프레셔가 전파되고 있었다
백프레셔(Backpressure)는 다운스트림 시스템이 처리할 수 없는 상황에서 발생합니다.
예를 들어
API → Queue → Worker → Database
구조가 있다고 가정하면,
데이터베이스가 느려지는 순간 워커 처리 속도가 감소합니다.
워커 처리 속도가 감소하면 큐가 쌓입니다.
큐가 쌓이면 API 응답도 느려집니다.
결국 문제는 데이터베이스 한 곳에서 시작되었지만 전체 시스템으로 전파됩니다.
이 상황에서는 워커 증설보다 병목 구간을 찾아 제거하는 것이 우선입니다.
실제 운영 환경에서 가장 먼저 확인하는 지표
지연시간이 증가했다고 해서 바로 워커를 늘리는 것은 위험합니다.
먼저 다음 지표를 확인해야 합니다.
- Queue Depth
- Queue Age
- Worker Utilization
- Database Latency
- External API Response Time
- Retry Count
- Error Rate
- CPU Usage
- Memory Usage
- Connection Pool 상태
이 지표를 보면 워커 부족인지, 데이터베이스 병목인지, 외부 API 문제인지 빠르게 판단할 수 있습니다.
결론
워커를 늘렸는데도 지연시간이 줄지 않는 이유는 대부분 워커 자체가 병목이 아니기 때문입니다. 실제 운영 환경에서는 데이터베이스, 외부 API, 큐 적체, 재시도 폭증, 백프레셔 전파 등이 더 큰 원인인 경우가 많습니다.
성능 문제를 해결할 때 중요한 것은 무조건 리소스를 추가하는 것이 아니라 어디가 실제 병목인지 정확하게 찾는 것입니다. 워커 수를 늘리는 것은 가장 쉬운 해결책처럼 보이지만, 잘못된 병목을 대상으로 증설하면 비용만 증가하고 사용자 경험은 전혀 개선되지 않을 수 있습니다.
운영 경험이 쌓일수록 깨닫게 되는 사실은 하나입니다. 지연시간 문제는 워커 개수가 아니라 병목 지점을 얼마나 빨리 발견하느냐에 의해 결정된다는 것입니다.
댓글 0
첫 댓글을 남겨보세요.