Monolithic Architecture, Micro Service Architecture

Monolithic Architecture, Micro Service Architecture (MSA) 에 대해 알아보기 전 먼저 두 아키텍쳐를 비교하는 그림을 살펴봅시다.

 

** 왼쪽은 모놀리식(Monolithic),  **오른쪽은 마이크로 서비스(Micro Service)

 

Monolithic vs Microservice

 

Monolithic vs Microservice

 

보다싶이 Monolithic은 하나의 Project로 통합되어 개발되는,  MSA는 모듈별로 개발한다는 것을 알 수 있습니다.

이제 본격적으로 두 아키텍쳐의 특징과 장단점을 알아봅시다.

Monolithic Architecture

기존에 사용하던 전통적 개발 방법으로 모든 시스템, 소프트웨어의 구성요소가 한 프로젝트에 통합되어 있는 구조입니다.

 

1 Project : 1 Application으로 구성되어 보통 동일한 개발 툴을 이용해 개발하고, 배포와 테스트도 하나의 Application만 수행하면 되기 때문에 개발 및 환경설정이 간단하기 때문에 주로 소규모 프로젝트에서 많이 쓰입니다. 

 

장점 

•  Local 환경에서 개발 편리함

•  통합 시나리오 테스트 진행 수월

•  간편한 배포

 

하지만 프로젝트의 규모가 커질수록 위 같은 장점도 단점으로 바뀌는 순간이 옵니다.

 

단점

•  코드의 수정 및 추가, 효율적인 자원관리가 어려움

   - 여러 컴포넌트가 하나의 서비스에 강하게 결합되어 있기 째문에 수정에 대한 영향도 파악이 어려움

 

•  Build 및 Test 시간이 길어짐

   - 작은 수정에도 시스템 전체를 빌드해야하고 테스트 시간도 길어진다.

 

•  scale out, 자주 업데이트 불가능 

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

 

•  부분의 장애가 서비스 전체적인 장애로 이어짐 

   - 이벤트 서비스에 트래픽이 몰려 해당 서버가 죽게 되면 다른 모든 서비스 역시 마비되는 상황 발생  ex) 수강신청..ㅎ

   - 개발자의 잘못된 코드 배포 또는 갑작스런 트래픽 증가로 인해 성능에 문제가 발생했을 때, 서비스 전체 장애로 확대됨

 

•  새로운 기술 적용이 어렵고 한 Framework 와 언어에 종속적이게 된다.

   - 만약 Spring Framework를 사용할 경우 blockchain 연동 모듈을 추가할 때 node.js를 사용하는 것이 일반적인 강세이다. 그러나 java를 이용하여 해당 모듈을 적용할 수 밖에 없다. 선정했던 framework가 Spring이기 때문이다.

---

소규모 프로젝트인 경우에는 특별히 나눌 필요 없이 Monolithic Architecture가 합리적일 수 있으나, 프로젝트의 규모가 커지고 한 프로젝트에 속한 개발자수가 많아질 수록 위 같은 단점들이 부각되어 나타납니다.

 

또한 최근 등장하는 프로젝트는 대체로 많은 기능, 대규모로 구성되어 있기 때문에 이러한 Monolithic 의 한계점을 극복할 수 있는 MSA가 등장하게 되었습니다. 

 

특정한 물리적인 서버에 서비스를 올리던 on-promise 서버 기반의 Monolithic Architecture에서  클라우드 환경을 이용하여 서버를 구성하는 MicroService Architecture로 많은 서비스들이 전환되고 있습니다. 

---

Micro Service Architecture , MSA

하나의 큰 어플리케이션을 여러 개의 작은 어플리케이션으로 나눠 만드는 아키텍쳐로  MSA는 1개의 시스템을 독립적으로 배포가능한 각각의 서비스로 분할합니다. 즉, MSA는 독립된 각각의 모듈을 조립하여 만드는 하나의 서비스를 위한 아키텍쳐입니다. ( SRP, Single Responseiblity Principle 단일책임원칙 중요 ) 

 

MSA로 구성된 각각의 서비스는 API를 통해서만 데이터를 주고받으며 1개의 큰 서비스를 구성합니다. 즉, 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부사항은 모두 추상화 합니다. 내부의 구현로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려집니다.

 

장점 

•  일부 서비스에 장애가 발생하여도 전체 서비스에 장애가 발생하지 않는다.

   - 각각의 서비스가 모듈화 되어 있어 각각 개별 서비스를 빠르게 개발할 수 있고, 유지보수도 쉽게 할 수 있도록 설계되어 있다.

 

•  각각의 서비스들은 서로 다른 언어와 프레임워크로 구성될 수 있다.

   - 팀 단위로 적절한 수준에서 기술 스택을 다르게 가져갈 수 있습니다.

 

•  Scale - out 가능하여 서비스의 확장이 용이하다

   - 서비스 별로 독립적인 배포가 가능하다.

   - 각각 서비스의 부하에 따라 개별적으로  scale-out이 가능하다. 메모리, CPU 적으로 상당부분 이득이 된다.

 

단점 

•  서비스가 분리되어 있어, 테스팅이나 트랜잭션 처리 등이 어렵다.

   - 개발환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않기 때문에 통합테스트가 어렵습니다. 

   - 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되어 있기 때문에 트랜잭션을 유지하는 것이 어렵습니다.

 

•   API Gateway, 서비스 간에 API로 통신하기 때문에 그에 대한 비용이 발생한다.

   - 각 서비스가 다른 서버로 분리 배포되어 있기 때문에 서버 URL이 다를 수밖에 없습니다.

   - 이 때 API Gateway는 API 서버 앞 단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할을 합니다. 

 

•  서비스 간의 호출이 연속적이기 때문에 디버깅 및 에러 트레이싱이 어렵다.

 

이처럼 MSA는 서비스가 모두 분산되어 있기 때문에 내부 시스템의 통신을 어떻게 가져가야할지, 통신 장애와 서버의 부하등이 있을 경우 어떻게 트랜잭션을 유지할지 결정하는 등 모놀리식에 비해 상대적으로 많이 복잡합니다.

 

 

학습에 많은 도움이 된 링크를  참조했습니다. 🙂

 

참조 및 출처

[MSA] Monolithic Architecture VS Micro Service Architecture

마이크로서비스 아키텍처(MSA) 개념 소개

[MSA] MSA란 무엇인가? 개념 이해하기