컷오버 당일 남은 데이터 이관과 전환 확인

Nike Korea Platform Migration · Series 3 - 컷오버와 직후 안정화2 / 3Backend

사전 배치 이후 바뀐 데이터를 마지막으로 반영하고, 트래픽 전환과 운영 확인을 이어간 과정을 정리합니다.

사전에 데이터를 옮겨 놔도 서비스가 계속 운영되는 동안에는 새 주문과 회원 정보 변경이 발생합니다. 플랫폼을 전환하는 날에는 마지막 배치 이후의 변경분을 반영해야 했습니다. 이 글에서 말하는 델타 데이터는 그 사이에 추가되거나 바뀐 데이터를 뜻합니다.

당일 작업은 데이터 이관만으로 끝나지 않았습니다. 기존 서비스의 쓰기를 멈추고, 남은 데이터를 반영하고, 검증을 거친 뒤 새 플랫폼으로 트래픽을 넘기는 순서를 맞춰야 했습니다.

쓰기 중단과 이관 기준 시점

기존 Breeze에서 데이터가 계속 바뀌면 마지막으로 옮겨야 할 범위도 계속 늘어납니다. 그래서 유지보수 시간에는 주문과 회원가입 등 새로운 데이터를 만드는 요청을 중단하고 이관 기준을 고정했습니다.

화면에 유지보수 안내를 띄우는 것과 실제 데이터 변경이 멈추는 것은 별개입니다. 이미 실행 중인 요청이나 백그라운드 작업이 남아 있을 수 있으므로, 최종 이관 범위를 정하려면 쓰기가 멈췄는지도 확인해야 합니다.

사전 배치에서 옮긴 데이터와 당일 변경분을 나눠 처리했습니다. 신규 주문뿐 아니라 이미 존재하는 주문의 상태 변경이나 회원 정보 수정도 함께 고려해야 했습니다. 생성일만 기준으로 잡으면 기존 데이터의 변경을 놓칠 수 있기 때문입니다.

당일에는 미리 옮긴 전체 데이터를 다시 처리하기보다 마지막으로 반영해야 할 범위를 확인하는 것이 중요했습니다. 데이터 종류마다 사전 배치가 어디까지 끝났는지와 최종 반영 범위를 맞춰 봐야 했습니다.

이관 작업이 오류 없이 끝났다고 해서 결과가 모두 맞는 것은 아닙니다. 원본과 대상의 건수를 비교하고, 차이가 있다면 변환 규칙에 따라 제외한 것인지 실제 누락인지 구분해야 했습니다.

주문은 건수 외에 금액과 상태도 중요합니다. 데이터가 존재하더라도 사용자의 주문으로 조회되지 않거나 후속 처리를 이어갈 수 없다면 전환 준비가 끝났다고 보기 어렵습니다. 그래서 배치 결과와 서비스에서 사용하는 조회 경로를 함께 확인해야 했습니다.

데이터 검증 이후에는 DNS를 전환하고 새 플랫폼으로 요청이 들어오는지 확인했습니다. DNS 변경만으로 모든 사용자의 요청이 동시에 바뀌는 것은 아니므로, 실제 유입과 주요 기능의 응답을 이어서 살펴봤습니다.

로그인, 상품 조회, 주문과 결제처럼 고객이 사용하는 경로의 상태를 확인하고 전환 이후 발생하는 오류를 봤습니다. 이 시점부터는 이관 작업의 성공 여부와 서비스가 정상적으로 운영되는지를 함께 판단해야 했습니다.

작업은 미국의 글로벌 팀과 한국 팀이 함께 진행했습니다. 시차가 있어 작업 시간과 담당자를 미리 맞춰야 했고, 당일에는 워룸을 유지하며 상태를 공유했습니다.

야간 작업에 맞춰 출근 시간을 조정하고 교대로 모니터링과 검증을 맡았습니다. 일부 인원은 다음 날 늦은 오전까지 안정화 확인을 이어갔습니다. 한 번의 전환 명령보다, 전후 작업을 끊기지 않게 이어가는 데 시간이 들었습니다.

음성·화상으로 논의한 내용도 중요한 결정과 진행 상태는 텍스트로 남겼습니다. 교대하거나 잠시 자리를 비운 사람이 현재 어디까지 진행됐는지 확인할 수 있어야 했기 때문입니다.

다음 글에서는 컷오버 직후의 안정화 작업을 다룹니다.