CS/Database

JDBC(Java Database Connectivity), 커넥션 획득 방법

olsohee 2024. 1. 15. 13:52

JDBC

JDBC(Java Database Connectivity)는 자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API이다. 

 

클라이언트가 애플리케이션 서버를 통해 데이터를 저장하거나 조회하면, 서버는 다음 과정을 통해서 데이터베이스를 사용한다.

  1. 커넥션 연결: 주로 TCP/IP를 사용해서 커넥션을 연결한다.
  2. SQL 전달: 애플리케이션 서버는 커넥션을 통해 SQL을 DB에 전달한다.
  3. 결과 응답: DB는 전달된 SQL을 수행하고 그 결과를 응답한다.

그러나 관계형 데이터베이스의 종류는 매우 다양한데, 각각의 데이터베이스마다 커넥션을 연결하는 방법, SQL을 전달하는 방법, 그리고 결과를 응답 받는 방법이 모두 다르다. 따라서 다음 두 가지 문제가 있다.

  1. 데이터베이스를 다른 종류의 데이터베이스로 변경하면(ex, MySQL -> Oracle) 애플리케이션 서버에 개발된 데이터베이스 사용 코드도 변경해야 한다.
  2. 개발자가 각각의 데이터베이스마다 커넥션 연결, SQL 전달, 그리고 그 결과를 응답 받는 방법을 새로 학습해야 한다.

이런 문제를 해결하기 위해 JDBC라는 자바 표준이 등장했다. 자바는 다음과 같은 표준 인터페이스를 정의해두었다. 따라서 개발자는 이 표준 인터페이스를 사용해서 개발하면 된다.

  • java.sql.Connection : 연결
  • java.sql.Statement : SQL 전달
  • java.sql.ResultSet : 결과 응답

JDBC 드라이버

자바가 제공하는 표준 인터페이스는 말 그대로 인터페이스일 뿐, 그 자체로는 동작하지 않는다. 따라서 JDBC 인터페이스를 각각의 DB 회사에서 자신의 DB에 맞도록 구현해서 라이브러리로 제공하는데, 이를 JDBC 드라이버라 한다.

JDBC의 등장으로 다음 2가지 문제가 해결되었다.

  1. 데이터베이스를 다른 종류의 데이터베이스로 변경하면 애플리케이션 서버의 데이터베이스 사용 코드 변경해야 하는 문제 ➡️ 애플리케이션 로직은 JDBC 인터페이스에만 의존하기 때문에 데이터베이스를 다른 종류로 변경하더라도 JDBC 구현 라이브러리만 변경하면 되고, 애플리케이션 서버의 데이터베이스 사용 코드는 변경하지 않아도 된다.
  2. 개발자가 각각의 데이터베이스마다 커넥션 연결, SQL 전달, 그리고 그 결과를 응답 받는 방법을 새로 학습해야 하는 문제 ➡️ JDBC 표준 인터페이스 사용법만 학습하면 된다.
[참고] 표준화의 한계
JDBC의 등장으로 앞서 말한 문제들은 해결됐지만, 여전히 각각의 데이터베이스마다 SQL, 데이터타입 등의 사용법이 다르다(ex, 페이징 쿼리). ANSI SQL이라는 표준이 있기는 하지만 일반적인 부분만 공통화했기 때문에 한계가 있다. 즉 데이터베이스를 변경하면 JDBC와 관련된 코드는 변경하지 않아도 되지만 SQL 작성 코드는 해당 데이터베이스에 맞게 변경해야 한다. 참고로 JPA를 사용하면 이렇게 각각의 데이터베이스마다 다른 SQL을 정의해야 하는 문제도 많은 부분 해결할 수 있다.

JDBC와 최신 데이터 접근 기술

JDBC는 오래된 기술이고 사용 방법도 복잡하다. 따라서 최근에는 JDBC를 직접 사용하기 보다는 JDBC를 편리하게 사용할 수 있는 다양한 기술들이 존재한다. 대표적으로 SQL Mapper와 ORM 기술로 나눌 수 있다.

SQL Mapper

  • SQL 응답 결과를 객체로 편리하게 변환해주고, JDBC의 반복 코드를 제거해준다.
  • 그러나 개발자가 SQL을 직접 작성해야한다.
  • 대표 기술: 스프링 JdbcTemplate, MyBatis

ORM

  • ORM은 객체를 관계형 데이터베이스 테이블과 매핑해주는 기술이다. 이 기술 덕분에 개발자는 반복적인 SQL을 직접 작성하지 않고, ORM 기술이 개발자 대신에 SQL을 동적으로 만들어 실행해준다. 따라서 각각의 데이터베이스마다 다른 SQL을 사용하는 문제도 해결해준다.
  • 대표 기술: JPA, 하이버네이트, 이클립스링크(JPA는 자바 진영의 ORM 표준 인터페이스이고, 이것을 구현한 것으로 하이버네이트와 이클립스 링크 등의 구현 기술이 있다.)

중요한 것은 SQL Mapper이든 ORM 기술이등 모두 내부에서 JDBC를 사용한다는 것이다. 따라서 JDBC를 직접 사용하지 않더라도 JDBC가 어떻게 동작하는지를 알아야 한다. 

커넥션 획득 방법

JDBC DriverManager

JDBC가 제공하는 DriverManager는 라이버러리에 등록된 각 데이터베이스 벤더들의 DB 드라이버를 관리하고, 커넥션을 획득한다. DriverManager가 커넥션을 획득하는 방법은 다음과 같다. 

  1. 애플리케이션 로직에서 커넥션이 필요하면 DriverManager.getConnection()을 호출한다.
  2. DriverManager는 라이브러리에 등록된 드라이버 목록을 자동으로 인식한다. 이 드라이버들에게 순서대로 다음 정보를 넘겨서 커넥션을 획득할 수 있는지 확인한다.
    • URL: ex) jdbc:h2:tcp://localhost/~/test
    • 이름, 비밀번호 등 접속에 필요한 추가 정보
    여기서 각각의 드라이버는 URL 정보를 체크해서 본인이 처리할 수 있는 요청인지 확인한다. 예를 들어 URL이 jdbc:h2 로 시작하면, H2 드라이버는 본인이 처리할 수 있으므로 실제 데이터베이스에 연결해서 커넥션을 획득하고, 이 커넥션을 클라이언트에 반환한다. 반면에 URL이 jdbc:h2 로 시작했는데 MySQL 드라이버가 먼저 실행되면, 이 경우 본인이 처리할 수 없다는 결과를 반환하게 되고, 다음 드라이버에게 순서가 넘어간다.
  3. 이렇게 찾은 커넥션 구현체가 클라이언트에 반환된다. (JDBC는 java.sql.Connection이라는 표준 커넥션 인터페이스를 제공한다. 그리고 각 데이터베이스 드라이버들은 이 Connection 인터페이스를 구현한 구현체를 제공한다.)

예를 들어 MySQL 드라이버가 라이브러리에 등록되어 있다고 가정하면, 우리는 다음과 같이 DriverManager를 통해 MySQL의 커넥션(Connection 인터페이스 구현체)을 획득할 수 있다. 

DriverManager를 통해 획득한 커넥션은 다음과 같이 MySQL 드라이버가 제공하는 ConnectionImpl이다. 그리고 이는 JDBC의 Connection 인터페이스를 구현한다.

커넥션 풀

앞서 살펴본 것과 같이 JDBC의 DriverManager를 통해 커넥션을 획득할 수 있다. 그리고 커넥션을 획득할 때는 다음과 같은 과정이 일어난다.

  1. 애플리케이션 로직에서 커넥션을 획득하려고 하면, DriverManager는 라이브러리에 등록된 드라이버 목록을 살펴 적절한 DB 드라이버를 찾는다.
  2. DB 드라이버는 DB와 TCP/IP 연결을 한다. (이때 3 way handshake와 같이 TCP/IP 연결을 위한 네트워크 동작이 일어난다.)
  3. DB 드라이버와 DB가 연결되면, DB 드라이버는 DB에 IP, PW 등의 정보를 전달한다.
  4. DB는 IP, PW를 통해 내부 인증을 완료하고, 내부에 DB 세션을 생성한다.
  5. DB는 커넥션 생성이 완료되었다는 응답을 보낸다.
  6. DB 드라이버는 커넥션 객체를 생성해서 클라이언트에 반환한다.

이렇게 필요할 때마다 커넥션을 매번 새로 생성하는 것은 과정도 복잡하고 시간도 많이 소요된다. 만약 고객이 애플리케이션을 사용할 때 DB에 접근해야 한다면, SQL을 실행하는 시간뿐만 아니라 커넥션을 새로 생성하는 시간이 추가된다. 따라서 결과적으로 고객에게 나가는 응답 속도가 늦어진다.

 

따라서 커넥션을 미리 생성해두고 사용하는 커넥션 풀이라는 개념이 등장하였다.

  • 애플리케이션 시작 시점에 커넥션 풀은 필요한 만큼 커넥션을 미리 확보해서 커넥션 풀에 보관한다. (커넥션 풀에 보관하는 커넥션의 수는 서비스 특징과 서버 스펙에 따라 다르지만 기본값은 보통 10개이다.)커넥션 풀에 들어 있는 커넥션은 이미 TCP/IP로 DB와 커넥션이 연결되어 있는 상태이기 때문에 언제든지 즉시 SQL을 DB에 전달할 수 있다.

  • 커넥션 풀에 들어 있는 커넥션은 이미 TCP/IP로 DB와 커넥션이 연결된 상태이다.

  • 따라서 애플리케이션 로직에서 DB 드라이버를 통해서 새로운 커넥션을 획득하는 것이 아니라, 커넥션 풀을 통해 커넥션을 획득하고 즉시 SQL을 DB에 전달할 수 있다. 

  • 커넥션을 모두 사용하고 나면 커넥션을 종료하는 것이 아니라, 다음에 다시 사용할 수 있도록 커넥션 풀에 반환하면 된다. 여기서 주의할 점은 커넥션을 종료하는 것이 아니라 커넥션이 살아있는 상태로 커넥션 풀에 반환해야 한다는 것이다.

커넥션 풀의 특징은 다음과 같다.

  • 적절한 커넥션 풀 숫자는 서비스 특징과 애플리케이션 서버 스펙, DB 서버 스펙 등에 따라 다르기 때문에 성능 테스트를 통해 정해야 한다.
  • 커넥션 풀은 서버당 최대 커넥션 수를 제한할 수 있다. 따라서 DB에 무한정 연결이 생성되는 것을 막아 주어서 DB를 보호하는 효과도 있다.
  • 오픈소스 커넥션 풀이 많이 있기 때문에 커넥션 풀을 직접 구현하기 보다는 오픈소스를 사용하는 것이 좋다. 대표적은 커넥션 풀 오픈소스는 commons-dbcp2, tomcat-jdbc pool, HikariCP 등이 있다. 스프링부트는 기본으로 HikariCP를 커넥션 풀로 제공한다.

DataSource: 커넥션 획득 방법의 추상화

커넥션을 얻는 방법으로 JDBC DriverManager를 사용하거나, 커넥션 풀을 사용하는 등 다양한 방법이 존재한다. 만약 DriverManager를 통해서 필요할 때마다 커넥션을 매번 새로 획득하다가, HikariCP 커넥션 풀을 사용하는 방법으로 변경하려면 어떻게 해야할까? 이 경우 커넥션을 획득하는 애플리케이션 코드도 함께 변경해야 한다.

 

자바에서는 이런 문제를 해결하기 위해 javax.sql.DataSource라는 인터페이스를 제공한다. DataSource는 커넥션을 획득하는 방법을 추상화한 인터페이스이다. 이 인터페이스의 핵심 기능은 커넥션 획득 기능이다.

public interface DataSource {
	Connection getConnection() throws SQLException; //커넥션 획득
}

 

그리고 대부분의 커넥션 풀은 DataSource 인터페이스를 이미 구현해두었다. 따라서 개발자는 DBCP2 커넥션 풀, HikariCP 커넥션 풀의 코드를 직접 의존하는 것이 아니라 DataSource 인터페이스에만 의존하도록 애플리케이션 로직을 작성하면 된다.

 

그런데 DriverManager는 DataSource 인터페이스를 구현하지 않는다. 따라서 DriverManager를 사용하다가 DataSource 기반의 커넥션 풀을 사용하려면 관련된 코드를 수정해야 한다. 이런 문제를 해결하기 위해 스프링은 DriverManager도 DataSource를 사용할 수 있도록 DriverManagerDataSource라는 DataSource 구현체를 제공한다. DriverManagerDataSource는 내부에서 DriverManager를 사용해서 커넥션을 생성 및 반환한다. 덕분에 DriverManagerDataSource를 통해서 DriverManager를 사용하다가 커넥션 풀을 사용하도록 코드를 변경해도, 애플리케이션 로직은 변경하지 않아도 된다.

결과적으로 DataSource 덕분에 애플리케이션 로직은 DriverManager나 커넥션 풀의 코드에 직접 의존하지 않으며, DataSource 인터페이스에만 의존할 수 있다. 따라서 커넥션 풀 구현 기술을 변경하고 싶으면 애플리케이션 코드의 변경 없이 해당 구현체로 갈아끼우기만 하면 된다.

DataSource 적용 전

// DriverManager를 통해 커넥션 획득
Connection con1 = DriverManager.getConnection(URL, USERNAME, PASSWORD);
Connection con2 = DriverManager.getConnection(URL, USERNAME, PASSWORD);
// DriverManagerDataSource를 통해 커넥션 획득
DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);

Connection con1 = dataSource.getConnection();
Connection con2 = dataSource.getConnection();
  • DriverManager와 DriverManagerDataSource 둘 다 매번 새로운 커넥션을 획득한다. (커넥션 풀 X)
  • 그러나 DriverManager와 달리, DriverManagerDataSource는 DataSource를 통해서 커넥션을 획득하며, 커넥션을 획득할 때마다 URL, USERNAME, PASSWORD 같은 파라미터를 전달하지 않아도 된다. 처음에 DataSource 객체 생성시에만 파라미터를 전달하고, 그 이후에 커넥션을 획득할 때는 파라미터 없이 dataSource.getConnection()만 호출하면 된다.
  • 설정과 사용의 분리: DriverManagerDataSource를 사용하면 DataSource 객체를 생성(설정)하는 시점에 필요한 데이터를 파라미터로 넘기고, DataSource를 사용하는 시점에는 URL, USERNAME, PASSWORD 같은 속성에 의존하지 않고 dataSource.getConnection()를 호출만 하면 된다. 덕분에 객체를 설정하는 부분과 사용하는 부분을 좀 더 명확하게 분리할 수 있으며 단일 체계의 원칙을 지킬 수 있다.
// 커넥션 풀을 통해 커넥션 획득
HikariDataSource dataSource = new HikariDataSource();
dataSource.setJdbcUrl(URL);
dataSource.setUsername(USERNAME);
dataSource.setPassword(PASSWORD);
dataSource.setMaximumPoolSize(10);
dataSource.setPoolName("MyPool");

Connection con1 = dataSource.getConnection();
Connection con2 = dataSource.getConnection();
  • HikariCP 커넥션 풀을 사용하면 설정한 풀의 사이즈(dataSource.setMaximumPoolSize(10))만큼 커넥션을 생성해두고, 커넥션 요청이 올 때마다 새로 커넥션을 생성하는 것이 아니라 커넥션 풀에서 가져다 쓴다. 
  • 그런데 만약 커넥션 풀에 커넥션이 다 생성되기 전에, 커넥션 요청이 들어온다면 어떻게 동작할까? 커넥션 요청이 들어왔는데 커넥션 풀에 커넥션이 없으면, 커넥션이 마저 생성될 때까지 기다린 후에 커넥션이 생성되는 그 커넥션을 가져다 쓴다.
  • 커넥션 풀에 커넥션을 채우는 것은 상대적으로 오래 걸리는 일이다. 따라서 애플리케이션을 실행할 때 커넥션 풀이 다 채워질 때까지 기다리면 애플리케이션 실행 속도가 늦어진다. 따라서 커넥션 풀에 커넥션을 생성하는 작업은 별도의 쓰레드에서 작동하여 애플리케이션 실행 속도에 영향을 주지 않도록 한다.

DataSource 적용 후

DataSource를 적용하면 다음과 같이 애플리케이션 코드는 DataSource에만 의존한다.

@Slf4j
public class MemberRepository {

    // DataSource 인터페이스를 주입받는다.
    private final DataSource dataSource;
    
    public MemberRepository(DataSource dataSource) {
        this.dataSource = dataSource;
    }
    
    //save()...
    //findById()...
    //update()....
    //delete()....
    
    // JdbcUtils를 통해 커넥션을 닫는다.
    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;
    }
}

 

그리고 다음과 같이 애플리케이션 로직을 호출할 때, 적절한 DataSource의 구현체를 주입하면 된다.

@Slf4j
class MemberRepositoryTest {

    MemberRepository repository;
	
    @BeforeEach
    void beforeEach() throws Exception {
	    
        // DriverManagerDataSource를 통해 매번 새로운 커넥션 생성
        DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        repository = new MemberRepository(dataSource);
    }
}
@Slf4j
class MemberRepositoryTest {

    MemberRepositoryV1 repository;
	
    @BeforeEach
    void beforeEach() throws Exception {
	
        //커넥션 풀
        HikariDataSource dataSource = new HikariDataSource(); 
        dataSource.setJdbcUrl(URL); 
        dataSource.setUsername(USERNAME); 
        dataSource.setPassword(PASSWORD);
        repository = new MemberRepository(dataSource);
    }
}

 

따라서 커넥션 획득 방법이 DriverManagerDataSource에서 HikariDataSource로 변경되어도 애플리케이션의 코드는 변경하지 않아도 된다. 

정리

JDBC를 통한 커넥션 획득 방법을 정리하면 다음과 같다.

  • JDBC의 DriverManager는 라이브러리에 등록된 DB 벤더들의 DB 드라이버들을 관리한다. 그리고 DriverManager를 통해 커넥션을 획득할 수 있다.
    • 이때 DriverManager는 각 DB 드라이버들에게 커넥션을 요청한다.
    • 적절한 DB 드라이버가 찾아지면, DB 드라이버는 TCP/IP를 통해 DB와의 연결을 완료한 후에 커넥션(Connection 인터페이스 구현체)을 반환한다. 
  • 즉, DB 드라이버가 DB와의 커넥션을 맺기 위해서는 네트워크 비용이 발생한다. 따라서 매번 새로운 커넥션을 생성하는 것은 고객에게 응답을 보내는데 SQL 수행 외에도 DB 연결에 걸리는 시간까지 추가로 소요된다. 따라서 애플리케이션 실행 시점에 커넥션을 미리 생성해두고 보관하는 커넥션 풀이라는 개념이 등장한다.
  • DataSource는 커넥션 연결 방법을 추상화하는 JDBC의 인터페이스이다.
    • 따라서 커넥션 풀을 사용할 시, 커넥션 풀은 DataSource의 구현체(ex, HikariDataSource)를 제공하기 때문에 이를 사용하면 된다.
    • 그리고 DriverManager를 통한 커넥션 획득시에도 스프링이 제공하는 DataSource 구현체인 DriverManagerDataSource를 사용하면 된다.
    • 따라서 커넥션 풀을 사용하든 매번 커넥션을 새로 생성하든 , 커넥션 획득 방법이 변경되어도 애플리케이션 로직에는 영향을 주지 않을 수 있다.

Reference

  • 인프런, 스프링 DB 1편 - 데이터 접근 핵심 원리,김영한

스프링 DB 1편 - 데이터 접근 핵심 원리

스프링 DB 1편 - 데이터 접근 핵심 원리스프링 DB 1편 - 데이터 접근 핵심 원리