7. 오케스트레이션(Orchestration)#

네트워크 팀은 모든 것을 제대로 해냈다. 견고한 소스 오브 트루스(SoT), 모든 작업에 대한 충분히 테스트된 플레이북, 그리고 이를 실행하는 명확한 대응 절차서가 있었다. 서류상으로는 새로운 VLAN 서비스 배포가 완전히 자동화되어 있었다. 실제로는 반나절이 걸렸고 특정 엔지니어 한 명이 필요했다.

그 엔지니어는 순서를 알고 있었다. 먼저 SoT 데이터가 완전한지 검증한다. 그 다음 사전 점검 플레이북을 실행한다. 출력을 검토하고, 실패한 장치를 찾아 계속할지 결정한다. 그 다음 배포 플레이북을 트리거한다. 기다린다. 검증 플레이북을 실행한다. ServiceNow 티켓을 수동으로 업데이트한다. 중간에 장치가 실패하면 다른 장치들이 알아채기 전에 롤백한다. 그녀는 아무도 완전히 내면화하지 못한 공유 문서에 단계별로 모든 것을 대응 절차서로 작성해 두었다.

그녀가 휴가를 가면 배포가 멈췄다. 주니어 엔지니어가 순서를 틀리게 했을 때, 네트워크는 6시간 동안 부분적인 상태로 남겨졌다. 자동화는 존재했다. 조율은 여전히 수동이었다.

이것이 이 챕터가 해결하는 문제다. 오케스트레이션은 자동화 도구들의 모음을 하나처럼 동작하는 시스템으로 전환하는 구성 요소다. 다른 블록들을 조율하고, 언제 실행할지 결정하며, 장애를 우아하게 처리하고, 모든 결정을 추적하며, 이 모든 것을 엔지니어가 중간에 서서 흐름을 수동으로 관리하지 않고도 수행한다.

7.1. 기초 개념#

7.1.1. 맥락#

지금까지 다룬 모든 구성 요소는 한 가지를 잘 수행한다. 소스 오브 트루스는 인텐트를 보유한다. 실행기(Executor)는 이를 적용한다. 수집기(Collector)는 상태를 가져온다. 가시성(Observability)은 그 상태를 이해한다. 각각은 전문가이며, 전문가에게는 연결자가 필요하다. 각각이 언제 행동해야 하는지, 결과로 무엇을 할지, 그리고 무언가 잘못되었을 때 어떻게 복구할지를 결정하는 무언가가.

그 연결자가 Orchestrator다.

챕터 3에서 우리는 이를 다른 모든 것을 조율하는 블록으로서 NAF 프레임워크의 중심에 배치했다. 챕터 5는 실행기가 구성 변경을 어떻게 적용하는지 보여주었고, 챕터 6은 가시성이 결과를 어떻게 검증하는지 보여주었다. 이 챕터는 오케스트레이터가 둘을 어떻게 순서화하고, 그 사이에서 발생할 수 있는 모든 것을 처리하는지 보여준다.

오케스트레이션 없이는 자동화를 실행하는 것이 아니다. 누군가가 올바른 순서로, 올바른 시간에, 올바른 방식으로 해석하며 호출해야 하는 스크립트를 실행하는 것이다. 그것은 이름만 자동화다.

7.1.2. 목표#

오케스트레이터는 다섯 가지 목표를 달성해야 한다.

1. 다중 블록 워크플로를 처음부터 끝까지 조율한다. 배포는 단일 행동이 아니다. 순서다. SoT에서 인텐트를 검증하고, 사전 점검을 실행하며, 구성을 적용하고, 결과를 검증하고, 이해관계자에게 알린다. 오케스트레이터는 전체 순서를 하나로 유지한다.

2. 사람의 시작 여부와 관계없이 이벤트에 자동으로 반응한다. ServiceNow 승인, 가시성 알림, 예약된 컴플라이언스 스캔, 이 모든 것이 사람이 수동으로 시작하지 않아도 워크플로를 트리거할 수 있어야 한다.

3. 복원력 있고 확장 가능한 실행. 800개의 스위치를 병렬로 다루는 워크플로는 안정적으로 완료되어야 한다. 재시작에서 살아남아야 한다. 성공한 장치들의 작업을 잃지 않고 부분 실패를 처리해야 한다.

4. 변조 방지 가시성을 제공한다. 운영자는 지금 무엇이 실행 중인지 볼 수 있어야 한다. 감사팀은 지난달에 무엇이 실행되었는지, 누가 트리거했는지, 어떤 버전의 워크플로가 실행되었는지, 모든 단계가 무엇을 생성했는지 볼 수 있어야 한다. 두 가지 요구 모두 동일한 시스템에서 충족되어야 한다.

5. 워크플로 정의를 프로덕션 소프트웨어로 관리한다. 800개의 스위치에 배포하는 워크플로는 임의로 변경될 수 없다. 로직 자체가 프로덕션에서 실행되는 코드에 적용되는 것과 동일한 규율로 영속화되고, 버전 관리되고, 테스트되고, 프로덕션으로 승격되어야 한다.

7.1.3. 기둥#

다섯 가지 기둥이 이 목표들을 지원한다.

1. 워크플로 엔진: 다단계 프로세스를 정의, 실행, 추적
2. 트리거링 계층: 수동, 예약, 이벤트 기반, 웹훅
3. 복원력 있는 실행: 워크플로가 재시작에서 살아남음; 수백 개 장치에서 장치별 병목 없이 재시도, 롤백, 동시 작업 지원
4. 감사 및 가시성: 모든 단계 기록, 모든 결정 추적 가능
5. 파이프라인 관리: 프로덕션에서 워크플로 정의를 안전하게 영속화, 버전 관리, 승격

7.1.4. 범위#

오케스트레이터는 조율한다. 행동하지 않는다.

범위 내:

• 다른 구성 요소들 조율
• 워크플로 로직과 단계 의존성 정의
• 여러 소스의 트리거링 처리
• 실행 상태 추적 및 감사 추적 생성
• 단계가 실패할 때 롤백 결정 관리

범위 외:

• 장치 변경 실행 (Executor의 역할)
• 네트워크 운영 상태 저장 (Observability의 역할)
• 네트워크 인텐트 보유 (소스 오브 트루스의 역할)

일반적인 실수는 이웃 블록의 실행 또는 저장 책임을 복제하는 오케스트레이터를 구축하는 것이다. 블록 간 인터페이스는 명확해야 한다.

자격 증명도 저장하고, 장치 인벤토리도 관리하고, 자체 구성 엔진도 실행하는 오케스트레이터는 다른 무언가로 성장한 것이다. 오케스트레이션 도구가 다른 블록의 책임을 흡수하기 시작한다면, 나중에 풀기 비용이 많이 드는 아키텍처 결합 문제가 있는 것이다.

7.2. 기능#

다섯 가지 목표와 기둥은 다섯 가지 핵심 기능을 통해 실현된다. 각각은 하나의 목표와 그것을 지원하는 기둥에 직접 매핑된다.

1. 워크플로 엔진: 워크플로가 어떻게 구조화되고 단계가 어떻게 조율되는지
2. 트리거링: 워크플로가 어떻게 언제 시작되는지, 그리고 호출자가 무엇을 경험하는지
3. 복원력과 확장성: 장애 하에서 그리고 대용량에서 워크플로가 어떻게 안정적으로 완료되는지
4. 상태와 추적성: 실행 상태 추적 및 변조 방지 감사 기록 생성
5. 파이프라인 관리: 프로덕션에서 워크플로 정의를 안전하게 영속화하고 관리

graph LR

    subgraph 목표
        direction TB
        A1[다중 블록 워크플로 처음부터 끝까지 조율]
        A2[이벤트에 자동으로 반응]
        A3[복원력 있고 확장 가능한 실행]
        A4[변조 방지 가시성과 감사]
        A5[프로덕션 파이프라인에 안전한 변경]
    end

    subgraph 기둥
        direction TB
        B1[워크플로 엔진: 정의, 실행, 추적]
        B2[트리거링 계층: 수동, 예약, 이벤트 기반]
        B3[복원력 있는 실행: 내구성, 재시도, 규모에서 롤백]
        B4[감사 및 가시성: 모든 단계 기록]
        B5[파이프라인 관리: 안전하게 영속화, 버전 관리, 승격]
    end

    subgraph 기능
        direction TB
        C1[워크플로 엔진]
        C2[트리거링]
        C3[복원력과 확장성]
        C4[상태와 추적성]
        C5[파이프라인 관리]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;

7.2.1. 워크플로 엔진#

워크플로 엔진은 오케스트레이터의 핵심이다. 다단계 프로세스를 정의하고, 실행하고, 상태를 추적하고, 단계 간의 관계를 처리한다.

패턴으로 들어가기 전에, 조율의 네 가지 근본적인 접근 방식을 명명할 가치가 있다. 이 선택이 다른 모든 것을 형성하기 때문이다.

7.2.1.1. 조율 접근 방식#

• 단일 구조(Monolith) (명령형 프로그램): 단일 Python 스크립트가 각 단계를 순서대로 호출하고, 각 결과를 기다리며, 다음에 무엇을 할지 결정한다. 작성하기 단순하며 많은 팀이 여기서 시작한다. 문제는 내구성이다. 스크립트가 10단계 중 5단계에서 충돌하면 처음부터 재시작해야 한다. 실행 사이에 영속적인 상태가 없다. 직접 스레딩 로직을 작성하지 않으면 단계를 병렬화할 수도 없다. 소규모 빠른 작업에는 효과적이지만 부하와 불안정한 인프라에서는 무너진다. 실제로 이것은 실행기 블록이 이미 제공하는 것이다. 운영자가 호출하는 스크립트. 이를 오케스트레이션이라고 부르는 것은 과대평가다.

• 워크플로(Workflow) (DAG 기반): 여기서 오케스트레이션이 진정으로 시작된다. 단계는 방향성 비순환 그래프(DAG)로 정의되며, 각 노드는 작업이고 엣지는 의존성을 나타낸다. 엔진은 노드별 상태를 추적한다. 충돌 후 재시작하면 실패하거나 불완전한 단계만 다시 실행된다. 병렬성이 내장되어 있다. 독립적인 브랜치가 동시에 실행된다. 이것이 프로덕션 오케스트레이션의 지배적인 접근 방식이며 네트워크 자동화에서 가장 검증된 방식이다. 이 범주의 도구로는 Prefect, Temporal, AWX 워크플로 템플릿이 있다.

• 코레오그래피(Choreography) (이벤트 기반, 중앙 조율자 없음): 오케스트레이터가 없다. 각 구성 요소가 다른 것이 게시한 이벤트에 반응한다. 실행기가 “배포 완료"를 게시하고, 가시성 시스템이 이를 소비하고 검증을 실행하며, 알림 시스템이 검증 결과를 소비한다. 구성 요소 간의 결합이 느슨하여 새로운 소비자를 추가하기 쉽다. 단점은 전체 워크플로 상태를 이해하는 단일 장소가 없다는 것이다. 교차 서비스 실패를 디버그하려면 여러 시스템의 이벤트를 상관 분석해야 한다. 이 접근 방식은 단순한 반응형 패턴에는 효과적이지만 복잡성에서 확장이 어렵다.

• 에이전틱(Agentic) (감지-논리-행동 루프): Large Language Model (LLM) 또는 AI 시스템이 로직 계층으로 작동한다. 에이전트는 가시성 또는 SoT에서 현재 상태를 관찰하고, 어떤 행동이 필요한지 추론하며, 실행기를 호출한다. 미리 정의된 워크플로 그래프를 따르는 대신 런타임에 동적으로 결정을 내린다. 이것이 결정론을 유연성과 맞바꾸는 접근 방식으로, 자율 네트워크를 위한 아키텍처 기반을 형성한다. 섹션 7.2.7에서 심층적으로 다루며, 챕터 17에서 완전한 자율성으로 확장된다.

대부분의 팀은 단일 구조(Monolith) 접근 방식으로 시작하여 자동화가 성숙해지면 워크플로(DAG 기반)로 발전한다. 코레오그래피는 감사 및 추적성 요구사항이 중앙 조율자를 가치 있게 만들기 때문에 네트워크 운영에서 거의 올바른 선택이 아니다. 에이전틱 접근 방식은 실재하지만 아직 프로덕션 네트워크 운영의 기본값은 아니다.

7.2.1.2. 워크플로 패턴#

DAG 기반 접근 방식 내에서 네 가지 패턴이 대부분의 실제 네트워크 자동화 워크플로를 커버한다.

• 순차(Sequential): 단계가 차례로 실행되며, 각각은 이전 단계의 성공적인 완료에 의존한다. 엄격한 순서가 필요할 때 적합하다. 인텐트 검증, 사전 점검, 실행, 검증.

• 병렬(Fan-out/Fan-in): 여러 독립적인 단계가 동시에 실행된다. 팬아웃 단계는 많은 병렬 작업을 시작하고(장치당 하나, 또는 건물당 하나), 팬인 단계는 계속하기 전에 모두 완료될 때까지 기다린다. 수백 개 장치에 걸친 작업에 필수적이다. 팬아웃 없이 장치당 10초 작업이 800개 장치에서는 순차적으로 두 시간 이상 걸린다.

• 조건부 분기(Conditional branching): 취하는 경로가 런타임 상태에 따라 달라진다. 사전 점검이 통과되었는가? 실행으로 분기한다. 실패했는가? 중단하고 알림으로 분기한다. 워크플로 정의에는 결과를 평가하고 다음 단계를 선택하는 결정 노드가 포함된다.

• 사가 패턴(Saga pattern): 장기 실행 워크플로의 경우, 사가 패턴(Saga Pattern)이 각 단계에 보상 트랜잭션을 추가한다. N 단계에서 워크플로가 실패하면, N-1단계부터 1단계까지 역순으로 보상 작업을 실행하여 시스템을 알려진 양호한 상태로 되돌린다. 이것이 오케스트레이션 수준에서 롤백이 작동하는 방식이다. 전체 워크플로를 다시 실행하는 것이 아니라 성공한 각 단계의 역을 실행하는 것이다.

flowchart TD
    subgraph Sequential["순차"]
        S1[단계 A] --> S2[단계 B] --> S3[단계 C]
    end

    subgraph FanOut["팬아웃과 팬인"]
        F0[시작] --> F1[장치 1]
        F0 --> F2[장치 2]
        F0 --> F3[장치 N]
        F1 --> FJ[팬인]
        F2 --> FJ
        F3 --> FJ
    end

    subgraph Saga["사가 - 실패 시 롤백"]
        P1[단계 1] --> P2[단계 2] --> P3[단계 3]
        P3 -- fail --> R3[Rollback 3]
        R3 --> R2[Rollback 2]
        R2 --> R1[Rollback 1]
    end

사가 패턴(Saga Pattern)은 또한 점진적 롤아웃의 구조적 기반이다. 한 번에 모두가 아니라 웨이브 방식으로 네트워크 변경을 배포하는 것이다. 웨이브 1은 소규모 테스트 집단을 커버하고, 성공하면 워크플로가 웨이브 2로, 그 다음 웨이브 N으로 팬아웃된다. 어떤 웨이브가 실패하면 보상이 해당 웨이브만 롤백한다. 이것은 카나리 배포의 네트워크 버전이다. 소프트웨어 팀이 코드 릴리스에 적용하는 것과 같은 통제된 승격 규율을 네트워크 변경에 적용하는 것이다.

7.2.1.3. 의존성 관리#

워크플로 단계는 거의 독립적으로 존재하지 않는다. 엔진은 세 가지 종류의 의존성을 표현하고 강제해야 한다.

• 데이터 의존성: 작업 B는 작업 A가 완료하고 B가 소비하는 결과를 생성할 때까지 시작할 수 없다. 엔진은 구조화된 데이터로 단계 간 출력을 전달한다. 실제로 이것은 사전 점검 단계가 처음부터 다시 쿼리하는 것이 아니라 실행 단계에 도달 가능한 장치 목록을 전달하는 것을 의미한다.

• 다중 입력 의존성 (팬인): 단계가 계속하기 전에 여러 병렬 브랜치를 기다린다. 엔진은 각 브랜치의 상태를 보유하고 구성된 완료 정책이 충족될 때만 조인 단계를 트리거한다. 모두 완료됨, 또는 M 중 N개, 또는 첫 번째 성공.

• 외부 의존성: 때로는 시스템 외부에서 무언가가 발생할 때까지 단계가 진행될 수 없다. 변경 창이 열린다. 사람이 승인한다. 재부팅 후 장치가 도달 가능해진다. 엔진은 구성 가능한 타임아웃과 대기가 해결되지 않을 때를 위한 정의된 에스컬레이션 경로가 있는 대기 상태를 지원해야 한다.

7.2.2. 트리거링#

워크플로는 어떻게든 시작되어야 한다. 트리거링은 두 가지 질문에 답한다. 무엇이 워크플로를 시작하게 하는가, 그리고 그 후 호출자는 무엇을 경험하는가.

챕터 5와 트리거링이 다른 점: 챕터 5에서 트리거링은 운영자나 시스템이 실행 엔진을 직접 호출하는 방법을 가리켰다. AWX에 대한 API 호출, Command Line Interface (CLI)에서 템플릿 시작. 그것은 실행 계층 트리거링이다. 여기서 트리거링은 오케스트레이터가 워크플로를 시작하게 하는 것을 설명하며, 이는 여러 단계 중 하나로 실행기를 호출할 수 있다. 오케스트레이터는 트리거를 받고 실행할 전체 워크플로를 결정한다. 실행기는 오케스트레이터가 지시하는 것을 실행할 뿐이다.

7.2.2.1. 트리거링 모드#

네 가지 모드가 사람에서 완전 자동화까지 전체 스펙트럼을 커버한다.

• API 호출: 오케스트레이터가 HTTP 엔드포인트를 노출한다. 운영자가 수동으로 호출하거나, UI 버튼이 호출하거나, 이벤트가 발생할 때 외부 시스템(ServiceNow, Nautobot, CI/CD 파이프라인)이 호출한다. 이것들은 같은 메커니즘이다. 다른 것은 누가 호출을 시작하고 구조화된 이벤트 데이터를 포함하는지 여부다. 시작자가 사람이든 시스템이든 지금 시작해야 하는 변경에 적합하다.

• 예약(Scheduled): cron 방식의 일정이 구성된 시간에 워크플로를 시작한다. 야간 컴플라이언스 스캔, 주간 펌웨어 감사, 월간 용량 보고서. 대부분의 오케스트레이터가 이를 기본적으로 지원한다. 일부 팀은 외부 스케줄러를 사용하고 오케스트레이터 API를 호출한다.

• 메시지 큐(Message queue): 오케스트레이터가 큐(Kafka, NATS, RabbitMQ)에서 메시지를 소비하고 메시지당 워크플로를 시작한다. 이것은 이벤트 생산자와 오케스트레이터를 분리한다. 생산자가 게시하고 이동하면, 오케스트레이터는 자신의 속도로 처리한다. 직접 API 호출의 최대 한 번 전달 보장이 불충분한 고볼륨 이벤트 스트림에 적합하다.

푸시(API 호출)와 풀(메시지 큐, 예약) 중의 선택은 볼륨과 결합 허용도에 달려 있다. API 호출이 더 단순하지만 발신자가 오케스트레이터의 엔드포인트를 알아야 한다. 메시지 큐는 고볼륨 스트림에 더 잘 확장되지만 운영할 인프라가 추가된다.

7.2.2.2. 응답 계약#

워크플로가 시작되면 호출자는 무엇을 기대해야 하는지 알아야 한다.

• 동기(Synchronous): 호출자가 워크플로가 완료될 때까지 기다리고 결과를 직접 받는다. 호출자가 결과를 받아 진행해야 하는 짧은 작업(30초 미만)에 적합하다. 대부분의 인터랙티브 사용 사례가 여기서 시작하여 10분 배포를 실행하려고 할 때 API 클라이언트가 타임아웃되면서 한계를 경험한다.

• 비동기(Asynchronous): 호출자가 즉시 워크플로 실행 ID를 받고 상태를 폴링하거나, 완료 시 결과를 받을 콜백 URL을 등록한다. 몇 개 이상의 장치를 다루는 워크플로에 필요하다. 이것은 시스템이 상태를 표시하는 방법에 직접적인 영향을 미친다. 프레젠테이션 계층(챕터 8)은 상태 엔드포인트와 푸시 알림을 노출해야 한다. 사용자가 어딘가에서 워크플로를 트리거했으며 열린 HTTP 연결을 유지하지 않고 추적할 방법이 필요하기 때문이다.

• 하이브리드(Hybrid): 워크플로가 비동기적으로 시작되지만, 호출자가 필요한 경우 동기 대기 엔드포인트를 선택적으로 블록할 수 있다. 호출자가 미리 선택하도록 강요하지 않는 편의 패턴이다.

이벤트 기반 워크플로에서의 멱등성: 가시성이 알림을 발생시키거나 SoT 변경 이벤트가 발생할 때, 여러 시스템이 동시에 반응할 수 있다. 동일한 알림이 두 번 발생할 수 있고, 메시지 큐가 동일한 메시지를 두 번 이상 전달할 수 있다. 모든 이벤트 기반 워크플로는 멱등성이 있어야 한다. 동일한 입력에 대해 두 번 실행하는 것이 한 번 실행하는 것과 같은 결과를 생성해야 한다. 오케스트레이션 수준에서 이것은 일반적으로 중복 제거 키가 필요하다. 오케스트레이터가 새 실행을 시작하기 전에 확인하는 고유 식별자. 해당 키가 있는 실행이 이미 존재하고 여전히 실행 중이라면 중복을 거부하거나 큐에 추가한다. 단순하게 들리지만 실제로는 놀랍도록 쉽게 잘못될 수 있다.

폐루프 패턴(Closed-Loop Pattern): 가시성이 드리프트 조건을 감지한다(장치 구성이 인텐트에서 벗어났다). 위의 트리거링 메커니즘을 통해 오케스트레이터에 알림을 보낸다. 오케스트레이터가 수정 워크플로를 시작한다. SoT에서 예상 상태를 쿼리하고, 실행기를 호출하여 장치를 수정하고, 가시성 점검을 다시 실행하여 수정을 확인한다. 점검이 통과되면 루프가 닫힌다. 실패하면 오케스트레이터가 에스컬레이션한다. 이 패턴은 자가 치유 자동화의 기반으로 챕터 15에서 심층적으로 다룬다. 루프는 오케스트레이터, 가시성, 실행기가 각각 독립적으로 역할을 수행할 수 있을 만큼 충분히 분리되어 있어야만 작동한다.

7.2.3. 복원력과 확장성#

이것이 프로토타입으로 만드는 오케스트레이터와 새벽 3시 프로덕션에서 신뢰하는 오케스트레이터를 구분한다. 이상적인 조건에서 안정적으로 실행되는 워크플로는 조율자 재시작 중간에 살아남을지, 800개 장치 중 40개가 사전 점검에 실패하는 것을 처리할지, 의존성이 해결되지 않을 때 우아하게 저하될지에 대해 아무것도 알려주지 않는다. 다음에 오케스트레이터가 테스트받을 때 데모에서는 아닐 것이다.

챕터 5에서 다룬 실행 계층의 복원력은 개별 장치 수준의 멱등성과 재시도를 다룬다. 플레이북이 하나의 장치에 대해 실패하면 재시도한다. 챕터 5가 다루지 않는 것은 워크플로 수준의 내구성이다. 오케스트레이터 자체가 실행 중간에 재시작될 때, 800개 중 40개 장치가 사전 점검에 실패할 때, 또는 의존성이 절대 해결되지 않아 워크플로가 멈출 때 무슨 일이 일어나는가. 오케스트레이터 자체를 확장하는 것, 고가용성, 수평적 워커, 동시 실행 하의 데이터베이스 부하를 포함하여, 이것은 챕터 11에서 다루는 인프라 관심사다.

7.2.3.1. 내구성 있는 상태#

메모리에 실행 상태를 저장하는 워크플로 엔진은 재시작 시 모든 것을 잃는다. 스크립트에는 허용되지만 프로덕션 오케스트레이션에는 허용되지 않는다. 내구성 있는 상태는 워크플로의 진행 상황이 오케스트레이터의 실패에서 살아남는다는 것을 의미한다. 어떤 단계가 완료되었는지, 무엇을 생성했는지, 어떤 것이 여전히 대기 중인지. 오케스트레이터가 다시 온라인 상태가 되면 중단한 곳에서 재개된다.

Temporal은 이 보장을 전적으로 중심으로 구축되었다. 재시작 시 이벤트 이력에서 워크플로 함수를 재생하여 진행 중인 상태를 충돌 방지로 만든다. AWX는 작업 상태를 데이터베이스에 저장한다. 스크립트는 아무것도 저장하지 않는다.

7.2.3.2. 재시도 전략#

모든 실패가 동일하지 않다. 펌웨어 재부팅 중 일시적으로 도달할 수 없었던 장치는 재시도해야 한다. 영구적인 인증 오류를 반환한 장치는 그렇지 않다. 재시도가 도움이 되지 않으며 잠금 정책을 트리거할 수 있다.

재시도 구성은 다음을 구분해야 한다.

• 일시적 실패(Transient failures): 네트워크 장애, API 타임아웃, 일시적인 리소스 경쟁. 지수 백오프로 재시도.
• 영구적 실패(Permanent failures): 잘못된 자격 증명, 유지보수 모드의 장치, 이 장치 유형에 적용되지 않는 구성. 중단하고 에스컬레이션.

워크플로 정의는 단계별 재시도 정책을 지정해야 한다. 사전 점검 단계와 구성 푸시 단계는 서로 다른 실패 의미론을 가지며 동일한 재시도 설정을 공유해서는 안 된다.

7.2.3.3. 롤백과 보상#

배포 워크플로가 중간에 실패하면 세 가지 옵션이 있다. 부분적인 상태로 두거나, 수동으로 수정하거나, 자동으로 롤백하거나. 대부분의 네트워크 운영에서 부분적인 상태는 위험하다. 새 구성을 받은 장치는 받지 못한 장치와 다르게 동작한다.

**사가 패턴(Saga Pattern)**은 각 단계에 대한 보상 트랜잭션을 정의하여 이를 해결한다. 워크플로가 N단계까지 성공하고 실패하면, N-1단계부터 1단계까지 역순으로 보상 작업을 실행한다. VLAN 배포에서: 구성 푸시가 30개 장치에서 성공하고 31번째에서 실패하면, 사가가 실패를 보고하기 전에 30개의 성공한 푸시를 롤백한다.

사가 패턴(Saga Pattern)은 보상 트랜잭션이 워크플로 설계 시 미리 정의되어야 한다. 이것은 사전에 추가 작업이다. 대안은 새벽 2시에 어떤 대응 절차서도 설명하지 않는 상태에 네트워크가 있다는 것을 발견하는 것이다.

7.2.3.4. 동시성 제어#

800개 장치에 동시에 팬아웃하면 대부분의 실행 계층이 압도된다. 오케스트레이션 수준의 동시성 제어는 다음을 의미한다.

• 배치(Batching): N개 장치를 병렬로 실행하고, 배치가 완료될 때까지 기다린 다음 다음 N개를 실행한다. 이것이 폭발 반경을 제어한다. 잘못된 구성이 문제를 드러내도 아직 800개 장치 모두를 건드리지 않은 것이다.
• 속도 제한(Rate limiting): 실행 계층에는 한계가 있다. 오케스트레이터가 이를 존중해야 한다. AWX 큐를 800개의 동시 작업으로 채우지 마라.
• 부분 성공 임계값(Partial success thresholds): 규모에서 성공이 무엇을 의미하는지 정의하라. 800개 중 798개 장치가 올바르게 구성되면 계속하기에 충분할 수 있다. 800개 중 600개는 워크플로를 중단하고 에스컬레이션해야 한다.

7.2.3.5. 타임아웃과 서킷 브레이커#

영원히 기다리는 워크플로는 안정성 문제다. 차단될 수 있는 모든 단계에는 구성된 타임아웃이 필요하다. 타임아웃이 만료되면 워크플로에는 정의된 행동이 필요하다. 에스컬레이션, 건너뜀, 또는 중단.

Circuit Breaker 패턴은 이를 반복 실패로 확장한다. 단계가 특정 기간 내에 N번 이상 실패하면 시도를 멈추고 알림을 올린다. 이것은 단일 도달 불가능한 장치가 워크플로를 몇 시간 동안 열어두는 것을 방지한다.

7.2.3.6. 블록 경계에서의 복원력#

위의 다섯 가지 패턴은 오케스트레이터 자체 실행 내의 실패를 다룬다. 내구성 있는 상태, 재시도, 롤백, 동시성, 타임아웃. 하지만 워크플로는 블록 경계에서도 실패하며, 이러한 실패는 다른 처리가 필요하다.

오케스트레이터가 SoT API를 호출하고 타임아웃을 받으면, 적절한 응답은 실행기가 장치 실패를 반환할 때와 다르다. SoT 타임아웃은 오케스트레이터가 배포하려는 인텐트가 현재 상태인지 확인할 수 없다는 것을 의미한다. 캐시된 데이터로 진행하면 오래된 구성을 적용할 위험이 있다. 올바른 응답은 보통 불확실성으로 진행하는 것이 아니라 중단하고 재시도하는 것이다. 절대 도달하지 않는 프레젠테이션 계층 이벤트(ServiceNow의 승인 웹훅)는 요청이 거부되었거나, 통합이 깨졌거나, 메시지가 손실되었음을 의미할 수 있다. 이것들은 서로 다른 복구 경로가 필요하다. 누락된 승인은 무한히 재시도해야 하는 일시적 실패가 아니다.

블록 경계 실패는 워크플로 정의에서 명시적으로 분류되어야 한다.

• 의존성 불가(Dependency unavailable) (SoT, 가시성): 워크플로가 안전하게 진행될 수 없다. 깔끔하게 실패하고, 진단 이벤트를 내보내고, 오래된 데이터로 재시도하지 마라.
• 의존성 저하(Dependency degraded) (부분 SoT 읽기, 가시성 지연): 워크플로가 신뢰도가 낮아진 상태로 운영하고 있음을 명시적으로 인정하고 진행할 수 있다. 저하된 상태를 기록하고 조용히 진행하지 마라.
• 하위 블록 실패(Downstream block failed) (실행기가 오류 반환, 수집기가 데이터 없음 반환): 위의 재시도 및 롤백 패턴을 적용하되, 알림 및 감사 기록이 올바른 블록을 명명하도록 실패 소스를 정확히 분류하라.

모든 실패를 재시도 가능한 장치 오류로 처리하는 워크플로는 재시도 예산을 소진하고 온콜 엔지니어를 잘못된 진단으로 호출할 때까지 깨진 SoT 통합을 재시도한다. 블록 경계에서 실패를 분류하는 것이 빠르게 실패하는 워크플로와 혼란스럽게 실패하는 워크플로의 차이다.

7.2.4. 상태와 추적성#

새벽 3시에 무언가 잘못되면 두 가지 질문에 즉각적인 답이 필요하다. 워크플로의 현재 상태는 무엇인가, 그리고 누가 트리거했는가?

감사팀이 세 달 후에 질문할 때, 동일한 기록이 답해야 한다. 무엇이 실행되었는지, 어떤 버전의 워크플로 정의가 실행되었는지, 모든 단계가 입력으로 무엇을 받았는지, 출력으로 무엇을 생성했는지, 최종 결과가 무엇이었는지.

이것들은 긴급도가 다른 다른 질문들이지만, 같은 소스에서 나온다. 워크플로의 실행 상태와 감사 기록.

추적성은 자동화 플랫폼 전반에 걸친 교차 절단 관심사다. 소스 오브 트루스는 인텐트에 대한 모든 변경을 기록한다. 가시성은 네트워크 상태에 대한 모든 변경을 기록한다. 하지만 그 기록들 중 어느 것도 누가 워크플로를 시작했는지, 어떤 단계가 순서대로 실행되었는지, 무엇이 결과를 초래했는지를 알려주지 않는다. 오케스트레이터의 감사 기록만이 그 격차를 메운다. 오케스트레이터가 다른 모든 블록을 조율하기 때문에, 그 추적이 특정 이벤트에 대해 전체 자동화 시스템에서 일어난 모든 것의 권위 있는 뷰다.

7.2.4.1. 상태는 네트워크 상태가 아니다#

이 구분은 놓치기 쉽다. 챕터 6에서 “상태"는 네트워크의 운영 상태를 의미했다. 인터페이스 카운터, BGP 세션, 장치 CPU. 챕터 5에서 “상태"는 SoT에 보유된 원하는 구성 인텐트를 의미했다. 여기서 상태는 워크플로 자체의 실행 상태를 의미한다. 어떤 단계가 실행되었는지, 어떤 것이 실행 중인지, 어떤 것이 실패했는지, 무엇을 생성했는지.

두 가지는 관련이 있다(워크플로 단계가 가시성이 검증하는 네트워크 상태 변경을 생성한다). 하지만 다르게 저장되고, 다르게 쿼리되며, 다른 목적을 제공한다. 혼동하지 마라.

7.2.4.2. 워크플로 상태 머신#

모든 워크플로 실행은 정의된 상태 머신을 통해 이동한다.

• 대기(Pending): 수신되었지만 아직 시작되지 않음
• 실행 중(Running): 능동적으로 단계 실행 중
• 성공(Succeeded): 모든 필수 단계가 성공적으로 완료됨
• 실패(Failed): 단계가 실패하고 워크플로가 계속될 수 없음
• 취소됨(Cancelled): 사람 또는 외부 신호에 의해 중단됨

워크플로 내의 각 단계는 자체 상태를 갖는다. 부분적으로 성공한 팬아웃 실행은 정확히 어떤 장치가 성공했는지, 어떤 것이 실패했는지, 어떤 것이 건너뛰어졌는지를 보여야 한다. “워크플로가 실패했다"는 장치별 분석 없이는 유용하지 않다.

7.2.4.3. 감사 로그 요구사항#

모든 워크플로 실행 기록은 최소한 다음을 포함해야 한다.

• 실행을 트리거한 사람 또는 시스템: 사람 신원, 시스템 이름, 트리거링 이벤트 ID
• 시작 시간과 완료 시간
• 실행된 워크플로 정의의 버전
• 워크플로가 받은 전체 입력
• 모든 단계의 출력
• 최종 결과

이 기록은 변조 방지되어야 한다. 사후에 편집할 수 없다. 규제 환경에서 오케스트레이터의 감사 로그는 변경 관리 기록이다. 이 기록이 변경될 수 있다면 변경 관리 시스템은 신뢰할 수 없다.

대부분의 오케스트레이션 도구는 자신이 소유하는 데이터베이스에 감사 로그를 기록한다. 그것이 충분한지는 컴플라이언스 요구사항에 달려 있다. 일부 조직은 데이터베이스 접근 권한이 있는 사람, 오케스트레이터 자체 데이터베이스에 대한 쿼리를 실행할 수 있는 사람을 포함하여 누구에 의한 변조도 방지하기 위해 오케스트레이션 감사 로그를 추가 전용 외부 시스템(SIEM, 쓰기 한 번 로그 저장소)으로 내보낸다.

7.2.5. 파이프라인 관리#

800개의 프로덕션 스위치를 구성하는 워크플로는 아키텍처적으로 프로덕션 소프트웨어다. 핵심 과제는 단순히 버전 관리가 아니다. 로직 자체가 관리하는 인프라만큼 신뢰할 수 있도록 워크플로 정의를 저장하고, 검증하고, 승격하는 방법이다.

워크플로 정의는 결정을 인코딩한다. 어떤 사전 점검을 실행할지, 장치에 도달할 수 없을 때 무엇을 할지, 무엇이 성공을 구성하는지. 부주의하게 변경하면 다음 번에 해당 워크플로가 실행될 때 건드리는 모든 장치에서 일어나는 일이 변경된다.

오케스트레이션 도구의 UI에서 워크플로 정의를 직접 편집하여 프로덕션 워크플로를 조용히 망가뜨리는 팀을 본 적이 있다. 다음 실행이 수정된 단계가 올바르게 처리하지 못한 장치 유형을 건드릴 때까지 아무도 알아채지 못했다. UI 편집에는 검토도, 테스트도, 롤백 경로도 없었다.

7.2.5.1. 전략#

• Git 기반 정의(Git-backed definitions): 워크플로 정의를 버전 제어에 저장하라. 오케스트레이션 도구가 로컬 UI 편집이 아닌 배포 시 Git에서 가져온다. 이것은 이력, 검토 프로세스, 그리고 이전 버전으로 롤백하는 능력을 제공한다.

• 블루/그린 파이프라인 버전(Blue/green pipeline versions): 프로덕션에서 두 가지 버전의 워크플로를 유지하라. 모든 활성 워크플로를 처리하는 현재 안정 버전과 검증 기간 후 새 실행을 받는 새 버전. 트래픽은 새 버전이 안정적으로 증명된 후에만 이동한다.

• 카나리 롤아웃(Canary rollout): 새 워크플로 버전이 먼저 소규모 실행을 처리한다. 펌웨어 업그레이드 워크플로는 전체 플릿으로 승격하기 전에 10개 장치에 새 버전을 적용할 수 있다. 문제가 800개가 아닌 10개 장치에서 드러난다.

7.2.5.2. 오케스트레이션 변경 테스트#

워크플로 정의는 프로덕션 전에 테스트할 수 있다.

• 드라이런 모드(Dry-run mode): 실제 입력에 대해 워크플로를 실행하되 네트워크를 수정하는 단계를 건너뛴다. 로직이 예상된 행동 순서를 생성하는지 확인한다.
• 스테이징 환경(Staging environment): 프로덕션에 대해 실행하기 전에 워크플로 변경을 테스트하는 데 전용으로 사용하는 장치 하위 집합.
• 섀도 실행(Shadow execution): 새 버전을 현재 버전과 병렬로 실행하되, 결과는 무시한다. 절환하기 전에 발산을 감지하기 위해 출력을 비교한다.

두 가지 다른 롤백: 워크플로 실행을 롤백한다는 것은 특정 실행으로 만든 네트워크 변경을 취소하는 것을 의미한다(섹션 7.2.3의 사가 패턴이 처리). 워크플로 정의를 롤백한다는 것은 워크플로 로직을 이전 버전으로 되돌리는 것을 의미한다. Git 참조를 전환하고, 정의를 재배포하면, 다음 실행이 이전 버전을 사용한다. 이것들은 직교 작업이다. 이를 혼동하는 것이 팀이 잘못된 것을 롤백하는 방법이다.

7.2.6. 솔루션 환경#

면책 조항: 여기에 나열된 도구들은 설명 목적의 예시이며 추천이 아니다. 각각은 다른 아키텍처와 절충점 프로파일을 가지고 있다. 팀의 역량, 기존 도구, 운영 제약에 대해 평가하라.

오케스트레이션 도구 시장은 네트워크 특화 플랫폼부터 범용 워크플로 엔진까지 광범위한 모델을 커버한다. 질문은 거의 “어느 것이 최선인가"가 아니라 항상 “어떻게 운영하는지에 맞는 것은 어느 것인가"다.

이 모든 것을 관통하는 한 가지 아키텍처 질문이 있다. 오케스트레이션 도구가 실행 엔진 역할도 하는가, 아니면 분리되어 있는가? AWX/AAP는 둘 다 하나로 합친다. Prefect, Temporal, Windmill은 별도의 실행 도구(Ansible, 커스텀 스크립트, API)를 호출하는 오케스트레이터다. 합쳐진 모델이 운영하기 더 단순하고, 분리된 모델은 실행 엔진을 독립적으로 교체할 더 많은 유연성을 제공한다. 챕터 3은 최소 결합 아래 이 절충점을 소개했다.

위 표의 AWX/AAP 행은 이를 기본 플랫폼으로 고려하는 팀을 위한 명확한 메모가 필요하다. AWX 워크플로 템플릿이 오케스트레이터이고, 개별 Ansible 작업 템플릿이 실행기다. 두 가지가 같은 플랫폼 내에서 실행되더라도 둘 사이의 아키텍처 경계는 존재한다. 모든 로직을 작업 템플릿(실행기)에 넣고 워크플로 템플릿을 단순히 연결하는 데만 사용하는 팀은 사실상 실행 프리미티브에서 오케스트레이터를 구축한 것이며, 이것은 가시성, 재시도 구성, 롤백 옵션을 제한한다. 반대로, 비즈니스 로직을 워크플로 템플릿에 넣는 팀(외부 데이터를 기반으로 한 조건부 분기, 동적 인벤토리 선택)은 AWX를 진정한 오케스트레이터로 사용하는 것이다. 이 구분이 중요한 이유는 AWX의 감사 추적, 승인 게이트, 알림 훅이 워크플로 수준 기능이기 때문이다. 모든 로직이 작업 템플릿에 있다면 구조를 재편하지 않고는 이러한 기능을 사용할 수 없다. 이것은 AWX의 한계가 아니다. 설계에서 오케스트레이션과 실행을 구분하지 않은 결과다.

이 도구들은 상당히 겹친다. Python이 Prefect와 Windmill 모두에서 실행된다. Prefect와 Temporal 모두 Ansible을 호출할 수 있다. 대략적인 시작점: 팀이 Ansible 우선이고 새로운 구성 요소를 최소화하고 싶다면 AWX 워크플로 템플릿이 자연스러운 선택이다. 소프트웨어 엔지니어링 규율이 있는 테스트 가능한 코드 우선 파이프라인을 원한다면 Prefect와 Windmill이 서로 다른 운영 모델로 작동한다. 부분 실패 하에서의 내구성이 주요 제약이라면 Temporal의 재생 모델이 이를 위해 목적 구축되어 있다. 이것을 최종 답이 아닌 평가를 위한 발판으로 취급하라.

7.2.7. 에이전틱 오케스트레이터#

7.2.1에 나열된 에이전틱 조율 접근 방식은 다른 실행 모델을 소개한다. 미리 정의된 DAG를 따르는 대신, Large Language Model (LLM)이 목표를 받고 런타임에 행동 순서를 결정한다. 에이전트는 가시성과 SoT 블록에서 현재 상태를 관찰하고, 어떤 행동이 격차를 좁히는지 추론하며, 실행기를 호출하고, 결과를 확인하기 위해 다시 관찰한다. 결과가 예상한 것이 아니라면 다시 추론한다. 결정 로직이 워크플로 정의에 인코딩되지 않는다. 모델의 추론에 있다.

전체 자동화 플랫폼에서 이를 가능하게 하는 것은 Model Context Protocol (MCP)(Model Context Protocol)다. 각 구성 요소가 MCP 서버를 노출한다. 에이전트가 추론 루프의 일부로 호출할 수 있는 정의된 도구 집합. SoT 서버는 장치 쿼리와 인텐트 조회를 노출하고, 가시성 서버는 상태 쿼리와 컴플라이언스 점검을 노출하며, 실행기 서버는 작업 트리거링과 상태 폴링을 노출한다. 에이전트는 워크플로 작성자가 가능한 모든 조합을 미리 코딩하지 않고도 상황이 요구하는 순서로 이 도구들을 호출한다.

아키텍처적 의미는 블록들이 서로에 대해 또는 에이전트에 대해 알 필요가 없다는 것이다. MCP 인터페이스가 계약이다. 오늘 DAG 기반 워크플로의 REST 호출에 응답하는 동일한 SoT가 수정 없이 AI 에이전트의 MCP 도구 호출에 응답한다. 명확한 블록 경계가 밀접한 결합이 결코 못 할 방식으로 여기서 보상을 준다.

DAG 기반 워크플로와 에이전틱 오케스트레이션은 상호 배타적이지 않다. 실제로 DAG 기반 워크플로는 일상적이고 잘 정의된 작업에 올바른 선택이다. VLAN 배포, 컴플라이언스 스캔, 펌웨어 업그레이드. 이것들은 고빈도이고, 예측 가능한 감사 추적이 필요하며, LLM 추론에 의존해서는 안 된다. 에이전틱 계층은 새로운 것을 처리한다. 인시던트 기반 수정, 이상 조사, 현재 상태가 이해될 때까지 올바른 행동 순서를 결정할 수 없는 상황. 두 가지 접근 방식은 동일한 플랫폼에 공존할 수 있으며, 상황이 알려진 패턴과 일치하지 않을 때 DAG가 에이전틱 워크플로로 라우팅한다.

이 섹션은 패턴을 소개한다. 에이전틱 오케스트레이션이 전체 네트워크에 걸쳐 지속적인 자율 운영으로 어떻게 확장되는지를 포함한 완전한 아키텍처 처리는 챕터 17에 있다.

7.3. 구현 예시#

7.3.1. 캠퍼스 VLAN 서비스 라이프사이클 오케스트레이션#

파트 2 전반에 걸쳐 동일한 캠퍼스 네트워크를 따라왔다. 챕터 4에서 Nautobot에 VLAN 서비스 요청을 저장했다. VLAN ID, 서브넷, 대상 스위치, 벤더별 구성 템플릿. 챕터 5에서 AWX를 통해 Ansible을 사용하여 캠퍼스 스위치에 그 구성을 푸시했다. 챕터 6에서 배포를 검증하고 서비스 모니터링을 시작했다.

우리가 다루지 않은 것은 누가 그 모든 것을 조율하는가다. 각 챕터에는 묵시적인 가정이 있었다. 엔지니어가 각 단계를 수동으로 실행했다. 여기서 그것을 명시적으로 만들고 엔지니어를 워크플로로 대체한다.

시나리오

애플리케이션 팀이 새 애플리케이션 세그먼트를 요청했다. VLAN app-payments, 서브넷 10.22.14.0/24, Cisco와 Arista 스택 전반에 걸쳐 building-b의 모든 액세스 스위치에 배포. 요청이 ServiceNow를 통해 제출되었고 방금 최종 승인을 받았다.

그 승인이 웹훅을 발사한다. 오케스트레이터가 이를 수신하고 VLAN 서비스 배포 워크플로를 시작한다.

워크플로

이것을 이미 실행 계층에 있는 AWX 워크플로 템플릿으로 구현한다. AWX는 조건부 분기와 승인 게이트가 있는 작업 템플릿을 연결하는 워크플로 템플릿을 지원하며, 이 시나리오에 충분하다.

flowchart TD
    A[ServiceNow 웹훅\nVLAN 요청 승인됨] --> B[1단계: SoT 검증\nNautobot에서 장치 레코드와\nVLAN 정의 완전성 쿼리]
    B --> C{SoT 데이터 완전?}
    C -- 아니오 --> Z1[중단: 엔지니어에게 알리고\nServiceNow 티켓 업데이트]
    C -- 예 --> D[2단계: 사전 점검 팬아웃\n모든 대상 스위치에서\n도달 가능성과 VLAN 상태]
    D --> E{사전 점검 통과?}
    E -- 실패 --> Z2[중단: 장치별 실패를\nServiceNow에 보고]
    E -- 통과 --> F[3단계: 승인 게이트\n프로덕션 실행 전\n선택적 사람 승인]
    F --> G[4단계: 배포 실행\nAWX를 통한 Ansible 플레이북]
    G --> H[5단계: 검증 팬아웃\n스위치당 가시성 점검]
    H --> I{모든 장치 검증됨?}
    I -- 완전 성공 --> J[6단계: 알림\nServiceNow 티켓 업데이트\nSlack에 게시]
    I -- 부분 실패 --> K[6a단계: 사가 보상\n실패 범위만 롤백]
    K --> J

1단계: SoT 검증

오케스트레이터는 네트워크를 건드리기 전에 장치 레코드와 VLAN 정의가 완전한지 확인하기 위해 Nautobot을 쿼리한다. 이 가드 단계는 실행기의 책임이 아닌 오케스트레이터의 책임이다. 실행기는 유효한 입력을 받아야 하며, 푸시 중간에 잘못된 데이터를 발견해서는 안 된다. 어떤 점검이 실패하면 워크플로가 중단되고 특정 격차를 ServiceNow 티켓에 업데이트한다. (SoT 검증이 어떻게 구성되는지는 챕터 4에서 다룬다.)

2단계: 대상 스위치에 걸친 사전 점검 (팬아웃)

워크플로가 모든 대상 스위치에 병렬로 팬아웃된다. 각 브랜치가 경량 사전 점검을 실행한다. 도달 가능성, VLAN 테이블 상태, 사용 가능한 용량. 팬인 단계가 결과를 분류하고 분기한다. 실패 임계값은 구성 가능하다. 오케스트레이션 측면에서 중요한 것은 이것이 조건부 분기가 있는 팬아웃/팬인 패턴이지, 순차적 폴링이 아니라는 것이다. (사전 점검 실행 패턴은 챕터 5에 있다.)

3단계: 승인 게이트

프로덕션 푸시 전 선택적 사람 승인. 엔지니어는 승인 또는 거부할 30분이 있고, 타임아웃이 자동으로 진행되며 기록된다. 오케스트레이터는 승인이 도달하거나 창이 만료될 때까지 외부 의존성이 있는 대기 상태로 워크플로를 유지한다.

승인 게이트는 아키텍처 결정이 아닌 정책 결정이다. 성숙도가 높은 팀은 종종 이것을 제거하고 사전 점검 결과에서 도출된 자동화된 신뢰 임계값으로 사람 승인을 대체한다. 사전 점검 커버리지가 95%를 초과하고 심각한 실패가 없다면 자동으로 진행한다. 여전히 신뢰를 구축 중인 팀은 게이트를 유지한다. 챕터 1에서 논의된 자동화 성숙도 스펙트럼의 다른 지점에서 두 가지 선택 모두 유효하다.

4단계: 배포 실행

오케스트레이터가 챕터 5의 AWX 작업 템플릿을 트리거하고, SoT 검증 단계의 파라미터를 전달하고, 결과를 기다린다. 실행기가 나머지를 처리한다. 이것이 실제 관심사의 분리다. 오케스트레이터가 행동하기로 결정하고, 실행기가 행동한다.

5단계: 가시성 검증 (팬아웃)

배포 후 두 번째 팬아웃이 대상 스위치당 검증 작업을 실행한다. VLAN이 VLAN 테이블에 나타나는가, 인터페이스가 예상 상태인가? 팬인이 결과를 분류한다. 완전 성공, 부분 성공, 또는 실패. (가시성 계층이 무엇을 어떻게 검증하는지는 챕터 6에서 다룬다.)

6단계: 결과 라우팅

완전 성공은 워크플로를 닫는다. ServiceNow 티켓이 업데이트되고 요약이 Slack에 게시된다. 부분 실패는 사가 보상을 트리거한다. 롤백 플레이북이 검증에 실패한 장치에 대해서만 실행되고, 성공한 장치는 구성을 유지한다. ServiceNow 티켓이 장치별 결과를 기록한다.

오프닝의 엔지니어로 돌아가서

이 워크플로는 챕터 3 NAF 프레임워크의 일곱 가지 구성 요소가 함께 작동하는 것을 보여준다. Nautobot(소스 오브 트루스)이 인텐트를 제공하고, AWX(실행기)가 이를 적용하고, Prometheus(가시성)가 결과를 검증하고, AWX 워크플로 템플릿(오케스트레이터)이 전체 순서를 조율하고, ServiceNow 웹훅(프레젠테이션, 챕터 8에서 다룸)이 애플리케이션 팀의 요청에서 전체 흐름을 트리거했다.

오프닝 이야기의 엔지니어는 아직 여기 있다. 승인 게이트가 발사될 때 검토하는 사람이 그녀다. 사가 패턴이 플래그를 세웠지만 완전히 해결하지 못한 부분 실패를 조사하는 사람도 그녀다. 여전히 전문가다. 오케스트레이터가 그녀에게서 가져간 것은 전문성이 아니다. 머릿속에서 순서를 유지하고, 단계별로 다시 실행하고, 그것을 할 수 있는 유일한 사람이 되는 부담이다. 그것이 자동화 없는 조율이 실제로 드는 비용이다.

7.4. 요약#

이 챕터는 Orchestrator가 작동하는 자동화 도구 집합을 하나처럼 동작하는 시스템으로 변환하는 구성 요소임을 확립했다. 없으면 조율은 수동으로 남고, 실패는 사람의 개입이 필요하며, 네트워크의 규모가 실제로 가능한 자동화의 한계가 된다.

핵심적으로 오케스트레이션은 다단계 프로세스가 어떻게 구조화되고 실행되는지를 정의하는 워크플로 엔진에 달려 있다. 단일 구조, DAG, 코레오그래피, 에이전틱 조율 중의 선택은 도구 선호가 아닌 아키텍처 결정이다. 명명된 패턴(순차, 팬아웃, 조건부, 사가)이 있는 DAG 모델은 네트워크 자동화의 프로덕션 표준이다. 섹션 7.2.7에서 Model Context Protocol (MCP)를 인터페이스 계층으로 소개한 에이전틱 패턴은 다른 절충점을 나타내며 챕터 17에서 완전히 다룬다.

트리거링은 외부 세계가 오케스트레이터에 도달하는 방법을 정의한다. 실행 계층 트리거링(챕터 5)과 오케스트레이션 계층 트리거링의 구분은 아키텍처적으로 중요하다. 하나는 단일 장치 변경을 이끌고, 다른 하나는 조율된 다중 시스템 워크플로를 이끈다. 이벤트 기반 자동화와 폐루프 패턴은 자동화된 트리거가 사람의 검토 없이 발사되기 때문에 멱등성과 중복 제거의 협상 불가능한 속성을 정확히 상속한다.

복원력과 확장성은 데모에서 작동하는 자동화와 새벽 3시에 작동하는 자동화를 분리한다. 내구성 있는 상태, 일시적 실패와 영구적 실패를 구분하는 재시도 전략, 부분 실패 보상을 위한 사가 패턴, 대규모 장치 집단을 위한 동시성 제어는 나중에 추가하는 선택적 기능이 아니다. 오케스트레이터가 조건이 이상적이지 않을 때 신뢰받을 수 있는지를 정의한다.

상태와 추적성은 무엇이 실행되었는지, 누가 트리거했는지, 모든 단계가 무엇을 생성했는지의 기록을 제공한다. 이 기록은 네트워크 운영 상태(챕터 6)와 네트워크 인텐트(챕터 4)와 구별된다. 변조 방지 감사 로그는 컴플라이언스 요구사항이지 사후 고려가 아니다. 파이프라인 관리가 루프를 닫는다. 워크플로 정의는 프로덕션 소프트웨어이며 자동화 플랫폼에서 실행되는 다른 코드와 동일한 규율로 버전 관리되고, 테스트되고, 승격되어야 한다.

캠퍼스 VLAN 서비스 시나리오는 이 다섯 가지 기능을 하나로 모았다. ServiceNow 웹훅으로 트리거된 10단계 워크플로가 조율 루프에 엔지니어 없이 SoT 검증, 사전 점검, 실행, 가시성 검증, 사가 보상을 조율했다. 자연스러운 다음 질문은 누가 이 워크플로가 실행 중인 것을 보고 이를 트리거한 애플리케이션 팀이 어떻게 진행 상황을 추적하는가이다. 그것이 챕터 8에서 다루는 프레젠테이션 계층이다.

💬 Found something to improve? Send feedback for this chapter