Istio 이상 : Azure의 서비스 메시 인터페이스

현대적인 클라우드 우선 애플리케이션 개발 (최소한 Azure에서)은 거의 Kubernetes에 의존하게되었습니다. Virtual Kubelets, AKS (Azure Kubernetes Service) 및 Azure Service Fabric Mesh와 같은 기술은 컨테이너를 사용하여 마이크로 서비스를 배포하고 관리하여 Azure에서 확장 가능한 분산 애플리케이션을 구축하는 데 핵심적인 요소입니다.

Azure의 Kubernetes 도구를 살펴보면 Microsoft가 오픈 소스 프레임 워크의 모든 측면에서 작업하면서 Cloud Native Computing Foundation과 관련하여 많은 작업을 수행하고 있음이 분명합니다. 우리는 놀라지 말아야합니다. Microsoft는 Kubernetes 프로젝트의 창립자 중 한 명을 고용 한 다음 중요한 공급 업체 인 Deis를 인수했습니다. Deis 팀은 Kubernetes 에코 시스템에 대한 최신 Azure 기여 중 하나 인 SMI (Service Mesh Interface)를 지원합니다.

서비스 메시 소개

먼저 서비스 메시가 무엇이며 Kubernetes 기반 애플리케이션에서 중요한 이유를 먼저 설명하는 것이 가장 좋습니다.

현대 IT 아키텍처는 모두 추상화에 관한 것입니다. 클라우드 서비스를 사용하면 더 이상 기본 하드웨어에 대해 생각할 필요가 없습니다. IaaS를 사용하는 경우 코드를 호스팅 할 가상 머신을 정의합니다. PaaS를 사용하면 우리가 선택한 서비스와 API를 사용하여 애플리케이션과 예산에 적합한 성능 수준을 선택하여 하드웨어에서 훨씬 더 멀리 떨어져 있습니다. Kubernetes와 같은 컨테이너 기반 아키텍처를 사용하면 두 가지 사이 어딘가에 있습니다. AKS와 같은 서비스를 사용하여 기본 가상 머신을 정의한 다음 컨테이너 포드를 호스팅하고 컴퓨팅 및 메모리의 변경에 따라 확장 할 수 있습니다. 이제 KEDA (Kubernetes 기반 이벤트 기반 자동 확장)를 통해 이벤트 수신시).

그것은 추상화의 한 측면 일뿐입니다. Kubernetes 마이크로 서비스는 본질적으로 상태 비 저장입니다. 그들은 외부 저장소를 사용하고 물리적 또는 가상 네트워크 위에 위치합니다. 가장 까다로운 것은 Kubernetes 실행의 네트워크 측면입니다. 서비스가 확장되고 축소되면 애플리케이션의 변경 사항에 맞게 네트워크를 수정해야합니다. 하지만 애플리케이션 프런트 엔드와 백 엔드가 서로 다른 속도로 확장 될 수있을 때 서비스 연결을 어떻게 유지합니까?

이것이 바로 서비스 메시가 들어오는 곳입니다. 현대적인 소프트웨어 정의 네트워크의 기능을 활용하여 기본 네트워크에서 코드를 분리하는 새로운 추상화 계층입니다. 서비스 메시는 코드와 함께 배포되는 네트워크 프록시 세트로 작동하여 코드가 기본 네트워크를 인식 할 필요없이 서비스 간 통신을 관리합니다. 서비스 메시를 애플리케이션의 네트워킹을위한 자동화 된 제어 영역으로 생각할 수 있으며 Kubernetes가 코드를 확장 및 축소 할 때 기본 제어 영역을 관리 할 수 ​​있습니다.

마이크로 서비스를위한 소프트웨어 정의 네트워크

서비스 검색과 함께 지연을 인식하고 확장 가능한 스마트로드 밸런싱을 구현하는 방법으로 가장 잘 생각할 수있는 서비스 메시는 기본적으로 Kubernetes 배포의 일부로 관리되는 동적 라우팅 규칙이있는 분산 라우터입니다. 추가 규칙을 정의 할 수 있습니다. 예를 들어 프로덕션 및 테스트 시스템을 별도로 유지하거나 새 릴리스 배포 및 컨테이너 버전 간의 변경을 처리합니다. 애플리케이션의 각 포드에는 서비스 검색 및 기타 상태 저장 요소가 서비스 외부에서 실행되는 사이드카로 실행되는 서비스 메시 인스턴스가 있습니다.

서비스 메시를 사용하면 인텔리전스를 새로운 네트워크 계층으로 푸시하므로이를 마이크로 서비스에 넣을 필요가 없습니다. 연결을 암호화해야합니까? 이것이 바로 서비스 메시의 일입니다. 클라이언트를 승인해야합니까? 서비스 메시에 대한 또 다른 작업입니다.

메시가 너무 많음

Kubernetes 배포를 서비스 메시와 결합하는 것은 많은 의미가 있습니다. 그러나 한 가지 더 큰 문제가 있습니다. 어떤 것을 사용합니까? 사절? 이스 티오? 링커 드? 아스펜 메시? 하나를 선택한 경우 비즈니스의 다른 부분에있는 개발 팀이 다른 부분을 선택하지 못하게하려면 어떻게해야합니까? 그렇다면 회사가 특정 플랫폼에서 표준화하기로 결정하면 어떻게됩니까?

이것이 바로 Microsoft가 Service Mesh Interface로 해결하기 위해 설정 한 문제입니다. 각 서비스 메시에 고유 한 API 세트가있는 대신 SMI는 서로 다른 서비스 메시에서 작동하는 공통 API를 구현하여 새로운 스마트 네트워크를 관리하는 방법입니다. 코드를 특정 서비스 메시 및 해당 API에 고정하는 대신 공통 API를 통해 가장 일반적인 사용 사례를 처리하는 코드를 작성할 수 있습니다. 서비스 메시를 교체해야하는 경우 (제공자를 변경하거나 더 잘 작동하는 것을 찾은 경우) 서비스 메시가 SMI를 구현하는 한 코드를 변경할 필요가 없습니다. 서비스 메시 사이드카를 변경하고 코드를 재배포하기 만하면됩니다.

SMI : 공통 서비스 메시 API

Hashicorp 및 Buoyant와 같은 Kubernetes 생태계 회사와 협력하여 Microsoft는 고객의 일반적인 요청을 지원하는 SMI의 주요 기능을 정의했습니다. 초기 릴리스에서는 트래픽 정책, 트래픽 원격 측정 및 트래픽 관리의 세 가지 영역에 중점을 두었습니다. 이 세 가지 영역은 대부분의 서비스 메시에 의해 제어되며 기본 애플리케이션을 변경하지 않고도 쉽게 구현할 수있는 사양을 만드는 것입니다.

SMI를 표준 API 집합으로 만들면 서비스 메시 공급 업체가 지정된 범위를 벗어난 자체 API 또는 추가 기능을 계속 제공하는 것을 막을 수 없습니다. 또는 변경할 필요가 없습니다. 제 3자는 SMI API와 독점 서비스 API 사이에있는 번역 계층을 구축 할 수 있습니다. SMI API는 확장 API 서버 및 사용자 지정 리소스 정의로 구현되므로 새 버전의 Kubernetes도 필요하지 않습니다. 기존 관리 도구를 사용하여 모든 클러스터에 설치할 수 있습니다. 따라서 Azure 및 기타 클라우드 호스팅 Kubernetes 서비스가 SMI를 기존 관리 Kubernetes 서비스에 쉽게 구축 할 수 있습니다.

Linkerd를 사용하든, Aspen Mesh를 사용하든, VMware의 NSX Service Mesh를 사용하든 상관없이 SMI를 사용하면 선호하는 것을 선택하여 코드 이동성을 개선하고 특정 클라우드 서비스에 대한 종속을 피할 수 있습니다. 그러면 코드에 영향을주지 않고 서비스 메시를 전환 할 수 있습니다. 새 서비스 메시가 더 나은 성능을 제공하는 경우 새 메시를 사용하도록 빌드 파이프 라인을 변경 한 다음 업데이트 된 애플리케이션을 배포하기 만하면됩니다.

Microsoft가 이와 같은 프로젝트를 주도하여 Kubernetes 커뮤니티의 광범위한 섹션과 협력하는 것을 보는 것은 흥미 롭습니다. 서비스 메시 구축에 명시 적으로 초점을 맞추지 않은 접근 방식을 취함으로써 Azure는 AKS 구성의 일부로 다양한 서비스 메시를 제공 할 수 있으므로 코드를 변경할 필요없이 원하는 도구를 선택할 수 있습니다.