What is MSA

MSA(MicroService Architecture)

---

MSA의 정의

마이크로서비스 아키텍처에 대한 정확한 정의는 없지만, 다음 특징을 갖는 서비스들의 조합으로 이뤄진 설계이다.

• 유지보수에 유리하고, 테스트 가능해야 함
• 느슨하게 결합되어야 함
• 독립적으로 배포 가능함
• 비즈니스 역량을 중심으로 구성해야 함
• 작은 팀에 의해 소유됨

마이크로서비스 아키텍처를 통해 팀은 대규모의 복잡한 애플리케이션을 신속하고 자주, 안정적이며 지속 가능하게 제공할 수 있다.

---

MSA의 등장배경

MSA의 등장을 살펴보기 위해선 기존에 어떠한 방식으로 개발이 진행되었는지에 대해 살펴봐야한다.

Monolithic Architecture

• 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어있는 형태

예를 들어, 웹 프로그램을 개발하기 위해 모듈별로 개발을 하고, 개발이 완료된 웹 애플리케이션을 하나의 결과물로 패키징하여 배포하는 형태이다.

이런 애플리케이션을 모놀리식 애플리케이션이라 하고, 주로 소규모 프로젝트에서 사용된다.

 

장점

아직까지 많은 소프트웨어가 모놀리식 형태로 구현되어 있고, 소규모 프로젝트에는 모놀리식 아키텍처가 합리적이다.

• 모놀리식 아키텍처의 가장 큰 장점은 심플함이다.
• 개발, 빌드, 배포, 테스트가 용이하며 빌드된 결과물을 WAS 같은 곳에 올리기만 하면 된다.

단점

하지만 일정 규모 이상의 서비스, 혹은 수백명의 개발자가 투입되는 프로젝트에서 모놀리식 아키텍처는 뚜렷한 한계를 보인다.

• 서비스/프로젝트 규모가 커질수록 영향도 파악 및 전체 시스템 구조 파악에 어려움이 있다.
• 빌드 시간 및 테스트시간, 배포 시간이 기하급수적으로 늘어나게 된다.
• 서비스를 부분적으로 scale-out하기가 힘들다.
• 하나의 모듈 장애가 전체 서비스의 장애로 이어지는 경우가 발생하게 된다.

MicroService Architecture

Martin Folwer는 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."

참조: https://martinfowler.com/articles/microservices.html

• 각각의 서비스는 그 크기가 작을 뿐, 서비스 자체는 하나의 모놀리틱 아키텍처와 유사한 구조를 가짐

각각의 서비스는 독립적으로 배포가 가능해야 하고, 다른 서비스에 대한 의존성이 최소화 되어야 한다.

또한, 서비스는 개별 프로세로 구동되며 REST와 같은 가벼운 방식으로 통신되어야 한다.

 

장점

MSA는 서비스 혹은 프로젝트의 규모가 커지며 생겼던 모놀리틱 아키텍처의 문제점들을 보완해 줄 수 있다.

• 복잡성의 문제 해결
  • 각각의 서비스는 모듈화가 되어있고, 모듈끼리 RPC 또는 message-driven API등을 이용하여 통신한다.
    이러한 MSA는 각각 개별의 서비스 개발을 빠르게 하며, 유지보수가 용이하도록 해준다.
• 팀 단위로 서비스 해결
  • 팀 단위로 각각의 모듈을 개발할 때, 적절한 수준에서 기술 스택을 다르게 가져갈 수 있다.
    회사가 Java/Spring 기반이라도, MSA를 적용하면 node.js 등을 이용해 개발 모듈을 연동함에 무리가 없다.
• 마이크로서비스의 개별 배포
  • 마이크로서비스는 서비스별로 독립적 배포가 가능하다.
    따라서 지속적인 배포도 모놀리식에 비해 가볍게 할 수 있다.
• 마이크로서비스의 개별 Scale-Out
  • 마이크로서비스는 각각 서비스의 부하에 따라 개별적으로 scale-out이 가능하다.
    이는 메모리, CPU적으로 상당부분 이득이 된다.

단점

MSA는 보다 복잡한 아키텍처로 전체 서비스가 커짐에 따라 그 복잡도가 기하급수적으로 늘어날 수 있다.

• 복잡성 증가
  • MSA는 모놀리식에 비해 상대적으로 많이 복잡하다. 서비스가 모두 분산되어 있어 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야한다.
    또한 통신의 장애와 서버의 부하 등이 생길 경우 어떻게 transaction을 유지할지 결정하고 구현해야한다.
• 데이터 transaction의 일관성
  • 모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 데이터베이스를 가지고 있는 서비스도 각각 다르고, 서비스 연결을 위해 통신을 포함해야 해서 트랜잭션을 유지하는게 어렵다.
• 통합 테스트의 어려움
  • 통합 테스트가 어려워진다. 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않다.
• 배포의 어려움
  • 실제 운영환경에 배포하는 것이 쉽지 않다.
    마이크로서비스의 경우 서비스 1개를 재배포 한다고 해도 다른 서비스들과의 연계가 정상적으로 이루어지는지 확인해야한다.

---

Component

컴포넌트는 독립적으로 대체하거나 업그레이드 가능한 소프트웨어 단위를 뜻한다.

시스템을 컴포넌트로 나누고 이를 연결하여 구축하는 것을 컴포넌트화라고 하고, 소프트웨어를 여러 서비스로 분리하는 것을 뜻한다.

라이브러리 vs 서비스

 

레퍼런스
https://sabarada.tistory.com/51?category=822070