MSA(Micro Service Architecture)란?

* 해당 내용은 CS(Computer Science) 스터디를 하며 공부한 내용을 정리한 글입니다.

 

 

마이크로서비스는 최근 많은 조직에서 고도의 에자일(Agile)성, 전달 신속성, 확장성 등의 이유로 채택하고 있는 서비스 아키텍처입니다.

 

기존의 Monolithic Architecture와 MSA의 변화와 차이를 중점으로 작성하겠습니다.

 

 

Monolithic Architecture

모놀리틱 아키텍처는 서비스의 아키텍처를 구성할 때 모든 서비스를 구성하는 비즈니스 로직, DB, UI 등은 논리적으로 모듈화될 수 있지만 하나의 패키지에 담아 빌드하고 배포하는 방법입니다.

(서버 한 대에 모든 DB와 API를 둔 뒤 서버 한 대로 배포를 진행하는 방식!)

형상은 아래 그림과 같습니다.

 

2013년도 쿠팡(Coupang)의 아키텍처

 

쿠팡을 예로 들어서 살펴보면, 다음과 같이 서버 한 대에 모든 API나 비즈니스 로직을 둔 뒤에 서버 한대로 배포를 진행하는 방식입니다.

이러한 형상은 기존에 가장 많이 사용되던 아키텍처로 빠르고 쉽게 서비스를 구성할 수 있어 적은 비용으로 서비스를 출시할 수 있다는 장점이 있습니다.

Monolithic Architecture의 한계점

하지만, 이러한 단순한 접근방법은 서비스의 규모가 커짐에 따라 한계점이 존재합니다.

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

• 개발자의 잘못된 코드 배포로 인해 성능에 문제가 있을 때, 서비스 전체의 장애로 확대될 수 있습니다. 만약 서비스 하나에서 메모리 누수 등의 문제가 나타나면 전체적인 성능 저하로 이어지게 됩니다.

1. 부분적인 Scale-out(서버 증강)이 어렵습니다.

• 쿠팡을 예로 들면, 만약 주문이 너무 많이 발생해서 트래픽적으로 문제가 발생하여 Scale-out으로 문제를 히결해야할 때, 주문 API 서버만 Scale-out하면 되는 것이 아니라 과하게 사용되지 않는 다른 모든 서비스가 Scale-out되어야하는 문제점이 존재합니다.

1. 서비스의 변경이 어렵습니다.

• 여러 컴포넌트가 하나의 서비스에 강하게 결합되어 있기 때문에 수정에 대해서 영향도 파악이 힘듭니다. 이는 결국 새로운 기능의 개발, 수정에 대해서 개발기간 지연을 야기합니다.

 

MSA의 등장

마이크로서비스 아키텍처의 표준 정의는 다음과 같습니다.

마이크로서비스 아키텍처 스타일은 각자 별도의 프로세스에서 실행되며, HTTP 자원 API 같은 가벼운 매커니즘으로 통신하는 작은 서비스를 모아 하나의 어플리케이션을 만든다. 이런 작은 서비스들은 각자의 비즈니스 기능을 담당하고 완전 자동화된 절차에 따라 독립적으로 배포 가능하다.

많은 조직에서 모놀리틱 아키텍처의 문제를 마이크로서비스 아키텍처를 도입하여 해결해왔습니다. 단일 서비스로 구축하는게 아닌 작게 쪼개서 개발하는 방식입니다.

MSA의 원칙

마이크로서비스를 구현할 때 지켜야할 원칙이 있습니다. 서비스 하나에 책임도 하나, 서비스는 자율적 이렇게 2가지 입니다.

 

서비스 하나에 책임도 하나

객체지향에서 흔히 이야기하는 SOLID 패턴의 S, Single Responsibility Principle을 의미하는 것이 맞습니다. 이 원칙은 클래스든 함수든 하나의 단위 요소는 반드시 하나의 책임만을 가져야 한다는 말입니다. 하나의 단위 요소가 여러 책임을 가지게 되면 결국 다른 요소들과 높은 결합도를 형성하게 됩니다. 이러한 단일 책임 원칙이 서비스 차원에도 적용해야 한다는 것입니다.

 

마이크로서비스는 자율적

마이크로서비스는 독립적으로 배포할 수 잇으며, 자율적인 서비스로서 비즈니스의 범위와 실행에 대한 전적인 책임을 져야합니다. 마이크로서비스는 라이브러리 의존성을 포함한 모든 의존 관계와 컨테이너 또는 물리적인 자원을 추상화하는 가상머신을 모두 함께 갖고 있어야합니다.