Netflix, RDS PostgreSQL에서 Aurora PostgreSQL로의 자동 마이그레이션 성공 사례 공개
넷플릭스는 데이터베이스 표준화를 위해 RDS PostgreSQL에서 Aurora PostgreSQL로의 마이그레이션을 결정, 확장성 및 운영 효율성(Operational Efficiency)을 확보하고자 함
자동화된 셀프 서비스(Self-service) 마이그레이션 워크플로우를 구축하여 400개 이상의 PostgreSQL 클러스터(Cluster) 마이그레이션을 지원, 운영 부담을 줄임
데이터 손실 방지, 최소한의 다운타임(Downtime) 보장, 애플리케이션(Application) 변경 최소화 등 기술적 과제(Technical Challenges) 해결에 집중
Aurora Read Replica 기반의 마이그레이션 전략을 채택하여 다운타임(Downtime)을 10분 내외로 단축하고, 데이터 일관성을 유지함
파트너 통합(Partner Integration) 데이터베이스 마이그레이션 사례를 통해 실제 운영 환경(Production Environment)에서의 성공적인 전환을 입증
RDS PostgreSQL에서 Aurora PostgreSQL로의 마이그레이션 단계
넷플릭스는 RDS PostgreSQL에서 Aurora PostgreSQL로의 마이그레이션을 위해 데이터 복제(Data Replication), 정지(Quiescence), 검증(Validation), 컷오버(Cutover)의 4단계 프로세스를 거쳤다.
데이터 복제(Data Replication): RDS에서 Aurora Read Replica를 생성하여 지속적인 데이터 동기화(Data Synchronization)를 수행
정지(Quiescence): 애플리케이션(Application)의 쓰기 트래픽(Write Traffic)을 중단하고, RDS 인스턴스(Instance)의 보안 그룹(Security Group)을 분리하여 데이터 일관성(Data Consistency) 확보
검증(Validation): Aurora의 OldestReplicationSlotLag 메트릭(Metric)을 통해 데이터 동기화 완료 여부 확인
컷오버(Cutover): Data Access Layer(DAL) 설정을 변경하여 Aurora로 트래픽(Traffic)을 전환
각 단계별로 데이터 손실(Data Loss)을 방지하고, 최소한의 다운타임(Downtime)을 보장하기 위한 노력을 기울였다.
Aurora Read Replica 기반 마이그레이션의 기술적 장점
본문에서는 Aurora Read Replica 기반 마이그레이션 방식이 스냅샷(Snapshot) 방식보다 다운타임(Downtime)을 단축하는 데 효과적이라고 설명한다.
지속적인 복제(Continuous Replication): RDS와 Aurora 간의 지속적인 데이터 동기화(Data Synchronization)를 통해 컷오버(Cutover) 시점의 데이터 격차 최소화
10분 내외의 다운타임(Downtime): RDS 인스턴스(Instance) 재부팅(Reboot) 및 유휴 WAL(Write-Ahead Log) 스위치(Switch) 시간을 포함하여 짧은 다운타임(Downtime) 보장
Data Access Layer(DAL) 활용: 애플리케이션(Application) 코드 변경 없이 트래픽(Traffic) 전환 가능
이러한 장점들을 통해 넷플릭스는 서비스 중단을 최소화하면서 RDS PostgreSQL에서 Aurora PostgreSQL로의 마이그레이션을 성공적으로 수행했다.
마이그레이션 중 CDC(Change Data Capture) 처리 방법
넷플릭스는 마이그레이션 과정에서 CDC(Change Data Capture) 소비자(Consumer)의 안전한 전환을 위해 논리적 복제 슬롯(Logical Replication Slot) 관리에 집중했다.
CDC 중단: 컷오버(Cutover) 전에 CDC 소비를 일시 중단하고, 복제 슬롯(Replication Slot)을 제거하여 WAL(Write-Ahead Log) 리사이클링(Recycling)을 방지
데이터 백필(Backfill): Aurora에서 새로운 복제 슬롯(Replication Slot)을 생성하고, 전체 데이터 백필(Backfill)을 수행하여 데이터 일관성(Data Consistency) 확보
갱신 이벤트(Refresh Events) 처리: CDC 소비자는 갱신 이벤트(Refresh Events)를 웁서트(Upsert) 연산으로 처리하도록 설계되어 데이터 손실(Data Loss) 및 중복 처리 방지
이러한 과정을 통해 넷플릭스는 CDC 소비자(Consumer)를 안전하게 Aurora PostgreSQL 환경으로 이전하고, 데이터 파이프라인(Data Pipeline)의 안정성을 유지했다.
RDS PostgreSQL에서 Aurora PostgreSQL로의 인스턴스 타입 선택
넷플릭스는 RDS PostgreSQL에서 Aurora PostgreSQL로의 인스턴스 타입(Instance Type) 선택 시 안정성과 성능을 최우선으로 고려했다.
Graviton2 기반 인스턴스(Instance): r6g 제품군을 우선적으로 고려하고, 기존 RDS 인스턴스(Instance)의 메모리(Memory) 사용량과 동일하게 설정
메모리(Memory) 기반 매핑: m-시리즈(Series) 인스턴스(Instance)가 지원되지 않으므로, 메모리(Memory) 용량에 맞춰 Aurora 인스턴스(Instance)를 선택
성능 테스트(Performance Test) 수행: 실제 워크로드(Workload)를 Aurora에서 실행하여 성능 저하 여부 확인
이러한 접근 방식을 통해 넷플릭스는 마이그레이션 후에도 안정적인 성능을 유지하고, 비용 효율성을 확보했다.
마이그레이션 롤백(Rollback) 전략
넷플릭스는 마이그레이션 과정에서 발생할 수 있는 문제에 대비하여 롤백(Rollback) 전략을 마련했다.
사전 정지(Pre-quiescence) 단계: Aurora 클러스터(Cluster) 삭제 및 RDS PostgreSQL로의 복귀를 통해 간단하게 롤백(Rollback) 수행
정지(Quiescence) 단계: RDS 보안 그룹(Security Group) 재설정 및 CDC(Change Data Capture) 재구성을 통해 RDS PostgreSQL로의 복귀
컷오버(Cutover) 이후: AWS DMS(Database Migration Service)를 활용하여 Aurora에서 RDS PostgreSQL로의 데이터 복제(Data Replication)를 수행
각 단계별로 롤백(Rollback) 전략을 수립하여, 마이그레이션 실패 시에도 데이터 손실(Data Loss)을 최소화하고 서비스의 안정성을 확보했다.
