마이크로서비스 간 트랜잭션 Saga 패턴

상황(Context)

서비스별 데이터베이스 패턴(Database per Service pattern)을 적용한 상황에서 각 서비스는 고유한 데이터베이스를 가지고 있습니다. 그러나 일부 비즈니스 트랜잭션은 여러 서비스에 걸쳐 일어나므로, 서비스 간 트랜잭션을 구현할 수 있는 메커니즘이 필요합니다.

 

예를 들어, 고객의 신용 한도가 있는 전자 상거래 스토어를 구축한다고 가정해 보면 애플리케이션은 새로운 주문이 고객의 신용 한도를 초과하지 않도록 보장해야 합니다. 하지만 주문 서비스와 고객 서비스는 서로 다른 데이터베이스를 사용하고 있으므로, 단순히 local ACID Transaction 을 사용할 수 없습니다.

 

문제 (Problem)

서비스 간에 걸쳐 있는 트랜잭션을 어떻게 구현할 수 있을까요?

 

제약 조건 (Forces)

2PC(2단계 커밋 프로토콜)는 사용할 수 없습니다.

 

해결책 (Solution)

여러 서비스에 걸친 각 비즈니스 트랜잭션을 사가(Saga) 로 구현합니다.

 

Saga 는 local 트랜잭션의 일련의 작업입니다.

 

각 local 트랜잭션은 데이터베이스를 업데이트하고, 다음 local 트랜잭션을 트리거할 message 또는 event 를 발행합니다.

 

만약 local 트랜잭션이 비즈니스 규칙을 위반하여 실패하면, Saga 는 앞서 실행된 local 트랜잭션에서 수행된 변경 사항을 취소하는 일련의 보상 트랜잭션을 실행하여 변경을 되돌립니다.

 

 

2 ways of coordination Sagas 

 

1. 코레오그래피(Choreography) - 각 local 트랜잭션이 domain event 를 발행하여 다른 서비스의 local 트랜잭션을 trigger 합니다.
2. 오케스트레이션(Orchestration) - 오케스트레이터(Orchestrator)라는 객체가 각 참가자에게 어떤 local 트랜잭션을 실행할지 지시합니다.

 

---

Example: Choreography-based saga

 

 

Choreography 접근 방식을 사용하는 e-commerce 애플리케이션은 choreography 기반 Saga 를 통해 주문을 처리하며, 다음 단계로 이루어집니다.

 

 

1. Order Service 가 /orders에 대한 POST 요청을 받아서 PENDING 상태의 주문을 생성합니다.
2. 그런 다음 Order Created event 를 발행합니다.
3. Customer Service 의 이벤트 핸들러가 고객의 신용 한도를 예약하려 시도합니다.

예를 들어, 고객이 100만 원의 신용 한도를 가지고 있는데 30만 원의 주문을 하려고 하면, 신용 한도에서 30만 원을 예약(reserve)하여 다른 거래가 이 금액을 사용하지 못하도록 하는 것입니다.
이후 주문이 최종 승인되면 그 금액이 실제로 결제되고, 주문이 취소되면 예약된 금액이 다시 풀리는 방식입니다.

 

   4. 그런 다음 결과를 나타내는 event 를 발행합니다.

   5. Order Service의 event handler 는 결과에 따라 주문을 승인하거나 거절합니다.

 

 

Example: Orchestration-based saga

 

 

 

 

Orchestration 접근 방식을 사용하는 전자상거래 애플리케이션은 Orchestration 기반 Saga 를 통해 주문을 처리하며, 다음 단계로 이루어집니다:

1. Order 서비스가 /orders에 대한 POST 요청을 수신하고 Create Order saga orchestrator 를 생성합니다.
2. Saga orchestrator 는 PENDING 상태의 주문을 생성합니다.
3. 그런 다음 Reserve Credit 명령을 Customer Service 에 전송합니다.
4. Customer Service 는 신용 한도를 예약하려고 시도합니다.
5. 이후 결과를 나타내는 응답 메시지를 다시 보냅니다.
6. Saga orchestrator 는 주문을 승인하거나 거절합니다.

 

---

 

Resulting context

이 패턴은 다음과 같은 장점을 가지고 있습니다:

• 데이터 일관성 유지: 여러 서비스 간의 데이터 일관성을 유지할 수 있으며, 이를 위해 분산 트랜잭션을 사용할 필요가 없습니다.

이 솔루션은 다음과 같은 단점도 가지고 있습니다:

• Lack of automatic rollback 자동 롤백 부족: 개발자가 이전에 이루어진 변경을 명시적으로 되돌리는 compensating transactions 보상 트랜잭션을 설계해야 하며, ACID 트랜잭션의 자동 rollback 기능에 의존할 수 없습니다.

compensating transactions 보상 트랜잭션 ex)

• Lack of isolation (the “I” in ACID) 격리 부족 : 격리가 부족하다는 것은 여러 saga 와 트랜잭션의 동시 실행으로 인해 데이터 이상 현상이 발생할 위험이 있다는 것을 의미합니다. 따라서 saga 개발자는 일반적으로 격리를 구현하기 위한 설계 기술인 countermeasures(대응책) 를 사용해야 합니다. 또한, countermeasures 를 선택하고 올바르게 구현하기 위해 신중한 분석이 필요합니다.

격리 부족에 대한 대응책 (Countermeasures)
1. 의미적 잠금(Semantic Lock)
커밋되지 않은 레코드를 표시하여 다른 트랜잭션이 접근하지 못하게 하는 방법으로, 격리 부족 문제를 해결합니다.
2. 교환 가능한 업데이트(Commutative Updates)
여러 업데이트 작업을 순서에 관계없이 수행할 수 있도록 설계하여 데이터 손실을 방지하는 방법입니다.
3. 비관적 관점(Pessimistic View)
Saga 의 단계를 재정렬하여 다른 트랜잭션의 영향을 줄이려는 방법입니다.
4. 값 다시 읽기(Reread Value)
업데이트 전에 레코드를 다시 읽어 변경 여부를 확인하여 부정확한 상태를 방지합니다.
5. 버전 파일(Version File)
작업을 기록하여 올바른 순서로 실행되도록 보장하는 방법입니다.
6. 가치 기준(By Value)
비즈니스 위험에 따라 사가 또는 분산 거래를 선택하여 각 요청에 대한 적절한 조치를 취합니다.

 

 

 

또한 다음과 같은 문제도 해결해야 합니다:

• 신뢰성을 보장하기 위해 서비스는 데이터베이스를 원자적(atomically) 으로 업데이트하고 메시지/이벤트를 게시해야 합니다. Database 와 message broker 를 가로지르는 전통적인 분산 트랜잭션 메커니즘을 사용할 수 없기 때문에, 아래 나열된 패턴 중 하나를 사용해야 합니다.
• Saga 를 시작하는 클라이언트는 asynchronous flow 비동기 흐름에서 synchronous request (e.g. HTTP POST /orders)  을 사용하여 결과를 확인할 수 있어야 합니다. 이를 위해 몇 가지 옵션이 있으며, 각 옵션은 다양한 trade-off 가 있습니다. 
  1. Service 는 saga 가 완료되면 응답을 보내며, 예를 들어 OrderApproved 또는 OrderRejected event 를 수신한 후에 응답을 보냅니다.
  2. Service 는 saga 를 시작한 후 응답(예: orderID 포함)을 보내고, 클라이언트는 주기적으로 결과를 확인하기 위해 GET 요청(예: GET /orders/{orderID}) 을 합니다.
  3. Service 는 saga 를 시작한 후 응답(예: orderID 포함) 을 보내고, saga 가 완료되면 클라이언트에게 이벤트(예: websocket, webhook 등)를 전송합니다.

 

 

---

 

 

references

 

 

https://microservices.io/patterns/data/saga.html

Microservices Pattern: Pattern: Saga

 

https://livebook.manning.com/book/microservices-patterns/chapter-4/218

Chapter 4. Managing transactions with sagas · Microservices Patterns