🥇 Istio اور Linkerd کے لیے CPU استعمال کا بینچ مارک

تعارف

ہم میں ہیں Shopify Istio کو بطور سروس میش تعینات کرنا شروع کر دیا۔ اصولی طور پر، سب کچھ ٹھیک ہے، سوائے ایک چیز کے: یہ مہنگا ہے.

В شائع کردہ معیارات Istio کے لئے یہ کہتا ہے:

Istio 1.1 کے ساتھ، پراکسی تقریباً 0,6 vCPUs (ورچوئل کور) فی 1000 درخواستیں فی سیکنڈ استعمال کرتی ہے۔

سروس میش میں پہلے علاقے کے لیے (کنکشن کے ہر طرف 2 پراکسی)، ہمارے پاس صرف پراکسی کے لیے 1200 کور ہوں گے، فی سیکنڈ 40 لاکھ درخواستوں کی شرح سے۔ گوگل کے لاگت کیلکولیٹر کے مطابق، یہ ترتیب کے لیے تقریباً $XNUMX/ماہ/کور پر کام کرتا ہے n1-standard-64یعنی صرف اس خطے میں 50 لاکھ درخواستوں کے لیے فی سیکنڈ 1 ہزار ڈالر فی مہینہ سے زیادہ لاگت آئے گی۔

ایوان سم (ایوان سم) بصری طور پر موازنہ سروس میش نے پچھلے سال تاخیر کی تھی اور میموری اور پروسیسر کے لیے بھی یہی وعدہ کیا تھا، لیکن یہ کام نہیں ہوا:

بظاہر، values-istio-test.yaml سی پی یو کی درخواستوں میں سنجیدگی سے اضافہ کرے گا۔ اگر میں نے اپنا ریاضی صحیح طریقے سے کیا ہے، تو آپ کو کنٹرول پینل کے لیے تقریباً 24 CPU کور اور ہر پراکسی کے لیے 0,5 CPU کی ضرورت ہے۔ میرے پاس اتنا نہیں ہے۔ جب میرے لیے مزید وسائل مختص کیے جائیں گے تو میں ٹیسٹ دہراؤں گا۔

میں خود دیکھنا چاہتا تھا کہ اسٹیو کی کارکردگی ایک اور اوپن سورس سروس میش سے کتنی ملتی جلتی ہے: لنکرڈ.

سروس میش کی تنصیب

سب سے پہلے، میں نے اسے ایک کلسٹر میں انسٹال کیا۔ سپر گلو:

$ 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 کا استعمال نہیں کرتے ہیں، لیکن یہ ایسے کام کے لیے مثالی ہے۔ مجھے ہر سروس میش کے لئے لفظی طور پر ایک دو کمانڈز استعمال کرنا پڑیں۔ میں نے تنہائی کے لیے دو کلسٹر استعمال کیے - ایک ایک Istio اور Linkerd کے لیے۔

یہ تجربہ Google Kubernetes Engine پر کیا گیا۔ میں نے 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      |
+---------+------------+---------+---------------------------+

کریش لوپ میں چند منٹ لگے، اور پھر کنٹرول پینل مستحکم ہو گئے۔

(نوٹ: SuperGloo ابھی کے لیے صرف Istio 1.0.x کو سپورٹ کرتا ہے۔ میں نے Istio 1.1.3 کے ساتھ تجربہ دہرایا، لیکن کوئی قابل توجہ فرق محسوس نہیں ہوا۔)

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 تعیناتی ترتیب دینا

لنکرڈ سائڈکار ایمبیڈنگ کو ترتیب دینے کے لیے، ہم تشریحات کا استعمال کرتے ہیں (میں نے انہیں دستی طور پر شامل کیا۔ 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 کے لیے منفرد ٹریفک کے ساتھ تجربہ کرنے کے لیے Istio نامی ایک فالٹ ٹولرنس سمیلیٹر بنایا ہے۔ ہمیں اپنی مرضی کے مطابق ٹوپولوجی بنانے کے لیے ایک ٹول کی ضرورت تھی جو ہمارے سروس گراف کے ایک مخصوص حصے کی نمائندگی کرے، متحرک طور پر مخصوص کام کے بوجھ کو ماڈل کرنے کے لیے ترتیب دیا گیا ہو۔

فلیش سیلز کے دوران Shopify کا بنیادی ڈھانچہ بہت زیادہ بوجھ میں ہے۔ ایک ہی وقت میں، 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 (آنے والے اور جانے والے)۔

ہم وسائل کے استعمال کو ٹریک کرتے ہیں۔ ڈیٹا ڈاگکیونکہ ہمارے پاس پرومیتھیس کلسٹر نہیں ہے۔

نتائج

کنٹرول پینل

سب سے پہلے، ہم نے CPU کی کھپت کی جانچ کی۔

لنکرڈ کنٹرول پینل ~ 22 ملی کور

اسٹیو کنٹرول پینل: ~ 750 ملی کور

Istio کنٹرول پینل تقریبا استعمال کرتا ہے 35 گنا زیادہ CPU وسائلLinkerd کے مقابلے میں. بلاشبہ، ہر چیز بطور ڈیفالٹ انسٹال ہوتی ہے، اور istio-telemetry یہاں CPU کے بہت سارے وسائل استعمال کرتی ہے (کچھ فنکشنز کو غیر فعال کر کے اسے غیر فعال کیا جا سکتا ہے)۔ اگر ہم اس جزو کو ہٹا دیتے ہیں تو پھر بھی ہمیں 100 سے زیادہ ملیکورس ملتے ہیں، یعنی 4 گنا زیادہLinkerd کے مقابلے میں.

سائڈ کار پراکسی

پھر ہم نے پراکسی کے استعمال کا تجربہ کیا۔ درخواستوں کی تعداد کے ساتھ ایک لکیری تعلق ہونا چاہیے، لیکن ہر سائیڈ کار کے لیے کچھ اوور ہیڈ ہوتا ہے جو وکر کو متاثر کرتا ہے۔

لنکرڈ: irs-کلائنٹ کے لیے ~100 ملیکور، irs-کلائنٹ-لوڈجن کے لیے ~50 ملیکور

نتائج منطقی لگتے ہیں، کیونکہ کلائنٹ پراکسی کو لوڈجن پراکسی سے دوگنا زیادہ ٹریفک ملتا ہے: لوڈجن سے ہر باہر جانے والی درخواست کے لیے، کلائنٹ کے پاس ایک آنے والا اور ایک باہر جانے والا ہوتا ہے۔

Istio/Envoy: irs-client کے لیے ~155 millicores، ~75 millicores irs-client-loadgen کے لیے

ہم Istio sidecars کے لیے اسی طرح کے نتائج دیکھتے ہیں۔

لیکن عام طور پر، Istio/Envoy پراکسی استعمال کرتے ہیں۔ تقریباً 50% زیادہ CPU وسائلLinkerd کے مقابلے میں.

ہم سرور کی طرف ایک ہی اسکیم دیکھتے ہیں:

لنکرڈ: IRs-server کے لیے ~50 ملی کور

Istio/Envoy: irs-server کے لیے ~80 ملیکور

سرور کی طرف، سائڈکار اسٹیو/اینجوئ استعمال کرتا ہے۔ تقریباً 60% زیادہ CPU وسائلLinkerd کے مقابلے میں.

حاصل يہ ہوا

Istio Envoy پراکسی ہمارے نقلی کام کے بوجھ پر Linkerd سے 50+% زیادہ CPU استعمال کرتی ہے۔ Linkerd کنٹرول پینل Istio کے مقابلے میں بہت کم وسائل استعمال کرتا ہے، خاص طور پر بنیادی اجزاء کے لیے۔

ہم ابھی تک سوچ رہے ہیں کہ ان اخراجات کو کیسے کم کیا جائے۔ اگر آپ کے پاس خیالات ہیں، تو براہ مہربانی اشتراک کریں!

ماخذ: www.habr.com

Istio اور Linkerd کے لیے CPU کی کھپت کا بینچ مارک