[TroubleShooting] DB socket timeout

Date

2025/12/15

문제 상황

부하 테스트 중 40초 이후부터 응답지언과 socket timeout이 발생했습니다. 특히 Ramp-up 종료 시점(모든 Thread 동시 활성 구간)에 집중적으로 오류가 발생했습니다.

테스트 구성

•

블랙 프라이데이 트래픽 금증 상황 가정

•

1시간 기준 Thread Pool 5000ea 동시 요청 (일일 평균 50,000 트래픽)

•

동시 접속자의 약 2%가 매초 요청을 발생시킨다고 가정

◦

5000 * 0.02 = 100 (TPS)

◦

100 TPS 성능 예상

•

로그인 → 상품 조회 → 주문 시나리오

•

전체 조회의 10%가 주문으로 이어짐을 가정

◦

로그인: 100 * 0.3 = 30 (TPS)

◦

상품 조회: 100 * 0.6 = 60 (TPS)

◦

주문: 100 * 0.1 = 10 (TPS)

•

지프 분포(Zipf Distribution)을 활용한 특정 상품 조회 집중 구현

RDS 인스터스 타입

당시 RDS 인스턴스 타입은 t3.medium이었습니다.

진단 순서

“DB 커넥션 풀”을 원인으로 접근하여

SpringBoot 애플리케이션의 HikariCP 설정 중 maxPoolSize을 조정해봤지만

약간의 변화만 있을 뿐 근본적으로 해결되지 않았습니다.

원인 가정

Socket Timeout의 발생 원인을 크게 두 가지로 잡고, 진행하였습니다.

DB 레벨 병목

비효율적 쿼리(N+1 / 인덱스 미비)로 인한 쿼리 처리 시간 증가

프로젝트 마감 기한까지 하루밖에 남지 않은 상황이라 코드 레벨 리팩토링을 끝까지 밀어붙이기보다는, 먼저 “DB 레벨 병목 여부”를 지표로 빠르게 판별하는 쪽을 선택했습니다.

원인 분석

Pool 문제

왜 maxPoolSize 튜닝이 효과적이지 않았을까?

Pool은 “동시에 잡을 수 있는 커넥션의 수”를 늘려줄 수 있지만, DB가 커넥션을 반환하는 속도를 올려주진 않았습니다.

DB의 성능 저하의 흐름은 다음과 같습니다.

•

쿼리 처리 시간이 늘어남

•

트랜잭션 점유 시간이 길어짐

•

커넥션 반환이 지연됨

•

풀의 active가 고정되고 요청이 대기함

•

결국 timeout으로 이어짐

따라서 Pool을 키워도 조금 완화되는 듯하다가 결국 다시 병목이 발생하는 현상이 반복되었을 것이라고 판단했습니다.

Credit 고갈

•

CPUUtilization: 특정 구간에서 CPU가 90~100%에 유지되는 패턴을 보임

•

CPUCreditUsage: Credit Burst 구간이 보임 (t계열의 인스턴스 타입은 Credit을 사용)

이 패턴은 “Pool”보다는 DB 처리 성능 쪽에 가까웠습니다.

t 계열은 “버스트로 잠깐 버틸 수는 있지만”, 부하가 지속되면 크레딧 소모 → 성능 저하로 이어질 수 있습니다.

또한 크레딧 고갈 시점과 timeout 구간이 일치했습니다.

해결 과정

임시 조치(의도적 검증): RDS 인스턴스 타입을 과하게 향상

“정말 DB의 성능이 원인인가?”를 확실히 규명하기 위해, RDS 인스턴스를 m5g.8large로 의도적으로 크게 올려 검증했습니다.

“너무 큰 사양 아닌가?” 할 수 있으며, 큰 사양이 사실임에도 인과관계를 확정시키기 위한 검증이라고 판단했습니다. 검증 이후에는 사이즈를 줄여 과도한 비용이 발생하지 않도록 했습니다.

결과:

Transaction per Second

•

상품 조회 TPS: 120 TPS 전후

•

Error Rate 1% 미만

개선점

인스턴스의 스펙업을 통해 문제를 해결했지만, 근본적인 해결 방안이라고 생각하지 않습니다. 물론 인스턴스의 스펙을 키워야 하는 상황이 있겠지만, 지금 상황에서 인스턴스 스펙업은 장애를 멈추는 응급 조치였을 뿐일 것입니다.

목표는 큰 DB로 버티기가 아니라, 낮은 스펙에서도 운영 가능한 구조로 바꾸는 것입니다.

따라서 정리한 개선 방향은 다음과 같습니다:

•

캐싱 적용으로 DB 의존도 감소

•

fetch join / N+1 제거

•

DB Replicas 확장 및 부하 분산

•

CQRS 패턴 적용