MSA 란 무엇인가?

MSA에 대해 알아보기 전 먼저 Monolithic이 무엇인지 알아보자.

Monolithic Architecture란 사전적 정의로 한 덩어리의 구조이다. 즉 전체 애플리케이션이 하나로 구성된다.

하지만 근래의 IT업계와 같이 시스템이 점점 커지고 여러 컴포넌트 및 기능들이 추가되면서 문제가 발생한다.

빌드 및 테스트 시간이 길어진다.
→ 하나의 덩어리 구조이기에 사소한 이슈에 대하여 작은 수정이 일어나도 전체 시스템을 빌드해야 하고, 또한 테스트 시간도 길어진다.
선택적 확장이 불가능하다.
→ 예를 들어 특수한 경우(이벤트(진짜 이벤트) 혹은 서비스 접속량이 폭주할 경우) 프로젝트 시스템 전체를 확장해야 한다.
하나의 서비스가 모든 서비스에 영향을 준다.
→ 순간적으로 트래픽이 몰리게 될 때 해당 서버가 죽게된다면 하나의 덩어리이기에 다른 모든 서비스에도 영향을 준다.
Framework와 사용 언어에 종속적이다

이와 같은 Monolithic Architecture의 단점 때문에 최근 시스템이 커지는 IT업계에서는 MSA(Micro Service Architecture) 를 도입.

MSA는 Micro Service Architecture의 줄임말로 단일 프로그램을 각 컴포넌트 별로 나누어 작은 서비스의 조합으로 구축하는 방법이다.

MSA의 특징을 말하기 전 단일 프로그램을 컴포넌트 별로 나누었을 때 장점과 단점에 대해 알아보자.

각각의 서비스가 모듈화
모듈끼리는 RPC 혹은 message-driven API등을 이용해 통신하며, 이를 통해 개별 서비스의 개발과 유지보수면에서 이점을 가질 수 있다.
각 모듈별 기술 스택의 다양화
모듈 단위로 적절한 기술스택 채택이 가능하게 된다.
서비스 별 독립적 배포가능
지속적인 배포를 Monolithic에 비해 가볍게 할 수 있다.(Agile)
각각의 서비스별 부하에 따라서 개별적 scale-out이 가능한다.
메모리 혹은 CPU면에서 이점을 가질 수 있다.

여기서 scale-out이란 기존 서버를 여러 서버로 나우어 일을 처리하는 방식을 뜻한다.

복잡성
MSA는 Monolithic과 비교하였을 때 상대적으로 시스템이 복잡하다. 서비스가 모두 분산되어있기에 내부 시스템의 모듈간 통신을 어떻게 연결할지 정해야하고, 통신의 장애와 서버의 부하에 있어 어떻게 transaction을 유지할지 결정하고 구현해야한다.
Transaction 유지의 어려움
Monolithic 에서는 단일 transaction을 유지하면 됐지만, MSA에서는 각각의 서비스 별로 DB를 가지고 있기때문이다.

트랜잭션이란, 데이터베이스의 상태를 변화시키기 위해 수행하는 작업의 단위를 말한다.

MSA는 API를 통해서 상호작용한다. MSA 내부 각 서비스의 end-point(접근점)을 API형태로 외부에 노출하고, 세부적인 기술적인 사항들은 모두 추상화를 한다.

MSA의 궁극적인 목표는 보다 빠르고 안전하게 고품질의 애플리케이션 개발을 돕고, 분리된 서비스를 통해 각 서비스는 다른 시스템들에 미치는 영향을 최소화 하면서 신속하게 반복하는 것이다.

몇가지 참고 키워드 : REST, Kafka, Message Stream

내 블로그 - 관리자 홈 전환	`Q` `Q`
새 글 쓰기	`W` `W`

글 수정 (권한 있는 경우)	`E` `E`
댓글 영역으로 이동	`C` `C`

티스토리툴바