스레드 풀

스레드 풀은 MySQL이 동시에 처리하는 작업 스레드의 수를 일정 범위로 제한하는 기능이다. 클라이언트마다 스레드를 하나씩 만드는 기본 방식의 한계를 보완하기 위해 도입되었다.

기본 방식의 한계

앞서 정리했듯 MySQL은 클라이언트가 연결할 때마다 새 스레드를 하나씩 할당한다(Connection Thread). 이 방식은 단순하고 빠르지만, 동시 연결 수가 많아질수록 다음 문제가 두드러진다.

• 활성 스레드 수가 CPU 코어 수를 한참 넘어가면, 컨텍스트 스위칭 비용이 실제 처리 비용을 압도할 수 있다.
• 동시에 실행되는 작업의 개수를 서버가 제어할 수 없다. 부하가 일정 임계점을 넘으면 응답 시간이 급격히 악화된다.

스레드 캐시는 "스레드를 재사용"하는 장치일 뿐, "동시 실행 스레드 수를 제한"하는 장치는 아니다. 이 차이가 스레드 풀이 필요한 이유다.

스레드 풀의 개념

스레드 풀은 클라이언트 연결과 실제 작업 처리 스레드를 분리한다.

• 클라이언트는 원하는 만큼 연결을 맺을 수 있다.
• 하지만 실제 쿼리는 일정 개수의 스레드(풀)가 돌아가며 처리한다.
• 작업 처리 스레드의 수는 보통 CPU 코어 수에 맞춰 제한되므로, 컨텍스트 스위칭 비용이 안정적으로 유지된다.

연결 수가 폭증해도 서버 내부의 활성 스레드 수는 일정하게 유지되므로, 처리량(throughput)이 안정화된다.

MySQL에서의 지원 현황

여기가 헷갈리기 쉬운 부분이다. 표준 MySQL Community 에디션에는 스레드 풀이 없다.

스레드 풀이 필요한 워크로드라면 보통 Percona Server나 MariaDB로 갈아타거나, 외부 커넥션 풀(ProxySQL 등)에서 동시 연결을 제한하는 방식으로 우회한다.

스레드 그룹 구조

Enterprise / Percona의 스레드 풀은 단일 큐가 아니라 여러 개의 스레드 그룹(Thread Group)으로 나뉘어 동작한다.

• thread_pool_size 변수가 그룹의 개수를 결정하며, 기본값은 CPU 코어 수다.
• 들어오는 연결은 해시 기반으로 특정 그룹에 배정된다.
• 그룹끼리는 락을 공유하지 않으므로, 멀티코어에서의 확장성이 좋다.

언제 효과적인가

• OLTP(Online Transaction Processing) 환경처럼 짧은 쿼리가 매우 많이 들어오는 워크로드
• 수천 개 이상의 동시 연결이 필요한 환경
• 응답 시간의 일관성이 중요한 환경 (트래픽 스파이크 대응)

한계

• 긴 쿼리가 그룹의 스레드를 오래 점유하면, 같은 그룹에 배정된 다른 연결은 대기해야 한다. 슬로우 쿼리 하나가 그룹 단위로 영향을 준다.
• 트랜잭션 처리 중에는 다른 그룹으로 옮겨갈 수 없다. 트랜잭션이 길어지면 그룹 내 가용 스레드가 빠르게 줄어든다.
• 동시 연결이 적은 환경에서는 오히려 오버헤드가 될 수 있다. 모든 워크로드에서 효과적이지는 않다.