결제 시스템을 다뤄본 엔지니어라면 ‘무중단 마이그레이션(Zero Downtime Migration)‘이라는 단어가 얼마나 무서운지 알 것이다. 일반적인 B2C 서비스라면 새벽 3시에 점검 공지를 띄우고 DB를 마이그레이션하겠지만, 글로벌 결제망(Payment Network)에서는 단 1초의 다운타임도 허용되지 않는다. 그 1초 동안 누군가의 카드 결제가 거절되고, 이는 곧바로 비즈니스 신뢰도 하락과 막대한 금전적 손실로 이어진다.

최근 아메리칸 익스프레스(American Express, 이하 Amex) 엔지니어링 블로그에 올라온 Migrating the Payments Network, Twice라는 글을 읽었다. 이들은 거대한 레거시 결제망을 새로운 마이크로서비스 아키텍처로 한 번, 그리고 새로운 쿠버네티스(Kubernetes) 인프라로 또 한 번, 총 두 번의 무중단 마이그레이션을 해냈다.

15년 넘게 백엔드와 인프라를 뒹굴며 온갖 마이그레이션 실패 사례를 목격해 온 입장에서, 이들의 접근 방식은 교과서적이면서도 대단히 실용적이었다. 이 글에서는 Amex가 어떤 엔지니어링 결정을 내렸는지 딥다이브 해보고, Hacker News의 반응과 내 개인적인 견해를 덧붙여 보겠다.

마이그레이션의 제약 조건: 타협은 없다

Amex 결제망은 전 세계 가맹점, 매입사, 발급사를 연결하는 미션 크리티컬 분산 시스템이다. 이들은 2018년부터 레거시에서 마이크로서비스 기반 플랫폼으로의 현대화를 시작했는데, 조건이 매우 까다로웠다.

• Zero Downtime: 계획된 점검 시간조차 허용 불가
• No Regressions: 기존 결제 처리 로직의 완벽한 1:1 호환
• Performance: Latency와 Throughput의 유지 혹은 개선

이런 제약 속에서 ‘빅뱅(Big-bang)’ 방식의 오픈은 자살 행위다. 이들은 철저히 점진적인 방식을 택했다.

첫 번째 마이그레이션: 레거시에서 마이크로서비스로

이 마이그레이션의 핵심은 GTR (Global Transaction Router)이라는 라우팅 레이어의 도입이다. 카드 승인 트래픽은 일반적인 HTTP API가 아니라, 결제 도메인 특화 포맷인 ISO8583 메시지를 담은 Long-lived TCP 커넥션으로 들어온다.

Amex는 마이그레이션을 3단계로 나누었다.

Stage 1: Connection Migration

가장 인상 깊었던 첫 번째 단계다. 새 플랫폼을 다 만들고 트래픽을 넘긴 것이 아니라, 먼저 GTR을 트래픽 흐름의 중간에 끼워 넣었다.

이때 GTR은 결제 프로토콜을 파싱하거나 비즈니스 로직을 수행하지 않는다. 들어온 커넥션을 그대로 레거시 시스템으로 포워딩(Dumb proxying)할 뿐이다.

솔직히 말해, 나는 이 패턴을 극찬하고 싶다. 과거에 나도 비슷한 레거시 분리 작업을 할 때 API Gateway에 섣불리 라우팅 로직을 넣었다가 장애를 낸 적이 있다. 인프라 요소(Router)를 추가하는 리스크와 비즈니스 로직을 변경하는 리스크는 철저히 분리해야 한다. Amex는 이 원칙을 정확히 지켰다.

Stage 2: Shadow Traffic

GTR이 자리 잡은 후, 실제 프로덕션 트래픽을 복제(Replay)하여 새로운 마이크로서비스 플랫폼으로 보냈다.

금융 시스템에서 Shadow Traffic은 선택이 아니라 필수다. 아무리 QA 환경에서 테스트를 빡세게 해도, 프로덕션의 기상천외한 엣지 케이스를 모두 커버할 수는 없다. 이 단계에서 레거시와 새 시스템의 결과값(Functional discrepancies)을 비교하며 로직의 정합성을 검증했다.

Stage 3: Canary Routing

검증이 끝난 후, GTR에 결제 프로토콜 기반의 라우팅 로직을 추가하여 1%, 5%, 10%씩 점진적으로 라이브 트래픽을 새 플랫폼으로 넘겼다. 이상이 감지되면 즉시 레거시로 롤백하는 구조다.

두 번째 마이그레이션: K8s에서 K8s로

새 플랫폼이 안정화된 후, 이들은 기존 쿠버네티스 환경에서 완전히 새로운 쿠버네티스 환경으로 넘어가야 하는 상황에 직면했다. 네트워크, 보안, 운영 프랙티스가 크게 바뀌어 In-place 업그레이드가 불가능했기 때문이다.

Hacker News에서 이 대목을 두고 한 유저가 남긴 댓글이 압권이다.

“Cmd+F ‘Kubernetes’. Oh Jesus Christ.”

격하게 공감한다. 쿠버네티스를 운영해 본 사람이라면 클러스터 대규모 업그레이드나 마이그레이션이 얼마나 고통스러운지 알 것이다.

Amex는 여기서 첫 번째 마이그레이션 때 구축해 둔 GTR을 다시 활용했다. 이번에는 외부 TCP 트래픽이 아니라 내부 gRPC 통신에 대해 Envoy Proxy와 커스텀 컨트롤 플레인을 이용해 멀티 리전 카나리 라우팅(Multi-region canary routing)을 수행했다. IaC(Infrastructure-as-Code)를 통해 새 환경을 완벽히 동일하게 구성하고, 트래픽을 리전 단위로 스위칭하며 무중단 이전을 완료했다.

Hacker News의 반응과 나의 생각

이번 케이스를 두고 커뮤니티에서는 꽤 흥미로운 토론이 오갔다.

1. 마이크로서비스로 Latency SLA를 어떻게 맞췄을까? 한 HN 유저는 결제망처럼 지연 시간에 민감한 시스템이 모놀리스에서 마이크로서비스로 전환했는데도 SLA를 충족했다는 점에 놀라워했다. 개인적인 생각으로는, Amex가 Closed-loop 네트워크(발급사와 매입사가 동일한 구조)를 가지고 있어 외부 네트워크 홉(Hop)이 적다는 점이 크게 작용했을 것이다. 또한 내부 통신을 gRPC로 최적화하고 GTR을 C++나 Go 같은 고성능 언어로 타이트하게 짰을 확률이 높다.

2. 인프라의 본질에 대한 뼈있는 농담 또 다른 유저는 이렇게 말했다.

“이 모든 엄청난 인프라와 고된 작업이, 결국 감사(Auditing)를 쉽게 하기 위해 한 숫자에서 다른 숫자를 아주 조심스럽고 정확하게 빼는(Subtract) 작업일 뿐이라는 게 참 재밌네요.”

이것이 금융 IT의 본질이다. 비즈니스 로직 자체는 ‘A 계좌에서 잔액 차감, B 계좌에 잔액 추가’로 끝날 만큼 단순할지 모른다. 하지만 그것을 전 세계에서 초당 수만 건씩, 0.1초 이내에, 단 하나의 유실도 없이, 분산 시스템 환경에서 멱등성(Idempotency)을 보장하며 처리하게 만드는 것. 그것이 바로 우리가 분산 라우터, 섀도우 트래픽, 쿠버네티스, Envoy를 도입하며 피땀을 흘리는 이유다.

총평 (Verdict)

Amex의 이 아키텍처는 일반적인 스타트업이나 트래픽이 적은 서비스에는 명백한 오버엔지니어링(Over-engineering)이다. 하지만 글로벌 결제 게이트웨이 수준의 시스템에서는 교과서로 삼아도 좋을 훌륭한 레퍼런스 다.

특히 내가 가장 높게 평가하는 부분은 롤백을 1급 시민(First-class capability)으로 대우했다는 점 이다. GTR을 통한 중앙 집중식 트래픽 제어는 언제든 문제가 생기면 버튼 하나로 레거시로 돌아갈 수 있는 심리적, 기술적 안전망을 제공했다.

결국 대규모 마이그레이션을 성공시키는 것은 최신 기술 자체가 아니라, 실패를 가정하고 시스템을 설계하는 ‘규율(Discipline)‘과 점진적으로 나아가는 ‘인내심(Patience)‘이다.

---

References:

• 원문: Migrating the Payments Network, Twice - American Express Engineering
• Hacker News 토론: HN Thread (47483830)