✨ MSA 환경에서 분산 트랜잭션 (2PC, SAGA)

들어가며

클라우드 인프라 기술이 대두되면서 유연한 확장과 안정성을 추구하는 많은 회사에서 MSA 아키텍처를 도입하게 되었습니다. (클라우드 인프라와 MSA)

 

MSA 아키텍처를 도입한다면 기존 모놀리식 아키텍처 시스템의 한계를 극복할 수 있습니다. 여러 서비스 간의 장애 전파, 스케일 아웃, 확장의 어려움 등 여러 이점이 있습니다.

 

하지만 항상 MSA 아키텍처가 옳은 답은 아닙니다. 복잡한 구조로 유지보수가 힘들 수 있고 비용적인 부분도 무시할 수 없습니다. 이러한 MSA 구조에서 고민해야하는 부분 중 하나인 트랜잭션 작업의 원자성을 어떻게 지킬 수 있을지 알아보겠습니다.

 

모놀리식과 MSA의 트랜잭션 처리

먼저 모놀리식과 MSA의 트랜잭션 처리에 대해 비교해보겠습니다. 설명을 위해 간단하게 토스 앱에서 돈을 송금하는 상황이라고 가정해보겠습니다.

 

모놀리식 아키텍처에서 트랜잭션 처리

 

기존 모놀리식 아키텍처에서의 트랜잭션 작업 구현은 간단합니다. DB 트랜잭션을 열고 작업 후 문제가 없다면 커밋을 하여 데이터베이스가 작업을 반영하면 됩니다.

 

만약 트랜잭션 내부에서 문제가 발생했다면 롤백을 하여 데이터베이스를 작업을 하기 전과 동일한 상태로 만들어줍니다.

 

일반적으로 비즈니스 로직을 구현한다면 이런식으로 구현하게 됩니다.

 

MSA 아키텍처에서 트랜잭션 처리의 한계

 

MSA 아키텍처는 여러 서비스들 간의 통신으로 비즈니스 로직이 동작합니다. 하지만 모놀리식 아키텍처에서는 하나의 데이터베이스를 사용하기 때문에 트랜잭션 처리에 큰 문제가 없었습니다.

 

하지만 MSA의 각각의 서비스는 데이터베이스를 따로 갖고 있는 구조이기 때문에 데이터의 일관성과 하나의 작업에 대한 원자성을 보장하기 힘듭니다!

 

위 그림을 본다면 각 서비스들은 rest template과 같은 기능으로(http 프로토콜) 통신할 수 있습니다. 하지만 트랜잭션을 사용할 수 없기 때문에 동시성 문제나 데이터 일관성을 깨뜨릴 수 있습니다.

 

 

MSA 환경에서 트랜잭션을 처리하는 방법

그렇다면 MSA 환경에서 트랜잭션을 처리할 수 있는 대표적인 방법인 2PC와 SAGA 패턴에 대해 알아보겠습니다.

 

 

2PC (2-Phase Commit)

2PC는 이름 그대로 두 단계에 나눠서 커밋을 하는 방법입니다. 준비 단계와 커밋,롤백 단계로 나눠집니다.

 

 

트랜잭션을 관리하는 코디네이터가 각 서비스에게 작업을 진행하도록 요청하고 문제가 없는지 물어봅니다. 만약 트랜잭션에 참여하고 있는 모든 서비스가 문제가 없다면 다음 단계로 넘어가서 커밋을 진행합니다. 

 

 

만약 하나의 서비스라도 문제가 발생했다면 트랜잭션에 참여한 모든 서비스에게 롤백을 요청하고 트랜잭션은 실패 처리합니다.

 

2PC 패턴을 사용하면 MSA 환경의 여러 서비스 간의 트랜잭션도 하나의 트랜잭션 처럼 관리가 가능하다는 장점이 있습니다.

 

하지만 트랜잭션을 관리하는 코디네이터가 단일 장애 지점(SPOF)이 될 수 있고 트랜잭션에 참여하는 모든 서비스의 작업이 완료될 때 까지 대기를 해야하기 때문에 지연시간이 많이 발생하며 확장이 어려운 구조가 될 수 있습니다.

 

 

SAGA

SAGA 패턴은 MSA 환경에서는 데이터 일관성을 지키기 어렵다는 것을 인정하고 약간의 일관성은 포기하지만 결과적 일관성을 보장하여 효율을 높히는 패턴입니다.

 

2PC는 트랜잭션을 하나의 큰 트랜잭션으로 묶어서 관리하지만 SAGA 패턴은 각각의 서비스의 짧은 로컬 트랜잭션으로 처리하고 중간에 문제가 발생한다면 보상 트랜잭션으로 롤백을 처리합니다.

 

보상 트랜잭션은 분산된 트랜잭션 중 문제가 발생했다면 이전에 커밋된 트랜잭션을 원래 상태로 되돌리는 트랜잭션입니다.

 

이러한 SAGA 패턴을 구현하는데는 Choreography SAGA, Orchestration SAGA 이렇게 두가지 방법이 있습니다.

 

 

Choreography SAGA

Choreography SAGA는 각 서비스끼리 개별적으로 이벤트를 주고 받으면서 트랜잭션을 처리하는 방식입니다.

 

 

해당 방식은 트랜잭션을 제어하는 모듈 없이 각각의 서비스가 개별적으로 MQ나 HTTP 방식을 통해 통신을 하여 트랜잭션을 처리하는 방식입니다.

 

중앙 집중형 방식이 아니기 때문에 SPOF가 없습니다. 하지만 각각의 서비스끼리 개별적으로 통신하기 때문에 트랜잭션 동작 방식에 대한 파악이나 추적이 어려운 단점이 있습니다.

 

Orchestration SAGA

Orchestration SAGA는 Orchestrator라는 중계자를 둬서 각 서비스에게 로컬 트랜잭션 실행, 보상 트랜잭션 실행 등을 제어하는 방식입니다.

 

해당 방식은 각각의 서비스에 대한 트랜잭션을 관리하는 중앙 제어자가 있기 때문에 트랜잭션을 추적하거나 디버깅하기 편합니다. 하지만 모든 서비스가 결합된다는 단점도 있습니다.

 

해결하려는 문제 상황에 맞는 적절한 방식을 선택해 적용하는 것이 가장 옳은 방법이라고 생각합니다.

 

마무리 총총

MSA 환경에서 트랜잭션을 처리하는 방법인 2PC와 SAGA패턴에 대해 알아보았습니다.

 

2PC는 낮은 가용성과 확장하기 여러운 구조를 가지고 있어 대부분 SAGA 패턴을 선택한다고 합니다.

 

SAGA 패턴에도 Choreography, Orchestration 방식이 있어 문제 상황에 맞는 적절한 패턴을 도입하면 안정적이고 유연한 서비스를 만들 수 있을 것이라 생각됩니다.

 

 

참고자료. https://www.youtube.com/watch?v=xpwRTu47fqY