Istio र Linkerd को लागि 🥇CPU खपत बेन्चमार्क

परिचय

हामी भित्र छौ Shopify Istio लाई सेवा जालको रूपमा प्रयोग गर्न थाल्यो। सिद्धान्तमा, सबै कुरा ठीक छ, एक चीज बाहेक: यो महँगो छ.

В बेन्चमार्क प्रकाशित Istio को लागी यो भन्छ:

Istio 1.1 को साथ, प्रोक्सीले लगभग 0,6 vCPUs (भर्चुअल कोर) प्रति 1000 अनुरोध प्रति सेकेन्ड खपत गर्दछ।

सेवा जालमा पहिलो क्षेत्रको लागि (जडानको प्रत्येक छेउमा 2 प्रोक्सीहरू), हामीसँग प्रोक्सीको लागि 1200 कोरहरू हुनेछन्, प्रति सेकेन्ड एक मिलियन अनुरोधहरूको दरमा। गुगलको लागत क्याल्कुलेटरका अनुसार, यसले कन्फिगरेसनको लागि लगभग $40/महिना/कोर काम गर्छ। n1-standard-64, अर्थात्, यस क्षेत्रले मात्र हामीलाई प्रति सेकेन्ड 50 मिलियन अनुरोधहरूको लागि प्रति महिना 1 हजार डलर भन्दा बढी खर्च गर्नेछ।

इभान सिम (इभान सिम) दृश्यात्मक तुलना सेवा जाल गत वर्ष ढिलाइ भयो र मेमोरी र प्रोसेसरको लागि उही प्रतिज्ञा गर्यो, तर यसले काम गरेन:

स्पष्ट रूपमा, values-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 को लागि।

यो प्रयोग गुगल कुबर्नेट्स इन्जिनमा गरिएको थियो। मैले Kubernetes प्रयोग गरें 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 |
+---------+--------------+---------+---------------------------+

त्यसपछि Istio:

$ 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 लाई साइडकार दूत स्थापना गर्न, हामी साइडकार इन्जेक्टर - प्रयोग गर्छौं 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 100 ms पछि।
हामी 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 100 ms पछि।

यो कन्फिगरेसनको साथ, हामी 9 अन्तिम बिन्दुहरू बीच एक स्थिर ट्राफिक प्रवाह मापन गर्न सक्छौं। साइडकारहरू मा irs-client-loadgen и irs-server प्रति सेकेन्ड १०० अनुरोधहरू प्राप्त गर्नुहोस्, र irs-client - 200 (आगमन र बहिर्गमन)।

हामी मार्फत स्रोत उपयोग ट्र्याक गर्छौं DataDogकिनभने हामीसँग प्रोमेथियस क्लस्टर छैन।

Результаты

प्यानेल नियन्त्रण गर्नुहोस्

पहिले, हामीले CPU खपत जाँच गर्यौं।

Linkerd नियन्त्रण प्यानल ~ 22 मिलीकोर

Istio नियन्त्रण प्यानल: ~ 750 मिलीकोर

Istio नियन्त्रण प्यानल लगभग प्रयोग गर्दछ ३५ गुणा बढी CPU स्रोतहरूLinkerd भन्दा। निस्सन्देह, सबै कुरा पूर्वनिर्धारित रूपमा स्थापना गरिएको छ, र istio-telemetry यहाँ धेरै प्रोसेसर स्रोतहरू खपत गर्दछ (यसलाई केही प्रकार्यहरू असक्षम गरेर असक्षम गर्न सकिन्छ)। यदि हामीले यो कम्पोनेन्ट हटायौं भने, हामीले अझै पनि १०० मिलिकोर भन्दा बढी पाउँछौं, त्यो हो १.२ गुणा बढीLinkerd भन्दा।

साइडकार प्रोक्सी

हामीले त्यसपछि प्रोक्सीको प्रयोगको परीक्षण गर्‍यौं। त्यहाँ अनुरोधहरूको संख्यासँग रैखिक सम्बन्ध हुनुपर्दछ, तर प्रत्येक साइडकारको लागि त्यहाँ केही ओभरहेड हुन्छ जसले वक्रलाई असर गर्छ।

Linkerd: irs-client का लागि ~100 millicores, ~ 50 millicores irs-client-loadgen को लागि

नतिजाहरू तार्किक देखिन्छन्, किनभने क्लाइन्ट प्रोक्सीले लोडजेन प्रोक्सीको तुलनामा दोब्बर ट्राफिक प्राप्त गर्दछ: लोडजनबाट प्रत्येक बहिर्गमन अनुरोधको लागि, क्लाइन्टसँग एउटा आगमन र एक बहिर्गमन हुन्छ।

Istio/Envoy: irs-client को लागि ~155 millicores, ~ 75 millicores irs-client-loadgen को लागि

हामी Istio sidecars को लागी समान परिणाम देख्छौं।

तर सामान्यतया, Istio/Envoy प्रोक्सीहरूले उपभोग गर्छन् लगभग 50% थप CPU स्रोतहरूLinkerd भन्दा।

हामी सर्भर साइडमा उही योजना देख्छौं:

लिङ्कर्ड: आईआरएस-सर्भरको लागि ~50 मिलिकोर

Istio/Envoy: ~80 millicores irs-सर्भरको लागि

सर्भर साइडमा, sidecar Istio/Envoy उपभोग गर्दछ लगभग 60% थप CPU स्रोतहरूLinkerd भन्दा।

निष्कर्षमा

Istio Envoy प्रोक्सीले हाम्रो सिमुलेटेड वर्कलोडमा Linkerd भन्दा 50+% बढी CPU खपत गर्छ। Linkerd नियन्त्रण प्यानलले Istio भन्दा धेरै कम स्रोतहरू खपत गर्दछ, विशेष गरी मुख्य घटकहरूको लागि।

हामी अझै पनि यी लागतहरू कसरी कम गर्ने भनेर सोचिरहेका छौं। यदि तपाईंसँग विचार छ भने, कृपया साझा गर्नुहोस्!

स्रोत: www.habr.com

Istio र Linkerd को लागि CPU खपत बेंचमार्क