Connection Pool을 늘려도 장애가 해결되지 않았던 이유
Connection Pool 부족은 대부분 병목의 결과다
Connection Pool을 늘려도 장애가 해결되지 않았던 이유
Connection Pool은 애플리케이션과 데이터베이스 사이의 연결을 관리하는 역할을 합니다.
애플리케이션은 데이터베이스 작업이 필요할 때 Pool에서 Connection을 가져와 사용하고, 작업이 끝나면 다시 반환합니다.
문제는 Connection을 사용하는 시간이 길어질 때 발생합니다.
예를 들어,
- 평소 쿼리 실행 시간 : 20ms
- 장애 시 쿼리 실행 시간 : 2초
가 되었다고 가정해보겠습니다.
같은 Connection 개수를 유지하더라도 Connection 점유 시간이 100배 증가합니다.
결국 Connection이 부족한 것이 아니라 Connection을 오래 붙잡고 있는 것이 문제인 경우가 많습니다.
데이터베이스 자체가 병목이 된 경우
가장 흔한 사례입니다.
운영 중 특정 쿼리가 느려지기 시작하면 Connection 반환 속도도 함께 느려집니다.
이때 발생하는 현상은 다음과 같습니다.
- Active Connection 증가
- Pending Request 증가
- Connection Wait Time 증가
- Timeout 증가
많은 운영자가 이 시점에서 Pool 크기를 늘립니다.
하지만 데이터베이스 CPU가 이미 포화 상태라면 상황은 오히려 악화됩니다.
더 많은 Connection이 동시에 접근하면서
- Lock 경쟁 증가
- Buffer Cache 경쟁 증가
- Disk I/O 증가
가 발생하기 때문입니다.
결국 병목은 그대로인데 트래픽만 더 밀어 넣는 결과가 됩니다.
Queue 적체가 원인이었던 경우
Connection Pool 장애는 종종 Queue 적체에서 시작됩니다.
예를 들어 다음 구조가 있다고 가정해보겠습니다.
API → Queue → Worker → Database
Worker가 처리해야 할 작업이 급증하면 Queue가 길어집니다.
Queue가 길어지면 Worker가 더 많은 작업을 동시에 처리하려고 시도합니다.
이 과정에서 Database Connection 사용량이 급격히 증가합니다.
결국 Connection Pool 부족 현상이 나타나지만 실제 원인은 Queue 적체입니다.
이 경우 Connection Pool을 늘려도 Queue 적체는 계속 증가합니다.
외부 API 지연이 Connection을 점유한 경우
실무에서 자주 발견되는 의외의 원인입니다.
잘못 설계된 코드에서는 Database Connection을 확보한 상태로 외부 API를 호출합니다.
예를 들어
- Connection 획득
- 데이터 조회
- 외부 API 호출
- 응답 대기
- 데이터 저장
- Connection 반환
구조라면,
외부 API 응답 시간이 3초만 되어도 Connection은 3초 동안 점유됩니다.
이때 Pool 크기를 늘려도 문제가 해결되지 않습니다.
근본 원인은 Connection 사용 구간이 지나치게 길기 때문입니다.
Thread Pool 고갈이 먼저 발생한 경우
Connection Pool 문제처럼 보였지만 실제로는 Thread Pool 문제인 경우도 있습니다.
Connection을 기다리는 스레드는 블로킹 상태로 남아 있습니다.
Connection 부족 현상이 길어지면
- Waiting Thread 증가
- Thread Pool 고갈
- Request Queue 증가
가 발생합니다.
결국 사용자 입장에서는 서비스 전체가 느려진 것처럼 보입니다.
하지만 실제 병목은 Connection Pool 이전 단계에 존재할 수 있습니다.
Connection Pool을 늘릴수록 더 느려진 이유
많은 사람들이 이해하기 어려워하는 현상입니다.
보통은 Pool을 늘리면 처리량도 증가할 것이라고 생각합니다.
하지만 데이터베이스가 이미 처리 한계에 도달한 상태라면 이야기가 달라집니다.
예를 들어,
- Pool Size 50
- Database CPU 90%
상태에서 Pool Size를 200으로 늘리면
데이터베이스는 더 많은 요청을 동시에 처리해야 합니다.
그 결과
- Lock Wait 증가
- Context Switching 증가
- CPU Saturation 증가
가 발생합니다.
오히려 평균 응답시간이 더 길어질 수 있습니다.
장애 당시 가장 먼저 확인한 지표
실제 운영 환경에서는 Connection Pool 숫자보다 다음 지표를 먼저 확인합니다.
1. Active Connections
현재 실제 사용 중인 Connection 수
2. Pending Connections
Connection을 기다리는 요청 수
3. Connection Wait Time
Connection 획득까지 걸리는 시간
4. Database Query Latency
쿼리 실행 시간
5. Queue Depth
대기 중인 작업 개수
6. Thread Pool Usage
스레드 사용률
7. External API Latency
외부 서비스 응답 시간
8. Lock Wait Time
데이터베이스 락 대기 시간
이 지표를 함께 봐야 진짜 병목을 찾을 수 있습니다.
실제 효과가 있었던 대응 방법
Connection Pool을 늘리는 것보다 효과가 좋았던 방법은 다음과 같습니다.
- 느린 쿼리 최적화
- 인덱스 추가
- Queue 적체 해소
- Worker 처리량 개선
- API 호출 구간 분리
- 캐시 적용
- 읽기 전용 Replica 활용
- Bulk 처리 적용
대부분의 경우 Pool Size 변경보다 훨씬 큰 효과를 얻을 수 있었습니다.
Connection Pool 문제를 바라보는 올바른 관점
Connection Pool 부족 경고가 발생했다고 해서 무조건 Pool 크기를 늘리는 것은 위험합니다.
실제 장애의 상당수는
- 느린 데이터베이스
- Queue 적체
- Worker 병목
- 외부 API 지연
- Thread Pool 부족
같은 상위 원인 때문에 발생합니다.
Connection Pool은 이러한 문제가 수면 위로 드러나는 지점일 뿐입니다.
마무리
운영 환경에서 Connection Pool 부족 현상은 자주 발생합니다. 하지만 Pool 크기를 늘리는 것은 대부분 증상을 완화하는 임시 처방에 가깝습니다.
진짜 중요한 것은 왜 Connection이 오래 점유되고 있는지, 어디에서 병목이 시작되었는지, Queue와 Worker가 정상적으로 동작하고 있는지를 파악하는 것입니다.
실제 장애 대응 과정에서 가장 큰 차이를 만드는 것은 Connection Pool 숫자가 아니라 병목 지점을 얼마나 빠르게 발견하느냐입니다. 운영 경험이 쌓일수록 알게 되는 사실은 하나입니다.
Connection Pool은 문제의 원인이 아니라, 시스템이 보내는 가장 중요한 경고 신호 중 하나라는 점입니다.
댓글 0
첫 댓글을 남겨보세요.