MSA ( Micro Service Architecture )를 알아보자.

kshired·2021년 11월 14일

요즘 MSA라는 단어가 공부하다보면 심심치않게 나오는 것을 알 수 있습니다.

저도 어떠한 개념인지 대충만 알고있고 어떠한 패턴인지 확실히 몰라, 그것에 대한 개념을 정리하기 위해 글을 써보겠습니다.

일단 MSA에 대해 이해하기 위해서는, Monolithic 아키텍쳐부터 알아봐야합니다.

Monolithic

Monolithic은 간단하게 말하면, 모든 요소들이 하나의 프로젝트로 통합되어 이루어진 형태로 보통 토이 프로젝트를 개발할 때 많이 사용하는 구조입니다.

이러한 단일 구조는 여러가지 단점이 존재하여 요즘 뜨고있는 아키텍쳐가 MSA라고 생각합니다.

Monolithic의 단점은 아래와 같습니다.

하나의 언어와 프레임워크에 종속적이다.
- 새로운 기능을 추가하려할 때, 만약 그 언어와 프레임워크에서 구현하기 상대적으로 불편하더라도 그것에 종속적으로 개발을 진행해야합니다.
특정한 기능만 scale-out하기 어렵다.
- 모든 기능들이 하나의 프로젝트로 통합되어 있기때문에, 특정한 기능만 scale-out하기는 어렵습니다.
부분적인 장애가 전체 서비스의 장애로 확대될 수 있습니다.
- 보통 서비스간의 결합도가 높고, 모든 서비스들이 하나의 프로젝트로 통합되어있는 상태이기때문에 하나의 장애가 전체의 장애를 일으킬 수 있는 확률이 높습니다.

위와 같은 Monolithic의 단점을 해결하기 위해 나온 것이 MSA입니다.

간단하게 말하자면, MSA는 결합도가 낮은 서비스의 집합으로 이루어진 Service Oriented Architecture 스타일의 개발 기법입니다.

각각의 서비스들은 작고, 독립적이며, 느슨한 결합을 지향합니다.

서비스를 독립적으로 배포할 수 있고, 팀이 전체 애플리케이션을 다시 빌드한 후 재배치하지 않고 기존 서비스를 업데이트할 수 있습니다.

또한 각각의 서비스들은 다른 기술스택으로 사용이 가능한 단일 영역으로 이루어질 수 잇습니다.

각각의 서비스들은 API를 통해 상호작용합니다.
- 각 서비스들은 End point를 통해 API와 같은 형태로 정보를 주고받으며 세부적인 구현은 추상화하게 됩니다.
하나의 서비스는 하나의 기능만 수행해야합니다.
- 각 서비스들은 자신만의 비즈니스 범위가 정해져있으며, 자신이 커버하게 되는 비즈니스 범위만 담당합니다.
각 서비스들은 상호 독립적입니다.
- 하나의 서비스의 장애가 다른 서비스의 장애를 일으키지 않습니다.
기술에 독립적입니다.
- Monolithic과 달리 각각의 서비스들은 다른 언어와 프레임워크로 작성될 수 있으며, API 형태로만 통신할 수 있으면 됩니다.
집중화된 관리체계를 사용하지 않습니다.
- REST와 같은 HTTP 통신 혹은 Kafka 같은 Message를 통해 데이터를 주고 받을 뿐, ESB와 같은 무거운 서비스가 집중화된 관리를하지 않습니다.