모노리틱 아키텍처 vs 마이크로 서비스 아키텍처

모노리틱 아키텍처 (Monolithic Architecture)

정의

간단히 말해서 "하나의 애플리케이션 내에 모든 로직들이 포함되어 있는 웹 서비스 구조" 이다.

예를 들어 쇼핑몰을 구축한다고 가정하면 주문관리, 상품관리 등 백엔드 로직뿐만 아니라 이를 표현하는 프론트 UX 로직까지 모든게 포함되어 있다. 상호 호출을 함수를 이용한 참조에 의한 호출 (Call-by-Reference) 구조를 취한다.

장점

• 소형 어플리케이션 서비스 개발시 편리하다.
• 하나의 통짜구조이므로 테스트와 배포가 편리하다.

단점

• 개발시 크기가 커서 빌드, 배포 시간, 서버의 기동 시간이 오래 걸린다.
• 개발 단위가 커질수록 협업하기 힘들다.
• 참조에 의한 호출 (Call-by-Reference) 구조를 취하기 때문에 전체 시스템에 대한 구조를 파악해야한다.
• 특정 컴포넌트, 모듈에 의하여 성능 문제나 장애등이 다른 컴포넌트까지 영향을 주게 된다.
• 장애 발생시 문제가 되는 컴포넌트 뿐만 아니라 전체를 다시 재배포해야한다.
• 다른 기술을 도입하고자 할 때 유연하지 않다.

 

마이크로 서비스 아키텍처 (Microservice Architecture)

정의

대용량 웹 서비스가 많아짐에 따라 SOA (Service Oriented Architecture : 서비스 지향 아키텍처)에 근간을 둔 아키텍처이다. 간단히 말해서 "서비스 단위로 컴포넌트를 여러개 분리한 아키텍처"를 말한다.

장점

• 서비스가 각자 물리적으로 분리되어 있기때문에 해당 서비스만 배포하면 되므로 유연한 배포가 가능하다.
• 부하가 많은 특정 서비스에 대해서만 확장 할 수 있어 확장성이 뛰어나다. (전체에 대한 모놀리틱 아키텍처에 반해 영향이 있는 컴포넌트만 확장을 하면된다.)

단점

• 참조에 의한 호출 (Call-by-Reference)이 아니고 네트워크 호출에 의한 전송이기 때문에 네트워크 데이터 처리, 시간 소요등이 늘어나게 되어 성능이 낮아질 수 있다.
• 서버의 수가 많아짐에 따라 CPU, Memoery 등 성능 관리의 효율적인 문제가 발생할 수 있다.
• 서비스들이 분리되어 있어 다른 서비스에 대한 의존성이나 종속성을 가진 특정 시나리오를 가지고 테스트를 하려고할 때 여러 서비스를 가지고 진행해야 하므로 테스트가 복잡해진다.
• 운영해야 할 시스템의 개수, 인력, 필요한 기술의 수 등도 같이 늘어나게 된다.
• RDBMDS를 사용하여 롤백 등의 처리를 할 경우 서비스 간 트랜잭션 처리가 힘들게 된다.

 

아키텍처 구조 비교

출처 : https://logiciel.io/monolithic-vs-microservices-architecture

 

결론

어느 것이 좋다는 흑백논리는 잘못된 것이다. 규모에 따라 운영 인력에 따라 아키텍처를 적절하게 선택하여 사용할 것이며 변행해서 사용할 필요가 있다. 어느 회사든 그렇듯이 소규모 프로젝트였다가 대규모 프로젝트로 발전하는 경우도 대다수이며 이런 경우를 대비하여 모놀리틱 아키텍처를 구상하더라도 언제든지 변형 가능하게끔 개발하여야 한다.