MSA (MicroService Architecture) vs Monolithic Architecture

Monolithic Architecture

 

  MSA에 대해 이해하기 위해서는 우선적으로 모놀리틱 아키텍쳐에 대한 이해가 필요하다.

  모놀리틱 아키텍쳐는 MSA가 도입되기 이전에 활용하던 전통적인 개발 방식으로 전체 어플리케이션을 하나의 덩어리로 개발하는 것을 말한다. 모놀리틱 아키텍쳐가 지니는 장점들은 다음과 같다.

 

1. 시스템 전체의 개발 환경이 동일하다는 점에서 개발이 편리하다.

2. 배포, 테스트 등 모든 과정이 하나의 어플리케이션에 대해 이루어지기 때문에 운영 관리가 편리하다. (특히 E2E 테스트에서 강점을 가진다.)

 

  그러나 시스템의 규모가 일정 수준 이상이 되면 모놀리틱 아키텍쳐는 수많은 한계를 맞닥뜨린다.

1. 부분 장애가 전체 서비스 장애로 이어질 수 있다.

2. 빌드 및 테스트 소요 비용이 증가한다. (작은 수정사항에도 전체 시스템을 다시 빌드하고 테스트해야 하기 때문)

3. 서비스가 커질수록 복잡도가 기하급수적으로 증가하기 때문에 전체 시스템의 구조 및 각 요소 파악이 어렵다. (여러 요소들이 강하게 연결되어 있기 때문에 새로운 요소를 추가하기도 어렵다.)

4. 특정 개발 환경에 종속적이다. (목적에 따라 적합한 개발 언어 등 환경을 선택하는 것이 필요한 경우가 존재하는데 전체 시스템이 하나의 개발 환경에서 개발되는 모놀리틱 아키텍쳐는 최적화된 기술 활용이 불가능하다.)

5. 부분적인 Scale out이 어렵다. (모든 서비스가 Scale out되어야 하기 때문에 비효율적이다.)

 

 

MicroService Architecture

위와 같은 모놀리틱 아키텍쳐의 한계를 극복하기 위해서 MSA가 등장하게 되었다. MSA는 여러가지 작은 서비스들을 만든 후 그를 조합하여 전체 시스템을 구현하는 방식이다. 각 컴포넌트들은 API들을 통해서만 인터렉션하며 내부 로직과 같은 구체적인 각 서비스의 내부는 공개되지 않는다. 각각의 서비스는 자신이 담당하는 하나의 목표만을 수행하며 재사용성이 뛰어나다. 최근 많은 시스템들이 클라우드 환경을 통해 물리적 시스템 기반 Monolithic Architecture에서 MSA로 전환하는 모습을 보여주고 있다.

 

• MSA의 장점

1. 각각의 서비스를 빠르게 개발하고 유지보수할 수 있다.

2. 서비스 별로 독립적인 테스트 및 배포가 가능하다.

3. 서비스의 목적에 따라 적절한 기술을 선택할 수 있다. (언어, DB 등)

4. 서비스의 부하에 따라 그에 적합한 사양을 선택할 수 있다. 즉, 효율적인 Scale out이 가능하다.

5. 일부 요소의 장애가 전체 시스템의 장애로 이어질 가능성이 상대적으로 낮다.

 

• MSA의 단점

1. 분산된 서비스들을 연결시키는 부분이 복잡하다. (API를 통해서만 소통하는 독립적 요소들이기 때문에 신중한 인터페이스 개발이 필요하다.)

2. 에러가 발생할 경우 트랜잭션을 어떻게 처리할 것인지에 대한 고민도 필요하다. (일반적으로 MSA는 서비스별로 별도의 DB를 사용하는 경우가 많다.)

3. 서비스들 간 통신의 과정에서 오버헤드가 발생한다. (ex. 서비스 간 메시지 처리 비용, 데이터 주고받을 때 변환 작업 필요)

4. E2E 테스트 혹은 다른 서비스와 연관성이 있는 기능을 테스트하는 것에서 어려움을 가진다.

5. 시스템이 분산되어 있기 때문에 전체 어플리케이션의 모니터링이 번거롭다.

6. 각각의 서비스가 다른 서버에 위치하기 때문에 API 게이트웨이 등을 통해서 전체 어플리케이션의 API를 묶어주는 작업 등이 필요하다.

 

 

결론

소규모의 어플리케이션에서는 Monolithic Architecture가 보다 적합한 모습을 보여준다. 또한 MSA를 처음 구현하는 과정에서 발생하는 비용 및 요구되는 역량 역시 적지 않다. 그러나 서비스가 확장되고 발생하는 부하 역시 증가한다면 서비스의 확장성과 안정성을 위해서 유연하게 아키텍쳐를 전환하는 모습이 필요할 것으로 보인다.