인터넷에서 말뚝 조항 о 서비스 메시 (서비스 메시) 그리고 여기에 또 다른 것이 있습니다. 만세! 그런데 왜? 그렇다면 도커, 쿠버네티스 등 컨테이너 플랫폼이 등장하기 전인 10년 전에 서비스 메시가 등장했다면 더 좋았을 것이라는 의견을 피력하고 싶다. 내 관점이 다른 관점보다 좋다 나쁘다를 말하는 것은 아니지만, 서비스 메시는 상당히 복잡한 동물이기 때문에 다양한 관점이 서비스 메시를 더 잘 이해하는 데 도움이 될 것입니다.

저는 XNUMX개가 넘는 마이크로서비스를 기반으로 구축되고 수천 개의 컨테이너화된 애플리케이션을 지원하는 dotCloud 플랫폼에 대해 이야기하겠습니다. 이를 개발하고 출시하는 과정에서 직면한 과제와 서비스 메시가 어떻게 도움이 될 수 있는지(또는 도움이 될 수 없는지) 설명하겠습니다.

닷클라우드의 역사

나는 dotCloud의 역사와 이 플랫폼의 아키텍처 선택에 대해 글을 썼지만 네트워크 계층에 대해서는 많이 이야기하지 않았습니다. 독서에 빠져들고 싶지 않다면 마지막 기사 dotCloud에 대한 요점은 간단히 말해서 고객이 광범위한 데이터를 지원하여 광범위한 애플리케이션(Java, PHP, Python...)을 실행할 수 있도록 하는 서비스형 PaaS 플랫폼입니다. 서비스(MongoDB, MySQL, Redis...) 및 Heroku와 같은 워크플로: 플랫폼에 코드를 업로드하면 플랫폼이 컨테이너 이미지를 구축하고 배포합니다.

dotCloud 플랫폼으로 트래픽이 어떻게 전달되었는지 알려드리겠습니다. 특별히 멋졌기 때문이 아니라(비록 시스템이 그 당시에는 잘 작동했음에도 불구하고), 주로 최신 도구를 사용하면 무리 간에 트래픽을 라우팅하는 방법이 필요한 경우 겸손한 팀이 짧은 시간 내에 이러한 디자인을 쉽게 구현할 수 있기 때문입니다. 마이크로서비스 또는 여러 애플리케이션. 이렇게 하면 옵션을 비교할 수 있습니다. 모든 것을 직접 개발하거나 기존 서비스 메시를 사용하면 어떻게 될까요? 표준 선택은 직접 만들거나 구입하는 것입니다.

호스팅된 애플리케이션에 대한 트래픽 라우팅

dotCloud의 애플리케이션은 HTTP 및 TCP 엔드포인트를 노출할 수 있습니다.

HTTP 엔드포인트 로드 밸런서 클러스터 구성에 동적으로 추가됨 힙통. 이는 오늘날 리소스가 수행하는 작업과 유사합니다. 입구 Kubernetes 및 다음과 같은 로드 밸런서에서 트라에픽.

도메인 이름이 dotCloud 로드 밸런서를 가리키는 경우 클라이언트는 적절한 도메인을 통해 HTTP 엔드포인트에 연결됩니다. 특별한 것은 없습니다.

TCP 엔드포인트 포트 번호와 연결되어 환경 변수를 통해 해당 스택의 모든 컨테이너에 전달됩니다.

클라이언트는 적절한 호스트 이름(gateway-X.dotcloud.com 등)과 포트 번호를 사용하여 TCP 엔드포인트에 연결할 수 있습니다.

이 호스트 이름은 "nats" 서버 클러스터로 확인됩니다(다음과 관련 없음). NAT), 이는 들어오는 TCP 연결을 올바른 컨테이너(또는 부하 분산 서비스의 경우 올바른 컨테이너)로 라우팅합니다.

Kubernetes에 익숙하다면 아마도 서비스가 생각날 것입니다. 노드포트.

dotCloud 플랫폼에는 이에 상응하는 서비스가 없었습니다. 클러스터IP: 단순화를 위해 플랫폼 내부와 외부에서 동일한 방식으로 서비스에 액세스했습니다.

모든 것이 매우 간단하게 구성되었습니다. HTTP 및 TCP 라우팅 네트워크의 초기 구현은 아마도 각각 수백 줄의 Python에 불과했을 것입니다. 플랫폼이 성장하고 추가 요구 사항이 나타나면서 개선된 간단한(순진하다고 말하고 싶습니다) 알고리즘입니다.

기존 코드에 대한 광범위한 리팩토링이 필요하지 않았습니다. 특히, 12팩터 앱 환경변수를 통해 얻은 주소를 직접 사용할 수 있습니다.

이것이 최신 서비스 메시와 어떻게 다릅니까?

제한된 시계. TCP 라우팅 메시에 대한 측정항목이 전혀 없었습니다. HTTP 라우팅의 경우 이후 버전에서는 오류 코드 및 응답 시간이 포함된 자세한 HTTP 측정항목을 도입했지만 최신 서비스 메시는 더 나아가 Prometheus와 같은 측정항목 수집 시스템과의 통합을 제공합니다.

가시성은 운영 관점(문제 해결을 돕기 위해)뿐만 아니라 새로운 기능을 출시할 때에도 중요합니다. 안전에 관한 것입니다 청록색 배포 и 카나리아 배포.

라우팅 효율성 또한 제한되어 있습니다. dotCloud 라우팅 메시에서 모든 트래픽은 전용 라우팅 노드 클러스터를 통과해야 했습니다. 이는 잠재적으로 여러 AZ(가용성 영역) 경계를 넘어 대기 시간이 크게 증가한다는 것을 의미했습니다. 페이지당 XNUMX개가 넘는 SQL 쿼리를 작성하고 각 쿼리에 대해 SQL 서버에 대한 새로운 연결을 여는 문제 해결 코드가 기억납니다. 로컬로 실행하면 페이지가 즉시 로드되지만 dotCloud에서는 각 TCP 연결(및 후속 SQL 쿼리)에 수십 밀리초가 걸리기 때문에 로드하는 데 몇 초가 걸립니다. 이 특별한 경우에는 지속적인 연결로 문제가 해결되었습니다.

최신 서비스 메시는 이러한 문제를 더 잘 처리합니다. 우선 연결이 라우팅되었는지 확인합니다. 소스에서. 논리적 흐름은 동일합니다. клиент → меш → сервис하지만 이제 메시는 원격 노드가 아닌 로컬로 작동하므로 연결이 клиент → меш 로컬이며 매우 빠릅니다(밀리초가 아닌 마이크로초).

최신 서비스 메시는 더욱 스마트한 로드 밸런싱 알고리즘도 구현합니다. 백엔드 상태를 모니터링하면 더 빠른 백엔드로 더 많은 트래픽을 보낼 수 있어 전반적인 성능이 향상됩니다.

Безопасность 그것도 더 좋아. dotCloud 라우팅 메시는 전적으로 EC2 Classic에서 실행되었으며 트래픽을 암호화하지 않았습니다(누군가 EC2 네트워크 트래픽에 스니퍼를 설치했다면 이미 큰 문제에 봉착했다는 가정하에). 최신 서비스 메시는 상호 TLS 인증 및 후속 암호화 등을 통해 모든 트래픽을 투명하게 보호합니다.

플랫폼 서비스에 대한 라우팅 트래픽

좋아요, 애플리케이션 간의 트래픽에 대해 논의했습니다. 그런데 dotCloud 플랫폼 자체는 어떻습니까?

플랫폼 자체는 다양한 기능을 담당하는 약 XNUMX개의 마이크로서비스로 구성되었습니다. 일부는 다른 사람의 요청을 수락했고 일부는 다른 서비스에 연결했지만 연결 자체를 수락하지 않은 백그라운드 작업자였습니다. 어떤 경우든 각 서비스는 연결해야 하는 주소의 끝점을 알아야 합니다.

많은 상위 수준 서비스는 위에서 설명한 라우팅 메시를 사용할 수 있습니다. 실제로 dotCloud의 XNUMX개가 넘는 마이크로서비스 중 상당수가 dotCloud 플랫폼 자체에 일반 애플리케이션으로 배포되었습니다. 그러나 소수의 낮은 수준 서비스(특히 이 라우팅 메시를 구현하는 서비스)에는 더 간단하고 종속성이 적은 서비스가 필요했습니다(그들은 작동하기 위해 스스로 의존할 수 없었기 때문에 - 오래된 닭고기와 달걀 문제).

이러한 낮은 수준의 미션 크리티컬 서비스는 몇 개의 주요 노드에서 직접 컨테이너를 실행하여 배포되었습니다. 이 경우 링커, 스케줄러, 러너 등 표준 플랫폼 서비스는 사용되지 않았습니다. 최신 컨테이너 플랫폼과 비교하고 싶다면 다음을 사용하여 제어 평면을 실행하는 것과 같습니다. docker run 작업을 Kubernetes에 위임하는 대신 노드에서 직접 수행합니다. 컨셉이랑 꽤 비슷하네요 정적 모듈(포드), 그것이 사용하는 kubeadm 또는 부트큐브 독립형 클러스터를 부팅할 때.

이러한 서비스는 간단하고 조악한 방식으로 노출되었습니다. YAML 파일에는 해당 이름과 주소가 나열되어 있습니다. 각 클라이언트는 배포를 위해 이 YAML 파일의 복사본을 가져와야 했습니다.

한편으로는 Zookeeper와 같은 외부 키/값 저장소의 지원이 필요하지 않기 때문에 매우 안정적입니다(기억하세요, 당시에는 etcd나 Consul이 존재하지 않았습니다). 반면에 서비스 이동을 어렵게 만들었습니다. 이동이 이루어질 때마다 모든 클라이언트는 업데이트된 YAML 파일을 수신하게 됩니다(그리고 재부팅될 수도 있음). 별로 편하지 않아요!

그 후, 우리는 각 클라이언트가 로컬 프록시 서버에 연결되는 새로운 체계를 구현하기 시작했습니다. 주소와 포트 대신 서비스의 포트 번호만 알고 다음을 통해 연결하면 됩니다. localhost. 로컬 프록시는 이 연결을 처리하고 이를 실제 서버로 전달합니다. 이제 백엔드를 다른 머신으로 이동하거나 확장할 때 모든 클라이언트를 업데이트하는 대신 이러한 모든 로컬 프록시만 업데이트하면 됩니다. 재부팅이 더 이상 필요하지 않습니다.

(또한 TLS 연결에서 트래픽을 캡슐화하고 수신측에 다른 프록시 서버를 배치할 뿐만 아니라 수신 서비스의 참여 없이 TLS 인증서를 확인할 계획이었습니다. localhost. 이에 대해서는 나중에 자세히 설명합니다.)

이는 다음과 매우 유사합니다. 스마트스택 Airbnb에서 가져온 것이지만 중요한 차이점은 SmartStack이 구현되어 프로덕션에 배포되는 반면 dotCloud의 내부 라우팅 시스템은 dotCloud가 Docker가 되면서 보류되었다는 점입니다.

저는 개인적으로 SmartStack이 Istio, Linkerd 및 Consul Connect와 같은 시스템의 전신 중 하나로 생각합니다. 왜냐하면 모두 동일한 패턴을 따르기 때문입니다.

• 각 노드에서 프록시를 실행합니다.
• 클라이언트가 프록시에 연결됩니다.
• 제어 영역은 백엔드가 변경되면 프록시 구성을 업데이트합니다.
• ... 이익!

서비스 메시의 최신 구현

오늘날 유사한 그리드를 구현해야 한다면 유사한 원칙을 사용할 수 있습니다. 예를 들어 서비스 이름을 공간의 주소에 매핑하여 내부 DNS 영역을 구성합니다. 127.0.0.0/8. 그런 다음 클러스터의 각 노드에서 HAProxy를 실행하고 각 서비스 주소(해당 서브넷의)에서 연결을 수락합니다. 127.0.0.0/8) 적절한 백엔드로 부하를 리디렉션/균형 조정합니다. HAProxy 구성을 제어할 수 있습니다. 신뢰, etcd 또는 Consul에 백엔드 정보를 저장하고 필요할 때 업데이트된 구성을 HAProxy에 자동으로 푸시할 수 있습니다.

이것이 바로 Istio의 작동 방식입니다! 하지만 몇 가지 차이점이 있습니다.

• 용도 특사 프록시 HAProxy 대신.
• etcd 또는 Consul 대신 Kubernetes API를 통해 백엔드 구성을 저장합니다.
• 서비스에는 127.0.0.0/8 대신 내부 서브넷(Kubernetes ClusterIP 주소)에 주소가 할당됩니다.
• 클라이언트와 서버 간에 상호 TLS 인증을 추가하는 추가 구성 요소(Citadel)가 있습니다.
• 회로 차단, 분산 추적, 카나리아 배포 등과 같은 새로운 기능을 지원합니다.

몇 가지 차이점을 간단히 살펴보겠습니다.

특사 프록시

Envoy Proxy는 Lyft(택시 시장에서 Uber의 경쟁자)가 작성했습니다. 레인]. 다른 프록시(예: HAProxy, Nginx, Traefik...)와 여러 면에서 유사하지만 Lyft는 다른 프록시에 없는 기능이 필요했기 때문에 프록시를 작성했으며 기존 프록시를 확장하는 것보다 새 프록시를 만드는 것이 더 똑똑해 보였습니다.

Envoy는 단독으로 사용될 수 있습니다. 다른 서비스에 연결해야 하는 특정 서비스가 있는 경우 이를 Envoy에 연결하도록 구성한 다음 다른 서비스의 위치로 Envoy를 동적으로 구성 및 재구성하는 동시에 가시성과 같은 다양한 추가 기능을 얻을 수 있습니다. 사용자 정의 클라이언트 라이브러리를 사용하거나 호출 추적을 코드에 삽입하는 대신 Envoy로 트래픽을 보내고 Envoy가 측정항목을 수집합니다.

그러나 Envoy는 다음과 같은 작업도 수행할 수 있습니다. 데이터 평면 (데이터 평면) 서비스 메시용. 이는 이제 Envoy가 이 서비스 메시에 대해 구성되었음을 의미합니다. 제어 평면 (제어 평면).

제어 영역

제어 영역의 경우 Istio는 Kubernetes API를 사용합니다. 이는 confd를 사용하는 것과 크게 다르지 않습니다., 이는 etcd 또는 Consul을 사용하여 데이터 저장소의 키 세트를 봅니다. Istio는 Kubernetes API를 사용하여 Kubernetes 리소스 세트를 봅니다.

이 사이에: 개인적으로 이 내용이 유용하다고 생각합니다. 쿠버네티스 API 설명내용은 다음과 같습니다:

Kubernetes API 서버는 API 리소스에 대한 저장, 버전 관리, 검증, 업데이트 및 의미 체계를 제공하는 "멍청한 서버"입니다.

Istio는 Kubernetes와 함께 작동하도록 설계되었습니다. Kubernetes 외부에서 사용하려면 Kubernetes API 서버(및 etcd 도우미 서비스)의 인스턴스를 실행해야 합니다.

서비스 주소

Istio는 Kubernetes가 할당하는 ClusterIP 주소를 사용하므로 Istio 서비스는 내부 주소(범위에 속하지 않음)를 받습니다. 127.0.0.0/8).

Istio가 없는 Kubernetes 클러스터의 특정 서비스에 대한 ClusterIP 주소에 대한 트래픽은 kube-proxy에 의해 가로채어 해당 프록시의 백엔드로 전송됩니다. 기술적인 세부 사항에 관심이 있다면 kube-proxy는 iptables 규칙(또는 구성 방법에 따라 IPVS 로드 밸런서)을 설정하여 ClusterIP 주소로 가는 연결의 대상 IP 주소를 다시 씁니다.

Istio가 Kubernetes 클러스터에 설치되면 컨테이너를 도입하여 특정 소비자 또는 전체 네임스페이스에 대해 명시적으로 활성화될 때까지 아무 것도 변경되지 않습니다. sidecar 사용자 정의 포드에 넣습니다. 이 컨테이너는 Envoy 인스턴스를 가동하고 다른 서비스로 이동하는 트래픽을 가로채서 해당 트래픽을 Envoy로 리디렉션하는 iptables 규칙 집합을 설정합니다.

Kubernetes DNS와 통합되면 이는 우리 코드가 서비스 이름으로 연결될 수 있고 모든 것이 "제대로 작동"할 수 있음을 의미합니다. 즉, 우리 코드는 다음과 같은 쿼리를 발행합니다. http://api/v1/users/4242다음 api 요청 해결 10.97.105.48, iptables 규칙은 10.97.105.48의 연결을 가로채서 로컬 Envoy 프록시로 전달하고 해당 로컬 프록시는 요청을 실제 백엔드 API로 전달합니다. 휴!

추가 프릴

Istio는 또한 mTLS(상호 TLS)를 통해 엔드투엔드 암호화 및 인증을 제공합니다. 라는 구성 요소 성.

구성품도 있어요 믹서Envoy가 요청할 수 있는 각 헤더, 백엔드 로드 등과 같은 다양한 요인에 따라 해당 요청에 대해 특별한 결정을 내리도록 요청합니다. (걱정하지 마세요. Mixer를 계속 실행하는 방법은 다양하며, 충돌이 발생하더라도 Envoy는 계속 작동합니다. 프록시로 사용 가능).

물론 가시성에 대해서도 언급했습니다. Envoy는 분산 추적을 제공하는 동시에 엄청난 양의 측정항목을 수집합니다. 마이크로서비스 아키텍처에서 단일 API 요청이 마이크로서비스 A, B, C 및 D를 통과해야 하는 경우 로그인 시 분산 추적은 요청에 고유 식별자를 추가하고 하위 요청을 통해 이러한 모든 마이크로서비스에 대한 이 식별자를 저장합니다. 캡처할 모든 관련 통화, 지연 등

개발 또는 구매

Istio는 복잡하다는 평판을 갖고 있습니다. 대조적으로, 이 게시물의 시작 부분에서 설명한 라우팅 메시를 구축하는 것은 기존 도구를 사용하여 비교적 간단합니다. 그렇다면 대신 자체 서비스 메시를 만드는 것이 합리적일까요?

적당한 요구사항(가시성, 회로 차단기 및 기타 세부 사항이 필요하지 않음)이 있는 경우 자체 도구를 개발해야 한다는 생각이 듭니다. 그러나 Kubernetes를 사용하는 경우 Kubernetes가 이미 서비스 검색 및 로드 밸런싱을 위한 기본 도구를 제공하므로 필요하지 않을 수도 있습니다.

그러나 고급 요구 사항이 있는 경우 서비스 메시를 "구매"하는 것이 훨씬 더 나은 선택인 것 같습니다. (Istio는 오픈 소스이기 때문에 항상 "구매"하는 것은 아니지만 이를 이해하고 배포하고 관리하려면 여전히 엔지니어링 시간을 투자해야 합니다.)

Istio, Linkerd 또는 Consul Connect를 선택해야 합니까?

지금까지 우리는 Istio에 대해서만 이야기했지만 이것이 유일한 서비스 메시는 아닙니다. 인기 있는 대안 - 링커드, 그리고 더 많은 것이 있습니다 영사 연결.

무엇을 선택?

솔직히 모르겠어요. 현재 나는 내 자신이 이 질문에 답할 만큼 유능하다고 생각하지 않습니다. 몇 가지가 있습니다 재미있는 조항 이러한 도구를 비교하고 심지어 벤치마크.

한 가지 유망한 접근 방식은 다음과 같은 도구를 사용하는 것입니다. 슈퍼글루. 서비스 메시에 의해 노출된 API를 단순화하고 통합하기 위해 추상화 계층을 구현합니다. 다양한 서비스 메시의 특정(그리고 내 생각에는 상대적으로 복잡한) API를 배우는 대신 SuperGloo의 더 간단한 구성을 사용할 수 있으며, 마치 HTTP 인터페이스와 백엔드 기능을 설명하는 중간 구성 형식이 있는 것처럼 서로 쉽게 전환할 수 있습니다. Nginx, HAProxy, Traefik, Apache에 대한 실제 구성 생성...

나는 Istio와 SuperGloo를 조금 다루었고 다음 기사에서는 SuperGloo를 사용하여 기존 클러스터에 Istio 또는 Linkerd를 추가하는 방법과 후자가 작업을 수행하는 방법, 즉 구성을 덮어쓰지 않고 한 서비스 메시를 다른 서비스 메시에 적용할 수 있습니다.

출처 : habr.com