오케스트레이션 vs. 코레오그래피 - 이벤트 기반 백엔드 통합

소개

현대 백엔드 시스템, 특히 마이크로서비스 아키텍처 내에서 원활한 통신과 견고한 데이터 흐름은 무엇보다 중요합니다. 시스템의 복잡성과 규모가 커짐에 따라 기존의 긴밀하게 결합된 통합은 민첩성과 복원력을 저해하는 병목 현상이 되는 경우가 많습니다. 여기서 이벤트 기반 아키텍처가 빛을 발하며 서비스 간 통신을 위한 유연하고 확장 가능한 패러다임을 제공합니다. 이 패러다임 내에서 복잡한 비즈니스 프로세스를 조정하기 위한 두 가지 주요 패턴이 등장합니다. 바로 오케스트레이션과 코레오그래피입니다. 각각의 미묘한 차이, 장점 및 절충점을 이해하는 것은 성능과 유지 관리 가능성 모두를 갖춘 분산 시스템을 구축하려는 아키텍트 및 개발자에게 매우 중요합니다. 이 글은 이러한 두 가지 강력한 접근 방식을 명확히 하여 실제 시나리오에서의 적용을 이해할 수 있는 명확한 경로를 제공할 것입니다.

이벤트 기반 시스템에서의 조정 명확히 이해하기

오케스트레이션 및 코레오그래피의 구체적인 내용으로 들어가기 전에 이벤트 기반 아키텍처의 기반을 형성하는 주요 용어에 대한 공통된 이해를 확립해 봅시다.

• 이벤트(Event): 과거에 발생한 일에 대한 기록입니다. 이벤트는 'OrderCreated' 또는 'PaymentProcessed'와 같이 불변하는 사실입니다. 일반적으로 상태 변경을 포함하지만 이에 반응하는 방법에 대한 로직은 포함하지 않습니다.
• 마이크로서비스(Microservice): 단일 비즈니스 기능을 수행하는 작고 자율적인 서비스입니다. 마이크로서비스는 종종 이벤트를 통해 서로 통신합니다.
• 메시지 브로커(Message Broker) 또는 이벤트 버스(Event Bus): 메시지/이벤트를 수신, 큐잉 및 전달하여 서비스 간의 통신을 촉진하는 미들웨어입니다. Apache Kafka, RabbitMQ, AWS SQS/SNS 등이 있습니다.
• 분산 트랜잭션(Distributed Transaction): 여러 독립적인 서비스를 포함하는 트랜잭션입니다. 이러한 트랜잭션에서 원자성(전부 또는 전무)을 보장하는 것은 상당한 과제이며, 종종 Saga 패턴과 같은 패턴으로 해결됩니다.

오케스트레이션: 중앙 지휘자

백엔드 시스템의 맥락에서 오케스트레이션은 오케스트라를 이끄는 지휘자에 비유될 수 있습니다. 오케스트레이터라고 불리는 중앙 서비스는 전체 비즈니스 프로세스의 흐름을 지시하는 책임을 집니다. 이는 작업 순서를 관리하고 다른 서비스에 명령을 보내며 진행하기 전에 응답을 기다립니다. 오케스트레이터는 프로세스에 대한 전체적인 보기를 가지고 있으며 실행을 적극적으로 제어합니다.

원칙:

• 중앙 집중식 제어: 단일 서비스가 워크플로를 결정하는 책임을 집니다.
• 명령 기반: 오케스트레이터는 다른 서비스에 명시적인 명령을 보냅니다.
• 상태 저장: 오케스트레이터는 종종 전체 프로세스의 상태를 유지합니다.

구현:

전자 상거래 주문 처리 프로세스를 예로 들어 보겠습니다. OrderService가 오케스트레이터 역할을 할 수 있습니다.

// OrderServiceImpl.java (Orchestrator)
@Service
public class OrderServiceImpl implements OrderService {

    @Autowired
    private PaymentClient paymentClient; // PaymentService에 대한 REST 클라이언트
    @Autowired
    private InventoryClient inventoryClient; // InventoryService에 대한 REST 클라이언트
    @Autowired
    private ShippingClient shippingClient; // ShippingService에 대한 REST 클라이언트

    @Override
    public Order createOrder(OrderRequest request) {
        // 1. 주문 기록 생성
        Order order = saveOrder(request);

        try {
            // 2. 결제 처리 (명령 전송, 응답 대기)
            PaymentResponse paymentResponse = paymentClient.processPayment(order.getOrderId(), request.getAmount());
            if (!paymentResponse.isSuccess()) {
                throw new PaymentFailedException("Payment failed for order: " + order.getOrderId());
            }

            // 3. 재고 차감 (명령 전송, 응답 대기)
            InventoryResponse inventoryResponse = inventoryClient.deductInventory(order.getOrderId(), order.getItems());
            if (!inventoryResponse.isSuccess()) {
                throw new InventoryFailedException("Inventory deduction failed for order: " + order.getOrderId());
            }

            // 4. 배송 시작 (명령 전송, 보통 비동기 응답으로 충분)
            shippingClient.initiateShipping(order.getOrderId(), order.getCustomerAddress());

            // 5. 주문 상태 업데이트 및 반환
            order.setStatus(OrderStatus.COMPLETED);
            return updateOrder(order);

        } catch (Exception e) {
            // 실패 처리: 보상 트랜잭션 (Saga 패턴)
            // 예: 결제 환불, 재고 복원
            refundPayment(order.getOrderId());
            restoreInventory(order.getOrderId(), order.getItems());
            order.setStatus(OrderStatus.FAILED);
            updateOrder(order);
            throw new OrderProcessingException("Order processing failed", e);
        }
    }
    // ... 저장, 업데이트 및 보상 작업을 위한 헬퍼 메서드
}

이 예제에서 OrderService는 사전에 정의된 순서로 PaymentService, InventoryService, ShippingService를 직접 호출합니다. 흐름을 관리하고 보상 작업(오케스트레이션과 함께 자주 사용되는 Saga 패턴의 한 형태)을 시작하여 잠재적인 실패를 처리합니다.

애플리케이션 시나리오:

• 엄격한 순서가 요구되는 복잡한 비즈니스 프로세스: 작업 순서가 중요하며 엄격하게 시행되어야 하는 경우.
• 워크플로 엔진: Camunda 또는 Netflix Conductor와 같은 시스템은 오케스트레이션 원칙을 기반으로 구축됩니다.
• 프로세스 상태에 대한 명확하고 중앙 집중식 보기가 필요한 경우: 전체 흐름을 디버깅하고 모니터링하기가 더 쉽습니다.

코레오그래피: 분산 댄스

그와 대조적으로 코레오그래피는 중앙 지휘자 없이 다른 댄서의 신호에 반응하고 자신의 움직임을 아는 댄서 그룹과 비슷합니다. 각 서비스는 자율적으로 작동하며 흥미로운 일이 발생하면 이벤트를 게시하고 다른 서비스가 게시한 이벤트에 반응합니다. 전체 흐름을 지시하는 단일 서비스는 없으며, 대신 참가 서비스의 독립적인 반응에서 전체 프로세스가 나타납니다.

원칙:

• 분산 제어: 단일 서비스가 전체 프로세스를 오케스트레이션하지 않습니다.
• 이벤트 기반: 서비스는 이벤트를 게시하고 이벤트에 반응합니다.
• 상태 비저장 (전체 프로세스의 경우): 개별 서비스는 자체 상태를 관리합니다.

구현:

이벤트 버스(예: Kafka)를 활용하여 코레오그래피를 사용하는 전자 상거래 주문 처리 사례를 다시 살펴보겠습니다.

// OrderService.java (Publisher)
@Service
public class OrderService {

    @Autowired
    private KafkaTemplate<String, OrderCreatedEvent> kafkaTemplate;

    public Order createOrder(OrderRequest request) {
        Order order = saveOrder(request); // 초기 주문 상태 저장

        // OrderCreated 이벤트 게시
        OrderCreatedEvent event = new OrderCreatedEvent(order.getOrderId(), order.getCustomerId(), order.getAmount(), order.getItems());
        kafkaTemplate.send("order-events", event.getOrderId().toString(), event);

        return order;
    }
}

// PaymentService.java (Consumer)
@Service
public class PaymentService {

    @Autowired
    private KafkaTemplate<String, PaymentProcessedEvent> kafkaTemplate;
    @Autowired
    private KafkaTemplate<String, PaymentFailedEvent> kafkaTemplateFailure;

    @KafkaListener(topics = "order-events", groupId = "payment-group", containerFactory = "kafkaListenerContainerFactory")
    public void handleOrderCreated(OrderCreatedEvent event) {
        try {
            // 결제 처리 로직
            boolean success = processPayment(event.getOrderId(), event.getAmount());

            if (success) {
                // PaymentProcessed 이벤트 게시
                PaymentProcessedEvent processedEvent = new PaymentProcessedEvent(event.getOrderId(), event.getAmount(), PaymentStatus.SUCCESS);
                kafkaTemplate.send("payment-events", processedEvent.getOrderId().toString(), processedEvent);
            } else {
                // PaymentFailed 이벤트 게시
                PaymentFailedEvent failedEvent = new PaymentFailedEvent(event.getOrderId(), "Insufficient funds");
                kafkaTemplateFailure.send("payment-failure-events", failedEvent.getOrderId().toString(), failedEvent);
            }
        } catch (Exception e) {
            // 로그 및 실패 이벤트 게시 가능
        }
    }
    // ... processPayment 로직
}

// InventoryService.java (Consumer)
@Service
public class InventoryService {

    @Autowired
    private KafkaTemplate<String, InventoryDeductedEvent> kafkaTemplate;
    @Autowired
    private KafkaTemplate<String, InventoryFailedEvent> kafkaTemplateFailure;

    @KafkaListener(topics = "payment-events", groupId = "inventory-group", containerFactory = "kafkaListenerContainerFactory")
    public void handlePaymentProcessed(PaymentProcessedEvent event) {
        // InventoryService는 자체 저장소 또는 다른 이벤트를 통해 주문 세부 정보를 가져올 수 있다고 가정
        OrderDetails orderDetails = fetchOrderDetails(event.getOrderId()); // 세부 정보를 가져오는 독립적인 방법 필요

        try {
            boolean success = deductInventory(event.getOrderId(), orderDetails.getItems()); // 차감 로직
            if (success) {
                // InventoryDeducted 이벤트 게시
                InventoryDeductedEvent deductedEvent = new InventoryDeductedEvent(event.getOrderId(), orderDetails.getItems());
                kafkaTemplate.send("inventory-events", deductedEvent.getOrderId().toString(), deductedEvent);
            } else {
                // InventoryFailed 이벤트 게시 (잠재적으로 PaymentRefundRequestedEvent와 같은 보상 작업)
                InventoryFailedEvent failedEvent = new InventoryFailedEvent(event.getOrderId(), "Out of stock");
                kafkaTemplateFailure.send("inventory-failure-events", failedEvent.getOrderId().toString(), failedEvent);
            }
        } catch (Exception e) {
            // 로그 및 실패 이벤트 게시 가능
        }
    }
    // ... deductInventory 로직
}

이 코레오그래피된 예제에서 OrderService는 단순히 OrderCreatedEvent를 게시합니다. PaymentService는 OrderCreatedEvent를 수신하고, 결제를 처리하고, PaymentProcessedEvent(또는 PaymentFailedEvent)를 게시합니다. 그러면 InventoryService는 PaymentProcessedEvent를 수신하고, 재고를 차감하고, InventoryDeductedEvent(또는 InventoryFailedEvent)를 게시하는 식으로 계속됩니다. 각 서비스는 소비하는 이벤트를 기반으로 독립적으로 작동합니다.

애플리케이션 시나리오:

• 느슨하게 결합된 시스템: 서비스가 진정으로 독립적으로 작동하고 한 서비스의 오류가 다른 서비스를 직접적으로 중단시키지 않아야 하는 경우.
• 확장성 및 복원력: 개별 서비스를 더 쉽게 확장하고 구성 요소 오류를 우아하게 처리할 수 있습니다.
• 자주 진화하는 복잡한 프로세스: 한 서비스의 로직 변경이 다른 서비스에 미치는 영향이 적습니다.
• 이벤트 소싱 아키텍처: 모든 상태 변경을 불변 이벤트로 저장한다는 개념과 자연스럽게 일치합니다.

오케스트레이션과 코레오그래피 비교: 주요 고려 사항

결론

오케스트레이션과 코레오그래피 모두 견고한 이벤트 기반 백엔드 시스템을 구축하기 위한 강력한 패턴입니다. 오케스트레이션은 복잡한 워크플로에 대한 명확하고 중앙 집중식 보기 및 제어를 제공하여 엄격한 순서 요구 사항이 있는 프로세스와 전체 상태에 대한 강력한 이해가 필요한 경우에 적합합니다. 그러나 단일 실패 지점을 도입하고 오케스트레이터가 너무 복잡해지면 병목 현상이 발생할 수 있습니다.

반면에 코레오그래피는 서비스가 이벤트에 자율적으로 반응하도록 하여 더 큰 디커플링, 확장성 및 복원력을 촉진합니다. 이 분산 접근 방식은 시스템을 변경에 더 잘 적응시키지만, 비즈니스 프로세스의 종단 간 흐름을 추적하고 포괄적인 오류 처리를 구현하기 어렵게 만들 수 있습니다.

오케스트레이션과 코레오그래피의 선택이 상호 배타적인 것은 아니며 종종 비즈니스 프로세스의 특정 맥락에 따라 달라집니다. 대규모 시스템에서 일반적인 접근 방식은 높은 수준의 중요한 워크플로에는 오케스트레이션을 사용하고 작고 독립적인 하위 프로세스에는 코레오그래피를 사용하는 하이브리드 모델을 사용하는 것입니다. 궁극적인 목표는 유연하고 복원력 있으며 유지 관리 가능한 시스템을 구축하여 비즈니스의 진화하는 요구 사항에 맞춰 확장할 수 있도록 하는 것입니다. 진정한 예술은 각 상호 작용에 가장 적합한 패턴을 분별하고 백엔드 서비스에 대한 제어와 자율성 간의 올바른 균형을 맞추는 데 있습니다.