19.7 무중단 배포 및 안전한 릴리스 전략

19.7 무중단 배포 및 안전한 릴리스 전략

과거 단일 계층(Monolithic) 서버 환경에서는 정기 점검을 통한 서비스 중단(Downtime)이 일반적이었다. 하지만 현대의 분산 네트워크 생태계, 특히 로보틱스 및 IoT 기반의 상시 운영 시스템에서는 배포 과정으로 인한 서비스 중단이 비즈니스의 심각한 손실을 초래할 수 있다.

예를 들어, 글로벌 자율주행 물류 창고 네트워크에서 업데이트를 위해 시스템이 중단되거나 펌웨어의 결함으로 인해 전체 장비의 통신망이 단절된다면 대규모 물류 장애가 발생하게 된다. 따라서 시스템 운영 시 서비스의 연속성을 보장하면서 코드를 교체하는 무중단 배포(Zero-Downtime Deployment) 전략의 적용이 필수적이다.

이 장에서는 어플리케이션의 가용성을 유지하면서 버전을 갱신하는 3가지 핵심 무중단 배포 기술과 그 적용 방안을 살펴본다.

1. 무중단 배포를 위한 3대 핵심 라우팅 및 관리 전술

  1. 롤링 업데이트 (Rolling Update): 전체 서비스 인스턴스를 한 번에 교체하지 않고, 점진적으로 이전 버전의 인스턴스를 새로운 버전으로 교체하는 방식이다. 배포 중에도 일정한 서버 가용 개수를 보장할 수 있어 대규모 트래픽 환경에 적합하다.
  2. 블루-그린 배포 (Blue-Green Deployment): 기존 프로덕션 환경(Blue)과 동일한 자원 크기를 갖춘 새로운 환경(Green)을 사전에 구축하여 테스트를 완료한 후, 로드 밸런서의 라우팅 연결만 변경하여 트래픽을 일시에 전환하는 방식이다. 데이터베이스 스키마와 같은 파괴적인 변경 시 백엔드 전환에 주로 활용된다.
  3. 카나리아 배포 (Canary Release): 신규 버전의 결함 가능성을 최소화하기 위해, 소규모 배포 대상(Canary)에게만 우선적으로 새로운 펌웨어나 소프트웨어를 배포하는 방식이다. 정상 진입 여부를 관명한 뒤 대상을 넓혀가며, 에지(Edge) 환경처럼 대규모 원격 디바이스 배포 시 중요한 안정성 확보 역할을 한다.

이어지는 세부 절에서는 쿠버네티스(Kubernetes) 오케스트레이션과 헬름(Helm) 명세, 그리고 프로메테우스(Prometheus) 지표 모니터링을 결합하여 이 세 가지 전략을 안전하고 효율적으로 구현하는 방법을 구체적인 런북(Runbook) 형태로 전개한다.

2. Rolling Update를 활용한 Zenoh Pub/Sub 트래픽 손실 최소화

롤링 업데이트(Rolling Update)는 쿠버네티스(Kubernetes)에서 인스턴스 버전을 교체할 때 기본적으로 활용되는 안정적인 배포 전략이다. 이 구조에서는 기존 애플리케이션 파드(Pod)들을 일관되게 유지하면서, 점진적으로 추가적인 파드를 실행시켜 트래픽을 이전한다.

2.1 트래픽 손실 방지를 위한 롤링 타격 전술

업데이트 과정에서 가장 주의해야 할 단계는 ‘기존 파드의 종료’ 시점이다.
시스템에 종료 명령(SIGTERM)이 전달되었을 때, Zenoh 라우터가 처리 중이던 메시지 전송 세션이 강제로 끊기게 되면 패킷 손실이 발생할 수 있다.

2.1.1 우아한 종료(Graceful Shutdown)와 사전 통제

종료 명령이 하달되더라도 즉시 프로세스를 소멸시키지 않고, 연결된 통신 세션을 온전히 마무리할 수 있는 ’유예 시간(Grace Period)’을 확보해야 한다.

## zenoh-router-deployment.yaml
spec:
  template:
    spec:
      containers:
      - name: zenoh-router
        image: zenoh:v2.0
        # 유예 시간 할당: 30초
        terminationGracePeriodSeconds: 30 
        
        lifecycle:
          preStop:
            exec:
              # SIGTERM 전송 전, 더 이상의 새로운 커넥션을 받지 않고 
              # 지연 없이 기존 패킷을 처리하도록 프로세스 안전 종료 대기
              command: ["sh", "-c", "sleep 10 && zenoh-admin close-session --soft"]

preStop 훅(Hook)의 설정은 안정성에 있어 매우 중요한 역할을 수행한다. 쿠버네티스의 로드밸런서(Service)가 엔드포인트 목록에서 파드의 IP를 완전하게 삭제하는 시간 동안 라우터는 대기해야 하며, 신규 트래픽의 전송을 방지하면서 기존 세션을 종료(close-session)한다.

2.1.2 가용성 제어를 위한 Surge와 Unavailable 비율의 설정

안정적인 업데이트를 보장하기 위해 파드의 대체 속도를 정밀하게 관리해야 한다. 리소스 한계를 제어하고 서비스 품질을 보호할 수 있는 제한 속성이 필요하다.

## Deployment Spec
  strategy:
    type: RollingUpdate
    rollingUpdate:
      # 업데이트 도중, 사용 불가능한 상태의 파드가 없도록 0으로 설정
      maxUnavailable: 0  
      
      # 배포 시, 전체 파드의 25% 비율만큼 수용 한도 내에서 초과 생성
      maxSurge: 25%

maxUnavailable: 0 설정은 고가용성이 요구되는 시스템 환경에서 롤링 업데이트의 핵심 방어선이 된다. 이는 기존 요청 대수 이하로 가용 서비스의 수치가 낮아지지 않도록 보장하여 연산 자원과 SLA(Service Level Agreement)를 지속적으로 보전한다.

이러한 정책의 구현을 통해, 에지 디바이스나 로보틱스 시스템들은 Zenoh 라우터 인스턴스들의 버전 교체 여부를 인지하지 못한 채 단절 없는 통신 환경을 보장받을 수 있다.

3. Blue-Green 배포를 통한 클라우드 백엔드 노드의 안전한 버전 전환

데이터베이스 스키마가 전면적으로 개편되거나 Zenoh 프로토콜 메시지의 코어 헤더 구조가 고의적으로 수정되는 상황(Breaking Change)에서는 배포 전략에 각별한 주의가 요구된다.
기존의 롤링 업데이트 방식은 구 버전의 라우터(v1.0)와 신 버전의 라우터(v2.0)가 하나의 클러스터 내에 공존하는 시간이 발생하게 된다. 이 경우, 두 라우터 아키텍처 간의 연결 오류 및 데이터 정합성 충돌의 위험이 동반될 수 있다.

따라서 완전히 변경된 프로토콜이나 대규모 업그레이드 배포에서는 기존 환경을 고립시킨 채 독립적으로 운영하는 블루-그린(Blue-Green) 배포 아키텍처 도입이 적합하다.

3.1 사전 모의 테스트를 포함하는 블루-그린 배포 단계별 런북

신규 배포와 동일한 전제 조건의 컴퓨팅 자원을 할당하여 환경을 독립적으로 2배 구축한다.

3.1.1 단계: 독립된 신규 환경(Green)의 구축

현재 운영 중인 서비스 망(Blue, v1.0 환경)의 설정과 통신을 유지하라.
쿠버네티스(Kubernetes) 환경 내부에 별도의 네임스페이스(Namespace)나 식별된 라벨(Label)의 영역을 할당하고, 신 버전이 탑재된 라우터 클러스터(Green, v2.0 환경)를 정상 배포한다.

## Blue-Green의 그린 배치 명세(Deployment) 예시
apiVersion: apps/v1
kind: Deployment
metadata:
  name: zenoh-router-green
  labels:
    app: zenoh
    color: green # 신규 대상을 구별하는 식별자
spec:
  replicas: 10
  template:
    metadata:
      labels:
        app: zenoh
        color: green
    spec:
      containers:
      - name: zenohd
        image: zenoh:v2.0 # 스키마 변경 사항을 품은 신규 이미지

3.1.2 단계: 신규 환경 사전 품질 검증

새롭게 배포된 그린(Green) 환경의 부팅 및 연결이 완료되면, 운영 레벨로 트래픽을 돌리기 전에 kubectl port-forward 등의 포트 포워딩이나 전용 접속 루트를 활용해 테스트 파편을 전송하고 디버깅한다.
해당 시스템이 정합성 문제없이 DB 구성을 획득하고 안정적으로 세션을 구축하는지 충분히 사전 검증한다.

3.1.3 단계: 로드밸런서 라우팅 전환(Traffic Switching)

사전 품질 요소의 검증이 마무리되었다면, 서비스 연결 설정을 명시하는 리소스 오브젝트인 서비스(Service)의 대상 라벨을 일괄 변경(Patch)하여 라이브 망의 목적지를 전환한다.

## LoadBalancer Service의 대상 오브젝트 전환
apiVersion: v1
kind: Service
metadata:
  name: zenoh-public-lb
spec:
  selector:
    app: zenoh
    # 기존 통신망인 blue를 green으로 수정하여 목적지를 실시간 전환한다.
    color: green

API 명령으로 해당 정보가 등록됨과 동시에 로드 밸런서는 이전 버전(Blue)으로 향하던 채널링 라인(Endpoint) 연결을 해제하고 검증된 신규 버전(Green) 노드 클러스터를 향해 모든 요청을 연결한다.

3.1.4 단계: 신속한 환경 복원(Rollback) 구조 확보

전환이 이루어진 직후, 서버 시스템 환경에서 불가피한 장애 및 오류 지표가 상승할 우려를 대비해야 한다. 문제 식별 시, 변경된 위의 대상 라벨 값을 다시 color: blue로 전환함으로써, 즉각적인 서비스 복원 로직을 수행할 수 있다 (Rollback 속도 최적화 보장). 무중단 전환 이후에도 추가적인 모니터링을 진행하고 서비스가 안정적으로 안착되었다면 이전 낡은(Blue) 환경 자원을 제거하여 완전하고 부드러운 전환을 달성할 수 있다.

4. Canary(카나리아) 릴리스를 이용한 에지 디바이스 점진적 업데이트

클라우드 플랫폼 인프라 환경은 즉각적인 컴포넌트 교체나 전환 등 유동성이 높으나, 에지 환경(로봇, 드론, 센서기기) 상호의 OTA 배포 파이프라인의 적용 과정은 상대적으로 신중을 기해야 한다.
잠재적 결함을 지닌 펌웨어 패키지를 전체 장비에 일시 전송하는(Big-Bang Release) 접근 방식은 서비스 중단을 넘어 시스템 영구 마비라는 재난적 상황을 초래할 여지가 크다. 장비 결함의 피해 복구를 위해 디바이스 회수 등에 드는 높은 비용과 대기 시간을 야기할 수 있기 때문이다.

이러한 위험성을 완화하고 리스크를 최소화하기 위해 점진적 배포의 모델로서 소수 대상에게 먼저 패킷을 할당하여 상태 검증을 수행하는 카나리아(Canary) 릴리스 전략을 적용한다.

4.1 통제된 환경에서의 점진적 카나리아 배포 전략 (Argo Rollouts 활용)

카나리아 배포는 전체 디바이스 풀(Pool)에서 선별된 극소수의 노드를 차출하여 신규 소프트웨어 구성 요소를 설치, 지속적인 모니터링 프로세스를 확보하는 전략이다.

4.1.1 단계: 선별된 소규모 테스트 그룹 배포

아르고 롤아웃(Argo Rollouts) 기능과 같은 트래픽 점진 배포 컨트롤러를 통해 신규 버전 이미지(v3.0) 패키지가 로드될 경우, 사전 구성된 테스트 구역으로 지정된 소수 노드(약 1% 비율)에게만 네트워크 업데이트 이벤트를 허용한다.
나머지 주요 기기 자원(99% 비율)은 기존 버전 펌웨어(v2.0)로 구동을 변함없이 유지한다.

## Argo Rollouts 활용 매니페스트 예시 (에지 제어 컨트롤러 점진 배포)
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: zenoh-edge-controller
spec:
  replicas: 10000 
  strategy:
    canary:
      steps:
      - setWeight: 1          # 1% 허용치에 우선 배포를 진행한다.
      - pause: {duration: 1h} # 1시간 간격으로 시스템의 정상 작동 여부를 모니터링한다.
      - setWeight: 10         # 이상 증세가 없을 경우 10% 단위로 수용치를 재확장한다.
      - pause: {duration: 6h} # 확장된 단위 모델 내에서 관망 유지 상태를 적용한다.
      - setWeight: 100        # 완전한 안정성 판별 시 모든 스위치를 완료 조치한다.

4.1.2 단계: 자동 모니터링 분석 및 오류 감산 체계 구축 (Prometheus Alert 통합)

지정된 관찰 시간 동안 모니터링 지표 검사를 자동화한다. 미리 배포 컨트롤 시스템에 연동된 프로메테우스의 지표 한계치 기준을 정의한다.

  • 안정성 자동 분석 판별 기준: 신규 배포 기기 내 패킷 단절(Drop Rate)이 기존 기기 보다 +5% 이상 크게 높게 도출될 때.
  • 측정된 메트릭 요소를 K8s 모니터링 기능이 포착했을 경우, 즉시 시스템 알람 전송과 함께 카나리아 롤아웃 단계를 즉각 철수, “롤백(Rollback)” 상태로 전환 처리하게 된다. 개발 또는 배포 운영진의 별도의 개입이나 허가 없이 오류 시스템을 원상 복구 시킬 수 있다.

4.1.3 단계: 순차적 대역폭 램프 업(Ramp-up)

1시간의 1차 정상 판별 후 아무런 장애나 오류 율이 상승하지 않았다면 비로소 다음 구간인 10%의 범주로 확산 인가(Weight)를 수행한다.
이 같은 무선 OTA의 배포 분산 모듈화는 한 번에 물리적인 막대한 부스트 대역폭을 서버 및 노드 간 소비하는 분산 트래픽 충돌 피해를 무마시키는 완충 스위치 기전 또한 달성할 수 있다.

5. 자동화된 롤백(Rollback) 메커니즘을 통한 신속한 장애 복구

아무리 완벽한 CI 린팅, 완고한 K8s 롤링 업데이트, 그리고 겁에 질린 카나리아(Canary) 배포를 거쳤더라도 “현실의 데이터“는 예측할 수 없다. 로봇들이 실제 현장 상황에서 발생하는 예상치 못한 페이로드 헤더나 이상 센서 값이 새로 배포된 Zenoh 분석 컨테이너 내부의 파서(Parser)를 건드려 1초당 10번씩 K8s 파드를 연속해서 재부팅 시키는 “CrashLoopBackOff” 소용돌이에 휘말려 들 수 있다.

장애를 인지하고 나서, 자던 개발자가 일어나 노트북을 열어 이전 소스코드 커밋(Commit) 번호를 찾아 구버전을 다시 컴파일하고 재배포하기까지 2시간이 걸렸다면, 당신의 직장은 파산할 것이다. 배포 철학의 최후의 보루는 인간을 배제한 “자동 즉결 롤백(Automated Instant Rollback)” 기전이다.

5.1 [인스펙션] 단일 소스 기반 복원 체계 런북

우리가 앞서 19.3.3에서 숭배했던 “GitOps” 사상이 이 절체절명의 수렁 속에서 진가를 뿜어 발한다. 오직 상태의 정의를 K8s나 외부 관제망 대신 단일한 텍스트 저장소(Git) 하나에 저장해 두었던 철학이 보답하는 순간이다.

5.1.1 단계: 깃옵스 사령관(ArgoCD)의 히스토리 보존력

ArgoCD 나 K8s 컨트롤 플레인 엔진은 컨테이너 매니페스트 설정이 바뀐 적이 있을 때마다 (v1.0 -> v1.5 등), 낡은 상태 버전을 버리지 않고 내부 데이터베이스 구석에 ReplicaSet 기록 덩어리로 박제해 두고 있다. 이것이 과거로 시간 여행을 떠나기 위한 티켓이다.

관제탑(Dashboard) 상단 파이프라인 모니터에 에러 임계치가 터져서 알람(Fire)이 들어온다.

5.1.2 단계: 수동 롤백 1단계 수행 (Imperative Revert)

만약 반수동 롤백이 필요하다면 Helm 차트의 시간 릴리즈 히스토리를 불러와 과거(Revision N) 로 회귀하라.

## 지금 배포한 최신 버전(v2.0) 라우터가 Crash를 뿜는가?
## 가장 안정적이었던 과거 직전 역사 번호(예: Revision 5)로 돌려버린다.
helm rollback zenoh-cloud-router 5

명령을 엔터(Enter) 하는 순간 찰나의 지연도 없이, K8s는 최신 v2.0 파드들에게 즉시 삭제 처리하고, 저장소에 기록된 v1.9 컨테이너 이미지를 신속하게(1초 이내) 구동하여 복구한다. 이미지 파일은 이미 로컬 노드 캐시 볼륨에 다운로드되어 있으므로 롤오버 부팅 속력은 극한에 달한다.

5.1.3 단계: Git Revert를 활용한 선언적 복원 (Declarative)

더 우아한 방식은 Git 창고 자체를 되감기 하는 것이다.
CLI 수동 조작 대신 인프라 소스 저장소(Infra Repo)에서 치명적이었던 커밋 조각을 날려버리는 git revert <commit-hash> 를 팀리더가 실행하여 마스터에 머지(Merge)한다.

## 장애를 발생시킨 방금의 커밋을 영원히 역사에서 지우고 푸시!
git revert abc1234
git push origin main

그러면 다시 19.3.3장의 ArgoCD 동기화 에이전트이 이 Git 폴더를 감시하다가 “저장소의 버전이 이전으로 복구되었음을 확인하고” 를 알아채고, 스스로 자동으로 인프라 상태를 롤백 동기화(Sync)시킨다.

인간 개발자는 그제야 커피를 마시며 천천히 로컬 PC에 떨어진 코어를 분석하고 버그를 잡아내면 될 일이다. 장애의 파편은 3분 만에 치워졌고 시스템은 안전하게 흐른다. 이렇듯 진정한 배포 파이프라인의 완성도는, 에러 발생 자체를 막으려는 병적인 고집이 아니라 에러가 터졌을 때 얼마나 경이로운 속도로 시스템을 어떻게 복구하느냐(Resilience)에 달려있다.