कुबेरनेट्स में काफ्का क्लस्टर के लिए उपयुक्त आकार का निर्धारण

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

अपाचे काफ्का विश्वसनीय, स्केलेबल और उच्च प्रदर्शन वाले वास्तविक समय स्ट्रीमिंग सिस्टम बनाने के लिए एक वितरित स्ट्रीमिंग प्लेटफॉर्म है। कुबेरनेट्स का उपयोग करके इसकी प्रभावशाली क्षमताओं को बढ़ाया जा सकता है। इसके लिए हमने विकास किया है ओपन सोर्स काफ्का ऑपरेटर और एक उपकरण कहा जाता है सुपरट्यूब. वे आपको कुबेरनेट्स पर काफ्का चलाने और इसकी विभिन्न विशेषताओं का उपयोग करने की अनुमति देते हैं, जैसे ब्रोकर कॉन्फ़िगरेशन को ठीक करना, पुनर्संतुलन के साथ मीट्रिक-आधारित स्केलिंग, रैक जागरूकता, "सॉफ्ट" (सुंदर) अद्यतन जारी करना, आदि।

अपने क्लस्टर में सुपरट्यूब आज़माएँ:

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

या संपर्क करें प्रलेखन. आप काफ्का की कुछ क्षमताओं के बारे में भी पढ़ सकते हैं, जिनके साथ काम सुपरट्यूब और काफ्का ऑपरेटर का उपयोग करके स्वचालित किया जाता है। हम उनके बारे में ब्लॉग पर पहले ही लिख चुके हैं:

• अरे नहीं! कुबेरनेट्स के लिए एक और काफ्का ऑपरेटर;
• प्रोमेथियस मेट्रिक्स के आधार पर काफ्का की निगरानी और संचालन करें;
• काफ्का ने कुबेरनेट्स पर जागरूकता फैलाई;
• इस्तियो के ऊपर अपाचे काफ्का चलाना - बेंचमार्क;
• काफ्का ऑपरेटर के साथ उपयोगकर्ता प्रमाणित और नियंत्रित क्लस्टर तक पहुंच;
• कुबेरनेट्स पर काफ्का रोलिंग अपग्रेड और डायनेमिक कॉन्फ़िगरेशन;
• काफ्का के लिए दूत प्रोटोकॉल फ़िल्टर, जालीदार.

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

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

सैद्धांतिक रूप से, हम किसी दिए गए भार को संभालने के लिए आवश्यक दलालों की संख्या का भी अनुमान लगा सकते हैं। हालाँकि, व्यवहार में विभिन्न स्तरों पर इतने सारे कॉन्फ़िगरेशन विकल्प हैं कि किसी विशेष कॉन्फ़िगरेशन के संभावित प्रदर्शन का मूल्यांकन करना बहुत मुश्किल (यदि असंभव नहीं) है। दूसरे शब्दों में, किसी दिए गए प्रदर्शन के आधार पर कॉन्फ़िगरेशन की योजना बनाना बहुत मुश्किल है।

सुपरट्यूब उपयोगकर्ताओं के लिए, हम आमतौर पर निम्नलिखित दृष्टिकोण अपनाते हैं: हम कुछ कॉन्फ़िगरेशन (बुनियादी ढांचे + सेटिंग्स) से शुरू करते हैं, फिर इसके प्रदर्शन को मापते हैं, ब्रोकर सेटिंग्स को समायोजित करते हैं और प्रक्रिया को दोबारा दोहराते हैं। ऐसा तब तक होता है जब तक बुनियादी ढांचे का सबसे धीमा घटक पूरी तरह से उपयोग नहीं किया जाता है।

इस तरह, हमें एक स्पष्ट विचार मिलता है कि एक क्लस्टर को एक निश्चित भार को संभालने के लिए कितने दलालों की आवश्यकता होती है (दलालों की संख्या अन्य कारकों पर भी निर्भर करती है, जैसे कि लचीलापन सुनिश्चित करने के लिए संदेश प्रतिकृतियों की न्यूनतम संख्या, विभाजन की संख्या) नेता, आदि)। इसके अलावा, हमें यह जानकारी मिलती है कि किन बुनियादी ढांचे के घटकों को ऊर्ध्वाधर स्केलिंग की आवश्यकता होती है।

यह आलेख प्रारंभिक कॉन्फ़िगरेशन में सबसे धीमे घटकों से अधिकतम लाभ प्राप्त करने और काफ्का क्लस्टर के थ्रूपुट को मापने के लिए हमारे द्वारा उठाए गए कदमों के बारे में बात करेगा। अत्यधिक लचीले कॉन्फ़िगरेशन के लिए कम से कम तीन चालू ब्रोकरों की आवश्यकता होती है (min.insync.replicas=3), तीन अलग-अलग पहुंच क्षेत्रों में वितरित। कुबेरनेट्स बुनियादी ढांचे को कॉन्फ़िगर, स्केल और मॉनिटर करने के लिए, हम हाइब्रिड क्लाउड के लिए अपने स्वयं के कंटेनर प्रबंधन प्लेटफॉर्म का उपयोग करते हैं - पाइपलाइन. यह ऑन-प्रिमाइस (बेयर मेटल, वीएमवेयर) और पांच प्रकार के क्लाउड (अलीबाबा, एडब्ल्यूएस, एज़्योर, गूगल, ओरेकल) के साथ-साथ उनके किसी भी संयोजन का समर्थन करता है।

काफ्का क्लस्टर अवसंरचना और विन्यास पर विचार

नीचे दिए गए उदाहरणों के लिए, हमने क्लाउड प्रदाता के रूप में AWS और Kubernetes वितरण के रूप में EKS को चुना। एक समान कॉन्फ़िगरेशन का उपयोग करके कार्यान्वित किया जा सकता है पीकेई - बंजई क्लाउड से कुबेरनेट्स वितरण, सीएनसीएफ द्वारा प्रमाणित।

डिस्क

अमेज़न विभिन्न ऑफर करता है ईबीएस वॉल्यूम प्रकार. महत्वपूर्ण या मुख्य स्थान पर gp2 и io1 हालाँकि, उच्च थ्रूपुट सुनिश्चित करने के लिए SSD ड्राइव हैं gp2 संचित ऋणों का उपभोग करता है (आई/ओ क्रेडिट), इसलिए हमने प्रकार को प्राथमिकता दी io1, जो लगातार उच्च थ्रूपुट प्रदान करता है।

उदाहरण प्रकार

काफ्का का प्रदर्शन ऑपरेटिंग सिस्टम के पेज कैश पर अत्यधिक निर्भर है, इसलिए हमें ब्रोकर्स (जेवीएम) और पेज कैश के लिए पर्याप्त मेमोरी वाले इंस्टेंस की आवश्यकता है। उदाहरण c5.2xबड़ा - एक अच्छी शुरुआत, क्योंकि इसमें 16 जीबी मेमोरी है और ईबीएस के साथ काम करने के लिए अनुकूलित. इसका नुकसान यह है कि यह हर 30 घंटे में केवल 24 मिनट से अधिक समय तक अधिकतम प्रदर्शन प्रदान करने में सक्षम है। यदि आपके कार्यभार को लंबी अवधि में चरम प्रदर्शन की आवश्यकता है, तो आप अन्य उदाहरण प्रकारों पर विचार करना चाह सकते हैं। हमने बिल्कुल यही किया, यहीं पर रुककर c5.4xबड़ा. यह अधिकतम थ्रूपुट प्रदान करता है 593,75 एमबी/एस. ईबीएस वॉल्यूम का अधिकतम थ्रूपुट io1 उदाहरण से अधिक c5.4xबड़ा, इसलिए बुनियादी ढांचे का सबसे धीमा तत्व इस उदाहरण प्रकार का I/O थ्रूपुट होने की संभावना है (जिसे हमारे लोड परीक्षणों को भी पुष्टि करनी चाहिए)।

Сеть

वीएम इंस्टेंस और डिस्क के प्रदर्शन की तुलना में नेटवर्क थ्रूपुट काफी बड़ा होना चाहिए, अन्यथा नेटवर्क एक बाधा बन जाता है। हमारे मामले में, नेटवर्क इंटरफ़ेस c5.4xबड़ा 10 Gb/s तक की गति का समर्थन करता है, जो VM इंस्टेंस के I/O थ्रूपुट से काफी अधिक है।

ब्रोकर तैनाती

सीपीयू, मेमोरी, नेटवर्क और डिस्क संसाधनों के लिए अन्य प्रक्रियाओं के साथ प्रतिस्पर्धा से बचने के लिए दलालों को समर्पित नोड्स पर तैनात किया जाना चाहिए (कुबेरनेट्स में निर्धारित)।

जावा संस्करण

तार्किक विकल्प जावा 11 है क्योंकि यह डॉकर के साथ इस अर्थ में संगत है कि जेवीएम उस कंटेनर के लिए उपलब्ध प्रोसेसर और मेमोरी को सही ढंग से निर्धारित करता है जिसमें ब्रोकर चल रहा है। यह जानते हुए कि सीपीयू सीमाएँ महत्वपूर्ण हैं, जेवीएम आंतरिक और पारदर्शी रूप से जीसी थ्रेड और जेआईटी थ्रेड की संख्या निर्धारित करता है। हमने काफ्का छवि का उपयोग किया banzaicloud/kafka:2.13-2.4.0, जिसमें जावा 2.4.0 पर काफ्का संस्करण 2.13 (स्कैला 11) शामिल है।

यदि आप कुबेरनेट्स पर जावा/जेवीएम के बारे में अधिक जानना चाहते हैं, तो हमारी निम्नलिखित पोस्ट देखें:

• मेरा जावा एप्लिकेशन OOMKilled क्यों है?;
• जावा 10 अनुप्रयोगों के लिए कंटेनरों का आकार सही ढंग से कैसे करें.

ब्रोकर मेमोरी सेटिंग्स

ब्रोकर मेमोरी को कॉन्फ़िगर करने के दो प्रमुख पहलू हैं: जेवीएम के लिए सेटिंग्स और कुबेरनेट्स पॉड के लिए। पॉड के लिए निर्धारित मेमोरी सीमा अधिकतम ढेर आकार से अधिक होनी चाहिए ताकि जेवीएम में जावा मेटास्पेस के लिए जगह हो जो उसकी अपनी मेमोरी में रहता है और ऑपरेटिंग सिस्टम पेज कैश के लिए जिसे काफ्का सक्रिय रूप से उपयोग करता है। हमारे परीक्षणों में हमने मापदंडों के साथ काफ्का दलालों को लॉन्च किया -Xmx4G -Xms2G, और पॉड के लिए मेमोरी सीमा थी 10 Gi. कृपया ध्यान दें कि JVM के लिए मेमोरी सेटिंग्स का उपयोग करके स्वचालित रूप से प्राप्त किया जा सकता है -XX:MaxRAMPercentage и -X:MinRAMPercentage, पॉड के लिए मेमोरी सीमा के आधार पर।

ब्रोकर प्रोसेसर सेटिंग्स

सामान्यतया, आप काफ्का द्वारा उपयोग किए जाने वाले धागों की संख्या बढ़ाकर समानता बढ़ाकर प्रदर्शन में सुधार कर सकते हैं। काफ्का के लिए जितने अधिक प्रोसेसर उपलब्ध होंगे, उतना बेहतर होगा। हमारे परीक्षण में, हमने 6 प्रोसेसर की सीमा के साथ शुरुआत की और धीरे-धीरे (पुनरावृत्तियों के माध्यम से) उनकी संख्या 15 तक बढ़ा दी। num.network.threads=12 नेटवर्क से डेटा प्राप्त करने और उसे भेजने वाले थ्रेड्स की संख्या बढ़ाने के लिए ब्रोकर सेटिंग्स में। तुरंत यह पता चलने पर कि अनुयायी दलालों को प्रतिकृतियां जल्दी से प्राप्त नहीं हो सकीं, उन्होंने उठाया num.replica.fetchers अनुयायी दलालों द्वारा नेताओं के संदेशों को दोहराने की गति को बढ़ाकर 4 तक करना।

लोड जनरेशन टूल

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

बेंच मार्किंग

प्रदर्शन माप एक पुनरावृत्तीय प्रक्रिया है जिसमें निम्नलिखित चरण शामिल हैं:

• बुनियादी ढांचे की स्थापना (ईकेएस क्लस्टर, काफ्का क्लस्टर, लोड जेनरेशन टूल, साथ ही प्रोमेथियस और ग्राफाना);
• एकत्रित प्रदर्शन संकेतकों में यादृच्छिक विचलन को फ़िल्टर करने के लिए एक निश्चित अवधि के लिए लोड उत्पन्न करना;
• देखे गए प्रदर्शन संकेतकों के आधार पर ब्रोकर के बुनियादी ढांचे और कॉन्फ़िगरेशन को समायोजित करना;
• काफ्का क्लस्टर थ्रूपुट का आवश्यक स्तर प्राप्त होने तक प्रक्रिया को दोहराते रहें। साथ ही, इसे लगातार प्रतिलिपि प्रस्तुत करने योग्य होना चाहिए और थ्रूपुट में न्यूनतम भिन्नता प्रदर्शित करनी चाहिए।

अगला अनुभाग उन चरणों का वर्णन करता है जो परीक्षण क्लस्टर बेंचमार्किंग प्रक्रिया के दौरान किए गए थे।

उपकरण

बेसलाइन कॉन्फ़िगरेशन को त्वरित रूप से तैनात करने, लोड उत्पन्न करने और प्रदर्शन को मापने के लिए निम्नलिखित टूल का उपयोग किया गया था:

• बंजई क्लाउड पाइपलाइन अमेज़ॅन से ईकेएस क्लस्टर आयोजित करने के लिए सी प्रोमिथेउस (काफ्का और इंफ्रास्ट्रक्चर मेट्रिक्स इकट्ठा करने के लिए) और ग्राफाना (इन मेट्रिक्स की कल्पना करने के लिए)। हमने फायदा उठाया एकीकृत в पाइपलाइन ऐसी सेवाएँ जो फ़ेडरेटेड मॉनिटरिंग, केंद्रीकृत लॉग संग्रह, भेद्यता स्कैनिंग, आपदा पुनर्प्राप्ति, एंटरप्राइज़-ग्रेड सुरक्षा और बहुत कुछ प्रदान करती हैं।
• संग्रेनेल - काफ्का क्लस्टर के लोड परीक्षण के लिए एक उपकरण।
• काफ्का मेट्रिक्स और बुनियादी ढांचे की कल्पना के लिए ग्राफाना डैशबोर्ड: कुबेरनेट्स काफ्का, नोड निर्यातक.
• कुबेरनेट्स पर काफ्का क्लस्टर स्थापित करने का सबसे आसान तरीका सुपरट्यूब सीएलआई। कुबेरनेट्स पर उत्पादन के लिए तैयार काफ्का क्लस्टर चलाने के लिए ज़ूकीपर, काफ्का ऑपरेटर, एन्वॉय और कई अन्य घटक स्थापित और ठीक से कॉन्फ़िगर किए गए हैं।
  • स्थापना के लिए सुपरट्यूब सीएलआई दिए गए निर्देशों का उपयोग करें यहां.

ईकेएस क्लस्टर

समर्पित कार्यकर्ता नोड्स के साथ एक ईकेएस क्लस्टर तैयार करें c5.4xबड़ा काफ्का दलालों के साथ पॉड्स के लिए अलग-अलग उपलब्धता क्षेत्रों में, साथ ही लोड जनरेटर और निगरानी बुनियादी ढांचे के लिए समर्पित नोड्स।

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

एक बार जब ईकेएस क्लस्टर चालू और चालू हो जाए, तो इसे एकीकृत करने में सक्षम करें निगरानी सेवा - वह प्रोमेथियस और ग्राफाना को एक क्लस्टर में तैनात करेगी।

काफ्का प्रणाली घटक

सुपरट्यूब सीएलआई का उपयोग करके ईकेएस में काफ्का सिस्टम घटकों (ज़ूकीपर, काफ्का-ऑपरेटर) को स्थापित करें:

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

काफ्का क्लस्टर

डिफ़ॉल्ट रूप से, ईकेएस प्रकार के ईबीएस वॉल्यूम का उपयोग करता है gp2, इसलिए आपको वॉल्यूम के आधार पर एक अलग स्टोरेज क्लास बनाने की आवश्यकता है io1 काफ्का क्लस्टर के लिए:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

दलालों के लिए पैरामीटर सेट करें min.insync.replicas=3 और तीन अलग-अलग उपलब्धता क्षेत्रों में नोड्स पर ब्रोकर पॉड्स तैनात करें:

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

विषय

हमने समानांतर में तीन लोड जनरेटर इंस्टेंसेस चलाए। उनमें से प्रत्येक अपने-अपने विषय पर लिखता है, अर्थात हमें कुल तीन विषयों की आवश्यकता है:

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

प्रत्येक विषय के लिए, प्रतिकृति कारक 3 है - अत्यधिक उपलब्ध उत्पादन प्रणालियों के लिए न्यूनतम अनुशंसित मूल्य।

लोड जनरेशन टूल

हमने लोड जनरेटर की तीन प्रतियां लॉन्च कीं (प्रत्येक ने एक अलग विषय में लिखा)। लोड जनरेटर पॉड्स के लिए, आपको नोड एफ़िनिटी सेट करने की आवश्यकता है ताकि वे केवल उनके लिए आवंटित नोड्स पर शेड्यूल हों:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

ध्यान देने योग्य कुछ बातें:

• लोड जनरेटर 512 बाइट्स लंबाई के संदेश उत्पन्न करता है और उन्हें 500 संदेशों के बैचों में काफ्का को प्रकाशित करता है।
• एक तर्क का उपयोग करना -required-acks=all प्रकाशन को तब सफल माना जाता है जब संदेश की सभी सिंक्रनाइज़ प्रतिकृतियां काफ्का दलालों द्वारा प्राप्त और पुष्टि की जाती हैं। इसका मतलब यह है कि बेंचमार्क में हमने न केवल नेताओं द्वारा संदेश प्राप्त करने की गति को मापा, बल्कि उनके अनुयायियों द्वारा संदेशों की प्रतिकृति बनाने की गति को भी मापा। इस परीक्षण का उद्देश्य उपभोक्ता की पढ़ने की गति का मूल्यांकन करना नहीं है (उपभोक्ता) हाल ही में प्राप्त संदेश जो अभी भी ओएस पेज कैश में बने हुए हैं, और इसकी तुलना डिस्क पर संग्रहीत संदेशों की पढ़ने की गति से की गई है।
• लोड जनरेटर 20 श्रमिकों को समानांतर में चलाता है (-workers=20). प्रत्येक कार्यकर्ता में 5 उत्पादक होते हैं जो कार्यकर्ता का काफ्का क्लस्टर से संबंध साझा करते हैं। परिणामस्वरूप, प्रत्येक जनरेटर में 100 निर्माता होते हैं, और वे सभी काफ्का क्लस्टर को संदेश भेजते हैं।

क्लस्टर के स्वास्थ्य की निगरानी करना

काफ्का क्लस्टर के लोड परीक्षण के दौरान, हमने यह सुनिश्चित करने के लिए इसके स्वास्थ्य की भी निगरानी की कि कोई पॉड पुनरारंभ न हो, कोई आउट-ऑफ-सिंक प्रतिकृतियां न हों, और न्यूनतम उतार-चढ़ाव के साथ अधिकतम थ्रूपुट हो:

• लोड जनरेटर प्रकाशित संदेशों की संख्या और त्रुटि दर के बारे में मानक आँकड़े लिखता है। त्रुटि दर वही रहनी चाहिए 0,00%.
• क्रूज़ कंट्रोलकाफ्का-ऑपरेटर द्वारा तैनात, एक डैशबोर्ड प्रदान करता है जहां हम क्लस्टर की स्थिति की निगरानी भी कर सकते हैं। इस पैनल को देखने के लिए यह करें:

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• आईएसआर स्तर ("इन-सिंक" प्रतिकृतियों की संख्या) सिकुड़न और विस्तार 0 के बराबर हैं।

माप परिणाम

3 दलाल, संदेश का आकार - 512 बाइट्स

तीन ब्रोकरों में समान रूप से वितरित विभाजन के साथ, हम प्रदर्शन हासिल करने में सक्षम थे ~500 एमबी/सेकेंड (लगभग 990 हजार संदेश प्रति सेकंड):

JVM वर्चुअल मशीन की मेमोरी खपत 2 जीबी से अधिक नहीं थी:

डिस्क थ्रूपुट उन सभी तीन उदाहरणों पर अधिकतम I/O नोड थ्रूपुट तक पहुंच गया, जिन पर ब्रोकर चल रहे थे:

नोड्स द्वारा मेमोरी उपयोग के डेटा से, यह पता चलता है कि सिस्टम बफरिंग और कैशिंग में ~10-15 जीबी का समय लगा:

3 दलाल, संदेश का आकार - 100 बाइट्स

जैसे-जैसे संदेश का आकार घटता है, थ्रूपुट लगभग 15-20% कम हो जाता है: प्रत्येक संदेश को संसाधित करने में लगने वाला समय इसे प्रभावित करता है। इसके अलावा, प्रोसेसर लोड लगभग दोगुना हो गया है।

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

4 दलाल, संदेश का आकार - 512 बाइट्स

आप केवल नए ब्रोकरों को जोड़कर और विभाजन का संतुलन बनाए रखकर काफ्का क्लस्टर के प्रदर्शन को आसानी से बढ़ा सकते हैं (यह सुनिश्चित करता है कि लोड ब्रोकरों के बीच समान रूप से वितरित है)। हमारे मामले में, ब्रोकर जोड़ने के बाद, क्लस्टर थ्रूपुट बढ़ गया ~580 एमबी/सेकंड (~1,1 मिलियन संदेश प्रति सेकंड). वृद्धि अपेक्षा से कम रही: यह मुख्य रूप से विभाजन के असंतुलन द्वारा समझाया गया है (सभी ब्रोकर अपनी क्षमताओं के चरम पर काम नहीं करते हैं)।

जेवीएम मशीन की मेमोरी खपत 2 जीबी से नीचे रही:

विभाजन के असंतुलन से ड्राइव वाले दलालों का कार्य प्रभावित हुआ:

निष्कर्ष

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

हमने सुपरट्यूब को एक क्लस्टर को जल्दी और आसानी से तैनात करने, इसे कॉन्फ़िगर करने, ब्रोकरों और विषयों को जोड़ने/हटाने, अलर्ट का जवाब देने और यह सुनिश्चित करने के लिए डिज़ाइन किया है कि काफ्का सामान्य रूप से कुबेरनेट्स पर ठीक से काम करता है। हमारा लक्ष्य आपको मुख्य कार्य (काफ्का संदेशों को "उत्पन्न करना" और "उपभोग करना") पर ध्यान केंद्रित करने में मदद करना है, और सारी मेहनत सुपरट्यूब और काफ्का ऑपरेटर पर छोड़ देना है।

यदि आप बंजई क्लाउड प्रौद्योगिकियों और ओपन सोर्स परियोजनाओं में रुचि रखते हैं, तो कंपनी की सदस्यता लें GitHub, लिंक्डइन या ट्विटर.

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

• «K8s में रेडिस ऑपरेटर के साथ एक कहानी और इस डेटाबेस से डेटा का विश्लेषण करने के लिए उपयोगिताओं की एक लघु समीक्षा";
• «RabbitMQ का कुबेरनेट्स में निर्बाध प्रवासन";
• «CoreOS से zetcd: ZooKeeper को...etcd स्टोरेज से बदलना'.

स्रोत: www.habr.com