PostgreSQL 파티셔닝 적용 중 데이터 불균형으로 인한 성능 저하 사례

파티셔닝 도입 배경과 현장 상황

B2B 서비스가 성장하면서 데이터베이스 테이블의 용량이 기하급수적으로 늘어났고, 서비스 반응성 저하와 백업·복구 시간 증가라는 문제에 직면했다. 특히 주문 이력, 로그, 이벤트 아카이브 등 대용량 테이블은 쿼리 성능 저하와 유지관리 부담이 두드러졌다. 이에 따라 PostgreSQL 파티셔닝을 도입해 확장성과 관리 용이성을 높이기로 결정했다.

실제 현장에서는 파티셔닝이 만능 해결책처럼 여겨지지만, 설계와 적용 과정에는 많은 함정이 숨어 있다. 특히 파티션 키 선정, 분포 예측, 관리 정책 등은 실무에서 충분히 검토되지 않고 넘어가는 경우가 많다. 우리 팀 역시 처음에는 파티셔닝을 ‘적용만 하면 성능이 좋아질 것’이라는 기대 아래 도입을 시작했다.

데이터 불균형의 징후와 성능 저하 발견 과정

파티셔닝 적용 후 초기에는 전체 쿼리 속도가 빠르게 개선되는 듯 보였다. 하지만 시간이 지나면서 특정 파티션에 작업이 집중되고, 일부 파티션에서는 쿼리 속도가 오히려 더 악화되는 현상이 감지됐다. 특히 월별 파티셔닝을 적용한 테이블에서 최근 월 파티션에 데이터가 몰리면서 인덱스 유지 비용까지 증가했다.

실제 장애 신고가 들어온 지점은 “특정 고객사의 주문 내역 조회”였다. 해당 고객사는 대량의 주문을 특정 기간에 몰아서 처리하는 패턴이 있었는데, 이로 인해 파티션 분포가 심하게 불균형해졌다. 이 때부터 파티셔닝이 단순히 데이터 분할 이상의 문제임을 실감했다.

문제 확인을 위해 아래와 같이 파티션별 데이터 건수를 점검했다.

SELECT
  inhrelid::regclass AS partition,
  reltuples::bigint AS row_count
FROM
  pg_class c
  JOIN pg_inherits i ON c.oid = i.inhrelid
ORDER BY
  row_count DESC;

이 결과에서 상위 1~2개 파티션에 전체 데이터의 80% 이상이 몰려있는 것을 확인했다.

파티션 키 선정 기준과 분포 예측의 허점

초기 설계에서 우리는 ‘날짜(월별)’를 파티션 키로 삼았다. 직관적으로 데이터가 시간 순으로 누적되고, 오래된 데이터는 자연스럽게 아카이빙/삭제가 가능할 것으로 기대했다. 그러나 실제 서비스 패턴은 예측과 달랐다. 특정 이벤트, 마케팅, 혹은 외부 연동 업무가 몰리는 기간이 반복적으로 존재했고, 이 때마다 일부 파티션에 데이터가 몰렸다.

예상하지 못한 또 다른 변수는 ‘고객사별 데이터 집중’이었다. B2B 특성상 일부 대형 고객사는 일시에 대량 데이터를 쌓으며, 이 패턴은 단순 시간 기준 파티션으로는 분산이 어려웠다. 결과적으로 파티션 설계가 서비스의 실제 사용 흐름과 맞지 않아 성능 저하로 이어졌다.

이 지점에서 실무자의 고민은 ‘파티션 키를 어떻게 선정해야 하는가’, ‘데이터 분포를 사전에 어떻게 예측할 수 있는가’로 모아진다. 현장에서는 다음 순서로 접근했다.

1. 주요 데이터 접속·저장 패턴을 로그로 수집
2. 파티션 키 후보(예: 날짜, 고객사, 복합키)의 분포 시뮬레이션
3. 실제 데이터의 시간·고객사별 분포 그래프 작성
4. 예외적 피크 구간이 전체에 미치는 영향 분석
5. 복합 파티셔닝(예: 월별+고객사) 시나리오 검토

실무 적용 중 막히는 지점과 점검 포인트

실제 파티셔닝을 적용하다 보면 다음과 같은 난관에 자주 봉착한다. 첫째, 데이터 분포가 시간이 지나며 예측과 달라진다. 서비스가 성장하거나 비즈니스 이벤트가 반복되면, 초기 파티션 설계가 무력화된다. 둘째, 파티션 키를 변경하거나 재설계하는 과정에서 데이터 이동 및 대규모 마이그레이션이 필요하다. 이 과정에서 서비스 중단이나 데이터 정합성 문제가 발생할 위험이 높다.

실무에서 가장 막히는 지점은 ‘파티션 설계 변경의 타이밍’이다. 언제, 어떻게, 어떤 근거로 파티션 구조를 바꿔야 하는지 결정하는 것이 가장 어렵다. 우리 팀은 아래와 같은 점검 순서를 적용했다.

1. 파티션별 데이터 건수, 인덱스 크기, 쿼리 빈도 주기적 수집
2. 특정 파티션에 쿼리 병목 또는 인덱스 부하 발생 시점 탐지
3. 데이터 분포 변화가 감지되면, 서비스 주요 이벤트와 연계해 원인 분석
4. 파티션 재분할/병합/키 변경 시, 서비스 영향도 최소화 방안(백필, 트래픽 분산 등) 사전 설계
5. 테스트 환경에서 파티션 변경 시나리오 반복 검증 및 롤백 플랜 마련

파티셔닝 구조 개선과 운영 전략

데이터 불균형이 심각해진 이후, 우리는 파티션 구조 개선에 착수했다. 기존 월별 파티셔닝에 더해 ‘고객사’를 보조 키로 삼는 복합 파티셔닝을 도입했다. 일부 대형 고객사에 대해서는 별도의 파티션을 분리해 관리하는 정책도 추가했다. 결과적으로 데이터가 보다 고르게 분산되고, 인덱스 유지 비용과 쿼리 효율성이 크게 개선됐다.

운영 중에도 주기적으로 아래 항목을 점검했다. 첫째, 신규 고객사 유입이나 서비스 기능 추가 시 데이터 분포 변화 예측. 둘째, 데이터 볼륨이 급증하는 파티션에 대한 자동 경고 및 확장 정책. 셋째, 파티션 아카이빙/삭제/병합 정책을 문서화해, 팀 전체가 관리 기준을 공유했다.

특히 아래와 같은 실무 원칙을 세웠다.

• 파티셔닝은 성능 최적화의 ‘최후 수단’임을 명확히 인식
• 파티션 키 선정 전에 실제 데이터 분포와 서비스 패턴을 충분히 분석
• 파티션 구조는 정기적으로 점검하고, 필요시 유연하게 변경할 수 있게 설계
• 파티션별 데이터 분포, 인덱스 부하 등 모니터링 지표를 자동화
• 파티션 변경 시 반드시 테스트 및 롤백 플랜을 수립

파티셔닝 설계 및 운영 체크리스트

• 파티션 키 선정 전, 실제 데이터 분포와 서비스 패턴(트래픽, 저장, 조회)을 수집·분석한다.
• 파티션별 데이터량, 쿼리 빈도, 인덱스 크기를 주기적으로 모니터링하고 불균형을 조기에 감지한다.
• 파티션 구조 변경(분할, 병합, 키 변경)이 필요한 시점을 정의하고, 적용 절차와 롤백 플랜을 마련한다.
• 대형 고객사·이벤트 등 예외적 데이터 집중 구간에 대한 별도 파티셔닝 정책을 준비한다.
• 파티션 관리 정책(아카이빙, 삭제, 병합 등)을 문서화해 팀 내에서 지속적으로 공유·점검한다.