📌 MSA
하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처
[ 마이크로서비스 ]
- small Services, each running in its own process (스스로 돌아갈 수 있는 작은 서비스)
- independently deployable(독립적 배포 가능)
📌 MSA 등장배경
Monolithic Architecture?
-- 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어있는 형태
많은 소프트웨어가 Monolithic형태로 구현되어있고 소규모 프로젝트에는 Monolithic Architecture가 훨씬 합리적이다.
하지만 일정 규모 이상의 프로젝트에서는 한계가 드러난다.
- 서비스/프로젝트가 커질수록 영향도 파악 및 전체 시스템 구조 파악에 어려움
- 빌드 시간 및 테스트 시간, 배포시간이 기하급수적으로 늘어남
- 서비스를 부분적으로 scale-out하기가 힘듬
- 부분의 장애가 전체 서비스의 장애로 이어지는 경우가 발생함
이러한 문제점들을 보완하기 위해서 MSA가 등장하게 되었다.
기존의 특정한 물리적인 서버에 서비스를 올리던 on-promise서버 기반의 Monolithic Architecture에서 이제는 클라우드 환경을 이용하여 서버를 구성하는 MicroService Architecture로 많은 서비스들이 전환되고 있다.
📌 MSA 장점
-
각 서비스가 모듈화 되어있으며 모듈끼리 RPC 또는 message-driven API등을 이용해서 통신함
👉 각 서비스의 개발속도 증가 -
각 서비스에 따라 개별적으로 서버를 나눌 수 있어(scale-out)메모리 및 cpu관리에 효율적임
-
서비스별로 독립적 배포가 가능해서 배포가 빠르고 모놀리식보다 가벼움
-
팀단위로 적절한 수준에서 기술 스택을 다르게 가져갈 수 있으며 유지보수가 쉬움
📌 MSA 단점
-
전체 서비스가 커짐에 따라 그 복잡도가 기하급수적으로 늘어남
-
성능
- 서비스 간 호출 시 API를 사용하기 때문에 통신비용이나 지연시간이 그만큼 늘어나게됨
-
테스트 / 트랜잭션
- 서비스가 분산되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가, 많은 자원을 필요로함
- 통신의 장애와 서버의 부하등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야함 -
데이터관리
- 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기 어렵고 데이터 정합성 또한 관리하기 어려움
🔎 참조
