Hikari 최적의 Connection Pool Size를 찾아서!

vuser 200으로 5분간 성능테스트 시 25번의 HikariPool-1 - Connection is not available, request timed out after 30000ms. SQLTransientConnectionException을 마주했습니다.  왜 Exception이 발생하고, 어떻게 해결했는지 알아봅시다.

 

이 글은 아래 목차로 구성되어 있습니다.

 

1. Hikari Connection Pool 동작 방식
2. Hikari CP Connection 획득 과정
3. Hikari CP Connection 반납 과정
4. 문제 원인 분석
5. 문제 해결 방법

 

원인 분석 전에 Hikari Connection pool 획득 및 반환 과정에 대해 알아보겠습니다.

Hikari Connection Pool 동작 방식

위에서 Hikari Connection Pool로부터 connection을 획득하는 방법을 살펴봤습니다. 하지만 어떤 방법으로 connection 수를 유지하는지 살펴보겠습니다.

Hikari Connection Pool이 어떻게 pool을 유지하는지는 Hikari 테스트 코드에서 알 수 있었습니다. 

 

  try (HikariDataSource ds = new HikariDataSource(config)) {
     getUnsealedConfig(ds).setIdleTimeout(3000);

     System.clearProperty("com.zaxxer.hikari.housekeeping.periodMs");

     SECONDS.sleep(1);

     HikariPool pool = getPool(ds);

     assertEquals("Total connections not as expected", 5, pool.getTotalConnections());
     assertEquals("Idle connections not as expected", 5, pool.getIdleConnections());

     try (Connection connection = ds.getConnection()) {
        Assert.assertNotNull(connection);

        MILLISECONDS.sleep(1500);

        assertEquals("Second total connections not as expected", 6, pool.getTotalConnections());
        assertEquals("Second idle connections not as expected", 5, pool.getIdleConnections());
     }

     assertEquals("Idle connections not as expected", 6, pool.getIdleConnections());

     MILLISECONDS.sleep(3000);

     assertEquals("Third total connections not as expected", 5, pool.getTotalConnections());
     assertEquals("Third idle connections not as expected", 5, pool.getIdleConnections());

 

HikariPool이 생성되면 HikariConfig 세팅값을 읽어 TotalConnection수와 IdleConnection 수를 유지합니다.

이후, dataSource로부터 1개의 추가 connection을 얻으며, IN USE 상태로 마킹합니다.

connection이 추가되어도 TotalConnection은 변경되지만, IdleConnection은 바로 증가하지 않습니다. Timeout시간만큼 InUSE상태였다가 Idle 상태로 변경합니다. 또다시 Timeout 시간만큼 체크하다가 더 이상 사용하지 않은 경우 connection을 반납하게 됩니다.

 

HikariConfig에는 Timeout 시간이 30초로 설정되어 있습니다.

private static final long CONNECTION_TIMEOUT = SECONDS.toMillis(30);

Hikari CP Connection 획득 과정

HikariPool.getConnection()을 획득 시 suspendResumeLock을 획득 후 Database와의 커넥션을 획득합니다. connection을 얻어오면 suspendResumeLock을 해제합니다.

 

connection을 얻는 과정은 스레드들이 담겨있는 ConcurrentBag으로부터 connection Wrapper클래스 bagEntry를 얻습니다. 

connectionBag.borrow()는 3단계를 거쳐 사용 가능한(idle) Connection을 빌려오게 됩니다.

 

borrow() 메서드가 호출되면 아래와 같은 순서의 조건식을 거치게 됩니다. 조건식에 해당할 경우 connection 객체를 얻어오게 됩니다.

var poolEntry = connectionBag.borrow(timeout, MILLISECONDS);

1. 요청한 스레드가 threadList(ThreadLocal)에 이미 사용한 connection이 있는지 확인. 이는 ThreadLocal타입이므로 각 스레드별 저장공간을 검사.
2. Hikari Pool 전체 커넥션 풀에 해당하는 sharedList(CopyOnWriteArrayList)에 STATE_NOT_IN_USE상태의 커넥션이 있는지 확인.
3. 빌릴 수 없는 커넥션이 없을 경우 headoffQueue(SynchronouseQueue)에 들어가 대기 -> 이때 경과시간이 설정 시간보다 지난 경우 SQLTransientConnectionException 발생.

 

❓왜 threadList의 요소들을 끝에서부터 검사할까요?

final var list = threadList.get();
for (int i = list.size() - 1; i >= 0; i--) {
   final var entry = list.remove(i);
   @SuppressWarnings("unchecked")
   final T bagEntry = weakThreadLocals ? ((WeakReference<T>) entry).get() : (T) entry;
   if (bagEntry != null && bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) {
      return bagEntry;
   }
}

1. 가장 최근에 사용한 connection을 검사하기 위해서
2. list 탐색 시간을 줄이기 위해서

threadList는 List타입 이므로 remove()를 첫 번째 요소부터 시작한다면 뒤에 요소들을 앞으로 밀어야 하는 O(N) 시간복잡도가 발생합니다. 끝에서부터 체크하면서 시간 복잡도를 O(1)로 줄일 수 있습니다.

 

Hikari CP Connection 반납 과정

1. connection을 획득한 스레드가 commit, exception에 의해 rollback이 되면 스레드는 스레드 풀에 반납되는 과정을 거칩니다.
2. STATE _NOT_IN_USE로 표시되며, handOffQUeue에서 대기 중인 스레드가 있는지 확인 후, 대기상태의 스레드가 존재 시 handOffQueue로 반납합니다. 
3. 대기 중인 스레드가 없다면, threadLocal내의 list value에 현재 connection 정보를 추가합니다.

---

위에서 Hikari Connection Pool이 어떻게 동작하는지 알아본 내용을 토대로, Exception이 발생한 원인을 분석해 보겠습니다.

문제 원인 분석

Connection pool을 다 차지한 상태에서 많은 부하로 발생한 다른 스레드들이 getConnection을 요청하다가, 더 이상 획득할 connection이 없어 마지막 대기 위치인 handOffQueue에서 더 이상 connection을 획득하지 못하고 SQLTransientConnectionException이 발생했던 것입니다.

tomcat 서버가 떠있는 docker 컨테이너 자원 사용량

또한 메모리 자원에 비해 CPU사용량이 100%를 넘는 상황이 발생했습니다. 이는 부하가 발생하는 상황에서 tomcat 스레드 간 HikariPool의 connection을 획득하고자 race condition이 발생했기 때문입니다. 

 

heeverse는 톰캣 스레드 수를 10개 (default)를 사용하고 있습니다. 톰캣 스레드 수가 10개이고, hikari Connection Pool Size도 10개면 충분할 것이라 예상했습니다. 

visual VM으로 확인한 스레드 수

Hikari wiki를 참고하면 하나의 스레드에서 수행하는 다수의 connection에 의해 Pool-Locking이 발생할 수 있다고 합니다. 

"Pool-locking"
The prospect of "pool-locking" has been raised with respect to single actors that acquire many connections.

 

hikari Pool State

 

Exception을 발생시킨 API 수행 시 어떤 트랜잭션이 수행되는지 살펴보겠습니다.

하나의 티켓 예매하기 API를 수행하기 위해서는 두 가지 종류의 트랜잭션이 발생합니다. 

1. 로그인 - 단기 트랜잭션
2. 티켓 예매 - 장기 트랜잭션(하나의 스레드에서 5번의 트랜잭션 발생)
   • JWT토큰 검사
   • ticket order 생성
   • 티켓 예매를 위한 lock
   • 비동기 로그 생성
   • 결과 티켓 조회

장기 트랜잭션 중 티켓 예매를 위한 Lock을 생성 시, Record Lock을 수행하기 위해, 비관적 락을 수행하고 있습니다. 하나의 스레드에 여러 커넥션을 얻는 작업 + Lock수행까지 겹치게 되는 상황이 되었습니다. 

문제 해결 방법

그럼 문제를 어떻게 해결할 수 있을까요? 두 가지 방법으로 문제 해결을 시도해 보았습니다.

 

1. data source 분리를 통한 스레드 경합 감소시키기

For example, systems with a mix of long running transactions and very short transactions are generally the most difficult to tune with any connection pool. In those cases, creating two pool instances can work well
예를 들어, 장기 실행 트랜잭션과 매우 짧은 트랜잭션이 혼합된 시스템은 일반적으로 연결 풀을 조정하기가 가장 어렵습니다. 이러한 경우 두 개의 풀 인스턴스를 만드는 것이 잘 작동할 수 있습니다.

 

장기 트랜잭션에는 ticket, ticket-order테이블에서 작업이 수행됩니다. 둘 중 select for update를 lock으로 인한 병목지점을 발생시키는 ticket과 그 이외 테이블의 datasource를 분리해 봤습니다. 하지만 data source를 분리하는 순간 트랜잭션 공유가 되지 않아 dabasae lock이 공유되지 않았습니다.

 

 

2. 최적의 hikari Pool size 찾기

Hikari wiki에 따르면 Pool-locking을 피하기 위한 최적의 pool size 공식을 제안하고 있습니다.

pool size = Tn x (Cm - 1) + 1

 

Tn :  최대 스레드 수, Cm : 싱글 스레드에서 동시에 수행되는 커넥션 수 

heeverse에서는 tomcat 최대 스레드 수 = 100, 싱글 스레드에서 동시에 수행되는 커넥션 수  = 5를 대입하여 41의 pool size를 설정했습니다.

 

pool size 조정 후 HIkari Pool State

최적의 pool size 설정을 통해 Hikari Connection Pool-locking을 피할 수 있었습니다.

 

이번에는 connection pool size 조정으로 해결했지만, hikari wiki에 따르면 하나의 스레드에서 여러 커넥션을 맺지 않도록 애플리케이션 레벨에서 조정하는 것을 검토하라고 합니다. 애플리케이션 레벨에서 하나의 스레드에서 최소한의 트랜잭션으로 티켓 예매를 할 수 있을지 분석해 봐야겠습니다.

---

[참고]

https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

https://saramin.github.io/2023-04-27-order-error/

https://techblog.woowahan.com/2664/