ఇస్టియో మరియు లింకర్డ్ కోసం CPU వినియోగ బెంచ్‌మార్క్

పరిచయం

మేము ఉన్నాము Shopify ఇస్టియోను సేవా మెష్‌గా అమలు చేయడం ప్రారంభించింది. సూత్రప్రాయంగా, ఒక విషయం మినహా ప్రతిదీ బాగానే ఉంది: అది ఖరీదైనది.

В ప్రచురించిన బెంచ్‌మార్క్‌లు ఇస్టియో కోసం ఇది ఇలా చెప్పింది:

Istio 1.1తో, ప్రాక్సీ సెకనుకు 0,6 అభ్యర్థనలకు దాదాపు 1000 vCPUలను (వర్చువల్ కోర్లు) వినియోగిస్తుంది.

సర్వీస్ మెష్‌లోని మొదటి ప్రాంతం కోసం (కనెక్షన్‌కి ప్రతి వైపు 2 ప్రాక్సీలు), సెకనుకు ఒక మిలియన్ అభ్యర్థనల చొప్పున మేము ప్రాక్సీ కోసం 1200 కోర్లను కలిగి ఉంటాము. Google యొక్క కాస్ట్ కాలిక్యులేటర్ ప్రకారం, ఇది కాన్ఫిగరేషన్ కోసం సుమారుగా $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ని ఉపయోగించము, కానీ ఇది అటువంటి పనికి అనువైనది. ప్రతి సర్వీస్ మెష్ కోసం నేను అక్షరాలా రెండు ఆదేశాలను ఉపయోగించాల్సి వచ్చింది. నేను ఐసోలేషన్ కోసం రెండు క్లస్టర్‌లను ఉపయోగించాను - ఇస్టియో మరియు లింకర్డ్ కోసం ఒక్కొక్కటి.

Google Kubernetes ఇంజిన్‌లో ఈ ప్రయోగం జరిగింది. నేను 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తో నేను ప్రయోగాన్ని పునరావృతం చేసాను, కానీ గుర్తించదగిన తేడా ఏమీ కనిపించలేదు.)

ఇస్టియో ఆటోమేటిక్ డిప్లాయ్‌మెంట్‌ని సెటప్ చేస్తోంది

ఇస్టియో సైడ్‌కార్ ఎన్వోయ్‌ను ఇన్‌స్టాల్ చేయడానికి, మేము సైడ్‌కార్ ఇంజెక్టర్ -ని ఉపయోగిస్తాము 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

ఆటోమేటిక్ లింకర్డ్ విస్తరణను సెటప్ చేస్తోంది

లింకర్డ్ సైడ్‌కార్ ఎంబెడ్డింగ్‌ని సెటప్ చేయడానికి, మేము ఉల్లేఖనాలను ఉపయోగిస్తాము (నేను వాటిని మాన్యువల్‌గా జోడించాను 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 ఇన్‌ఫ్రాస్ట్రక్చర్‌ను అధిగమించిన టోపోలాజీలు మరియు వర్క్‌లోడ్‌లకు సరిపోయే మోడల్ వర్క్‌ఫ్లోలకు మా రెసిలెన్స్ సిమ్యులేటర్ కావాలని మేము కోరుకుంటున్నాము. సర్వీస్ మెష్‌ని ఉపయోగించడం యొక్క ముఖ్య ఉద్దేశ్యం ఏమిటంటే, మనకు నెట్‌వర్క్ స్థాయిలో విశ్వసనీయత మరియు తప్పును తట్టుకోవడం అవసరం మరియు ఇంతకుముందు సేవలకు అంతరాయం కలిగించిన లోడ్‌లను సర్వీస్ మెష్ సమర్థవంతంగా ఎదుర్కోవడం మాకు ముఖ్యం.

ఫాల్ట్ టాలరెన్స్ సిమ్యులేటర్ యొక్క గుండె వద్ద వర్కర్ నోడ్ ఉంది, ఇది సర్వీస్ మెష్ నోడ్‌గా పనిచేస్తుంది. వర్కర్ నోడ్‌ను స్టార్టప్‌లో స్థిరంగా లేదా REST API ద్వారా డైనమిక్‌గా కాన్ఫిగర్ చేయవచ్చు. మేము రిగ్రెషన్ పరీక్షల రూపంలో వర్క్‌ఫ్లోలను సృష్టించడానికి వర్కర్ నోడ్‌ల డైనమిక్ కాన్ఫిగరేషన్‌ని ఉపయోగిస్తాము.

అటువంటి ప్రక్రియ యొక్క ఉదాహరణ ఇక్కడ ఉంది:

• మేము 10 సర్వర్‌లను ప్రారంభించాము bar ప్రతిస్పందనను అందించే సేవ 200/OK 100 ms తర్వాత.
• మేము 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 ms తర్వాత.

ఈ కాన్ఫిగరేషన్‌తో, మేము 9 ఎండ్ పాయింట్‌ల మధ్య స్థిరమైన ట్రాఫిక్ ప్రవాహాన్ని కొలవగలము. లోపల సైడ్‌కార్లు irs-client-loadgen и irs-server సెకనుకు 100 అభ్యర్థనలను స్వీకరించండి మరియు irs-client - 200 (ఇన్కమింగ్ మరియు అవుట్గోయింగ్).

మేము వనరుల వినియోగాన్ని ట్రాక్ చేస్తాము డేటాడాగ్ఎందుకంటే మనకు ప్రోమేతియస్ క్లస్టర్ లేదు.

Результаты

నియంత్రణ ప్యానెల్లు

మొదట, మేము CPU వినియోగాన్ని పరిశీలించాము.

లింకర్డ్ కంట్రోల్ ప్యానెల్ ~22 మిల్లీకోర్

ఇస్టియో నియంత్రణ ప్యానెల్: ~750 మిల్లీకోర్

Istio నియంత్రణ ప్యానెల్ సుమారుగా ఉపయోగిస్తుంది 35 రెట్లు ఎక్కువ CPU వనరులులింకర్డ్ కంటే. వాస్తవానికి, ప్రతిదీ డిఫాల్ట్‌గా ఇన్‌స్టాల్ చేయబడింది మరియు istio-telemetry ఇక్కడ చాలా ప్రాసెసర్ వనరులను వినియోగిస్తుంది (కొన్ని ఫంక్షన్‌లను నిలిపివేయడం ద్వారా ఇది నిలిపివేయబడుతుంది). మేము ఈ భాగాన్ని తీసివేస్తే, మేము ఇప్పటికీ 100 మిల్లీకోర్ల కంటే ఎక్కువ పొందుతాము, అంటే 4 రెట్లు ఎక్కువలింకర్డ్ కంటే.

సైడ్‌కార్ ప్రాక్సీ

మేము ప్రాక్సీ వినియోగాన్ని పరీక్షించాము. అభ్యర్థనల సంఖ్యతో సరళ సంబంధం ఉండాలి, కానీ ప్రతి సైడ్‌కార్‌కు వక్రతను ప్రభావితం చేసే కొంత ఓవర్‌హెడ్ ఉంటుంది.

లింకర్డ్: ఐఆర్ఎస్-క్లయింట్ కోసం ~100 మిల్లీకోర్లు, ఐఆర్ఎస్-క్లయింట్-లోడ్జెన్ కోసం ~50 మిల్లీకోర్లు

ఫలితాలు లాజికల్‌గా కనిపిస్తాయి, ఎందుకంటే క్లయింట్ ప్రాక్సీ లోడ్‌జెన్ ప్రాక్సీ కంటే రెండు రెట్లు ఎక్కువ ట్రాఫిక్‌ను పొందుతుంది: లోడ్‌జెన్ నుండి ప్రతి అవుట్‌గోయింగ్ అభ్యర్థన కోసం, క్లయింట్‌కు ఒక ఇన్‌కమింగ్ మరియు ఒక అవుట్‌గోయింగ్ ఉంటుంది.

ఇస్టియో/ఎన్వోయ్: ఐఆర్ఎస్-క్లయింట్ కోసం ~155 మిల్లీకోర్లు, ఐఆర్ఎస్-క్లయింట్-లోడ్జెన్ కోసం ~75 మిల్లీకోర్లు

మేము Istio సైడ్‌కార్‌ల కోసం ఇలాంటి ఫలితాలను చూస్తాము.

కానీ సాధారణంగా, Istio/Envoy ప్రాక్సీలు వినియోగిస్తారు సుమారు 50% ఎక్కువ CPU వనరులులింకర్డ్ కంటే.

మేము సర్వర్ వైపు అదే పథకాన్ని చూస్తాము:

లింకర్డ్: ఐఆర్ఎస్-సర్వర్ కోసం ~50 మిల్లీకోర్

ఇస్టియో/ఎన్వోయ్: ఐఆర్ఎస్-సర్వర్ కోసం ~80 మిల్లీకోర్

సర్వర్ వైపు, సైడ్‌కార్ ఇస్టియో/ఎన్వాయ్ వినియోగిస్తుంది సుమారు 60% ఎక్కువ CPU వనరులులింకర్డ్ కంటే.

తీర్మానం

ఇస్టియో ఎన్వాయ్ ప్రాక్సీ మా అనుకరణ పనిభారంపై లింకర్డ్ కంటే 50+% ఎక్కువ CPUని వినియోగిస్తుంది. లింకర్డ్ నియంత్రణ ప్యానెల్ ఇస్టియో కంటే చాలా తక్కువ వనరులను వినియోగిస్తుంది, ముఖ్యంగా ప్రధాన భాగాల కోసం.

ఈ ఖర్చులను ఎలా తగ్గించుకోవాలో ఇంకా ఆలోచిస్తున్నాం. మీకు ఆలోచనలు ఉంటే, దయచేసి భాగస్వామ్యం చేయండి!

మూలం: www.habr.com