13.6.5.2 블루 그린(Blue-Green) 배포 방식의 핫-스와핑(Hot-swapping) 및 V1-V2 파이프 우회 전술
운영 중인 파이프라인의 단일 노드 바이너리(.so)를 교체하다가 과거의 기억(State Context)이 증발하여 깡통이 돼버릴 위험(13.6.5.1장 참조)을 회피하기 위해, 아키텍트는 쩨쩨한 심장부 수술을 포기하고 군단 단위의 클론(Clone) 교체 전술을 꺼내 들어야 한다.
다운타임(Downtime) 0.001초조차 허용되지 않는 현금 채굴망(초단타 금융 매매, 자율주행 관제망)에서는 새로운 Yolo 모델(V2)을 띄우기 위해 기존 모델(V1)의 파이프를 파괴하거나 정지(Pause)시키지 않는다.
Zenoh-Flow 선언적 매니페스트를 뒤흔들어, 망의 한쪽에선 구버전 시스템(Blue)이 죽을 때까지 트래픽을 처리하게 하면서, 동시에 다른 쪽에 신버전 시스템(Green)을 부화시켜 조용히 라우팅 밸브를 틀어버리는 궁극의 인프라 기만술, 블루-그린(Blue-Green) 핫-스와핑(Hot-Swapping) 런북을 설파한다.
1. 평행 우주의 창조: 스웜 네트워킹의 다중 인스턴싱
기존의 방식은 V1을 끄고 V2를 켜는 무식한 리플로이(Re-deploy)였다면, 블루-그린 체제에서는 마스터 데몬이 기존 파이프라인 UUID_Blue_V1 을 건드리지 않은 채, 완전히 독립적인 두 번째 파이프라인 UUID_Green_V2 를 허공(혹은 새로운 클라우드 컨테이너 팜)에 통째로 띄워버린다(Instantiating Parallel Universe).
문제는 두 파이프라인이 하나의 소스(카메라 센서)를 취해야 한다는 것이다. V1과 V2 데몬은 모두 Source 포트를 물어버리려 경합을 벌인다.
이때 하드 리얼타임 아키텍트는 하드웨어 인터럽트단의 I/O 충돌을 막기 위해 퍼블리셔 분기(Fork) 멀티캐스트 전술을 쓴다. Source 노드에서 생성된 데이터(zflow::Data)가 V1 파이프의 배관(Link)으로 스며드는 동시에, Zenoh-Flow의 마스터 스케줄러가 데몬 레벨에서 V2 파이프라인의 입구로도 똑같은 데이터를 복제 사출(Shadow Forking) 해버린다.
# [블루그린 데이터 복제 우회 V1->V2 런북]
links:
# 낡은 V1 시스템 (현재 실탄을 쏘아 액추에이터를 움직이는 주 시스템)
- from: { node: "Camera_Node", output: "RawFrame" }
to: { node: "Yolo_V1_Operator", input: "Image_In" }
# 새로운 V2 시스템 (새로 띄워졌지만, 데이터만 집어삼킬 뿐 실제 모터 제어는 하지 않는 그림자)
- from: { node: "Camera_Node", output: "RawFrame" }
to: { node: "Yolo_V2_Operator", input: "Image_In" }
2. 웜업(Warm-up) 관찰과 섀도우 연산(Shadow Computing)
이 기괴한 위상 속에서, V2(Green) 노드는 GPU 할당과 모델 로딩 등 길고 고통스러운 웜업(Warm-up) 패널티를 혼자서 감내한다. 방파제 벽 뒤에서 파이프라인이 켜지는 동안에도 앞방의 V1(Blue)은 카메라 프레임을 받아 멈춤 없이 60FPS로 자율주행을 지속한다(Zero Downtime).
수십 초 후, V2의 웜업이 끝났다. 하지만 V2는 이빨을 드러내지 않는다. (섀도우 컴퓨팅 상태)
V2는 데이터를 받아 연산을 태우고 결과를 뱉어내지만, 관리자는 V2의 최종 싱크(Sink)단 밸브를 모터 액추에이터에 잇지 않고 가짜 더미(Dummy/Dev/Null)로 밀어버려 허공에 연산 결과를 폐기한다.
이 기간 동안 인프라 관제탑은 V1과 V2의 연산 결괏값을 비교 대조한다. 만일 V2 Yolo 모델이 버그를 먹고 세그먼트 충돌을 일으키거나 레이턴시가 500ms 이상으로 지연되더라도 시스템 장애는 절대 발생하지 않는다. V1이 생존하여 차량을 몰고 있기 때문이다. V2는 완벽하게 격리된 ’진공관 속의 시험관’이다.
3. 라우팅 시프트(Routing Shift)와 구세대(Blue) 말소
V2가 충분한 시간 동안 과거의 연산 컨텍스트(State)를 쌓고 안정성을 입증했다면, 이제 왕위를 찬탈해야 한다.
Zenoh-Flow 관리자는 거대한 라우터망의 경로 테이블(Link Mapping)을 트위스팅(Twisting)한다.
# [왕위 교체의 찰나, Sink 배관 스위칭 런북]
# 1. 엑추에이터 모터(Sink)로 가는 V1 배관의 입력 스위치를 막고, V2의 배관으로 우회 시킨다.
zfctl update-link actuator_sink --from Yolo_V2_Operator
# 2. V2가 실권을 장악한 것을 확인한 직후,
# 낡고 늙어버린 V1 파이프라인 인스턴스의 모가지를 잘라(Destroy) 메모리를 수거한다!
zfctl destroy ${UUID_BLUE_V1}
밸브가 스위칭되는 그 1밀리초의 타임 윈도우(Time Window) 동안 데이터 유보는 단 하나도 발생하지 않았다.
수동적인 라이브러리 바이너리 교체(dlopen 핫스왑)가 남기는 상태 초기화의 공포를 극복하기 위해, 아키텍처는 무식하리만치 무거운 완벽한 평행 우주(Multi-Pipeline Replication) 복제술을 발동한 것이다.
메모리 위에는 두 개의 태양이 뜨고, 구세대의 태양이 스스로 빛을 잃을 때까지 자원을 갈아 넣어(Resource Burn-rate) 안정성의 절대무적(Infallibility)을 증명하는 전술. 하드 리얼타임 데이터 플로우 세계관에서 배포(Deployment)의 극의는 코딩이 아니라 공간 라우팅의 교묘한 협잡에 있다.