Monolithic vs. MSA
Contents
5.1. Monolithic vs. MSA¶
Flask를 배우다 보면 선배 개발자들이 “플라스크는 MSA라는 것은 알고 있지?”라는 말을 자주 해줍니다. 그런데 처음 웹 프레임워크를 배우는 학생들은 MSA라는 용어 자체가 생소한 경우가 많습니다.
MSA라는 말을 처음 들어보는 것도 멘붕인데 선배 개발자들이 이런 말까지 합니다. “Django는 Monolithic 아키텍처야. 그래서 Django와 Flask는 근본적으로 달라. 알지?”
이런말을 처음 접하게 된다면 적지 않게 당황하게 됩니다. 하지만 알고 보면 별로 복잡하지 않은 개념입니다. Flask를 배우는 김에 MSA와 Monolisic(모놀리식)의 개념에 대해 간단히 살펴보도록 하겠습니다.
Monolithic과 MSA에 대한 설명은 [MSA] Monolithic Architecture VS Micro Service Architecture 참조하여 재정리 하였으니 관심있는 독자는 해당 블로그를 방문하기 바랍니다.
5.1.1. Monolithic Architecture¶
**Monolithic(모놀리식)**을 네이버 영어사전에서 찾아보면 ‘(조직, 단결 등이) 단일체인, 한 덩어리로 뭉친’이라고 나옵니다. 사전적 의미 그대로 모놀리식 아키텍처는 어떤 서비스(또는 프로젝트)를 하나의 큰 덩어리로 된 어플리케이션(Application, 이하 앱)으로 만든다는 뜻입니다. 우리가 일반적으로 생각하는 방식과 비슷합니다.
Fig. 5.1 모놀리식 아키텍처 (이미지 출처: sangmin7476 )¶
모놀리식 아키텍처는 장단점이 존재합니다. 장점과 단점에 대해 간단히 알아보겠습니다.
장점
로컬 머신(예: 개인 컴퓨터)에서 편리하게 개발 \(\to\) 한 덩어리로 만들기 때문에 분산 개발 환경이 불필요합니다.
통합된 시나리오를 활용해서 전체 기능을 쉽게 테스트할 수 있습니다.
배포가 간단합니다(하나의 앱만 배포하면 끝)
단점
큰 덩어리로 되어 있기 때문에 유지보수(코드 수정 및 추가)가 어렵습니다.
필요에 따라 자원(CPU, Memory, Storage 등)을 적절히 분배하기 어렵습니다.
신속한 업데이트가 어렵습니다.
새로운 기술이 개발되었을 경우 적용하기 어렵습니다(유지보수가 어려운 것과 같은 이치)
부분적 장애가 발생해도 전체 시스템 작동이 안될 수 있습니다.
Scale out이 어렵습니다.
스케일 아웃(scale out)에 대한 설명
갑자기 이용자(접속자)가 늘어나면 서버를 몇 대 늘여서 서비스 능력을 높여줘야 합니다. 이렇게 서버를 증설하는 것을 scale out 한다고 말합니다. 앱이 기능별로 분리가 되어 있다면 증설이 쉽습니다. 청주대 온라인 강의 시스템에 학생들이 몰리면 온라인 강좌만 담당하는 서버만 추가하면 됩니다. 만약 청주대의 모든 시스템이 하나의 큰 덩어리로 코딩되어 있으면 scale out 하기 매우 어려워 집니다.
모놀리식 구조는 한 덩어리만 생각하면 되므로 단순합니다. 그래서 개발도, 테스트도, 배포도 편리합니다. 하지만 개발 규모가 커지면 이런 단순함이 독이 됩니다. 왜냐하면 모듈간 의존성이 높아지게 되고, 개발자들은 코드 이해가 어렵고, 하나의 프로젝트에 많은 개발자가 투입되어 의사소통도 어려워집니다. 그래서 대안으로 등장한 것이 MSA 입니다. 이제 MSA Architecture에 대해 간단히 살펴보도록 하겠습니다.
5.1.2. MSA Architecture¶
MSA는 ‘Micro Service Architecture’의 약어입니다. 단어 그대로 아주 작은 서비스를 위한 아키텍처라는 말입니다. 기술적(Technical)으로 말하면 하나의 큰 앱을 작은 앱으로 나누어 만드는 방법입니다. 우리가 직관적으로 생각하는 앱은 전체가 한 덩어리로 된 하나의 앱으로 만드는 것입니다.
Fig. 5.2 MSA 아키텍처 (이미지 출처: sangmin7476 )¶
물론 MSA도 장단점이 있습니다.
장점
빌드 및 테스트 시간이 줄어듭니다. 이미 만들어진 서비스는 다시 빌드하지 않고 새롭게 추가되거나 수정된 부분만 처리하기 때문에 시간을 아낄 수 있습니다.
서비스를 분리해서 개발하므로 유연하게 기술을 적용할 수 있습니다. 인증 기능은 django auth로 구현하고, 채팅 기능은 node를 이용해서 구현하는 예를 들 수 있습니다.
손쉽게 scale out 가능합니다.
서비스 사이에 결합도가 낮아져 유지보수가 편리하고 시스템을 안정적으로 운영할 수 있습니다.
단점
하나의 서비스가 다른 서비스를 호출할 경우 네트워크 통신이 추가적으로 발생하므로 속도가 느려질 수 있습니다.
서버를 나누고 각각의 서버가 담당하는 앱이 있기 때문에 서버간 데이터베이스 처리를 해야하는 경우 트랜잭션을 처리하는 알고리즘을 추가로 작성해야 합니다.
서버가 증가하기 때문에 로깅, 모니터링, 배포, 테스트, 데이터베이스 관리 등 추가적인 작업이 필요합니다.
5.1.3. 모놀리식과 MSA, 어떤 것이 좋은 건가요?¶
앞에서 살펴본 것과 마찬가지로 어떤 아키텍처든 장단점이 있기 마련입니다. 모놀리식과 MSA도 각각 장단점이 있습니다. 따라서 어떤 것이 좋은 아키텍처라고 콕 짚어서 말할 수 없습니다. MSA가 더 좋을 것 같지만 아직도 많은 서비스가 모놀리식 아키텍처를 적용하고 있는 것으로 알려져 있습니다.
아키텍처는 것은 다양한 개발 경험과 운영 노하우를 바탕으로 선택해야 합니다. 아키텍처를 선택하거나 새롭게 고안하는 것을 아키텍처 설계(Architecture Design)라고 합니다. 소프트웨어공학 측면에서 볼때 ‘상위 설계’에 해당합니다. 이런 아키텍처 설계를 담당하는 사람을 아키텍처 설계자 (Architecture Designer) 또는 소프트웨어 시스템 설계자 (Software System Designer)라고 부릅니다.