웹 서비스나 애플리케이션을 운영하다 보면 가장 당혹스러운 순간 중 하나가 바로 데이터베이스 연결 오류입니다. 특히 트래픽이 급증하거나 특정 이벤트가 진행 중일 때 발생하는 "Too many connections" 에러는 서비스 전체를 마비시킬 수 있는 치명적인 문제입니다. 이 오류는 말 그대로 MySQL 서버가 허용할 수 있는 최대 동시 연결 수를 초과했을 때 발생하며, 신규 사용자의 진입을 막고 기존 세션까지 불안정하게 만듭니다. 단순히 서버의 사양을 높이는 것만이 능사가 아닙니다. 현재 설정된 max_connections 값을 적절하게 수정하고, 불필요하게 자원을 점유하고 있는 대기 세션(Sleep Session)을 정리하는 과정이 필수적입니다. 오늘은 MySQL 운영 환경에서 빈번하게 발생하는 이 문제를 근본적으로 해결하기 위한 설정 변경 방법과 실전 유지보수 노하우를 아주 상세하게 다루어 보겠습니다.
Too many connections 에러가 발생하는 근본적인 원인 분석
이 에러를 해결하기 위해서는 먼저 왜 이러한 현상이 발생하는지 그 메커니즘을 정확히 이해해야 합니다. MySQL 서버는 클라이언트로부터 연결 요청이 들어올 때마다 하나의 스레드를 할당하여 작업을 처리합니다. 하지만 서버의 메모리와 CPU 자원은 유한하기 때문에 무한정 연결을 받아들일 수는 없습니다. 따라서 MySQL은 설정 파일에 정의된 최대 연결 수만큼만 접속을 허용하도록 설계되어 있습니다.
기본 설정값의 한계와 트래픽 급증
MySQL을 처음 설치하면 기본적으로 max_connections 값은 보통 151로 설정되어 있습니다. 개인 프로젝트나 소규모 웹사이트에서는 이 수치가 충분할 수 있지만, 동시 접속자가 조금만 늘어나는 쇼핑몰이나 커뮤니티 사이트에서는 턱없이 부족한 수치입니다. 마케팅 이벤트를 통해 사용자가 순간적으로 몰리거나, 애플리케이션 서버(WAS)를 스케일 아웃(Scale-out)하여 서버 대수를 늘릴 경우, DB로 들어오는 연결 요청 총합이 이 제한 값을 순식간에 넘어서게 됩니다. 이때 152번째 접속자부터는 연결 거부 메시지를 받게 되며 서비스 장애로 이어집니다.
애플리케이션의 커넥션 누수(Connection Leak)
설정값이 넉넉함에도 불구하고 이 에러가 발생한다면 애플리케이션 코드를 의심해봐야 합니다. 개발자가 DB 연결을 맺은 후(Open), 작업을 마치고 명시적으로 연결을 닫지(Close) 않는 경우가 이에 해당합니다. 특히 예외 처리(Exception Handling) 구문에서 연결 종료 코드가 누락되면, 에러가 발생할 때마다 연결이 끊어지지 않은 채 서버에 '좀비'처럼 남아 있게 됩니다. 이렇게 쌓인 유령 세션들은 아무런 작업을 하지 않으면서 연결 슬롯만 차지하여, 정작 필요한 정상적인 연결 요청을 방해하게 됩니다.
슬로우 쿼리로 인한 병목 현상
쿼리 튜닝이 제대로 되지 않아 특정 쿼리의 수행 시간이 길어지는 경우에도 연결 부족 현상이 발생할 수 있습니다. 하나의 요청을 처리하는 데 1초가 걸린다면 해당 연결은 1초 만에 반환되지만, 10초가 걸린다면 그만큼 오랫동안 연결을 점유하게 됩니다. 이러한 슬로우 쿼리가 동시다발적으로 실행되면, 새로운 요청을 처리할 스레드가 부족해지면서 결국 연결 한계에 도달하게 됩니다. 이는 단순히 max_connections 값을 늘리는 것으로는 해결되지 않으며, 근본적인 쿼리 최적화가 동반되어야 합니다.
현재 MySQL 연결 상태 점검 및 진단하기
무작정 설정을 변경하기 전에 현재 서버의 상태를 정확한 수치로 확인하는 것이 중요합니다. MySQL은 다양한 상태 변수와 명령어를 통해 현재 연결 현황을 실시간으로 모니터링할 수 있는 기능을 제공합니다. 다음의 명령어들을 통해 현재 상황을 진단해 봅시다.
SHOW VARIABLES LIKE '%max_connections%';
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Threads_running';
SHOW STATUS LIKE 'Max_used_connections';
위 명령어들의 의미를 정확히 해석하는 것이 튜닝의 첫걸음입니다. 각 항목이 나타내는 바는 다음과 같습니다.
- max_connections: 서버가 허용하는 최대 동시 접속 수 설정값입니다.
- Threads_connected: 현재 활성화된(열려 있는) 전체 커넥션 수입니다. 이 값이 max_connections에 근접했다면 위험 신호입니다.
- Threads_running: 현재 실제로 쿼리를 수행 중인(Sleeping 상태가 아닌) 스레드 수입니다. Connected 값은 높은데 Running 값이 현저히 낮다면, 대부분의 세션이 놀고 있다는 뜻이므로 타임아웃 설정 튜닝이 필요합니다.
- Max_used_connections: 서버 가동 이후 동시 접속자 수가 최대 몇 명까지 도달했었는지를 보여주는 지표입니다. 이 값이 max_connections 설정값보다 높거나 비슷하다면 과거에 이미 연결 거부가 발생했을 확률이 높습니다.
Processlist를 통한 세부 현황 파악
전체적인 숫자만으로는 어떤 사용자가, 어떤 호스트에서, 어떤 쿼리를 실행 중인지 알 수 없습니다. 구체적인 범인을 색출하기 위해서는 프로세스 리스트를 확인해야 합니다.
SHOW FULL PROCESSLIST;
이 명령어를 실행하면 현재 접속 중인 모든 세션의 ID, User, Host, DB, Command, Time, State, Info 정보를 볼 수 있습니다. 여기서 눈여겨봐야 할 컬럼은 Command와 Time입니다. Command가 'Sleep'이면서 Time(초 단위)이 매우 큰 세션들이 다수 존재한다면, 이것이 바로 연결 슬롯을 낭비하는 주범입니다. 이러한 세션들이 정리되지 않고 쌓이면 신규 접속을 방해하게 됩니다.
max_connections 설정 값 안전하게 변경하기
진단 결과 최대 연결 수를 늘려야 한다고 판단되었다면, 두 가지 방법으로 설정을 변경할 수 있습니다. 하나는 재부팅 없이 즉시 적용하는 방법이고, 다른 하나는 서버 재시작 후에도 유지되도록 설정 파일을 수정하는 방법입니다. 운영 중인 서비스의 안정성을 위해 두 가지 방법을 모두 적용하는 것이 좋습니다.
방법 1: 서비스 중단 없는 동적 변경 (일시적)
댓글
댓글 쓰기