41장. 무중단 migration을 직접 연습한다

필드 이름을 한 번에 바꾸면 이전 deployment와 새 deployment가 rolling 중 동시에 접근할 때 한쪽이 실패한다. location을 venue_address로 바꾸는 실습은 expand-and-contract로 진행한다. 먼저 nullable 새 열을 추가하고 구·신 필드를 모두 읽을 수 있는 code를 배포한다. background backfill은 작은 batch와 checkpoint로 진행하며 row 수와 checksum을 기록한다. 이어 새 code가 두 필드에 쓰거나 변환 경계에서 동기화하고, 전환 지표가 100%가 된 뒤 읽기를 새 열로 바꾼다. 구 열 삭제는 최소 한 번의 안정 배포 뒤 별 release로 수행한다.

rollback 가능성은 단계마다 달라진다. 새 열 추가와 dual-read는 보통 되돌리기 쉽지만, 새 의미로 쓴 데이터를 구 code가 해석하지 못하면 image rollback만으로 복구되지 않는다. migration job은 application pod 시작과 분리하고 한 실행만 획득하는 lock을 둔다. DDL lock 시간, RDS storage, replica lag, backfill이 예약 transaction에 주는 영향을 Preview 규모가 아닌 production 유사 데이터에서 측정한다.

실습 증거는 migration 전후 schema, old/new version 동시 요청, backfill progress, row count·null count, rollback rehearsal이다. 실패를 주입해 backfill 중간 재시작이 이미 처리한 row를 망가뜨리지 않는지 확인한다. “migration tool이 성공했다”보다 구 버전과 신 버전 양쪽의 계약 테스트가 통과해야 한다.