[MSA] MSA의 단점과 진입장벽이 높은 이유

 

MSA의 단점? 진입장벽?

 

IPC

MSA환경에서 다른 모듈을 호출하려면 타 서비스 호출을 위한 통신을 활용해야한다 (HTTP/gRPC)

Keepalive, CP, Timeout..등에 대한 개념과 트러블슈팅을 위해 판단능력이 있어야 한다.

 

 

Transaction

A ,B, C 순서대로 기능을 호출하다가 C가 실패한다면.. A,B도 Rollback 되어야한다.

모놀리식에서는 한통에 모든 소스(모듈들)가 있기때문에 Springboot의 @Transaction을 사용해도 무방하다. 알아서 롤백시켜줌.

그치만 MSA는 각각의 기능(모듈)이 독립적으로 분리되어있기에 @Transaction을 써봤자 내 모듈에서만 유효하다.

타 서비스(모듈)로 I/F하는거라면 타 서비스꺼는 자동롤백되지 않는다.

그렇기에 실패가 발생할경우 실패라는 Event를 I/F하고 실패에 대한 Rollback 로직을 직접 작성해야한다. (보상 트랜잭션 -> SAGA 패턴)

트랜잭션 구성하는 것은 매우 난이도가 높으니.. 사용하지 않는게 최선이다?...

 

SAGA 패턴이란 마이크로서비스들끼리 이벤트를 주고 받아 특정 마이크로서비스에서의 작업이 실패하면 이전까지의 작업이 완료된 마이크서비스들에게 보상 (complemetary) 이벤트를 소싱함으로써 분산 환경에서 원자성(atomicity)을 보장하는 패턴입니다.

해당 SAGA 패턴의 핵심은 트랜잭션의 관리주체가 DBMS에 있는 것이 아닌 Application에 있습니다. Application이 분산되어 있을때는 각 Applicatin은 하위에 존재하는 DB는 local 트랜잭션만 담당합니다.
즉, 각각의 Application의 트랜잭션 요청의 실패로 인한 Rollback 처리(보상 트랜잭션)은 Application에서 구현합니다.

출처:  https://azderica.github.io/01-architecture-msa/

 

 

Data Query

DB도 분산되어있기에 복잡한 조건의 통계나 결과값을 내려면 타시스템끼리 모두 I/F가 필요하여 쉽지 않다.

이에 대한 내용으로 API 조합패턴 ,CQRS패턴 이있다.

* 참고 : https://taes-k.github.io/2020/11/22/msa-5/ 
API 조합 패턴의 개념은 어렵지 않습니다. 클라이언트 측에서 각각의 MSA 서비스들을 호출하는것이 아닌, MSA로 나누어진 여러 서비스들의 데이터를 조합해주는 API 조합기를 두어 클라이언트는 API 조합기만을 호출함으로써 원하는 조합된 데이터를 얻는형태의 패턴입니다.
만약 현재 서비스에 API 게이트웨이가 적용되어 있다면 API 게이트웨이를 API 조합기로 사용 할 수도 있습니다.

Command and Query Resposibility Segregation 이하 CQRS은 말 그대로 Command (명령)과 Query (조회)를 분리하는 패턴입니다.

일반적인 엔터프라이즈 어플리케이션에서 데이터는 RDBMS에서 관리를 하고 텍스트 서치 들을 위해 ES(Elastic search)나 Solar등을 이용하는것 처럼 명령과 조회를 분리하는 패턴을 CQRS라고 합니다.

 

 

 

모니터링

어떤 서비스의 어떤 트랜잭션 의 어떤 구간에서 문제가 생겼는지?