헤이 하브르! 나는 기사의 번역을 당신의 관심에 제시합니다 "서비스 메시 데이터 플레인과 제어 플레인" 저자 매트 클라인.

이번에는 서비스 메시 구성 요소, 데이터 플레인 및 제어 플레인에 대한 설명을 "원하고 번역"했습니다. 이 설명은 나에게 가장 이해하기 쉽고 흥미로웠으며 가장 중요하게는 "전혀 필요한가?"라는 이해로 이어졌습니다.

지난 10년 동안 "서비스 메시"에 대한 아이디어가 점점 더 대중화되고(2017년 XNUMX월 XNUMX일 원문) 공간에 참여하는 사람이 늘어나면서 전체 전체의 혼란도 그에 비례하여 증가하는 것을 보았습니다. 다양한 솔루션을 비교하고 대조하는 방법에 관한 기술 커뮤니티입니다.

상황은 내가 XNUMX월에 쓴 다음 일련의 트윗에 가장 잘 요약되어 있습니다.

서비스 메시 혼란 #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. 그 중 어느 것도 Istio와 동일하지 않습니다. Istio는 완전히 다른 것입니다. 1 /

첫 번째는 단순히 데이터 평면입니다. 그 자체로는 아무것도 하지 않습니다. 그들은 뭔가 더 하고 싶은 마음이 있는 것 같습니다. 2/

Istio는 여러 부분을 하나로 묶는 제어 평면의 한 예입니다. 이것은 또 다른 레이어입니다. /끝

이전 트윗에서는 여러 가지 프로젝트(Linkerd, NGINX, HAProxy, Envoy 및 Istio)를 언급했지만 더 중요한 것은 데이터 플레인, 서비스 메시 및 제어 플레인의 일반적인 개념을 소개하는 것입니다. 이 게시물에서는 한 걸음 물러서서 "데이터 플레인"과 "제어 플레인"이라는 용어가 의미하는 바를 매우 높은 수준에서 설명한 다음 해당 용어가 트윗에서 언급된 프로젝트에 어떻게 적용되는지에 대해 이야기하겠습니다.

서비스 메시란 실제로 무엇입니까?

그림 1: 서비스 메시 개요

그림 1 가장 기본적인 수준에서 서비스 메시의 개념을 보여줍니다. XNUMX개의 서비스 클러스터(AD)가 있습니다. 각 서비스 인스턴스는 로컬 프록시 서버와 연결됩니다. 단일 애플리케이션 인스턴스의 모든 네트워크 트래픽(HTTP, REST, gRPC, Redis 등)은 로컬 프록시를 통해 적절한 외부 서비스 클러스터로 전달됩니다. 이런 방식으로 애플리케이션 인스턴스는 네트워크 전체를 인식하지 못하고 로컬 프록시만 인식합니다. 실제로 분산 시스템 네트워크가 서비스에서 제거되었습니다.

데이터 플레인

서비스 메시에서 애플리케이션을 위해 로컬에 위치한 프록시 서버는 다음 작업을 수행합니다.

• 서비스 발견. 귀하의 애플리케이션에 어떤 서비스/애플리케이션을 사용할 수 있나요?
• 건강검진. 서비스 검색에서 반환된 서비스 인스턴스가 정상이고 네트워크 트래픽을 받아들일 준비가 되어 있습니까? 여기에는 활성(예: 응답/상태 확인) 및 수동(예: 비정상 서비스 상태를 표시하는 3개의 연속 5xx 오류 사용) 상태 확인이 모두 포함될 수 있습니다.
• 라우팅. REST 서비스에서 "/foo"에 대한 요청을 받을 때 요청을 어느 서비스 클러스터로 보내야 합니까?
• 로드 밸런싱. 라우팅 중에 서비스 클러스터가 선택되면 요청을 어떤 서비스 인스턴스로 보내야 합니까? 시간 초과는 어떻게 되나요? 어떤 회로 차단 설정을 사용합니까? 요청이 실패하면 다시 시도해야 합니까?
• 인증 및 승인. 수신 요청의 경우 mTLS 또는 기타 메커니즘을 사용하여 호출 서비스를 암호화 방식으로 식별/인증할 수 있습니까? 인식/승인된 경우 서비스에서 요청된 작업(엔드포인트)을 호출할 수 있습니까? 아니면 인증되지 않은 응답을 반환해야 합니까?
• 관찰 가능성. 운영자가 분산 트래픽 흐름과 디버깅 문제가 발생할 때 이해할 수 있도록 각 요청에 대해 자세한 통계, 로그/로그 및 분산 추적 데이터를 생성해야 합니다.

데이터 플레인은 서비스 메시의 모든 이전 지점을 담당합니다. 실제로 서비스(사이드카)에 로컬인 프록시는 데이터 플레인입니다. 즉, 데이터 평면은 서비스와 주고받는 모든 네트워크 패킷을 조건부로 브로드캐스팅, 전달 및 모니터링하는 역할을 담당합니다.

제어 평면

로컬 프록시가 데이터 플레인에서 제공하는 네트워크 추상화는 마술적(?)입니다. 그러나 프록시는 서비스 B에 대한 "/foo" 경로를 실제로 어떻게 알 수 있습니까? 프록시 요청으로 채워진 서비스 검색 데이터를 어떻게 사용할 수 있나요? 로드 밸런싱, 타임아웃, 회로 차단 등에 대한 매개변수는 어떻게 구성됩니까? 블루/그린 방법 또는 정상적인 트래픽 전환 방법을 사용하여 애플리케이션을 어떻게 배포합니까? 시스템 전체 인증 및 권한 부여 설정은 누가 구성합니까?

위의 모든 항목은 서비스 메시의 제어 평면의 제어를 받습니다. 제어 평면은 격리된 상태 비저장 프록시 세트를 가져와 이를 분산 시스템으로 전환합니다..

많은 기술자들이 데이터 플레인과 제어 플레인의 별도 개념을 혼란스럽게 생각하는 이유는 대부분의 사람들에게 데이터 플레인은 익숙하지만 제어 플레인은 낯설거나 이해하지 못하기 때문이라고 생각합니다. 우리는 오랫동안 물리적 네트워크 라우터와 스위치를 사용해 왔습니다. 우리는 패킷/요청이 A 지점에서 B 지점으로 이동해야 하며 이를 위해 하드웨어와 소프트웨어를 사용할 수 있다는 것을 알고 있습니다. 차세대 소프트웨어 프록시는 우리가 오랫동안 사용해 온 도구의 단순한 버전입니다.

그림 2: 인간 제어 영역

그러나 대부분의 네트워크 운영자가 시스템의 이 부분을 기술 구성 요소와 연결하지 않을 수도 있지만 우리는 오랫동안 제어 평면을 사용해 왔습니다. 이유는 간단합니다.
오늘날 사용되는 대부분의 제어 평면은 다음과 같습니다..

에 그림 2 제가 "인간 제어 평면"이라고 부르는 것을 보여줍니다. 여전히 매우 일반적인 이러한 유형의 배포에서는 아마도 심술궂은 인간 운영자가 잠재적으로 스크립트를 통해 정적 구성을 생성하고 일부 특수 프로세스를 통해 모든 프록시에 배포합니다. 그런 다음 프록시는 이 구성을 사용하기 시작하고 업데이트된 설정을 사용하여 데이터 평면 처리를 시작합니다.

그림 3: 고급 서비스 메시 제어 평면

에 그림 3 서비스 메시의 '확장된' 제어 평면을 보여줍니다. 이는 다음과 같은 부분으로 구성됩니다.

• 인간: 전체 시스템에 관해 높은 수준의 결정을 내리는 사람(화가 덜 났으면 좋겠음)이 여전히 있습니다.
• 제어 영역 UI: 사람은 시스템을 제어하기 위해 일종의 사용자 인터페이스와 상호 작용합니다. 이는 웹 포털, 명령줄 애플리케이션(CLI) 또는 기타 인터페이스일 수 있습니다. 사용자 인터페이스를 사용하여 운영자는 다음과 같은 전역 시스템 구성 매개변수에 액세스할 수 있습니다.
  • 배포 제어, 블루/그린 및/또는 점진적인 트래픽 전환
  • 인증 및 권한 부여 옵션
  • 라우팅 테이블 사양(예: 애플리케이션 A가 "/foo"에 대한 정보를 요청할 때 발생하는 일)
  • 시간 초과, 재시도, 회로 차단 설정 등과 같은 로드 밸런서 설정
• 워크로드 스케줄러: 서비스는 Kubernetes 또는 Nomad와 같은 일정 유형의 예약/조정 시스템을 통해 인프라에서 실행됩니다. 스케줄러는 로컬 프록시와 함께 서비스를 로드하는 일을 담당합니다.
• 서비스 발견. 스케줄러는 서비스 인스턴스를 시작하고 중지할 때 상태를 서비스 검색 시스템에 보고합니다.
• 사이드카 프록시 구성 API : 로컬 프록시는 운영자 개입 없이 최종적으로 일관된 모델을 사용하여 다양한 시스템 구성 요소에서 상태를 동적으로 추출합니다. 현재 실행 중인 모든 서비스 인스턴스와 로컬 프록시 서버로 구성된 전체 시스템은 궁극적으로 하나의 생태계로 통합됩니다. Envoy의 범용 데이터 플레인 API는 이것이 실제로 어떻게 작동하는지 보여주는 한 예입니다.

기본적으로 제어 플레인의 목적은 데이터 플레인에서 궁극적으로 허용되는 정책을 설정하는 것입니다. 더 발전된 제어 평면은 일부 시스템의 더 많은 부분을 운영자로부터 제거하고 올바르게 작동한다면 수동 조작이 덜 필요합니다!...

데이터 플레인과 컨트롤 플레인. 데이터 플레인과 제어 플레인 요약

• 서비스 메시 데이터 영역: 시스템의 모든 패킷/요청에 영향을 줍니다. 애플리케이션/서비스 검색, 상태 확인, 라우팅, 로드 밸런싱, 인증/권한 부여 및 관찰 가능성을 담당합니다.
• 서비스 메시 제어 영역: 서비스 네트워크 내에서 실행 중인 모든 데이터 플레인에 대한 정책 및 구성을 제공합니다. 시스템의 패키지/요청을 건드리지 않습니다. 제어 평면은 모든 데이터 평면을 분산 시스템으로 전환합니다.

현재 프로젝트 환경

위의 설명을 이해했다면, 서비스 메시 프로젝트의 현재 상태를 살펴보겠습니다.

• 데이터 플레인: 링커드, NGINX, HAProxy, Envoy, Traefik
• 제어 평면: Istio, Nelson, 스마트스택

위의 각 솔루션에 대한 심층 분석보다는 현재 생태계에 많은 혼란을 야기하고 있다고 생각되는 몇 가지 사항에 대해 간략하게 설명하겠습니다.

Linkerd는 2016년 초에 서비스 메시를 위한 최초의 데이터 플레인 프록시 서버 중 하나였으며 서비스 메시 디자인 모델에 대한 인식과 관심을 높이는 환상적인 작업을 수행했습니다. 그로부터 약 6개월 후 Envoy는 Linkerd에 합류했습니다(그는 2015년 말부터 Lyft에 있었지만). Linkerd와 Envoy는 서비스 메시를 논의할 때 가장 자주 언급되는 두 가지 프로젝트입니다.

Istio는 2017년 XNUMX월에 발표되었습니다. Istio 프로젝트의 목표는 다음에 표시된 확장된 제어 평면과 매우 유사합니다. 그림 3. Istio용 Envoy가 기본 프록시입니다. 따라서 Istio는 제어 평면이고 Envoy는 데이터 평면입니다. 짧은 시간 안에 Istio는 많은 관심을 불러일으켰고 다른 데이터 플레인은 Envoy를 대체하기 위해 통합되기 시작했습니다(Linkerd와 NGINX 모두 Istio와의 통합을 시연했습니다). 동일한 제어 평면 내에서 서로 다른 데이터 평면을 사용할 수 있다는 사실은 제어 평면과 데이터 평면이 반드시 긴밀하게 결합될 필요는 없음을 의미합니다. Envoy의 일반 데이터 플레인 API와 같은 API는 시스템의 두 부분 사이에 브리지를 형성할 수 있습니다.

Nelson과 SmartStack은 컨트롤 플레인과 데이터 플레인의 분리를 더욱 자세히 설명하는 데 도움이 됩니다. Nelson은 Envoy를 프록시로 사용하고 HashiCorp 스택을 기반으로 서비스 메시를 위한 안정적인 제어 평면을 구축합니다. 노마드 등 SmartStack은 아마도 새로운 서비스 메시의 첫 번째 물결이었을 것입니다. SmartStack은 HAProxy 또는 NGINX를 중심으로 제어 평면을 구축하여 데이터 평면의 서비스 메시에서 제어 평면을 분리하는 기능을 보여줍니다.

서비스 메시를 갖춘 마이크로서비스 아키텍처가 점점 더 많은 주목을 받고 있으며(맞습니다!) 점점 더 많은 프로젝트와 공급업체가 이 방향으로 작업하기 시작하고 있습니다. 향후 몇 년 동안 데이터 플레인과 제어 플레인 모두에서 많은 혁신이 이루어지고 다양한 구성 요소가 추가로 혼합되는 것을 보게 될 것입니다. 궁극적으로 마이크로서비스 아키텍처는 운영자에게 더욱 투명하고 마법(?)이 되어야 합니다.
짜증이 점점 줄어들기를 바랍니다.

주요 시사점

• 서비스 메시는 데이터 플레인과 제어 플레인이라는 두 가지 부분으로 구성됩니다. 두 구성 요소가 모두 필요하며, 구성 요소가 없으면 시스템이 작동하지 않습니다.
• 모두가 제어 평면에 대해 잘 알고 있으며, 이 시점에서 제어 평면은 바로 여러분이 될 수 있습니다!
• 모든 데이터 플레인은 기능, 성능, 구성 가능성 및 확장성 측면에서 서로 경쟁합니다.
• 모든 제어 평면은 기능, 구성 가능성, 확장성 및 사용 편의성 측면에서 서로 경쟁합니다.
• 하나의 제어 평면에는 올바른 추상화 및 API가 포함될 수 있으므로 여러 데이터 평면을 사용할 수 있습니다.

출처 : habr.com