DB 테이블 파티셔닝 키 선정 오류와 데이터 쏠림

증상 확인: 쿼리 성능이 갑자기 저하되거나 특정 파티션만 과도하게 커짐

데이터베이스의 특정 테이블에 대한 INSERT나 SELECT 쿼리 성능이 예상과 달리 현저히 떨어지는 현상을 확인했습니다, 예를 들어 시간이 지남에 따라 쿼리 응답 시간이 선형적으로 증가하는 패턴을 보입니다. 시스템 모니터링 도구를 통해 확인 시, 디스크 I/O가 특정 물리적 스토리지에 집중되어 있고, 일부 파티션의 데이터 볼륨이 다른 파티션에 비해 압도적으로 큰 ‘데이터 쏠림’ 현상이 관찰됩니다. 이는 파티셔닝 키 선정 오류의 대표적인 징후입니다.

원인 분석: 균등 분포를 저해하는 파티셔닝 키의 선택

파티셔닝의 핵심 목적은 대용량 데이터를 작은 논리적 단위로 분할하여 관리 효율성과 쿼리 성능을 향상시키는 데 있습니다. 파티셔닝 키 선정 오류는 이 목적을 근본적으로 무너뜨립니다. 가장 흔한 원인은 카디널리티가 지나치게 낮은 컬럼(예: ‘성별’, ‘도시’ 코드)을 키로 선택하는 경우입니다. 이는 파티션 개수 자체를 제한하여 결국 소수의 파티션에 데이터가 몰리게 만듭니다. 또 다른 심각한 오류는 시간 기반 파티셔닝에서 실제 데이터 발생 패턴을 고려하지 않는 것입니다. 특히, ‘생성일자’를 키로 삼았지만, 특정 기간(예: 대규모 프로모션 기간)에 90%의 데이터가 집중적으로 입력된다면 해당 월의 파티션만 비정상적으로 커지게 됩니다.

해결 방법 1: 기존 파티셔닝 전략의 즉각적인 진단과 보정

현재 시스템의 파티셔닝 상태를 정확히 파악하는 것이 첫걸음입니다. 서버를 중단하지 않고도 실행 가능한 조치부터 시작합니다.

파티션 데이터 분포 현황 분석

데이터베이스 관리 시스템(DBMS)별 명령어를 통해 각 파티션의 행 수와 데이터 크기를 확인합니다.

1. MySQL/InnoDB 기준 진단:
   SELECT PARTITION_NAME, TABLE_ROWS, DATA_LENGTH FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 'your_table_name'; 명령어를 실행합니다. TABLE_ROWS와 DATA_LENGTH 값이 특정 파티션에 집중되어 있는지 확인합니다.
2. 현재 파티셔닝 함수 및 키 확인:
   SHOW CREATE TABLE your_table_name\G 명령어를 실행하여 출력 결과의 ‘PARTITION BY’ 절을 확인합니다. 현재 사용 중인 키와 함수(예: RANGE, LIST, HASH)를 정확히 파악합니다.

분석 결과, 특정 파티션의 데이터 양이 다른 파티션 평균의 10배를 초과한다면 심각한 쏠림으로 판단하고 다음 단계로 진행합니다.

해결 방법 2: 파티셔닝 키 재선정을 위한 실전 전략

파티셔닝 키는 데이터 접근 패턴과 균등 분포, 두 마리 토끼를 모두 잡아야 합니다. 기존 키가 명백히 실패했다면, 재설계는 필수입니다.

1. 후보 컬럼 선정: 카디널리티가 높으며, 빈번한 WHERE 조건절에 사용되는 컬럼을 후보로 검토합니다. ‘회원번호’, ‘트랜잭션 UUID’와 같이 고유한 값이 많고, 데이터가 자연스럽게 분산될 수 있는 컬럼이 이상적입니다.
2. 복합 키 검토: 단일 컬럼으로 적합한 키를 찾기 어렵다면, 복합 키를 고려합니다. 예를 들어. partition by range (to_days(created_at)) subpartition by hash(user_id % 4)와 같이 메인 파티셔닝은 범위로, 서브파티셔닝은 해시로 구성하여 두 차원에서 분산을 도모할 수 있습니다.
3. 새로운 파티션 테이블 생성 및 데이터 이관: 기존 테이블 구조를 복제하되, create table 문의 partition by 절을 새로 선정한 키와 전략으로 변경합니다. 이후 데이터를 새 테이블로 이관합니다. 이 작업은 대량의 데이터 이동이 수반되므로, 서비스 트래픽이 가장 적은 시간대에 진행하고 트랜잭션 로그 백업을 반드시 수행한 후 시작해야 합니다.

해결 방법 3: 데이터 재분배와 동적 파티션 관리 자동화

파티셔닝 키를 변경하는 것이 현실적으로 어려운 경우, 기존 파티셔닝 전략 내에서 데이터 쏠림을 완화하고 관리 부하를 줄이는 운영적 해결책을 적용합니다.

HASH 파티셔닝의 파티션 수 조정

HASH 파티셔닝을 사용 중이고 쏠림이 발생했다면, 파티션 개수를 증가시키는 것이 가장 효과적인 방법입니다. 파티션 개수를 소수가 아닌 2의 제곱수(예: 16, 32, 64)로 설정하면 데이터 분포가 보다 균일해지는 경향이 있습니다. ALTER TABLE … 이처럼 pARTITION BY HASH(column) PARTITIONS 64; 와 같은 명령으로 파티션 수를 조정할 수 있으나, 이 작업 또한 테이블 리빌드가 발생하므로 주의가 필요합니다.

파티션 병합 및 분할 전략 수립

RANGE 파티셔닝에서 특정 기간의 데이터가 폭증하는 패턴이 명확하다면, 해당 기간의 파티션 크기를 더 작은 단위로 분할하는 전략이 필요합니다. 예를 들어, 월별 파티셔닝에서 데이터가 집중되는 월은 주별로, 나머지 월은 월별로 유지하는 혼합 전략을 수립합니다. 대부분의 현대 RDBMS는 ALTER TABLE … REORGANIZE PARTITION 명령어를 통해 기존 파티션을 분할하거나 병합하는 기능을 제공합니다.

이러한 분할/병합 작업을 정기 배치 작업(예: 매월 1일 새벽)에 등록하여 파티션 크기가 일정 수준을 넘지 않도록 자동화하는 것이 시스템 안정성을 높이는 핵심입니다.

주의사항: 파티셔닝 변경 작업의 위험과 필수 절차

파티셔닝은 테이블의 물리적 구조를 변경하는 중대한 작업입니다. 실수는 데이터 손실이나 장시간 서비스 중단으로 이어질 수 있습니다.

• 완전 백업 선행: 파티션 스키마를 변경하기 전에 반드시 해당 테이블의 논리적 백업(예: mysqldump)을 포함한 전체 데이터베이스 백업을 수행합니다. 운영 체제의 스냅샷 기능이 있다면 이를 함께 활용하는 것이 복구 시간을 단축시킵니다.
• 스테이징 환경 검증: 모든 변경 사항은 실제 운영 환경에 적용하기 전에 스테이징 환경에서 충분히 테스트해야 합니다. 특히 데이터 이관 스크립트의 정확성과 성능, 새로운 파티션 키를 사용한 핵심 쿼리의 실행 계획 변경을 꼼꼼히 점검합니다.
• 변경 시간대 계획: 데이터 재분배 작업은 디스크 I/O와 CPU를 집중적으로 사용합니다. 서비스 이용이 최소화되는 공식 점검 시간대를 활용하고, 변경에 소요될 예상 시간을 사전에 고지해야 합니다.

전문가 팁: 파티셔닝 키 후보를 선정할 때는 데이터 분포의 균등성만 고려하지 마십시오. 가장 빈번하게 실행되고, 성능이 중요한 비즈니스 쿼리의 WHERE 절과 JOIN 조건을 분석하십시오. 파티셔닝 키가 이러한 조건에 포함된다면 ‘파티션 프루닝’이 동작하여 쿼리 성능이 극적으로 개선됩니다. 이상적인 키는 높은 카디널리티로 인한 균등 분포와 비즈니스 접근 패턴, 이 두 가지 축에서 최적의 교차점을 찾는 것입니다. 장기적으로는 파티션 모니터링 지표(파티션 별 크기, 행 수, 마지막 접근 시간)를 대시보드화하여 데이터 쏠림 현상이 재발하지 않도록 선제적으로 관리하는 체계를 구축해야 합니다.