커넥션 풀(Connection Pool)이란

커네션 풀이란 ?

📌

WAS(Web Application Server) 와 데이터베이스 사이의 연결에는 많은 비용이 든다. MySQL 8.0을 기준으로 INSERT 문을 수행할 때 필요한 비용 중 서버가 DB에 연결하기 위한 Connection 비용이 가장 큰 비율을 차지한다. 이처럼 Connection에 많은 비용이 투자되는 것의 보완할 수 있는 방법이 바로 커넥션 풀(Connection Pool)이다.

 

커넥션 풀이란 웹 컨테이너(WAS)가 실행 될 때 DB연결을 위해 미리 일정수의 connection 객체를 만들어 Pool에 담아 뒀다가 사용자(클라이언트)의 요청이 발생하면 Pool에서 생성되어 있는 Connection 객체를 넘겨주고 사용자가 사용이 끝나면 Connection 객체를 다시 Pool에 반환하여 보관하는 기법이다. 다음 내용을 설명하기 전에 WAS 와 Web Server 의 개념을 정리해둔 글이 있으니 참고하면 좋을 것 같다 !

 

Web Server 와 WAS의 차이

 

커넥션 풀의 특징

DataBase Connection Pool 의 약자로 DB와 커넥션을 맺고 있는 객체를 관리하는 역할을 한다. 커넥션 풀의 특징으로는 아래와 같다.

• 웹 컨테이너(WAS)가 실행되면서 connection 객체를 미리 pool에 생성해 둔다.
• HTTP 요청에 따라 pool에서 connection객체를 가져다 쓰고 반환한다.
• 이와 같은 방식으로 물리적인 데이터베이스 connection(연결) 부하를 줄이고 연결 관리 한다.
• pool에 미리 connection이 생성되어 있기 때문에 connection을 생성하는 데 드는 요정 마다 연결 시간이 소비되지 않는다.
• 커넥션을 계속해서 재사용하기 때문에 생성되는 커넥션 수를 제한적으로 설정한다

위에 커넥션 풀 설명에 따르면, 동시 접속 할 경우 pool에서 미리 생성 된 connection을 제공하고 없을 경우는 사용자는 connection이 반환될 때까지 번호순대로 대기상태로 기다린다.

 

여기서 WAS에서 커넥션 풀을 크게 설정하면 메모리 소모가 큰 대신 많은 사용자가 대기시간이 줄어들고, 반대로 커넥션 풀을 적게 설정하면 그 만큼 대기시간이 길어진다.

 

 

커넥션 풀의 동작 과정

1. 사용자가 DB를 사용하기 위해 Connection을 요청한다.

2. Connection Pool에서 사용되지 않고 있는 Connection 객체를 제공한다.

3. 사용자가 Connection 객체를 사용 완료하면 Pool로 반환한다.

 

💡 웹 어플리케이션에서 커넥션 풀을 사용해서 얻는 이점

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

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

 

2. 서버의 한정적인 자원을 효율적으로 사용할수 있다.
두번째로는 서버는 한정정인 자원을 가지고 있는데 요청이 올때마다 무제한의 Connection을 생성하게 된다면 전체 시스템에 성능에 문제가 생길 수 있다. 이러한 문제를 해결하기 위해 커넥션풀에 미리 정해진 숫자의 Connection을 생성해서 관리한다.

 

Java에서 커넥션 풀 설정

Java에서는 DataSource 인터페이스를 통해 커넥션 풀을 사용한다.
Spring Boot 2 버전의 경우 HikariCP를 기본 커넥션 관리 라이브러리로 가져간다.

 

HikariCP란 ?

HikariCP는 가벼운 용량과 빠른 속도를 가지는 JDBC의 커넥션 풀 프레임워크이다. SpringBoot를 사용해 본 사람이라면 한버 쯤은 이를 들어본 적이 있을 것이다. HikariCP의 동작 원리에 대해 알아보겠다.

Thread가 커넥션을 요청했을 때 유휴 커넥션이 존재한다면 해당 커넥션을 반환해준다.

 

 

만약 유휴 커넥션이 존재하지 않는다면, HandOffQueue를 Polling 하면서 다른 Thread가 커넥션을 반납하기를 기다린다.

다른 Thread가 커넥션 풀에 커넥션을 반납하면 커넥션 풀은 HandOffQueue에 반납된 커넥션을 삽입하고 HandOffQueue를 Polling 하던 Thread는 커넥션을 획득하게 된다.

 

만약 커넥션 풀의 크기가 너무 작다면, 커넥션을 획득하기 위해 대기하고 있는 Thread가 많아지게 될 것이다. 이러한 문제는 커넥션 풀의 크기를 늘려주면 해결할 수 있다. 그렇다면 커넥션 풀의 크기는 어느 정도인 게 좋을까?

 

커넥션 풀의 크기와 성능

커넥션 풀이 크면 클수록 좋을까? 언뜻 생각해보면 커넥션을 많이 가지고 있을수록 유리할 것 같긴 하다.

하지만, Connection을 사용하는 주체인 Thread의 개수보다 커넥션 풀의 크기가 크다면 사용되지 않고 남는 커넥션이 생겨 메모리의 낭비가 발생하게 된다.

 

MySQL의 공식레퍼런스에서는 600여 명의 유저를 대응하는데 15~20개의 커넥션 풀만으로도 충분하다고 언급하고 있다. MySQL은 최대 연결 수를 무제한으로 설정한 뒤 부하 테스트를 진행하면서 최적화된 값을 찾는 것을 추천한다. 

 

우아한 형제들 테크 블로그에서는 다음과 같은 공식을 추천하고 있다.

 

pool size = Tn X (CM - 1) + 1

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

DB와 WAS의 Context Switching 역시 한계가 있기 때문에 Thread Pool의 크기는 Conncetion Pool의 크기를 결정하는데 매우 중요하다.

 

 

 

[참고]

https://programmer93.tistory.com/74

https://code-lab1.tistory.com/209