MSA(Micro Service Architecture)란? MSA vs Monolithic

모놀리틱(Monolithic) 아키텍처

[그림 1] Monolithic vs MSA

 

 

모놀리틱(Monolithic) 아키텍처는 하나의 어플리케이션을 단일 독립 시스템으로 구축하는 아키텍처를 뜻한다.

 

소규모의 어플리케이션이라면 모놀리틱 아키텍처가 간단한 구조로 유지보수하기 더 용이할 수 있다.

하지만 어플리케이션의 규모가 커질수록 아래와 같은 어려움들이 발생한다.

 

• 영향도 및 전체 구조 파악이 어려움
• 빌드, 테스트, 배포 시간이 증가
• 부분의 장애가 전체 장애로 이어짐
• 부분적인 scale-out이 어려움
• 작은 수정 사항에도 전체를 재빌드 및 배포해야 함

이러한 문제점들을 보완하기 위해 등장한 아키텍처가 바로 MSA(Micro Service Architecture)이다.

 

 

 

MSA(MicroService Architecture)란?

미국의 유명한 소프트웨어 개발자 마틴 파울러(Martin Fowler)는 MSA를 아래와 같이 정의했다.

 

In short, 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. 

 

 

요약하자면 MSA는 하나의 어플리케이션을 각각 독립적으로 실행되고 빌드, 배포할 수 있는 작은 서비스들의 집합체로 쪼개는 구조를 뜻한다.

 

MSA는 아래와 같은 장점을 가진다.

 

• 각각의 작은 서비스를 독립적으로 수정 및 빌드, 배포할 수 있다
• 부분 장애가 전체 장애로 이어지는 가능성이 줄어든다
• 부분적인 scale-out이 가능하다(부하가 발생하는 서비스만 Scale-out이 가능)
• 작은 서비스를 담당하는 인력을 분산해 전문성을 높일 수 있다
• 요구 사항을 빠르게 반영할 수 있다

 

이와 같이 MSA는 서비스 각각이 독립성을 지니기 때문에 유연성과 확장성을 높일 수 있다.

또한 어플리케이션의 규모가 커질수록 작은 서비스들로 나누어 관리하면 유지보수에 더 용이할 수 있다.

이러한 이유로 최근 많은 서비스들이 MSA를 채택하고 있다.

 

그러나, MSA가 무조건 좋은 아키텍처인 것은 아니다.

MSA는 아래와 같은 단점들이 존재한다.

 

• 초기 개발 비용이 높다
• 서비스 간 통신이 필수적이며 이에 따른 비용이 존재한다
• 모놀리틱 아키텍처에 비해 구조가 복잡하다(복잡도 증가)
• 데이터 정합성 관리가 어렵다
• 테스트 복잡도가 증가한다

 

한동안 MSA가 유행처럼 번진 적이 있는데, 최근에는 MSA의 단점을 비판하며 모놀리틱 혹은 다른 아키텍처를 채택하는 서비스들도 많이 생겨나고 있다.

 

결국 어떤 아키텍처를 채택해야 할지에 대해서는 많은 고민이 필요할 것이다.

 

이를 위해 MSA에 대해 좀 더 깊게 알아보자.

 

 

MSA의 특징

[그림 2] MSA의 특징

 

제대로 구성된 MSA는 아래와 같이 8개의 특징을 만족한다.

 

1. API Management : API를 통해 서비스 간 통신한다. API Gateway를 통해 외부 요청과 내부 서비스간 통신을 관리한다. 클라이언트의 요청을 API Gateway를 통해 일원화한다.
2. Auto Scaling & Self Healing : 부하 발생 시 자동으로 Scale-out이 가능하고, 서비스 장애 시 복구 자동화가 가능하다. 주로 클라우드 환경에서 동작한다.
3. Config Management : 서비스의 재빌드/재부팅 없이 설정사항 반영이 가능하다
4. Resilience & Fault Tolerance : 부분의 장애가 전체의 장애로 연계되지 않도록 계단식 실패 방지 구조를 가진다.
5. Centralized Logging : 서비스별로 나뉜 로그를 중앙 집중화하여 한 곳에서 관리 가능하다
6. Centralized Monitoring : 여러 서비스의 정보를 중앙 집중화하여 한 곳에서 모니터링 가능하다
7. Distributed Tracing : 작은 서비스들 간의 호출을 추적할 수 있다
8. Service Discovery : 여러 서비스들을 검색 및 등록하는 등 관리가 용이하다.

 

물론 위와 같은 8개의 특징을 모두 만족하지 않아도 MSA라고 볼 수 있지만, 위 특징을 만족한다면 더욱 안정적이고 효율적인 MSA를 운영할 수 있을 것이다.

 

 

MSA의 구조

[그림 3] MSA의 구성요소 (출처 : Gartner)

 

 

Gartner에 따르면, MSA는 크게 Inner Architecture와 Outer Architecure로 나뉜다.

 

• Inner Architecture : 실제 내부 서비스와 직접적으로 관련된 아키텍처로, API와 앱 Instance를 구성한다. 
• Outer Architecture : 내부 아키텍처가 제대로 동작하기 위해 지원하는 외부 아키텍처

 

Inner Architecure는 말 그대로 내부 서비스들의 아키텍처이다.

서비스들을 어떻게 정의하고, 해당 서비스에 접근하는 API를 설계한 구조이다.

우리가 기존에 모놀리틱 아키텍처로 설계했던 서비스를 작은 서비스들로 나누었다고 보면 된다.

 

이때 작은 서비스들을 어떤 식으로 정의할지에 대해서 비즈니스나 시스템의 특성을 고려해야 한다.

쇼핑몰이라면 조회, 장바구니, 결제, 배송, 문의 등 기능으로 쪼갤 수도 있고, 배포 및 장애 대응 등을 고려하여 쪼갤 수도 있다.

 

 

Outer Architecure는 아래와 같이 크게 6개로 나뉜다.

 

1. External Gateway
2. Service Mesh
3. Container Management
4. Backing Services
5. Telemetry
6. CI/CD Automation

 

이에 대해 좀 더 자세히 알아보자.

 

 

External Gateway(외부 게이트웨이)

[그림 4] 외부 게이트웨이

 

외부 게이트웨이(External Gateway)는 클라이언트의 요청을 일원화할 수 있는 창구이다.

 

만약 외부 게이트웨이가 없이 클라이언트가 수많은 서비스들에 따로따로 요청을 보내야 한다면 매우 불편할 것이다.

또한 매 요청마다 공통 기능(보안, 인증, 인가 등)이 중복으로 적용되는 비효율이 발생한다.

 

따라서 수많은 요청을 한 곳에서 관리하고 매 요청마다 중복되는 기능을 제공하는 외부 게이트웨이가 필요하다.

 

보통 API gateway를 External Gateway와 비슷한 개념으로 본다.

 

외부 게이트웨이 아래와 같은 기능들을 한다.

 

• 인증 및 인가 : API 호출에 대한 인증 및 인가를 담당
• 요청의 일원화 : 여러 서비스들에 대한 요청을 한 곳으로 일원화
• 라우팅 : 클라이언트의 요청을 적절한 서비스에게 위임
• Service Discovery : 각 서비스를 호출하기 위해 서비스의 위치(IP 등)를 파악하고 있어야 한다

 

Service Mesh

서비스 메쉬(Service Mesh)는 서비스들 간의 결합을 돕는 기능이다.

 

여러 개로 나뉜 서비스들은 결국에는 하나의 커다란 서비스를 위한 것이기 때문에 어떤 식으로든 결합이 필요하다.

이를 돕기 위한 기능이 서비스 메쉬다.

 

서비스 메쉬는 아래와 같은 기능들을 한다.

 

• 라우팅 : 요청을 적절한 서비스에게 전달 
• 로드 밸런싱 : 트래픽을 적절하게 분산하는 기능
• Service Discovery : 서비스를 검색할 수 있으며 호출 가능하다
• Config 저장소 : 작은 서비스들과 전체 환경에 대한 설정을 저장
• ID Provider : 신뢰할 수 있는 ID를 제공하고 유효성을 검사

 

언뜻 보면 외부 게이트웨이와 비슷한 기능을 하는 것처럼 보인다.

다만 다른 점은 외부 게이트웨이는 어플리케이션 외부 경계에 위치하지만 서비스 메쉬는 경계 내부에 위치하며 내부적으로 요청을 처리한다는 점이다.

 

즉, 외부 게이트웨이는 외부의 요청을 처리하며 서비스 메쉬는 내부의 요청을 처리한다는 것이다.

 

 

 

Container Management

컨테이너 관리는(Container Management)는 개별 서비스들을 컨테이너 기반으로 관리한다는 것이다.

주로 쿠버네티스나 OpenShift와 같이 컨테이너 관리 소프트웨어를 통해 동작한다.

 

컨테이너 관리는 아래와 같은 기능들을 한다.

 

• 운영체제 수준 가상화 방식으로 운영체제 커널을 공유
• 각각의 컨테이너는 각자의 네임스페이스와 파일시스템을 가지고 운영
• 어플리케이션의 의존성을 관리하며 어디서든 실행 가능하도록 함
• 물리적 하드웨어의 필요성을 제거하고 자원을 효율적으로 사용할 수 있도록 함

 

또한 컨테이너 관리는 다음과 같은 특징들을 가진다.

 

• 스케줄링 : 컨테이너 클러스터 내부에서 스케줄링이 가능
• 구성 스크립팅: 사전에 어플리케이션 구성 정보를 스크립팅하여 컨테이너 로드 가능
• 모니터링 : 컨테이너 상태를 모니터링할 수 있음
• Service Discovery : 특정 컨테이너가 어느 호스트에서 실행되는지 검색 가능
• 로드 밸런싱 : 특정 컨테이너에 부하가 집중되지 않도록 방지 가능
• 오토 스케일링 : 자동으로 컨테이너 확장 및 제거

 

이러한 컨테이너 기반 운영은 유연성과 자율성을 가질 수 있으며 인프라 관리를 용이하게 할 수 있어 MSA에 적합하다고 할 수 있다.

 

다만 컨테이너가 많아질수록 컨테이너의 유지보수가 어려워지기 때문에 이러한 점을 잘 고려해야 한다.

 

 

 

Backing Service

Backing Service는 말 그대로 어플리케이션에 필요한 Backing 서비스들을 포괄적으로 지칭하는 개념이다.

예를 들어 데이터베이스, 세션 관리 시스템, SMTP 서비스 등이 있다.

 

문제는 이러한 서비스들과 내부 마이크로 서비스들이 강하게 결합한다면 매우 비효율적이라는 것이다.

 

예를 들어 하나의 트랜잭션이 강하게 결합되어 처리될 때 장애가 발생한다면 해당 트랜잭션이 끊기고 요청은 보존되지 않을 것이다.

 

또한 여러 서비스들이 동기 방식으로 통신하며 비용을 높인다면 시스템의 유연성이 낮아질 것이다.

 

이를 해결할 수 있는 방식이 Message Queue이다.

 

참고) Message Queue

메시지 큐는 MSA에서 많이 사용되는 비동기 방식의 데이터 송수신 방식이다.

 

메시지를 발행하는 생산자(Producer)와 메시지를 수신하는 소비자(Consumer) 사이에 위치하며 메시지를 전달하는 매개체역할을 진행한다.

 

메시지가 일단 메시지 큐에 도착하면 장애가 발생하더라도 소비자에게 메시지가 전달될 가능성을 크게 높일 수 있다.

 

또한 비동기 방식으로 메시지를 전달하기 때문에 서비스 간 결합도를 낮추고 유연성을 높일 수 있다.

다수의 메시지 큐를 두어 많은 요청을 처리할 수 있어 대규모 트래픽 관리에도 용이하다.

 

이러한 특성 때문에 많은 MSA에서 Apache Kafka와 같은 메시지 큐를 채택하고 있다.

 

 

Telemetry

Telemetry는 서비들의 모니터링, 진단 등을 수행한다. 

 

다양한 서비스들의 로그를 수집하여 보여주고, 진단을 가능하게 한다.

 

예를 들어 AWS의 Amazon Elastic Search 등이 있다.

각 서비스의 Agent에서 로그를 수집하고 로그 서버를 통해 취합된다.

 

이러한 취합된 정보를 Kibana와 같은 시각화 툴을 이용해 관리자에게 보여줄 수도 있다.

 

또한, 다양한 이벤트가 발생한 순서대로 추적할 수 있는 Tracing 기능도 제공할 수 있다.

 

MSA는 매우 많은 서비스들이 분산되어 있기 때문에 이를 추적 및 관리할 수 있는 Telemetry는 필수적이다.

 

 

CI/CD Automation 

CI/CD 자동화(CI/CD Automation)는 말 그대로 CI/CD를 자동화할 수 있는 기능이다.

 

MSA는 작은 서비스들의 배포가 잦은 편으로 개발 민첩성을 위해 배포를 자동화하는 것이 좋다.

 

또한 다양한 서비스들을 개발하는 개발자의 수가 많은 MSA의 특성상 코드를 통합하는 CI도 중요하다. 

개발자들이 작성한 소스코드, 테스트 코드를 통합하고 자동으로 빌드 및 테스트할 수 있는 환경이 구축되어야 한다.

 

이후 실행환경에 통합된 코드를 자동으로 배포할 수 있어야 한다. 

 

 

 

정리

MSA는 대규모 시스템을 관리할 때 모놀리틱 아키텍처보다 강점이 있을 수 있다.

 

그러나 복잡성이 높아지고 서비스들 간의 통신에 따른 비용이 발생하는 등 배보다 배꼽이 클 수도 있다.

 

무조건 MSA가 좋은 아키텍처인 것은 아니기 때문에 MSA의 특징에 대해 제대로 파악하고 

 

자신의 어플리케이션에 적절한 아키텍처를 선택하자.

 

 

 

---

참고

 

[1] https://martinfowler.com/articles/microservices.html

[2] https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-1-MSA%EC%9D%98-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90-3sk28yrv0e

[3] https://metanetglobal.com/bbs/board.php?bo_table=tech&wr_id=38