모놀리식 아키텍처 Monolithic Architecture(MA)
정의
모놀리식 애플리케이션은 한 개의 서비스 안에서 개별 컴포넌트가 모두 결합되어 하나의 큰 모듈로 존재하는 전통적인 아키텍처 스타일이다.
모든 서비스들(검색, 뉴스, 게임, 쇼핑 서비스)이 하나의 모듈 (SpringBoot의 경우 jar파일) 안에 들어 있다. 서비스들은 완전히 다른 기능들임에도 불구하고 밀접하게 결합되어 있으며, 동일한 Database를 사용한다.
장점
- 개발의 단순성 : 애플리케이션을 구축하는 표준적인 방법이기 때문에 추가적인 지식이나 설정이 요구되지 않는다. 모든 소스코드는 한 곳에 있다.
- 디버깅 단순성 : 모든 소스코드가 한 곳에 있기 때문에 디버깅 프로세스가 간단하다. 요청의 흐름을 쉽게 따라가고 문제를 찾을 수 있다.
- 테스트 단순성 : 종속성 없이 한 개의 서비스만을 테스트 할 수 있다.
- 배포의 단순성 : jar 파일 하나만 교체하면 되기 때문에 쉽게 배포할 수 있다. UI가 백엔드 코드와 함께 패키징 되는 경우에는 중단 변경사항 또한 없다.
- 공통 서비스 : 공통의 관심사는 한번만 처리된다.
예 보안, 로깅, 예외처리, 모니터링, Tomcat 매개변수 선택 및 설정, 데이터 소스 연결 풀 설정 등 - 초기 구축에서 비용 저렴 : 모든 소스코드는 한 곳에 위치하고 단일 배포단위로 패키징 되어 배포되기 대문에 인프라 개발비용에 오버헤드가 없다. 따라서 일반적으로 어플리케이션 개발 초기에 많이 사용되는 방식이다.
단점
모놀리식 아키텍처의 단점은 애플리케이션이 성공하면서 규모가 커질 때 더 드러나게 된다.
-
개발 속도 저하 : CI/CD 파이프라인 있는 모놀리식 애플리케이션을 상상해보자. 이 모놀리식 애플리케이션의 서비스는 각 풀 리퀘스트에 대해 실행되는 테스트가 포함되어 있다. 소스코드의 작은 변경사항일지라도 파이프라인이 성공할 때 까지 많은 시간(예를 들어 1시간) 을 기다려야 한다. 만약 실패한다면 다시 기다려야 한다. 동료가 변경사항을 병합한다면 리베이스/Merge 후 다시 기다려야 한다.
-
높은 코드 결합 : 특히 새로운 팀원에게는 시스템이 이해하기 어려워 진다.
-
코드 소유권 불명확 : 시스템이 성장하면서 서비스 별로 각각 팀이 생기게 되었다. Flight Service를 작업하는 팀이 생기고, Billing Service를 담당하는 팀이 생겼다. 그러나 이 서비스들 간에는 경계가 없기 때문에 한 팀이 다른 팀의 코드에 영향을 미칠 수 있게 된다.
-
데이터베이스 성능 문제 : 모든 서비스에 대해 단일 데이터베이스가 사용되기 때문에 성능의 문제가 발생할 수 있다.
-
배포 문제 : 아무리 작은 변경이여도 전체의 모놀리식 앱을 다시 배포해야 한다.
-
레거시 기술의 문제 : Java8로 작성되어 있는 애플리케이션이라고 가정했을대, Java11로 마이그레이션한다고 하면 얼마나 걸릴지 상상해 보자. 이 애플리케이션은 마이그레이션 되지 않을 수도 있다.
진화하기 ➡️ Micro Service Architecture
모놀리식 아키텍처는 빠른 개발. 테스트 및 디버깅의 단순성, 초기 구축 비용 등의 이점 때문에 소규모 애플리케이션에 적합하다. 하지만 애플리케이션의 성공으로 시스템이 성장하게 되면 비즈니스의 장애물이 될 수 있으며 다른 형태로 진화해야 한다.
이 경우 MSA(Micro Service Architecture)가 그 방향이 될 수 있다.
출처
https://datamify.medium.com/monolithic-architecture-advantages-and-disadvantages-e71a603eec89
