MSA 환경에서의 트랜잭션 처리 - SAGA 패턴

☁️ MSA 환경에서의 트랜잭션 처리

📍 분산 트랜잭션을 구현하는 방법

• 2PC (2 Phase Commit)
• SAGA 패턴

 

📌 2PC (2 Phase Commit)

 

2PC는 분산 트랜잭션을 구현하는데 널리 사용되는 패턴으로 Prepare 단계와 Commit 단계로 구성되어 있다.

• 분산 시스템 환경에서 Cordinator라는 추가적인 인프라 필요

Prepare Phase	관련된 모든 서비스는 Commit을 준비, Transaction Coordinator에 트랜잭션을 시작할 준비가 되었음을 알린다.
Commit Phase	트랜잭션을 시작할 준비가 되었다면, Coordinator는 Commit을 요청 - 서비스 중 하나라도 실패한다면, Coordinator는 관련된 모든 서비스에 해당 트랜잭션을 롤백하도록 요청

 

 

 

⚠️ 2PC의 한계

• 장애 취약성
  • Cordinator에 모든 트랜잭션의 의존성이 존재
    • Cordinator에 문제가 생기면, 모든 트랜잭션은 멈추고 모든 비즈니스가 정지된다.
    • Data에 대한 Lock이 걸린다.
    • 문제가 발생시 결정 주체가 없어진다.
• Cordinator의 모든 결정은 취소가 불가능 ❌
  • Commit / Abort 결정에 대해 그 사이에 어떤 문제가 발생하더라도 완료해야만 한다.

 

따라서, 2PC의 경우 Coordinator에 의존하여 모든 서비스에 대해 준비 상태를 확인해야 하고 데이터 Lock 에 의해서 가용성의 한계가 존재한다.

 

💡SAGA 패턴

---

SAGA 패턴 이란 마이크로 서비스들끼리 트랜잭션에 대한 이벤트를 주고 받아 특정 마이크로 서비스에서 작업이 실패했을 경우 이전까지의 작업이 완료된 마이크로 서비스들에게 보상 트랜잭션(이벤트)를 소싱함으로 분산 환경에서 원자성을 보장하는 방식

 

즉, SAGA 패턴을 이용하면 데이터 일관성을 보장받을 수 있고 트랜잭션 실패 시, 보상 트랜잭션으로 데이터 정합성을 맞출 수 있다.

 

🆎 SAGA 패턴의 종류

---

1️⃣ Choreography 방식

 

독립적인 조율자 (Orchestration) 을 두지않고, SAGA를 구현하는 방법

• 이벤트 Pub/Sub을 통해 통신을 하는 방식
• 여러 서비스를 거쳐 서비스에서 실패(예외 상황 혹은 장애)가 발생한다면 보상 트랜잭션 이벤트를 발행

❗ 구현이 비교적 간단, 하지만 트랜잭션 상황을 모니터링을 하기 어렵다는 단점 존재

⇒ 조금이라도 복잡해진다면 그다지 좋은 방법이 아니다.

 

2️⃣ Orchestration 방식

 

독립적인 조율자 (Orchestrator)를 두어, 하나의 SAGA(트랜잭션)에 대한 매니징을 담당하는 방법

• 중앙 집중식 컨트롤러 마이크로 서비스로 SAGA를 조정
• Orchestrator가 중앙 집중식 컨트롤러 역할을 하고 각 서비스에 실행할 트랜잭션을 알려주는 방식
• Orchestrator는 요청을 실행, 각 서비스의 상태를 확인, 실패에 대한 복구처리를 한다.

구현이 비교적 어렵지만, 전체적인 트랜잭션의 모니터링이 수월하다.

 

참고자료

Saga 패턴 - Azure Design Patterns

Saga pattern - AWS 권장 가이드

MSA : SAGA패턴 (by 박혜린님)

Adopting Choreography-based Saga pattern on your Microservice Architecture

Microservices Pattern: Sagas