오케스트레이션

오케스트레이션은 여럿을 하나의 조정자가 대신 지휘하는 일입니다. 사람이 하나씩 챙기던 배치와 차례를 그 조정자에게 맡깁니다. 무엇을 지휘하는지는 자리마다 다릅니다.

상세

악단에서 소리를 내는 사람은 연주자입니다. 지휘자는 한 음도 내지 않습니다. 누가 언제 들어오고 얼마나 크게 갈지만 정합니다.

오케스트레이션은 여럿을 다루는 일에서 지휘자에 해당하는 자리를 따로 세우는 것입니다. 그 자리를 조정자라고 부르겠습니다. 낱개는 자기 일만 합니다. 낱개를 어디에 놓을지, 어떤 차례로 돌릴지, 몇 개를 살려 둘지는 조정자가 대신 정합니다. 정해 놓고 끝이 아닙니다. 조정자는 낱개들이 지금 어떤 상태인지를 계속 들여다봅니다.

사람이 조정자에게 말하는 방법은 원하는 것을 적어 두는 것입니다. 조정자는 그 적힌 것을 읽고 낱개들을 그리로 몰아갑니다.

flowchart TD
    U["사람"] -->|"원하는 것을 적는다"| C["조정자"]
    C -->|"적힌 차례대로 시킨다"| W["낱개들"]
    C -->|"적힌 상태와의 차이를 메운다"| W
    W -->|"실제 상태"| C

몰아가는 방식은 두 결로 갈립니다. 하나는 적힌 차례를 그대로 실행하는 것입니다. 먼저 이것, 다음 저것, 그 다음 그것입니다. 다른 하나는 끝에 있어야 할 상태만 적어 두는 것입니다. 조정자는 실제 상태를 계속 잽니다. 적힌 상태와 다르면 그 차이를 메웁니다. 어느 쪽을 이 말의 본뜻으로 볼지는 문서마다 갈립니다.

배경

낱개가 몇 개뿐이면 사람이 다 챙길 수 있습니다. 어느 기계에 무엇을 올릴지 사람이 정합니다. 어떤 작업을 어떤 차례로 돌릴지도 사람이 기억합니다. 죽은 것이 있으면 사람이 다시 띄웁니다.

낱개와 기계가 늘면 이 방식이 무너집니다. 배치 규칙이 사람 머릿속에만 있어서 다른 사람은 왜 그 자리에 올렸는지 모릅니다. 밤에 죽은 것을 아침에 압니다. 작업 사이의 앞뒤 관계를 문서에 적어 두어도 실제로 지켜졌는지는 아무도 못 봅니다.

그래서 이 일을 사람 대신 계속 들여다볼 자리가 필요해졌습니다. 규칙을 그 자리에 적어 두면 사람은 규칙만 고치면 됩니다. 이름은 악단에서 빌려 왔습니다. 낱개는 각자 자기 일만 하고 맞물리는 방식은 지휘자가 정한다는 그림이 같습니다.

갈래

무엇을 조율 대상으로 삼느냐가 축입니다. 조정자가 하는 일의 골자는 같습니다. 지휘받는 낱개가 무엇이냐에 따라 부르는 이름과 근거로 삼는 문서가 갈립니다.

컨테이너와 워크로드

지휘받는 것은 컨테이너이고, 그것을 올릴 자리는 머신입니다. 쿠버네티스 공식 문서는 클러스터가 제어 평면 하나와 노드라 부르는 워커 머신 집합으로 이뤄진다고 적습니다. 노드가 애플리케이션 워크로드를 이루는 파드를 안고 돕니다. 제어 평면이 그 노드와 파드를 관리합니다. 조정자가 대신 정하는 것은 세 가지로 적혀 있습니다. 컨테이너마다 얼마만큼의 프로세서와 메모리가 필요한지 알려 주면 자원을 가장 잘 쓰도록 노드에 끼워 넣습니다. 배포된 컨테이너의 원하는 상태를 적으면 실제 상태를 정해진 속도로 그 상태에 맞춰 갑니다. 실패한 컨테이너를 다시 띄웁니다. 사용자가 정한 헬스 체크에 응답하지 않는 컨테이너는 죽입니다. 서비스할 준비가 될 때까지 클라이언트에 알리지 않습니다.

같은 문서가 이 말의 뜻에 선을 긋는 대목도 있습니다. 오케스트레이션의 기술적 정의를 「정해진 워크플로의 실행 — 먼저 A, 다음 B, 다음 C」라고 적습니다. 그리고 쿠버네티스는 한낱 오케스트레이션 시스템이 아니라고 못 박습니다. 오히려 오케스트레이션의 필요를 없앤다고 적습니다. 쿠버네티스는 현재 상태를 주어진 원하는 상태로 계속 몰아가는 독립적이고 조합 가능한 제어 프로세스들의 모음이라고 적습니다. 중앙 집중식 제어도 필요하지 않다고 적습니다. 같은 일을 하는 도커 스웜 문서는 반대로 자기 기능을 오케스트레이션이라 부릅니다. 스웜을 만들거나 관리하는 데 별도의 오케스트레이션 소프트웨어가 필요 없다는 뜻입니다. 스웜의 매니저 노드는 클러스터 상태를 끊임없이 감시해 실제 상태와 적어 둔 원하는 상태의 차이를 맞춥니다. 노마드도 자기를 워크로드 오케스트레이터라고 소개합니다.

sequenceDiagram
    participant 매니저
    participant 워커
    매니저->>워커: 복제본 10개를 나눠 배정
    워커--)매니저: 실제 상태
    Note over 워커: 두 개를 안고 있던 워커가 죽는다
    매니저->>워커: 모자란 두 개를 새로 만들어 배정

도커 스웜 문서가 든 예가 그림 그대로입니다. 복제본 열 개짜리 서비스를 띄워 둡니다. 그중 두 개를 안고 있던 워커 머신이 죽으면 매니저가 죽은 두 개를 대신할 복제본 두 개를 새로 만듭니다. 그리고 돌고 있는 워커에 그 둘을 배정합니다.

태스크와 워크플로

지휘받는 것은 태스크이고, 정해야 할 것은 자리가 아니라 차례와 시각입니다. 아파치 에어플로우 공식 문서는 자기를 워크플로를 개발하고 스케줄링하고 모니터링하는 오픈소스 플랫폼이라고 적습니다. 시각 기반이나 이벤트 기반의 배치 파이프라인, 머신러닝, 모델 학습이 그 워크플로의 예로 적혀 있습니다.

워크플로 하나를 통째로 담는 모델의 이름이 DAG(Directed Acyclic Graph, 방향성 비순환 그래프)입니다. 문서는 DAG 를 워크플로를 실행하는 데 필요한 모든 것을 감싼 모델이라고 적습니다. 속성으로는 넷을 듭니다. 언제 돌릴지를 정하는 스케줄, 워커에서 도는 개별 작업 단위인 태스크, 태스크가 실행되는 차례와 조건인 태스크 의존 관계, 워크플로 전체가 끝났을 때 할 일인 콜백입니다.

의존 관계는 태스크 사이에 앞뒤를 걸어 둡니다. 앞선 태스크 하나에 뒤따르는 태스크를 둘 걸면 이런 모양이 됩니다.

flowchart TD
    A["앞선 태스크"] --> B["뒤따르는 태스크"]
    A --> C["뒤따르는 다른 태스크"]

앞선 태스크에서 뒤따르는 태스크로 화살표가 갑니다. 앞선 태스크에서 뒤따르는 다른 태스크로도 갑니다. 앞선 태스크가 끝난 뒤에 뒤따르는 두 태스크가 돕니다. 이 차례를 조정자가 지킵니다.

서비스 호출

지휘받는 것은 참여자들이 주고받는 상호작용입니다. BPMN(Business Process Model and Notation) 2.0 명세는 모델링 대상을 셋으로 가릅니다. 프로세스, 곧 오케스트레이션과 코레오그래피, 그리고 이 둘을 담을 수 있는 콜라보레이션입니다.

명세는 조직 안쪽의 비공개 비즈니스 프로세스를 흔히 워크플로 프로세스라고 불러 왔다고 적습니다. 그리고 웹 서비스 영역에서 흔히 쓰이는 또 다른 동의어가 「서비스의 오케스트레이션」이라고 덧붙입니다. 이 자리의 조정자는 참여자 하나입니다. 그 참여자의 관점에서 활동의 흐름이 정해집니다.

예시

쿠버네티스 디플로이먼트

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

.spec.replicas 에 3 을 적었습니다. 이 디플로이먼트는 레플리카셋을 만듭니다. 그 레플리카셋이 복제된 파드 세 개를 만듭니다. 파드 수가 적어 둔 수보다 적으면 .spec.template 으로 새 파드를 띄웁니다. 셀렉터에 걸리는 파드 수가 .spec.replicas 를 넘거나 그 템플릿이 .spec.template 과 다르면 그 파드들을 종료할 수 있습니다. 사람이 적은 것은 개수 하나입니다. 어느 노드에 올릴지도, 죽은 것을 언제 다시 띄울지도 적지 않았습니다.

에어플로우 DAG

with DAG(
    "tutorial",
    default_args=default_args,
    description="A simple tutorial DAG",
    schedule=timedelta(days=1),
    start_date=datetime(2021, 1, 1),
    catchup=False,
    tags=["example"],
)

schedule=timedelta(days=1) 이 언제 돌릴지를 정합니다. 하루에 한 번입니다.

t1 >> t2 >> t3
t1 >> [t2, t3]

차례는 비트 시프트 연산자로 잇습니다. t1 >> t2 는 t1 다음에 t2 라는 뜻입니다. 같은 관계를 t2 << t1 로 뒤집어 적을 수도 있습니다. 여러 개를 이으면 t1 >> t2 >> t3 이 됩니다. 리스트를 주면 t1 >> [t2, t3] 처럼 여러 태스크를 한꺼번에 의존으로 걸 수 있습니다.

경계

코레오그래피

참여자들이 정해진 메시지를 주고받아 일을 끝내는 것도 오케스트레이션인가. 아닙니다.

BPMN 2.0 명세는 코레오그래피가 프로세스의 한 종류이지만 목적과 행동이 표준 BPMN 프로세스와 다르다고 적습니다. 표준 프로세스, 곧 오케스트레이션 프로세스는 특정 참여자나 조직의 활동 흐름을 정의합니다. 코레오그래피는 그와 대비되게 비즈니스 참여자들이 상호작용을 조율하는 방식을 형식화합니다. 초점이 참여자 안에서 수행되는 일의 오케스트레이션이 아니라 참여자들 사이의 메시지 교환에 있다고 명세가 못 박습니다.

W3C(World Wide Web Consortium) 의 WS-CDL(Web Services Choreography Description Language) 명세도 같은 방향으로 적습니다. 코레오그래피는 전역 관점에서 참여자들의 공통되고 상보적인 관찰 가능한 행동을 정의해 피어 투 피어 협업을 기술하는 것입니다. 그렇게 순서 지어진 메시지 교환이 공통의 비즈니스 목표를 이룹니다.

가르는 선은 지휘하는 자리가 하나 있느냐입니다. 한 참여자의 관점에서 활동의 흐름이 적혀 있으면 오케스트레이션입니다. 그런 자리 없이 참여자들이 서로 무엇을 주고받기로 했는지만 전역 관점에서 적혀 있으면 코레오그래피입니다.

스케줄링

어느 머신에 올릴지 고르는 것이 오케스트레이션인가. 그 일부입니다.

쿠버네티스 공식 문서는 kube-scheduler 를 기본 스케줄러라고 적습니다. 제어 평면의 한 부분으로 돈다고도 적습니다. 하는 일은 새로 만들어졌거나 아직 배치되지 않은 파드에 알맞은 노드를 고르는 것입니다. 파드 안의 컨테이너마다, 그리고 파드 자체마다 요구가 다르므로 그 요구를 못 맞추는 노드를 걸러 냅니다. 원한다면 자기 스케줄링 컴포넌트를 따로 짜서 대신 쓸 수 있도록 설계돼 있다고도 적습니다.

배치를 고르는 일은 조정자가 하는 여러 일 중 하나이고, 갈아 끼울 수 있는 부품입니다. 적어 둔 개수를 유지하는 일, 실패한 것을 다시 띄우는 일, 원하는 상태로 정해진 속도로 옮겨 가는 일은 같은 문서에 그 옆의 별개 항목으로 적혀 있습니다.

관련 항목

이것에 관여하는 역할·참여자

제어 평면 · 매니저 노드 · kube-scheduler · 제어 루프 · 클라이언트

이것이 지휘하는 낱개

컨테이너 · 파드 · 노드 · 워커 노드 · 클러스터 · 태스크 · 레플리카셋 · 배치 잡

사람이 조정자에게 적어 두는 명세

원하는 상태 · 매니페스트 · 디플로이먼트 · DAG · 워크플로 · 태스크 의존 관계 · 콜백 · 비즈니스 프로세스

조정자가 대신 맡는 기능

자가 치유 · 롤아웃 · 롤백 · 스케일링 · 빈 패킹 · 서비스 디스커버리 · 로드 밸런싱 · 헬스 체크 · 스케줄링 · 모니터링

이 일을 맡는 도구

쿠버네티스 · 도커 · 도커 스웜 · 노마드 · 아파치 에어플로우

이것이 다루는 워크로드 유형

파이프라인 · 머신러닝 · 워크로드

이것과 맞세워지는 대립 개념

코레오그래피 · 피어 투 피어 · 콜라보레이션 · 메시지

이것을 정의하는 표준·기구

BPMN · WS-CDL · WS-BPEL(Web Services Business Process Execution Language) · W3C · OMG(Object Management Group) · OASIS(Organization for the Advancement of Structured Information Standards)