[Spring Boot] 커넥션 풀(HikariCP) 튜닝: 병목을 뚫고 장애를 예방하는 인프라의 심장

여러분이 인기 아이돌 콘서트 티켓팅 사이트의 백엔드 개발자라고 상상해 봅시다. 밤 8시 정각, 1만 명의 유저가 동시에 '결제하기' 버튼을 누릅니다. 스프링 부트(Spring Boot) 서버는 무사히 요청을 받았지만, 데이터베이스(DB)에 접속하려다 보니 심각한 문제가 발생합니다. 애플리케이션이 DB와 TCP/IP 통신을 맺고 로그인하는 과정은 엄청나게 무겁고 긴 시간이 소요됩니다. 1만 명이 접속할 때마다 매번 이 연결(Connection)을 새로 맺는다면 DB 서버는 10초도 안 돼서 뻗어버릴 것입니다. 이 끔찍한 병목(Bottleneck) 현상을 해결하기 위해 "미리 DB와의 연결(통로) 100개를 맺어놓고, 유저가 올 때마다 빌려주고 다시 반납받는 대여소"를 만들었는데, 이것이 바로 커넥션 풀(Connection Pool)입니다. 그리고 스프링 부트가 전 세계 수많은 풀 중에서 최고로 인정하여 기본(Default)으로 탑재한 전설적인 라이브러리가 바로 HikariCP(히카리CP)입니다.

이번 포스팅에서는 "백엔드 성능 튜닝의 최전선!" HikariCP의 구동 원리와 장애를 막기 위한 황금 튜닝 공식에 대하여 다뤄보겠습니다.

🏎️ 1. HikariCP는 왜 세상에서 가장 빠를까?

과거에는 Tomcat-JDBC, c3p0, Apache DBCP 등 다양한 커넥션 풀이 있었습니다. 하지만 HikariCP가 등장한 이후 모든 벤치마크 테스트에서 다른 풀들을 말 그대로 '압살'해버리며 천하통일을 이루었습니다. (스프링 부트 2.0부터 기본 탑재)

• 극단적인 코드 경량화: 히카리CP의 핵심 코드는 몇 천 줄에 불과할 정도로 가볍습니다. 쓸데없는 오버헤드가 없습니다.
• ConcurrentBag 매커니즘: 멀티 쓰레드 환경에서 여러 쓰레드가 락(Lock)을 걸고 커넥션을 차지하려 싸우는 과정(Context Switching)을 최소화하는 독자적인 알고리즘을 사용합니다.
• 바이트코드 수준의 최적화: 자바 코드가 컴파일된 바이트코드를 극한으로 깎아서 최적화하여 0.001초의 속도라도 더 끌어올렸습니다.

⚙️ 2. 실무 장애를 막는 3대 핵심 튜닝 옵션

히카리CP는 기본값만 써도 훌륭하지만, 대용량 트래픽을 받는 실무 서버라면 application.yml에서 튜닝을 해야 합니다. 가장 중요한 3가지 옵션을 살펴봅시다.

1. maximum-pool-size (최대 풀 크기)
가장 중요한 옵션입니다. 풀에 유지할 커넥션의 최대 개수입니다. 기본값은 10입니다.

spring:
  datasource:
    hikari:
      maximum-pool-size: 50 # 동시에 50개의 트랜잭션 쿼리를 처리할 수 있음

"그럼 크게 1000개 주면 무조건 빠른 거 아니야?" 절대 아닙니다. DB 서버의 CPU 코어 수와 메모리 한계가 있기 때문에, 커넥션이 너무 많으면 서로 CPU를 차지하려 싸우느라 오히려 성능이 수직으로 추락합니다(Thrashing). 실무의 황금 공식은 [DB 서버의 CPU 코어 수 * 2 + 디스크 여유분(보통 1~2)] 언저리에서 성능 테스트(JMeter)를 통해 최적점을 찾는 것입니다.

2. connection-timeout (커넥션 획득 대기 시간)
풀에 있는 50개의 커넥션을 유저들이 전부 빌려가서 텅 비어있을 때, 51번째 유저가 들어오면 기다려야 합니다. 이때 "얼마나 기다리다 포기(Exception)할 것인가?"를 정합니다. 기본값은 30000ms(30초)입니다.

spring:
  datasource:
    hikari:
      connection-timeout: 3000 # 3초 안에 커넥션 못 빌리면 쿨하게 에러 던져라!

실무에서는 30초 대기는 너무 깁니다. 유저가 하얀 화면을 30초나 보고 있게 만들 바엔, 3초 만에 "현재 접속자가 많아 지연되고 있습니다"라는 에러 창을 띄워주는 것이 WAS(스프링) 서버의 쓰레드(Thread) 고갈을 막는 현명한 방법입니다.

3. max-lifetime (커넥션 최대 수명)
커넥션이 풀에 존재할 수 있는 최대 수명입니다. 기본값은 30분(1800000ms)입니다. DB 서버나 방화벽(Firewall)이 오랫동안 통신이 없는 커넥션을 강제로 끊어버리는 경우가 잦습니다. 이를 막기 위해 인프라의 네트워크 타임아웃 시간보다 2~3분 정도 짧게 설정하는 것이 원칙입니다.

🚨 3. 데드락(Deadlock)의 공포: Pool Size 튜닝의 함정

만약 한 번의 API 요청(쓰레드 하나) 안에서 커넥션을 2개 이상 동시에 요구하는 로직이 있다면 치명적인 커넥션 데드락(Deadlock) 장애가 발생할 수 있습니다.

예를 들어 풀 사이즈가 10인데, 쓰레드 10개가 동시에 들어와서 각각 1개씩 커넥션을 물고 안 놔준 채 "로직 처리를 위해 1개 더 줘!"라고 외치면, 풀은 이미 비어있으므로 모든 쓰레드가 영원히 대기 상태에 빠져 서버가 멈춰버립니다. 따라서 풀 사이즈를 정할 때는 단일 로직에서 동시에 요구하는 커넥션 수까지 고려하여 넉넉하게 산정해야 합니다.

🎯 4. 마무리 및 다음 단계

지금까지 느려 터진 데이터베이스 물리적 연결의 병목을 뚫어버리고, 대용량 트래픽 앞에서도 서버가 뻗지 않고 든든하게 버텨주게 하는 스프링 부트 인프라의 척추, HikariCP 커넥션 풀의 동작 원리와 실무 튜닝 공식에 대해 다루어 보았습니다. 이제 여러분의 서버는 효율적인 통로 관리를 통해 수많은 유저를 맞이할 준비가 되었습니다.

하지만, 아무리 커넥션 풀을 빵빵하게 늘려놓아도 근본적인 문제가 남습니다. "쇼핑몰 메인 페이지의 상품 목록"처럼 1초에 1,000명씩 조회하지만 데이터는 하루에 한 번만 바뀌는 데이터를 매번 느린 DB(디스크)까지 가서 조회해 와야 할까요? 이건 엄청난 리소스 낭비입니다. 디스크까지 안 가고 메모리 선에서 요청을 끊어버리는 압도적인 스피드의 기술이 필요합니다. 이어지는 13단계 포스팅에서는 "DB의 부하를 0으로 만들고 응답 속도를 10배 끌어올린다!" 실무 대용량 트래픽 처리의 만병통치약, Spring Boot와 Redis를 활용한 글로벌 캐싱(Caching) 아키텍처 전략에 대해 아주 뼈 때리게 파헤쳐 보겠습니다!