모놀리식 아키텍처 (Monolithic Architecture) vs 마이크로서비스 아키텍처 (MicroService Architecture)
# 모놀리식 아키텍처와 마이크로 서비스 아키텍처 비교
# 모놀리식 아키텍처 (Monolithic Architecture)
전통의 아키텍처를 지칭한다. 소프트웨어의 모든 구성요소가 한 프로젝트에 통합 되어 있는 형태.
모놀리식 아키텍처의 경우 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행된다. 따라서 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야 한다. 코드 베이스가 증가하게 되면 모놀리식 애플리케이션의 기능을 추가하거나 개선하기가 더 복잡해진다.
장점
- 소규모 프로젝트에서는 합리적이다.
- 개발, 빌드, 배포, 테스트가 용이하다.
단점
- 어플리케이션 구동시간이 늘어나고 빌드,배포 시간이 길어진다.
- 조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포를 해야한다.
- 많은 양의 코드가 몰려있어 유지보수가 힘들다.
- 일부분의 오류가 전체에 영향을 미친다.
- 기능별로 알맞는 기술, 언어, 프레임워크를 선택하기가 까다롭다.
- scale out이 불가능 하다.
# 마이크로서비스 아키텍처 (MicroService Architecture)
마이크로서비스 아키텍처는 하나의 큰 애플리케이션을 여러 개의 작은 서비스 유닛으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처를 말한다. 각 마이크로서비스는 상호 통신이 가능하며 이를 통해 전체 서비스를 구성한다. 애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행된다. 이러한 서비스는 경량 API를 사용하여 잘 정의된 인터페이스를 통해 통신한다. 서비스는 비즈니스 기능을 위해 구축되며 서비스마다 한 가지 기능을 수행한다. 서비스가 독립적으로 실행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있다.
장점
- 독립적인 서비스로 배포가 빠르고 모놀리식보다 가볍다.
- 서비스별 개별 배포 가능하여 배포 시 전체 서비스의 중단이 없다.
- 각 서비스에 따라 개별적으로 서버를 나눌 수 있어 메모리 및 cpu 관리에 효율적이다.
- 각 서비스가 모듈화 되어있고 모듈끼리 RPC, Message-driven 이용하여 통신하기 때문에 각 서비스의 개발 속도가 증가한다.
- 분리된 서비스로 개발할 수 있기 때문에 서비스마다 가장 적합한 기술을 선택 할 수 있다.
- 서버 및 프로스 장애 시, 격리 및 복구가 쉬워 장애가 전체 서비스로 확장될 가능성이 적다.
단점
- 각자 배포한 서비스에 대해 다른 서비스와 연계가 잘 되는지 확인해야 한다.
- 서비스 간 호출 시 REST API 사용으로 인한 통신비용, Latency(지연시간)가 증가한다.
- 서비스가 분산되어 있어 트랜잭션 관리, 장애 추적 및 테스트 등이 쉽지 않다.
- 서비스마다 DB가 분리되어 데이터의 조회가 어렵고 데이터의 중복이 발생한다.
- 전체 서비스가 커짐에 따라 복잡도가 기하급수적으로 늘어날 수 있다.