ለኢስቲዮ እና ሊንከርድ የሲፒዩ ፍጆታ መለኪያ

መግቢያ

ውስጥ ነን Shopify ኢስቲዮ እንደ የአገልግሎት መረብ ማሰማራት ጀመረ። በመርህ ደረጃ ፣ ከአንድ ነገር በስተቀር ሁሉም ነገር ተስማሚ ነው- ውድ ነው.

В የታተሙ መለኪያዎች ለኢስቲዮ እንዲህ ይላል:

በIstio 1.1፣ ፕሮክሲው በ0,6 ጥያቄዎች በሰከንድ 1000 vCPUs (ምናባዊ ኮሮች) ይበላል።

በአገልግሎት መረብ ውስጥ ለመጀመሪያው ክልል (በእያንዳንዱ የግንኙነቱ ክፍል 2 ፕሮክሲዎች) በሰከንድ አንድ ሚሊዮን ጥያቄዎች ላይ በመመስረት 1200 ተኪ-ብቻ ኮሮች ይኖረናል። የGoogle ወጪ ማስያ ለማዋቀር በወር $40/ኮር ነው። n1-standard-64ማለትም ይህ ክልል ብቻ በሴኮንድ ለ50 ሚሊየን ጥያቄ በወር ከ1ሺህ ዶላር በላይ ያስወጣናል።

ኢቫን ሲም (እ.ኤ.አ.ኢቫን ሲም) በግልጽ ሲወዳደር የአገልግሎት ሜሽ ባለፈው አመት ዘግይቷል እና ለማህደረ ትውስታ እና ፕሮሰሰር ተመሳሳይ ቃል ገብቷል ፣ ግን አልተሳካም

በግልጽ ለማየት እንደሚቻለው, values-isio-test.yaml ወደ ሂደተሩ የሚቀርቡትን ጥያቄዎች በእጅጉ ይጨምራል። በትክክል ከቆጠርኩ ለቁጥጥር ፓነል 24 ፕሮሰሰር ኮር እና 0,5 ሲፒዩ ለእያንዳንዱ ፕሮክሲ እፈልጋለሁ። ያን ያህል የለኝም። ተጨማሪ መገልገያዎች ለእኔ ሲመደቡ ፈተናዎቹን እደግማለሁ።

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

ሱፐርግሎልን ተጠቀምኩ ምክንያቱም የአገልግሎት መረብን ማስነሳት በጣም ቀላል ያደርገዋል። ብዙ ማድረግ አልነበረብኝም። ሱፐርግሎልን በምርት ውስጥ አንጠቀምም ነገር ግን ለዚህ ተግባር ፍጹም ነው። በእያንዳንዱ የአገልግሎት መረብ ላይ በጥሬው ሁለት ትዕዛዞችን ተግባራዊ ማድረግ ነበረብኝ። ሁለት የማግለል ስብስቦችን ተጠቀምኩ - አንድ እያንዳንዳቸው ለኢስቲዮ እና ሊንከርድ።

ሙከራው የተካሄደው በጎግል ኩበርኔትስ ሞተር ላይ ነው። ኩበርኔትስ ተጠቀምኩኝ። 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      |
+---------+------------+---------+---------------------------+

Crash-loop ጥቂት ደቂቃዎችን ወስዷል፣ እና ከዚያ የቁጥጥር ፓነሎች ተረጋግተዋል።

(ማስታወሻ፡ SuperGloo እስካሁን ድረስ Istio 1.0.xን ብቻ ነው የሚደግፈው። ሙከራውን በIstio 1.1.3 ደግሜዋለሁ፣ ግን ምንም የሚታይ ልዩነት አላስተዋልኩም።)

Istio አውቶማቲክ ማሰማራትን በማዋቀር ላይ

ኢስቲዮ የጎን መኪና ኤንኤን እንዲጭን ፣ የጎን መኪና መርፌን እንጠቀማለን - MutatingAdmissionWebhook. በዚህ ጽሑፍ ውስጥ ስለ እሱ አንነጋገርም. ይህ የሁሉንም አዳዲስ ፖድዎች ተደራሽነት የሚቆጣጠር እና በተለዋዋጭ ሁኔታ የጎን መኪና እና ለተግባራት ኃላፊነት ያለው ኢንቲኮንቴይነር የሚጨምር ተቆጣጣሪ ነው ማለት እችላለሁ። iptables.

እኛ በShopify የጎን መኪናዎችን ለመተግበር የራሳችንን የመዳረሻ መቆጣጠሪያ ጽፈን ነበር፣ ነገር ግን በዚህ መለኪያ፣ ከኢስቲዮ ጋር የሚመጣውን መቆጣጠሪያ ወሰድኩ። ተቆጣጣሪው በስም ቦታ ላይ መለያ ሲኖር በነባሪ የጎን መኪናዎችን ያስገባል። 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 failover simulator ሠራን። ልዩ የሥራ ጫናዎችን ለመቅረጽ በተለዋዋጭ የተዋቀረ የአገልግሎታችንን ግራፍ የተወሰነ ክፍል የሚወክል ብጁ ቶፖሎጂ ለመፍጠር መሳሪያ እንፈልጋለን።

በፍላሽ ሽያጭ ወቅት የሾፕፋይ መሠረተ ልማት በከባድ ጭነት ውስጥ ነው። በተመሳሳይ ጊዜ, 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 (ገቢ እና ወጪ).

የሀብት አጠቃቀምን እንከታተላለን DataDogምክንያቱም የፕሮሜቲየስ ክላስተር የለንም።

ውጤቶች

የመቆጣጠሪያ ፓነሎች

በመጀመሪያ የሲፒዩ ፍጆታን ተመልክተናል.

የሊንከርድ መቆጣጠሪያ ፓነል ~ 22 ሚሊድራማ

ኢስቲዮ የቁጥጥር ፓነል: ~ 750 ሚልዮን

የ Istio መቆጣጠሪያ ፓኔል በግምት ይጠቀማል 35 እጥፍ ተጨማሪ የሲፒዩ ሀብቶችከሊንከርድ. እርግጥ ነው, ሁሉም ነገር በነባሪነት ተዘጋጅቷል, እና ኢስቲዮ-ቴሌሜትሪ እዚህ ብዙ የሲፒዩ ሀብቶችን ይጠቀማል (አንዳንድ ተግባራትን በመቀነስ ሊሰናከል ይችላል). ይህን አካል ካስወገዱት, አሁንም ከ 100 ሚሊ-ኮርስ በላይ ያገኛሉ, ማለትም 4 ጊዜ ተጨማሪከሊንከርድ.

የጎን መኪና ፕሮክሲ

ከዚያ የተኪ አጠቃቀምን አረጋገጥን። ከጥያቄዎች ብዛት ጋር ቀጥተኛ ግንኙነት ሊኖር ይገባል፣ ነገር ግን ለእያንዳንዱ የጎን መኪና ኩርባውን የሚነካ የተወሰነ ራስ አለ።

ሊንከርድ፡ ~100 ሚሊኮርስ ለአይርስ-ደንበኛ፣ ~50 ሚሊኮርስ ለአይርስ-ደንበኛ-ሎድገን

ውጤቶቹ አመክንዮአዊ ይመስላሉ፣ ምክንያቱም የደንበኛው ተኪ ከሎድገን ፕሮክሲው በእጥፍ የሚበልጥ ትራፊክ ይቀበላል፡ ለእያንዳንዱ የወጪ ጥያቄ ከሎድገን ደንበኛው አንድ ገቢ እና አንድ የወጪ ጥያቄ አለው።

ኢስቲዮ/መልእክተኛ፡ ~155 ሚሊኮርስ ለአይርስ-ደንበኛ፣ ~75 ሚሊኮርስ ለአይርስ-ደንበኛ-ሎድገን

ለኢስቲዮ የጎን መኪናዎች ተመሳሳይ ውጤቶችን እናያለን።

ግን በአጠቃላይ የኢስቲዮ/የመልእክተኛ ፕሮክሲዎች ይበላሉ ወደ 50% ተጨማሪ የሲፒዩ ሀብቶችከሊንከርድ.

በአገልጋዩ በኩል ተመሳሳይ እቅድ እናያለን-

ሊንከርድ፡ ~ 50 ሚሊኮርስ ለአይርስ-ሰርቨር

ኢስቲዮ/መልእክተኛ፡ ~80 ሚሊኮርስ ለአይርሰ-ሰርቨር

የአገልጋይ የጎን መኪና ኢስቲዮ/መልእክተኛ ይበላል ወደ 60% ተጨማሪ የሲፒዩ ሀብቶችከሊንከርድ.

መደምደሚያ

የኢስቲዮ ኤንጄይ ፕሮክሲ በእኛ አስመሳይ የስራ ጫና ከሊንከርድ 50+% የበለጠ ሲፒዩ ይበላል። የሊንከርድ የቁጥጥር ፓነል ከኢስቲዮ በጣም ያነሰ ሀብቶችን ይጠቀማል ፣ በተለይም ለዋና ዋና ክፍሎች።

እነዚህን ወጪዎች እንዴት እንደሚቀንስ አሁንም እያሰብን ነው. ሀሳብ ካሎት ሼር ያድርጉ!

ምንጭ: hab.com