Connection Pool

데이터베이스 커넥션을 얻는 과정

• DB 드라이버를 통해 커넥션을 조회한다.
• DB와 TCP/IP 커넥션을 연결한다.
• DB에 부가정보 전달한다.
• 내부에 DB 세션 생성한다.
• DB는 커넥션 생성이 완료되었다는 응답을 보낸다
• DB 드라이버는 커넥션 객체 생성해서 클라이언트에 반환한다.

이러한 과정은 복잡하고 시간도 많이 소요된다.

 

커넥션 풀

• 어플리케이션 시작 시점에 커넥션 풀은 필요한 만큼 커넥션을 확보해서 풀에 보관한다.
• 보통 기본값은 10개이다.
  • 적절한 커넥션 풀 숫자는 성능 테스트를 통해 정해야 한다.
• 커넥션 풀은 서버당 최대 커넥션 수를 제한하는 효과도 있다(DB 보호)
• 스프링부트는 기본적으로 hikariCP를 사용한다. (성능, 안정성, 편리함 모두 검증 됨)
• 참고로, 커넥션 풀에서 커넥션을 생성하는 작업은 별도 쓰레드로 동작한다. (커넥션 생성이 오래걸리는 작업이기 때문에)
• 커넥션 풀이 무제한으로 많으면 좋을까?
  • Thread수보다 커넥션이 많으면 작업은 하지 못하고 그냥 놀게됨. 메모리만 차지
  • 리소스 소모: 각각의 커넥션은 메모리와 시스템 리소스를 사용. 서버의 리소스를 과도하게 소모
  • 네트워크 부하: 많은 커넥션을 유지하면 서버와의 네트워크 트래픽이 늘어날 수 있다. TCP 소켓 계속 열어 놓고 있기 때문에
  • Tn x (Cm - 1) + 1
    • Tn : Thread 개수
    • Cm : 하나의 Task에서 동시에 필요한 커넥션 수
    • 데드락은 피하겠지만, 여유 커넥션풀이 하나라 성능상 좋지 못함
  • Tn × ( Cm - 1 ) + ( Tn / 2 )

 

DataSource

• 커넥션을 획득하는 방법을 추상화한 인터페이스
• 핵심 기능은 커넥션 조회이다 -> getConnection()
• 설정과 사용의 분리 케이스
  • 최초에 생성할 때만 URL, USERNAME, PASSWORD와 같은 파라미터를 전달해 설정하고
  • 실제로 사용할 때는 설정은 신경쓰지 않고 getConnection()만 호출하면 된다.

 

hikariCP

• maxLifetime : 커넥션을 얼마나 유지할지에 대한 설정이다.
  • maxLifetime에 설정한 시간이 지나면 커넥션을 재연결한다.
  • 커넥션풀에서 꺼내서 사용중인 커넥션은 제거되진 않지만, 커넥션 풀에 돌아오는 순간 제거된다.
• connectionTimeout : 커넥션 맺을때 기다리는 시간
• minimumIdle: 유휴 커넥션을 유지할 최소 연결 수
  • 기본적으로 maximumPoolSize과 같은 값을 가진다
• maximumPoolSize : 풀에서 유지 가능한 최대 연결 수
• readOnly : 읽기 전용 모드로 연결을 가져올 것인지 제어
• connectionInitSql : 새 커넥션이 풀에 추가되기전에 매번 실행될 SQL
• transactionIsolation : 커넥션의 기본 트랜잭션 격리 수준
• idleTimeout : 커넥션이 idleTimeout시간 동안 놀고 있으면 연결 해제 한다.
  • minimumIdle < maximumPoolSize
    • idleTimeout은 유휴 상태로 놀고 있는 커넥션들을 제거하는 역할인데, 풀의 최소 갯수까지 떨어지면 더 이상 제거하지 않는다
  • maxLifetime -1 > idleTimeout