MSA | Microservices Architecture

이번 시간은 간략하게 MSA에 대해 알아보자.

다음 시간은 기본적인 구조를 파악할 것이다.



MSA란?

MSA의 명확한 정의는 사실 없지만, 비즈니스 기능, 배포자동화, 엔드포인트의 인텔리전스, 언어 및 데이터의 분산 제어를 중심으로 공통 특성을 가진 구조를 주로 MSA라 얘기한다.

간단히 말해서, MSA는 각각 자체 프로세스에서 실행되고 종종 HTTP 리소스 API인 경량 메커니즘과 통신하는 소규모 서비스 모음으로 단일 애플리케이션을 개발하는 방식이다.

각각의 서비스는 비즈니스 기능을 중심으로 구축되며 완전히 자동화된 배포 기계를 통해 독립적으로 배포할 수 있다.

다른 프로그래밍 언어로 작성되고 다른 데이터 저장 기술을 사용할 수 있으며 이러한 서비스들에 대한 최소한의 중앙 집중식 관리가 있다.

어떤 서비스는 Node.js로, 또 어떤 서비스는 자바로, 서비스별로 다른 언어, 그리고 각각 MySQL, MongoDB 등등 다른 DB를 가져도 된다는 얘기다.


기존 Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태여서 부분 장애가 전체 서비스의 장애로 확대될 수 있고 Scale-out이 어려우며 한 Framework와 언어에 종속적이었기 때문에 MSA가 등장한 것이다.

좀 더 자세히 알고싶다면 넷플릭스가 3일동안의 서비스 장애를 겪고 MSA를 도입하게된 사례를 참고하자.

국내엔 배달의 민족이 비슷한 이유로 MSA를 도입하게되었다.



이렇게 좋아보이는 MSA 스타일을 안 쓸 이유가 없어보이는가?

그렇지 않다.

사실 MSA는 기존 모놀리식 아키텍쳐에 비해 복잡해도 너무 복잡하다.

비용, 생산성, 유지보수, 운영 인프라 등을 충분히 고려해야한다.

ThoughtWorks의 수석 엔지니어이자 소프트웨어 시스템 디자인 패턴으로 유명한 마틴 파울러는 모놀리식으로 관리하기에 특별히 복잡한 시스템을 운영할 상황이 아니라면 MSA는 고려할 필요조차도 없다고 얘기했다.

MSA를 도입하고자 한다면 충분히 심사숙고하여 선택하길 바란다.

Thanks for watching, Have a nice day.