SAGA 보상 트랜잭션

펌 : https://waspro.tistory.com/603

SAGA 패턴 & 보상트랜잭션

SAGA 패턴은 서비스 별 각 트랜잭션이 단일 서비스 내의 데이터를 갱신하는 일련의 로컬 트랜잭션을 의미한다.

첫번째 서비스의 트랜잭션이 완료되면 두번째 서비스의 트랜잭션이 동작하도록 트리거 되는 방식이라 생각할 수 있다.

SAGA 패턴은 크게 두가지 방식으로 구현할 수 있다.

• Event / Chreography : 각 로컬 트랜잭션이 이벤트를 발생시키고, 다른 서비스가 트리거 하는 방식
• Command / Orchestration : 오케스트레이터가 어떤 트랜잭션을 수행할 건지 알려주는 방식

그럼 각 방식에 대해 간단히 살펴보자.

Event/Chreography

각 서비스 마다 자신의 트랜잭션을 관리하며 현재 상태를 변경한 후 이벤트를 발생시키고, 그 이벤트를 다른 서비스에 전달하는 방식으로 트랜잭션이 처리된다.

 

결과 값 또한 잘 진행되지 않았을 시에는 보상 트랜잭션을 통한 보상 이벤트를 발생시켜 관리된다.

 

각 트랜잭션마다 공통된 공유 ID를 정의하는 것이 중요하므로 Event를 던질 때 마다 모든 Listener가 참조하는 트랜잭션을 확인할 수 있다.

물건을 주문하기 위한 과정을 설명하고 있다. Order, Payment, Socket, Delivery 서비스는 하나의 마이크로서비스 형태의 독립된 형태로 관리되며 각 서비스를 개별 트랜잭션을 관리한다.

 

각 서비스는 자신의 트랜잭션이 성공적으로 완료되면 다음 서비스를 호출하기 위한 Trigger를 동작시킨다. 이 또한 하나의 이벤트 형태로 동작하며, 다음 서비스를 동작하게 하는 역할을 담당한다.

각 트랜잭션은  독립적으로 동작하기 때문에 트래잭션이 완료된 경우의 해당 트랜잭션을 롤백하기 위해서는 이전 서비스로 돌아가야 한다.

동일한 프로세스가 진행된다고 할 때 Stock Service에서 재고를 확인하는 도중 해당 상품이 매진 된 것을 확인했을 때는 이러한 동작을 하게 된다.

이미 개별 트랜잭션이 완료된 서비스는 Order, Payment 두 서비스가 있다.

Stock Service는 현재까지 처리가 완료된 서비스를 알고 있어야 하며, 정보를 기반으로 해당 서비스의 Rollback을 요청하게 된다.

 

이는 각 마이크로서비스의 롤백 프로세스가 처리되어 Commit된 정보를 이전 상태로 돌린다.

 

이와 같은 방식은 구현이 복잡하지 않아(완료된 서비스 정보, 다음 서비스 요청을 위한 트리거) 쉽게 개발하고 배치할 수 있으나, 서비스 간 호출 흐름을 인지하는 ID를 관리해야 하며, 모든 서비스는 Trigger에 의해 동작할 수 있도록 각 서비스 이벤트를 리슨하고 있어야 한다.

Command/Orchestration

오케스트레이터가 전체 서비스에 명령을 날리며, 명령을 중계하는 브로커(MessageQueue)를 사용한다. 이때 전송 채널은 각 서비스 별로 할당하지만, 결과를 확인하는 Reply 채널을 두어 서비스 성공 또는 실패에 대한 처리 방안을 마련한다.

각 명령에 해당하는 상태 시스템을 가지고 있고, 이 상태 시스템을 통해서 전체 트랜잭션의 상태를 파악하기 쉽기 때문에 테스트하기도 쉽다.

모든 흐름은 Order Saga Orchestrator에 의해 동작한다. 서비스 별 트랜잭션을 직접 관리하고, 성공, 실패에 따른 동작 방식 역시 오케스트레이터가 직접 관리한다.

만약 이와 같은 형태에서 트랜잭션 실패가 났을 경우를 살펴보자.

위와 같이 주문한 서비스의 Stock이 부족할 경우의 처리 과정이다.

1) Stock Service는 재고를 확인했더니 부족하여 이를 Reply Channel을 통해 Saga Orchestrator에게 전달한다.

2) Orchestrator는 환불을 위한 Payment Channel을 생성하여 Payment Service에게 전달한다.

3) Payment Service는 환불을 진행하고 클라이언트에게 알림을 발송한다.

위와 같이 Chreography 방식은 서비스 간 종속성이 없어 서비스 간 보다 독립된 서비스 구축이 가능하며, 서비스 복잡도가 감소한다. 또한, 테스트가 쉽고 롤백을 쉽게 관리할 수 있다.

다만 모든 트랜잭션 관리는 오케스트레이터가 관리하여 오케스트레이터의 관리와 네트워크 Hop이 증가할 수 있으며, 인프라가 다소 복잡하게 구성될 수도 있다.