19.9 배포 후 자동화된 상태 검증 및 모니터링/시각화 연동

19.9 배포 후 자동화된 상태 검증 및 모니터링/시각화 연동

CI/CD 배포 파이프라인의 최종 단계에서 단일 쿠버네티스 포트 상태가 ‘생성’ 판정의 기록(Success)을 출력했다고 하여 시스템 적용의 완수에 대한 완전한 안전성을 확보했다고 볼 수는 없다. 오케스트레이션 엔진이 컨테이너의 물리적 프로세스를 성공적으로 구동하였다고 치더라도, Zenoh 코어 라인 시스템의 런타임 특성상 트래픽 처리 대기 상태의 불능 장애나 락업(Lock-up, 데드락)이 발생된다면 이는 본질적으로 시스템 장애의 은폐에 해당한다.

엔터프라이즈 레벨의 안정성 보장에 있어 ’배포 확인의 원칙(Deploy Completion)’의 진정한 의미는, 단순한 컨테이너 인프라 객체 생성 로그가 아니라 “신규로 기동 된 애플리케이션 컴포넌트들이 비즈니스 연산 로직을 장애 없이 제어하고 트래픽 패킷 율을 보장할 수 있는가?“가 외부 모니터링 시각화 관제 시스템과 융합하여 상호 지표로서 증명되는 단계를 가리킨다.

graph TD
    subgraph "배포 후 자동화 검증 루프 (Post-Deployment Verification)"
        Deploy[1. K8s / K3s 파드 컴포넌트 생성 요청]
        Liveness[2. Health Check<br/>Liveness & Readiness 지속 검사]
        Prom[3. 시스템 관제 등록<br/>Prometheus Auto Discovery]
        Dash[4. Grafana<br/>형상 이벤트 및 배포 로그 Annotation]
        Roll[5. AlertManager<br/>경계치 오류 시 Alert 규칙 통보]
    end

    Deploy -->|컨테이너 시작 프로세스| Liveness
    Liveness -->|트래픽 인가 안정 스위치 개방| Prom
    Liveness -.->|검출 제한치 도달 시 서비스 재기동| Deploy
    Prom -->|Metric Pulling 지속화| Dash
    Dash -->|Error 임계 수치 상회 트리거 전송| Roll
    Roll -->|Auto-Revert 기반 파이프라인 중단 파라미터 호출| Deploy

본 챕터에서는 위와 같은 피드백 관측 메커니즘을 상세화하여 기계 중심적 자동 복원 방호 기술을 다룬다.
쿠버네티스의 자체 탑재된 프로브 탐침을 통한 어플리케이션 신체적 모니터링 강제, 시스템 재동기화 후 즉시 프로메테우스 통계 지표에 엮이는 대상 메트릭 인가 절차, 더 나아가 Grafana 등의 현황 파악 대시보드 뷰 체계 안에 자동 이벤트를 송출시켜 ‘선언적 인프라 시각화’ 체제 통합 모델까지 시스템 적인 완전한 모듈화 사례들을 기술한다.

1. Liveness 및 Readiness Probe를 이용한 자동화된 상태 검증

단일 쿠버네티스 데몬 프로세스나 혹은 에지 자원의 환경 통제자 체계는, 단순히 파드 OS 컨테이너 안의 기본 쉘 런타임 프로세스가 비종료(Running) 상태로 존재함만 관측할 뿐 앱의 런타임 특성상 데드락이나 기능 이상은 확인하지 못하는 제한적 시스템 한계를 지닌다.
Zenoh 컴포넌트 C 언어 플러그인 계열 메모리 누수나 무한 루프 등 로직 이상으로 애플리케이션 내의 점유 CPU나 연산 상태가 허용치 초과 락업(Lockup)이 발생했을 시, 쿠버네티스는 이를 정상 구동으로 판단하여 로드밸런싱 인가 트래픽을 지속 공급하며 결과적으로 네트워크 응답 지연 발생이나 병목 대칭 마비의 심층 전파 사태로 이어지게 관리할 우려가 따른다.

위와 같은 구조의 맹점을 원천적으로 극복할 수 있도록 운영 배포 선언문에 반드시 어플리케이션 상세 헬스 체크용 두 개의 분리된 프로브(Probe) 요소를 정의하도록 강제해야 한다.

1.1 Liveness Probe (애플리케이션의 동작 한계 상태 타격 검증)

Liveness 프로브 장치는 “대상 애플리케이션의 프로세스 교착 가능성 판단과 즉각적 컨테이너 재가동 복원 트리거를 당길 것인가?“를 진단한다.

대다수 Zenoh 라우터 체인은 내부 8000포트(REST 기반 Admin 인스펙션)를 노출하며 시스템의 현재 작동성을 보장하는 지표를 발산한다. 시스템 엔진에서는 주기적(보통 10초 간격)으로 HTTP 핑을 호출, 제한적 무응답 검증 시 해당 구동 컴포넌트를 강제 단절 후 프로세스를 재스핀 시키는 자동 치유 기능을 세팅해야 한다.

## 파드 설정 yaml 내부
        livenessProbe:
          httpGet:
            path: /info # Zenoh Info 관제 기본 런타임 정보 호스팅
            port: 8000  # API 호스트 및 연결 포트 넘버
          # 컨테이너 구동 기동 시 충분한 시간 지연 대기 기간의 한정 (부팅 프로세스 즉각 차단 충돌 방지 차원)
          initialDelaySeconds: 15 
          periodSeconds: 10       # 일정 주기 체크 단위 지정
          failureThreshold: 3     # 타임아웃 3회의 무응답 한도 연속 초과 시 지연 없는 종료 프로세스 활성화

1.2 Readiness Probe (클라이언트 트래픽의 수용 허용 검증선)

Liveness 검측이 컴포넌트의 단순 생존력 측정을 판가름한다면, 두 번째 Readiness 검사는 “현실의 관제 로드밸런서가 외부 인터넷이나 기기의 인바운드 연결성을 개방해도 충분할 정도로 세션 인프라 시스템 수용의 내부 요건 충족 상태가 완성되었는가?“를 증명하는 핵심 요소이다.

에지 플랫폼으로 론칭된 라우터 클러스터는 전원 재부팅 즉시 패킷을 소화하는 인입 라인이 전개되면 내부 연결 테이블 피어 토폴로지 맵핑 스토리지 지점이 아직 시스템화되지 못한 상태에서 패킷을 잃어버리는 누수 로스타임을 생성한다. 트래픽의 통로 파이프라인의 안전 보장을 위해서 내부 검증 상태까지 충전이 마무리된 인스턴스만이 외부 네트워크 서비스 인가를 수령하도록 한다.

        readinessProbe:
          httpGet:
            path: /info/routers
            port: 8000
          # 라우팅 정보의 검사에 의의, 라우터 망 내 시스템의 Peer 연동 테이블이 
          # 가동 후 일정 상태치 교차 정보를 확인 및 동기 획득 완료된 증표의 판별 유무.
          initialDelaySeconds: 5
          periodSeconds: 5
          successThreshold: 1  # 1회의 상태 응답 회신 성공 기준 인가 시에만 트래픽 진입 허용.
          failureThreshold: 2

두 기종의 런타임 상태 확인 매커니즘 없이는 아무리 고도화된 스위칭 컴포넌트 구조라 한들 인프라 무중단 무손실 배포 전략(Zero-downtime) 체인을 담보하지 못한다. 신규 모듈 배포 교체 중 통제가 결여된 미가동 내부 컨테이너로 잘못된 분산 데이터 라우팅이 진입하여 런타임 오류나 HTTP 502 타임아웃 레이턴시를 양산하는 원인이 될 수 있다. 따라서 인스턴스 자체가 기계적 프로브 검증을 직접 수용 증명하면서 제어 네트워크 망의 연동을 안정화 시키도록 설계 구조화가 완벽하게 다듬어져야 한다.

2. Service Monitor 구성 및 Prometheus와의 자동 통합

운영망이 고도로 복잡하고 규모가 거대한 인프라 배포 관점 환경, 기존 버전 라우터 노드 그룹(v1)과 배포 대상 개선 업데이트 서버(v2)가 현장에 동적인 교체 증감을 보여주고 있을 때, 개별 인스턴스나 로봇 등에서 소모하고 있는 세션 CPU 로드 값 지표나 트래픽 송신 지연 등의 내부 팩트 파라미터를 메트릭 검출 관제 시스템에 관리자가 직접 주소를 기재하고 조작하여 인력 소모적인 수동 시스템 체제로 연결하는 행위는 현대 모델에선 폐기되어야 할 구조이다.

무중단 버전 증감에 따라 추가 배포된 노드의 정보망을 오토 다이나믹 방식의 레코딩으로 직접 포착하며, 동시에 프로메테우스(Prometheus) 백본 서버가 모니터링 정보를 통합 연동할 수 있도록 Service Discovery 기반 패턴 관측 방식을 연계시켜야만 한다.

2.1 선언적 아키텍처 관점의 Prometheus 자동 모니터링 모델 (Operator)

인프라 구성 내 prometheus-operator 생태계가 이미 도입되어 있다면, 전통적인 정적 설정 기입 파일 체계인 prometheus.yml 모델에 수백여 에지 로봇과 물리 타겟 아이피 어드레스(IP Address) 풀 경로를 반복 하드코딩 업데이트하는 고전적인 작업을 피할 수 있다.
해결책으로 모니터링 요소 자체의 수집 대상 기준을 결정하는 ServiceMonitor 타겟팅 정의 명세의 쿠버네티스 커스텀 파일마저 파이프라인 CI망의 인프라 정의 설정 관리로 같이 통합 연계시킨다.

2.1.1 단계: 라우터 인스턴스 측 관찰 가능성(Observability) 확보 노출

일차적 요소로서 구동 배포될 Zenoh 시스템 컨테이너 내부 환경에 프로메테우스 스크래핑 전송 연결 메트릭 도구 모듈(zenoh-plugin-prometheus) 플러그인 연계 시스템 스위치 선언(예를 들어 기본 구성 포트 9090 등) 옵션 파라미터를 사전 제공하도록 한다.

2.1.2 단계: K8s ServiceMonitor 감축 스펙 결합 및 선언 연계

배포 구성 단위인 Helm 차트 혹은 파드 구조 객체에 하단 명시된 내용의 블록 단위를 같이 삽입한다. 이는 클러스터 프로메테우스 오퍼레이터가 관리를 지속 중인 모니터링 정보 통합망 체계 안에서 “가용 상태 관측을 위해, 지정된 런타임 요소 특성 값(Label)을 보유하며 실행 중인 파드들을 발견할 시 능동적 지표 데이터 확보 작업 묶음에 편입할 것(Dynamic Target Discovery & Pull)“을 자동 지시하는 논리적 연결 선언 체계이다.

## service-monitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: zenoh-cloud-monitor
  labels:
    release: prometheus # 오퍼레이터 대상 자동 수집 인가를 명시하는 중요 매핑 트리거
spec:
  # 데이터 모니터링 타겟에 대한 구별자를 속성 지정
  selector:
    matchLabels:
      app: zenoh
      role: backend-router
  
  # 검출 대상 그룹 컴포넌트들의 측정 노출 포트를 연계 지정, 수집 단위 메트릭 타임 인터벌 지정
  endpoints:
  - port: metrics-port # Pod 명세에 지정 노출되어진 라스트 포트의 이름
    path: /metrics
    interval: 15s
    scrapeTimeout: 5s

이렇듯 자동화 모델(ServiceMonitor) 요소를 포함하여 파이프라인 컴포넌트 배포 사이클 안에 병합해 놓게 되면, ArgoCD 혹은 Flux 모델을 통한 컨테이너 배포 스케일 확장 발생 시 혹은 롤아웃 모델 작동 시점에 인프라 팀 개발 관리자가 부수적인 모니터링 서버 망 개입을 실시하지 않아도 프로메테우스 인프라 TSDB(시계열 데이터 저장 정보) 레거시 내부로 신규 객체 타겟 매핑의 유기적인 수집 연동 정보 관여 흐름을 자동으로 완성시킨다.

고도화된 통합 선언 연장 효과 덕분으로, 서버 환경의 개발 진영은 배포 컴포넌트 시스템 릴리스 완료와 동시 시점에 자동으로 구성 완료된 현황판과 스크래핑 시스템 시각화 현주소(Grafana) 데이터베이스 파이프라인 모니터링 정보를 즉각 제공 뷰어로써 런타임 지표 파악 효과를 최척화 상태로 취득할 이익 보장이 가능해진다.

3. Grafana Annotation API를 활용한 배포 이벤트 트래킹 시각화

분산 시스템의 모니터링에서 마주치는 가장 큰 기만(Deception)은, 그라파나(Grafana) 대시보드 그래프가 갑자기 치솟을 때(예: CPU 100% 스파이크, 레이턴시 급증) 그것이 물리적인 고장인지, 외부의 해킹 시도인지, 아니면 “우리 팀이 5분 전에 코드 배포를 해서 발생한 충격타” 인지 실시간으로 분간할 길이 없다는 점이다.

서버가 느려진 시간에 슬랙(Slack) 공지를 뒤져가며 “아까 오후 3시에 누가 배포했나요?“라고 묻는 것은 비효율적인 대응 방식이다.
배포 파이프라인은 코드를 서버로 쏘아 올림과 동시에, 모니터링 대시보드의 정중앙에 “이 시점에 v1.5 배포가 감행되었음” 이라는 지워지지 않는 세로줄 역사(Annotation, 주석)를 기계적으로 새겨 넣어야 한다.

3.1 [Runbook] CI/CD 파이프라인의 이벤트 그레이빙(Graving) 기술

GitHub Actions나 GitLab CI의 배포 파이프라인 맨 마지막 성공(Success) 스텝에, 그라파나의 REST API API를 호출하는 curl 커맨드를 한 줄 관통시킨다.

3.1.1 단계: 배포의 폭발을 Grafana 데이터베이스에 꽂기

## GitLab CI 예시 (deploy_production 단계 성공 시)
deploy_edge_fleet:
  stage: deploy
  script:
    - kubectl apply -f zenoh-edge.yaml
    - echo "배포 완료!"
  # K8s 배포가 100% 성공(after_script)했을 때 그라파나 타격 
  after_script:
    - |
      curl -H "Authorization: Bearer ${GRAFANA_API_KEY}" \
           -H "Content-Type: application/json" \
           -X POST http://grafana-server.io/api/annotations \
           -d '{
                 "text": "🚀 Zenoh Edge v1.5 Deploy by CI Bot",
                 "tags": ["deploy", "edge", "production", "v1.5"]
               }'

3.1.2 단계: 그라파나 대시보드(Dashboard) 연동 철학의 완성

위 스크립트를 통해 K8s 배포가 떨어진 정확한 1밀리 초 단위의 시간 기록이 그라파나 엔진에 이식되었다.
이제 대시보드 톱니바퀴 설정에서 Annotations 옵션을 켜고, 쿼리 태그를 deploy 로 필터링하라.

그러면 수천 대의 라즈베리 파이 로봇들이 보내오는 Zenoh 트래픽(Pub/Sub) 증감 그래프 위로, 마치 명확하게 빨간색 세로 점선과 함께 “🚀 Zenoh Edge v1.5 Deploy” 라는 툴팁이 영구적으로 렌더링된다.

이 시각화 연동의 이점:
만약 이 배포선(Annotation 세로선)이 그어진 지점의 2분 뒤부터 로봇들의 P2P 네트워크 단절 횟수 메트릭 그래프가 급격히 상승한다면?
어떤 천재 개발자나 분석가의 조사도 필요 없다. 이 장애는 방금 푸시한 v1.5 코드의 태생적 치명적인 결함임이 지표의 인과관계(Causality)를 통해 1초 만에 논박 불가하게 증명된 것이다. 당신의 관리자는 즉시 19.7.4 장에서 다룬 롤백(Rollback) 버튼을 향해 반사적으로 버튼을 실행하라. 오직 시점과 데이터의 결합만이 인간의 추론을 기계적 확신으로 승화시킨다.

4. 주요 지표(Metrics) 모니터링을 연동한 성능 이슈(Alert) 대응 기반 파이프라인

배포 직후 애플리케이션의 상태를 육안으로 대시보드를 통해 관제하는 것은 초기 모니터링에 유효하지만, 24시간 연속 운용되는 무중단 글로벌 에지 및 클라우드 시스템에서는 운영자의 수동적 인지 속도만으로는 복잡한 장애 조치 제어가 불가하다.

따라서 배포 파이프라인의 완성은 수집된 시계열 메트릭(Metric) 값을 바탕으로 이상 징후를 스스로 판가름(Evaluation)하고, 한계치 오차를 넘는 결함 폭주 발생 시 외부 관제 시스템을 통한 모니터링 알람(Alert)을 전송하는 동시에 사전에 정의된 복구 파이프라인 훅(Hook)을 기계적으로 역호출함으로써 운영 체계를 방어하는 ‘자동 관제(Automated Alerting & Remediation)’ 네트워크 구조를 구축하는 것으로 대미를 장식해야 한다.

4.1 PrometheusRule 선언을 통한 이상 징후 조기 포착 로직 구성

이벤트 트래픽을 관제하기 위해서는 임계값을 설정하는 규칙(Rule) 엔진이 필요하다. 프로메테우스 오퍼레이터를 사용 중일 경우, 쿠버네티스의 CRD 자원인 PrometheusRule을 활용하여 시스템 이상 수준의 알람 임계 수치를 선언적(YAML)으로 구성할 수 있다.

## zenoh-alert-rules.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: zenoh-performance-alerts
  labels:
    role: alert-rules
spec:
  groups:
  - name: zenoh.rules
    rules:
    # Rule 1: 메시지 단절(Drop) 현상 급증 
    - alert: ZenohHighDropRate
      expr: rate(zenoh_messages_dropped_total[5m]) > 100
      for: 2m  # 2분 이상 지속될 때만 발송(일시적 스파이크 제외)
      labels:
        severity: critical
      annotations:
        summary: "비정상적인 메시지 Drop 수치 초과"
        description: "라우터 인스턴스에서 5분간 초당 100개 이상의 패킷 손실이 2분 이상 관측되었습니다."

    # Rule 2: 라우터 간 물리적 단절 
    - alert: ZenohRouterDisconnected
      expr: zenoh_connected_peers < 1
      for: 1m
      labels:
        severity: warning
      annotations:
        summary: "노드 세션 고립 경고"
        description: "현재 라우터와 연결된 피어가 0개입니다. 망 분리 현상을 확인하십시오."

4.2 Alertmanager 연동 및 자동화된 롤백(Auto-Rollback) 구조 실현

프로메테우스에서 규정한 임계치가 상회할 경우, 이벤트는 Alertmanager 구역으로 발송된다. 해당 관리 툴은 운영팀에 Slack, 이메일 등의 전달 역할을 1차적으로 수행할 뿐만 아니라, 가장 치명적인 문제(Critical)에 한해서 파이프라인 복구 시스템(Webhook API)을 즉각적으로 기동하는 연계 책임을 담당한다.

## Alertmanager 내부의 Receiver 라우팅 선언의 예
route:
  receiver: 'slack-notifications'
  routes:
    - match:
        severity: critical
      receiver: 'automated-rollback-webhook'

receivers:
- name: 'automated-rollback-webhook'
  webhook_configs:
  # 알람이 크리티컬 수치일 경우 CI/CD 도구의 Rollback 트리거 파이프라인 주소를 직접 타격
  - url: 'http://gitlab-ci-server/api/v4/projects/1/trigger/pipeline?token=ROLLBACK_TOKEN'

모니터링 알람 엔진과 배포 도구 파이프라인망 간의 트리거 시스템이 구축되면, “배포 이후, 모니터링 통계가 수집되며, 수치가 제한선을 연속 초과할 경우 시스템 에러 여파로 인한 롤백 체계를 자동 시작한다“라는 기계적 방어 루프가 온전히 완성된다.

결론적으로, 프로토콜 레이어에 국한된 최적화를 넘어 시스템 통제 계층이 결합된 인프라스트럭처의 견고한 파이프라인 설계는 에지에서 클라우드를 아우르는 Zenoh 생태계의 영구적인 탄력성(Resilience)과 자동 치유성(Self-healing)을 달성하는 초석이 될 것이다.

5. 주요 지표(Metrics) 모니터링을 연동한 성능 이슈(Alert) 대응 기반 파이프라인

배포 파이프라인 구축의 대장정을 마무리하는 궁극의 뼈대는, 파이프라인 자신이 흩뿌린 컨테이너(Zenoh Router)를 배포 이후에도 끝까지 책임지도록 경고망(Alerting) 의 신경줄을 CI 프로세스 전체의 라이프사이클 안으로 다시 되말아 올리는(Feedback Loop) 작업이다.

앞서 19.7.3에서 카나리아 배포를 설명하며 “프로메테우스가 에러 레이트를 감별하여 롤아웃을 중단시킨다“는 사상을 짚은 바 있다. 본 장에서는 그 기계적 퇴각 룰(Rollback Triggers)을 구체적인 프로메테우스 알러트(Alert) 규칙으로 성문화하여 배포 코드 안에 영구적으로 장입하는 기술을 논단한다.

5.1 [인스펙션] PrometheusAlertRule 기반 파괴 감지 선언문

모니터링 알람(Alert) 규칙을 그라파나 화면을 보며 마우스로 찍어대는(Click-Ops) 원시적인 행태를 당장 폐기하라.
인프라 코드를 수정할 때, 그 코드를 방어하는 알람 룰(Alert Rule)의 스펙 매니페스트 역시 한 세트로 묶어 K8s 배포 시스템(ArgoCD)을 통해 태워 보내야 한다.

5.1.1 K8s CustomResource (PrometheusRule) 주입

Zenoh 망을 감시하는 3대 치명적 오류 기준 기준(네트워크 드랍, 메모리 포화, TCP 연결성 단절)을 매니페스트로 규정한다.

## zenoh-alert-rules.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: zenoh-critical-alerts
  labels:
    role: alert-rules 
spec:
  groups:
  - name: zenoh.alerts
    rules:
    # 치명적 오류 기준 1: 네트워크 트래픽 급락 (라우팅 버그)
    - alert: ZenohTrafficDropped
      expr: rate(zenoh_router_rx_bytes_total[5m]) < 1000 # 5분간 처리량이 1kb 미만으로 멈춰버림
      for: 2m  # 2분간 지속되면 즉각적으로 알람(Fire)
      labels:
        severity: critical
        action: auto-rollback # 파이프라인 훅 트리거 용어
      annotations:
        summary: "Zenoh Router Traffic Frozen"
        description: "새로 배포된 라우터가 P2P 망에서 연결이 끊겨 데이터를 수신하지 못하고 있음."

    # 치명적 오류 기준 2: OOM(Out of Memory) 사전 징후 (메모리 릭)
    - alert: ZenohMemoryLeak
      expr: container_memory_usage_bytes{container="zenohd"} / container_spec_memory_limit_bytes > 0.9
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Zenoh D Node Memory at 90%"
        description: "이 파드는 5분 안에 OOM Killed 당하여 위험이 매우 높음."

5.2 자동화된 심판정 (AlertManager to CI Webhook)

위임된 알람 규칙(AlertRule)이 Trigger(Fire 상태)되는 순간, 프로메테우스의 행동 강령 체계인 얼럿 매니저(AlertManager) 는 개발자의 슬랙(Slack) 로 알림을 울리는 것과 동시에, GitHub Actions 나 Spinnaker 의 원격 API(Webhook)를 정밀 타격하여 비상사태(Rollback) 트리거를 당겨버린다.

## alertmanager-config.yaml
receivers:
- name: 'slack-and-rollback'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/T0000/B000/XXXX'
    title: '🚨 Zenoh Cluster Alert: 배포 심각한 장애 발발'
  webhook_configs:
  - url: 'https://api.github.com/repos/company/zenoh-infra/dispatches'
    # 배포 롤백 파이프라인을 기계가 직접 호출해버리는 롤백 수행 구조

인간이 “배포가 잘못되었다“고 인지하여 수동으로 되돌림 버튼을 누르는 데에는 최소 10분의 지연이 생긴다. 10분이면 10,000대의 자율주행 드론이 길을 잃고 낭떠러지로 수십 대가 추락할 수 있는 영겁의 시간이다.

“모니터링(Metrics) -> 알람 생성(AlertRule) -> 기계적 파이프라인 역소환(Webhook Rollback)” 이라는 이 거대한 완전 자동 피드백 폐쇄 루프(Closed-Loop)를 구축하는 것, 이것이야말로 Chapter 19에서 논의해 온 에지-클라우드 연속성 배포 파이프라인의 가장 견고한 배포 파이프라인의 완성다. 인간을 배제하라. 오직 기계가 기계를 자동으로 제어하도록 설계하라.