DB Connection

데이터베이스 연결 구조

 

2Tier : 자바 프로그램이 클라이언트로 직접 db 서버에 접근하여 데이터를 접근하는 구조

 

3Tier : 자바 프로그램과 db 서버 사이에 미들웨어 계층이 존재하는 구조.

미들웨어 계층은 비즈니스 로직 구현, 트랜잭션 처리, 리소스 관리 등을 담당한다.

postgres에서 pgbouncer이 미들웨어에 속한다.

 

JDBC는 Java Database Connectivity의 약어로, 다양한 종류의 RDB에 접속하고 SQL문을 수행할 때 사용되는 표준 SQL 인터페이스 API이다. 

자바 애플리케이션에서 DB에 접근하기 위해선 다음과 같은 구조로 동작한다

Java (WEB) application -> JDBC API -> JDBC Driver -> DB

 

Connection Pool (DBCP)

사용자가 요청할때마다 JDBC 드라이버를 로드하고 연결 객체를 생성하는 것은 비효율적이다.

이를 해결하기 위해 커넥션 풀을 사용한다.

WAS가 실행될 때 일정량의 Connection 객체를 미리 만들어놓고 pool에 저장한다. 

클라 요청이 오면 커넥션 객체를 빌려주고 완료되면 다시 객체를 pool에 반환한다.

 

커넥션 풀의 장점

DB 접속 설정 객체를 미리 만들어 연결하여 메모리 상에 등록해 놓기 때문에 불필요한 작업이 사라지므로 빠르게 db에 접속 할 수 있다.

connection 수를 제한할 수 있어서 과도한 접속으로 인한 서버 자원 고갈 방지가 가능하다.

연결이 끝난 connection을 재사용함으로써 새로 객체를 만드는 비용을 줄일 수 있다.

 

커넥션 풀의 주의사항

동시 접속자가 많을 경우나 너무 많은 DB 접근이 발생할 경우, connection은 한정되어 있기 때문에 

쓸 수 있는 connection이 반납될때까지 기다려야 한다.

이때, 너무 많은 connection을 생성하면 메모리 소모가 크고 성능을 떨어뜨려 적정량의 객체를 생성해 두어야 한다.

 

크기를 무한정 늘리면 좋지 않다. 왜냐하면 connection은 thread와 함께 고려해야 하기 때문이다.

thread pool 크기가 connection pool 크기보다 작으면 남는 connection은 메모리 공간만 차지하게 된다.

 

적절한 Connection Pool 크기 설정

Connection Pool의 크기를 어떻게 설정해야 적절한가에 대해 Hikari CP의 공식 문서에서는 아래의 공식을 제시하고 있다.

1 connections = ((core_count) * 2) + effective_spindle_count

여기서 core_count는 현재 서버에서 사용하는 CPU 개수를 나타내고, effective_spindle_count는 DB 서버가 처리할 수 있는 동시 I/O 요청 수를 나타냅니다. 이 공식에 따르면, CPU 속도가 Disk I/O 보다 월등히 빠르므로, Thread가 Disk 작업에서 블로킹되는 시간에 다른 Thread의 작업을 처리할 수 있는 여유가 생긴다는 점을 반영하고 있다.

 

Connection pool의 종류

1. commons-dbcp: 아파치에서 제공하는 대표적인 connection pool 라이브러리이다.
2. tomcat-jdbc-pool: Tomcat에 내장되어 있으며, Apache Commons DBCP 라이브러리를 기반으로 만들어졌다.
3. HikariCP: 스프링 부트 2.0부터 default JDBC connection pool로 사용되며, zero-overhead의 특징을 가지고 있다