마이크로 서비스 : SAGA 패턴 : 정의, 개념, 종류, 개요

서비스별 데이터베이스

Soa와 구분되는 Msa 특징으로 각각의 마이크로서비스는 각자의 비즈니스 처리를 위한 영구 데이터를 소유하고 있다는 것입니다. 그렇기 때문에 이러한 소유한 데이터는 다른 서비스에 직접 호출되게 하지 않고, 자신의 API를 통해서만 액세스 할 수 있습니다.

주문서비스가 주문수행을 위해 고객 정보를 필요로 한다면, 바로 고객 테이블을 질의를 할 수 없습니다. 반드시 고객 서비스의 API를 통해서만 호출할 수 있습니다. 따라서 이런 구조에서 분산 트랜잭션 문제가 발생할 수 있습니다.

 

 

여러 서비스 간에 데이터 일관성을 유지하는 방법

두 개의 서비스에 걸쳐서 트랜잭션 처리가 필요한 업무가 있을 수 있습니다. 즉 여러 서비스 간의 데이터 일관성을 유지할 필요가 있습니다. 이런 분산 트랜잭션 처리를 위해 전통적인 방법으로 2PC 같은 기법을 사용했습니다.

그런데 이런 방법은 하나의 서비스가 장애가 있는 경우나 각각 서비스에 동시에 Rocking을 걸게 되면 발생하는 퍼포먼스의 문제로 효율적인 방법이 아닙니다. 특히 각각의 서비스가 다른 Instance에 있기 때문에 통제하기 어렵습니다.

그래서 나타난 패턴이 Saga 패턴입니다. Saga 패턴은 각 서비스의 로컬 트랜잭션을 순차적으로 처리하는 패턴입니다.각 로컬 트랜잭션은 데이터베이스를 업데이트한 다음에 Saga 내에 있는 다음 로컬 트랜잭션을 트리거하는 메시지 또는 이벤트를 게시하는 기법입니다.

그렇다면 다른 트랜잭션의 결과에 따라 롤백이 필요한 경우 나오는 개념이 보상 트랜잭션입니다. 보상 트랜잭션은 어떤 서비스에서 트랜잭션 처리에 실패할 경우, 그 서비스의 앞선 다른 서비스에서 처리된 트랜잭션을 되돌리게 하는 트랜잭션입니다.

Saga는 일관성 유지가 필요한 트랜잭션을 모두 묶어 하나의 트랜잭션으로 처리하지 않습니다. 각각의 로컬 트랜잭션으로 분리하여 순차적으로 처리하는 방법입니다.

트랜잭션이 실패한 경우 이전 로컬 트랜잭션이 작성한 변경 사항을 취소하는 일련의 보상 트랜잭션을 통해 전체의 일관성을 유지합니다. 

 

 

Choreography SAGA

Saga 패턴과 이전차시에서 배웠던 이벤트 주도 설계를 활용한 패턴입니다. 주문 처리가 시작되면 Order Service는주문을 생성하고 주문 생성됨 이벤트를 게시하고 트랜잭션을 종료합니다.

 

마이크로 서비스 : SAGA 패턴 : 정의, 개념, 종류, 개요

 

다음에는 Customer Service가 주문 생성됨 이벤트를 확인한 뒤, 신용한도를 조회하여 신용한도가 충족된다면 신용 승인됨 이벤트를 게시하고, 아니라면 신용한도 초과됨 이벤트 게시하게 됩니다.

그럼 다시 Order Service는 Customer Service가 발행한 이벤트를 확인한 뒤 최종으로 신용 승인 이벤트인 경우에는 주문승인처리를 수행하고, 신용한도 초과됨 이벤트인 경우에는 주문처리취소를 수행하게 됩니다.

이와 같이 하나의 큰 트랜잭션으로 묶지 않고 3개의 로컬 트랜잭션으로 처리함을 볼 수 있습니다.

 

 

Orchestrator SAGA

이벤트를 통해서가 아니라 Orchestration 클래스가 직접 처리하는 방식입니다. 살펴보면 주문서비스가 주문을 생성하고, CreateOrderSaga 클래스를 생성합니다. CreateOrderSaga는 고객서비스에 승인한도조회 명령을 보냅니다. 고객서비스는 한도를 조회하여 CreateOrderSaga에 바로 응답을 줍니다.

 

마이크로 서비스 : SAGA 패턴 : 정의, 개념, 종류, 개요

 

이전 패턴에서처럼 메시지 이벤트를 사용하지 않고 동기식 API를 사용합니다. CreateOrderSaga는 바로 신용이 충족됐는지 한도가 초과되었는지를 알 수 있습니다. 따라서 그 결과를 주문서비스에게 가르쳐 주고, 주문서비스는 최종으로 주문을 승인하거나 취소를 하게 됩니다.