Istio এবং Linkerd-এর জন্য CPU খরচের বেঞ্চমার্ক

ভূমিকা

আমারা আছি বিষয়শ্রেণী একটি পরিষেবা জাল হিসাবে Istio স্থাপন শুরু. নীতিগতভাবে, সবকিছু ঠিক আছে, একটি জিনিস ছাড়া: এটা ব্যয়বহুল.

В প্রকাশিত বেঞ্চমার্ক ইস্টিওর জন্য এটি বলে:

Istio 1.1 এর সাথে, প্রক্সি প্রতি সেকেন্ডে প্রতি 0,6 অনুরোধে প্রায় 1000 vCPUs (ভার্চুয়াল কোর) ব্যবহার করে।

পরিষেবা জালের প্রথম অঞ্চলের জন্য (সংযোগের প্রতিটি পাশে 2টি প্রক্সি), আমাদের কাছে প্রতি সেকেন্ডে এক মিলিয়ন অনুরোধের হারে শুধুমাত্র প্রক্সির জন্য 1200 কোর থাকবে। Google-এর খরচ ক্যালকুলেটর অনুসারে, কনফিগারেশনের জন্য এটি প্রায় $40/মাস/কোর হিসাবে কাজ করে n1-standard-64, অর্থাৎ, শুধুমাত্র এই অঞ্চলে প্রতি সেকেন্ডে 50 মিলিয়ন অনুরোধের জন্য আমাদের প্রতি মাসে 1 হাজার ডলারের বেশি খরচ হবে।

ইভান সিম (ইভান সিম) দৃশ্যত তুলনা পরিষেবা জাল গত বছর বিলম্ব করেছে এবং মেমরি এবং প্রসেসরের জন্য একই প্রতিশ্রুতি দিয়েছে, কিন্তু এটি কার্যকর হয়নি:

স্পষ্টতই, values-istio-test.yaml CPU অনুরোধগুলিকে গুরুত্ব সহকারে বৃদ্ধি করবে। যদি আমি আমার গণিত সঠিকভাবে করে থাকি, তাহলে কন্ট্রোল প্যানেলের জন্য আপনার আনুমানিক 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!

আমি সুপারগ্লু ব্যবহার করেছি কারণ এটি পরিষেবা জাল বুটস্ট্র্যাপিংকে অনেক সহজ করে তোলে। আমাকে বেশি কিছু করতে হয়নি। আমরা উত্পাদনে সুপারগ্লু ব্যবহার করি না, তবে এটি এই জাতীয় কাজের জন্য আদর্শ। প্রতিটি পরিষেবা জালের জন্য আমাকে আক্ষরিকভাবে কয়েকটি কমান্ড ব্যবহার করতে হয়েছিল। আমি বিচ্ছিন্নতার জন্য দুটি ক্লাস্টার ব্যবহার করেছি - একটি ইস্টিও এবং লিঙ্কার্ডের জন্য।

পরীক্ষাটি গুগল কুবারনেটস ইঞ্জিনে পরিচালিত হয়েছিল। আমি কুবারনেটস ব্যবহার করেছি 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      |
+---------+------------+---------+---------------------------+

ক্র্যাশ-লুপটি কয়েক মিনিট সময় নেয় এবং তারপরে নিয়ন্ত্রণ প্যানেলগুলি স্থিতিশীল হয়৷

(দ্রষ্টব্য: সুপারগ্লু আপাতত শুধুমাত্র Istio 1.0.x সমর্থন করে। আমি Istio 1.1.3 এর সাথে পরীক্ষাটি পুনরাবৃত্তি করেছি, কিন্তু কোনো লক্ষণীয় পার্থক্য লক্ষ্য করিনি।)

Istio স্বয়ংক্রিয় স্থাপনা সেট আপ করা হচ্ছে

ইস্টিওকে সাইডকার এনভয় ইনস্টল করতে, আমরা সাইডকার ইনজেক্টর - ব্যবহার করি MutatingAdmissionWebhook. আমরা এই নিবন্ধে এটি সম্পর্কে কথা বলতে হবে না. আমাকে শুধু বলতে দিন যে এটি একটি নিয়ামক যা সমস্ত নতুন পডের অ্যাক্সেস নিরীক্ষণ করে এবং গতিশীলভাবে একটি সাইডকার এবং initContainer যোগ করে, যা কাজের জন্য দায়ী 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

স্বয়ংক্রিয় লিঙ্কার্ড স্থাপনা সেট আপ করা হচ্ছে

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 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 প্রতি সেকেন্ডে 100টি অনুরোধ গ্রহণ করুন এবং irs-client — 200 (আগত এবং বহির্গামী)।

আমরা মাধ্যমে সম্পদ ব্যবহার ট্র্যাক DataDogকারণ আমাদের প্রমিথিউস ক্লাস্টার নেই।

Результаты

নিয়ন্ত্রণ প্যানেল

প্রথমত, আমরা CPU খরচ পরীক্ষা করেছি।

লিংকার্ড কন্ট্রোল প্যানেল ~22 মিলিকোর

ইস্টিও কন্ট্রোল প্যানেল: ~750 মিলিকোর

Istio কন্ট্রোল প্যানেল প্রায় ব্যবহার করে 35 গুণ বেশি CPU সম্পদLinkerd এর চেয়ে অবশ্যই, সবকিছু ডিফল্টরূপে ইনস্টল করা হয়, এবং istio-টেলিমেট্রি এখানে প্রচুর প্রসেসর সংস্থান গ্রহণ করে (এটি কিছু ফাংশন নিষ্ক্রিয় করে নিষ্ক্রিয় করা যেতে পারে)। যদি আমরা এই উপাদানটি সরিয়ে ফেলি, আমরা এখনও 100 মিলিকোরের বেশি পাই, অর্থাৎ 4 গুণ বেশিLinkerd এর চেয়ে

সাইডকার প্রক্সি

আমরা তারপর একটি প্রক্সি ব্যবহার পরীক্ষা. অনুরোধের সংখ্যার সাথে একটি রৈখিক সম্পর্ক থাকা উচিত, তবে প্রতিটি সাইডকারের জন্য কিছু ওভারহেড রয়েছে যা বক্ররেখাকে প্রভাবিত করে।

লিংকার্ড: IRs-ক্লায়েন্টের জন্য ~100 মিলিকোর, IR-ক্লায়েন্ট-লোডজেনের জন্য ~50 মিলিকোর

ফলাফলগুলি যৌক্তিক দেখায়, কারণ ক্লায়েন্ট প্রক্সি লোডজেন প্রক্সির চেয়ে দ্বিগুণ বেশি ট্রাফিক পায়: লোডজেন থেকে প্রতিটি আউটগোয়িং অনুরোধের জন্য, ক্লায়েন্টের একটি ইনকামিং এবং একটি আউটগোয়িং থাকে৷

Istio/দূত: IRs-ক্লায়েন্টের জন্য ~155 মিলিকোর, IR-ক্লায়েন্ট-লোডজেনের জন্য ~75 মিলিকোর

আমরা Istio sidecars জন্য অনুরূপ ফলাফল দেখতে.

কিন্তু সাধারণভাবে, ইস্টিও/এনভয় প্রক্সি ব্যবহার করে প্রায় 50% বেশি CPU সম্পদLinkerd এর চেয়ে

আমরা সার্ভারের দিকে একই স্কিম দেখতে পাচ্ছি:

Linkerd: irs-সার্ভারের জন্য ~50 মিলিকোর

Istio/দূত: irs-সার্ভারের জন্য ~80 মিলিকোর

সার্ভারের দিকে, সাইডকার ইস্টিও/এনভয় ব্যবহার করে প্রায় 60% বেশি CPU সম্পদLinkerd এর চেয়ে

উপসংহার

ইস্টিও এনভয় প্রক্সি আমাদের সিমুলেটেড কাজের চাপে Linkerd থেকে 50+% বেশি CPU ব্যবহার করে। Linkerd কন্ট্রোল প্যানেল ইস্টিওর তুলনায় অনেক কম সম্পদ ব্যবহার করে, বিশেষ করে মূল উপাদানগুলির জন্য।

আমরা এখনও চিন্তা করছি কিভাবে এই খরচ কমানো যায়। আপনার যদি ধারণা থাকে, শেয়ার করুন!

উত্স: www.habr.com