메타급 규모에서 데이터 수집 시스템 마이그레이션하기 (새 탭에서 열림)

Meta는 수 페타바이트 규모의 소셜 그래프 데이터를 매일 MySQL에서 데이터 웨어하우스로 수집하는 시스템을 기존 고객 소유 파이프라인에서 단순한 자체 관리형 아키텍처로 전환했다. 이 과정에서 수천 개 작업을 단계적으로 검증하고, 데이터 품질·지연 시간·리소스 사용량을 비교하며 안전하게 마이그레이션했다. 섀도 작업, 리버스 섀도, 자동화된 데이터 품질 분석, 신속한 롤백 체계를 통해 전체 워크로드를 성공적으로 이전하고 레거시 시스템을 폐기했다.

대규모 데이터 수집 시스템 개편 배경

• Meta의 소셜 그래프는 세계 최대 규모의 MySQL 환경 중 하나에서 운영된다.
• 데이터 수집 시스템은 매일 수 페타바이트의 데이터를 증분 방식으로 데이터 웨어하우스에 적재한다.
• 적재된 데이터는 다음과 같은 용도로 활용된다.
  • 분석 및 리포팅
  • 머신러닝 모델 학습
  • 제품 개발
  • 사내 의사결정 및 데이터 기반 서비스
• 기존 시스템은 소규모에서는 효과적이었지만, 규모가 커지면서 엄격해진 데이터 적재 시간 요구사항을 안정적으로 충족하기 어려워졌다.
• 이에 따라 고객 팀이 직접 운영하던 파이프라인을 단순한 자체 관리형 데이터 웨어하우스 서비스로 대체했다.

마이그레이션 성공 기준

각 작업은 다음 조건을 충족해야 다음 단계로 진행됐다.

• 데이터 품질 일치
  • 기존 시스템과 신규 시스템의 행 개수를 비교했다.
  • 데이터 체크섬을 비교해 두 시스템의 결과가 완전히 일치하는지 검증했다.
• 적재 지연 시간 개선
  • 신규 시스템의 데이터 적재 지연 시간이 기존보다 개선되거나 최소한 동등해야 했다.
• 리소스 사용량 개선
  • 컴퓨팅 및 스토리지 사용량이 기존보다 줄어들거나 최소한 비슷해야 했다.
• 핵심 테이블 추가 기준
  • 중요 테이블은 해당 데이터를 사용하는 팀들과 별도의 마이그레이션 조건을 합의했다.

1단계: 섀도 단계

• 사전 운영 환경에 신규 시스템 기반의 섀도 작업을 생성했다.
• 섀도 작업은 운영 작업과 동일한 실제 데이터를 읽지만, 별도의 섀도 테이블에 결과를 기록했다.
• 실제 운영 데이터와 동작을 사용하므로 다음과 같은 문제를 사전에 발견할 수 있었다.
  • 데이터 변환 오류
  • 특수한 데이터 패턴에서 발생하는 예외
  • 신규 시스템의 리소스 부족
• 운영 테이블과 섀도 테이블의 행 개수 및 체크섬을 지속적으로 비교했다.
• 불일치가 발생하면 원인을 조사하고 사전 운영 환경에 수정 사항을 배포한 뒤 재검증했다.
• 동시에 섀도 작업의 컴퓨팅·스토리지 사용량을 측정해 운영 환경에 충분한 자원이 있는지 확인했다.
• 기준을 통과한 작업은 운영 환경에서도 안정적으로 실행되는지 추가로 검증했다.

2단계: 리버스 섀도 단계

• 신규 시스템의 섀도 작업이 운영 테이블에 데이터를 기록하도록 전환했다.
• 기존 시스템의 운영 작업은 섀도 테이블에 데이터를 기록하게 했다.
• 이로써 신규 시스템이 실제 운영 작업이 되고, 기존 시스템은 비교용 섀도 작업으로 역할이 바뀌었다.
• 이 방식의 장점은 다음과 같다.
  • 전환 이후에도 기존 시스템과 신규 시스템의 결과를 계속 비교할 수 있다.
  • 데이터 불일치가 발견되면 기존 작업을 다시 구성하지 않고 즉시 되돌릴 수 있다.
  • 신규 시스템이 실제 운영 환경에서 지속적으로 안정적인지 확인할 수 있다.

3단계: 마이그레이션 정리

• 두 시스템의 결과를 계속 비교하면서 불일치 여부를 감시했다.
• 문제가 발견되지 않으면 기존 시스템에서 실행 중인 섀도 작업을 제거했다.
• 이후 신규 시스템이 운영 작업으로서 데이터 적재를 계속 수행하며 마이그레이션이 완료됐다.

자동화된 데이터 품질 분석 도구

• 각 섀도 테이블 파티션과 대응하는 운영 테이블 파티션을 읽어 행 개수와 체크섬을 비교했다.
• 불일치 내역은 Meta의 실시간 데이터 분석 시스템인 Scuba에 기록했다.
• 매시간 Scuba 로그를 분석해 불일치를 일으킨 실제 예시 행을 찾았다.
• 원인 분석에 필요한 상세 디버깅 정보도 다시 Scuba에 기록했다.
• 이를 통해 엔지니어는 다음을 빠르게 판단할 수 있었다.
  • 불일치의 근본 원인
  • 이미 알려진 문제인지 여부
  • 해당 문제가 수정 진행 중인지 여부
• 이 도구는 마이그레이션 이후에도 릴리스 검증 과정에서 계속 사용되고 있다.

CDC 기반 구조와 롤백 문제

• 기존 시스템과 신규 시스템 모두 CDC(Change Data Capture)를 사용해 변경분을 대상 테이블에 증분 반영했다.
• 각 작업은 다음 테이블을 관리한다.
  • 소스 데이터베이스의 전체 덤프를 저장하는 내부 테이블
  • 소스 변경 사항을 저장하는 델타 테이블
  • 데이터 소비자가 사용하는 대상 테이블
• 작업 엔터티, 테이블 이름, 스키마 등의 메타데이터는 중앙 관리 서비스가 관리했다.
• CDC에서는 이전에 적재된 데이터가 이후 데이터 생성에 다시 사용된다.
• 따라서 과거 데이터에 문제가 있으면 해당 문제가 신규 적재 데이터로 계속 전파될 수 있다.
• 마이그레이션 후 문제가 발생하면 잘못된 데이터가 계속 확산되는 것을 막기 위해 신속한 롤백이 필요했다.

조기 신호와 신속한 롤백

• 데이터 소비자가 문제를 발견할 때까지 기다리지 않고, 리버스 섀도 단계에서 두 시스템의 결과를 지속적으로 비교했다.
• 이를 통해 마이그레이션 성공 여부에 대한 조기 신호를 확보했다.
• 문제가 발견되면 기존 시스템이 이미 섀도 작업으로 실행 중이므로 빠르게 이전 상태로 되돌릴 수 있었다.
• 마이그레이션 작업을 처음부터 다시 생성하거나 재구성하지 않아도 된다는 점이 롤백 위험을 줄였다.

대규모 데이터 시스템을 이전할 때는 한 번에 전환하기보다, 실제 데이터 기반의 섀도 실행과 양방향 역할 전환을 통해 검증하는 방식이 안전하다. 특히 행 개수·체크섬·지연 시간·리소스 사용량을 자동 비교하고, 문제가 생겼을 때 즉시 롤백할 수 있는 구조를 마이그레이션 설계에 포함하는 것이 중요하다.