MSA 설계 시 고려해야할 것들

이번 포스팅에서는 MSA를 설계할 때 고려해야할 것들, 주의할 점등에 대해서 알아보자.

MSA의 설계 철학
. service의 크기는 작아야한다.
. test 및 자동 배포를 하여 유지보수 부담을 낮춰야 한다.
. 각 작업자는 자신의 코드영역만 작업할 수 있어야 한다.
. 각 service는 유연하고 회복력이 있게 구성되어야 하며, 해당 service만으로도 완전해야 한다.
. 각 service는 구분되며 이에 필요한 기술스택은 다양할 수 있다.

위의 설계 철학에 따른 구조를 위 그림과 같다고 할 수 있을 것이다.
일부 시스템은 단일 서비스로 구현되고 어떠한 시스템은 여러 service에 분산 될 수 있다.
분산되는 service의 경우 HTTP를 통해 통신하거나 Kafka와 같은 메세지 브로커를 비동기식으로 사용해 구현될 수 있다.
그렇다면  MSA 적용시 어떠한 점들을 고려해야 할까?
우선 우리의 프로젝트가 과연 MSA를 적용하는것이 옳은지 생각해봐야한다.
만약 MSA를 적용하기에 비효율적으로 복잡하거나 런타임 시 결합이 긴밀할 것으로 생각된다면 MA를 적용하는 것이 좋을 수 있다.
MSA를 적용하기로 했다면 이제 분산 작업을 설계할 차례이다.
MSA를 사용할 때 우리는 service를 분산시킬 것이며, 이는 각 service가 고유 DB를 지닌다는 얘기가 된다.
이로인해 DB에 대해 어떻게 접근할 지를 고려해야 하며 DB와 관련된 여러가지 문제가 발생할 수 있다. 해결책으로는 아래 이미지의 여러 패턴을 적용하는 것이 있지만 이 내용은 다소 분량이 커서 다른 포스팅에서 다루기로 한다.

DB외에도 고려해야 할 점은 또 있다.
우선 service를 구분하는 범위에 대한 기준을 정해야 한다.
단순히 A service로 묶을지 혹은 A의 기능인 A`와 A``를 개별 service로 묶을지에 대한 기준이다.
이러한 기준은 비즈니스 혹은 해당 서비스에 따라서 달라질 수 있다.
그 외에도 service내에서 API를 어떻게 설계할지, 또는 service간의 종속성과 배포 용이성, 장애 대응을 어떻게 할지 등등 고려해야할 점이 많다.


참고 -
https://microservices.io/patterns/microservices.html https://ko.m.wikipedia.org/wiki/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4