목표
모놀리식 아키텍처(Monolithic Architecture)에 대해서 배워 봅시다.
모놀리식 아키텍처(Monolithic Architecture)
모놀리식 아키텍처란, 마이크로서비스의 각광에 따라 마이크로서비스가 아닌 전통의 아키텍처를 지칭하는 의미로 생겨난 단어이다. 위의 그림에서 처럼 모든 모듈은 서비스 내부의 Product 형태로 종속되어 있으며, 서비스에만 집중할 수 있는 구조로 되어 있다.
이는 Monolithic 이라는 단어의 뜻 그대로 하나의 Massive 한 Context 형태의 아키텍처를 의미하며, 하나의 서비스 또는 어플리케이션이 하나의 거대한 아키텍처를 가질 때, Monolithic 하다고 한다.
특징
모놀리식 아키텍처를 갖는 Software의 특징은 그 자체로 강건하며 내부 요소간의 Dependency 를 크게 가질 수 있다는 점이다. 그리고 이는 필연적으로 구조적인 Coupling 이 강력하게 유지되는 결과를 초래한다.
또한 각 비즈니스 컴포넌트들이 하나의 강한 결합 구조를 지니며 통일성이 있다. 이는 비즈니스 로직이 서비스에 최적화된 코드를 만들어내는데 좀 더 집중할 수 있는 반면 복합적인 예외를 만들 수 있는 위험성을 내포하게 된다.
맥락(Context)
서버 사이드 기업용 애플리케이션 개발을 하고 있다고 해보자. 데스크탑 브라우저와 모바일 브라우저, 그리고 네이티브 모바일 애플리케이션을 포함해 여러 가지 다양한 클라이언트 지원해야만 한다. 또한, 애플리케이션은 3rd 파티가 사용할 수 있도록 API를 노출해야 할 수도 있다. 또한 웹서비스나 메시지 브로커를 통해서 다른 애플리케이션 서비스와 통합해야 할 수도 있다. 애플리케이션은 비즈니스 로직을 실행하고, 데이터베이스에 접근하며, 다른 시스템들과 메시지를 주고받아 HTML/JSON/XML 응답을 돌려주는 것으로 요청(HTTP 요청과 메시지)을 처리한다.
애플리케이션은 계층형 아키텍처나 6방형(hexagonal) 아키텍처를 갖거나 다양한 유형의 컴포넌트로 구성되어 있다.
프리젠테이션 컴포넌트(Presentation Component)- HTTP 요청을 제어해서 HTML이나 JSON/XML(웹서비스 API들로써)로 응답을 보내는 책임
비즈니스 로직(Business Logic)- 애플리케이션의 비즈니스 로직
데이터베이스 접근 로직(DataBase Access Logic)- 데이터베이스에 접근해서 데이터 접근 객체 만드는 책임
애플리케이션 통합 로직(Application Integration Logic)- 메시지 처리 레이어를 말하며, Spring Integration을 기반으로 하는 걸 예로 들 수 있음
이들은 애플리케이션의 다양한 기능적인 측면에 상응하는 논리적인 컴포넌트이다.
장점과 단점
개발 초기에는 단순한 아키텍처 구조와 개발의 용이함이 큰 장점이지만 규모가 커짐에 따라 복잡도가 심각하게 증가한다.
가령 토이 프로젝트를 한다고 생각해보자. 생각이 흐르는대로 Prototyping 을 할 때는 구조가 복잡하고 Dependency 가 크더라도 손쉽게 만들 수 있으며 오히려 모듈별로 분리하고 나누는 것은 코드의 최적화 및 구현에 방해가 되는 경우가 많다.
그러나 프로토 타이핑 이후에 새로운 컨텐츠를 추가하거나 새로운 팀원이 생겼을 때 문제는 시작된다. 이 거대한 구조가 본인에게는 간단하고 쉬울 수 있으나 새로운 팀원에게는 가혹하게 느껴질 것이다.
또한 최근 클라우드 환경이 각광받으면서 두드러지게된 단점으로 하나의 모듈을 수정하기 위해서는 전체 어플리케이션의 배포가 수반되며 서버 기동, 빌드 및 배포 시간이 오래걸린다는 점이 있다.
마이크로 서비스 아키텍처 관련 포스팅에서 한번 더 언급을 하겠으나, 일반적으로 마이크로서비스 아키텍처의 Scalability 복잡도가 N+M 이라면 모놀리식 아키텍처의 복잡도는 N*M 형태로 증가하기 때문에 컨테이너의 과부하와 배포 및 스케일링의 어려움을 겪게 된다.
또한 기술 스택의 선택폭이 좁아지며 많은 문제를 해결하기 위해 보다 강력하고 탄탄한 기술력이 요구된다. 이는 내부 구성요소들 간의 강력한 Dependency 문제 때문이다. 한 모듈의 선택은 다른 외부 모듈에서 버그를 초래할 수 있다. 따라서 사용하고자 하는 프로젝트의 큰 그림이 아키텍처 구성 단계에서 그려져 있어야 문제를 최소화할 수 있다.
최근에는 많은 서비스들이 초창기에 모놀리식으로 개발되고 향후 마이크로서비스 아키텍처로 구조를 변경한다. 혹은 인프라가 잘 갖추어진 회사에서라면 여러분을 도와줄 많은 플랫폼들이 이미 마이크로서비스 아키텍처로 존재할 것이다.
近期评论