DataSource 란?
DataSource는 커넥션을 획득하는 방법을 추상화하는 인터페이스이다. 이 인터페이스의 핵심 기능은 커넥션 조회이다. 특히 자바에서는 javax.sql.DataSource라는 인터페이스를 제공해준다.
만약 사용자가 DriverManager를 통해 커넥션을 획득하다가 나중에 HikariCP 커넥션 풀을 이용하려고 하면 커넥션을 획득하는 애플리케이션 코드를 모두 변경해야 한다. 하지만 이 커넥션을 획득하는 방법을 추상화해놓은 DataSource 인터페이스를 이용한다면 해당 인터페이스의 구현체만 갈아 끼우면 된다.
따라서 애플리케이션 로직은 DataSource 인터페이스에만 의존하도록 하면, 사용자는 커넥션을 획득하는 방법을 바꾸더라도 애플리케이션 로직을 변경하지 않아도 된다.
DB Connection Pooling
이러한 DataSource는 DB Connection Pooling 기능을 제공한다. DB Connection Pooling은 커넥션 객체를 미리 만들어 저장해두었다가 요청시 꺼내 쓰는 기능을 뜻한다.
커넥션을 맺고 끊는 과정이 줄어들기 때문에 속도와 성능이 좋아진다. 이러한 커넥션 풀을 관리하고, 커넥션 객체를 풀에서 꺼냈다 반환하는 과정을 DataSource가 담당한다.
Connection Pool
커넥션 비용
WAS(Web Application Server)와 데이터베이스 사이의 연결에는 많은 비용이 든다. MySQL 8.0을 기준으로 INSERT 문을 수행할 때 필요한 비용의 비율은 다음과 같다. 괄호 안의 숫자가 비율을 의미한다.
1. Connecting (3)
2. Sending query to server (2)
3. Parsing query (2)
4. Inserting row (1)
5. Inserting index(1)
6. Closing (1)
즉, 서버가 DB에 연결하기 위한 Connecting 비용이 가장 큰 비율을 차지한다. 이처럼 Connection을 생성하는 작업은 비용이 많이 드는 작업이다. 이를 보완할 수 있는 방법이 바로 Connection Pool이다.
커넥션 풀(Connection Pool)이란?
커넥션 풀은 데이터베이스와 연결된 커넥션을 미리 만들어 놓고 이를 pool로 관리하는 것이다. 즉, 필요할 때마다 커넥션 풀의 커넥션을 이용하고 반환하는 기법이다. 이처럼 미리 만들어 놓은 커넥션을 이용하면 Connection에 필요한 비용을 줄일 수 있다. 따라서 DB에 빠르게 접속할 수 있다.
또한 커넥션 풀을 사용하면 커넥션 수를 제한할 수 있어서 과도한 접속으로 인한 서버 자원 고갈을 방지할 수 있으며 DB 접속 모듈을 공통화해 DB 서버의 환경이 바뀔 경우 유지보수를 쉽게 할 수 있다.
HikariCP란?
HikariCP는 가벼운 용량과 빠른 속도를 가지는 JDBC의 커넥션 풀 프레임워크이다. SpringBoot를 사용해 본 사람이라면 한 번쯤은 이름을 들어본 적이 있을 것이다. SpringBoot는 커넥션 풀 관리를 위해 HikariCP를 사용한다.
이러한 HikariCP의 동작법을 통해 커넥션 풀이 어떻게 동작하는지 알아보자.
[그림 2]와 같이 Thread가 커넥션을 요청했을 때 유휴 커넥션이 존재한다면 해당 커넥션을 반환해준다.
만약 유휴 커넥션이 존재하지 않는다면, HandOffQueue를 Polling 하면서 다른 Thread가 커넥션을 반납하기를 기다린다.
다른 Thread가 커넥션 풀에 커넥션을 반납하면 커넥션 풀은 HandOffQueue에 반납된 커넥션을 삽입하고 HandOffQueue를 Polling 하던 Thread는 커넥션을 획득하게 된다.
만약 커넥션 풀의 크기가 너무 작다면, 커넥션을 획득하기 위해 대기하고 있는 Thread가 많아지게 될 것이다. 이러한 문제는 커넥션 풀의 크기를 늘려주면 해결할 수 있다. 그렇다면 커넥션 풀의 크기는 어느 정도인 게 좋을까?
커넥션 풀의 크기와 성능
커넥션 풀이 크면 클수록 좋을까? 언뜻 생각해보면 커넥션을 많이 가지고 있을수록 유리할 것 같긴 하다.
하지만, Connection을 사용하는 주체인 Thread의 개수보다 커넥션 풀의 크기가 크다면 사용되지 않고 남는 커넥션이 생겨 메모리의 낭비가 발생하게 된다.
MySQL의 공식레퍼런스에서는 600여 명의 유저를 대응하는데 15~20개의 커넥션 풀만으로도 충분하다고 언급하고 있다. MySQL은 최대 연결 수를 무제한으로 설정한 뒤 부하 테스트를 진행하면서 최적화된 값을 찾는 것을 추천한다.
우아한 형제들 테크 블로그에서는 다음과 같은 공식을 추천하고 있다.
- Tn = 전체 Thread의 개수
- Cm = 하나의 Task에서 동시에 필요한 Connection 수
DB와 WAS의 Context Switching 역시 한계가 있기 때문에 Thread Pool의 크기는 Conncetion Pool의 크기를 결정하는데 매우 중요하다.
출처
https://code-lab1.tistory.com/209
'DB' 카테고리의 다른 글
| (필기)Index , B tree, B+ tree (0) | 2023.04.16 |
|---|---|
| Oracle vs MySQL vs MSSQL (0) | 2023.03.10 |
| 데이터베이스 샤딩(Sharding) (0) | 2023.03.01 |
| w3school SQL tutorial (0) | 2023.02.21 |
| [인프런] 시니어 백엔드 개발자가 알려주는 데이터베이스 개론 & SQL (0) | 2023.02.21 |
