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 시스템에 꼭 필요한 요소 중 하나입니다.