DB 샤드 간 데이터 재배치(Migration) 시 서비스 성능 저하

증상 확인: 데이터 재배치 중 발생하는 성능 저하 패턴

데이터베이스 샤드 간 재배치(Migration) 작업 중 다음과 같은 현상이 관찰되나요? 쿼리 응답 시간이 평소보다 300% 이상 증가했거나, CPU 사용률이 80% 이상을 장기간 유지하며, 디스크 I/O 대기 시간이 급격히 늘어났습니다. 일례로, INSERT, UPDATE와 같은 쓰기 작업의 지연이 두드러지며, 간헐적인 커넥션 타임아웃이 발생할 수 있습니다. 이는 단순한 리소스 부족이 아닌, 데이터 이동이라는 특수 작업으로 인한 시스템 전반의 과부하 상태를 의미합니다.

원인 분석: 재배치 프로세스의 내부 동작과 병목 현상

데이터 재배치는 단순한 파일 복사가 아닙니다. 소스 샤드에서 데이터를 읽어오는 단계, 네트워크를 통해 전송하는 단계, 타겟 샤드에 쓰는 단계, 그리고 양쪽 샤드의 메타데이터를 동기화하는 단계로 구성됩니다. 각 단계는 기존 서비스 트래픽과 리소스를 경쟁적으로 사용합니다. 주요 병목 지점은 다음과 같습니다. 첫째, 디스크 I/O 경합: 소스 샤드의 데이터 읽기와 타겟 샤드의 데이터 쓰기가 동시에 발생하며 디스크 성능을 집중적으로 소모합니다. 둘째, 네트워크 대역폭 포화: 대량의 데이터가 내부 네트워크를 통해 이동하며, 애플리케이션 서버와 DB 간의 정상 트래픽을 방해합니다. 셋째, 메타데이터 락(Metadata Lock) 경합: 마이그레이션 중인 테이블의 스키마 변경이나 인덱스 재구성이 발생할 경우, 해당 테이블에 대한 일반 쿼리 실행이 대기 상태에 빠질 수 있습니다.

해결 방법 1: 운영 정책 최적화 – 서비스 영향도 최소화

가장 안전한 접근법은 재배치 작업 자체가 서비스에 미치는 영향을 제어하는 것입니다. 기술적 변경 없이 운영 방식을 조정하여 성능 저하를 완화할 수 있습니다.

경고: 본 방법을 실행하기 전, 반드시 현재 데이터베이스 클러스터의 전체 백업을 수행하십시오. 운영 중인 시스템의 작업 스케줄 변경은 예상치 못한 부하 패턴을 유발할 수 있습니다.

1. 작업 시간대 변경: 서비스 사용량이 가장 낮은 시간대(예: 새벽 2시~5시)로 재배치 작업을 예약하십시오. 대부분의 DB 관리 도구(예: MongoDB Balancer, Vitess)는 작업 스케줄 설정을 지원합니다.
2. 병렬 처리 제한(Throttling): 한 번에 이동하는 데이터 청크(Chunk)의 크기와 동시에 실행되는 마이그레이션 작업의 수를 제한하십시오. MongoDB의 경우 balancer.stop() 명령으로 밸런서를 중지한 후, sh.setBalancerState()로 제한된 시간대를 설정할 수 있습니다.
3. 모니터링 강화: 재배치 작업 중에는 CPU, 메모리, 디스크 I/O, 네트워크 트래픽, 오픈 커넥션 수를 실시간으로 모니터링해야 합니다. 임계치(예: CPU 70%, 디스크 사용률 85%)를 초과하면 작업을 일시 중단할 수 있는 경고 알림을 설정하십시오.

해결 방법 2: 기술적 구성 조정 – 마이그레이션 효율 극대화

운영 정책만으로 부족하다면, 데이터베이스 및 인프라의 기술적 설정을 최적화하여 재배치 자체의 속도를 높이고 리소스 소모를 줄여야 합니다.

데이터베이스 엔진별 최적화 명령어 및 설정

사용 중인 DBMS에 따라 최적화 포인트가 다릅니다. 공통 원리는 디스크 I/O와 네트워크 오버헤드를 줄이는 것입니다.

• MongoDB:
  1. 인덱스 마이그레이션을 분리: moveChunk 시 _secondaryThrottle 및 waitForDelete 파라미터를 조정하여 부하를 분산.
  2. Config Server의 성능 확인: 샤드 키 메타데이터를 관리하는 Config Server의 사양이 충분한지 점검. 성능 병목이 될 수 있음.
• MySQL 기반 샤딩 (Vitess/ProxySQL):
  1. 온라인 스키마 변경 도구(gh-ost, pt-online-schema-change) 활용: 트리거 기반이 아닌 바이너리 로그 복제 방식을 사용하여 메인 테이블에 대한 부하를 최소화.
  2. 대량 데이터 복사 시 LOAD DATA INFILE 또는 클라이언트 측 일괄 삽입(Batch Insert) 사용: row-by-row 삽입보다 네트워크 왕복(RTT)을 획기적으로 감소.
• PostgreSQL (Citus): citus.shard_replication_factor 값을 임시로 1로 조정하여 재배치 시 복제본 간 동기화 오버헤드를 제거. 작업 완료 후 원래 값으로 복원 필수.

인프라 계층 최적화

데이터베이스가 구동되는 하드웨어와 네트워크 성능이 재배치 속도를 결정합니다.

1. 디스크 I/O 성능 확보: 소스 및 타겟 샤드가 위치한 서버의 디스크가 SSD이며, 충분한 Provisioned IOPS(클라우드 환경)를 보유하고 있는지 확인. 로컬 SSD는 네트워크 스토리지보다 재배치 속도에 유리함.
2. 네트워크 대역폭 확장: 샤드 간 통신이 전용 네트워크 링크 또는 충분한 대역폭을 가진 가상 네트워크를 통해 이루어지도록 구성. 재배치 작업 기간 동안만 임시로 네트워크 대역폭을 업그레이드하는 옵션을 검토.
3. 메모리 할당량 증가: 재배치 작업 중에는 데이터베이스의 버퍼 풀(Buffer Pool)이나 캐시 크기를 일시적으로 증가시켜 디스크 접근 빈도를 낮출 수 있습니다, 인스턴스 타입 업그레이드가 한 방법입니다.

해결 방법 3: 아키텍처적 접근 – 지속적이고 무정지 재배치 구현

재배치를 주기적인 “이벤트”가 아닌, 시스템의 “일상적인 상태”로 만드는 것이 궁극적인 해결책입니다. 이를 위해서는 애플리케이션과 데이터 계층의 설계 변경이 필요할 수 있습니다.

1. 듀얼 라이팅(Dual Writing) 패턴 도입: 애플리케이션 레이어에서 쓰기 작업 발생 시, 기존 샤드와 새로운 샤드 양쪽에 동시에 데이터를 기록합니다. 이 방식은 재배치 기간을 무한히 길게 가져가도 서비스 중단이 발생하지 않도록 합니다. 백그라운드에서 점진적으로 기존 데이터를 새로운 샤드로 이동시키는 작업을 수행한 후, 데이터 정합성이 확인되면 읽기 트래픽을 새로운 샤드로 전환하고 기존 샤드의 쓰기를 중단합니다.
2. 가상 샤드 키 또는 동적 파티셔닝 사용: 물리적 샤드 재배치 대신, 논리적인 파티션 매핑을 변경하는 방식입니다. 데이터 자체를 이동시키지 않고, 어떤 데이터가 어떤 물리적 샤드에 속하는지를 정의하는 메타데이터(라우팅 테이블)만 변경합니다. 이는 데이터 이동에 따른 I/O/네트워크 비용을 근본적으로 제거합니다. Cassandra의 Virtual Nodes(vnodes) 개념이 대표적입니다.
3. 서비스 메시(Service Mesh)를 활용한 트래픽 제어: 재배치 기간 동안 특정 유저 또는 트래픽을 새로운 샤드로 점진적으로 라우팅하는 카나리아 릴리스(Canary Release)를 데이터 계층에 적용합니다. Istio, Linkerd와 같은 서비스 메시를 사용하면 애플리케이션 코드 변경 없이 세밀한 트래픽 라우팅 규칙을 설정할 수 있습니다.

주의사항 및 예방 조치

성능 저하를 해결하는 과정에서 데이터 무결성과 서비스 가용성을 훼손해서는 안 됩니다. 다음 체크리스트를 반드시 준수하십시오.

• 롤백 계획 수립 필수: 재배치 작업 실패 또는 심각한 성능 저하 발생 시, 원래 상태로 안전하게 되돌릴 수 있는 절차(롤백 스크립트, 백업 복구 절차)를 사전에 테스트하고 문서화해야 합니다.
• 데이터 정합성 검증 자동화: 재배치가 완료되었다고 선언하기 전, 소스와 타겟 샤드 간의 데이터 건수, 체크섬, 샘플 레코드 검증을 자동화된 도구로 반드시 수행합니다. 수동 검증은 신뢰성과 확장성이 떨어집니다.
• 연쇄 장애 방지: 한 번에 너무 많은 샤드에서 재배치 작업을 동시에 실행하지 마십시오. 하나의 샤드 재배치로 인한 성능 저하가 다른 샤드의 부하 증가를 유발하며, 전체 클러스터의 연쇄 과부하로 이어질 수 있습니다.
• 애플리케이션 타임아웃 설정 조정: 재배치 기간 중에는 일시적으로 애플리케이션의 데이터베이스 쿼리 타임아웃 값을 늘려, 단순한 지연으로 인한 불필요한 에러를 방지할 수 있습니다. 단, 이 설정은 작업 종료 후 원복해야 합니다.

전문가 팁: 재배치 성능 저하는 미리 예측하고 설계할 수 있는 문제입니다. 새 샤딩 클러스터를 도입할 때, POC(Proof of Concept) 단계에서 최대 부하 조건에서의 대량 데이터 재배치 테스트를 반드시 수행하십시오. 이 테스트에서 측정된 지표(예: 분당 이동 가능한 데이터량, CPU/IO 사용률)는 향후 운영 시 가장 정확한 용량 계획(Capacity Planning)의 기준이 됩니다. 또한, “무정지 운영”을 목표로 한다면, 해결 방법 3에서 언급된 듀얼 라이팅 패턴과 가상 샤딩 전략을 초기 아키텍처 설계 단계부터 고려하는 것이 장기적인 운영 복잡성과 비용을 줄이는 길입니다.