모놀리식 아키텍처(MA) vs 마이크로서비스 아키텍처(MSA)

모놀리식 아키텍처(Monolithic Architecture, MA)

---

개념

하나의 통합된 코드 베이스로 여러 비즈니스 기능을 수행하는 전통적인 소프트웨어 개발 모델

단일 애플리케이션 내에 서비스의 모든 로직이 통으로 들어가 있다. (like 맥가이버 칼)

 

장점 👍🏻

• 간결하다.
• 중앙 집중된 구조이기 때문에 분산된 애플리케이션에 비해 엔드 투 엔드 테스트 를 더 빠르게 수행할 수 있다.
• 단일 애플리케이션에 비즈니스 로직, UI, 콘텐츠 등 모든 구성 요소를 이루는 코드가 들어있기 때문에 디버깅하기 간편하다. 
• 소규모 애플리케이션이라면 단순하면서 견고한 구조를 만들기 좋다.

*엔드 투 엔드 테스트(End-to-End, E2E) : 사용자 관점에서 애플리케이션의 흐름을 처음부터 끝까지 테스트하는 것

단점 👎🏻

• 단일 애플리케이션이 커지면 구동부터 빌드, 배포에 드는 시간이 오래걸린다.
• 특정 컴포넌트나 모듈에서 문제가 생기면 전체 서비스에 악영향을 미칠 수 있다.
• 작은 부분만 수정하더라도 전체 애플리케이션을 통째로 컴파일해서 배포해야 한다 -> 배포가 잦은 환경에서 번거롭다. 
• 기능별로 알맞은 기술이나 언어, 프레임워크를 따로 선택하기 까다롭다. 

---

마이크로서비스 아키텍처(MicroService Architecture, MSA)

---

넷플릭스(Netflix)의 아키텍처를 도식화한  그림

개념

서비스를 아주 작은 서비스(Microservice) 단위로 나눠 각 서비스에서 독립적으로 서비스를 구성하는 모델

중앙 집중적인 관리 체계 대신 경량화된 API나 메시지로 직접 통신하며 접근하는 방식 

 

장점 👍🏻

• 서비스를 잘게 쪼개면서 개발 구조가 민첩하고 유연해졌다.
• 각 서비스를 독립적으로 개발하고 배포할 수 있어 작업 시간이 단축되고 확장성이 높아졌다.  
• 배포가 빠르고 잦아 애자일 작업 방식을 취하기 편하다.
• 한 서비스가 다운되더라도 다른 서비스는 문제없이 작동할 수 있다. 
• 서비스에 적합한 언어나 프레임워크 등 기술을 독립적으로 선택할 수 있다.
• 자체 DB를 서비스마다 가지고 있어 데이터 무결성을 유지하기 좋다.

단점 👎🏻

• 분산된 서비스가 서로 API를 호출하는 과정에서 통신 비용과 지연 시간이 들어 큰 인프라 비용이 발생할 수 있다. 
• 장애 추적, 디버깅, E2E 테스트가 어렵다.
• DB가 분리되며 데이터를 조회하기 어렵고 DB 간 데이터 중복이 발생할 수 있다.
• 서비스가 커지는 만큼 복잡해져서 적절히 관리하지 않으면 개발 속도나 운영 성능이 나빠진다.

---

언제 어떤 아키텍처를 써야 할까?

모놀리식	MSA
기술적 복잡도가 높은 대규모 프로젝트 다양한 기술 스택을 사용하고, 여러 비즈니스별 요구사항이 명확한 경우 장애를 줄이고 시스템 전체의 가용성과 탄력성을 높여야 할 때	기술적 복잡도가 낮은 소규모 프로젝트 MVP 수준의 단일 비즈니스 또는 신설 도메인 등 시장 진입을 위해 빠르고 간편하게 기능 개발 및 배포를 수행해야 할 때
	ex. 네이버의 메일 + 계정

실제 기업들의 아키텍처 전환기

MA to MSA

• 오늘의 집

오늘의집 MSA Phase 1. 전환전략 - 오늘의집 블로그

• 쿠팡

마이크로서비스 아키텍처로의 전환

MA

• StackOverFlow

https://blog.insane.pe.kr/1587

MSA가 정답은 아니다? : Stackoverflow의 사례

 

 

참고

https://www.inflearn.com/pages/infcon-2023-tech-msa

[INFCON Tech Series #5] 모놀리식 vs 마이크로서비스 아키텍처, 우리 팀에 맞는 선택은? - 인프런 | 스토

너무너무 잘 설명이 되어있다! 👍🏻