김영한 님의 스프링 DB 1편 - 데이터 접근 핵심 원리 강의를 보고 작성한 내용입니다.
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-db-1/dashboard
1. 커넥션 풀
1-1. DB 커넥션 획득 과정
-
획득 과정
-
애플리케이션 로직은 DB 드라이버를 통해 커넥션을 조회
-
DB 드라이버는 DB와 TCP/IP 커넥션을 연결, 이 과정에서 3 way handshake 같은 TCP/IP 연결을 위한 네트워크 동작이 발생
-
DB 드라이버는 TCP/IP 커넥션이 연결되면 ID, PW와 기타 부가정보를 DB에 전달
-
DB는 ID, PW를 통해 내부 인증을 완료하고, 내부에 DB 세션을 생성
-
DB는 커넥션 생성이 완료되었다는 응답을 보낸다
-
DB 드라이버는 커넥션 객체를 생성해서 클라이언트에 반환
-
-
단점
-
위의 과정을 거쳐서 커넥션을 새로 만드는 것은 과정도 복잡하고 시간도 많이 소요
-
DB와 어플리케이션 서버에서 TCP/IP 커넥션을 새로 생성하기 위한 리소스를 매번 사용해야한다
-
고객이 어플리케이션을 사용할 때 SQL을 실행하는 시간 + 커넥션을 새로 만드는 시간이 소요돼서 응답 속도가 느려진다
-
- ➡️커넥션을 미리 생성해두고 사용하는 커넥션 풀을 이용해서 문제를 해결
1-2. 커넥션 풀 초기화
-
어플리케이션을 시작하는 시점에 커넥션 풀은 필요한 만큼 커넥션을 미리 확보해서 풀에 보관
-
보통 얼마나 보관할 지는 서비스의 특징과 서버 스펙에 따라 다르지만 기본값은 보통 10개
-
커넥션 풀에 있는 커넥션들은 TCP/IP로 모두 DB와 커넥션이 연결되어 있는 상태이기 때문에 언제든지 바로 DB에 SQL을 전달할 수 있다
1-3. 커넥션 풀 사용
-
어플리케이션 로직에서 DB 드라이버를 통해서 새로운 커넥션을 획득하는 것이 아닌 커넥션 풀에서 이미 연결되어 있는 커넥션을 조회
-
커넥션 풀을 통해 이미 생성되어 있는 커넥션을 객체 참조로 그냥 가져다 쓰기만 하면 된다
-
커넥션 풀에 커넥션을 요청하면 커넥션 풀은 자신이 가지고 있는 커넥션 중에 하나를 반환한다
1-4. 커넥션 반납
-
어플리케이션 로직은 커넥션 풀에서 받은 커넥션을 사용해서 SQL을 DB에 전달하고 그 결과를 받아서 처리한다
-
이렇게 되면 커넥션을 연결하는 시간 없이 SQL 처리 시간만 소요된다
-
커넥션을 모두 사용하고 나면 커넥션을 종료하는 것이 아니라, 다음에 다시 사용할 수 있도록 커넥션을 그대로 커넥션 풀에 반환
-
커넥션을 종료하면 TCP/IP 연결이 끊어지기 때문에 커넥션을 종료하는 것이 아니라 커넥션이 살아있는 상태로 커넥션 풀에 반환해야 한다
1-5. 참고
-
적절한 커넥션 풀 숫자는 서비스의 특징과 애플리케이션 서버 스펙, DB 서버 스펙에 따라 다르기 때문에 성능 테스트를 통해서 정해야 한다
-
커넥션 풀은 개념적으로 단순해서 직접 구현할 수도 있지만, 사용도 편리하고 성능도 뛰어난 오픈소스 커넥션 풀이 많기 때문에 오픈소스를 사용하는 것이 좋다
-
대표적으로 commons-dbcp2 , tomcat-jdbc pool , HikariCP 등이 있다
-
스프링 부트 2.0 부터는 기본 커넥션 풀로
hikariCP를 제공
2. DataSource
2-1. 커넥션 획득 방법의 변경
-
커넥션을 얻는 방법은 DirverManager를 직접 이용하거나 커넥션 풀을 사용하는 등의 여러 방법이 존재
-
DriverManager를 이용하면 신규 커넥션을 생성해서 얻는 방식
-
커넥션 풀을 이용하면 커넥션 풀에서 커넥션을 가져오는 방식
-
BUT> DriverManager를 사용해서 커넥션을 획득하다가 커넥션 풀을 사용하도록 변경하면 커넥션을 획득하기 위핸 어플리케이션의 코드도 함께 변경해야한다
-
➡️커넥션 획득 방법을 추상화하여 문제를 해결
2-2. 커넥션 획득 방법 추상화
public interface DataSource extends CommonDataSource, Wrapper { Connection getConnection() throws SQLException; }
-
자바는
javax.sql.DataSource라는 인터페이스를 제공 -
커넥션을 어떻게 획득할 것인지 ( DriverManager를 이용 or HikariCP를 이용 ) 관계 없이 커넥션을 획득하는 방법을 추상화
-
DataSource는 커넥션을 획득하는 방법을 추상화 하는 인터페이스이며 핵심 기능은 커넥션 조회
-
커넥션 조회를 위해 DataSource에는 Connection을 반환하는 getConnection() 메서드가 존재
-
즉, DBCP2 커넥션 풀, HikariCP 커넥션 풀의 코드를 직접 의존하는 것이 아니라 DataSource 인터페이스에만 의존
2-3. DriverManager와 DriverManagerDataSource
-
DriverManager는DataSource인터페이스를 사용하지 않기 때문에 DriverManager 는 직접 커넥션을 획득해야한다- 그래서 DriverManager 를 사용하다가
DataSource기반의 커넥션 풀을 사용하도록 변경하면 관련 코드를 다 고쳐야 한다
- 그래서 DriverManager 를 사용하다가
-
이런 문제를 해결하기 위해 스프링은
DriverManager도DataSource를 통해서 사용할 수 있도록DriverManagerDataSource라는DataSource를 구현한 클래스를 제공 -
그러므로
DriverManagerDataSource를 통해서DriverManager를 사용하다가 커넥션 풀을 사용하도록 코드를 변경해도 애플리케이션 로직은 변경하지 않아도 된다
3. DataSource - DriverManager
3-1. DriverManager를 통한 커넥션 획득
@Test
void driverManager() throws SQLException {
Connection con1 = DriverManager.getConnection(URL, USERNAME, PASSWORD);
Connection con2 = DriverManager.getConnection(URL, USERNAME, PASSWORD);
}3-2. DriverManagerDataSource를 통한 커넥션 획득
@Test
void dataSourceDriverManager() throws SQLException {
DataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
useDataSource(dataSource);
}
private void useDataSource(DataSource dataSource) throws SQLException {
Connection con1 = dataSource.getConnection();
Connection con2 = dataSource.getConnection();
log.info("connection={}, class={}", con1, con1.getClass());
log.info("connection={}, class={}", con2, con2.getClass());
}-
내부에서 DriverManager를 사용하기 때문에 항상 새로운 커넥션을 획득
-
DataSource 인터페이스를 통해 커넥션을 가지고 온다
-
DriverManagerDataSource는 여러 단계를 거쳐 DataSource를 상속받음
3-3. 비교
-
DriverManager와 DriverManagerDataSource 모두 새롭게 커넥션을 생성해서 획득한다
-
DriverManager는 getConnection()을 통해 커넥션을 획득할 때마다 URL, USERNAME, PASSWORD와 같은 파라미터를 계속 넘겨주어야 한다
-
DriverManagerDataSource는 처음 객체를 생성할 때만 파라미터를 넘겨주고, 커넥션을 획득할 때는
dataSource.getConnection()만 호출 -
➡️DriverManagerDataSource는 설정과 사용을 분리
3-4. 설정과 사용
-
설정 :
DataSource를 만들고 필요한 속성들을 사용해서 URL , USERNAME , PASSWORD 같은 부분을 입력하는 것을 말한다 -
사용 : 설정은 신경쓰지 않고,
DataSource의getConnection()만 호출해서 사용한다 -
즉, 필요한 데이터를
DataSource가 만들어지는 시점에 미리 다 넣어두게 되면,DataSource를 사용하는 곳에서는dataSource.getConnection()만 호출하면 되므로, URL , USERNAME , PASSWORD 같은 속성들에 의존하지 않아도 된다 -
Repository 는
DataSource만 의존하고, 이런 설정에 필요한 속성을 몰라도 된다DataSource만 주입받아서getConnection()만 호출하면 된다
4. DataSource - 커넥션 풀
4-1. 코드
@Test
void dataSourceConnectionPool() throws SQLException, InterruptedException {
HikariDataSource dataSource = new HikariDataSource();
dataSource.setJdbcUrl(URL);
dataSource.setUsername(USERNAME);
dataSource.setPassword(PASSWORD);
dataSource.setMaximumPoolSize(10);
dataSource.setPoolName("MyPool");
useDataSource(dataSource);
Thread.sleep(1000);
}-
스프링에서 JDBC를 사용하면 HikariCP를 사용할 수 있도록 자동으로 라이브러리를 가져온다
-
HikariDataSource는 DataSource 인터페이스를 구현하고 있다
-
커넥션 풀에서 커넥션을 생성하는 작업은 애플리케이션 실행 속도에 영향을 주지 않기 위해 별도의 Thread에서 작동
-
커넥션 풀을 채울 때 별도의 Thread를 사용하는 이유 : 어플리케이션을 실행할 때 커넥션 풀을 채울 때까지 대기하면 어플리케이션 실행 시간이 늦어지기 때문에 별도의 Thread를 사용해서 커넥션 풀을 채워야 어플리케이션 실행 시간에 영향을 주지 않기 때문
4-2. 로그 확인
#커넥션 풀 초기화 정보 출력 HikariConfig - MyPool - configuration: HikariConfig - maximumPoolSize................................10 HikariConfig - poolName................................"MyPool"
HikariConfig: HikariCP 관련 설정을 확인할 수 있다 ( 풀의 이름, 최대 풀 수 등을 확인 )
#커넥션 풀 전용 쓰레드가 커넥션 풀에 커넥션을 10개 채움 [MyPool connection adder] MyPool - Added connection conn0: url=jdbc:h2:..user=SA [MyPool connection adder] MyPool - Added connection conn1: url=jdbc:h2:..user=SA ... [MyPool connection adder] MyPool - Added connection conn9: url=jdbc:h2:..user=SA
MyPool connection adder: 커넥션 풀에 커넥션을 채우는 별도의 Thread
#커넥션 풀에서 커넥션 획득 1 ConnectionTest - connection=HikariProxyConnection@446445803 wrapping conn0: ... #커넥션 풀에서 커넥션 획득 2 ConnectionTest - connection=HikariProxyConnection@832292933 wrapping conn1: ...
-
HikariProxyConnection: Hikari가 커넥션 풀에서 관리하는 커넥션 -
HikariProxyConnection내부에 실제 wrapping conn이라는 JDBC Connection이 들어있다
MyPool - After adding stats (total=10, active=2, idle=8, waiting=0)
-
useDataSource()에서 커넥션을 2개 획득하고 반환하지 않았음 -
그래서 커넥션 풀에 있는 10개의 커넥션 중 2개가 active 상태
-
if> 최대 커넥션은 10개인데 11개의 커넥션을 요청한다면?
-
커넥션을 받지 못한 애가 커넥션을 받을 때까지 기다린다 ➜ waiting=1
-
일정 시간동안 계속 받지 못하면 중단된다 ( 시간 설정 가능 )
-
5. DataSource 적용하기
5-1. DataSource 의존관계 주입
// 변경 전
public class MemberRepositoryV1 {
private Connection getConnection() {
return DBConnectionUtil.getConnection();
}
}// 변경 후
public class MemberRepositoryV1 {
private final DataSource dataSource;
public MemberRepositoryV1(DataSource dataSource) {
this.dataSource = dataSource;
}
private Connection getConnection() throws SQLException {
Connection con = dataSource.getConnection();
log.info("get connection={}, class={}", con, con.getClass());
return con;
}
}-
외부에서 DataSource 를 주입 받아서 사용하기 때문에 직접 만든 DBConnectionUtil 을 사용하지 않아도 된다
-
DataSource 는 표준 인터페이스 이기 때문에 DriverManagerDataSource 에서 HikariDataSource 로 변경되어도 코드를 변경하지 않아도 된다
5-2. close() 변경
// 변경 전
public class MemberRepositoryV1 {
if (rs != null) {
try {
rs.close();
} catch (SQLException e) {
log.info("error", e);
}
}
...
}// 변경 후
public class MemberRepositoryV1 {
JdbcUtils.closeResultSet(rs);
JdbcUtils.closeStatement(stmt);
JdbcUtils.closeConnection(con);
}-
스프링은 JDBC를 편리하게 다룰 수 있는 JdbcUtils 라는 편의 메서드를 제공
-
JdbcUtils를 이용해서 커넥션을 쉽게 닫을 수 있다
5-3. 테스트로 확인
5-3-1. DriverManagerDataSource
class MemberRepositoryV1Test {
MemberRepositoryV1 repository;
@BeforeEach
void beforeEach() {
DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
repository = new MemberRepositoryV1(dataSource);
}
@Test
void crud() throws SQLException {
// 등록, 조회, 수정, 삭제
...
}
}#로그 확인 Creating new JDBC DriverManager Connection to ... get connection=conn0: ... ... Creating new JDBC DriverManager Connection to ... get connection=conn5: ...
-
로그를 보면 쿼리를 수행할 때마다 계속 새로운 커넥션을 맺는 것을 볼 수 있다
-
DriverManagerDataSource를 사용했기 때문에 매번 새로운 커넥션을 획득하게 된다
➜ 속도, 성능 저하
5-3-2. HikariDataSource
class MemberRepositoryV1Test {
MemberRepositoryV1 repository;
@BeforeEach
void beforeEach() {
HikariDataSource dataSource = new HikariDataSource();
dataSource.setJdbcUrl(URL);
dataSource.setUsername(USERNAME);
dataSource.setPassword(PASSWORD);
repository = new MemberRepositoryV1(dataSource);
}
@Test
void crud() throws SQLException {
// 등록, 조회, 수정, 삭제
...
}
}#로그 확인 get connection=HikariProxyConnection@418958713 wrapping conn0: ... get connection=HikariProxyConnection@1865516976 wrapping conn0: ... get connection=HikariProxyConnection@220695851 wrapping conn0: ... get connection=HikariProxyConnection@762074108 wrapping conn0: ... get connection=HikariProxyConnection@873993427 wrapping conn0: ... get connection=HikariProxyConnection@1989132530 wrapping conn0: ...
-
get connection을 보면 모두 동일한 Connection을 획득하는 것을 알 수 있다
-
쿼리를 수행할 때마다 커넥션을 사용하고 쿼리가 끝나면 커넥션을 close()하기 때문에 커넥션이 다시 커넥션 풀로 반환
-
다시 쿼리를 수행할 때 또 커넥션을 가져오는데 혼자 사용하기 때문에 같은 커넥션을 가져오게 된다
-
웹 애플리케이션에 동시에 여러 요청이 들어오면 여러 쓰레드에서 커넥션 풀의 커넥션을 다양하게 가져간다
-
- Hikari가 커넥션 풀에서 커넥션을 반환할 때 HikariProxyConnection이라는 객체를 생성하고 그 안에 실제 커넥션을 wrapping해서 반환하기 때문에 객체 인스턴스가 전부 다른 것을 볼 수 있는데 실제 객체 내부의 커넥션은 동일한 커넥션이다
- MemberRepositoryV1 는 DataSource 인터페이스에만 의존하기 때문에 DriverManagerDataSource 에서 HikariDataSource 로 변경해도 MemberRepositoryV1 의 코드를 변경하지 않아도 된다 ➜ DI + OCP
-
참고> HikariDataSource를 DataSource로 받아버리면 아래 설정이 불가능하기 때문에 HikariDataSource로 선언되어야 한다
- 인터페이스에는 HikariDataSource를 설정하는 setXXX() 메서드가 없기 때문에
