메타급 규모에서 데이터 수집 시스템 마이그레이션하기
Meta는 수 페타바이트 규모의 소셜 그래프 데이터를 매일 MySQL에서 데이터 웨어하우스로 수집하는 시스템을 기존 고객 소유 파이프라인에서 단순한 자체 관리형 아키텍처로 전환했다. 이 과정에서 수천 개 작업을 단계적으로 검증하고, 데이터 품질·지연 시간·리소스 사용량을 비교하며 안전하게 마이그레이션했다. 섀도 작업, 리버스 섀도, 자동화된 데이터 품질 분석, 신속한 롤백 체계를 통해 전체 워크로드를 성공적으로 이전하고 레거시 시스템을 폐기했다. ## 대규모 데이터 수집 시스템 개편 배경 - Meta의 소셜 그래프는 세계 최대 규모의 MySQL 환경 중 하나에서 운영된다. - 데이터 수집 시스템은 매일 수 페타바이트의 데이터를 증분 방식으로 데이터 웨어하우스에 적재한다. - 적재된 데이터는 다음과 같은 용도로 활용된다. - 분석 및 리포팅 - 머신러닝 모델 학습 - 제품 개발 - 사내 의사결정 및 데이터 기반 서비스 - 기존 시스템은 소규모에서는 효과적이었지만, 규모가 커지면서 엄격해진 데이터 적재 시간 요구사항을 안정적으로 충족하기 어려워졌다. - 이에 따라 고객 팀이 직접 운영하던 파이프라인을 단순한 자체 관리형 데이터 웨어하우스 서비스로 대체했다. ## 마이그레이션 성공 기준 각 작업은 다음 조건을 충족해야 다음 단계로 진행됐다. - **데이터 품질 일치** - 기존 시스템과 신규 시스템의 행 개수를 비교했다. - 데이터 체크섬을 비교해 두 시스템의 결과가 완전히 일치하는지 검증했다. - **적재 지연 시간 개선** - 신규 시스템의 데이터 적재 지연 시간이 기존보다 개선되거나 최소한 동등해야 했다. - **리소스 사용량 개선** - 컴퓨팅 및 스토리지 사용량이 기존보다 줄어들거나 최소한 비슷해야 했다. - **핵심 테이블 추가 기준** - 중요 테이블은 해당 데이터를 사용하는 팀들과 별도의 마이그레이션 조건을 합의했다. ## 1단계: 섀도 단계 - 사전 운영 환경에 신규 시스템 기반의 섀도 작업을 생성했다. - 섀도 작업은 운영 작업과 동일한 실제 데이터를 읽지만, 별도의 섀도 테이블에 결과를 기록했다. - 실제 운영 데이터와 동작을 사용하므로 다음과 같은 문제를 사전에 발견할 수 있었다. - 데이터 변환 오류 - 특수한 데이터 패턴에서 발생하는 예외 - 신규 시스템의 리소스 부족 - 운영 테이블과 섀도 테이블의 행 개수 및 체크섬을 지속적으로 비교했다. - 불일치가 발생하면 원인을 조사하고 사전 운영 환경에 수정 사항을 배포한 뒤 재검증했다. - 동시에 섀도 작업의 컴퓨팅·스토리지 사용량을 측정해 운영 환경에 충분한 자원이 있는지 확인했다. - 기준을 통과한 작업은 운영 환경에서도 안정적으로 실행되는지 추가로 검증했다. ## 2단계: 리버스 섀도 단계 - 신규 시스템의 섀도 작업이 운영 테이블에 데이터를 기록하도록 전환했다. - 기존 시스템의 운영 작업은 섀도 테이블에 데이터를 기록하게 했다. - 이로써 신규 시스템이 실제 운영 작업이 되고, 기존 시스템은 비교용 섀도 작업으로 역할이 바뀌었다. - 이 방식의 장점은 다음과 같다. - 전환 이후에도 기존 시스템과 신규 시스템의 결과를 계속 비교할 수 있다. - 데이터 불일치가 발견되면 기존 작업을 다시 구성하지 않고 즉시 되돌릴 수 있다. - 신규 시스템이 실제 운영 환경에서 지속적으로 안정적인지 확인할 수 있다. ## 3단계: 마이그레이션 정리 - 두 시스템의 결과를 계속 비교하면서 불일치 여부를 감시했다. - 문제가 발견되지 않으면 기존 시스템에서 실행 중인 섀도 작업을 제거했다. - 이후 신규 시스템이 운영 작업으로서 데이터 적재를 계속 수행하며 마이그레이션이 완료됐다. ## 자동화된 데이터 품질 분석 도구 - 각 섀도 테이블 파티션과 대응하는 운영 테이블 파티션을 읽어 행 개수와 체크섬을 비교했다. - 불일치 내역은 Meta의 실시간 데이터 분석 시스템인 Scuba에 기록했다. - 매시간 Scuba 로그를 분석해 불일치를 일으킨 실제 예시 행을 찾았다. - 원인 분석에 필요한 상세 디버깅 정보도 다시 Scuba에 기록했다. - 이를 통해 엔지니어는 다음을 빠르게 판단할 수 있었다. - 불일치의 근본 원인 - 이미 알려진 문제인지 여부 - 해당 문제가 수정 진행 중인지 여부 - 이 도구는 마이그레이션 이후에도 릴리스 검증 과정에서 계속 사용되고 있다. ## CDC 기반 구조와 롤백 문제 - 기존 시스템과 신규 시스템 모두 CDC(Change Data Capture)를 사용해 변경분을 대상 테이블에 증분 반영했다. - 각 작업은 다음 테이블을 관리한다. - 소스 데이터베이스의 전체 덤프를 저장하는 내부 테이블 - 소스 변경 사항을 저장하는 델타 테이블 - 데이터 소비자가 사용하는 대상 테이블 - 작업 엔터티, 테이블 이름, 스키마 등의 메타데이터는 중앙 관리 서비스가 관리했다. - CDC에서는 이전에 적재된 데이터가 이후 데이터 생성에 다시 사용된다. - 따라서 과거 데이터에 문제가 있으면 해당 문제가 신규 적재 데이터로 계속 전파될 수 있다. - 마이그레이션 후 문제가 발생하면 잘못된 데이터가 계속 확산되는 것을 막기 위해 신속한 롤백이 필요했다. ## 조기 신호와 신속한 롤백 - 데이터 소비자가 문제를 발견할 때까지 기다리지 않고, 리버스 섀도 단계에서 두 시스템의 결과를 지속적으로 비교했다. - 이를 통해 마이그레이션 성공 여부에 대한 조기 신호를 확보했다. - 문제가 발견되면 기존 시스템이 이미 섀도 작업으로 실행 중이므로 빠르게 이전 상태로 되돌릴 수 있었다. - 마이그레이션 작업을 처음부터 다시 생성하거나 재구성하지 않아도 된다는 점이 롤백 위험을 줄였다. 대규모 데이터 시스템을 이전할 때는 한 번에 전환하기보다, 실제 데이터 기반의 섀도 실행과 양방향 역할 전환을 통해 검증하는 방식이 안전하다. 특히 행 개수·체크섬·지연 시간·리소스 사용량을 자동 비교하고, 문제가 생겼을 때 즉시 롤백할 수 있는 구조를 마이그레이션 설계에 포함하는 것이 중요하다.
원문 읽기(새 탭에서 열림)
