MSA의 태동

기능단위로 서비스를 나눈 아키텍처라고 볼 수 있겠다.

보통 싸피에서는 여러개의 서비스별 서버를 실행할 경우, 이를 MSA라고 부른다.

개인적으로, csr방식으로 front와 back을 나눈것부터 MSA의 시작이라고 생각한다.

MSA 구성요소

MSA 적용시 장점

기존의 monolithic 아키텍처와 비교했을 때 다음과 같은 장점이 있다.

• 부분적인 장애 발생시, 전체 서비스 장애로 이어지지 않는다.
• 서비스별로 Scale-out이 가능하다. 예를들면, 게임 챔피언을 추천해주고, 게임 매치승 예측하는 게임을 제공하는 웹사이트를 생각해보자. 게임챔피언 추천 트래픽은 적고, 매치승을 예측하는 서비스에 트래픽이 몰린다면, 해당 서비스 서버만 증설하면 된다.
• 서비스 간 느슨하게 결합되있다. 특정 서비스 수정시 어떤 부작용이 있는지 에측이 쉽다.
• 배포가 모놀리식보다 빠르고 쉽다.
• 개발 스택 선택이 자유롭다**. spring, fast api, express** 등 서비스별로 여러 프레임워크를 선택할 수 있다.
• 서비스 별 추상화를 통해, 의존성이 최소화된다.

→ 즉, 서비스가 다양하지 않으면, 사실 msa는 필요가없다.

MSA 적용시 단점

• 복잡하다
• 서비스 별 통신을 어떻게 가져가야 할지 정해야한다.