DB 커넥션 풀(Connection Pool)과 Hikari CP

서론

HikariCP는 데이터베이스와 애플리케이션 간의 연결을 관리하는 데 있어, 가장 빠르고 가벼운 Connection Pool 오픈소스 라이브러리 중 하나입니다. 이번 게시글에서는 Connection Pool과 Hikari CP에 대해 한번 정리해 보겠습니다.

 

목차

1. 전통적인 WAS와 DB 연결 방법
2. Connection Pool이란?
3. Connection Pool을 무작정 크게 만들면 성능이 좋아질까?
4. 이상적인 Connection Pool의 크기는 얼마일까?
5. Hikari CP란?

 

전통적인 WAS와 DB 연결 방법

전통적인 WAS와 DB 연결 플로우

일반적으로 웹 애플리케이션은 CRUD와 같은 데이터를 연산 작업을 처리할 때 위 이미지와 같이 DB에 직접 연결하기 위해 매번 드라이버(Driver)를 로드하고 connection 객체를 받아오는 방식으로 이루어집니다.

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;


public class Test {

    public static void main(String[] args) {
    
        String driver = "oracle.jdbc.driver.OracleDriver";
        String url = "jdbc:oracle:thin:@localhost:1521:orcl";
        Connection conn = null;
        Statement statement = null;
        String sql = "";
        
        try {
            Class.forName(driver);
            conn = DriverManager.getConnection(url, "master", "master");
            statement = conn.createStatement();
            sql = "select * from Table";
            statement.execute(sql);
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            try {
                conn.close();
                statement.close();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        
    }
}

위 코드를 보면 조금 더 빠르게 이해가 가능할 것 같습니다. 코드를 보면 sql을 수행하기 위해 드라이버(Driver)를 로드하고 connection 수행하고 있는 것을 확인할 수 있습니다.

지금이야 쿼리가 하나라 크게 문제가 되나 싶지만 매번 모든 요청마다 위 과정을 반복하면 어떨까요?

일반적으로 WAS(Web Application Server)와 데이터베이스와의 연결에는 많은 비용이 듭니다. 공식문서를 보면 MySQL 8.0 버전을 기준으로 INSERT문을 수행하는데 드는 비용의 비율은 다음과 같습니다.

• Connecting: (3)
• Sending query to server: (2)
• Parsing query: (2)
• Inserting row: (1 × size of row)
• Inserting indexes: (1 × number of indexes)
• Closing: (1)

각 괄호의 숫자는 상대적인 비용의 대략적인 비율을 의미하며, 잘 보면 Connecting 즉 서버와 DB가 연결하는데 가장 큰 비용이 드는 것을 확인할 수 있습니다.

비용 중에서도 연결이 가장 비율이 큰 이유 중 하나는 Database는 최초 접속 시 TCP 통신을 하기 때문입니다.(네트워크 레벨이라 간단하게만 설명하겠습니다.)

3-way-handshake 과정

TCP로 통신하는 프로그램들은 데이터를 전송하기 전에 정확한 전송을 보장하기 위해 위 이미지와 같이 3-way-handshake라는 과정을 거칩니다.

4-way-handshake 과정

또한 데이터의 전송이 종료되면 사용한 리소스를 반환하기 위한 4-way-handshake과정도 수행합니다.

모든 과정을 요약하면 아래와 같습니다.

1. 애플리케이션 로직은 DB 드라이버를 통해 커넥션을 조회한다.
2. DB 드라이버는 DB와 TCP/IP 커넥션을 연결한다. 물론 이 과정에서 3-way-handshake 같은 TCP/IP 연결을 위한 네트워크 동작이 발생한다.
3. DB 드라이버는 TCP/IP 커넥션이 연결되면, ID, PW와 기타 부가정보를 DB에 전달한다.
4. DB는 ID, PW를 통해 내부 인증을 완료하고 내부에 DB 세션을 생성한다.
5. DB는 커넥션 생성이 완료되었다는 응답을 보낸다.
6. DB 드라이버는 커넥션 객체를 생성해서 클라이언트에 반환한다.

전통적인 방법은 커넥션을 새로 만드는 과정과 DB는 물론이고 애플리케이션 서버에서도 TCP/IP 커넥션을 새로 생성하기 위한 리소스를 매번 사용해야 하기에 실제 서비스의 응답속도에 영향을 많이 끼치게 됩니다.

따라서 이러한 점을 보완하기 위해 Connection Pool이란 개념이 나왔습니다.

 

Connection Pool이란?

WAS(웹 컨테이너)가 실행될 때 DB연결을 위해 미리 일정수의 connection 객체를 만들어 Pool에 담아 뒀다가 클라이언트의 요청이 발생하면 Pool에서 생성되어 있는 Connection 객체를 넘겨주고 처리가 끝나면 Connection 객체를 다시 Pool에 보관하는 방식을 뜻합니다.

Connection Pool 플로우

즉, 커넥션 풀은 데이터베이스와 연결된 커넥션을 미리 만들어 pool에 보관한 다음 필요할 때마다 커넥션 풀의 커넥션을 이용하고 반환하는 기법입니다. 

Connection 풀을 사용해서 얻을 수 있는 이점은 다음과 같습니다.

1. 서버의 부하를 줄여준다.

Java에서는 DB Connection을 맺는 과정이 부하가 많이 걸리는 작업이라 동시에 많은 사람들이 DB 커넥션을 요구한다면 최악의 경우 서버가 죽어버리는 문제가 발생할 수도 있습니다. 이러한 문제를 해결하기 위해 미리 Connection을 생성하고 재활용하여 서버에 부하를 줄일 수 있습니다.

2. 서버의 한정적인 자원을 효율적으로 사용할 수 있다.

서버는 한정적인 자원을 가지고 있는데 요청이 올 때마다 무제한의 Connection을 생성하게 된다면 전체 시스템에 성능에 문제가 생길 수 있다. 이러한 문제를 해결하기 위해 커넥션풀에 미리 정해진 숫자의 Connection만 생성하도록 제한할 수 있습니다.

그렇다면 여기서 Connection Pool을 무작정 크게 만들면 성능이 좋아질까? 하는 의문이 생길 수 있습니다.

 

Connection Pool을 무작정 크게 만들면 성능이 좋아질까?

결론부터 말하면 무작정 Connection Pool을 늘린다고 성능이 좋아지지는 않습니다.

먼저 WAS와 DB의 연결은 thread가 담당합니다. 그리고 thread 또한 thread pool을 가지고 있습니다. 만약 Thread Pool의 크기보다 Connection Pool의 크기가 더 크면 메모리상에서 남은 Connection은 작업을 하지 못하고 놀게 되기에, 실직적으로 메모리만 차지하게 됩니다. 따라서 Connection Pool을 크게 하더라도 thead pool의 크기보다 커버리면 놀게 되는 Connection Pool이 많아지기 때문에 자원을 효율적으로 사용하지 못하게 됩니다. 

그렇다고 무작정 thread pool의 크기를 늘린다고 해결되지는 않습니다. thread의 증가는 문맥교환(Context Switching)으로 인한 한계가 존재하고, Connection Pool을 늘려서 많은 Thread를 받았더라도 다양한 원인으로 성능적인 한계가 존재합니다. 

먼저, Disk 경합 측면에서 성능적인 한계가 존재합니다. 데이터베이스는 하드 디스크 하나당 하나의 I/O를 처리하기 때문에 Blocking이 발생하게 됩니다. SSD를 사용하면 일부 병렬 처리가 가능하지만 이 또한 한계가 존재합니다. 즉, 특정 시점부터는 성능적인 증가가 Disk 병목으로 인해 미비해집니다.

다음은 데이터베이스에서도 Context Switiching으로 인한 성능적인 한계가 존재합니다.

Context Switching에 대해 간단히 살펴보면 우리는 멀티 스레드 환경에서 CPU가 수 십, 수 백 개의 Thread를 동시에 실행할 수 있다고 알고 있습니다. 하지만 실제로 CPU 코어는 CPU스케줄링 알고리즘을 통해 동시에 하나의 작업만 처리할 수 있습니다. 빠르게 여러 개의 작업을 context-swithing 하며 동작하기 때문에 ‘동시에’ 동작하는 것처럼 보이는 것뿐입니다. 한 번의 작업이 끝난 다음의 Thread의 작업을 수행하기 위해 context-switching이 일어나며 이 순간 작업에 필요한 Thread의 Stack 영역 데이터를 로드하는 등 추가적인 작업이 필요하기 때문에 오버헤드가 발생하게 됩니다.

[OS] CPU 스케줄링(CPU Scheduling)

CPU 스케줄링에 대해서는 위 포스팅을 참고해 주시면 감사하겠습니다.

Thread Pool과 Connection Pool의 관계

1. thread는 Connection Pool에서 유휴 상태인 DB Connection이 존재하면 사용하고, 생성해야 한다면 생성합니다.
2. 그리고 DB Connection을 이용해서 DB에서 쿼리를 수행한 뒤 결과를 반환합니다.

즉, 정리하면 다음과 같습니다.

• Connection pool에 무조건 많은 Connection들을 생성하게 되면, Connection 자체도 객체이기 때문에 그만큼 메모리를 추가로 사용하게 된다. (성능 저하)
• 반대로 Connetion pool에 Connection 객체가 너무 적으면 많은 유저들이 사용하는 애플리케이션의 경우 사용 중인 Connection이 반납될 때까지 대기해야 하는 시간이 길어지게 된다. (성능 저하)
• 그렇다고 무작정 Thread Pool을 늘려도 Context Switiching으로 인한 한계가 존재한다.

 

이상적인 Connection Pool의 크기는 얼마일까?

그렇다면 과연 가장 이상적인 Connection Pool의 크기는 얼마일까요? 

MySQL의  공식문서

먼저 MySQL의 공식문서에서는 위와 같이 600명의 유저에 대해서 15~20개의 connection pool크기가 적당하다고 언급되어 있습니다. 그리고 그 이상부터는 적절하게 부하 테스트를 진행하며 적당한 값을 직접 찾는 것을 추천하고 있습니다.

우아한향제들 기술블로그

다음으로 우아한형제들의 기술블로그에서는 위와 같은 pool size 공식을 언급하고 있습니다.

• Tn : 전체 Thread 개수
• Cm : 하나의 Task에서 동시에 필요한 Connection 수

위 공식은 HikariCP wiki가 원본 출처이며, 이 공식대로 Maximum pool size를 설정하면 Dead lock을 피할 수 있다고 합니다.

 

Hikari CP란?

그렇다면 이제 Hikari CP는 무엇일까요?

HikariCP는 2012년 처음 개발된, 130kb의 가벼운 용량과 빠른 속도를 가지는 JDBC의 커넥션 풀 오픈소스 라이브러리인 JDBC DataSource의 구현체입니다.

 

DataSource의 위치

대표적인 커넥션 풀 오픈소스로는 common-dbcp2, tomcat-jdbc pool, HikariCP 등이 있으며, Spring Boot 2.0 이전 버전까지는 기본적으로 connection pool을 tomcat-jdbc pool을 사용했지만 2.0 버전 이후부터는 HikariCP를 사용하도록 변경되었습니다.

HikariCP의 상대적 성능

HikariCP의 깃허브에 나와있는 다른 오픈소스와 비교한 HikariCP의 성능입니다. 굉장히 다른 오픈소스보다 빠른 것을 알 수 있습니다.

HikariCP가 다른 CP 라이브러리 보다 빠른 이유는 다음과 같습니다.

1. 적은 메모리 사용량: HikariCP는 매우 적은 메모리를 사용하므로 초기화 및 연결 시간이 짧다.
2. 높은 처리량: HikariCP는 매우 빠르게 연결을 생성하고 반환하기 때문에 처리량이 매우 높다.
3. 작은 코드 베이스: HikariCP는 코드 베이스가 작기 때문에 구성이 간단하고 가볍다.
4. 풍부한 구성 옵션: HikariCP는 다양한 구성 옵션을 제공하여 애플리케이션에 최적화된 커넥션 풀을 생성할 수 있다.
5. 스레드 안전성: HikariCP는 스레드 안전하게 설게되어 있으므로 여러 스레드에서 안전하게 사용할 수 있다.

Spring에서 Hikari에서 자주 사용하는 설정은 다음과 같습니다.

spring: 
    datasource: 
    	hikari: 
            driver-class-name: com.mysql.cj.jdbc.Driver 
            username: {id} 
            password: {password} 
            jdbc-url: jdbc:mysql://{url}:{port}/{db스키마} 
            minimum-idle: 5 
            maximum-pool-size: 10
            idle-timeout: 30000 
            pool-name: DevLogHikariCP 
            max-lifetime: 200000 
            connection-timeout: 30000 
            connection-test-query: /*CONNECTION TEST QUERY*/SELECT NOW() FROM DUAL

각 설정값의 의미는 다음과 같습니다.

• minimum-idle: Connection Pool에 유지 가능한 최소 커넥션 개수
• maximum-pool-size: Connection Pool에 유지 가능한 최대 커넥션 개수
• idle-timeout: Connection이 Poll에서 유휴상태(사용하지 않는 상태)로 남을 수 있는 최대 시간
• pool-name: Connction Pool 이름
• max-lifetime: Connection의 최대 유지 가능 시간
• connection-timeout: Pool에서 Connection을 구할 때 대기시간, 대기시간안에 구하지 못하면 Exception
• connection-test-query: Connection이 잘 되었는지 확인하는 TEST SQL

 

참고

1. https://programmer93.tistory.com/74
2. https://velog.io/@rlacksals96/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-TCPUDP%EC%99%80-3way-handshake
3. https://velog.io/@hyun6ik/%EC%BB%A4%EB%84%A5%EC%85%98-%ED%92%80-%EC%9D%B4%ED%95%B4
4. https://1-7171771.tistory.com/119
5. https://hyuntaeknote.tistory.com/12
6. https://escapefromcoding.tistory.com/712