등장 배경
어플리케이션의 크기가 점차 커지면서, 기존의 모놀리틱한 아키텍처의 단점이 드러나기 시작했다.
- 어플리케이션의 크기가 커질수록 영향도 파악 및 전체 시스템 구조의 파악에 어려움
- 빌드 시간 및 테스트시간, 배포시간의 증가
- 서비스를 유연한 스케일 아웃이 어려움
- 장애의 전파
여러 개의 작은 서비스로 나누어 변경이 용이하도록 하기위해 MSA가 등장했다고 볼 수 있다.
MSA 정의
마틴 파울러의 MSA 정의 “the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.”
핵심은 각 서비스가 스스로 돌아갈 수 있고 서로 가벼운 메커니즘에 의해 통신이 가능해야 하며, 개별적 배포가 가능해야 한다는 것이다.
여기서 지난 번 사내서비스 개발기에서 언급했던 Gradle 멀티모듈 프로젝트 만들기와 핵심이 일맥상통하는 것 같다. 즉, 가볍고 독립적인 모듈 또는 서비스 여러 개로 분리하여 하나의 어플리케이션을 구성하되 지나친 의존성은 배제해야 한다는 것이다. (common 모듈의 저주)
장점
- 서비스 별 개별 배포 가능 ( 배포 시 전체 서비스의 중단이 없음)
- 요구사항을 신속하게 반영하여 빠르게 배포할 수 있음.
- 특정 서비스에 대한 확장성이 용이함.
- 장애가 전체 서비스로 확장될 가능성이 적음
- 부분적 장애에 대한 격리가 수월함
단점
- 서비스 간 호출 시 API를 사용하기 때문에, 통신 비용이나, Latency가 증가
- 테스트와 트랜잭션의 복잡도가 증가하고, 많은 자원을 필요로 함
- 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어려움