MSA 제대로 이해하기

(1) MSA의 기본 개념

(2) 아키텍처 개요

(3) API Gateway

(4) Service Mesh

(5) Backing Service

(6) Telemetry

MSA 제대로 이해하기 -(1) MSA의 기본 개념

마이크로 서비스 아키텍쳐를 한마디로 다음과 같이 표현할 수 있습니다.

"하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐"

이것은 마치 레고놀이와 비슷하다고 볼 수 있는데요, 작은 레고블록(Microservice) 하나하나를 붙여 어떠한 큰 결과물을 만드는 형태를 MSA라고 말씀드릴 수 있겠습니다.

MSA의 등장배경

MSA의 등장을 살펴보기 위해서는, 기존에 우리가 어떠한 방식으로 개발을 진행해 왔는지에 대해 살펴 볼 필요가 있습니다.

Monolithic Architecture

Monolithic Architecture란, 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어있는 형태입니다.

아직까지는 많은 소프트웨어가 Monolithic 형태로 구현되어 있고, 소규모 프로젝트에는 Monolithic Architecture가 훨씬 합리적입니다. 간단한 Architecture이고, 유지보수가 용이하기 때문이죠.

하지만 일정 규모 이상의 서비스, 혹은 수백명의 개발자가 투입되는 프로젝트에서 Monolithic Architecture은 뚜렷한 한계를 보입니다.

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

MSA는 비즈니스 민첩성(Business agility)과 관련이 큽니다. ~(경영자는 좋아하지만 개발자는 싫어한다는 MSA..)~ 서비스나 프로젝트가 크고, 복잡하고, 장기적으로 운영될 수록, MSA의 장점이 더욱 드러나게됩니다.

MSA 이전에도 CBD, SOA 등 Monolith를 논리/물리적으로 구조화 하기 위한 노력들이 있어왔습니다.
MSA는 큰 의미에서 SOA의 부분집합으로 여겨지고 있으며, 다음에 기회가 될 때 SOA와 MSA에 대해 자세히 다뤄보도록 하겠습니다.

Micro service의 정의

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

위 문장에서 저는 small services, each running in its own process(스스로 돌아 갈 수 있는 작은 서비스) 와, independently deployable(독립적 배포 가능) 이 MicroService를 설명해 줄 수 있는 가장 핵심적인 문구라고 생각합니다.

martin Fowler의 페이지를 참조하여, MSA에서의 (micro)Service를 제 나름의 생각으로 정리해 보았습니다.

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

• 각각의 서비스는 독립적으로 배포가 가능해야함.

• 각각의 서비스는 다른 서비스에 대한 의존성이 최소화 되어야함

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

일반적으로 하나의 서비스는 하나의 기능이며, 하나의 프로젝트라고 볼 수 있지만, 비즈니스와 시스템의 실정에 맞게 서비스의 범위(크기)를 설정하는 것이 중요합니다.

MSA의 장단점

MSA의 장점

우선 MSA의 장점에 대해 알아보도록 하겠습니다. MSA는 서비스가 커지면서 생겼던 Monolithic Architecture의 문제점들을 어느정도 보완해 줄 수 있습니다.

• 배포(deployment) 관점
  * 서비스 별 개별 배포 가능 ( 배포 시 전체 서비스의 중단이 없음)

  • 요구사항을 신속하게 반영하여 빠르게 배포할 수 있음.

• 확장(scaling) 관점
  * 특정 서비스에 대한 확장성이 용이함.

  • 클라우드 사용에 적합한 아키텍쳐.

• 장애(failure) 관점
  * 장애가 전체 서비스로 확장될 가능성이 적음

  • 부분적 장애에 대한 격리가 수월함

이외에도, 신기술의 적용이 유연하고, 서비스를 polyglot하게 개발/운영 할 수 있다는 장점이 있습니다.

MSA의 단점

Monolithic Architecture은 단순한 아키텍쳐인데 비해 MSA는 보다 복잡한 아키텍쳐로, 전체 서비스가 커짐에 따라 그 복잡도가 기하급수적으로 늘어날 수 있습니다.

• 성능 - 서비스 간 호출 시 API를 사용하기 때문에, 통신 비용이나, Latency가 그만큼 늘어나게 됩니다.

• 테스트 / 트랜잭션 - 서비스가 분리되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가하고, 많은 자원을 필요로 합니다.

• 데이터 관리 - 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어렵습니다.

MSA 제대로 이해하기 -(2) 아키텍처 개요

MicroService Architecture는 크게 Inner Architecture와 Outer Architecture로 구분할 수 있습니다. 위 그림에서 남색 부분은 Inner Architecture의 영역이고, 회색 부분은 Outer Architecture 부분입니다.

Inner architecture

Inner architecture는 내부 서비스와 관련된 architecture입니다. 쉽게 말해, 내부의 서비스를 어떻게 잘 쪼개는지에 대한 설계입니다.

Inner Architecture에서 고려해야 할 부분은 다음과 같습니다.

• (마이크로)서비스를 어떻게 정의할 것인가?

  쇼핑몰에서, 주문하기 부분과, 카트에 넣기를 같은 서비스로 넣을 것인지, 다른 서비스로 분리할 것인지는 그 비즈니스나 시스템의 특성에 따라 정의되어야 합니다.

  서비스를 정의하기 위해 고려해야 할 사항은 비즈니스 뿐만 아니라, 서비스 간의 종속성, 배포 용이성, 장애 대응, 운영 효율성 등 굉장히 많습니다.

• DB Access 구조를 어떻게 설계할 것인가?

  Microservice가 사용하는 데이터는 일반적으로 일관된 API를 통해서 접근합니다. 또한 각 마이크로 서비스에는 자체의 데이터베이스를 가질 수 있는데, 일부의 비즈니스 트랜잭션은 여러 microservices를 걸쳐 있기 때문에, 각 서비스에 연결된 데이터베이스의 정합성을 보장해 줄 수 있는 방안이 필요합니다.

• (마이크로)서비스 내 api를 어떻게 설계할 것인가?

• 논리적인 컴포넌트들의 layer를 어떠한 방식으로 설계할 것인가? 등등...

Inner Architecture는 비즈니스마다, 서비스마다, 시스템마다 각각의 특성이 있기 때문에 딱히 정해져 있는 것이 없습니다.( 표준이 없습니다.) 따라서 이 부분은 MSA를 설계하는 데에 가장 어려운 부분이기도 합니다.

Outer architecture

맨 위의 그림에서와 같이 Gartner에서는 MSA의 Outer architecture을 총 6개의 영역으로 분류하고 있습니다.

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

이번 글은 '아키텍처의 개요' 이므로, 위 6가지 요소가 어떠한 것인지 맛보기로만 간단하게 알아보도록 하겠습니다.

위 6가지 요소에 대한 세부 내용은 이어지는 글에서 상세하게 다루어볼 예정입니다.

1. External Gateway

External Gateway는 전체 서비스 외부로부터 들어오는 접근을 내부 구조를 드러내지 않고 처리하기 위한 요소입니다. 사용자 인증(Consumer Identity Provider)과 권한 정책관리(policy management)를 수행하며, API Gateway가 여기서 가장 핵심적인 역할을 담당합니다.

API Gateway는 서버 최앞단에 위치하여 모든 API 호출을 받습니다. 받은 API 호출을 인증한 후, 적절한 서비스들에 메세지를 전달될 수 있도록 합니다.(routing)

2. Service Mesh

Service Mesh는 마이크로서비스 구성 요소간의 네트워크를 제어하는 역할을 합니다. 서비스 간에 통신을 하기 위해서는 service discovery, service routing, 트래픽 관리 및 보안 등을 담당하는 요소가 있어야 합니다.
Service Mesh는 위에 언급된 기능들을 모두 수행합니다.

3. Container Management

컨테이너 기반 어플리케이션 운영은 유연성과 자율성을 가지며, 개발자가 손쉽게 접근 및 운영할 수 있는 인프라 관리 기술이기 때문에 MSA에 적합하다고 평가받고 있습니다.

대표적인 컨테이너 관리 환경인 Kubernetes가 Container management에 많이 사용되고 있습니다. 특히 AWS의 EKS, Google cloud platform의 GKE는 kubernetes를 지원하는 클라우드 서비스로, 앞으로의 어플리케이션 운영 환경을 많이 변화시킬 것으로 예상됩니다.~(아직은 많은 개선이 필요한 서비스입니다.)~

4. Backing Service

Backing Service는 어플리케이션이 실행되는 가운데 네트워크를 통해서 사용할 수 있는 모든 서비스를 말하며, My SQL과 같은 데이터베이스, 캐쉬 시스템, SMTP 서비스 등 어플리케이션과 통신하는 attached Resource들을 지칭하는 포괄적인 개념입니다.

MSA에서의 특징적인 Backing service들 중 하나는 Message queue입니다. MSA에서는 메세지의 송신자와 수신자가 직접 통신하지 않고 Message Queue를 활용하여 비동기적으로 통신하는 것을 지향합니다.

예를 들어, MSA를 적용한 프로젝트에서 장애 발생이 일어났다고 가정해 봅시다. 이 경우, 마이크로서비스 오케스트레이션이 진행되면서, 새로운 마이크로 서비스를 신규 생성하거나 재생성 등의 작업을 진행하게 됩니다.

만약 Message Queue를 사용하지 않는 강한 결합 구조의 경우, 여러 서비스를 걸치는 실시간 트랜잭션을 처리할 때, 하나의 서비스가 죽어버린다면 트랜잭션이 끊어지기 때문에 해당 서비스 요청을 보존할 수 없고 큰 에러가 발생하게 됩니다. 또한 REST 통신으로 트랜잭션 실패에 대한 처리를 구현하는 방법은 굉장히 복잡합니다.

MSA에서 데이터 변경이나, 보상 트랜잭션과 관련된 처리는 Message Queue를 활용한 비동기 처리가 효율적입니다.

5. Telemetry

Telemetry의 어원은 Tele(먼 거리) + metry(측정)입니다. 즉, 실시간으로 먼 거리에서 원격으로 측정할 수 있다... 뭐 이런 의미가 되겠네요.

MSA에서는 상당수의 마이크로서비스가 분산환경에서 운영되기 때문에 서비스들의 상태를 일일이 모니터링하고, 이슈에 대응 하는 것은 굉장히 힘들고 오랜 시간이 걸립니다. Telemetry는 서비스들을 모니터링하고, 서비스별로 발생하는 이슈들에 대응할 수 있도록 환경을 구성하는 역할을 합니다.

6. CI/CD Automation

CI/CD는 어플리케이션 개발 단계를 자동화하여, 어플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법입니다.

지속적인 통합(Continuous Integration), 지속적인 전달(Continuous Delivery), 지속적인 배포(Continuous Deployment)가 CI/CD의 기본 개념으로, 이를 자동화하는 것은 배포가 잦은 MSA 시스템에 꼭 필요한 요소 중 하나입니다.

MSA 제대로 이해하기 -(3)API Gateway

지난 포스팅에서 MSA를 구성하는 아키텍처 요소에 대해 살펴보았습니다. Inner Architecture와 Outer Architecture로 나누어 설명을 드렸었죠.

MSA 제대로 이해하기 - (2)아키텍처 개요

오늘은 그 중 Outer Architecture에서도 API Gateway에 대해 설명하려 합니다.

API Gateway의 필요성

MSA는 큰 서비스를 잘게 쪼개어 개발/운영 하는 아키텍처입니다. 하나의 큰 서비스는 수십~수백개의 작은 서비스로 나뉘어지며, 만약 이를 클라이언트에서 서비스를 직접 호출하는 형태라면 다음과 같은 문제점이 생길 수 있습니다.

• 각각의 서비스마다 인증/인가 등 공통된 로직을 구현해야하는 번거로움이 있습니다.
• 수많은 API 호출을 기록하고 관리하기가 어렵습니다.
• 클라이언트에서 여러 마이크로 서비스에 대한 번거로운 호출을 해야합니다.
• 내부의 비즈니스 로직이 드러나게 되어 보안에 취약해집니다.

특히 이러한 문제점들은 마이크로 서비스의 갯수가 많아질 수록 기하급수적으로 늘어나게 될 것입니다.

어느 규모 이상의 마이크로 서비스 기반 어플리케이션에는 API Gateway를 도입하는 것이 효율적입니다.

API Gateway는 API 서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화 해주는 또다른 서버입니다. API에 대한 인증과 인가 기능을 가지고 있으며, 메세지의 내용에 따라 어플리케이션 내부에 있는 마이크로 서비스로 라우팅하는 역할을 담당합니다.

API Gateway의 시작은 SOA의 핵심 인프라라고 할 수 있는 ESB(Enterprise Service Bus)에서 시작되었습니다. 따라서 API Gateway의 많은 부분들이 ESB로 부터 승계되었습니다.
ESB가 SOAP/XML 기반의 무거운 기능을 가졌다면, API Gateway는 REST/JSON 기반으로 보다 가볍게 설계된 것이 특징입니다.

API Gateway의 주요 기능

1. 인증 및 인가 ( Authentication and Authorization)

마이크로 서비스 아키텍처에서 각각의 서비스에 API 호출에 대한 인증 및 인가를 하는 것은, 같은 소스코드를 서비스 인스턴스들마다 심어주어야한다는 것을 의미합니다. 이러한 경우, 소스의 중복이 심하여 유지 관리가 어려운 것은 물론, 로깅 및 모니터링을 관리하는 것도 매우 어려워집니다.
이러한 이유로 인증서 관리나, 인증, SSL, 프로토콜 변환과 같은 기능들은 API Gateway에서 오프로드 함으로, 각각의 서비스의 부담을 줄이고, 서비스의 관리 및 업그레이드를 보다 쉽게 할 수 있게 합니다.

Authentication(인증)과 Authorization(인가)의 차이

Authentication은 유저가 누구인지 확인하는 절차(A라고 하며 접근하는 사람이 진짜 A인지 확인하는 절차)이고, Authorization은 어떠한 유저가 특정 자원에 접근하려 할때, 그에대한 접근 권한이 있는지 확인하는 절차입니다.

2. 요청 절차의 단순화

여러 마이크로서비스를 대상으로하는 기능을 이용하려 할 때, 만약 API Gateway가 없다면 클라이언트에서 여러 서비스들에 대해 요청을 진행해야 했을 겁니다.
하지만, API Gateway는 여러 클라이언트의 요청을 단일 클라이언트의 요청으로 대체 가능하도록 합니다. 따라서 클라이언트와 백엔드 간의 API 통신량을 줄여주어 대기시간을 줄이고 효율성을 높여줄 수 있습니다.

3. 라우팅 및 로드밸런싱

API Gateway는 클라이언트로 부터 접수된 메세지에 따라, API 호출을 적절한 서비스에 라우팅 할 수 있는 기능이 있습니다. 또한, 서비스 인스턴스들에 대한 부하분산을 할 수 있습니다.

4. 서비스 오케스트레이션

오케스크레이션은 여러개의 마이크로 서비스를 묶어 새로운 서비스를 만드는 개념입니다. 오케스트레이션 로직을 과도하게 넣는 것은, API Gateway의 부담을 늘리는 것으로, 성능 저하를 일으킬 수 있어, MSA와 API Gateway에 대한 높은 수준의 기술적 이해를 바탕으로 이루어져야 합니다.

5. 서비스 디스커버리

API Gateway는 각 서비스를 호출하기위해, 서비스마다의 IP주소와 포트번호를 알고 있어야 합니다. legacy 환경에서는 고정적인 IP주소를 가지고 있기 때문에 크게 문제될 것이 없지만, 클라우드 환경에서는 동적인 환경에서 배포되기 때문에 서비스의 위치를 찾는 것이 어렵습니다. 이러한 서비스의 위치(IP 주소와 포트번호)를 찾는 것을 "Service Discovery"라 하며, API Gateway에서는 서버사이드나, 클라이언트 사이드를 기준으로 하여 서비스 디스커버리를 구현할 수 있습니다.

API Gateway 적용시 고려해야 할 사항

1. API Gateway 적용의 가장 큰 단점은 API Gateway를 내부 마이크로서비스와 결합한다는 것입니다. 이러한 결합은 기존 SOA에서의 ESB(Enterprise Service Bus)에서 발생했던 문제점이 다시 발생할 수 있습니다.

2000년대 후반, 많은 SOA 프로젝트가 실패한 이유로 SOA의 핵심적인 요소 중 하나인 ESB가 꼽히는 경우를 많이 볼 수 있었습니다. 그 이유는 다음과 같습니다.
첫 번째로, 당시 ESB 내부 처리 로직을 XML을 기반으로 하였는데, XML의 파싱은 오버헤드가 큰 작업이었습니다.
두 번째로, ESB는 가벼운 연산 뿐만 아니라, 과도한 Orchestration 등 무거운 로직을 가지고 있었습니다. 특히 ESB를 Gateway로의 특성이 아닌 시스템을 통합하기 위한 역할로 많이 구현하였기 때문에 많은 실패 사례가 발생하였습니다.

2. API Gateway의 Scale-out 적용이 유연하게 일어나지 않을 경우, API Gateway가 병목지점이 되어 어플리케이션의 성능저하가 일어날 수 있습니다.

3. API Gateway라는 추가적인 계층이 만들어지는 것이기 때문에, 그만큼 네트워크 latency가 증가하게 됩니다.

MSA 제대로 이해하기 -(4)Service Mesh

이번에는 Outer Architecture 중 Service Mesh에 대한 이야기입니다.

Service Mesh

Service Mesh는 쉽게말해 마이크로 서비스 간의 통신(네트워크)을 담당하는 요소입니다.

마이크로 서비스 구성 요소간 상호 통신을 위해서는 Service Discovery, 서비스 라우팅, Failure recovery, load balancing(트래픽 관리), 보안 등의 문제를 처리할 수 있는 메커니즘이 필요합니다.

Service Mesh는 통신 및 네트워크 기능을 비즈니스 로직과 분리한 네트워크 통신 인프라입니다.모든 서비스의 인프라 레이어로서 서비스들 간의 통신을 처리하며, 위의 언급된 많은 기능들을 포함하고 있습니다.

API Gateway도 비슷한 기능이 있지 않았나요?

이전 포스팅에서 API Gateway에서도 Service Discovery, 라우팅, 트래픽 관리와 같은 비슷한 기능을 담당한다고 말씀드렸습니다.

MSA 제대로 이해하기 -(3)API Gateway

그럼 API Gateway와 Service Mesh는 무엇이 다른걸까요?

• 적용되는 위치
  API Gateway는 마이크로서비스 그룹의 외부 경계에 위치하여 역할을 수행하지만, ServiceMesh는 경계 내부에서 그 역할을 수행합니다.

• 아키텍쳐 형태
  API Gateway가 중앙집중형 아키텍쳐여서 SPOF(Single Point of Failure)을 생성한다면, Service Mesh는 분산형 아키텍쳐를 취하기 때문에 SPOF를 생성하지 않고 확장이 용이합니다.

• 패턴
  API Gateway는 일반적으로 Gateway proxy pattern을 사용해서 수행됩니다. Consumer(호출자)은 구현 내용을 알 필요 없이 Gateway를 호출하는 방법만 알면 Gateway가 알아서 수행해주는 방식입니다.
  반면, Service Mesh는 일반적으로 Sidecar proxy pattern을 사용합니다. Consumer(호출자)의 코드에는 Provider(공급자)의 주소를 찾는방법, failover와 관련된 코드 등의 내용이 들어가게 됩니다. 다만, 호출자의 코드는 어플리케이션 코드(비즈니스 로직)에 내장되는 것이 아니라 sidecar 형태로 별개로 관리됩니다.

이외의 차이점에 대해서는 아래의 표에 정리해 보았습니다.

최근 MSA에서 API Gateway는 노출되는 부분(External)에 위치하여 내부서비스를 보호 및 제어하는 역할을 하고, Service Mesh는 내부 서비스(Internal)에 위치하여 서비스를 관리하는 구조로 많이 사용되고 있습니다.

그림 출처 : Service Mesh vs API Gateway

Service Mesh의 종류

Service mesh는 현재 크게 세가지 유형으로 구분할 수 있습니다.

1) PaaS (Platform as a Service)의 일부로 서비스 코드에 포함되는 유형
Microsoft Azure Service fabric, lagom, SENECA 등이 이 유형에 해당되며, 프레임워크 기반의 프로그래밍 모델이기 때문에, 서비스메쉬를 구현하는데에 특화된 코드가 필요합니다. ( Mesh-native Code )

2) 라이브러리로 구현되어 API 호출을 통해 Service mesh에 결합되는 유형
Spring Cloud, Netflix OSS(Ribbon/Hystrix/Eureka/Archaius), finagle 등이 이 유형에 해당되며, 프레임워크 라이브러리를 사용하는 형태입니다. 이중 Netfilix의 Prana는 sidecar 형태로 동작합니다. 서비스 메시를 이해하고 코드를 작성해야합니다. (Mesh Aware Code)

3) Side car proxy를 이용하여 Service mesh를 마이크로서비스에 주입하는 유형
Istio/Envoy, Consul, Linkerd 등이 이 유형에 해당되며, sidecar proxy 형태로 동작됩니다. 따라서 서비스메시와 무관하게 코드를 작성할 수 있습니다.

Sidecar pattern?

Sidecar pattern은 (컨테이너 배포방식의 경우) 모든 응용 프로그램 컨테이너에 추가로 sidecar 컨테이너가 배포됩니다. Sidecar는 서비스에 들어오거나 나가는 모든 네트워크 트래픽을 처리하게 됩니다. 가장 큰 특징은, 비즈니스 로직이 포함된 실제 서비스와 sidecar이 병렬로 구성되어있기 때문에, 서비스 호출에서 서비스가 직접 서비스를 호출하는 것이 아니라 proxy 를 통해서 호출하게됩니다.

따라서, 대규모의 마이크로서비스 환경이라고 하여도 개발자가 별도의 작업 없이 서비스의 연결 뿐만 아니라, 로깅, 모니터링, 보안, 트래픽 제어와 같은 다양한 이점을 누릴 수 있습니다.

최근의 Service Mesh는 Sidecar pattern 유형이 recommended 되고 있는 추세입니다.

Service Mesh의 주요 기능

일반적으로, Istio나 consul, Linkerd와 같은 Service Mesh 프레임워크들은 다음과 같은 기능들을 지원하고 있습니다.

• Service Discovery
• Load balancing (지연시간 기반 / 대기열 기반 )
• Dynamic Request Routing
• Circuit Breaking
• 암호화 (TLS)
• 보안
• Health check, Retry and Timeout
• Metric 수집

MSA 제대로 이해하기-(5)Backing Service

이번 시간에는 MSA의 Outer Architecture 중 Backing Service에 대해 알아보도록 하겠습니다.

Backing service

우선 Backing Service란, 어플리케이션이 실행되는 가운데 네트워크를 통해서 사용할 수 있는 모든 서비스를 말하며 My SQL과 같은 데이터베이스, 캐쉬 시스템, SMTP 서비스 등 어플리케이션과 통신하는 attached Resource들을 지칭하는 포괄적인 개념입니다.

마이크로서비스 Backing service의 특징

마이크로 서비스에서의 Backing service는 메세지큐를 활용한 비동기 통신 패턴을 많이 사용합니다. 현대 MSA의 특징 중 하나는 하나의 Micro Service에 이벤트(장애 발생, 트래픽 증가, 소스 반영 등)가 발생할 경우, Micro Service 오케스트레이션이 진행되며, 마이크로서비스의 신규 생성, 재생성, 서비스 인스턴스의 삭제 등의 작업이 빈번하게 이루어진다는 것입니다.

그림과 같이 하나의 비즈니스 프로세스를 수행하기 위해 여러 마이크로 서비스간 통신이 필요한 경우를 생각해보겠습니다.

하나의 트랜잭션에서 여러 마이크로 서비스들이 강하게 결합되어 처리되는 방식의 경우, Orchestration이 진행되면서 진행 중인 트랜잭션이 끊어지게 되고, 해당 서비스 요청을 보존할 수 없게 됩니다.

MSA에서는 Message queue를 활용하여 트랜잭션을 분리하는 전략을 많이 취합니다. 특히 Message queue를 사용할 경우 서비스의 영속성( 서비스에 장애가 발생하더라도 event message가 consumer에 전달되는 것이 보장됨 )을 유지할 수 있다는 장점이 있습니다.

Message queue

일반적인 웹서비스에서 서버-클라이언트 사이의 통신은 결합도가 높은 구조이며, 동기방식으로 작동합니다. 이와 같은 방식은 시스템 내 요소들 간에 의존성이 높아 시스템에 많은 영향을 끼치며, 유연성이 낮습니다.

서비스 간 결합도가 낮아야 하는 MSA에서 데이터의 송수신 방법으로는 비동기방식으로 메시지를 사용하는 것이 효율적입니다. Message Queue(MQ)는 메세지를 발행하는 생산자(producer, publisher) 와 메세지를 받는 소비자(consumer, subscriber) 사이에 위치하는 매개체역할을 수행하는 미들웨어입니다.

분산된 마이크로서비스 간에 Message queue를 이용하여 비동기 방식으로 통신하는 것은 다음과 같은 특징을 가집니다.

• 비동기 / 약결합
• Redundancy : 서비스가 실패하더라도 재처리를 할 수 있습니다.
• Resilence : 전체 시스템에 대한 영향이 적고, 회복 탄력성이 높습니다.
• 보장성 : Message Queue에 들어간 Message는 최소 한번은 처리됩니다.
• 확장성 : 다수의 Message queue를 두어 많은 요청에 대해 유연하게 확장할 수 있습니다.

Apache Kafka

Kafka는 Pub/Sub 구조에 특화된 메세지 큐이고, 분산 환경에 특화되어 설계되어있습니다. RabbitMQ나, ActiveMQ에 비해 높은 처리량, 및 성능을 가지고 있습니다.

Apache Kafka의 특징

• 대용량 및 실시간 처리에 특화되어있습니다.
• 단순한 TCP 기반의 프로토콜을 사용함으로 오버헤드가 적습니다.
• 메모리가 아닌 파일시스템에 메세지를 저장합니다.
• OS에서 처리하는 페이지 캐시를 이용함으로써 속도가 빠릅니다.
• consumer가 pull 방식으로 메세지를 받으며, batch 처리가 가능합니다.

MSA 제대로 이해하기-(6)Telemetry

이번 시간에는 MSA의 Outer Architecture 중 Telemetry에 대해 알아보도록 하겠습니다.

Telemetry

MSA에서는 상당수의 마이크로서비스가 분산환경에서 운영되기 때문에 서비스들의 상태를 일일이 모니터링하고, 이슈에 대응 하는 것은 굉장히 힘들고 오랜 시간이 걸립니다. Telemetry는 서비스들을 모니터링하고, 서비스별로 발생하는 이슈들에 대응할 수 있도록 환경을 구성하는 역할을 합니다.

Telemetry는 Grafana, Prometheus, EFK와 같이 오픈소스로 직접구현하는 방법, Datadog와 같은 상용 솔루션을 이용하는 방법, 그리고 AWS Cloud watch, GCP Stackdriver와 같이 public cloud의 SaaS를 이용하는 방법으로 구현할 수 있습니다.

Telemetry의 주요기능

1. Monitoring

모니터링은 인프라 및 응용 프로그램의 성능이나 효율성을 확인하는 작업으로 마이크로 서비스를 운영하는데에 필요로 합니다. Monitoring을 위해서는 metric 수집, logging, Tracing 영역에서의 데이터 수집 및 분석이 필요합니다.

AWS의 Cloud watch, Azure의 Monitor, GCP의 Stackdriver가 Public cloud에서 Monitoring을 담당하는 요소이며, OSS로는 Prometheus등이 있습니다.
Monitoring은 각 대상에서 수집한 Metric을 통해 대상의 리소스 사용률이나, 트래픽 등을 대시보드로 볼 수 있게 해줍니다.

2.Logging

Log는 실행중인 프로세스에서 발생하는 이벤트를 말하며, Logging은 이러한 Log들을 수집해서 보여주는 것을 말합니다. 마이크로 서비스 아키텍쳐는 Monolithic 어플리케이션보다 실행하는 프로세스의 수가 훨씬 많기 때문에 장애가 발생시에 root cause를 파악하기 힘듭니다.

AWS에서는 Amazon Elastic Search 등이 Logging을 담당하는 요소이며, OSS로는 EFK(Elastic Search - FluentD - Kibana) 가 대표적입니다. 각 서비스에 심어진 Agent가 해당 서비스의 Log정보들을 수집하고, Log Server(Aggregator)를 통해 취합됩니다. 최종적으로 Kibana와 같은 툴을 통해 시각화된 데이터를 관리자에게 보여줍니다.

image 출처: https://medium.com/@carlosedp/log-aggregation-with-elasticsearch-fluentd-and-kibana-stack-on-arm64-kubernetes-cluster-516fb64025f9

Logging시의 고려사항

• 로그를 서비스 내 저장소에 저장할 경우, 관리가 어려워지므로 ( container managed service의 경우 컨테이너가 종료되거나 재시작 될 경우 사라질 수 있습니다.) 로그를 어플리케이션 서버 내부에 저장하지 않고 외부 저장소에 저장하도록 합니다.
• MSA 에서 가상머신과 컨테이너는 application과의 결합이 "약한 결합"입니다. 즉, 배포에 사용되는 컨테이너는 배포할 때마다 달라질 수 있습니다. 따라서 디스크 저장 상태에 의존하는 것이 아니라, 별도의 Logging도구를 활용하는 것이 효율적입니다.
• 로그파일은 ACL을 통하여 로그 관리자만 로그를 확인 할 수 있도록 하여야 합니다.

3. Tracing

Tracing은 마이크로 서비스 아키텍처에서 발생한 Event를 발생한 순서대로 나열하여 추적할 수 있게 해주는 기능입니다.

AWS에서의 Amazon X-Ray 등이 Tracing을 담당하는 요소이며, OSS로는 Zipkin Jaeger등이 대표적입니다.