[24.03.01] 마이크로서비스 안티 패턴

 

 

이번 주제는 마이크로서비스 구축 시 안티 패턴에 관한 주제입니다.

 

1. Monolith in Microservices

첫 번째로 마이크로서비스의 단일 DBMS 사용이다.

기본적으로 MSA 에서는 각 서비스마다 DB 인스턴스를 가지는게 일반적이다.

왜냐하면 데이터베이스 유형, 스키마 규칙, IOPS 용량을 각자 설정할 수 있기 때문이다.

 

두 번째로는 배포의 복잡성이 증가하는 것이다.

기존 Monolithic 버전의 빌드 및 배포보다 복잡한 배포과정을 가진다면 MSA 의 장점인 유연하고 민첩한 배포가 불가능하므로

이러한 부분을 쉽게 관리할 수 있도록 해야한다.

 

마지막으로 불분명한 도메인 경계이다.

예시로 User 관련 기능들이나 ACL 같은 기능들이 모든 서비스에서 중복으로 관리되어지고있다면 

아키텍처를 개선하는데 큰 어려움이 있다.

 

따라서 도메인 주도 설계 및 마이크로서비스 당 단일 DB 인스턴스를 가지는 게 좋다.

2. Chatty Microservices

마이크로서비스로 분리하면서 서비스 간 통신(REST, IPC..)이 필요한 경우가 많다.

이러한 경우 과도한 통신이 일어날 수 있다.

예시 3가지를 소개한다.

 

첫 번째로는 소량의 데이터를 얻기 위해서 대량의 데이터를 보내 레이턴시가 높게 나타나는 경우이다.

두 번째로는 너무 많은 세분화 서비스들은 빈번한 네트워크 지연, I/O Blocking, 직렬화과정에서 문제를 일으킬 수 있다.

마지막으로 수 많은 네트워크가 실패 시 처리가 제대로 이루어지지 않으면 이후 요청들에도 문제가 발생할 수 있다.

 

이러한 문제를 해결하기 위해선 서비스 간의 분리를 확실하게 하고 스케일링이 쉽도록 설계해야한다.

아래의 그림처럼 서비스 간의 직접 통신이 줄어들어 위의 문제들을 해결할 수 있다.

물론 HA, 확장성 부분에서 관리 포인트가 늘어난다...

 

3. Distributed Monolith

분산된 모놀리스? 무슨 의미일지 궁금하다.

아래 예시를 보자.

분리된 독립 서비스로 운영되지만 orderService, paymentService, invoiceService는 모두 의존하고있다.

이러한 경우 문제가되는 것은 데이터 일관성의 문제이다.

또한 서비스들은 서비스가 사용하는 다른 서비스를 알아야해서 상호 의존성이 생기게 된다.

위의 문제를 해결하기 위해서는 메세지 큐를 사용하여 서로에 대한 의존성을 끊어줄 수 있다.

 

4.Distributed Data Inconsistency

난 개인적으로 이 부분이 가장 중요하다고 생각한다.

아무리 좋은 아키텍처 및 설계로 서비스를 나누었다고해서 기존 데이터 변화가 정상적으로 작동하지 않는다면 무용지물이다.

예시를 몇 가지 보자.

 

첫 번째는 대부분 통신은 비동기 방식으로 진행된다. 그러다보니 레이턴시가 생겨서 순간(5초 이내) 데이터가 일치하지 않을 수 있다.

두 번째는 네트워크 에러이다. 이것은 보상 트랜잭션이나 에러에 대한 롤백이 정상적으로 되지 않을 경우 큰 문제가 된다.

마지막은 동시성 문제이다. OrderService의 인스턴스가 3개라고 생각해보자. 만약 스케줄 잡이 돌고있다면 동시에 어떠한 데이터를 건드려 분산 데이터의 불일치가 발생할 수 있다.

 

이러한 부분은 각 서비스의 동시성에 대한 꼼꼼한 처리 및 Saga Pattern, Outbox Pattern, DeadLetter Queue 등으로 해결할 수 있지만 매우 복잡하다..