Orchestration 방식이란?
SAGA Orchestration은 중앙 조정자(Saga Orchestrator)가 모든 트랜잭션 단계를 직접 관리하는 방식이다.
Orchestrator는 각 마이크로서비스에 "명령(Command)"을 보내고, 서비스는 해당 명령을 처리한 뒤 "결과(Reply)"를 Orchestrator에게 알려준다.
즉, Choreography가 이벤트를 구독하며 자율적으로 움직이는 방식이라면,
Orchestration은 중앙 조정자가 전체 흐름을 명시적으로 통제하는 방식이다.
👉 오케스트라 지휘자처럼 각 서비스를 순서대로 지휘하는 구조
Orchestration 기반 주문 처리의 핵심 특징 정리
SAGA Orchestration 방식의 핵심은 전체 Saga 생명주기를 중앙에서 명시적으로 기록하고 제어한다는 점이다.
Saga가 시작되면 Orchestrator는 DB에 해당 Saga의 상태를 저장하고, 단계가 진행될 때마다
Order_Initiated → Inventory_Reserved → Payment_Processed → Delivery_Scheduled …
과 같이 상태(State)를 명확하게 전이시키며 기록한다.
이 구조 덕분에 전체 흐름이 하나의 워크플로우처럼 드러나며, 무엇이 언제 실행되고 실패했는지도 한눈에 파악할 수 있다.
1. 명령(Command) 기반의 흐름 제어
Orchestrator는 각 단계에서 특정 서비스에 명확한 명령을 보낸다.
예를 들면
- ReserveInventoryCommand
- ProcessPaymentCommand
처럼 “무엇을 수행해야 하는지”가 분명하게 정의된 명령(Command)을 전달하고, 각 서비스는 해당 명령을 실행한 뒤 Reply로 결과를 반환한다.
이 구조를 통해 Orchestrator는 다음과 같은 흐름을 완전히 통제할 수 있다.
- 어떤 서비스가 언제 호출되는지
- 특정 단계가 실패하면 어떤 보상 트랜잭션을 실행해야 하는지
- 보상의 순서를 어떻게 진행해야 하는지
즉, 전체 Saga의 흐름을 중앙에서 명확하게 계획하고 실행할 수 있다.
2. 상태 추적 및 성능 분석이 매우 용이함
Choreography에서는 서비스마다 이벤트를 발행하고 처리하기 때문에 전체 흐름을 파악하려면 각 서비스의 로그, 메시지 브로커의 트레이스 등을 모아 퍼즐처럼 맞춰야 한다.
반면 Orchestration에서는 Orchestrator만 확인하면 아래 내용을 모두 알 수 있다.
- Saga의 전체 생명주기
- 어떤 단계에서 실패했는지
- 재시도(retry) 횟수
- 보상 트랜잭션 기록
- 단계별 수행 시간 및 성능 분석
이러한 명확한 추적 기능은 운영 및 디버깅에 매우 유리하다.
3. 장애 복구가 간편함
Orchestrator 서버가 죽더라도 문제가 없다.
Orchestrator는 자신의 상태를 DB에 저장해 두기 때문에, 재기동 시 마지막 상태를 읽어 남은 단계를 이어서 처리할 수 있다.
이 과정은 Choreography보다 훨씬 간단하며 안정적이다.
(Choreography의 경우 이벤트 재처리, 중복 문제, 순서 보장이 복잡하게 얽힘)
4. 보상 트랜잭션을 정확한 역순으로 보장
보상 트랜잭션은 SAGA의 핵심 개념 중 하나인데, Orchestration에서는 이를 정확한 역순으로, 중앙에서 통제하며 수행할 수 있다.
예를 들어 정상 흐름이
1. 재고 차감
2. 결제
3. 배송 예약이라면, 결제 단계에서 실패했을 때 보상 순서는 다음과 같이 명확하다.
→ 배송 취소
→ 결제 취소
→ 재고 복구Orchestrator는 전체 단계의 순서를 알고 있고, 각 단계의 실패·성공 여부도 기록하고 있기 때문에 정확한 보상 범위와 보상 순서를 안전하게 실행할 수 있다.
Orchestration 기반 SAGA - 성공 & 실패 시나리오
Orchestration 방식에서 각 단계는 로컬 트랜잭션으로 독립적으로 실행되지만, 단계 전환 · 상태 저장 · 보상(rollback) 여부는 모두 Orchestrator가 명확히 결정한다.
성공 시나리오: Orchestrator가 전체 주문 흐름을 지휘하는 경우
1. 주문 생성 & Saga 시작
사용자가 주문을 요청하면 OrderService가 주문을 생성하고, 이를 바탕으로 SagaOrchestrator가 SAGA 생명주기를 시작한다.
Saga 상태는 Order_Initiated로 기록된다.
2. 재고 예약 단계 (Inventory Reserved)
Orchestrator는 InventoryService에게 재고를 예약하라(Reserve)는 명령(Command)을 전송한다.
재고 처리가 성공하면 Orchestrator는 상태를 Inventory_Reserved로 전환한다.
3. 결제 처리 단계 (Payment Processed)
재고가 확보되었으므로 Orchestrator는 PaymentService에 결제를 진행하라는 명령을 보낸다.
결제가 성공하면 Saga 상태는 Payment_Processed로 바뀐다.
4. 배송 예약 단계 (Delivery Scheduled)
결제가 완료되면 Orchestrator는 DeliveryService에게 배송 예약 명령을 보낸다.
배송 준비까지 성공하면 상태는 Delivery_Scheduled로 기록된다.
5. Saga 완료 (Completed)
모든 단계가 성공적으로 끝나면 Orchestrator는 Saga 상태를 Completed로 저장하고, OrderService에 최종 성공을 알리며 주문 처리 흐름이 성공적으로 종료된다.
👉 이 흐름에서 중요한 점은 각 단계의 성공 여부와 다음 단계로의 전환 시점을 오케스트레이터가 명확하게 알고 통제한다는 점이다.
실패 시나리오: 결제 실패 시 보상 트랜잭션 실행 흐름
1. Saga 시작 & 재고 예약까지 정상 처리
주문 생성과 재고 예약 단계는 정상적으로 진행되어 Saga 상태는 Inventory_Reserved까지 전이된다.
2. 결제 단계에서 실패 발생
Orchestrator가 결제 명령을 전송했으나, PaymentService는 결제 실패(예: 잔액 부족, 카드 오류)를 Reply로 반환한다.
Saga 상태는 Payment_Failed로 변경된다.
3. 보상 트랜잭션 시작 (Compensation Begins)
Orchestrator는 즉시 보상 단계를 진행한다.
첫 번째 보상 작업은 재고 복구(Release)다.
InventoryService에 재고를 다시 증가시키라는 명령을 보낸다.
4. 재고 복구 성공 -> Saga 보상 완료
재고가 정상적으로 복구되면 Reply가 반환되고, Orchestrator는 Saga 상태를 Compensated로 저장한다.
5. 주문 취소 처리
보상 절차가 모두 종료되면 Orchestrator는 OrderService에게 주문 취소를 알리고 전체 Saga를 종료한다.
👉 Orchestration에서는 보상 로직이 "자율적 이벤트"가 아니라 Orchestrator가 결정하고 명령함으로써 보상 범위와 보상순서를 매우 안정적으로 보장할 수 있다.
Orchestration 방식의 장단점
SAGA Orchestration은 전체 분산 트랜잭션을 중앙에서 조율하기 때문에 흐름 제어와 상태 관리가 매우 명확해지는 반면, 중앙 집중 구조가 주는 부담도 함께 존재한다.
Orchestration의 장점
1. 전체 흐름을 명확히 제어할 수 있다
Orchestrator는 모든 단계를 "명령(Command)"으로 지시하고, 각 단계의 성공/실패 여부를 직접 확인하며 다음 단계로 전이시킨다.
덕분에 SAGA 전체 흐름이 선명하게 보이고, 서비스 간 의존성과 순서를 중앙에서 안정적으로 통제할 수 있다.
즉,
- 주문이 지금 어디까지 진행되었는지
- 어떤 단계에서 실패했는지
- 보상 트랜잭션이 어디까지 실행되었는지
를 한 곳에서 정확히 파악 가능하다.
2. 중앙 집중식 모니터링이 가능하다
모든 Saga 상태가 Orchestrator의 DB에 저장되기 때문에 추적 및 모니터링이 Choreography 보다 압도적으로 쉽다.
예를 들어 특정 주문의 SAGA를 조회하면 다음 내용이 즉시 확인된다.
- 어떤 경로로 처리되었는지
- 각 단계에서 얼마의 시간이 소요되었는지
- 어느 구간에서 병목이 발생했는지
- 어떤 데이터가 오갔는지
이러한 가시성은 운영 환경에서 성능 분석 · 장애 대응 · 최적화에 매우 큰 강점이 된다.
3. 복잡한 로직과 상태 처리가 편하다
오케스트레이터에 비즈니스 로직이 집중되기 때문에 일반적인 백엔드 서비스에서 구현하던 안정성 패턴들을 그대로 적용하기 쉽다.
- 조건부 분기
- 병렬 실행
- 재시도 / 백오프
- 타임아웃
- 서킷 브레이커
- 장애 감지 후 스킵 처리
이러한 로직들을 오케스트레이터 안에서 일관성 있게 관리할 수 있다.
예를 들어, 두 개의 서비스를 동시에 호출하고 싶다면 오케스트레이터가 스레드를 두 개 띄워 병렬로 명령을 보내고 결과를 취합하면 끝이다.
구현 난이도가 낮으며 예측이 가능하다.
4. 트랜잭션 실행 과정의 가시성이 뛰어나다
Orchestrator는 Saga의 모든 단계를 기록하므로 트랜잭션의 "흐름과 시간"을 실시간으로 파악할 수 있다.
- 어느 단계가 병목인지
- 어떤 데이터가 전달되는지
- 전체 처리 시간은 얼마인지
이 모든 정보를 기반으로 성능 최적화가 가능하다.
Orchestration의 단점
1. 중앙 집중 구조로 인한 부하와 운영 부담
모든 요청이 Orchestrator를 반드시 거치기 때문에 자연스럽게 트래픽이 한 지점에 집중된다.
물론 Orchestrator 자체는 수평 확장이 가능하지만, 이때 다음 문제들이 추가로 발생한다.
- Orchestrator 간 상태 동기화 문제가 생길 수 있음
- 공유 데이터베이스(DB)가 새로운 병목 지점이 될 수 있음
- 동기 호출이 많아 연결 수가 급증할 수 있음
중앙 집중 구조는 CPU/메모리 부하뿐 아니라 네트워크 연결 유지, 동기 요청 처리, DB 락 경쟁까지 고려해야 한다.
2. 서비스 의존도 증가
Orchestrator는 각 서비스에 명령을 전달하기 때문에 서비스 내부의 세부적인 규칙들을 반드시 알고 있어야 한다.
- 통신 방식(REST/gRPC 등)
- 인증/인가 방식
- 에러 코드 규칙
- 서비스의 기술적 특징
새로운 서비스가 추가되면 오케스트레이터 코드도 반드시 수정 · 배포해야 한다.
결과적으로 Orchestrator가 비대하고 복잡해지는 리스크가 있다.
3. SPOF(Single Point of Failure) 가능성
Orchestrator는 Saga의 중심이기 때문에 장애가 발생하면 곧바로 전체 흐름이 중단될 가능성이 있다.
물론 클러스터링 · 고가용성 구성을 통해 완화할 수 있지만, 구성 · 운영 난이도가 증가한다.
'아키텍처 & 설계(Architecture & Design) > MSA' 카테고리의 다른 글
| SAGA: Orchestration vs Choreography 비교 (1) | 2025.11.28 |
|---|---|
| Choreography 기반 SAGA 패턴 이해하기 — 분산 환경에서의 트랜잭션 처리 방식 (0) | 2025.11.17 |
| SAGA 패턴과 에서의 격리성(Isolation) 문제 (0) | 2025.11.10 |
| SAGA 패턴과 멱등성 – 분산 트랜잭션에서 꼭 짚고 넘어가야 할 관계 (0) | 2025.11.10 |
| 분산 트랜잭션의 한계와 SAGA 패턴 (0) | 2025.11.07 |
