레거시 서비스를 한 번에 끌 수 없어 일부 요청부터 새 서비스로 옮기려 합니다. 요청 라우팅과 데이터 쓰기 책임을 어떻게 나누고 실패하면 어떻게 되돌리나요?

strangler 방식은 기존 시스템을 한 번에 끄지 않고, 진입 라우터나 모듈 경계에서 기능·사용자 집단을 조금씩 새 시스템으로 전환하는 방법입니다. 기존 외부 계약을 유지하거나 호환 계층을 두고, 새 경로의 결과·오류·지연을 관찰하면서 전환 범위를 늘립니다. 먼저 읽기처럼 부수 효과가 작은 기능을 옮기고 쓰기는 권위 있는 소유자를 명확히 하는 것이 일반적으로 안전합니다.

예를 들어 계정 조회의 5%를 새 서비스로 보내 결과 차이를 비교할 수 있지만, 두 시스템이 동시에 계정 상태를 권위 있게 수정하면 부분 성공과 충돌이 생깁니다. 이중 쓰기를 한다면 어느 시스템이 원본인지, 실패를 어떻게 재처리할지, 순서를 어떻게 맞출지 명시해야 하며 단순히 두 곳에 호출하는 것으로 일관성이 생기지 않습니다. shadow traffic도 실제 결제·메일 같은 부수 효과가 실행되지 않도록 읽기 전용 또는 시뮬레이션 경로로 보내야 합니다.

전환 확대 기준은 오류율·p99·데이터 차이·남은 레거시 호출입니다. 라우팅을 되돌릴 때 새 시스템이 만든 데이터가 레거시 형식으로 표현되지 않을 수 있으므로, 호환 가능한 저장 형식과 역방향 읽기·보정 절차를 먼저 준비해야 합니다. 최종 제거에는 사용 경로가 없다는 증거, 보관·복구 요구, 운영자 도구 종료까지 포함합니다.

테스트는 사용자 단위·기능 단위 전환, 전환 중 장애, 쓰기 재시도, 양방향 데이터 차이, 롤백을 포함합니다. 구축 완료가 아니라 권위 소유권과 레거시 의존성이 실제로 사라졌을 때 전환 완료로 판단하겠습니다.

읽기 전환과 쓰기 권위를 나눕니다

새 서비스의 읽기를 일부 사용자에게 보내고 레거시 결과와 비교하는 shadow는 효과가 적어 안전하지만, 결제·메일 같은 부수 효과를 실행하지 않는 모드여야 합니다. 쓰기는 한 시스템만 권위 있게 하고 다른 쪽은 이벤트·outbox를 통한 복제·보정 대상으로 둡니다. 두 곳에 직접 쓰면 한쪽 성공 뒤 다른 쪽 실패, 순서 역전, 중복 이벤트가 생기므로 권위 저장소와 재처리 규칙을 먼저 정합니다.

롤백은 데이터 표현까지 봅니다

새 서비스가 만든 데이터가 레거시 형식으로 손실 없이 표현되는지, 역변환과 신규 쓰기 제한이 있는지 확인한 뒤 트래픽을 확대합니다. 오류율·p99뿐 아니라 사용자별 결과 차이·중복 효과·레거시 호출량을 기준으로 중단합니다. 라우팅을 되돌려도 새 데이터가 읽히지 않으면 복구가 아니므로 호환 읽기·대사·보정 상태를 둡니다. 최종 완료는 새 서비스가 배포된 때가 아니라 쓰기 권위, 이벤트, 운영 도구와 복구 절차가 실제로 이전된 때입니다.

구체적인 경계 사례

전환 단위는 데이터 소유권과 맞춥니다. 같은 계정의 요청을 매번 임의 분배하면 한 요청은 새 저장소, 다음 요청은 옛 저장소를 권위로 읽어 값이 역행할 수 있습니다. 안정적인 계정 배정과 전환 세대를 두고, 최종 증분 복제가 따라잡은 뒤 쓰기 권위를 바꾸며 이전 세대 쓰기는 실제 저장 지점에서 거절하겠습니다.

shadow 비교에서는 양쪽 응답의 현재 시각·정렬되지 않은 목록 같은 비결정적 필드를 먼저 정규화해야 의미 있는 차이를 찾습니다. 다르다는 이유로 새 결과를 자동 채택하지 않고 정한 권위와 규칙으로 조사합니다. 구형 endpoint를 제거하기 전에는 배치·관리자 도구·재해 복구 절차까지 사용 흔적을 확인하고, 보관할 데이터와 더 이상 허용하지 않을 자격 증명을 정리합니다.