इस्तियो और लिंकरड के लिए सीपीयू खपत बेंचमार्क

परिचय

हम अंदर हैं Shopify इस्तियो को एक सेवा जाल के रूप में तैनात करना शुरू किया। सिद्धांत रूप में, सब कुछ ठीक है, एक चीज़ को छोड़कर: ये महंगा है.

В प्रकाशित बेंचमार्क इस्तियो के लिए यह कहता है:

इस्तियो 1.1 के साथ, प्रॉक्सी प्रति 0,6 अनुरोध प्रति सेकंड लगभग 1000 वीसीपीयू (वर्चुअल कोर) की खपत करता है।

सेवा जाल में पहले क्षेत्र के लिए (कनेक्शन के प्रत्येक तरफ 2 प्रॉक्सी), हमारे पास केवल प्रॉक्सी के लिए 1200 कोर होंगे, प्रति सेकंड दस लाख अनुरोधों की दर से। Google के लागत कैलकुलेटर के अनुसार, कॉन्फ़िगरेशन के लिए यह लगभग $40/माह/कोर बैठता है n1-standard-64यानी, अकेले इस क्षेत्र में प्रति सेकंड 50 मिलियन अनुरोधों के लिए हमें प्रति माह 1 हजार डॉलर से अधिक का खर्च आएगा।

इवान सिम (इवान सिम) दृष्टिगत रूप से तुलना की गई सर्विस मेश में पिछले साल देरी हुई और मेमोरी और प्रोसेसर के लिए भी यही वादा किया गया था, लेकिन यह काम नहीं कर सका:

जाहिर है, values-istio-test.yaml सीपीयू अनुरोधों को गंभीरता से बढ़ा देगा। यदि मैंने अपना गणित सही ढंग से किया है, तो आपको नियंत्रण कक्ष के लिए लगभग 24 सीपीयू कोर और प्रत्येक प्रॉक्सी के लिए 0,5 सीपीयू की आवश्यकता होगी। मेरे पास उतना नहीं है. जब मुझे अधिक संसाधन आवंटित किए जाएंगे तो मैं परीक्षण दोहराऊंगा।

मैं स्वयं देखना चाहता था कि इस्तियो का प्रदर्शन किसी अन्य ओपन सोर्स सर्विस मेश के समान कैसे है: लिंकरड.

सेवा जाल स्थापना

सबसे पहले, मैंने इसे एक क्लस्टर में स्थापित किया सुपरग्लू:

$ 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!

मैंने सुपरग्लू का उपयोग किया क्योंकि यह सर्विस मेश को बूटस्ट्रैप करना बहुत आसान बनाता है। मुझे ज्यादा कुछ नहीं करना पड़ा. हम उत्पादन में सुपरग्लू का उपयोग नहीं करते हैं, लेकिन यह ऐसे कार्य के लिए आदर्श है। मुझे प्रत्येक सेवा जाल के लिए वस्तुतः कुछ आदेशों का उपयोग करना पड़ा। मैंने अलगाव के लिए दो समूहों का उपयोग किया - इस्तियो और लिंकरड के लिए एक-एक।

यह प्रयोग Google 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 |
+---------+--------------+---------+---------------------------+

फिर इस्तियो:

$ 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      |
+---------+------------+---------+---------------------------+

क्रैश-लूप में कुछ मिनट लगे और फिर नियंत्रण पैनल स्थिर हो गए।

(नोट: सुपरग्लू अभी केवल इस्तियो 1.0.x का समर्थन करता है। मैंने इस्तियो 1.1.3 के साथ प्रयोग दोहराया, लेकिन कोई उल्लेखनीय अंतर नहीं देखा।)

इस्तियो स्वचालित परिनियोजन की स्थापना

इस्तियो को साइडकार एन्वॉय स्थापित करने के लिए, हम साइडकार इंजेक्टर का उपयोग करते हैं - MutatingAdmissionWebhook. हम इस लेख में इसके बारे में बात नहीं करेंगे. मुझे बस इतना कहना है कि यह एक नियंत्रक है जो सभी नए पॉड्स की पहुंच पर नज़र रखता है और गतिशील रूप से एक साइडकार और इनिटकंटेनर जोड़ता है, जो कार्यों के लिए जिम्मेदार है iptables.

शॉपिफ़ाई में हमने साइडकार लागू करने के लिए अपना स्वयं का एक्सेस कंट्रोलर लिखा था, लेकिन इस बेंचमार्क के लिए मैंने उस कंट्रोलर का उपयोग किया जो इस्तियो के साथ आता है। नेमस्पेस में शॉर्टकट होने पर नियंत्रक डिफ़ॉल्ट रूप से साइडकार इंजेक्ट करता है 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

स्वचालित लिंकरड परिनियोजन की स्थापना

लिंकरड साइडकार एम्बेडिंग सेट करने के लिए, हम एनोटेशन का उपयोग करते हैं (मैंने उन्हें मैन्युअल रूप से जोड़ा है 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

इस्तियो फॉल्ट टॉलरेंस सिम्युलेटर

हमने Shopify के अद्वितीय ट्रैफ़िक के साथ प्रयोग करने के लिए इस्तियो नामक एक दोष सहिष्णुता सिम्युलेटर बनाया। हमें एक कस्टम टोपोलॉजी बनाने के लिए एक टूल की आवश्यकता थी जो हमारे सेवा ग्राफ़ के एक विशिष्ट हिस्से का प्रतिनिधित्व करेगा, जो विशिष्ट वर्कलोड को मॉडल करने के लिए गतिशील रूप से कॉन्फ़िगर किया जाएगा।

फ्लैश बिक्री के दौरान शॉपिफाई का बुनियादी ढांचा भारी भार में होता है। उसी समय, Shopify विक्रेताओं को ऐसी बिक्री अधिक बार आयोजित करने की सलाह देता है. बड़े ग्राहक कभी-कभी नियोजित फ्लैश सेल के बारे में चेतावनी देते हैं। दूसरे लोग उन्हें दिन या रात के किसी भी समय हमारे लिए अप्रत्याशित रूप से संचालित करते हैं।

हम चाहते थे कि हमारा लचीलापन सिम्युलेटर ऐसे वर्कफ़्लो को मॉडल करे जो अतीत में शॉपिफाई के बुनियादी ढांचे को प्रभावित करने वाली टोपोलॉजी और वर्कलोड से मेल खाता हो। सर्विस मेश का उपयोग करने का मुख्य उद्देश्य यह है कि हमें नेटवर्क स्तर पर विश्वसनीयता और दोष सहनशीलता की आवश्यकता है, और यह हमारे लिए महत्वपूर्ण है कि सर्विस मेश प्रभावी ढंग से उन भारों का सामना करता है जो पहले बाधित सेवाओं का सामना करते थे।

दोष सहनशीलता सिम्युलेटर के केंद्र में एक वर्कर नोड है, जो सर्विस मेश नोड के रूप में कार्य करता है। वर्कर नोड को स्टार्टअप पर स्थिर रूप से या REST API के माध्यम से गतिशील रूप से कॉन्फ़िगर किया जा सकता है। हम प्रतिगमन परीक्षण के रूप में वर्कफ़्लो बनाने के लिए वर्कर नोड्स के गतिशील कॉन्फ़िगरेशन का उपयोग करते हैं।

यहां ऐसी प्रक्रिया का एक उदाहरण दिया गया है:

• हमने 10 सर्वर लॉन्च किए हैं bar सेवा जो प्रतिक्रिया लौटाती है 200/OK 100 एमएस के बाद.
• हम 10 क्लाइंट लॉन्च करते हैं - प्रत्येक प्रति सेकंड 100 अनुरोध भेजता है bar.
• हर 10 सेकंड में हम 1 सर्वर हटाते हैं और त्रुटियों की निगरानी करते हैं 5xx ग्राहक पर.

वर्कफ़्लो के अंत में, हम लॉग और मेट्रिक्स की जांच करते हैं और जांचते हैं कि परीक्षण उत्तीर्ण हुआ या नहीं। इस तरह हम अपने सर्विस मेश के प्रदर्शन के बारे में सीखते हैं और दोष सहनशीलता के बारे में हमारी धारणाओं का परीक्षण करने के लिए एक प्रतिगमन परीक्षण चलाते हैं।

(नोट: हम इस्तियो फॉल्ट टॉलरेंस सिम्युलेटर की ओपन सोर्सिंग के बारे में सोच रहे हैं, लेकिन अभी तक ऐसा करने के लिए तैयार नहीं हैं।)

सर्विस मेश बेंचमार्क के लिए इस्तियो फॉल्ट टॉलरेंस सिम्युलेटर

हम सिम्युलेटर के कई कार्यशील नोड स्थापित कर रहे हैं:

• irs-client-loadgen: 3 प्रतिकृतियां जो प्रति सेकंड प्रति 100 अनुरोध भेजती हैं irs-client.
• irs-client: 3 प्रतिकृतियां जो अनुरोध प्राप्त करती हैं, 100ms प्रतीक्षा करें और अनुरोध को अग्रेषित करें irs-server.
• irs-server: 3 प्रतिकृतियां जो वापस आती हैं 200/OK 100 एमएस के बाद.

इस कॉन्फ़िगरेशन के साथ, हम 9 समापन बिंदुओं के बीच एक स्थिर ट्रैफ़िक प्रवाह को माप सकते हैं। साइडकार्स इन irs-client-loadgen и irs-server प्रति सेकंड 100 अनुरोध प्राप्त करें, और irs-client - 200 (इनकमिंग और आउटगोइंग)।

हम इसके माध्यम से संसाधन उपयोग को ट्रैक करते हैं DataDogक्योंकि हमारे पास प्रोमेथियस क्लस्टर नहीं है।

निष्कर्ष

कण्ट्रोल पेनल्स

सबसे पहले, हमने सीपीयू खपत की जांच की।

लिंकरड नियंत्रण कक्ष ~22 मिलीकोर

इस्तियो नियंत्रण कक्ष: ~750 मिलीकोर

इस्तियो नियंत्रण कक्ष लगभग उपयोग करता है 35 गुना अधिक CPU संसाधनलिंकरड की तुलना में। बेशक, सब कुछ डिफ़ॉल्ट रूप से स्थापित है, और इस्तियो-टेलीमेट्री यहां बहुत सारे प्रोसेसर संसाधनों का उपभोग करती है (इसे कुछ कार्यों को अक्षम करके अक्षम किया जा सकता है)। यदि हम इस घटक को हटा दें, तो भी हमें 100 मिलीकोर्स से अधिक प्राप्त होता है 4 गुना अधिकलिंकरड की तुलना में।

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

फिर हमने प्रॉक्सी के उपयोग का परीक्षण किया। अनुरोधों की संख्या के साथ एक रैखिक संबंध होना चाहिए, लेकिन प्रत्येक साइडकार के लिए कुछ ओवरहेड होता है जो वक्र को प्रभावित करता है।

लिंकर्ड: आईआरएस-क्लाइंट के लिए ~100 मिलीकोर्स, आईआरएस-क्लाइंट-लोडजेन के लिए ~50 मिलीकोर्स

परिणाम तार्किक लगते हैं, क्योंकि क्लाइंट प्रॉक्सी को लोडजेन प्रॉक्सी की तुलना में दोगुना ट्रैफ़िक प्राप्त होता है: लोडजेन से प्रत्येक आउटगोइंग अनुरोध के लिए, क्लाइंट के पास एक इनकमिंग और एक आउटगोइंग होता है।

इस्तियो/दूत: आईआरएस-क्लाइंट के लिए ~155 मिलीकोर्स, आईआरएस-क्लाइंट-लोडजेन के लिए ~75 मिलीकोर्स

हम इस्तियो साइडकार के लिए समान परिणाम देखते हैं।

लेकिन सामान्य तौर पर, इस्तियो/दूत प्रॉक्सी उपभोग करते हैं लगभग 50% अधिक CPU संसाधनलिंकरड की तुलना में।

हम सर्वर साइड पर भी यही योजना देखते हैं:

लिंकरड: आईआरएस-सर्वर के लिए ~50 मिलीकोर

इस्तियो/दूत: आईआरएस-सर्वर के लिए ~80 मिलीकोर

सर्वर साइड पर, साइडकार इस्तियो/एन्वॉय खपत करता है लगभग 60% अधिक CPU संसाधनलिंकरड की तुलना में।

निष्कर्ष

इस्तियो एनवॉय प्रॉक्सी हमारे सिम्युलेटेड वर्कलोड पर लिंकरड की तुलना में 50+% अधिक सीपीयू की खपत करता है। लिंकरड नियंत्रण कक्ष इस्तियो की तुलना में बहुत कम संसाधनों का उपभोग करता है, खासकर मुख्य घटकों के लिए।

हम अभी भी इस बारे में सोच रहे हैं कि इन लागतों को कैसे कम किया जाए। यदि आपके पास विचार हैं तो कृपया साझा करें!

स्रोत: www.habr.com