DATABASE CONNECTION POOL
DB 커넥션 풀은 애플리케이션에서 데이터베이스를 연결할 때, 매번 새로 연결 생성을 하는 비용을 줄이기 위하여 미리 여러개의 커넥션을 만들어 두고, 필요한 경우 재사용하는 기법으로 성능 최적화와 자원관리 용이를 위해 사용한다.
지금까지 써왔던 PRISMA 같은 ORM에서는 자동으로 풀링기능을 지원하여 소중함을 몰랐지만, 앞으로 로우쿼리로 작업할 때가 많을 것 같아 사용법을 익혀두면 좋을 것 같다.
개념
커넥션 풀은 DB와의 연결을 미리 만들어 풀에 보관하며, 요청이 발생하면 미리 생성된 커넥션을 대여해주고 작업이 끝나면 반환받는다. 만약 만들어둔 커넥션이 모두 사용중이라면, 새로 생성하거나 대기한다. 최소 연결수와 최대 연결수를 설정하여 과부하를 방지할 수 있다.
장점
장점으로는 매번 연결/해제 하는 비용을 절감할 수 있다는 점이고, 커넥션 자원 관리를 효율적으로 수행할 수 있으며 성능 향상 및 트래픽 처리 능력이 증가한다.
커넥션 풀을 사용하지 않을 때 문제점
전반적인 성능 하락을 초래하며, 커넥션을 자주 생성하고 소멸 시키기에 CPU와 메모리 사용량을 증가시켜 불필요한 서버 자원을 소비하게 된다. 데이터베이스 최대 커넥션 수가 정해져있는데 이를 초과하여 데이터베이스에 접근할 수 없는 결과를 초래하게 된다.
그렇다면 ?
Max_Connection을 100000으로 두고 서버의 성능을 대폭 향상시키면 되는 것 아닌가라는 의구점이 들 것이다. max_connection을 무한정으로 늘리기에는 innodb_buffer_pool_size와 같은 데이터베이스 파라미터 들도 조정해야하고 시스템 성능은 더불어 뒷받침이 되어야 하며, 운영체제 상에서 많은 커넥션을 허용하려면 File Descriptor 제한도 늘려야 한다.
FILE DECRIPTOR 란
여기서 파일 디스크립터는 운영체제가 파일이나 소켓같은 I/O 자원에 대한 접근을 추적하기 위하여 사용하는 정수형 핸들이다. 프로세스가 파일을 열거나 네트워크 소켓에 연결할 때마다 고유한 파일 디스크립터가 할당된다.
보통 프로세스가 열 수 있는 파일 디스크립터는 리눅스의 경우 1024개로 제한이 되어있으며, 열린 파일의 디스크립터를 명시적으로 닫지 않으면 자원 누수가 발생할 수 있다.
장점
운영체제가 자원에 효율적으로 접근할 수 있게 해준다.
단점
파일 디스크립터를 너무 많이 열면 에러가 발생한다.
파일 디스크립터 수 확인 및 제한 설정
# 현재 열린 파일 디스크립터 확인
lsof -p <process_id>
# 현재 파일 디스크립터 제한 확인
ulimit -n
# 파일 디스크립터 제한 설정 (일시적)
ulimit -n 2048정리
DB 커넥션 풀은 데이터 베이스 연결을 효율적으로 관리하여 성능을 향상시키며 사용하지 않으면 전반적인 성능 하락, 불필요 서버 자원 소비, 커넥션 한계 초과등의 손해가 막심하다.
