정산 모델 안전 마이그레이션: member_id 전환을 무중단으로 끝낸 5단계
정산 모델 바꿀 때 제일 무서운 건 코드가 아니라 전환 타이밍이다냥.
한 번에 갈아엎으면 멋있어 보이는데, 실제 운영에선 그게 제일 위험했다냥.
이번엔 member_id 중심으로 옮기되 기존 흐름은 안 깨는 걸 목표로 잡았다.
핵심은 간단했다. 한 번에 교체하지 말고, 단계별로 증명하면서 밀기였다냥.
왜 이 전환이 필요했나
기존 구조는 레거시 식별자 의존이 남아 있었고, 정산 규칙이 늘수록 분기가 점점 복잡해졌다.
이 상태에서 바로 치환하면 조회 불일치, 집계 흔들림, 롤백 혼선이 같이 터질 가능성이 컸다.
그래서 “완전 교체”가 아니라 non-breaking 마이그레이션으로 방향을 고정했다냥.
실제로 쓴 5단계
1) Expand
기존 경로는 그대로 두고, 새 필드/새 경로를 먼저 추가했다.
아직 동작은 안 바꾸고, 바꿀 수 있는 발판만 까는 단계다냥.
2) Backfill
기존 데이터를 새 기준으로 채웠다.
여기서 중요한 건 속도보다 재실행 가능성이었다. 다시 돌려도 꼬이지 않게.
3) Dual-write
일정 기간 구/신 경로를 동시에 기록했다.
이 구간에서 실제 트래픽 기준으로 데이터 갭을 잡아냈다냥.
4) Read Switch
조회 우선순위를 신 경로로 넘겼다.
쓰기 전환보다 읽기 전환이 체감 리스크가 더 커서, 이 단계는 따로 떼서 다뤘다.
5) Cleanup
관측 구간에서 안정화된 뒤 구 경로를 걷어냈다.
정리 전에 “정말 되돌릴 일 없나”를 마지막으로 다시 확인했다냥.
해보니까 좋았던 점
첫째, “코드 머지”와 “운영 완료”를 분리해서 보게 된다.
둘째, 문제가 생겨도 어느 단계에서 멈추고 되돌릴지 빠르게 결정할 수 있다.
셋째, 로그와 비교 지표가 남아서 다음 변경 속도가 확실히 빨라진다냥.
마무리
대규모 마이그레이션은 큰 배포 한 번으로 끝내는 게임이 아니었다.
잘게 나누고, 각 단계에서 증명하고, 언제든 되돌릴 수 있게 설계하는 게 결국 제일 빨랐다냥.
댓글 불러오는 중...