💡 서비스의 규모가 확장되고, 데이터 저장 및 통신을 클라우드를 통해 하는 요즘, 기존의 방식인 모놀리식과 대비되는 MSA가 대두되고 있습니다. 이번 시간엔 MSA와 모놀리식에 대해 알아보고 차이점을 짚어보도록 하겠습니다. 👏🏻
0. 모놀리식 서비스 아키텍처
What is MA?
MA : Monolithic Architecture ( 모놀리식이 ‘모놀리'식이 아니라 놀람 😅 )
Monolithic : 단단히 짜여 하나로 되어 있는
어플리케이션은 하나의 아키텍처로 구성되어 있기에, 대부분의 기업용 어플리케이션은 하나의 아키텍처를 두는 모놀리식으로 개발되었다.
모놀리식 아키텍처는 개발과 관리가 용이하다는 장점이 있으나, 시스템이 복잡해지고 커질수록 코드를 이해하기가 어려워지고 그럴수록 유지보수하기 어려워진다. 또한 작은 버그를 수정하더라도 전체를 다시 빌드 & 배포해야된다는 점에서 서비스의 크기와 비례하여 시스템이 무거워진다.
This is MA
아래 그림을 보게 되면 여러 비즈니스 로직들을 담은 시스템은 하나의 DB와 하나의 애플리케이션과 상호작용한다.
What is the Advantage at MA?
하나의 시스템이 모든 비즈니스 로직을 담고 있다는 것은 나름 장점들이 있다.
1️⃣ 첫째, 모든 기능들이 하나의 시스템에서 동작하므로 서버 환경, DB 환경이 하나이기에 환경 세팅에 시간 소요가 상대적으로 적고, 환경을 고려한 개발이 쉽다.
2️⃣ 둘째, 모든 기능들이 하나의 시트템에서 동작하므로, 모든 기능들에 대한 테스트(End to End)를 하기 쉽다.
What is Problem at MA?
하나의 시스템에서 모든 것을 관리하는 것은 단순하게 생각하면 간편하다고 생각할 수 있다. 하지만 앞서 말한 것처럼 기능이 무수히 추가되면서 시스템의 규모가 늘어나면 다양한 문제 발생 가능성이 높아진다.
1️⃣ 첫째, 기능이 많아진다는 것은 하나의 프로젝트에 코드들이 무수히 많아진다는 것을 의미한다. 코드가 많아지면 코드를 이해하고 해석하고 개발하는데 시간이 오래걸리는 것을 의미한다. 이는 유지보수가 어려워진다고 할 수 있다.
2️⃣ 둘째, 하나의 시스템에 모든 기능이 담겨있다면 기능 하나가 수정되면 전체를 다시 빌드하고 배포해야 한다. 만약 시스템의 크기가 크다면 빌드 및 배포 시간이 늘어난다는 것을 의미한다. 이는 버그나 수정사항의 즉시 적용이 어렵다는 점을 내포한다.
3️⃣ 셋째, 만약 특정 기능에 오류가 발생했다고 가정해보자. 해당 오류로 시스템이 죽으면 전체가 시스템이 먹통이 된다. 이는 작은 요소가 전체에 영향을 미치는 것을 내포하는데, 트래픽이 급증하게 되면 전체 시스템에 영향을 미치는 것까지 생각할 수 있다.
4️⃣ 넷째, 다양한 기능들은 그 종류에 따라 다양한 언어와 프레임워크를 선택하여 개발할 수 있다. 하지만 MA일 경우, 하나의 시스템으로 구성되기 때문에 기능별로 알맞은 언어 및 프레임워크를 선택하기 어렵다.
1. 마이크로서비스 아키텍처
What is MSA?
MSA : MicroService Archtecture
서비스가 커지면 커질수록 시스템이 무거워지는 모놀리식의 단점을 해결하기 위해, 여러 모듈(경량화되고 독립적인 서비스)을 조합하여 애플리케이션을 구현하는 방식으로 모듈마다 자체 DB를 가지고 있기 때문에, 개발부터 배포까지 효율적으로 수행할 수 있다. 하지만 독립적이고 확장성을 고려한 설계가 어려운 점과, 모듈이 나눠져 있어 트랜잭션 처리 등이 어렵다는 단점이 있다.
This is MSA
아래 그림을 보게 되면 여러 비즈니스 로직은 기능(모듈)별 각자의 DB 환경을 공유하고, 모듈별로 애플리케이션과 독립적으로 통신하는 것을 확인할 수 있다.
What is the Advantage at MSA?
모놀리식 방법의 단점을 극복하고자 등장한 것이 바로 MSA이다. 각각의 기능들이 서로 독립적인 시스템으로 구성되어 있기 때문에 여러 장점들이 있다.
1️⃣ 첫째, 서비스별 시스템이 독립적으로 구성되어 있어, 그만큼 하나의 기능을 개발할 때 봐야할 코드의 수도 적으며, 이해하기 쉽다. 즉 적고 작은 만큼 유지보수하기 쉽다.
2️⃣ 둘째, 서비스가 독립적으로 나눠져 있어, 하나의 서비스에 문제는 하나의 서비스만 수정하여 빌드 및 배포하면 되므로 상대적으로 빌드 및 배포가 빠르다.
3️⃣ 셋째, 각 기능에 맞는 언어와 프레임워크를 선택할 수 있다.
What is Problem at MSA?
독립적으로 기능별 서비스가 나뉘어져 있는 MSA. 나뉘어진 만큼 되려 관리가 힘들 수 있다. MSA를 채택하여 애플리케이션을 구성하면 어떤 단점이 있을까?
1️⃣ 첫째, 위에서 말한 것처럼 여러 모듈들이 분산되어 있어 관리 및 모니터링이 힘들다.
2️⃣ 둘째,시스템이 커질수록 각각의 서비스가 독립적인 서비스이긴 힘들다. 즉, A 서비스가 B 서비스의 코드를 호출할 수 있는데 이 부분은 모놀리식과 비교하였을 때 어렵다.
→ 모놀리식일 경운 단순히 같은 시스템 내부에서의 method 호출,
→ but, MSA 일 경우, http 통신 등을 통해 호출해야 한다.
3️⃣ 셋째,모듈별로 애플리케이션과 통신하므로 다양한 통신에서 발생하는 오류가 상대적으로 잦다.
4️⃣ 넷째,하나의 시스템의 동작을 모두 확인하는 통합 테스트를 End-to-End로 진행하기 위해선 각각의 마이크로 모듈들과 UI, Gateway를 구동시켜야 한다. 즉, 상대적으로 통합테스트 하기 어렵다.
👇🏻 글을 마치며
서비스의 확장 가능성을 고려하여 모놀리식 아키텍처와 마이크로서비스 아키텍처를 적절하게 선택하는 것이 중요하다.
만약 서비스의 확장 가능성이 낮거나 시스템이 크지 않다면 모놀리식 아키텍처를 사용하고,
서비스의 확장 가능성이 높거나 시스템이 크다면 마이크로서비스 아키텍처를 사용하는 것이 나을 것이다.
개인적으론
- 정체된 서비스보다 다양한 니즈에 맞게 변화되어지는 서비스가 실제로 더 많고 서비스의 존재 가치가 더 높다.
- 클라우드 컴퓨팅의 발전으로 서버 환경을 구축하기 쉬워졌다.
라고 생각하기 때문에, 개발자로서 마이크로서비스 아키텍처는 필수적으로 갖춰야 하는 역량이라고 생각한다.
참고문서
[MSA] Monolithic Architecture VS Micro Service Architecture
