[DB] HikariCP 에 대한 내용 정리

⚡ 개요

웹 개발을 하면서 DB는 매우 중요한 요소이다. 데이터에 대해서 저장, 갱신, 관리, 검색등 여러 가지의 작업을 통해서 결과물을 도출하고 있다. 웹 개발을 시작하면서는 DB에 대해서 그냥 조회 잘하고 저장 잘하면 끝이라고 생각했던 때가 있었다. 맞는 말이 될 수도 있지만 웹 개발을 오래 하다 보면 많이 중요하다... 내가 사용하고 있는 DB의 장점, 라이브러리, 속도 향상 등등에 대해서 정리를 하려고 한다. 

 

⚡ HikariCP 란?? 

HikariCP는 Java 언어를 위한 고성능 JDBC (Java Database Connectivity) 커넥션 풀 라이브러리이다.

커넥션 풀은 데이터베이스 연결을 관리하고 재사용하여 애플리케이션의 성능을 향상하는 데 사용이 되고  HikariCP는 빠른 시작 속도, 낮은 메모리 사용량, 높은 확장성과 성능으로 알려져 있다.

HikariCP는 간단하고 사용하기 쉬운 API를 제공하며 다양한 구성 옵션을 통해 애플리케이션에 적합한 성능 조정을 할 수 있도록 해준다. 내가 사용하고 있는 Spring Boot에서는 HikariCP를 기본 커넥션 풀로 사용하도록 구성되어 있다. 따라서 Spring Boot 프로젝트에서 HikariCP를 설정하는 것은 일반적으로 추가적인 구성이 필요하지 않다.

 

✋ 커넥션 풀에 대해서 간단한 설명

커넥션 풀은 커넥션을 미리 만들어 놓고 이를 pool로 관리하는것을 말한다. 필요할 때마다 커넥션 풀의 커넥션을 이용하고 반환하는 방식을 사용한다. 미리 만들어 놓은 커넥션을 이용하면 커넥션에 필요한 비용을 줄일 수 있고 따라서 성능 향상을 하는 데에 도움이 된다. 

 

커넥션 풀 관리가 중요한 이유는 커넥션을 맺는 과정이 복잡하고 컴퓨터의 자원을 많이 사용하기 때문이다.

(보통 DB와 연결할 때 TCP 통신을 하기 때문에 비용이 많이 든다.)

 

⚡ Spring boot HikariCP 설정 방법

옵션에 대해서는 내가 어떤걸 설정해라 하는 것보다 경험하고 필요한 내용들을 넣는 것이 중요하다고 생각한다.

그중에서 내가 사용하고 있는 설정에 대해서 정리 하려고한다. (참조)

-- application.yml
spring:
  datasource:
    hikari:
      jdbc-url: 
      username:
      password:
      driver-class-name: 
      maximum-pool-size: 10
      minimum-idle: 5
      data-source-properties:
        cachePrepStmts:
        prepStmtCacheSize:
        prepStmtCacheSqlLimit:
        useServerPrepStmts:

설정 내용중 모르는 부분이나 다른 설정을 해야 한다면 참조를 한번 보면 좋을 거 같다.

내가 설정해놓은 설정 외에 커넥션 타임아웃, 자동 커밋, 풀 초기화, 모니터링과 로깅 옵션등 다양한 옵션이 있다.

 

⚡ 커넥션 풀의 크기에 대한 설명 ❗

이번에 정리하는 내용중 가장 중요한 내용이라고 생각을 한다.

커넥션 풀 관리를 잘 못하게 되면 Dead lock이 발생할수도 있고, 속도가 매우 느려지는 장애를 맞이 할 수 있다.

 

커넥션 풀의 Maximum pool size 공식

 

Connection Pool Size = (core_count * 2) + effective_spindle_count

 

위의 공식은 일반적으로 디스크 드라이브의 입출력 성능을 추정하기 위해 사용되는 공식이라고 한다. 이 공식은 디스크의 회전 속도와 컴퓨터 시스템의 프로세서 코어 수를 고려해서 계산이 되는데 HikariCP wiki에서는 이 공식대로 Maximum pool size를 설정하면 Dead lock을 피할 수 있다고 한다. (실제 테스트는 못하겠어서 참조 자료로 대체한다.) (참조)

우아한 형제 개발진들은 위의 공식에서 추가적으로 내부의 상황을 고려해서 추가적으로 공식에 대입을 해서 사용하고 있는 것으로 보았다. 공식을 분석하면서 테스트 내용 및 JPA 관련 내용도 존재해서 많은 도움이 되었다.

 

공식에 대한 내용을 설명하자면 

core_count : 시스템의 프로세서 코어 수를 나타낸다. 이는 시스템이 병렬로 작업을 처리할 수 있는 프로세서의 물리적인 코어 수를 의미한다.

TMI
하나의 코어를 가진 CPU가 수백개의 요청을 받았을 때 동시에 처리되는 것처럼 보이지만 실제로는 하나의 코어는 하나의 작업만을 처리할 수 있다. 우리의 눈에 동시에 처리되는것처럼 보이는 것은 time-slicing 기법 때문에 동시에 보이는 것뿐이다. 

effective_spindle_count : spindle은 동시 I/O 요청의 개수를 의미한다. 하드웨어의 갯수라고 생각하면 될 거 같다.

(추가적인 레이드의 구성 방식에 따라서 달라질수도 있다고 한다.)

 

⚡ 생각

위의 기본적인 내용 및 커넥션 풀에 대한 내용 관련해서는 위의 공식을 기준으로 상황에 맞게 추가적인 공식을 더해서 사용하면 될 거 같다고 생각을 한다. 내부적으로도 커넥션 풀의 갯수에 대해서 서버의 성능 및 상황 등을 고려해서 테스트를 진행 및 적용 단계에  있다.