Service Mesh 비교 (AWS App Mesh vs Istio)

마이크로서비스 아키텍처는 시스템 기능을 여러 독립 서비스로 분리하므로 이러한 서비스 간의 통신 메커니즘은 확장 가능하고 사용 가능한 고성능 아키텍처의 핵심 역할을 합니다.

서비스 메시 는 투명하고 언어 독립적인 방식으로 서비스 통신 을 관리하는 인프라 계층입니다 . 서비스 인스턴스가 서비스 검색, 부하 분산, 데이터 암호화, 인증 및 권한 부여와 같은 중요한 작업을 수행하는 방법을 구성하는 데 도움이 됩니다.

서비스 메시 패턴은 다음과 같은 경우에 더 적합합니다.

• 통신을 위한 공통 아키텍처 패턴이 필요한 여러 프로그래밍 언어로 된 서비스.
• 보안, 서비스 검색, 로드 밸런싱, 인증, 모니터링 등과 같은 오프로드 책임
• 특히 동기식 통신( REST, gRPC, WebSocket )에 유용합니다. 비동기 또는 이벤트 기반의 경우 이벤트 메시 또는 메시징 아키텍처 와 함께 공존할 수 있습니다 .

 

Istio

Istio 는 Kubernetes 및 Envoy as Service Proxy 에 대한 기본 통합을 통해 Google, IBM 및 Lyft에서 만든 가장 인기 있는 오픈 소스 서비스 메시입니다 . Istio 컨트롤 플레인은 자동 로드 밸런싱, 라우팅, 정책 관리, 관찰 가능성(메트릭, 로그 및 트레이스), 인증 및 통신 등을 처리합니다.

Istio는 마이크로서비스 기반 앱을 실행할 수 있도록 지원하는 오픈 소스 서비스 메시입니다. 

Istio as Managed Service 는 Istio 오픈소스 코드베이스의 상위 5개 공급자와 함께 사용할 수 있습니다.

• Google Anthos Service Mesh  — 이전 Google Cloud는 Istio를 관리형 서비스로 제공했지만 현재는 지원 중단되었습니다. Google은 Istio에서만 지원되는 Anthos Service Mesh로 마이그레이션할 것을 권장합니다.
• Aspen Mesh  — F5 의 일부로 다중 클러스터/다중 클라우드 기능, 운영 지원, 보안이 강화된 배포, RBAC 지원, 개체 중심 정책, 간소화된 mTLS 관리, 직관적인 UI를 갖춘 Istio용 완전 호스팅 SaaS 플랫폼을 제공합니다. , 및 기타 기능.
• Solo Gloo Mesh  — 통합 컨트롤 플레인, 제로 트러스트 보안, 운영 지원 등을 통해 다중 클러스터 및 하이브리드 클라우드 관리 기능을 갖춘 엔터프라이즈 Istio를 제공합니다. AWS( EKS Anywhere 포함), Azure , Red Hat 및 온프레미스 배포를 지원합니다.
• Istio on IBM Cloud - Istio를 기존 Kubernetes 클러스터와 직접 통합하는 관리형 추가 기능으로 제공됩니다. IBM Cloud Kubernetes Service 클러스터에서 생산 준비가 된 Istio 인스턴스를 사용하여 클릭 한 번으로 배치를 지원합니다.
• Red Hat OpenShift Mesh  — 하이브리드 클라우드 엔터프라이즈 Kubernetes 플랫폼을 지원하는 프로덕션 등급 Istio를 제공하며 OpenShift Kubernetes 배포를 사용하는 경우 가장 적합합니다.

Kubernetes 배포를 제공하는 공급업체는 Istio 배포가 에코시스템을 완성할 가능성이 가장 높습니다. Kubernetes as a PaaS와 Istio as a Service 메시 솔루션 간의 시너지 효과는 기업에서 중요한 측면입니다.

그림 A – Istio 아키텍처(출처: https://istio.io/latest/docs/concepts/what-is-istio/ )

 

 

AWS App Mesh

AWS App Mesh 는 마이크로서비스 아키텍처에 대한 애플리케이션 수준 네트워킹 및 서비스 통신 지원을 제공하는 관리형 서비스입니다. 또한 Envoy 프록시를 사용하여 여러 솔루션 접근 방식과 호환됩니다. AWS에서 실행되는 AWS Fargate ,  Amazon EC2 ,  Amazon ECS ,  Amazon EKS 및  Kubernetes 를 지원  합니다.

그림 B – AWS AppMesh 아키텍처(출처: https://aws.amazon.com/ )

 

기능 비교

기능적 및 비기능적 요구 사항을 충족하기 위한 시스템 컨텍스트 및 적용 가능성에 따라 달라집니다. 

특징	AWS App Mesh	Istio	내용
운영 비용	낮음	높음	Istio는 자체 관리 컨트롤 플레인을 제공하며 관리 서비스를 사용하지 않는 경우 운영 오버헤드가 있습니다.
이식성	낮음	높음	Istio는 Kubernetes용으로 구축되었으며 VM도 지원하고 SMI (어댑터를 통해)를 준수합니다. 자체 관리형 K8, EKS, GKE 등과 통합 가능
유연성	낮음	높음	Istio는 확장 가능하고 공급업체 중립적 App Mesh는 EKS, ECS, Fargate를 위한 최고 수준의 지원입니다. 그러나 EC2에서 Kubernetes를 사용하더라도 AWS를 사용해야 합니다.
간편한 설정(EKS 사용)	중간	높음	Istio – EKS로 설정하려면 러닝커브가 요구되고 Istio에 대한 더 깊은 이해가 필요합니다.  App Mesh – EKS를 사용하면 특히 AWS 지원 및 통합으로 인해 설정이 쉽습니다.
관측 가능성	중간	높음	Istio – 요청 헤더를 추가하여 추적할 수 있습니다.  App Mesh – 추적을 활성화하려면 애플리케이션 코드를 업데이트해야 합니다.
쿠버네티스 지원	낮음	높음	Istio는 기본적으로 Kubernetes와 통합됩니다.
다중 클러스터 지원	높음	예	AWS App Mesh  –   다중 계정 설정에서 App Mesh를 사용 Istio  –  Istio 를 사용한 다중 클러스터 설정
가중 라우팅	예	예	A/B, 카나리아 배포 등에 유용합니다.
속도 제한	아니요	예	App Mesh 로드맵에 계획되어 있음
결함 관리	부분적	예	둘 다 시간 초과, 재시도 회로 차단기를 지원합니다. 그러나 Istio는 재시도, 상태 확인, 실패 주입 간의 가변 지터도 지원합니다. App Mesh는 재시도 구성에 대한 사용자 정의 오류 코드 사용을 허용하지 않으며 기본 정책만 적용합니다.
트래픽 미러링	아니요	예	Istio는 현재 트래픽 미러링을 허용하지만 App Mesh에는 현재 이 기능이 없습니다.
보안 - mTLS 및 인증	예	예	둘 다 mTLS를 지원합니다. 그러나 Istio는 자동 인증서 롤오버를 포함하여 mTLS 설정에 대해 보다 세분화된 제어를 제공합니다. 또한 Istio는 요청 인증을 허용하고 Auth0, Keycloak 등과 통합할 수 있습니다. App Mesh에는 AWS 워크로드 및 설정에 대한 장점인 IAM 통합이 있습니다.

 

기타 대안

Istio와 AWS App Mesh는 훌륭한 솔루션이지만 고려할 가치가 있는 다른 경쟁 기술이 있습니다.

• Linkerd  — Buoyant에서 만든 Rust 를 사용하여 만든 경량 서비스 메시 중 하나입니다. CNCF의 일부로 점진적 성숙도 수준에 도달했습니다.
• Open Service Mesh  — Microsoft에서 만든 Golang을 사용하여 구축된 경량 서비스 메시 중 하나입니다. CNCF의 일부인 샌드박스 프로젝트입니다.
• Consul  — Hasicorp 에서 구축했으며 서버 및 클라이언트 기능을 모두 제공하는 단일 바이너리를 제공합니다. 사이드카 패턴과 함께 Envoy 프록시를 사용합니다.
• Kuma  — Kong 이 개발한 Golang을 사용하여 구축된 Envoy 기반 서비스 메시이며 CNCF 샌드박스 프로젝트입니다.

 

결론

서비스 메시를 포함한 각 기술 선택은 고려 중인 시스템, 조직 성숙도, 아키텍처 성숙도, 개발자 기술 세트, 아키텍처 로드맵, 현재 조직 기술 환경과의 정렬, 보안 고려 사항 등 상황에 따라 다릅니다.

위의 요소를 고려할 때 아래 지침 원칙은 서비스 메시 선택 결정을 내리는 데 도움이 됩니다.

AWS App Mesh는 다음과 같은 시나리오에 더 적합합니다.

• 애플리케이션 아키텍처가 AWS 클라우드 네이티브 아키텍처를 활용하고 있으며 클라우드 서비스 간의 시너지 효과가 선호됩니다.
• 최소한의 운영 오버헤드가 없는 관리형 서비스 모델 이 선호됩니다.
• 세분화된 제어 는 필요성이 아닙니다.
• 엔지니어링 기술 은 서비스 메시에 대한 측면에서 제한적입니다.
• 공급업체 고정 은 관심 영역이 아니거나 오픈 소스 코드가 필요성이 아닙니다.
• 멀티 클라우드 서비스 메쉬 가 필요하지 않습니다 .

Istio Service Mesh는 다음과 같은 시나리오에 더 적합합니다.

• 애플리케이션 아키텍처 는 공통 메시 아키텍처를 기본 인프라 계층으로 활용하고 있습니다.
• 벤더 종속 이 선호되지 않으며 오픈 소스 가 핵심 우선 순위입니다.
• 멀티클라우드 아키텍처와 더 일치 하는 산업 표준 솔루션이 선호됩니다.
• 메쉬 네트워크, 정책, 구성, 설정 등 을 유연 하게 관리할 수 있는 세분화된 제어 가 필요합니다 .
• 엔지니어링 팀 은 서비스 메시 지식을 보유하고 있으며 필요한 경우 솔루션을 관리하거나 심지어 맞춤화하려고 합니다.

출처 : https://vedcraft.com/architecture/aws-appmesh-vs-istio-comparison-of-service-mesh/

AWS App Mesh vs. Istio: A Comparison Of Service Mesh - Vedcraft