오토스케일링과 DB 커넥션 고갈 문제
스프링 부트 애플리케이션에서 기본으로 설정된 HikariCP 커넥션 풀 크기는 10개입니다. 오토스케일링을 통해 파드 개수가 증가하면, 각 파드가 단일 데이터베이스에 물리 커넥션을 생성하게 됩니다. 이로 인해 파드 개수에 비례하여 물리 커넥션이 급증하며 커넥션 고갈 현상이 발생할 수 있습니다.
데이터베이스의 커넥션 한계에 도달하면 커넥션 풀 대기 시간이 발생합니다. 이때 30초가량의 대기 시간이 지속되면 톰캣 워커 스레드가 모두 잠기게 됩니다. 결과적으로 헬스체크 실패가 발생하며 클러스터 전체가 연쇄적으로 재시작되는 병목 현상이 나타날 수 있습니다.
기술적 역량의 핵심: 리소스 제어
대규모 트래픽을 다루는 이커머스 및 핀테크 분야의 채용 환경에서는 단순히 오토스케일링을 구축해 본 경험보다, 스케일아웃 과정에서 발생하는 리소스 고갈을 제어할 수 있는 능력이 더 중요하게 평가됩니다. 단순히 파드를 늘려 트래픽을 분산하는 것을 넘어, 그 이면에 숨은 기술적 병목을 방어하고 시스템 안정성을 유지하는 설계 능력이 핵심입니다.
실전 아키텍처 해결 방안
커넥션 고갈을 방지하고 시스템 안정성을 확보하기 위해 다음과 같은 아키텍처 전략을 고려할 수 있습니다.
프록시 계층 도입 RDS Proxy나 PgBouncer와 같은 프록시 계층을 도입하면 물리 커넥션을 일정하게 유지할 수 있습니다. 트랜잭션 단위의 멀티플렉싱을 통해 데이터베이스 커넥션 고갈을 원천적으로 차단하는 것이 가능합니다.
커넥션 풀 최적화 파드 내부의 HikariCP 풀 크기를 관행적인 10개로 유지하지 않고, 데이터베이스 코어 수와 파드 최대 증설치를 고려하여 파드당 3~5개 수준으로 타이트하게 제한하는 것이 효과적입니다.
헬스체크 분리 쿠버네티스의 라이브니스 프로브와 데이터베이스 헬스체크를 분리해야 합니다. 이를 통해 데이터베이스 지연이 발생하더라도 애플리케이션 파드가 강제로 종료되는 상황을 방지할 수 있습니다.