[Spring] 커넥션 풀과 DataSource에 대한 이해

[김영한님의 스프링 DB 1편 - 데이터 접근 핵심 원리를 학습 후 정리한 내용입니다.]

순서

1. 커넥션 풀이란?
2. DataSource이란?
3. DataSource 예제 - DriverManager
4. DataSource 예제 - 커넥션 풀
5. DataSource 실제 적용

 

1. 커넥션 풀이란?

데이터베이스 커넥션을 획득할 때에는 아래 그림과 같이 매우 복잡한 과정을 거친다.

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

이렇게 커넥션을 새로 만드는 것은 과정도 복잡하고, 시간도 많이 소모된다. DB와 애플리케이션 모두 TCP/IP 커넥션을 새로 생성하기 위한 리소스를 매번 사용해야 한다.

진짜 문제는 고객에 애플리케이션을 사용할 때, SQL을 실행하는 시간에 커넥션을 매번 만들고 있으니 응답 속도에 영향이 갈 수 밖에 없다.

이런 문제를 한번에 해결하는 아이디어가 바로 커넥션을 미리 생성해두고 사용하는 커넥션 풀이라는 방법이다. 커넥션 풀은 이름 그대로 커넥션을 관리하는 풀(ex swimming pool)이다.

[커넥션 풀 초기화]

• 애플리케이션을 시작하는 시점에 커넥션 풀은 필요한 만큼 커넥션을 미리 확보하여 풀에 보관한다. 얼마나 보관할 지는 서버의 스펙에 따라 다르지만 기본값은 보통 10개이다.

[커넥션 풀 사용]

• 사용자의 요청이 들어오면, 애플리케이션 로직에서 이제는 DB 드라이버를 통해서 새로운 커넥션을 획득하는 것이 아니라, 이미 생셩되어 있는 커넥션을 가져다 쓰면 된다.

정리하자면 다음과 같다.

• 커넥션 풀은 서버당 최대 커넥션 수를 제한할 수 있다. 따라서 DB에 무한정 연결이 생성되는 것을 막기 때문에 DB를 보호하는 효과도 있다.
• 직접 구현할 수도 있겠지만, 성능이 뛰어난 오픈소스 커넥션 풀이 많기 때문에 이걸 사용하자.
• 최근에는 hikariCP를 주로 사용한다. (레거시 프로젝트가 아닌 이상)

 

2. DataSource란?

커넥션을 생성하는 방법에는 DriverManager를 직접 사용하거나, 커넥션 풀을 사용하는 등 다양한 방법이 존재한다.

그런데 만약 DriverManager를 통해서 커넥션을 획득하다가, HikariCP를 사용하는 방법으로 변경하려면 어떻게 해야할까?이렇게 될 경우 커넥션을 획득하는 애플리케이션 코드도 함께 변경해야 한다. 의존관계가 DriverManger에서 HikariCP로 변경되기 때문이다.

자바에서는 이런 문제를 해결하기 위해 javax.sql.DataSource라는 인터페이스를 제공한다. 아래 그림을 보자. DataSource는 커넥션을 획득하는 방법을 추상화하는 인터페이스이다.

정리하면 다음과 같다.

• 대부분의 커넥션 풀은 DataSource 인터페이스를 이미 구현해 두었다. 따라서 개발자는 DBCP2 커넥션 풀, HikariCP 커넥션 풀의 코드를 직접 의존하는 것이 아니라 DataSource 인터페이스에만 의존하도록 애플리케이션 로직을 작성하면 된다.
• 커넥션 풀 구현 기술을 변경하고 싶으면 해당 구현체로 갈아끼우기만 하면 된다.
• 스프링은 DriverManager도 DataSource를 통해서 사용할 수 있도록 DriverMangerDataSoure라는 DataSource의 구현체를 제공한다.
• 자바는 DataSource를 통해 커넥션을 획득하는 방법을 추상화했다. 이제 애플리케이션 로직은 DataSource 인터페이스에만 의존하면 된다.

 

3. DataSource예제 - DriverManager

[기존의 DriverManager 사용]

@Slf4j
public class ConnectionTest {

    @Test
    void driverManager() throws SQLException {
        Connection con1 = DriverManager.getConnection(URL,USERNAME,PASSWORD);
        Connection con2 = DriverManager.getConnection(URL,USERNAME,PASSWORD);
				log.info("connection={}, class={}", con1, con1.getClass());
				log.info("connection={}, class={}", con2, con2.getClass());
    }

}

 

[DataSource의 구현체 DriverManagerDataSource 사용]

@Slf4j
public class ConnectionTest {

    @Test
    void dataSourceDriverManager() throws SQLException {
        //DriverManagerDataSource - 항상 새로운 커넥션 획득
        DriverManagerDataSource 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());
    }
}

• 기존 코드와 비슷하지만 DriverManagerDataSource 는 DataSource 를 통해서 커넥션을 획득할 수 있다. 참고로 DriverManagerDataSource 는 스프링이 제공하는 코드이다
• 설정과 사용을 분리할 수 있다는 점에서 SRP(단일 책임 원칙)을 만족하는 방법이다.
• 설정 - DataSource 를 만들고 필요한 속성들을 사용해서 URL , USERNAME , PASSWORD 같은 부분을 입력하는 것을 말한다. 이렇게 설정과 관련된 속성들은 한 곳에 있는 것이 향후 변경에 더 유연하게 대처할 수 있다.
• 사용 - 설정은 신경쓰지 않고, DataSource 의 getConnection() 만 호출해서 사용하면 된다.
• 쉽게 이야기해서 리포지토리(Repository)는 DataSource에만 의존하고, 이런 속성을 몰라도 된다.

 

3. DataSource 예제 - 커넥션 풀

[DataSource의 구현체 HikariDataSource 사용]

@Test
void dataSourceConnectionPool() throws SQLException, InterruptedException {
    //커넥션 풀링: HikariProxyConnection(Proxy) -> JdbcConnection(Target)
    HikariDataSource dataSource = new HikariDataSource();
    dataSource.setJdbcUrl(URL);
    dataSource.setUsername(USERNAME);
    dataSource.setPassword(PASSWORD);
    dataSource.setMaximumPoolSize(10);
    dataSource.setPoolName("MyPool");
    useDataSource(dataSource);
    Thread.sleep(1000); //커넥션 풀에서 커넥션 생성 시간 대기
}

• 커넥션 풀 최대 사이즈를 10으로 지정하고, 풀의 이름을 MyPool 이라고 지정했다.
• 커넥션 풀에서 커넥션을 생성하는 작업은 애플리케이션 실행 속도에 영향을 주지 않기 위해 별도의 쓰레드에서 작동한다. 별도의 쓰레드에서 동작하기 때문에 테스트가 먼저 종료되어 버린다. 예제처럼 Thread.sleep 을 통해 대기 시간을 주어야 쓰레드 풀에 커넥션이 생성되는 로그를 확인할 수 있다.

 

🤔결과 분석

1) MyPool connection adder

별도의 쓰레드 사용해서 커넥션 풀에 커넥션을 채우고 있는 것을 확인할 수 있다. 이 쓰레드는 커넥션 풀에 커넥션을 최대 풀 수( 10 )까지 채운다.

그렇다면 왜 별도의 쓰레드를 사용해서 커넥션 풀에 커넥션을 채우는 것일까? 커넥션 풀에 커넥션을 채우는 것은 상대적으로 오래 걸리는 일이다. 애플리케이션을 실행할 때 커넥션 풀을 채울 때 까지 마냥 대기하고 있다면 애플리케이션 실행 시간이 늦어진다. 따라서 이렇게 별도의 쓰레드를 사용해서 커넥션 풀을 채워야 애플리케이션 실행 시간에 영향을 주지 않는다

2) 커넥션 풀에서 커넥션 획득 - MyPool - After adding stats (total=10, active=2, idle=8, waiting=0)

커넥션 풀에서 커넥션을 획득하고 그 결과를 출력했다. 여기서는 커넥션 풀에서 커넥션을 2개 획득하고반환하지는 않았다. 따라서 풀에 있는 10개의 커넥션 중에 2개를 가지고 있는 상태이다. 그래서 마지막 로그를 보면 사용 중인 커넥션 active=2 , 풀에서 대기 상태인 커넥션 idle=8 을 확인할 수 있다.

 

5. DataSource 실제 적용

DataSource를 주입받아 MemberRepository를 새롭게 정의했다.

기존과 달라진 것은, close()메서드에서 직접 커넥션을 닫아주어야 했던 것이 jdbcUtils을 사용해서 간편하게 사용이 가능해졌고, MemberRepository에서 사용하는 dataSource변수를 외부에서 쉽게 주입할 수 있으므로, 커넥션을 획득하는 방법이 변경되더라도 해당 repository코드를 변경하지 않아도 된다.

[MemberRepository]

@Slf4j
@RequiredArgsConstructor
public class MemberRepositoryV1 {

    private final DataSource dataSource;

    //회원 등록, 조회, 수정, 삭제 메서드

    private void close(Connection con, Statement stmt, ResultSet rs) {
        JdbcUtils.closeResultSet(rs);
        JdbcUtils.closeStatement(stmt);
        JdbcUtils.closeConnection(con);
    }

    private Connection getConnection() throws SQLException {
        Connection con = dataSource.getConnection();
				log.info("get connection={}, class={}", con, con.getClass());
        return con;
    }
}

 

[Test]

@Slf4j
class MemberRepositoryV1Test {

    MemberRepositoryV1 repository;

    @BeforeEach
    void beforeEach() throws Exception {
        //기본 DriverManager - 항상 새로운 커넥션 획득
        //DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        //커넥션 풀링: HikariProxyConnection -> JdbcConnection
        HikariDataSource dataSource = new HikariDataSource();
        dataSource.setJdbcUrl(URL);
        dataSource.setUsername(USERNAME);
        dataSource.setPassword(PASSWORD);
        repository = new MemberRepositoryV1(dataSource);
    }

    @Test
    void crud() throws SQLException, InterruptedException {
				log.info("start");
        //save
        Member member = new Member("memberV123", 10000);
        repository.save(member);

        //findById
        Member memberById = repository.findById(member.getMemberId());
				assertThat(memberById).isNotNull();

        //update: money: 10000 -> 20000
        repository.update(member.getMemberId(), 20000);
        Member updatedMember = repository.findById(member.getMemberId());
				assertThat(updatedMember.getMoney()).isEqualTo(20000);

        //delete
        repository.delete(member.getMemberId());
				assertThatThrownBy(() -> repository.findById(member.getMemberId()))
                .isInstanceOf(NoSuchElementException.class);
    }
}

 

🤔결과 분석

1)DriverManagerDataSource 사용 시

• DriverManagerDataSource를 사용하면 conn0~5 번호를 통해서 항상 새로운 커넥션이 생성되어서 사용되는 것을 확인할 수 있다.

 

2) HikariDataSource 사용 시

• 커넥션 풀 사용시 conn0 커넥션이 재사용 된 것을 확인할 수 있다.
• 테스트는 순서대로 실행되기 때문에 커넥션을 사용하고 다시 돌려주는 것을 반복한다. 따라서 conn0 만 사용된다.
• 웹 애플리케이션에 동시에 여러 요청이 들어오면 여러 쓰레드에서 커넥션 풀의 커넥션을 다양하게 가져가는 상황을 확인할 수 있다
• DriverManager → HikariDataSource로 변경해도 MemberRepositoryV1의 코드는 전혀 변경하지 않아도 된다. MemberRepositoryV1은 DataSource인터페이스에만 의존하기 때문이다. 이것이 바로 DataSource를 사용하는 장점이다. (DI + OCP)