[MSA] Saga Pattern

정의

Saga^[각주:1] Pattern은 분산 환경(MSA)에서 트랜잭션을 처리하는 데 사용되는 아키텍처 패턴이다.

• 분산 트랜잭션을 서비스 간 트랜잭션으로 모방한다
  • 같은 서비스에서 하나의 DB에 동작하는 ACID 트랜잭션을 모방
  • 그러나 Isolation(독립성)^[각주:2]은 달성할 수 없다
  • 각 서비스에서 트랜잭션을 실행하여 하나의 트랜잭션처럼 보이게 한다
• 실패 시 보상 트랜잭션(Compensationg Transaction)을 수행하여 일관성을 유지한다.

구현 방식

Orchestration

• 중앙 집중 관리
• 중앙 서비스가 다른 서비스를 적절한 순서로 호출
• 실패 시 중앙 서비스가 이미 호출한 서비스를 어떻게 보상할 지 알고 있다
• 서비스 호출 후 응답을 기다린다
  • 응답을 기다리지 않는 비동기 통신으로 최적화 가능
  • 다른 서비스에 명령 전달
• ex) e커머스 주문 시스템
  • 사용자가 구매 버튼을 클릭
  • Order 서비스 호출
  • Order 서비스가 Orchestator 역할을 수행
  • Order 서비스가 Payment, Inventory, Shipping 서비스를 올바른 순서로 호출
    • 서비스를 호출 후 응답을 기다리고 다음 서비스를 호출
  • 배송 중 실패하면 보상 동작 트리거. 서비스에 결제를 되돌리고 재고를 채우는 요청 전송.
• 장점
  • 제어가 쉽고 신뢰성이 좋다
• 단점
  • 오케스트레이터에서 병목 현상이 발생할 수 있다
• 서비스들이 긴밀하게 연결되어 있을 때 적절
• 워크플로 복잡할 때 권장

Choreography

• 분산형 (각자 수행)
• 서비스 간 이벤트를 통해 통신 (Event Driven Architecture)
  • 중앙 서비스나 오케스트레이터 없음
• 서비스는 이벤트에 반응하여 무엇을 해야할 지, 보상이 필요한 지 알게 된다
• ex) e커머스 주문 시스템
  • 사용자가 제품을 구매
  • “ProductOrdered” 이벤트를 보냄
  • 결제 서비스 뿐만 아니라 상품 추천 서비스와 같이 병렬로 처리할 수 있는 다른 서비스에서도 소비
  • 결제 서비스는 결제 확인 후 “ProductPurchased”, 실패하면 “PurchaseFailed” 이벤트를 보냄
    • 결제 실패하면 Order 서비스가 이벤트를 소비하여 사용자에게 상황을 알림
    • 이벤트를 소비하지 않는 서비스에서는 아무 일도 일어나지 않음
  • 제품 구매되면 이벤트를 보내면 여러 서비스가 이벤트를 읽어서 주문 내역을 업데이트하고, 재고를 차감하고, 배송을 시작한다
• 응답을 기다리지 않음
  • 단순히 이벤트를 보내면 관심 있는 서비스가 이벤트를 소비하고 작업 수행
• 워크플로가 단순할 때 권장
• 이벤트는 영구적으로 저장될 수 있고 Truth of Source가 될 수 있다
  • ⇒ Event Sourcing
• 장점
  • 단순성: 각 서비스가 독립적으로 동작하여 구현과 관리가 단순
  • 확장성: 분산된 아키텍처이므로독립적으로 확장 가능. 오케스트레이션에서는 오케스트레이터가 병목이 될 수 있다
  • 유연성: 새로운 서비스나 프로세르를 추가하거나 변경할 때 더 유연. 오케스트레이터를 변경하지 않고 해당 서비스만 변경
  • 내결함성(Fault Tolerance): 한 서비스에 장애가 발생해도 다른 서비스는 동작 가능. 오케스트레이션에서는 오케스트레이터에 장애가 발생하면 전체 프로세스 영향
  • Source of Truth: 이벤트 스트림 자체가 전체 시스템의 상태를 나타내는 진실의 소스가 도리 수 있다
• 단점
  • 일관성이 떨어질 수 있다
  • 롤백이 어렵다
• 서비스가 독립적으로 구성되었을 때 적절

출처

https://www.youtube.com/watch?v=C0rGwyJkDTU&t=2s

 

1. 일련의 사건 [본문으로]
2. 트랜잭션 수행 시 다른 트랜잭션이 끼어들지 못하게 보장하는 것 [본문으로]