Your VICIdial Database Will Melt Down in 6 Months. Here's How to Prevent It.

Context

VICIdial은 MySQL이 유일한 확장 불가능한 병목이며, 6개월 운영 후 데이터베이스 성능 저하로 에이전트 로그인 불가, 실시간 리포트 로딩 30초 이상, CPU 100% 점유 상태에 이른다. MyISAM 테이블 레벨 잠금으로 인해 vicidial_log의 느린 SELECT 쿼리가 모든 쓰기 작업을 차단하고, vicidial_manager 테이블이 1년 내 100만 행을 초과하면서 저장소와 I/O가 포화된다.

Technical Solution

• DNS 리버스 조회 제거: my.cnf에 skip-name-resolve 설정을 추가하여 매 연결마다 발생하는 MySQL DNS 조회 오버헤드 제거 및 "Too many connections" 에러 방지
• 테이블 아카이빙 자동화: ADMIN_archive_log_tables.pl을 일일 1시 운영 중 백그라운드로 실행하여 vicidial_log, vicidial_log_extended, call_log, vicidial_carrier_log를 주기적으로 아카이빙
• MEMORY 테이블 상한선 설정: max_heap_table_size를 최소 64MB(500+ 에이전트 환경에서 128-256MB)로 구성하여 vicidial_live_agents, vicidial_auto_calls, vicidial_hopper의 INSERT 실패 방지
• 연결 풀 및 캐시 최적화: max_connections 2000, table_open_cache 4096, thread_cache_size 128-512로 설정하여 수백 개의 Perl 데몬 동시 연결 처리
• 쿼리 캐시 및 동시 삽입 활성화: query_cache_size/type을 0으로 비활성화하고 concurrent_insert=2로 설정하여 MyISAM의 높은 쓰기 부하에 대응
• 느린 쿼리 로깅: slow_query_log 활성화 및 long_query_time=2초로 설정하여 vicidial_manager 정리 시 LIMIT을 통한 잠금 최소화
• 디스크 I/O 분리: 데이터베이스 파일을 SSD/NVMe에, 콜 녹음을 별도 디스크/파티션에 배치하여 iostat 모니터링 시 디스크 사용률 80% 이상 회피
• 메모리 할당 최적화: key_buffer_size를 배포 규모(50 에이전트 512MB, 100 에이전트 1024MB, 500 에이전트 4096MB)에 맞춰 설정하되, 전체 RAM의 40-50% 이상 할당하지 않아 OS 파일 캐시 확보
• 연결 타임아웃 단축: interactive_timeout, wait_timeout을 기본값 28800초에서 600초로 단축하여 좀비 연결 정리

Impact

vicidial_manager 테이블: 50 에이전트 기준 월 5-10MB 증가로 6개월 내 40MB+ 도달 (아카이빙 미실시 시 연 100만 행 초과). vicidial_log 테이블: 월 1MB 행 생성으로 6개월 내 6MB 행, 약 2GB 디스크 점유. 총 6개월 누적 데이터베이스 크기: 아카이빙 미실시 시 31GB 이상 증가. MySQL 인스턴스 구성 시 50 에이전트 배포에 약 2GB 버퍼(16GB 서버), 100 에이전트에 약 4GB 버퍼(32GB 서버), 500 에이전트에 약 10GB 버퍼(64GB 서버) 할당.

Key Takeaway

MyISAM 기반 고빈도 쓰기/폴링 워크로드는 테이블 레벨 잠금 해제 불가능하므로, 사전 예방적 아카이빙, DNS 오버헤드 제거, 메모리 상한선 구성으로 데이터 증가에 따른 성능 저하를 선제적으로 차단해야 한다. 확장성 부족한 단일 데이터베이스 설계에서는 용량 계획과 유지보수 일정(일일 아카이빙, 월간 OPTIMIZE)이 아키텍처 변경 못지않게 중요하다.