MSA란
Micro Service Archiecture 의 약자로 정확한 정의는 없다. 다만 개념 자체는 마이크로 단위로 나누어진 작고, 독립적으로 배포가 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크라고 볼 수 있다.
등장 배경
MSA와 대비되는 아키텍쳐로는 모놀리식 아키텍쳐(Monolithic Archiecture)가 있다. 이 모놀리식 아키텍쳐는 모든 소프트웨어의 구성요소가 하나로 합쳐져있는 형태로 웹 화면과 데이터베이스 흐름까지 모두 하나로 되어있는 아키텍쳐를 말한다.
이러한 모놀리식 아키텍쳐의 문제점은 부분 서비스 장애가 전체 서비스 장애로 이어질 수 있다는 점이다. 부분적인 서비스 변경도 어렵고 수정도 어렵다. 또한 여러 서비스가 하나로 통합되어 있는 형태인 만큼 서비스의 규모가 커지면 그만큼 빌드 배포 시간도 길어지게 된다.
이러한 문제들을 해결하고자 Micro Service Architecture가 나오게 되었다.
특징
큰 특징 중 하나는 API를 통해 모든 구성요소가 상호 작용을 한다는 것이다. 마이크로 서비스는 end-point(진입점)을 API형태로 외부에 제공하며 내부 구현 로직, 아키텍쳐와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.
SOA(Service Oriented Archiecture)와 매우 흡사하며 공통점을 가진다.
제대로 설계된 마이크로 서비스 아키텍쳐는 하나의 비지니스 범위에 맞춰 설계되므로 하나의 기능만 수행된다. 즉 자기일만 처리할 수 있으며 여러 애플리케이션에서 재사용할 수 있어야 한다. 어플리케이션은 기술 중립적 프로토콜을 사용해서 통신하므로 서비스 구현 기술과는 무관하다. 따라서 여러 언어로 이루어진 애플리케이션을 구축할 수 있다.
장점
각각의 서비스는 모듈화가 되어있으며 RPC나 Message Driven API 등을 이용하여 통신한다.
각 서비스를 독립적으로 개발 및 배포할 수 있으며 유지보수도 쉽게 할 수 있다.
서비스 부하에따라 각각의 애플리케이션을 scale-out하는 것이 가능하다.
단점
모놀리식 구조에 비해 상대적으로 복잡하다.
모든 서비스가 분산되어 있기 때문에 내부 시스템의 통신을 어떻게 가져가야 할지 표준 정의가 되어 있어야 한다.
통신 장애나 서버 부하가 일어날시 transaction을 어떻게 유지하고 결정하고 구현해야 한다.
통합 테스트가 어렵다.
서비스 하나를 배포하면 다른 서비스들과 연계가 제대로 이루어지는지 확인해야 한다.