Event Driven Architecture

• Microservice

  • Atomicity, Consistency → Commit Transaction

    

    • Step
      • Send an Order message kafka broker
      • Send a Confirm message to kafka broker
      • Receive the Confirmed message to order service
      • Receive the Ordered message to catalog service

  • Atomicity, Consistency → Rollback Trasaction

    • Step
      • Receive the Ordered mesage to catalog service
      • Send a Rejected message to kafka broker
      • Receive the Rejected message to order service
      • Receive the Ordered message

Event Sourcing

• 특징

  • 데이터 마지막 상태만 저장하는 것이 아닌, 해당 데이터에 수행된 전체 이력을 기록

  • 데이터 구조 단순

  • 데이터의 일관성과 트랜잭션 처리 가능

  • 데이터 저장소의 개체를 직접 업데이트 하지 않기 때문에, 동시에 대한 충돌 문제 해결

    

  • 도메인 주도 설계

    • Aggregate, Projection

  • 메시지 중심의 비동기 작업 처리

  • 단점

    • 모든 이벤트에 대한 복원 부족 → 해결책 : 스냅샷
    • 다양한 데이터 조회 → 해결책 : CQRS
      • CQRS : 명령과 조회의 책임을 분리

        • 상태를 변경하는 COMMAND

        • 조회를 담당하는 QUERY

          

          → Event Store = Kafka, Event Handlers = Topic 에 전달된 값을 Catch

Saga Pattern

• 처리방식

  • Application 에서 Transaction 처리
    • choreography, orchestration
  • Application 이 분리된 경우에는 각각의 local transaction 만 처리
  • 각 app 에 대한 연속적인 trasaction 실패할 경우 → 보상 transaction 처리
  • 데이터의 원자성을 보장하지는 않지만, 일관성을 보장

• Choreography-based saga

  

• Orchestration-based saga

  

차이점 : orchestration 은 중앙 집중적인 처리 방식이며(broker 를 통한 연결) choreography 방식은 개별적인 서비스가 통신을 통해 처리한다.

정리 :

• 개념

  • Orchestration에서는 하나의 Kafka broker와 오케스트레이터가 각 서비스의 실행 순서와 처리를 관리합니다.
  • Choreography에서는 여러 개의 topic을 구성하여 각 서비스가 필요한 topic만 구독하고 발행하는 방식으로 자율적으로 이벤트를 관리합니다. Kafka cluster는 동일하지만 topic을 여러 개 사용하여 이벤트 흐름을 관리하는 경우가 일반적입니다.

• 적합 상황

  • Choreography는 자율적이고 느슨하게 결합된 서비스에 유리하며, 단순한 프로세스와 높은 확장성을 원할 때 적합합니다.
    • e-커머스 시스템에서 주문 처리: 사용자가 주문을 완료하면 주문 서비스가 ‘주문 완료’ 이벤트를 발행하고, 재고 서비스와 결제 서비스가 이를 받아 처리하는 경우. 각각의 서비스가 이벤트에 독립적으로 반응하므로 주문 과정이 간단하고, 중앙 제어가 필요하지 않습니다.
    • 간단한 비즈니스 프로세스 관리: 예를 들어, 사용자 가입 시 메일 알림, 데이터베이스 저장, 권한 부여 등이 독립적으로 처리되는 경우.
  • Orchestration은 중앙 집중 제어가 필요한 복잡한 비즈니스 로직이나 워크플로우에 유리하며, 순차적 처리와 상태 관리가 중요한 경우 적합합니다.
    • 은행 시스템에서 대출 신청 프로세스: 대출 신청 시 여러 단계를 순차적으로 거쳐야 하는데, 신용 평가, 보증 심사, 대출 승인 등의 단계를 순서대로 제어하고 처리해야 하는 상황에 적합합니다.
    • 여행 예약 서비스: 항공권 예약, 호텔 예약, 차량 렌탈 등이 중앙 오케스트레이터에 의해 관리되고, 각 단계가 성공적으로 완료되었는지 확인해야 하는 경우.

• 보상 트랜잭션

  구분	Orchestration	Choreography
  보상 트랜잭션 책임	오케스트레이터가 보상 트랜잭션을 관리	각 서비스가 보상 트랜잭션을 자체적으로 관리
  트랜잭션 상태 관리	중앙에서 상태를 관리하여 일관성 유지 용이	개별 서비스가 상태를 관리하며 분산적
  보상 트랜잭션 트리거	오케스트레이터가 호출	이벤트 기반으로 보상 트랜잭션이 트리거됨
  구현 난이도	트랜잭션 추적과 관리가 상대적으로 쉬움	서비스 간 협조 필요, 복잡한 이벤트 관리 요구
  복구/롤백 모니터링	중앙에서 일관된 모니터링 가능	분산된 상태로 각 서비스에서 개별적으로 모니터링