MSA(MicroService Architecture)란?

이번 포스팅에서는 클라우드 네이티브의 디자인 패턴이라 할 수 있는 MSA에 대해서 살펴볼까 합니다.

1. MSA란 무엇일까요?

보통 MSA를 설명하자면 Monolithic architecture와 비교해서 설명할 수 있습니다.
Monolithic architecture는 아래 그림과 같이, 어플리케이션 내에 모든 비지니스 로직이 다 들어가 있는 구조 입니다.

반면 MSA는 어플리케이션 각각의 서비스들을 Microservice라는 단위로 쪼개어서 구성하는 것입니다.
즉, 아래 그림처럼 서비스를 비지니스 경계에 맞게 세분화하고 서비스 간 통신은 네트워크 호출을 통해 진행하여 확장가능하고 회복적이며 유연한 어플리케이션을 구성하는 것입니다.

각각의 서비스들에 대한 호출은 각각의 API로 관리가 됩니다. 즉, 외부에서 서비스들을 호출할 때는 각각의 API를 통해 호출이 되는 구조입니다.

그렇다면, 왜 최근 들어 이런 MSA가 왜 화두가 되고 있을까요?
아마도 기존 Monolithic 구조의 단점으로부터 그 이유를 찾아볼 수 있을 것 같은데요.
기존 Monolithic 구조에서는 모든 구성요소가 한 프로젝트에 통합되어 있어서 새로운 기능 추가 및 업데이트에 어려움이 있고,특정 요소에 문제가 발생하면 전체적인 장애로 이어질 수도 있습니다.
또한 여러 시스템이 하나의 서버에서 동작하는 구조이기 때문에, Scale-out 시 필요없는 자원이 함께 증가될 수 있습니다.
결국, MSA는 이런 특성에 반해 이러한 한계점을 극복할 수 있기 때문에 각광을 받고 있는 게 아닐까 생각합니다.

2. 구성요소 및 기반 기술

그럼 MSA를 도입한다고 한다면, 어떤 기술과 구성요소를 알아야 할까요?
절대적이라고는 할 수 없지만 보통 MSA의 주요 컴포넌트들은 스프링 클라우드 또는 쿠버네티스를 사용하여 구현하고 있습니다.

주요 컴포넌트는 다음과 같습니다.

• Config Manangement
• Service Discovery
• API Management
• Centralized Logging/Monitoring
• Distributed Tracing
• REsilience & Fault Tolerance
• Auto Scaling & Self-Healing

아래 그림은 스프링 클라우드 또는 쿠버네티스에서 위 컴포넌트 들에 대한 제공 기술을 정리한 것입니다.

스프링 클라우드와 쿠버네티스는 둘다 MSA를 구현하기 위한 최적의 환경이지만 그 특징이 서로 상이하므로 개발자 구현 환경에 적합한 기술을 선정하는 것이 필요합니다.

어떤 기술을 도입하더라도 이를 보완하기 위해 추가적인 기반 기술을 알아야 하는데 바로 Service Mesh라는 것입니다.
Service Mesh는 Microservice 간 통신을 위해 서비스를 식별하고, 경로를 파악하며, 로드밸런싱 및 전체 서비스의 장애 전파 차단 기능을 합니다.
또한 Telemetry와 통합되어 로깅, 모니터링, 트래이싱 기능을 담당합니다.

아래와 같이 다양한 Service Mesh 사용 서비스들이 제공되고 있는데, 이 중 ISTIO가 가장 많이 사용되고 있다고 합니다.

이상, MSA에 대해서 간략하게 살펴 보았습니다.

Reference

스프링으로 하는 마이크로서비스 구축(매그너스 라슨)
누구나 쉽게 이해할 수 있는 MSA(네이버 클라우드)(그림 출처 포함)