Kafka के लिए API Gateway का उपयोग करने के लाभों की खोज
Yuan Bao
March 31, 2023
Kafka का संक्षिप्त परिचय
Kafka मूल रूप से LinkedIn द्वारा एक वितरित मैसेजिंग सिस्टम के रूप में बनाया गया था जो Zookeeper समन्वय पर निर्भर करता था और इसमें कई पार्टीशन और रेप्लिका शामिल थे। बाद में इसे Apache Software Foundation को दान कर दिया गया। इसकी उत्कृष्ट थ्रूपुट, स्थायित्व और क्षैतिज स्केलिंग क्षमताओं के कारण, Kafka उद्योग में व्यापक रूप से अपनाया गया वितरित स्ट्रीम-प्रोसेसिंग प्लेटफॉर्म बन गया है।
Kafka के तीन प्राथमिक उपयोग केस हैं:
- मैसेजिंग सिस्टम: यह सबसे आम उपयोग केस है, जहां इसे बैकएंड माइक्रोसर्विसेज के बीच संदेश संचार के लिए उपयोग किया जाता है। Kafka सिस्टम डिकपलिंग, ट्रैफिक शेपिंग और एसिंक्रोनस संचार की अनुमति देता है।
- स्टोरेज सिस्टम: Kafka संदेशों को डिस्क पर स्टोर करता है और इसमें मल्टी-रेप्लिका सुविधा शामिल है, जिससे यह डेटा स्थायित्व सिस्टम के रूप में उपयोग के लिए उपयुक्त विकल्प बन जाता है। यह डेटा हानि के जोखिम को काफी कम कर देता है।
- स्ट्रीम-प्रोसेसिंग प्लेटफॉर्म: Kafka स्ट्रीम प्रोसेसिंग के लिए एक व्यापक लाइब्रेरी प्रदान करता है, जिसमें विंडोइंग, जॉइनिंग और ट्रांसफॉर्मेशन जैसे ऑपरेशन शामिल हैं।
Kafka की तकनीकी आर्किटेक्चर
एक मानक Kafka क्लस्टर में कई Producers, Consumers, Brokers और एक Zookeeper क्लस्टर होता है। Zookeeper Kafka क्लस्टर का मुख्य नियंत्रण घटक है, जो क्लस्टर मेटाडेटा और कंट्रोलर चुनावों का प्रबंधन करता है। Producers संदेशों को Brokers को भेजते हैं, जो संदेशों को डिस्क पर स्टोर करते हैं, जबकि Consumers Brokers से संदेशों को सब्सक्राइब करते हैं और उन्हें उपभोग करते हैं।
मुख्य अवधारणाएं
Kafka टॉपिक और पार्टीशन
Kafka में, संदेशों को टॉपिक्स द्वारा वर्गीकृत किया जाता है। Producers आमतौर पर संदेश भेजते समय एक टॉपिक निर्दिष्ट करते हैं, जबकि Consumers आमतौर पर संदेशों को उपभोग करने के लिए एक टॉपिक को सब्सक्राइब करते हैं।
एक टॉपिक आमतौर पर कई पार्टीशन से बना होता है, जिसमें प्रत्येक पार्टीशन में अलग-अलग संदेश होते हैं। जब एक संदेश Kafka को भेजा जाता है, तो यह पार्टीशनिंग नियमों के आधार पर उपयुक्त पार्टीशन में स्टोर हो जाता है। उचित पार्टीशनिंग नियमों को सेट करके, संदेशों को अलग-अलग पार्टीशन में समान रूप से वितरित किया जा सकता है।
Producer और Consumer
Producer संदेश भेजने वाले पक्ष को संदर्भित करता है, जो संदेश बनाने और उन्हें Kafka brokers को भेजने के लिए जिम्मेदार होता है।
Consumer संदेश प्राप्त करने वाले पक्ष को संदर्भित करता है, जो Kafka क्लस्टर के broker से कनेक्ट होने, एक विशेष टॉपिक को सब्सक्राइब करने और संदेशों को उपभोग करने के लिए जिम्मेदार होता है।
Kafka Brokers
एक Broker को Kafka का एक स्वतंत्र नोड या इंस्टेंस माना जा सकता है। एक Kafka क्लस्टर एक या अधिक Brokers से बना होता है।

Kafka को API गेटवे की आवश्यकता क्यों है
ज्यादातर मामलों में, जब Kafka को बैकएंड माइक्रोसर्विसेज के बीच मैसेज सिस्टम के रूप में उपयोग किया जाता है, तो डेवलपर्स को प्रोजेक्ट में उपयोग की जाने वाली भाषा के आधार पर अलग-अलग Kafka SDKs का चयन करना पड़ता है ताकि प्रोड्यूसर या कंज्यूमर क्लाइंट्स विकसित किए जा सकें।
हालांकि, इस दृष्टिकोण की कुछ सीमाएं हैं, जैसे कि जब क्लाइंट को सीधे Kafka से कनेक्ट करने की आवश्यकता होती है। ऐसे मामलों में, कॉलर और Kafka के बीच एक API गेटवे जोड़ने से सेवाओं को डिकपल करने में मदद मिल सकती है। इस तरह, कॉलर को Kafka या विशिष्ट संचार प्रोटोकॉल के बारे में चिंता करने की आवश्यकता नहीं होती है, जिससे कॉलिंग लागत कम हो जाती है। इसके अलावा, एक API गेटवे Kafka द्वारा एक्सपोज्ड APIs के लिए सुरक्षा समर्थन और ट्रैफिक नियंत्रण क्षमताएं प्रदान कर सकता है, जिससे Kafka सेवाओं की स्थिरता सुनिश्चित होती है।
Kafka से सीधे कनेक्ट करना
Kafka को मैसेज क्यू मिडलवेयर के रूप में उपयोग करते समय सीधे कनेक्ट करने से कई सीमाएं और जोखिम हो सकते हैं:
- अलग-अलग कंज्यूमर्स को Kafka के संचार प्रोटोकॉल को अनुकूलित करना होगा।
- Kafka एक्सपोज्ड APIs को सुरक्षित करने, ट्रैफिक नियंत्रण और अन्य मुद्दों के लिए समाधान प्रदान नहीं करता है। रेट-लिमिटिंग नीतियों के बिना, कुछ प्रोड्यूसर्स या कंज्यूमर्स अत्यधिक कंप्यूटिंग पावर और बैंडविड्थ का उपभोग कर सकते हैं।
- कंज्यूमर्स और प्रोड्यूसर्स दोनों को Kafka क्लस्टर टोपोलॉजी के बारे में जागरूक होना चाहिए, जो Kafka क्लस्टर में परिवर्तनों से प्रभावित हो सकता है।
API गेटवे Kafka की उपयोगिता को बढ़ाता है
संचार प्रोटोकॉल रूपांतरण
जब एक API गेटवे का उपयोग Kafka को प्रॉक्सी करने के लिए किया जाता है, तो क्लाइंट API गेटवे के साथ HTTP प्रोटोकॉल का उपयोग करके संचार करता है, जबकि API गेटवे Kafka के साथ Kafka के प्रोटोकॉल का उपयोग करके संचार करता है। API गेटवे क्लाइंट के संदेशों को Kafka के प्रोटोकॉल में परिवर्तित करता है, जिससे क्लाइंट को अलग-अलग Kafka संदेश प्रोटोकॉल को अनुकूलित करने की आवश्यकता नहीं होती है। यह विकास लागत को काफी कम कर देता है और उपयोग करने में अधिक सुविधाजनक बनाता है।
रेट लिमिटिंग
जब संसाधन सीमित होते हैं, तो Kafka नोड्स की सेवा क्षमता भी सीमित होती है। इस सीमा को पार करने से सेवा क्रैश हो सकती है और एक चेन रिएक्शन हो सकता है। रेट लिमिटिंग इससे बचने में मदद कर सकता है। पारंपरिक Kafka आर्किटेक्चर में, क्लाइंट SDKs के माध्यम से Kafka के साथ संचार करते हैं। हालांकि, यदि क्लाइंट्स या अनुरोधों की संख्या अधिक होती है, तो यह Kafka नोड्स की मशीन लोड को प्रभावित कर सकता है और Kafka की कार्यक्षमता की स्थिरता को प्रभावित कर सकता है। आर्किटेक्चर में एक API गेटवे जोड़ने से Kafka क्लस्टर के लिए विभिन्न आयामों में रेट-लिमिटिंग फंक्शन समर्थन को आसानी से जोड़ा जा सकता है, क्योंकि API गेटवे इस क्षेत्र में उत्कृष्ट हैं। इन क्षमताओं में शामिल हैं:
- फिक्स्ड टाइम विंडो एल्गोरिदम का उपयोग करके एक निर्दिष्ट समय सीमा के भीतर एकल क्लाइंट द्वारा सेवा के लिए किए जाने वाले अनुरोधों की कुल संख्या को सीमित करना।
- एकल क्लाइंट द्वारा एकल सेवा के लिए किए जाने वाले समवर्ती अनुरोधों की संख्या को सीमित करना।
- लीकी बकेट एल्गोरिदम का उपयोग करके एकल क्लाइंट द्वारा सेवा के लिए अनुरोध दर को सीमित करना।
इन रेट लिमिटिंग फंक्शन्स को लागू करके, Kafka नोड्स को प्रभावी ढंग से सुरक्षित किया जा सकता है, जिससे उनकी स्थिरता सुनिश्चित होती है।
प्रमाणीकरण समर्थन
प्रमाणीकरण भी एक API गेटवे की एक मजबूत विशेषता है। पारंपरिक Kafka आर्किटेक्चर में, अधिकांश Kafka पोर्ट्स को आंतरिक नेटवर्क के भीतर एक्सेस किया जाता है। यदि सार्वजनिक नेटवर्क से एक्सेस की आवश्यकता होती है, तो सुरक्षा सुनिश्चित करने के लिए जटिल कॉन्फ़िगरेशन की आवश्यकता होती है। Kafka को प्रॉक्सी करते समय API गेटवे की प्रमाणीकरण कार्यक्षमता का उपयोग करके Kafka-एक्सपोज्ड पोर्ट्स को सुरक्षित किया जा सकता है, साथ ही क्लाइंट एक्सेस को चुनिंदा रूप से अनुमति या अस्वीकार किया जा सकता है।
मॉनिटरिंग क्षमता
वर्तमान में Kafka के लिए कई मॉनिटरिंग उत्पाद उपलब्ध हैं, जैसे Kafka Eagle, Kafka Monitor, Kafka Manager, आदि। इनमें से प्रत्येक के अपने फायदे और नुकसान हैं। एक सार्वभौमिक मॉनिटरिंग क्षमता प्राप्त करना चुनौतीपूर्ण है, और कस्टमाइजेशन लागत अपेक्षाकृत अधिक है। इसके अलावा, उन्हें आंतरिक मॉनिटरिंग सिस्टम के साथ एकीकृत करना मुश्किल हो सकता है। Kafka मॉनिटरिंग सिस्टम को शुरू से बनाना भी महंगा है, क्योंकि Kafka के लिए मॉनिटरिंग जानकारी कई पहलुओं को कवर करती है, और Kafka द्वारा प्रदान किए गए मॉनिटरिंग मेट्रिक्स को Java Management Extension (JMX) के माध्यम से जटिल प्रोसेसिंग की आवश्यकता होती है।
आर्किटेक्चर में एक API गेटवे जोड़ने से, क्लाइंट और API गेटवे संचार HTTP प्रोटोकॉल पर आधारित होता है। इसके परिणामस्वरूप, HTTP प्रोटोकॉल पर आधारित मॉनिटरिंग सॉफ्टवेयर का इकोसिस्टम बहुत समृद्ध है। यह Kafka सेवाओं के लिए व्यापक ऑब्जर्वेबिलिटी प्रदान करने में सक्षम बनाता है, जो बहुत कम लागत पर संभव होता है।
Kafka रोलिंग अपग्रेड
Kafka सेवाएं broker पतों के माध्यम से एक्सपोज्ड होती हैं, जिन्हें प्रोड्यूसर्स और कंज्यूमर्स को अपनी कॉन्फ़िगरेशन जानकारी में प्रदान करना होता है ताकि वे Kafka क्लस्टर से कनेक्ट हो सकें। पता सूची आमतौर पर host1:port1, host2:port2 के रूप में फॉर्मेट की जाती है, और इसमें एक या अधिक पते शामिल हो सकते हैं जो कॉमा से अलग होते हैं।
हालांकि, इस कॉन्फ़िगरेशन विधि की सीमाएं हैं: इसके लिए Kafka broker पतों को स्थिर रहने और सेवाओं को स्थिर रहने की आवश्यकता होती है। Kafka क्लाइंट्स यह मानते हैं कि सभी broker पते उपलब्ध हैं और उनमें से एक को यादृच्छिक रूप से चुनते हैं। रोलिंग अपग्रेड के दौरान यह समस्या पैदा कर सकता है क्योंकि क्लाइंट्स को यह ज्ञात नहीं होता है कि किस broker का उपयोग करना है, और broker पतों को बदलने के लिए सभी प्रोड्यूसर और कंज्यूमर क्लाइंट्स को परिवर्तन करने की आवश्यकता होती है।
Kafka के लिए एक API गेटवे का उपयोग करके, broker पतों को गेटवे परत पर कॉन्फ़िगर किया जा सकता है, और क्लाइंट्स को अब Kafka brokers के विशिष्ट विवरणों पर ध्यान देने की आवश्यकता नहीं होती है। यहां तक कि यदि broker पता बदल जाता है, तो क्लाइंट्स प्रभावित नहीं होते हैं। यह Kafka के लिए रोलिंग अपग्रेड करना आसान बनाता है, बिना क्लाइंट्स को प्रभावित करने की चिंता किए।
सारांश
इस प्रकार, Kafka में एक API गेटवे जोड़कर, API गेटवे की समृद्ध कार्यक्षमता के माध्यम से Kafka सेवाओं के लिए रेट लिमिटिंग, प्रमाणीकरण, मॉनिटरिंग और रोलिंग अपग्रेड क्षमताएं प्रदान करना आसान हो जाता है।
Apache APISIX का उपयोग करके Kafka का विस्तार
Apache APISIX Apache Software Foundation के तहत एक उच्च-प्रदर्शन, रियल-टाइम API गेटवे है। यह लोड बैलेंसिंग, डायनामिक अपस्ट्रीम्स, कैनरी रिलीज, सर्किट ब्रेकिंग, प्रमाणीकरण, और ऑब्जर्वेबिलिटी जैसी परिष्कृत ट्रैफिक प्रबंधन सुविधाओं की एक श्रृंखला प्रदान करता है। एक API गेटवे के रूप में, APISIX उद्यमों को API और माइक्रोसर्विस ट्रैफिक को तेजी से और सुरक्षित रूप से प्रोसेस करने में मदद करता है और इसे Kubernetes Ingress और सर्विस मेश में व्यापक रूप से उपयोग किया जाता है। Kafka सेवा के सामने एक APISIX परत जोड़कर, उद्यम प्लेटफॉर्म की समृद्ध प्लगइन सिस्टम का लाभ उठा सकते हैं ताकि संदेश प्रॉक्सी, लॉग डिलीवरी, रेट लिमिटिंग, मॉनिटरिंग और अन्य क्षमताएं सक्षम की जा सकें। APISIX के साथ, क्लाइंट से सर्वर तक के उत्तर-दक्षिण ट्रैफिक और उद्यम माइक्रोसर्विसेज के बीच पूर्व-पश्चिम ट्रैफिक दोनों को प्रभावी ढंग से प्रोसेस किया जा सकता है।

Kafka संदेशों को प्रॉक्सी करना
APISIX Kafka संदेशों को प्रॉक्सी करने की क्षमता प्रदान करता है। क्लाइंट सीधे APISIX के साथ संचार कर सकते हैं, जो क्लाइंट और Kafka के बीच संदेश प्रोटोकॉल रूपांतरण को संभालता है।
APISIX में Kafka प्रॉक्सी सुविधा को सक्षम करने के लिए, हमें नीचे दिखाए गए अनुसार एक रूट जोड़ने की आवश्यकता है:
curl -X PUT 'http://127.0.0.1:9180/apisix/admin/routes/Kafka' \ -H 'X-API-KEY: <api-key>' \ -H 'Content-Type: application/json' \ -d '{ "uri": "/Kafka", "plugins": { "Kafka-proxy": { "sasl": { "username": "user", "password": "pwd" } }, "limit-count": { "count": 2, "time_window": 60, "rejected_code": 503, "key_type": "var", "key": "remote_addr" } }, "upstream": { "nodes": { "Kafka-server1:9092": 1, "Kafka-server2:9092": 1, "Kafka-server3:9092": 1 }, "type": "none", "scheme": "Kafka" } }'
यह अनुरोध APISIX में /Kafka URI के साथ एक रूट बनाता है, जो तीन Kafka broker नोड्स को अपस्ट्रीम सेवाओं के रूप में जोड़ता है। kafka-proxy प्लगइन का उपयोग Kafka अनुरोधों में SASL/PLAIN प्रमाणीकरण जोड़ने के लिए किया जाता है। APISIX में कॉन्फ़िगरेशन हॉट अपडेट्स का समर्थन करता है, इसलिए Kafka brokers को बदलने के लिए API गेटवे को रीस्टार्ट करने या क्लाइंट को प्रभावित करने की आवश्यकता नहीं होती है।
इसके अलावा, इस रूट के लिए limit-count प्लगइन सक्षम किया गया है ताकि रेट लिमिटिंग के लिए समर्थन प्रदान किया जा सके। प्लगइन की कॉन्फ़िगरेशन निर्दिष्ट करती है कि 60 सेकंड के अंतराल में केवल दो अनुरोधों को पास करने की अनुमति है, और किसी भी अतिरिक्त अनुरोध को APISIX द्वारा 503 स्टेटस कोड के साथ अस्वीकार कर दिया जाएगा।
लॉग पुशिंग
APISIX का kafka-logger प्लगइन लॉग्स को JSON ऑब्जेक्ट्स के रूप में एक Apache Kafka क्लस्टर में पुश करने की अनुमति देता है।
यहां एक कॉन्फ़िगरेशन उदाहरण है:
curl http://127.0.0.1:9180/apisix/admin/routes/1 \ -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "plugins": { "kafka-logger": { "brokers" : [ { "host" :"127.0.0.1", "port" : 9092 }, { "host" :"127.0.0.1", "port" : 9093 } ], "kafka_topic" : "test2", "key" : "key1" } }, "upstream": { "nodes": { "127.0.0.1:1980": 1 }, "type": "roundrobin" }, "uri": "/hello" }'
APISIX केवल Kafka संदेशों को प्रॉक्सी करने की क्षमता से अधिक प्रदान करता है। यह ट्रेसिंग, मेट्रिक्स, और लॉगिंग क्षमताओं को विभिन्न प्लगइन्स के माध्यम से प्रदान करता है, जो ऑब्जर्वेबिलिटी के सभी पहलुओं को कवर करते हैं। APISIX पर सरल प्लगइन कॉन्फ़िगरेशन के साथ, Prometheus, Skywalking, और अन्य ऑब्जर्वेबिलिटी सेवाओं के साथ एकीकरण संभव है, जिससे Kafka क्लस्टर की मॉनिटरिंग क्षमताओं को बढ़ाया जा सकता है।
सारांश
यह लेख Kafka के लिए एक API गेटवे लागू करने के फायदों पर प्रकाश डालता है, और Apache APISIX का उपयोग करके यह दिखाता है कि यह Kafka के लिए रेट लिमिटिंग, प्रमाणीकरण, मॉनिटरिंग और रोलिंग अपग्रेड जैसी सुविधाएं कैसे प्रदान करता है।