본문 바로가기
web/SpringBoot

[MSA] 아키텍처 구성

by 뽀리님 2023. 11. 28.

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

 

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

 

참조 https://sharplee7.tistory.com/70?category=1020249

 

 

 

각각의 구성요소들 이다.

 

 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등이 유명

 

 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

참조 https://sharplee7.tistory.com/70?category=1020249

 

 

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

 

 

 

 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) 등이 있습니다.

 

 Backing Service

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

마이크로서비스에서 데이터에 대해 정의 하는 부분이 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)

 

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

 

 CI/CD

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

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

 

 

참고

https://sharplee7.tistory.com/70?category=1020249