अपाचे काफ्का की बेंचमार्किंग: प्रदर्शन-प्रति-मूल्य

इस लेख में, मैं अपाचे काफ़्का के लिए वातावरण की तुलना करने वाला एक अध्ययन प्रस्तुत करता हूँ। अंतिम लक्ष्य सबसे प्रभावी सेटअप ढूँढना और सर्वोत्तम मूल्य-प्रदर्शन अनुपात प्राप्त करना है।

हमारा डेटा प्लेटफ़ॉर्म बड़े डेटा सेट के लिए विश्लेषणात्मक प्लेटफ़ॉर्म बनाने के लिए प्रबंधित सेवाएँ प्रदान करता है, जो अन्य बाज़ार समाधानों के साथ प्रतिस्पर्धा करता है। प्रतिस्पर्धी बने रहने के लिए, हम अपनी ताकत को पहचानने और बेहतर बनाने के लिए नियमित रूप से आंतरिक शोध करते हैं, जिससे बेहतर सौदे सुनिश्चित होते हैं। यह लेख ऐसे ही एक अध्ययन को दर्शाता है। वर्तमान में, हमारा प्लेटफ़ॉर्म क्लाउड प्रदाताओं के रूप में AWS और GCP का समर्थन करता है। दोनों कई कंप्यूट जनरेशन और दो CPU आर्किटेक्चर (Intel और AMD के साथ x86, और ARM) प्रदान करते हैं। मैं नए प्रोसेसर पर नए संस्करणों के प्रदर्शन का मूल्यांकन करने के लिए विभिन्न जावा वर्चुअल मशीन (JVM) का उपयोग करके इन सेटअपों की तुलना करता हूँ।

यदि आप TL;DR चाहते हैं: ARM कमाल का है। आधुनिक महंगी वास्तुकला का मतलब हमेशा “बेहतर” नहीं होता। आप सीधे परिणामों पर जा सकते हैं या कार्यप्रणाली और सेटअप के बारे में अधिक जानने के लिए आगे बढ़ सकते हैं।

क्रियाविधि

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

मेरा लक्ष्य सबसे दिलचस्प परिणामों की पहचान करने के लिए विभिन्न कॉन्फ़िगरेशन का परीक्षण करना है। इसके लिए, मैं प्रारंभिक निष्कर्षों को फ़िल्टर करने के लिए परीक्षण मैट्रिक्स के विचार का उपयोग करता हूँ। मैं प्रदर्शन को और बेहतर बनाने के लिए परफ़ और eBPF जैसे टूल का उपयोग करके इन निष्कर्षों का गहराई से विश्लेषण करूँगा।

परीक्षण मामले

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

मैंने पहली तुलना के लिए ये संस्करण चुने:

• ओपनजेडीके 11 (पूर्वव्यापी तुलना के लिए, हालांकि यह पुराना हो चुका है)
• ओपनजेडीके 17 (वर्तमान में उपयोग में आने वाला जेवीएम)
• अमेज़न कोरेटो 11.0.22-amzn (एक वैकल्पिक पूर्वव्यापी तुलना)
• अमेज़न कोरेटो 17.0.10-amzn (हमारे वर्तमान संस्करण का एक विकल्प)
• अमेज़न कोरेटो 21.0.2-amzn (एक नया LTS संस्करण जो बेहतर होना चाहिए)

एक बार संस्करण निर्धारित हो जाने के बाद, मैंने अमेज़ॅन कोरेटो और ओपनजेडीके का उपयोग करके काफ़्का छवियों के निर्माण के लिए कुछ स्क्रिप्ट तैयार कीं।

छवि सेटिंग्स

बेंचमार्किंग परीक्षणों के लिए, मैंने विशिष्ट प्रदर्शन मीट्रिक पर ध्यान केंद्रित करने के लिए काफ़्का सेटिंग्स को बदल दिया। मैं [JVM] x [instance_type] x [architecture] x [cloud_provider] के विभिन्न संयोजनों का परीक्षण करना चाहता था, इसलिए नेटवर्क कनेक्टिविटी और डिस्क प्रदर्शन के प्रभावों को कम करना महत्वपूर्ण था। मैंने डेटा स्टोरेज के लिए tmpfs के साथ कंटेनर चलाकर ऐसा किया:

 podman run -ti \ --network=host \ --mount type=tmpfs,destination=/tmp \ kfbench:3.6.1-21.0.2-amzn-arm64

स्वाभाविक रूप से, यह सेटअप उत्पादन के लिए नहीं है, लेकिन CPU और मेमोरी की बाधाओं को अलग करना आवश्यक था। सबसे अच्छा तरीका है परीक्षणों से नेटवर्क और डिस्क प्रभावों को हटाना। अन्यथा, वे कारक परिणामों को विकृत कर देंगे।

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

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

इसके अतिरिक्त, मैंने मेमोरी से डेटा को अधिक बार निकालने के लिए कुछ अतिरिक्त काफ़्का सेटिंग्स लागू कीं:

 ############################# Benchmark Options ############################# # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.bytes # Chaged from 1GB to 256MB to rotate files faster log.segment.bytes = 268435456 # https://kafka.apache.org/documentation/#brokerconfigs_log.retention.bytes # Changed from -1 (unlimited) to 1GB evict them because we run in tmpfs log.retention.bytes = 1073741824 # Changed from 5 minutes (300000ms) to delete outdated data faster log.retention.check.interval.ms=1000 # Evict all data after 15 seconds (default is -1 and log.retention.hours=168 which is ~7 days) log.retention.ms=15000 # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.delete.delay.ms # Changed from 60 seconds delay to small value to prevent memory overflows log.segment.delete.delay.ms = 0

यहां परिवर्तनों का सारांश दिया गया है:

• डेटा को तेज़ी से हटाने के लिए लॉग रिटेंशन समय 15 सेकंड पर सेट किया गया है, और tmpfs में स्टोरेज को प्रबंधित करने के लिए लॉग रिटेंशन आकार 1 GB तक सीमित है। फ़ाइलों को तेज़ी से घुमाने के लिए लॉग सेगमेंट का आकार भी 256 MB में बदला गया है
• पुराने डेटा को तुरंत हटाने के लिए अवधारण जांच अंतराल को 1 सेकंड तक कम कर दिया गया है
• मेमोरी संबंधी समस्याओं को रोकने के लिए सेगमेंट डिलीट विलंब को 0 पर सेट किया गया है

यह कॉन्फ़िगरेशन उत्पादन उपयोग के लिए उपयुक्त नहीं है, लेकिन यह हमारे बेंचमार्क परीक्षणों के लिए महत्वपूर्ण है क्योंकि यह अप्रासंगिक कारकों के प्रभाव को कम करता है।

इंस्टेंस प्रकार

डबलक्लाउड में, इस लेख को लिखने के समय तक, हम कम्प्यूट संसाधनों की इन प्रमुख पीढ़ियों का समर्थन करते हैं:

• s1 परिवार : m5a इंस्टेंस (जिसमें i1 इंटेल प्रोसेसर के साथ m5 का प्रतिनिधित्व करता है)
• s2 परिवार : m6a इंस्टेंस (i2 इंटेल प्रोसेसर के साथ m6i का प्रतिनिधित्व करता है)
• sg1 परिवार : AMD रोम प्रोसेसर के साथ GCP n2-मानक इंस्टेंस

ग्रैविटॉन प्रोसेसर के लिए, हम समर्थन करते हैं:

• g1 परिवार : m6g इंस्टैंस (ग्रेविटॉन 2)
• g2 परिवार : m7g इंस्टैंस (ग्रेविटॉन 3)

इसके अतिरिक्त, मैंने एम्पीयर अल्ट्रा पर ग्रेविटन के विकल्प के रूप में GCP पर t2a इंस्टेंस का परीक्षण किया। AWS के सीमित क्षेत्रीय समर्थन के कारण हम अपने ग्राहकों को ये ऑफ़र नहीं करते हैं, लेकिन मैंने प्रदर्शन की तुलना करने के लिए इन्हें बेंचमार्क में शामिल किया है। यदि आप “सही” क्षेत्रों में से किसी एक में हैं तो ये एक अच्छा विकल्प हो सकता है।

बेंचमार्क टूल

बेंचमार्किंग के लिए, मैंने franz-go लाइब्रेरी और उदाहरण के आधार पर एक हल्का उपकरण विकसित किया। यह उपकरण बिना किसी बाधा के काफ़्का को कुशलतापूर्वक संतृप्त करता है।

हालांकि librdkafka अपनी विश्वसनीयता और लोकप्रियता के लिए जाना जाता है, लेकिन cgo के साथ संभावित समस्याओं के कारण मैंने इसे टाल दिया।

परीक्षा

काफ़्का अपनी स्केलेबिलिटी के लिए प्रसिद्ध है, जिससे विषयों को कई विभाजनों में विभाजित किया जा सकता है ताकि ब्रोकर्स में कार्यभार को कुशलतापूर्वक क्षैतिज रूप से वितरित किया जा सके। हालाँकि, मैंने प्रदर्शन-से-मूल्य अनुपात पर हमारे विशेष ध्यान के लिए एकल-कोर प्रदर्शन का मूल्यांकन करने पर ध्यान केंद्रित किया।

इसलिए, परीक्षणों में व्यक्तिगत कोर क्षमताओं का पूर्ण उपयोग करने के लिए एकल विभाजन वाले विषयों का उपयोग किया गया।

प्रत्येक परीक्षण मामले में दो प्रकार शामिल थे:

• तुल्यकालिक उत्पादन: संदेश पावती की प्रतीक्षा करता है, कम विलंबता वाले वातावरण को मापने के लिए आदर्श है जहां मिलीसेकंड मायने रखते हैं, जैसे वास्तविक समय अनुप्रयोग
• एसिंक्रोनस उत्पादन: संदेशों को बफर करता है और उन्हें बैचों में भेजता है, जो काफ्का क्लाइंट के लिए विशिष्ट है जो 10-100 एमएस की सहनीय विलंबता के साथ वास्तविक समय की जरूरतों को संतुलित करता है

मैंने विषय विभाजन धागों को पूरी तरह से संतृप्त करने के लिए 8 KB संदेशों का उपयोग किया, जो एक औसत ग्राहक मामले से भी बड़ा था।

परिणाम

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

यह स्वीकार करना महत्वपूर्ण है कि क्लाउड प्रदाताओं की अतिरिक्त छूट के कारण वास्तविक परिणाम भिन्न हो सकते हैं। जब भी संभव हो, दोनों क्लाउड प्रदाताओं के लिए फ्रैंकफर्ट में परीक्षण किए गए (या नीदरलैंड में उन मामलों में जहां इंस्टेंस-प्रकार विकल्प प्रतिबंधित थे)।

चार्ट

सभी चार्ट पर, मैं इंस्टेंस के लिए पारंपरिक नामों का उपयोग करता हूँ, वही नाम जो उनके प्रदाता उपयोग करते हैं। इंस्टेंस को पहले क्लाउड प्रदाताओं (AWS, फिर GCP) और फिर पीढ़ी के अनुसार क्रमबद्ध किया जाता है: पुराने से नए तक।

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

AWS निष्कर्ष

एस1 परिवार: सबसे धीमा प्रदर्शन

AMD EPYC 7571 के साथ m5a-जनरेशन पर आधारित "पहली पीढ़ी" s1 इंस्टेंस, Q3 2019 से पहले के हैं, हमारे लीगेसी विकल्प हैं। वे फ्रैंकफर्ट में हमारे विकल्पों में सबसे कम कुशल और सबसे धीमे हैं, जिनकी ऑन-डिमांड लागत लगभग ~0.2080 €/घंटा है। नए s2 परिवार में संक्रमण, जिसकी लागत ~0.2070 €/घंटा है, मूल रूप से समान कीमत पर दोगुनी दक्षता प्रदान करता है। हम ग्राहकों को विश्लेषणात्मक अनुप्रयोगों के लिए क्वेरी समय और अंतर्ग्रहण गति को बढ़ाने के लिए इन अधिक लागत प्रभावी और प्रदर्शनकारी विकल्पों पर माइग्रेट करने के लिए प्रोत्साहित करते हैं।

g1 परिवार: s2 के बराबर दक्षता

G1 परिवार Graviton 2 पर आधारित है और ऐतिहासिक रूप से अच्छा मूल्य प्रदान करता है, लेकिन AMD प्रोसेसर के साथ नया S2 परिवार अब Apache Kafka के लिए इसकी दक्षता के स्तर से मेल खाता है। थोड़ा कम बैंडविड्थ और मामूली कीमत लाभ की पेशकश करने के बावजूद, G1 परिवार अब नए विकल्पों की तुलना में पुराना माना जाता है।

जी2 परिवार: बेहतर दक्षता

ग्रैविटन 3 द्वारा संचालित g2 परिवार अपनी बेहतरीन दक्षता के कारण हमारी शीर्ष अनुशंसा के रूप में सामने आता है। यह कुछ परिदृश्यों में s2 और i2 परिवारों से 39% तक बेहतर प्रदर्शन करता है, लगभग सभी क्षेत्रों में लागत प्रभावी समाधान प्रदान करता है, जो इसे अधिकांश अपाचे काफ़्का उपयोग मामलों के लिए आदर्श बनाता है। काफ़्का की विशिष्ट IO-बाउंड प्रकृति को देखते हुए, लागत बचत के लिए कम्प्यूटेशनल दक्षता को अनुकूलित करना महत्वपूर्ण साबित होता है। मैंने arm64 आर्किटेक्चर को अपनाने की बढ़ती प्रवृत्ति देखी है, हमारे लगभग आधे क्लस्टर पहले से ही इस नई तकनीक का लाभ उठा रहे हैं।

x86_64 दक्षता रुझान

परीक्षण से पता चलता है कि प्रत्येक नया AMD या Intel प्रोसेसर समग्र थ्रूपुट और विलंबता के मामले में सुधार करता है। इसके बावजूद, नए m6 और m7 पीढ़ियों के लिए दक्षता लाभ स्थिर हो गया है। हमारे परीक्षणों के अनुसार, m7 पीढ़ी भी, कुछ क्षेत्रों में संभावित रूप से कम विलंबता प्रदान करते हुए, g2 परिवार की तुलना में दक्षता में कम है।

m7a परिवार: विलंबता प्रदर्शन में अग्रणी

m7a परिवार कम विलंबता वाले अनुप्रयोगों में उत्कृष्ट है, जो थ्रूपुट और विलंबता के मामले में Intel और पिछली AMD दोनों पीढ़ियों से आगे है। हालांकि यह सार्वभौमिक रूप से उपलब्ध नहीं है, लेकिन यह आर्किटेक्चर प्रदर्शन को बढ़ाने में AMD की प्रगति को दर्शाता है। यदि आपके क्षेत्र में यह उपलब्ध है, तो बेहतर परिणामों के लिए m7a पर विचार करें।

जीसीपी निष्कर्ष

AWS के साथ दक्षता की तुलना

GCP इंस्टेंस में आमतौर पर उनके AWS विकल्पों की तुलना में कम दक्षता होती है। यह मेरे लिए एक बड़ी जानकारी थी, क्योंकि ग्राहक आमतौर पर विश्लेषणात्मक अनुप्रयोगों में इसकी लागत-प्रभावशीलता के लिए GCP को पसंद करते हैं, जिसके परिणामस्वरूप कम बिल आते हैं। हमारा sg1 परिवार n2-मानक पीढ़ी का उपयोग करता है, जो AWS s2 परिवार के बराबर है। हालाँकि, इस तुलना को अन्य इंस्टेंस प्रकारों तक बढ़ाने का मेरा प्रयास क्षेत्रीय उपलब्धता, विशेष रूप से c3 और n2 पीढ़ियों के लिए विवश था।

आर्म ताऊ प्रोसेसर: लागत-प्रभावशीलता

GCP के ताऊ प्रोसेसर का उपयोग करने वाले आर्म इंस्टेंस, ग्रैविटन 2 की तुलना में 5-7% दक्षता में सुधार प्रदान करते हैं, जो उन्हें आपके क्षेत्र में उपलब्ध होने पर एक उचित लागत-बचत विकल्प बनाता है। हालाँकि आर्म इंस्टेंस के लिए GCP समर्थन चार क्षेत्रों तक सीमित है, लेकिन यह g1 परिवार के लिए तुलनीय प्रदर्शन और दक्षता प्रदान करता है।

निरंतर उपयोग छूट

चूंकि अपाचे काफ्का क्लस्टर में वीएम का निरंतर उपयोग होता है, इसलिए निरंतर उपयोग छूट का लाभ उठाने से 20% तक की छूट मिलती है। यह एम्पीयर अल्ट्रा जैसी पुरानी कम्प्यूटेशनल पावर को भी दक्षता के मामले में ग्रैविटन 3 के साथ प्रतिस्पर्धी बनाता है। हालांकि, यहां सीधी तुलना करना मुश्किल है, क्योंकि अतिरिक्त AWS छूट भी लागू हो सकती है।

JVM अंतर्दृष्टि

मुझे लगा कि ARM आर्किटेक्चर पर नए JVM संस्करणों के साथ मैं एक महत्वपूर्ण सुधार देखूंगा। हालाँकि, ऐसा लगता है कि openjdk-11 और corretto-11 पहले से ही ARM के लिए काफी अनुकूलित हैं। चूँकि Kafka के नए संस्करणों के लिए Java 17 और उच्चतर की आवश्यकता होती है, इसलिए मैंने Java 17 पर स्विच किया, जिसके परिणामस्वरूप हमारे बेंचमार्क में लगभग 4-8% प्रदर्शन लाभ हुआ।

इसके अतिरिक्त, 21.0.2-amzn आशाजनक प्रतीत होता है, जो नए इंस्टेंस प्रकारों पर अतिरिक्त 10-20% प्रदर्शन वृद्धि प्रदान करता है।

निष्कर्ष

समय-समय पर, मैं हमारे उत्पादन क्लस्टरों के लिए इष्टतम समाधान खोजने और उपयोगी जानकारी एकत्र करने के लिए आंतरिक शोध करता हूँ। ARM आर्किटेक्चर की ओर बढ़ना प्रबंधित सेवाओं के लिए फायदेमंद है, क्योंकि इससे पैसे की बचत होती है और ऊर्जा का उपयोग कम होता है।

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