쉐도우 무중단 상태 저장 마이그레이션 프레임워크

논문은 쿠버네티스에서 인메모리 상태를 유지하는 마이크로서비스, 특히 StatefulSet이 관리하는 파드의 마이그레이션 문제를 다룬다. 기존 MS2M 프레임워크는 컨테이너를 CRIU로 체크포인트하고, 메시지 큐를 이용해 상태를 재구성함으로써 전통적인 VM 기반 마이그레이션보다 다운타임을 크게 줄였다. 그러나 StatefulSet은 동일 Ordinal을 가진 파드가 동시에 존재할 수 없다는 제약 때문에, 체크포인트 복구 단계에서 파드를 중단하고 새로 생성해야 했으며, 이 과정에서 평균 38.5초의 서비스 중단이 발생했다. 또한 체크포인트를 OCI 이미지로 패키징해 레지스트리로 푸시·풀하는 과정이 5.4초 정도 추가 비용을 발생시켰다. SHADOW는 이러한 두 가지 병목을 해소하기 위해 세 가지 주요 설계를 제시한다. 첫 번째는 쿠버네티스 오퍼레이터 기반 구현이다. ‘StatefulMigration’이라는 CRD를 정의하고, 컨트롤러‑런타임을 이용해 선언형 상태 머신을 구현한다. 사용자는 마이그레이션 의도만 CR에 기술하면 오퍼레이터가 체크포인트 생성, 전송, 복구, 메시지 재생, 최종 전환까지 전 과정을 자동으로 조정한다. 단계별 진행 상황과 소요 시간을 CR 상태에 기록해 가시성을 제공하고, 재시도 로직을 내장해 일시적 오류에 강인하다. 두 번째는 ShadowPod 전략이다. 체크포인트를 만든 뒤, 대상 노드에 ‘-shadow’라는 이름의 파드를 생성한다. 이 파드는 StatefulSet 소유가 아니므로 동일 Ordinal을 공유해도 충돌하지 않으며, 원본 파드와 동시에 실행된다. 복구된 ShadowPod은 CRIU 체크포인트에 포함된 프로세스 상태를 그대로 유지하므로 즉시 Ready 상태가 되며, 서비스 라벨을 동일하게 설정해 쿠버네티스 Service가 트래픽을 두 파드에 동시에 라우팅한다. 이렇게 하면 복구와 메시지 재생이 병렬로 진행돼 다운타임이 발생하지 않는다. Deployment 관리 파드에서는 이 단계만으로 충분히 무중단 마이그레이션이 완성된다. 세 번째는 StatefulSet 전용 ‘Identity Swap’ 및 ‘ExchangeFence’ 메커니즘이다. ShadowPod이 독립적으로 서비스하더라도 StatefulSet이 제공하는 PVC 바인딩, 순차적 스케일링 등 관리 기능을 상실한다. 이를 보완하기 위해 ShadowPod을 다시 체크포인트하고, 동일 이미지로 StatefulSet이 관리하는 새로운 파드를 원본 이름(예: consumer-0)으로 생성한다. 이때 ExchangeFence를 적용해 메시지 교환을 일시적으로 차단하고, 버퍼 큐에 모든 인입 메시지를 저장한다. 이후 원본과 새 파드의 큐를 완전히 비우고, 버퍼 큐의 메시지를 새 파드에 전달함으로써 메시지 손실·중복 없이 서비스 전환을 마친다. 이 과정은 최종 단계에 추가 지연을 초래하지만, StatefulSet 관리 하에 완전한 무중단 마이그레이션을 보장한다. 전송 효율성도 개선한다. 기존은 체크포인트를 OCI 이미지로 만들고 레지스트리 푸시·풀하는 방식이었지만, SHADOW는 두 가지 대안을 제공한다. 첫째, ms2m‑agent DaemonSet을 각 워커 노드에 배치해 오퍼레이터가 레지스트리 푸시 작업을 에이전트에게 위임한다. 둘째, ‘Direct’ 모드에서는 소스 노드의 에이전트가 체크포인트를 스트리밍으로 직접 대상 노드에 전송해 레지스트리 경유를 완전히 생략한다. 논문 실험에서는 네 가지 구성(Sequential, ShadowPod‑D‑Reg, ShadowPod‑Swap, Direct) 중 레지스트리 기반 전송만을 평가했으며, 280번의 마이그레이션(4가지 구성 × 7가지 메시지 속도) 결과 ShadowPod 전략이 복구 단계 시간을 최대 92% 단축하고, 전체 마이그레이션 시간을 최대 77% 감소시켰다. 특히 StatefulSet‑Swap 구성에서 ExchangeFence를 적용한 경우 0% 메시지 손실을 유지하면서 서비스 다운타임을 완전히 없앴다. 이러한 결과는 쿠버네티스 기반 상태 저장 마이크로서비스가 클라우드·엣지 환경에서 동적으로 재배치될 때, 기존의 순차적 stop‑recreate 방식보다 훨씬 효율적이며 운영 복잡성을 크게 낮춘다.