Istio 및 Linkerd의 CPU 소비 벤치마크

소개

우리는 Shopify Istio를 서비스 메시로 배포하기 시작했습니다. 원칙적으로 한 가지를 제외하고는 모든 것이 정상입니다. 비싸다..

В 게시된 벤치마크 Istio의 경우 다음과 같이 말합니다.

Istio 1.1을 사용하면 프록시는 초당 요청 0,6개당 약 1000개의 vCPU(가상 코어)를 사용합니다.

서비스 메시의 첫 번째 지역(연결 양쪽에 프록시 2개)의 경우 초당 1200만 요청의 속도로 프록시 전용 코어 40개를 갖게 됩니다. Google의 비용 계산기에 따르면 구성 비용은 약 $XNUMX/월/코어로 계산됩니다. n1-standard-64즉, 이 지역에서만 초당 50만 건의 요청에 대해 월 1만 달러 이상의 비용이 소요됩니다.

이반 심(이반 심) 시각적으로 비교 작년에 서비스 메시가 지연되고 메모리와 프로세서에 대해서도 동일하게 약속했지만 제대로 작동하지 않았습니다.

분명히 value-istio-test.yaml은 CPU 요청을 심각하게 증가시킵니다. 계산을 올바르게 수행했다면 제어판에는 약 24개의 CPU 코어가 필요하고 각 프록시에는 0,5개의 CPU가 필요합니다. 나는 그다지 가지고 있지 않습니다. 더 많은 리소스가 할당되면 테스트를 반복하겠습니다.

나는 Istio의 성능이 다른 오픈 소스 서비스 메시와 얼마나 비슷한지 직접 확인하고 싶었습니다. 링커드.

서비스 메시 설치

우선 클러스터에 설치했습니다. 슈퍼글루:

$ supergloo init
installing supergloo version 0.3.12
using chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources created
serviceaccount/supergloo created
serviceaccount/discovery created
serviceaccount/mesh-discovery created
clusterrole.rbac.authorization.k8s.io/discovery created
clusterrole.rbac.authorization.k8s.io/mesh-discovery created
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding created
deployment.extensions/supergloo created
deployment.extensions/discovery created
deployment.extensions/mesh-discovery created
install successful!

나는 서비스 메시의 부트스트래핑을 훨씬 쉽게 만들어주기 때문에 SuperGloo를 사용했습니다. 나는 많은 일을 할 필요가 없었습니다. 우리는 프로덕션에서 SuperGloo를 사용하지 않지만 이러한 작업에 이상적입니다. 각 서비스 메시에 대해 말 그대로 몇 가지 명령을 사용해야 했습니다. 격리를 위해 Istio와 Linkerd에 각각 하나씩 두 개의 클러스터를 사용했습니다.

실험은 Google Kubernetes Engine에서 수행되었습니다. 쿠버네티스를 사용했어요 1.12.7-gke.7 그리고 노드 풀 n1-standard-4 자동 노드 확장(최소 4, 최대 16).

그런 다음 명령줄에서 두 서비스 메시를 모두 설치했습니다.

첫 번째 링크:

$ supergloo install linkerd --name linkerd
+---------+--------------+---------+---------------------------+
| INSTALL |     TYPE     | STATUS  |          DETAILS          |
+---------+--------------+---------+---------------------------+
| linkerd | Linkerd Mesh | Pending | enabled: true             |
|         |              |         | version: stable-2.3.0     |
|         |              |         | namespace: linkerd        |
|         |              |         | mtls enabled: true        |
|         |              |         | auto inject enabled: true |
+---------+--------------+---------+---------------------------+

그런 다음 이스티오:

$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true
+---------+------------+---------+---------------------------+
| INSTALL |    TYPE    | STATUS  |          DETAILS          |
+---------+------------+---------+---------------------------+
| istio   | Istio Mesh | Pending | enabled: true             |
|         |            |         | version: 1.0.6            |
|         |            |         | namespace: istio-system   |
|         |            |         | mtls enabled: true        |
|         |            |         | auto inject enabled: true |
|         |            |         | grafana enabled: true     |
|         |            |         | prometheus enabled: true  |
|         |            |         | jaeger enabled: true      |
+---------+------------+---------+---------------------------+

충돌 루프는 몇 분 정도 걸렸고 제어판이 안정화되었습니다.

(참고: SuperGloo는 현재 Istio 1.0.x만 지원합니다. Istio 1.1.3으로 실험을 반복했지만 눈에 띄는 차이점은 발견하지 못했습니다.)

Istio 자동 배포 설정

Istio가 사이드카 Envoy를 설치하도록 하려면 사이드카 인젝터를 사용합니다. MutatingAdmissionWebhook. 이 기사에서는 그것에 대해 이야기하지 않을 것입니다. 이것이 모든 새로운 포드의 액세스를 모니터링하고 작업을 담당하는 사이드카와 initContainer를 동적으로 추가하는 컨트롤러라고 말씀드리겠습니다. iptables.

Shopify에서는 사이드카를 구현하기 위해 자체 액세스 컨트롤러를 작성했지만 이 벤치마크에서는 Istio와 함께 제공되는 컨트롤러를 사용했습니다. 네임스페이스에 바로가기가 있는 경우 컨트롤러는 기본적으로 사이드카를 삽입합니다. istio-injection: enabled:

$ kubectl label namespace irs-client-dev istio-injection=enabled
namespace/irs-client-dev labeled

$ kubectl label namespace irs-server-dev istio-injection=enabled
namespace/irs-server-dev labeled

자동 Linkerd 배포 설정

Linkerd 사이드카 임베딩을 설정하려면 주석을 사용합니다(저는 다음을 통해 수동으로 추가했습니다). kubectl edit):

metadata:
  annotations:
    linkerd.io/inject: enabled

$ k edit ns irs-server-dev 
namespace/irs-server-dev edited

$ k get ns irs-server-dev -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    linkerd.io/inject: enabled
  name: irs-server-dev
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

Istio 내결함성 시뮬레이터

Shopify 고유의 트래픽을 실험하기 위해 Istio라는 내결함성 시뮬레이터를 구축했습니다. 우리는 특정 워크로드를 모델링하도록 동적으로 구성되고 서비스 그래프의 특정 부분을 나타내는 사용자 지정 토폴로지를 생성하는 도구가 필요했습니다.

Shopify의 인프라는 플래시 판매 중에 과부하 상태입니다. 이와 함께 쇼피파이(Shopify) 판매자에게 그러한 판매를 더 자주 개최하도록 권장합니다.. 대규모 고객은 때때로 계획된 반짝 세일에 대해 경고합니다. 다른 사람들은 밤낮 언제든지 우리를 위해 예상치 못한 일을 진행합니다.

우리는 탄력성 시뮬레이터가 과거에 Shopify의 인프라를 압도했던 토폴로지 및 워크로드와 일치하는 워크플로를 모델링하기를 원했습니다. 서비스 메시를 사용하는 주요 목적은 네트워크 수준의 안정성과 내결함성이 필요하다는 것이며, 이전에 서비스를 중단시켰던 부하에 서비스 메시가 효과적으로 대처하는 것이 중요합니다.

내결함성 시뮬레이터의 중심에는 서비스 메시 노드 역할을 하는 작업자 노드가 있습니다. 작업자 노드는 시작 시 정적으로 구성하거나 REST API를 통해 동적으로 구성할 수 있습니다. 우리는 작업자 노드의 동적 구성을 사용하여 회귀 테스트 형태로 워크플로를 생성합니다.

다음은 그러한 프로세스의 예입니다.

• 우리는 10개의 서버를 다음과 같이 출시합니다. bar 응답을 반환하는 서비스 200/OK 100ms 후.
• 우리는 10개의 클라이언트를 시작합니다. 각 클라이언트는 초당 100개의 요청을 보냅니다. bar.
• 10초마다 1개의 서버를 제거하고 오류를 모니터링합니다. 5xx 클라이언트에서.

워크플로가 끝나면 로그와 측정항목을 검사하고 테스트가 통과했는지 확인합니다. 이것이 서비스 메시의 성능에 대해 배우고 회귀 테스트를 실행하여 내결함성에 대한 가정을 테스트하는 방법입니다.

(참고: 우리는 Istio 내결함성 시뮬레이터를 오픈 소스화하는 것을 고려하고 있지만 아직 그렇게 할 준비가 되어 있지 않습니다.)

서비스 메시 벤치마크를 위한 Istio 내결함성 시뮬레이터

시뮬레이터의 여러 작업 노드를 설정했습니다.

• irs-client-loadgen: 초당 3개의 요청을 보내는 100개의 복제본 irs-client.
• irs-client: 요청을 받은 3개의 복제본은 100ms를 기다린 후 다음으로 요청을 전달합니다. irs-server.
• irs-server: 반환되는 복제본 3개 200/OK 100ms 후.

이 구성을 사용하면 9개 엔드포인트 간의 안정적인 트래픽 흐름을 측정할 수 있습니다. 사이드카 irs-client-loadgen и irs-server 초당 100개의 요청을 수신합니다. irs-client — 200(수신 및 발신).

우리는 다음을 통해 리소스 사용량을 추적합니다. 데이터 도그Prometheus 클러스터가 없기 때문입니다.

조사 결과

제어판

먼저 CPU 사용량을 조사했습니다.

Linkerd 제어판 ~22밀리코어

Istio 제어판: ~750밀리코어

Istio 제어판은 대략적으로 다음을 사용합니다. 35배 더 많은 CPU 리소스링커드보다 물론 모든 것이 기본적으로 설치되며 istio-telemetry는 여기에서 많은 프로세서 리소스를 소비합니다(일부 기능을 비활성화하여 비활성화할 수 있음). 이 구성 요소를 제거해도 여전히 100밀리코어 이상을 얻을 수 있습니다. 4 번링커드보다

사이드카 프록시

그런 다음 프록시 사용을 테스트했습니다. 요청 수와 선형 관계가 있어야 하지만 각 사이드카에는 곡선에 영향을 미치는 약간의 오버헤드가 있습니다.

링커드: irs-client의 경우 ~100밀리코어, irs-client-loadgen의 경우 ~50밀리코어

결과는 논리적으로 보입니다. 클라이언트 프록시는 loadgen 프록시보다 두 배 많은 트래픽을 수신하기 때문입니다. 즉, loadgen에서 나가는 모든 요청에 ​​대해 클라이언트에는 하나의 수신 요청과 하나의 송신 요청이 있습니다.

Istio/Envoy: irs-client의 경우 ~155밀리코어, irs-client-loadgen의 경우 ~75밀리코어

Istio 사이드카에서도 비슷한 결과가 나타납니다.

그러나 일반적으로 Istio/Envoy 프록시는 약 50% 더 많은 CPU 리소스링커드보다

서버 측에서도 동일한 구성표를 볼 수 있습니다.

Linkerd: irs-server의 경우 ~50밀리코어

Istio/Envoy: irs-server의 경우 ~80밀리코어

서버 측에서 사이드카 Istio/Envoy는 약 60% 더 많은 CPU 리소스링커드보다

결론

Istio Envoy 프록시는 시뮬레이션된 워크로드에서 Linkerd보다 50% 이상 더 많은 CPU를 소비합니다. Linkerd 제어판은 특히 핵심 구성 요소의 경우 Istio보다 훨씬 적은 리소스를 사용합니다.

우리는 이러한 비용을 어떻게 줄일 수 있을지 계속 고민하고 있습니다. 아이디어가 있다면 공유해주세요!

출처 : habr.com