MSA란?
마이크로서비스 아키텍처에 대한 정확한 정의는 없다. 하지만 마이크로서비스란 작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크라고 할 수 있다. 마이크로서비스는 완전히 독립적으로 배포가 가능하고, 다른 기술 스택(개발 언어, 데이터베이스 등)이 사용 가능한 단일 사업 영역에 초점을 둔다.
MSA 등장배경
Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태이다. 웹 개발을 예로 들면 웹 프로그램을 개발하기 위해 모듈별로 개발을 하고, 개발이 완료된 웹 어플리케이션을 하나의 결과물로 패키징하여 배포되는 형태를 말한다.
- 부분 장애가 전체 서비스의 장애로 확대될 수 있다.
- 개발자의 잘못된 코드 배포 또는 갑작스런 트래픽 증가로 인해 성능에 문제가 생겼을 때, 서비스 전체의 장애로 확대될 수 있다.
- 부분적인 *Scale-out(여러 server로 나누어 일을 처리하는 방식)이 어렵다.
- Monolithic Architecture에서는 사용되지 않는 다른 모든 서비스가 Scale-out되어야 하기 때문에 부분 Scale-out이 어렵다.
- 서비스의 변경이 어렵고, 수정 시 장애의 영향도 파악이 힘들다.
- 여러 컴포넌트가 하나의 서비스에 강하게 결합되어 있기 때문에 수정에 대한 영향도 파악이 힘들다.
- 배포 시간이 오래 걸린다.
- 최근 어플리케이션 개발 방법은 CI/CD를 통한 개발부터 배포까지 빠르게 반영하는 추세이다. 그러나 규모가 커짐에 따라 작은 변경에도 높은 수준의 테스트 비용이 발생하기도 하며, 많은 사람이 하나의 시스템을 개발하여 배포하기 때문에 영향을 줄 수 밖에 없다.
- 한 Framework와 언어에 종속적이다.
- Spring framework를 사용할 경우, blockchain 연동 모듈을 추가할 때 node.js를 사용하는 것이 일반적이며 강세이다. 그러나 java를 이용하여 해당 모듈을 작성할 수 밖에 없다. 선정했던 framework가 Spring이기 때문이다.
이러한 Monolithic Architecture의 문제점들을 보완하기 위해 MSA가 등장하게 되었다.
MSA 특징
👉🏻 MSA는 API를 통해서만 상호작용할 수 있다. 즉, 마이크로 서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.
MSA 적용사례
2015년 배달의 민족은 루비라는 데이터베이스 하나만을 사용하고 있었다.
- 리뷰에 장애가 생기면서, 주문도 장애가 생겨버린다.
2016년부터 마이크로서비스 도전을 시작했다
2016년 첫 자바 마이크로서비스 등장
결제 서비스를 데이터베이스까지 완전하게 분리하고 결제에서 장애가 생겨도 전화로는 주문할수 있드록 서비스하였다.
주문 중계 서비스는 가볍게 노드js를 사용하여 구현하였다.
- 차후에는 거대해져 spring으로 변경
탈루비
2019년에는 각 서비스를 다 MSA로 구현
배달의 민족은 장애에 아주 민감한 서비스라 MSA적용에 아주 적합한 서비스였다.
장애가 생기면 손님, 가게사장, 고객응대직원 등 많은 사람들에게 불편함을 주는 서비스
비용, 복잡도가 늘어도 장애를 줄이는게 중요했다.
MSA의 장단점
아직까지 MSA는 복잡도, 비용도 늘어난다. 무조건적으로 MSA를 도입할게 아니라 ROI(Return On Investment)를 잘 따져보고 도입하는것을 신중하게 도입해야된다.
하지만 MSA를 도입해보는것은 항상 생각해볼만하다. 특정한 서비스에서는 정말 좋은 서비스지만 앞서 살펴봤듯이 무조건적으로 좋은 Architecture는 아니다
