[Cloud Native] 클라우드 네이티브 애플리케이션의 서비스 조합 패턴

서비스 조합 패턴(Service Composition Pattern)

서비스 조합 패턴은 마이크로서비스 아키텍처에서 여러 서비스를 조합하여 비즈니스 기능을 구현하는 방식을 설명한다. 이번 포스팅에서는 서비스 오케스트레이션 패턴, 서비스 코레오그래피 패턴, 사가 패넡을 다루며, 각 패턴의 특징과 사용 사례를 상세히 자세히 설명한다.

1. 서비스 오케스트레이션 패턴(Service Orchestration Pattern)

서비스 오케스트레이션 패턴은 중앙 집중형 조정 서비스(오케스트레이터)가 여러 서비스의 작업을 조정하여 전체 프로세스를 관리하는 방이다. 오케스트레이터 서비스는 각 서비스 호출의 순서와 조건을 관리하며, 복잡한 비즈니스 로직을 구현한다.

• 장점
  • 중앙 집중형 관리: 모든 서비스 호출과 순서를 중앙에서 관리하므로 전체 프로세스의 흐름을 쉽게 제어할 수 있다.
  • 명확한 프로세스 흐름: 프로세스의 흐름이 명확하게 정의되고, 오케스트레이터가 이를 관리하여 일관된 동작을 보장한다.
• 단점
  • 단일 장애 지점(SFOP): 오케스트레이터가 단일 장애 지점이 되어 시스템 전체에 영향을 줄 수 있다.
  • 복잡한 유지보수: 오케스트레이터가 복잡해지면 시스템의 유지보수와 업데이트가 어려울 수 있다.
• 예시: 전자상거래 플랫폼에서 주문 처리 프로세스가 오케스트레이터를 통해 관리된다. 오케스트레이터는 주문 생성, 결제, 재고확인, 배송요청 등 여러 단계를 순차적으로 호출하여 전체 주문 프로세스를 조정한다.

2. 서비스 코레오그래피 패턴(Service Choreography Pattern)

서비스 코레오그래피 패턴은 각 서비스가 독립적으로 작업을 수행하고, 다른 서비스와의 상호작용을 통해 전체 프로세스를 완성하는 방식이다. 서비스 간의 상호작용은 메시지나 이벤트를 통해 이루어진다.

• 장점
  • 서비스 독립성: 각 서비스가 독립적으로 작업을 수행하므로 서비스 간의 결합도가 낮다.
  • 유연성: 서비스 간의 상호작용을 유연하게 조정할 수 있으며, 서비스의 변경이 다른 서비스에 미치는 영향을 줄일 수 있다.
• 단점
  • 상태 관리 복잡성: 여러 서비스가 상호작용하므로 상태 관리와 오류 처리가 복잡할 수 있다.
  • 추적의 어려움: 서비스 간의 상호작용을 추적하고 디버깅하는 것이 어려울 수 있다.
• 예시 및 기술
  • AMQP(Advanced Message Queuing Protocol): 메시지 브로커를 통한 메시지 전송 및 처리에 사용된다. RabbitMQ와 같은 메시지 브로커가 AMQP를 지원한다. 이 기술은 서비스 간의 비동기 메시징을 통해 코레오그래피를 구현하는 데 유용하다.
  • Apache Kafka: 분산 스트리밍 플랫폼으로, 고속의 메시징 및 이벤트 스트리밍을 지원한다. Kafka를 사용하면 여러 서비스 간의 이벤트를 처리하고 전달하는 데 효과적이다.

3. 사가 패턴(Saga Pattern)

사가 패턴은 긴 거래 또는 프로세스를 여러 개의 작은 트랜잭션으로 나누고, 각 트랜잭션을 독립적으로 실행하여 전체 프로세스를 관리하는 방식이다. 각 트랜잭션은 성공적으로 완료되거나, 실패 시 보상 트랜잭션을 수행하여 상태를 복구한다.

• 장점
  • 분산트랜잭션 관리: 긴 거래를 여러 개의 트랜잭션으로 나누어 관리할 수 있다.
  • 높은 유연성: 각 트랜잭션이 독립적으로 실행되므로 시스템의 유연성을 높일 수 있다.
• 단점
  • 복잡한 오류 처리: 트랜잭션의 실패와 보상 처리 로직이 복잡할 수 있다.
  • 상태 일관성 유지 어려움: 트랜잭션 간의 상태 일관성을 유지하는 것이 어려울 수 있다.
• 예시: 항공권 예약 시스템에서 예약 생성, 결제, 좌석 배정의 각 단계를 사가패턴으로 관리한다. 예약 생성 후 결제가 실패하면, 결제 실패를 처리하기 위한 보상 트랜잭션이 실행되어 예약 상태를 복구한다.

4. 정리

서비스 조합 패턴은 다양한 비즈니스 요구 사항을 충족하기 위해 서비스 간의 상호작용을 조정하는 방식을 제시한다. 각 패턴의 사용 사례와 사용하지 말아야 할 경우는 다음과 같다.

• 서비스 오케스트레이션 패턴
  • 사용해야 하는 경우:
    • 복잡한 비즈니스 프로세스를 중앙에서 관리하고자 할 때 유용하다.
    • 서비스 호출 순서와 조건을 중앙에서 관리해야 하는 경우에 적합하다.
  • 사용하지 말아야 할 경우:
    • 단일 장애 지점이 우려되거나 비즈니스 로직이 자주 변경되는 경우에는 적합하지 않을 수 있다.
• 서비스 코레오그래피 패턴
  • 사용해야 하는 경우:
    • 서비스 간의 높은 독립성과 유연성을 필요할 때 유용하다.
    • 서비스 간의 상호작용을 유연하게 조정하고, 서비스 변경이 다른 서비스에 미치는 영향을 줄일 수 있는 경우에 적합하다.
    • AMQP나 Kafka와 같은 메시징 시스템을 통해 이벤트 기반 상호작용을 관리할 수 있다.
  • 사용하지 말아야 할 경우:
    • 사용자에게 제공하는 API 와 같은 인터렉티브 서비스의 경우
    • 복잡한 상태 관리와 서비스 간의 상호작용 추적이 중요한 경우에는 어려울 수 있다.
    • 상태 일관성을 유지하기 어려운 경우에는 사용을 피하는 것이 좋다.
• 사가 패턴
  • 사용해야 하는 경우:
    • 긴 거래를 여러 개의 작은 트랜잭션으로 나누어 관리할 필요가 있을 떄 유용하다.
    • 트랜잭션 실패 시 상태를 복구해야 하는 경우에 적합하다.
  • 사용하지 말아야 할 경우:
    • 단순한 트랜잭션 처리에는 필요하지 않으며, 높은 데이터 일관성이 요구되는 경우에는 복잡할 수 있다.