본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 20일!
오늘은 DB 스레드 커넥션 풀에 대한 개념 학습을 진행하였다.
애플리케이션에서 DB 요청을 위해 연결하는 작업은 네트워크를 통해 연결하기 때문에 큰 비용이 든다.
이러한 작업을 유저 요청이 올 때마다 매번 수행한다면 엄청난 병목이 된다.
그렇기 때문에 매번 DB에 연결하는 것이 아니라, 미리 연결을 만들어 두고 관리하는 방법으로 연결을 재사용하는 DB Connection Pool을 사용한다.
Spring에서는 DataSource 인터페이스를 이용하여 커넥션 풀을 관리한다.
기존에는 Tomcat, JDBC를 이용하였지만, 2.0 이후부터는 HikariCP 라이브러리를 기본 옵션으로 사용한다.
(그래서 진행하고 있는 커뮤니티 피드 서비스 프로젝트를 실행하면 콘솔에 Hikari pool 관련 내용이 출력된다.)
DataSource에서 지정해둔 타임아웃 시간을 초과하면 해당 요청을 에러로 처리한다.
위와 같은 문제를 예방하기 위해 처음부터 많은 연결을 만들어두면 어떻게 될까?
DB가 처리할 수 있는 스레드 숫자는 제한되어 있다. (cpu 코어 개수 * 2 + 저장 매체에 따른 개수 차이)
즉, 오히려 잦은 컨텍스트 스위칭으로 인해서 성능이 떨어지게 된다.
nGrinder 등의 부하 테스트 툴을 사용하여 테스트를 진행하며 최적의 스레드 풀 개수를 찾는 것이 좋다.
요청이 스레드 풀을 빠르게 반환하게 하려면 트랜잭션을 작게 잡는 것도 중요하다!
한 트랜잭션 안에서 너무 많은 작업이 진행되면 그만큼 해당 요청이 스레드를 점유하는 시간이 길어지고, 다른 요청들은 대기할 확률이 높아짐에 따라 타임아웃 에러가 발생할 가능성이 높아진다.
이전 강의 중에 잠깐 설명해주셨다시피, 프로젝트 설정 중 Open-in-view 옵션을 true로 해두면 (영속성 컨텍스트의 생존 범위가 트랜잭션 범위보다 커져서) Controller 반환 때까지 커넥션을 반납하지 않는다.
하지만 이런 osiv 옵션을 켜두면 뷰 템플릿이나 API Controller에서도 지연로딩이 가능하다는 장점이 있다.
성능이 중요하지 않고 뷰 템플릿을 이용하는 서비스의 경우, OSIV 옵션을 켜두는 것이 좋은 선택일수도 있다.
매번 프로젝트를 진행할 때마다 로그에 출력되는 Hikari Pool 관련 내용이 기억이 난다.
DB 커넥션과 같이 너무 당연하게 사용했던 것들이 어떻게 동작하는지에 대해 알고 있으면 더 깊이 있는 개발을 할 수 있을 것 같다.