कुबर्नेट्समधील काफ्का क्लस्टरसाठी योग्य आकार निश्चित करणे

नोंद. अनुवाद: या लेखात, Banzai Cloud ने काफ्काला Kubernetes मध्ये वापरणे सोपे करण्यासाठी त्याची सानुकूल साधने कशी वापरली जाऊ शकतात याचे उदाहरण सामायिक केले आहे. खालील सूचना स्पष्ट करतात की तुम्ही तुमच्या पायाभूत सुविधांचा इष्टतम आकार कसा ठरवू शकता आणि आवश्यक थ्रूपुट प्राप्त करण्यासाठी काफ्का स्वतःच कॉन्फिगर करू शकता.

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

तुमच्या क्लस्टरमध्ये सुपरट्यूब वापरून पहा:

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

किंवा संपर्क करा दस्तऐवजीकरण. आपण काफ्काच्या काही क्षमतांबद्दल देखील वाचू शकता, ज्याचे कार्य सुपरट्यूब आणि काफ्का ऑपरेटर वापरून स्वयंचलित आहे. आम्ही त्यांच्याबद्दल ब्लॉगवर आधीच लिहिले आहे:

• अरे नाही! कुबर्नेट्ससाठी अजून एक काफ्का ऑपरेटर;
• प्रोमिथियस मेट्रिक्सवर आधारित काफ्काचे निरीक्षण करा आणि ऑपरेट करा;
• Kubernetes वर काफ्का रॅक जागरूकता;
• Istio - बेंचमार्क वर अपाचे काफ्का चालवणे;
• काफ्का ऑपरेटरसह वापरकर्ता प्रमाणीकृत आणि प्रवेश नियंत्रित क्लस्टर्स;
• Kubernetes वर Kafka रोलिंग अपग्रेड आणि डायनॅमिक कॉन्फिगरेशन;
• काफ्कासाठी दूत प्रोटोकॉल फिल्टर, मेशेड.

जेव्हा तुम्ही Kubernetes वर काफ्का क्लस्टर उपयोजित करण्याचा निर्णय घ्याल, तेव्हा तुम्हाला अंतर्निहित पायाभूत सुविधांचा इष्टतम आकार ठरवण्याचे आव्हान आणि थ्रुपुट आवश्यकता पूर्ण करण्यासाठी तुमच्या काफ्का कॉन्फिगरेशनमध्ये सुधारणा करण्याची आवश्यकता असेल. मेमरी, प्रोसेसर, डिस्क स्पीड, नेटवर्क बँडविड्थ इ. यांसारख्या मूलभूत संरचना घटकांच्या कार्यप्रदर्शनावरून प्रत्येक ब्रोकरची कमाल कामगिरी निर्धारित केली जाते.

तद्वतच, ब्रोकर कॉन्फिगरेशन असे असावे की सर्व पायाभूत घटकांचा त्यांच्या कमाल क्षमतेनुसार वापर केला जाईल. तथापि, वास्तविक जीवनात हा सेटअप खूपच गुंतागुंतीचा आहे. एक किंवा दोन घटकांचा (डिस्क, मेमरी किंवा प्रोसेसर) जास्तीत जास्त वापर करण्यासाठी वापरकर्ते ब्रोकर कॉन्फिगर करतील अशी अधिक शक्यता आहे. साधारणपणे सांगायचे तर, ब्रोकर कमाल परफॉर्मन्स दाखवतो जेव्हा त्याचे कॉन्फिगरेशन सर्वात हळू घटक त्याच्या पूर्ण मर्यादेपर्यंत वापरण्याची परवानगी देते. अशा प्रकारे एक दलाल हाताळू शकणार्‍या भाराची आपल्याला अंदाजे कल्पना येऊ शकते.

सैद्धांतिकदृष्ट्या, दिलेला भार हाताळण्यासाठी आवश्यक असलेल्या दलालांच्या संख्येचाही आम्ही अंदाज लावू शकतो. तथापि, सराव मध्ये विविध स्तरांवर इतके कॉन्फिगरेशन पर्याय आहेत की विशिष्ट कॉन्फिगरेशनच्या संभाव्य कार्यक्षमतेचे मूल्यांकन करणे खूप कठीण (अशक्य नसल्यास) आहे. दुसऱ्या शब्दांत, काही दिलेल्या कामगिरीवर आधारित कॉन्फिगरेशनची योजना करणे खूप कठीण आहे.

सुपरट्यूब वापरकर्त्यांसाठी, आम्ही सहसा खालील दृष्टिकोन घेतो: आम्ही काही कॉन्फिगरेशन (पायाभूत सुविधा + सेटिंग्ज) सह प्रारंभ करतो, नंतर त्याचे कार्यप्रदर्शन मोजतो, ब्रोकर सेटिंग्ज समायोजित करतो आणि प्रक्रिया पुन्हा करा. पायाभूत सुविधांचा सर्वात मंद घटक पूर्णपणे वापरला जाईपर्यंत हे घडते.

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

हा लेख सुरुवातीच्या कॉन्फिगरेशनमधील सर्वात धीमे घटकांचा जास्तीत जास्त फायदा घेण्यासाठी आणि काफ्का क्लस्टरच्या थ्रूपुटचे मोजमाप करण्यासाठी आम्ही उचललेल्या चरणांबद्दल बोलेल. अत्यंत लवचिक कॉन्फिगरेशनसाठी किमान तीन कार्यरत दलाल आवश्यक आहेत (min.insync.replicas=3), तीन वेगवेगळ्या प्रवेशयोग्यता झोनमध्ये वितरीत केले. कुबर्नेट्स इन्फ्रास्ट्रक्चर कॉन्फिगर, स्केल आणि मॉनिटर करण्यासाठी, आम्ही हायब्रिड क्लाउडसाठी आमचे स्वतःचे कंटेनर व्यवस्थापन प्लॅटफॉर्म वापरतो - पाइपलाइन. हे ऑन-प्रिमाइसेस (बेअर मेटल, व्हीएमवेअर) आणि पाच प्रकारचे क्लाउड (अलिबाबा, AWS, Azure, Google, Oracle) तसेच त्यांच्या कोणत्याही संयोजनास समर्थन देते.

काफ्का क्लस्टर इन्फ्रास्ट्रक्चर आणि कॉन्फिगरेशनवर विचार

खालील उदाहरणांसाठी, आम्ही क्लाउड प्रदाता म्हणून AWS आणि Kubernetes वितरण म्हणून EKS निवडले. वापरून समान कॉन्फिगरेशन लागू केले जाऊ शकते P.K.E. - CNCF द्वारे प्रमाणित, Banzai Cloud कडून Kubernetes वितरण.

डिस्क

अॅमेझॉन विविध ऑफर देते ईबीएस व्हॉल्यूम प्रकार. मुळात gp2 и io1 तथापि, उच्च थ्रुपुट सुनिश्चित करण्यासाठी SSD ड्राइव्ह आहेत gp2 जमा क्रेडिट्स वापरतात (I/O क्रेडिट्स), म्हणून आम्ही प्रकाराला प्राधान्य दिले io1, जे सातत्यपूर्ण उच्च थ्रुपुट ऑफर करते.

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

काफ्काचे कार्यप्रदर्शन ऑपरेटिंग सिस्टमच्या पृष्ठ कॅशेवर खूप अवलंबून आहे, म्हणून आम्हाला ब्रोकर (JVM) आणि पृष्ठ कॅशेसाठी पुरेशी मेमरी असलेली उदाहरणे आवश्यक आहेत. उदाहरण c5.2x मोठा - चांगली सुरुवात, कारण त्यात 16 GB मेमरी आहे आणि EBS सह काम करण्यासाठी अनुकूलित. त्याचा गैरसोय असा आहे की ते दर 30 तासांनी केवळ 24 मिनिटांपेक्षा जास्त कार्यप्रदर्शन प्रदान करण्यास सक्षम आहे. तुमच्या वर्कलोडला दीर्घ कालावधीसाठी सर्वोच्च कामगिरीची आवश्यकता असल्यास, तुम्ही इतर उदाहरण प्रकारांचा विचार करू शकता. नेमकं तेच केलं, थांबून c5.4x मोठा. हे जास्तीत जास्त थ्रुपुट प्रदान करते 593,75 Mb/s. 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 वर Kafka आवृत्ती 2.13 (Scala 11) समाविष्ट आहे.

जर तुम्हाला कुबर्नेट्सवर 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);
• संकलित कार्यप्रदर्शन निर्देशकांमधील यादृच्छिक विचलन फिल्टर करण्यासाठी विशिष्ट कालावधीसाठी लोड तयार करणे;
• ब्रोकरच्या पायाभूत सुविधा आणि कॉन्फिगरेशनचे निरीक्षण केलेल्या कामगिरी निर्देशकांवर आधारित समायोजन करणे;
• काफ्का क्लस्टर थ्रूपुटची आवश्यक पातळी प्राप्त होईपर्यंत प्रक्रियेची पुनरावृत्ती करा. त्याच वेळी, ते सातत्याने पुनरुत्पादक असणे आवश्यक आहे आणि थ्रूपुटमध्ये कमीतकमी फरक प्रदर्शित करणे आवश्यक आहे.

पुढील विभागात चाचणी क्लस्टर बेंचमार्किंग प्रक्रियेदरम्यान केलेल्या चरणांचे वर्णन केले आहे.

साधने

बेसलाइन कॉन्फिगरेशन त्वरित उपयोजित करण्यासाठी, भार निर्माण करण्यासाठी आणि कार्यप्रदर्शन मोजण्यासाठी खालील साधने वापरली गेली:

• बनझाई मेघ पाइपलाइन Amazon वरून EKS क्लस्टर आयोजित करण्यासाठी c Prometheus (काफ्का आणि पायाभूत सुविधा मेट्रिक्स गोळा करण्यासाठी) आणि ग्राफाना (या मेट्रिक्सची कल्पना करण्यासाठी). आम्ही फायदा घेतला एकात्मिक в पाइपलाइन सेवा ज्या फेडरेटेड मॉनिटरिंग, सेंट्रलाइज्ड लॉग कलेक्शन, भेद्यता स्कॅनिंग, आपत्ती पुनर्प्राप्ती, एंटरप्राइझ-ग्रेड सुरक्षा आणि बरेच काही प्रदान करतात.
• संगरेनेल — काफ्का क्लस्टर लोड चाचणीसाठी एक साधन.
• काफ्का मेट्रिक्स आणि इन्फ्रास्ट्रक्चर व्हिज्युअलायझ करण्यासाठी ग्राफना डॅशबोर्ड: कुबर्नेट्स काफ्का, नोड निर्यातक.
• Kubernetes वर काफ्का क्लस्टर सेट करण्याचा सर्वात सोपा मार्ग सुपरट्यूब 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 पृष्ठ कॅशेमध्ये आहेत आणि डिस्कवर संग्रहित संदेश वाचण्याच्या गतीशी त्याची तुलना.
• लोड जनरेटर 20 कामगार समांतर चालवतात (-workers=20). प्रत्येक कामगारामध्ये 5 उत्पादक असतात जे काफ्का क्लस्टरशी कामगाराचे कनेक्शन सामायिक करतात. परिणामी, प्रत्येक जनरेटरमध्ये 100 उत्पादक आहेत आणि ते सर्व काफ्का क्लस्टरला संदेश पाठवतात.

क्लस्टरच्या आरोग्यावर लक्ष ठेवणे

काफ्का क्लस्टरच्या लोड चाचणी दरम्यान, आम्ही पॉड रीस्टार्ट, सिंकच्या बाहेरच्या प्रतिकृती नाहीत आणि कमीतकमी चढ-उतारांसह जास्तीत जास्त थ्रूपुट नसल्याचे सुनिश्चित करण्यासाठी त्याच्या आरोग्याचे परीक्षण केले:

• लोड जनरेटर प्रकाशित झालेल्या संदेशांची संख्या आणि त्रुटी दर याबद्दल मानक आकडेवारी लिहितो. त्रुटी दर समान राहिला पाहिजे 0,00%.
• जलपर्यटन नियंत्रण, kafka-operator द्वारे तैनात केलेले, डॅशबोर्ड प्रदान करते जेथे आम्ही क्लस्टरच्या स्थितीचे परीक्षण देखील करू शकतो. हे पॅनेल पाहण्यासाठी हे करा:

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

• ISR पातळी ("इन-सिंक" प्रतिकृतींची संख्या) संकुचित आणि विस्तार 0 च्या समान आहेत.

मापन परिणाम

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 च्या खाली राहिला:

विभाजनांच्या असंतुलनामुळे ड्राइव्हसह दलालांच्या कामावर परिणाम झाला:

निष्कर्ष

शेकडो ग्राहक, पुनर्विभाजन, रोलिंग अपडेट्स, पॉड रीस्टार्ट इत्यादी अधिक जटिल परिस्थितींचा समावेश करण्यासाठी वर सादर केलेला पुनरावृत्तीचा दृष्टीकोन विस्तारित केला जाऊ शकतो. हे सर्व आम्हाला विविध परिस्थितींमध्ये काफ्का क्लस्टरच्या क्षमतांच्या मर्यादांचे मूल्यांकन करण्यास, त्याच्या ऑपरेशनमधील अडथळे ओळखण्यास आणि त्यांच्याशी लढण्याचे मार्ग शोधण्याची परवानगी देते.

आम्ही एक क्लस्टर जलद आणि सहजपणे उपयोजित करण्यासाठी, ते कॉन्फिगर करण्यासाठी, ब्रोकर आणि विषय जोडण्यासाठी/काढण्यासाठी, अलर्टला प्रतिसाद देण्यासाठी आणि सर्वसाधारणपणे काफ्का कुबर्नेट्सवर योग्यरित्या कार्य करते याची खात्री करण्यासाठी आम्ही सुपरट्यूब डिझाइन केले आहे. आमचे ध्येय तुम्हाला मुख्य कार्यावर लक्ष केंद्रित करण्यात मदत करणे आहे (काफ्का संदेश “व्युत्पन्न करा” आणि “उपभोग”), आणि सर्व कठोर परिश्रम सुपरट्यूब आणि काफ्का ऑपरेटरवर सोडून द्या.

तुम्हाला बॅनझाई क्लाउड तंत्रज्ञान आणि मुक्त स्त्रोत प्रकल्पांमध्ये स्वारस्य असल्यास, येथे कंपनीची सदस्यता घ्या GitHub, संलग्न किंवा Twitter.

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• «K8s मधील Redis ऑपरेटरसह एक कथा आणि या डेटाबेसमधील डेटाचे विश्लेषण करण्यासाठी उपयुक्ततेचे एक लहान-पुनरावलोकन";
• «RabbitMQ चे Kubernetes मध्ये अखंड स्थलांतर";
• «CoreOS कडून zetcd: ZooKeeper ची जागा...etcd स्टोरेजसह».

स्त्रोत: www.habr.com