MSA(MicroService Architecture)

일단 들어가기에 앞서 마이크로 서비스 아키텍쳐에 대한 정확한 정의는 존재하지 않는다. 따라서 MSA에 대해 설명할 때에는 대략적으로 이게 어떤 것인지 밖에 설명할 수 없다.

MSA란?

• 작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크이다.
• 마이크로서비스는 완전히 독립적으로 배포가 가능하고, 다른 기술 스택이 사용 가능한 단일 사업 영역에 초점을 둔다.

MSA의 등장 배경

MSA는 Monolithic Architecture의 문제점들을 보완하기 위해 등장하였다.

• Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태이다.
• 웹 개발을 예시로 들면 모듈별로 개발을 하고, 개발이 완료된 웹 어플리케이션을 하나의 결과물로 패키징하여 배포하는 형태이다.
• 주로 소규모 프로젝트에서 사용되고, 유리하다.
• 일정 규모 이상의 서비스, 혹은 많은 개발자가 투입되는 프로젝트에서 Monolithic Architecture는 한계점이 명확하다.

1.부분적인 장애가 전체 서비스의 장애로 확대될 수 있다.

• 개발자의 잘못된 코드 배포 또는 트래픽 급증에 의해 성능에 문제가 생겼을 때, 서비스 전체의 장애로 확대될 수 있다.

2.부분적인 *Scale-out(여러 server로 나누어 일을 처리하는 방식)이 어렵다.

• Monolithic Architecture에서는 사용되지 않는 다른 모든 서비스가 Scale-out 되어야 하기 때문에 부분 Scale-out이 어렵다.

3.배포 시간이 오래 걸린다.

4. 하나의 Framework와 언어에 종속적이다.

• Spring framework를 사용할 경우 java를 이용하여 해당 모듈을 작성할 수 밖에 없다.

이러한 Monolithic Architecture 문제점들을 보완하기 위해 MSA가 들장하게 되었다.

MSA의 장점

• 각각의 서비스는 모듈화가 되어있으며 이러한 모듈끼리는 RPC 또는 message-driven API 등을 이용하여 통신한다.
• 이러한 MSA는 각각 개별의 서비스 개발을 빠르게 하며, 유지보수도 쉽게 할 수 있도록 한다.
• 팀 단위로 적절한 수준에서 기술 스택을 다르게 가져갈 수 있다

MSA의 단점

• MSA는 모놀리식에 비해 상대적으로 많이 복잡하다.
• 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야 한다.
• 또한, 통신 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야한다.
• 통합 테스트가 어렵다. 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않다.
• 실제 운영환경에 대해서 배포하는 것이 쉽지 않다.
• 마이크로서비스의 경우 서비스 1개를 재배포한다고 하면 다른 서비스들과의 연계가 정상적으로 이루어지고 있는지도 확인해야 한다.