MSA?
마이크로서비스(microservice)는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다.
마이크로서비스 아키텍처(주로 마이크로서비스라고도 함)란 애플리케이션 개발을 위한 아키텍처 스타일을 의미합니다. 마이크로서비스를 사용하면 대규모 애플리케이션을 각각 담당 영역을 가진 소규모의 독립적인 구성요소로 구분할 수 있습니다.
MSA는 비즈니스 요구사항에 의해 기존에 하나였는 서비스를 여러 개의 별도의 서비스로 분리해서 관리하는 아키텍쳐를 의미합니다.
기존의 큰 하나의 덩어리로 뭉쳐져 있던 서비스를 분리해서 서비스간 서로 영향을 미치지 않고, 서비스 별로 배포할 수 있다는 장점이 존재합니다.
하지만, 기존보다 복잡해진 아키텍쳐를 관리해야 하고, 트랜잭션 관리 등에 대해서는 신경을 모놀리틱 아키텍쳐보다 써야 한다는 단점이 존재하죠.
특히 트랜잭션 관련해서는 기존에는 없던 문제가 생깁니다!!
기존에는 하나의 프로젝트 안에서 하나의 DB로 관리해서 비교적 편리하게 트랜잭션 관리가 됐습니다!
스프링의 경우에는 @Transactional 어노테이션을 붙이면 편하게 처리할 수 있죠.
하지만 MSA에서는 각 서비스가 별도의 어플리케이션이기 때문에 처리를 추가로 해줘야합니다!
서비스간 내부적으로 작업이 실패했는지 알 수가 없다.
서로 작업이 실패했는지 알려줘야 하는 별도의 트랜잭션 처리 작업이 필요한 이유입니다!
트랜잭션 패턴
1. 2-Phase Commit 패턴 (2PC)
트랜잭션 처리, 데이터베이스, 컴퓨터 네트워크에서 2단계 커밋 프로토콜(two-phase commit protocol, 2PC)은 원자적 커밋 프로토콜(ACP)의 일종이다. 트랜잭션을 커밋할지, 아니면 롤백할지에 대해 분산 원자적 트랜잭션에 관여하는 분산 알고리즘의 하나이다.
[위키백과 - 2단계 커밋 프로토콜](https://ko.wikipedia.org/wiki/2%EB%8B%A8%EA%B3%84%EC%BB%A4%EB%B0%8B%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C)
분산 데이터베이스 환경에서 트랜잭션 처리를 위해 사용되는 고전적인 방법입니다. 여러 노드를 거쳐서 트랜잭션의 원자성을 얻기 위한 알고리즘이죠.
다음과 같은 과정으로 진행됩니다.
- 트랜잭션 관리자는 DB 1, 2에 데이터
- 커밋할 준비가 되면, 1단계를 시작한다.
- 그리고 각 노드에 커밋 가능 여부를 묻는다.
- 모든 노드가 커밋할 준비가 됐다고 하면 2단계에서 트랜잭션 매니저는 실계 커밋 요청을 전송하고 커밋이 수행된다.
- 만약 하나의 노드라도 '아니오'라고 답하면, 2단계의 모든 노드에 트랜잭션 중단 요청을 보낸다.
2 - 1. Choreography Saga 패턴 (Saga 패턴)
이saga 패턴은 분산 애플리케이션에서 일관성을 유지하고 여러 마이크로서비스 간의 트랜잭션을 조정하여 데이터 일관성을 유지하는 데 도움이 되는 장애 관리 패턴입니다. 마이크로서비스는 모든 트랜잭션에 대한 이벤트를 게시하고 이벤트 결과에 따라 다음 트랜잭션을 시작합니다. 트랜잭션의 성공 또는 실패에 따라 두 가지 경로를 사용할 수 있습니다
마이크로서서비스간 이벤트를 주고 받아 특정 마이크로서비스에서 작업이 실패하면, 이전까지의 작업이 완료된 마이크로서비스에 보상 이벤트를 발행함으로써, 원자성을 보장하는 패턴
MSA에서 조금 쉽게 트랜잭션(Transaction) 처리하기
위와 같이 직관적으로 보상 트랜잭션을 통해 문제를 해결함으로써,
MSA 환경에서도 트랜잭션의 원자성을 보장하려고 노력하죠.
하지만 이런 Choreography Saga Pattern에도 단점이 존재합니다.
바로 App이 계속 추가되다면 시스템의 복잡도가 증가하게 됩니다!
서비스가 추가되게 된다면 내부 트랜잭션 처리에 대한 결과에 대한 보상 트랜잭션 또한 늘어나므로 시스템의 복잡도가 매우 증가하게되죠
그리고 이에 따른 의존성 처리도 복잡해 지게 되고요
2 - 2. Orchestration Saga 패턴
중앙에 오케스트레이션 서버를 놓고 해당 서버에서 메세지 라우팅, 이벤트 스토어 기능등을 제공하는 형태
위의 문제를 해결한 패턴이 바로 오케스트레이션 사가 패턴입니다.
각 서비스별로 서로 메세지를 주고 받는 대신, 중앙의 오케스트레이션 서버로 메세지를 보내고, 해당 서버는 각 서비스에서 도착한 메세지 및 트랜잭션 처리 결과를 관리하는 역할 을 수행하죠.
해당 아키텍쳐의 위상은 여러 VPC간의 통신을 도와주는 Transit-Gateway과 유사해 보이는군요!
단점
하지만 위와 같은 위상을 가지더라도 단점은 존재하게 됩니다.
카프카와 같은 메세지 큐로 각 서버와 오케스트레이션 서버간의 메세지 전달은 할 수 있겠지만
처리된 결과의 도착 여부, 넘어간 메세지의 처리 여부 등의 기능도 필요하므로 추가 기능 개발이 필요하다는 단점이 존재합니다.
개발 기간이 부족하다면 구현하기 빡세겠죠
With Axon Server
이 문제는 Axon Server를 사용하면 비교적 쉽게 오케스트레이션 서버를 구성할 수 있습니다.
MSA에서 조금 쉽게 트랜잭션(Transaction) 처리하기 14:48
Spring 기준 Maven 및 Gradle에 의존성을 추가해서 사용할 수 있다.
Axon vs Kafka
대표적인 메세징 서비스인 카프카와 비교했을 경우
차이점은 아래와 같습니다.
| Kafka | Axon | |
|---|---|---|
| 코드 구현 여부 | 직접 해야함 | Axon Framework 이용 |
| Topic 관리 | 직접 해야함 | Axon Framework 이용 |
| DDD지원 | X | O |
| 기술 종속성 | Kafka | Axon Framekwork |
| Event 성공 여부 관리 | 직접 해야함 | Axon Framework 에서 처리 |
| 학습 곡선 | Pub/Sub 모델에 대한 이해 필요 | DDD, CQRS, Event Sourcing |
| 라이션스 | 무료 | 유/무료 |
참고
