[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 와 같은 인터렉티브 서비스의 경우
      • 복잡한 상태 관리와 서비스 간의 상호작용 추적이 중요한 경우에는 어려울 수 있다.
      • 상태 일관성을 유지하기 어려운 경우에는 사용을 피하는 것이 좋다.
  • 사가 패턴
    • 사용해야 하는 경우:
      • 긴 거래를 여러 개의 작은 트랜잭션으로 나누어 관리할 필요가 있을 떄 유용하다.
      • 트랜잭션 실패 시 상태를 복구해야 하는 경우에 적합하다.
    • 사용하지 말아야 할 경우:
      • 단순한 트랜잭션 처리에는 필요하지 않으며, 높은 데이터 일관성이 요구되는 경우에는 복잡할 수 있다.

댓글남기기