Microservice Architecture 컴포넌트

Microservice Architecture를 구성하는데 필요한 각각의 필요 요소들에 대해 이를 그룹화 하고 잘 정리한 자료를 찾는 것은 쉽지 않다.

사실 이 분야 전문가는 Gartner라고 생각하고 있고 그 분야의 전문가인 것 처럼 Gartner는 2018년 부터 Microservice Architecture에 대해 잘 정리하고 있다.

Gartner는 Microservice Architecuture의 구성 요소로써 실제 서비스에 필요한 컴포넌트들을 다루는 Outer Architecture와 그 컴포넌트에 실릴 응용 프로그램을 설계하고 개발하는 Inner Architecture라는 대분류를 만들고 다음의 다이어그램으로 그 영역을 표시했다.

 

Microservice Architecture Platform Components

Functional Components of a Microservice Platform, 2018 by Gartner

• The outer architecture of an MSA is the operating environment and platform for building and running microservices; inner architecture describes the architecture of individual microservices.
• MSA의 아우터 아키텍처는 마이크로서비스를 구축하고 운영하는데 필요한 운영 환경과 플랫폼을 의미합니다. 이너 아키텍처는 개별 마이크로서비스의 아키텍처를 의미합니다.

 

1. API Gateway

• 마이크로서비스들에 존재하는 각각의 서비스 API들을 외부의 클라이언트들에게 제공해 주기위한 Gateway 서비스 제공
• 상용 제품의 경우 엔진을 구성하는 API Gateway와 API들을 관리하고 엔진을 관리하는 APIM(API Management)로 구성됨
• OSS(Open Source Software) 제품으로는 초기에 Spring Cloud에서 많이 사용했던 Netflix OSS 기반의 Zuul과 최근에 Spring Cloud에 포함된 Spring Cloud Gateway 제품, Kong/Konga, Tyk 등이 있음
• 상용 제품으로는 Google Cloud의 APIgee, Redhat이 인수한 3Scale, 금융권에서 2010년 중반에 많이 사용했던 CA사의 APIGateway등이 유명

​

2. Service Mesh

API Gateway가 마이크로서비스 외부 클라이언트들이 외부에서 접속 할 수 있도록 하는 것과 달리 서비스매쉬는 마이크로서비스 내부에서 마이크로서비스 간의 서비스 Discovery(식별), Routing(경로), Load Balancing(부하분산), 인증/인가, 보안 등의 역할을 담당합니다.

서비스매쉬는 서비스 타입에 따라,

• Mesh-Native Code 방식: 플랫폼 제공 벤더에서 제공해주는 서비스 매쉬 타입(벤더에서 제어)
  • e.g. Azure Service Fabric
• Mesh-Aware Code 방식: 프로그램 코드 기반 서비스 매쉬 타입(개발자가 직접 제어)
  • e.g. Spring Cloud Neflix Eureka
• Mesh-Agnostic Code 방식: 플랫폼에서 관리자가 임의로 설정(사이드카 인젝션으로 제어)
  • e.g. istio/envoy

서비스매쉬 종류(Mesh-Native Code vs Mesh-Aware Code vs Mesh-Agnostic Code)

 

과거 Container 관리 환경이 Kubernetes 환경으로 통일되기 이전에는 특히 Pivotal이 주도하던 Cloud Foundry 진영에서 Eureka, Ribbon, Hystrix, OpenFeign, Spring Cloud Config Server등으로 Mesh-Aware Code 기반 Service Mesh를 구축했지만 Kubernetes가 오픈소스로 발표되고 대부분의 벤더들이 Kubernetes를 지원하는 현 시점(2020.11.29)에서는 istio와 envoy proxy로 Service Mesh를 구성하는 Mesh-Agnostic Code 방식이 더 인기가 있는 듯 합니다.

개인적으로 Agile과 DevOps를 지향하는 조직이라면 istio/envoy처럼 각 서비스별 미세한 설정이 불가능한 방식 보다 각 서비스간 미세 설정이 가능한 Mesh-Aware Code 기반을 추천드립니다. 특히 최근 pivotal(지금은 vmware네요 ^^;)이 Spring Cloud Kubernetes를 개발해 발표했고 Spring Cloud Kubernetes의 경우 Service Mesh를 위해 Kubernetes의 Master Node의 etcd에 있는 서비스 정보를 이용하기 있기때문에 과거 Eureka보다 관리해야 하는 영역이 많이 줄어들어 사용해지기 편해진 면이 있습니다.

​

3. Container Management

Container를 관리하는 관리 기능을 의미합니다. 단 한대의 PC/서버에서 많지 않은 컨테이너를 관리하는 시스템이라면 Docker Engine을 통해서도 충분히 Container들을 관리 할 수 있겠지만 관리해야 하는 Container의 수가 수십,수백개가 된다면 이야기가 틀려집니다. Container Management는 바로 이렇게 관리해야 할 Container가 많은 경우 고려해야 하는 사항을 의미합니다.

Kubrernetes 발표와 더불어 이 시장은 신규 시스템 도입 검토를 위해 Kubernetes이외를 검토하는 경우가 없기 때문에 언급할 필요가 없지만 Pivotal이 주도한 Cloud Foundray, Docker에서 주도한 Docker Swam, 아파치 재단이 주도한 메소스, DC/OS 등이 있었습니다.

대표적인 제품으로는 Private Cloud 구축을 위해 사용되는 Redhat의 OpenShift와 VMWare의 Tanzu(구 PKS)가 있으며 Public Cloud의 경우 Amazon AWS의 EKS(Elastic Kubernetes Service), MS Azure의 AKS(Azure Kubernetes Service), Google Cloud의 GKE(Google Cloud Engine) 등이 있습니다.

​

4. Backing Service

마이크로서비스에서 데이터에 대해 정의 하는 부분이 Backing Service 입니다. Backing Service는 크게 3 영역으로 나뉘며 다음과 같습니다.

• Persistence: RDBMS와 NoSQL을 의미합니다. (e.g. oracle, mysql, maria, mongoDB, postgres ...)
• Cache: 데이터 캐쉬를 정의합니다. (e.g. radis)
• Message Broker: Queue등을 이용한 메시지 전달 매체와 방법을 의미합니다. (e.g. rabbitmq, kafka)

​

5. Telemetry

마이크로서비스는 각 서비스들이 분리되어 있기 때문에 각 서비스간의 로그를 한데 모아야 하는 이슈, 각 서비스가 어떻게 호출되는지 추적해야 하는 이슈, 그리고 각 서비스에 대한 모니터링 이슈가 생길 수 밖에 없습니다. Telemetry는 바로 Log, Trace, Monitoring을 의미합니다.

• Log : e.g. ELK(Elastic Search, Logstash, Kibana), EFK(Elastic Search, Flount.d, Kibana)
• Trace: e.g. sluth/zipkin
• Moinitoring: e.g. Prometheus/Grafana

​

6. CI/CD

마이크로서비스는 많은 구성요소들이 유기적으로 통합되어 하나의 서비스를 구성하게 됩니다. 문제는 너무나 많은 구성요소들로 되어 있기때문에 개발, 배포, 테스트등이 쉽지 않다는 겁니다. CI/CD는 이를 위해 많은 부분을 자동화 시켜 지속적인 통합과 배포(Delivery)를 지원해 주는 개념입니다.

• Nexus, Habor, Helm, Jenkins, Git, gradle, maven, junit등으로 구성될 수 있습니다.

 

기타: MSA 컴포넌트 별 대표 제품들

MSA를 구성하는 대표 SW

이상입니다.

끝~