Kubernetes मा काफ्का क्लस्टरको लागि उपयुक्त आकार निर्धारण गर्नुहोस्

नोट। अनुवाद।: यस लेखमा, Banzai क्लाउडले Kubernetes भित्र काफ्कालाई प्रयोग गर्न सजिलो बनाउन कसरी यसको अनुकूलन उपकरणहरू प्रयोग गर्न सकिन्छ भन्ने उदाहरण साझा गर्दछ। निम्न निर्देशनहरूले तपाइँ कसरी तपाइँको पूर्वाधारको इष्टतम आकार निर्धारण गर्न सक्नुहुन्छ र आवश्यक थ्रुपुट प्राप्त गर्न काफ्कालाई कन्फिगर गर्न सक्नुहुन्छ भनेर वर्णन गर्दछ।

Apache Kafka विश्वसनीय, स्केलेबल र उच्च प्रदर्शन वास्तविक समय स्ट्रिमिङ प्रणालीहरू सिर्जना गर्न एक वितरित स्ट्रिमिङ प्लेटफर्म हो। यसको प्रभावशाली क्षमताहरू Kubernetes प्रयोग गरेर विस्तार गर्न सकिन्छ। यसका लागि हामीले विकास गरेका छौं खुला स्रोत काफ्का अपरेटर र एक उपकरण भनिन्छ सुपरट्यूब। तिनीहरूले तपाईंलाई Kubernetes मा काफ्का चलाउन र यसका विभिन्न सुविधाहरू प्रयोग गर्न अनुमति दिन्छ, जस्तै ब्रोकर कन्फिगरेसनलाई फाइन-ट्युनिङ, रिब्यालेन्सिङको साथ मेट्रिक-आधारित स्केलिंग, र्याक जागरूकता, "नरम"। (मनोरम) अपडेटहरू रोल आउट गर्दै, आदि।

आफ्नो क्लस्टरमा Supertubes प्रयास गर्नुहोस्:

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

वा सम्पर्क गर्नुहोस् कागजात। तपाईंले काफ्काका केही क्षमताहरूको बारेमा पनि पढ्न सक्नुहुन्छ, जसको साथ काम सुपरट्यूब र काफ्का अपरेटर प्रयोग गरेर स्वचालित हुन्छ। हामीले पहिले नै ब्लगमा उनीहरूको बारेमा लेखेका छौं:

• धत्तेरिका! Kubernetes को लागी अर्को काफ्का अपरेटर;
• प्रोमेथियस मेट्रिक्समा आधारित काफ्कालाई निगरानी र सञ्चालन गर्नुहोस्;
• Kubernetes मा काफ्का र्याक जागरूकता;
• Istio - बेन्चमार्क मा Apache Kafka दौड्दै;
• काफ्का अपरेटरसँग प्रयोगकर्ताले प्रमाणित र पहुँच नियन्त्रित क्लस्टरहरू;
• काफ्का रोलिङ अपग्रेड र Kubernetes मा गतिशील कन्फिगरेसन;
• काफ्काका लागि दूत प्रोटोकल फिल्टर, मेशेड.

जब तपाइँ Kubernetes मा काफ्का क्लस्टर तैनाथ गर्ने निर्णय गर्नुहुन्छ, तपाइँ सम्भवतः अन्तर्निहित पूर्वाधारको इष्टतम आकार निर्धारण गर्ने चुनौतीको सामना गर्नुहुनेछ र थ्रुपुट आवश्यकताहरू पूरा गर्न तपाइँको काफ्का कन्फिगरेसनलाई फाइन-ट्यून गर्न आवश्यक छ। प्रत्येक ब्रोकरको अधिकतम कार्यसम्पादन अन्तर्निहित पूर्वाधार घटकहरू जस्तै मेमोरी, प्रोसेसर, डिस्क गति, नेटवर्क ब्यान्डविथ, इत्यादिको कार्यसम्पादनद्वारा निर्धारण गरिन्छ।

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

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

Supertubes प्रयोगकर्ताहरूका लागि, हामी सामान्यतया निम्न दृष्टिकोण लिन्छौं: हामी केही कन्फिगरेसन (पूर्वाधार + सेटिङहरू) बाट सुरु गर्छौं, त्यसपछि यसको कार्यसम्पादन मापन गर्छौं, ब्रोकर सेटिङहरू समायोजन गर्छौं र प्रक्रिया फेरि दोहोर्याउँछौं। पूर्वाधारको सबैभन्दा ढिलो भाग पूर्ण रूपमा प्रयोग नभएसम्म यो हुन्छ।

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

यस लेखले प्रारम्भिक कन्फिगरेसनहरूमा सबैभन्दा ढिलो कम्पोनेन्टहरूबाट अधिकतम प्राप्त गर्न र काफ्का क्लस्टरको थ्रुपुट मापन गर्न हामीले चालेका कदमहरूको बारेमा कुरा गर्नेछ। एक उच्च लचिलो कन्फिगरेसन कम्तिमा तीन चलिरहेको दलाल आवश्यक छ (min.insync.replicas=3), तीन फरक पहुँच क्षेत्रहरूमा वितरित। Kubernetes पूर्वाधार कन्फिगर गर्न, मापन गर्न र निगरानी गर्न, हामी हाइब्रिड क्लाउडहरूको लागि हाम्रो आफ्नै कन्टेनर व्यवस्थापन प्लेटफर्म प्रयोग गर्छौं - पाइपलाइन। यसले अन-प्रिमाइस (बेयर मेटल, VMware) र पाँच प्रकारका क्लाउडहरू (अलिबाबा, AWS, Azure, Google, Oracle), साथै तिनीहरूको कुनै पनि संयोजनलाई समर्थन गर्दछ।

काफ्का क्लस्टर पूर्वाधार र कन्फिगरेसनमा विचार

तलका उदाहरणहरूको लागि, हामीले क्लाउड प्रदायकको रूपमा AWS र Kubernetes वितरणको रूपमा EKS छनौट गर्यौं। समान कन्फिगरेसन प्रयोग गरेर लागू गर्न सकिन्छ P.K.E. - CNCF द्वारा प्रमाणित Banzai क्लाउड बाट Kubernetes वितरण।

डिस्क

अमेजनले विभिन्न प्रस्तावहरू प्रदान गर्दछ EBS भोल्युम प्रकार। मूल मा gp2 и io1 त्यहाँ SSD ड्राइभहरू छन्, तथापि, उच्च थ्रुपुट सुनिश्चित गर्न gp2 संचित क्रेडिट उपभोग गर्दछ (I/O क्रेडिट), त्यसैले हामीले प्रकारलाई प्राथमिकता दियौं io1, जसले लगातार उच्च थ्रुपुट प्रदान गर्दछ।

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

काफ्काको कार्यसम्पादन अपरेटिङ सिस्टमको पृष्ठ क्यासमा अत्यधिक निर्भर छ, त्यसैले हामीलाई ब्रोकरहरू (JVM) र पृष्ठ क्यासका लागि पर्याप्त मेमोरी भएको उदाहरणहरू चाहिन्छ। उदाहरण c5.2x ठूलो - राम्रो सुरुवात, किनकि यसमा १६ जीबी मेमोरी छ र EBS सँग काम गर्न अनुकूलित। यसको बेफाइदा यो हो कि यो केवल प्रत्येक 30 घण्टामा 24 मिनेट भन्दा बढीको लागि अधिकतम प्रदर्शन प्रदान गर्न सक्षम छ। यदि तपाइँको कार्यभारलाई लामो समयको अवधिमा शिखर प्रदर्शन आवश्यक छ भने, तपाइँ अन्य उदाहरण प्रकारहरू विचार गर्न सक्नुहुन्छ। ठ्याक्कै हामीले के गर्यौं, रोकेर c5.4x ठूलो। यसले अधिकतम थ्रुपुट प्रदान गर्दछ 593,75 Mbps। EBS भोल्युमको अधिकतम थ्रुपुट io1 उदाहरण भन्दा उच्च c5.4x ठूलो, त्यसैले पूर्वाधारको सबैभन्दा ढिलो तत्व यो उदाहरण प्रकारको I/O थ्रुपुट हुन सक्छ (जसलाई हाम्रो लोड परीक्षणले पनि पुष्टि गर्नुपर्छ)।

सञ्जाल

नेटवर्क थ्रुपुट VM उदाहरण र डिस्कको कार्यसम्पादनको तुलनामा पर्याप्त ठूलो हुनुपर्छ, अन्यथा सञ्जाल एक बाधा बन्छ। हाम्रो मामला मा, नेटवर्क इन्टरफेस c5.4x ठूलो 10 Gb/s को गतिलाई समर्थन गर्दछ, जुन VM उदाहरणको I/O थ्रुपुट भन्दा धेरै उच्च छ।

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

CPU, मेमोरी, नेटवर्क, र डिस्क स्रोतहरूको लागि अन्य प्रक्रियाहरूसँग प्रतिस्पर्धा गर्नबाट बच्न समर्पित नोडहरूमा दलालहरूलाई (कुबर्नेटमा अनुसूचित) तैनाथ गरिनुपर्छ।

जाभा संस्करण

तार्किक छनोट Java 11 हो किनभने यो JVM ले ब्रोकर चलिरहेको कन्टेनरमा उपलब्ध प्रोसेसर र मेमोरी सही रूपमा निर्धारण गर्ने अर्थमा डकरसँग उपयुक्त छ। CPU सीमाहरू महत्त्वपूर्ण छन् भन्ने थाहा पाएर, JVM ले आन्तरिक र पारदर्शी रूपमा GC थ्रेडहरू र JIT थ्रेडहरूको संख्या सेट गर्दछ। हामीले काफ्का छवि प्रयोग गर्यौं banzaicloud/kafka:2.13-2.4.0, जसमा Java 2.4.0 मा काफ्का संस्करण 2.13 (Scala 11) समावेश छ।

यदि तपाइँ Kubernetes मा Java/JVM बारे थप जान्न चाहनुहुन्छ भने, हाम्रा निम्न पोस्टहरू हेर्नुहोस्:

• किन मेरो Java अनुप्रयोग OOMKilled छ;
• Java 10 अनुप्रयोगहरूको लागि कन्टेनरहरू कसरी सही रूपमा आकार गर्ने.

ब्रोकर मेमोरी सेटिङहरू

ब्रोकर मेमोरी कन्फिगर गर्नका लागि दुईवटा मुख्य पक्षहरू छन्: JVM र Kubernetes पोडका लागि सेटिङहरू। पोडको लागि सेट गरिएको मेमोरी सीमा अधिकतम हिप साइज भन्दा ठूलो हुनुपर्छ ताकि JVM सँग जाभा मेटास्पेसको लागि ठाउँ छ जुन आफ्नै मेमोरीमा रहन्छ र काफ्काले सक्रिय रूपमा प्रयोग गर्ने अपरेटिङ सिस्टम पृष्ठ क्यासको लागि। हाम्रा परीक्षणहरूमा हामीले प्यारामिटरहरू सहित काफ्का ब्रोकरहरू सुरू गर्यौं -Xmx4G -Xms2G, र पोडको लागि मेमोरी सीमा थियो 10 Gi। कृपया ध्यान दिनुहोस् कि JVM को लागि मेमोरी सेटिङहरू स्वचालित रूपमा प्रयोग गरेर प्राप्त गर्न सकिन्छ -XX:MaxRAMPercentage и -X:MinRAMPercentage, पोडको लागि मेमोरी सीमामा आधारित।

ब्रोकर प्रोसेसर सेटिङहरू

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

लोड जेनेरेसन उपकरण

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

बेन्चमार्किङ

प्रदर्शन मापन एक पुनरावृत्ति प्रक्रिया हो जसमा निम्न चरणहरू समावेश छन्:

• पूर्वाधार स्थापना (EKS क्लस्टर, काफ्का क्लस्टर, लोड उत्पादन उपकरण, साथै Prometheus र Grafana);
• संकलित प्रदर्शन सूचकहरूमा अनियमित विचलनहरू फिल्टर गर्न निश्चित अवधिको लागि लोड उत्पन्न गर्दै;
• अवलोकन गरिएको कार्यसम्पादन सूचकहरूमा आधारित ब्रोकरको पूर्वाधार र कन्फिगरेसन समायोजन गर्दै;
• काफ्का क्लस्टर थ्रुपुटको आवश्यक स्तर प्राप्त नभएसम्म प्रक्रिया दोहोर्याउनुहोस्। एकै समयमा, यो लगातार पुन: उत्पादन योग्य हुनुपर्दछ र थ्रुपुटमा न्यूनतम भिन्नताहरू प्रदर्शन गर्नुपर्दछ।

अर्को खण्डले परीक्षण क्लस्टर बेन्चमार्किङ प्रक्रियाको क्रममा प्रदर्शन गरिएका चरणहरू वर्णन गर्दछ।

उपकरणहरू

निम्न उपकरणहरू छिटो आधारभूत कन्फिगरेसन डिप्लोय गर्न, लोड उत्पन्न गर्न र प्रदर्शन मापन गर्न प्रयोग गरियो:

• Banzai क्लाउड पाइपलाइन Amazon c बाट EKS क्लस्टर व्यवस्थित गर्नका लागि Prometheus (काफ्का र पूर्वाधार मेट्रिक्स सङ्कलन गर्न) र ग्राफाना (यी मेट्रिक्स कल्पना गर्न)। हामीले फाइदा उठायौं एकीकृत в पाइपलाइन सेवाहरू जसले संघीय निगरानी, ​​केन्द्रीकृत लग सङ्कलन, भेद्यता स्क्यानिङ, विपद् रिकभरी, इन्टरप्राइज-ग्रेड सुरक्षा र अधिक प्रदान गर्दछ।
• संगरेनेल - काफ्का क्लस्टर लोड परीक्षणको लागि एउटा उपकरण।
• काफ्का मेट्रिक्स र पूर्वाधारको दृश्यावलोकनका लागि ग्राफाना ड्यासबोर्डहरू: कुबर्नेट्स काफ्का, नोड निर्यातक.
• Kubernetes मा Kafka क्लस्टर सेटअप गर्ने सबैभन्दा सजिलो तरिकाको लागि Supertubes CLI। चिडियाखाना, काफ्का अपरेटर, दूत र अन्य धेरै कम्पोनेन्टहरू स्थापना गरिएका छन् र कुबर्नेट्समा उत्पादन-तयार काफ्का क्लस्टर चलाउन ठीकसँग कन्फिगर गरिएका छन्।
  • स्थापनाको लागि सुपरट्यूब CLI दिइएको निर्देशन प्रयोग गर्नुहोस् यहाँ.

EKS क्लस्टर

समर्पित कार्यकर्ता नोडहरूसँग EKS क्लस्टर तयार गर्नुहोस् c5.4x ठूलो काफ्का ब्रोकरहरूसँग पोडहरूका लागि विभिन्न उपलब्धता क्षेत्रहरूमा, साथै लोड जनरेटर र अनुगमन पूर्वाधारहरूको लागि समर्पित नोडहरू।

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

एक पटक EKS क्लस्टर माथि र चालू भएपछि, यसको एकीकृत सक्षम गर्नुहोस् निगरानी सेवा - उनले प्रोमेथियस र ग्राफानालाई क्लस्टरमा तैनात गर्नेछिन्।

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

सुपरट्यूब CLI प्रयोग गरी EKS मा काफ्का प्रणाली कम्पोनेन्टहरू (जुकीपर, काफ्का-अपरेटर) स्थापना गर्नुहोस्:

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

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

पूर्वनिर्धारित रूपमा, EKS प्रकारको EBS भोल्युमहरू प्रयोग गर्दछ 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 काफ्का ब्रोकरहरूद्वारा सन्देशका सबै सिङ्क्रोनाइज्ड प्रतिकृतिहरू प्राप्त र पुष्टि भएपछि प्रकाशन सफल मानिन्छ। यसको मतलब यो हो कि बेन्चमार्कमा हामीले सन्देशहरू प्राप्त गर्ने नेताहरूको गति मात्र मापन गरेका छैनौं, तर तिनीहरूका अनुयायीहरूले सन्देशहरू नक्कल गरिरहेका छन्। यस परीक्षणको उद्देश्य उपभोक्ता पढ्ने गतिको मूल्याङ्कन गर्नु होइन (उपभोक्ताहरू) भर्खरै प्राप्त सन्देशहरू जुन अझै पनि OS पृष्ठ क्यासमा रहन्छ, र डिस्कमा भण्डारण गरिएका सन्देशहरूको पढ्ने गतिसँग यसको तुलना।
• लोड जेनेरेटरले समानान्तरमा २० जना कामदारहरू चलाउँछन् (-workers=20)। प्रत्येक कार्यकर्ताले 5 उत्पादकहरू समावेश गर्दछ जसले काफ्का क्लस्टरमा कामदारको जडान साझा गर्दछ। नतिजाको रूपमा, प्रत्येक जेनेरेटरमा 100 उत्पादकहरू छन्, र तिनीहरू सबैले काफ्का क्लस्टरमा सन्देशहरू पठाउँछन्।

क्लस्टरको स्वास्थ्य अनुगमन

काफ्का क्लस्टरको लोड परीक्षणको क्रममा, हामीले कुनै पोड रिस्टार्ट नभएको, सिङ्कको बाहिरको प्रतिकृतिहरू र न्यूनतम उतार-चढावको साथ अधिकतम थ्रुपुट नभएको सुनिश्चित गर्न यसको स्वास्थ्यको पनि निरीक्षण गर्यौं:

• लोड जनरेटरले प्रकाशित सन्देशहरूको संख्या र त्रुटि दर बारे मानक तथ्याङ्कहरू लेख्छ। त्रुटि दर समान रहनु पर्छ 0,00%.
• क्रूज नियन्त्रण, काफ्का-अपरेटर द्वारा तैनात, एक ड्यासबोर्ड प्रदान गर्दछ जहाँ हामी क्लस्टर को स्थिति पनि निगरानी गर्न सक्छौं। यो प्यानल हेर्नको लागि:

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

• ISR स्तर ("इन-सिंक" प्रतिकृतिहरूको संख्या) संकुचन र विस्तार ० बराबर छ।

मापन परिणामहरू

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

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

JVM भर्चुअल मेसिनको मेमोरी खपत 2 GB भन्दा बढी थिएन:

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

नोडहरू द्वारा मेमोरी प्रयोगको डेटाबाट, यसले प्रणाली बफरिङ र क्यासिङले ~ 10-15 GB लियो:

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

सन्देशको आकार घट्दै जाँदा, थ्रुपुट लगभग 15-20% ले घट्छ: प्रत्येक सन्देशलाई प्रशोधन गर्न बिताएको समयले यसलाई असर गर्छ। साथै, प्रोसेसर लोड लगभग दोब्बर भएको छ।

ब्रोकर नोडहरूमा अझै पनि प्रयोग नगरिएका कोरहरू भएकाले, काफ्का कन्फिगरेसन परिवर्तन गरेर कार्यसम्पादन सुधार गर्न सकिन्छ। यो सजिलो काम होइन, त्यसैले थ्रुपुट बढाउनको लागि ठूला सन्देशहरूसँग काम गर्नु राम्रो हुन्छ।

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

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

JVM मेसिनको मेमोरी खपत 2 GB भन्दा कम रह्यो:

ड्राइभको साथ दलालहरूको काम विभाजनको असंतुलनबाट प्रभावित भएको थियो:

निष्कर्ष

माथि प्रस्तुत गरिएको पुनरावृत्ति दृष्टिकोण सयौं उपभोक्ताहरू, पुन: विभाजन, रोलिङ अद्यावधिकहरू, पोड पुन: सुरु, आदि समावेश थप जटिल परिदृश्यहरू कभर गर्न विस्तार गर्न सकिन्छ। यी सबैले हामीलाई विभिन्न परिस्थितिहरूमा काफ्का क्लस्टरको क्षमताहरूको सीमाहरू मूल्याङ्कन गर्न, यसको सञ्चालनमा अवरोधहरू पहिचान गर्न र तिनीहरूलाई लड्ने तरिकाहरू पत्ता लगाउन अनुमति दिन्छ।

हामीले छिटो र सजिलैसँग क्लस्टरलाई डिप्लोय गर्न, यसलाई कन्फिगर गर्न, ब्रोकरहरू र विषयहरू थप्न/हटाउन, अलर्टहरूमा प्रतिक्रिया दिन, र काफ्काले सामान्य रूपमा Kubernetes मा ठीकसँग काम गर्छ भनी सुनिश्चित गर्न Supertubes डिजाइन गरेका छौं। हाम्रो लक्ष्य तपाईलाई मुख्य कार्य ("उत्पन्न" र "उपभोग" काफ्का सन्देशहरू) मा ध्यान केन्द्रित गर्न मद्दत गर्नु हो, र सबै कडा परिश्रम सुपरट्यूब र काफ्का अपरेटरमा छोड्नुहोस्।

यदि तपाइँ Banzai क्लाउड टेक्नोलोजीहरू र खुला स्रोत परियोजनाहरूमा रुचि राख्नुहुन्छ भने, कम्पनीको सदस्यता लिनुहोस् GitHub, LinkedIn वा twitter.

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «K8s मा Redis अपरेटरसँगको एउटा कथा र यस डाटाबेसबाट डाटा विश्लेषण गर्नका लागि उपयोगिताहरूको सानो-समीक्षा»;
• «RabbitMQ को Kubernetes मा सिमलेस माइग्रेसन»;
• «CoreOS बाट zetcd: ZooKeeper लाई...etcd भण्डारणको साथ प्रतिस्थापन गर्दै"।

स्रोत: www.habr.com