एक निरंतर बढ़ते ऑल-इन-वन एपीएम के रूप में, हम यह सुनिश्चित करने के लिए बहुत समय बिताते हैं कि ऐपसिग्नल यातायात में हमारी वृद्धि का सामना कर सकता है। आमतौर पर, हम इस बारे में बात नहीं करते कि हम यह कैसे करते हैं; हमारा ब्लॉग रूबी के हुड के तहत महान चीजों के बारे में लेखों से भरा है या अमृत के साथ पागल चीजें कर रहा है, लेकिन इस बारे में नहीं कि ऐपसिग्नल क्या टिकता है।
हालांकि, इस बार हम अपने स्टैक में पिछले कुछ वर्षों में किए गए कुछ बड़े बदलावों को साझा करना चाहते हैं, इसलिए हम हर महीने हमारे द्वारा भेजे गए दो अंकों के अरबों अनुरोधों को (आसानी से) संसाधित कर सकते हैं। वास्तविक समय में। इसलिए आज हम अपने स्केलिंग अनुभव का उपयोग अपने स्वयं के स्टैक पर चर्चा करने और इस तरह आपकी सहायता करने के लिए करते हैं।
मानक रेल सेटअप से अधिक कस्टम भागों तक
ऐपसिग्नल एक सुंदर मानक रेल सेटअप के रूप में शुरू हुआ। हमने एक एपीआई एंडपॉइंट के माध्यम से डेटा एकत्र करने वाले एक रेल ऐप का उपयोग किया, जिसने पृष्ठभूमि में संसाधित करने के लिए साइडकीक नौकरियां बनाईं।
थोड़ी देर बाद हमने रेल एपीआई को रैक मिडलवेयर के साथ बदल दिया ताकि थोड़ी गति हासिल की जा सके और बाद में इसे एक गो वेब सर्वर से बदल दिया गया जिसने साइडकीक संगत नौकरियों को रेडिस में धकेल दिया।
ऐप्लिकेशन की स्थिति और वेतन वृद्धि/अपडेट
जबकि इस सेटअप ने लंबे समय तक अच्छा काम किया, हम उन मुद्दों में भाग लेने लगे जहां डेटाबेस उनके खिलाफ चलने वाले प्रश्नों की मात्रा के साथ नहीं रह सके। इस बिंदु पर हम पहले से ही दसियों अरबों अनुरोधों को संसाधित कर रहे थे। इसका मुख्य कारण यह था कि सही काउंटरों को बढ़ाने और सही दस्तावेज़ों को अपडेट करने के लिए प्रत्येक साइडकीक प्रक्रिया को डेटाबेस से संपूर्ण ऐप की स्थिति प्राप्त करने की आवश्यकता थी।
हम डेटा के स्थानीय कैशिंग के साथ इसे कुछ हद तक कम कर सकते हैं, लेकिन हमारे सेटअप की राउंड-रॉबिन प्रकृति के कारण इसका अभी भी मतलब है कि प्रत्येक सर्वर को सभी डेटा का पूरा कैश होना चाहिए, क्योंकि हम यह सुनिश्चित नहीं कर सकते कि पेलोड किस सर्वर पर है खत्म हो जाएगा। हमने महसूस किया कि डेटा वृद्धि के साथ हम इस सेटअप का अनुभव कर रहे थे, भविष्य में यह असंभव हो जाएगा।
काफ्का दर्ज करें
डेटा प्रोसेसिंग पाइपलाइन के रूप में काफ्का का उपयोग करने के लिए हमने तय किए गए डेटा को संभालने के बेहतर तरीके की तलाश में। डेटाबेस में मेट्रिक्स को एकत्रित करने के बजाय, अब हम मेट्रिक्स को काफ्का प्रोसेसर में एकत्रित करते हैं . हमारा लक्ष्य यह है कि हमारी काफ्का पाइपलाइन डेटाबेस से तब तक पूछताछ नहीं करती जब तक कि एकत्रित डेटा को फ्लश नहीं करना पड़ता। यह पाइपलाइन के अंत में प्रति पेलोड प्रश्नों की मात्रा को दस रीड्स से कम करके केवल एक राइट तक ले जाता है।
हम प्रत्येक काफ्का संदेश के लिए एक कुंजी निर्दिष्ट करते हैं और काफ्का गारंटी देता है कि एक ही कुंजी एक ही विभाजन पर समाप्त होती है, जो एक ही सर्वर द्वारा खपत होती है। हम संदेशों के लिए एक कुंजी के रूप में ऐप की आईडी का उपयोग करते हैं, इसका मतलब है कि सर्वर पर सभी ग्राहकों के लिए कैश होने के बजाय, हमें केवल उन ऐप्स के लिए डेटा कैश करना होगा जो सर्वर को काफ्का से प्राप्त होता है, सभी ऐप नहीं।
काफ्का एक महान प्रणाली है और हमने पिछले दो वर्षों में प्रवास किया है। अभी लगभग सभी प्रसंस्करण काफ्का के माध्यम से जंग में किया जाता है, लेकिन रूबी में अभी भी कुछ चीजें आसान हैं, जैसे सूचनाएं और अन्य डेटाबेस-भारी कार्य भेजना। इसका मतलब यह था कि हमें काफ्का से हमारे रेल स्टैक तक डेटा प्राप्त करने के लिए किसी तरह की आवश्यकता थी।
काफ्का और रूबी/रेल को जोड़ना
जब हमने इस संक्रमण को शुरू किया तो कुछ काफ्का रूबी रत्न थे, लेकिन किसी ने भी काफ्का के नवीनतम (उस समय 0.10.x) रिलीज के साथ काम नहीं किया और अधिकांश का रखरखाव नहीं किया गया था।
हमने अपना खुद का रत्न लिखने पर ध्यान दिया (जो हमने अंततः किया)। हम इसके बारे में एक अलग लेख में और लिखेंगे। लेकिन एक अच्छा ड्राइवर होना आवश्यकताओं का केवल एक हिस्सा है। हमें रूबी में डेटा का उपभोग करने और कार्यों को निष्पादित करने के लिए एक प्रणाली की भी आवश्यकता थी और पुराने के दुर्घटनाग्रस्त होने पर नए श्रमिकों को जन्म देना।
आखिरकार हम एक अलग समाधान लेकर आए। हमारा काफ्का स्टैक रस्ट में बनाया गया है और हमने एक छोटा बाइनरी लिखा है जो sidekiq_out की खपत करता है विषय और रेडिस में साइडकीक संगत नौकरियां बनाता है। इस तरह हम इस बाइनरी को अपने वर्कर मशीनों पर तैनात कर सकते हैं और यह साइडकीक में नई नौकरियों को फीड करेगा जैसे आप रेल के भीतर ही करेंगे।
बाइनरी के पास कुछ विकल्प हैं जैसे कि रेडिस में डेटा की मात्रा को सीमित करना, जब तक कि थ्रेशोल्ड साफ़ न हो जाए, तब तक काफ्का विषय का उपभोग करना बंद कर दें। इस प्रकार, यदि कोई बैकलॉग है, तो काफ्का का सारा डेटा रेडिस की स्मृति में श्रमिकों पर समाप्त नहीं होगा।
रूबी के दृष्टिकोण से, रेल में उत्पन्न नौकरियों और काफ्का से आने वाली नौकरियों के बीच कोई अंतर नहीं है। यह हमें काफ्का से डेटा प्राप्त करने वाले नए कर्मचारियों के प्रोटोटाइप की अनुमति देता है और इसे रेल में संसाधित करता है-सूचनाएं भेजने और डेटाबेस को अपडेट करने के लिए- बिना काफ्का के बारे में कुछ भी जाने।
इसने काफ्का में प्रवास को आसान बना दिया क्योंकि हम नए रूबी कोड को तैनात किए बिना काफ्का और वापस स्विच कर सकते थे। इसने परीक्षण को बहुत आसान बना दिया क्योंकि आप स्थानीय रूप से संपूर्ण काफ्का स्टैक को सेटअप किए बिना रूबी द्वारा उपभोग किए जाने वाले परीक्षण सूट में आसानी से नौकरियां उत्पन्न कर सकते थे।
हम अपने सभी (आंतरिक) संदेशों को परिभाषित करने के लिए प्रोटोबफ का उपयोग करते हैं, इस तरह हम पूरी तरह से सुनिश्चित हो सकते हैं कि यदि परीक्षण पास हो जाता है, तो कार्यकर्ता काफ्का से नौकरियों को सही ढंग से संसाधित करेगा।
अंत में इस समाधान ने हमारा बहुत समय और ऊर्जा बचाई और हमारी रूबी टीम के लिए जीवन को बहुत आसान बना दिया।
पेशेवरों और विपक्ष
हर चीज की तरह इस सेटअप के कुछ फायदे और नुकसान भी हैं:
पेशेवरों:
- रूबी में कोई बदलाव जरूरी नहीं, एपीआई संगत
- तैनाती और वापस करने में आसान
- काफ्का और रूबी के बीच स्विच करना आसान
- सीमक का उपयोग करते समय रेडिस संदेशों द्वारा अतिभारित नहीं होता है, सर्वर पर मेमोरी बचाता है, संदेशों को काफ्का में रखता है।
- क्षैतिज स्केलिंग, कुंजी संदेशों के कारण प्रत्येक सर्वर पर छोटे कैश की ओर ले जाती है।
विपक्ष:
- अभी भी समस्या है कि प्रत्येक साइडकीक थ्रेड को सर्वर द्वारा उपभोग किए जाने वाले विभाजन से ऐप्स के लिए सभी डेटा के कैश तक पहुंच की आवश्यकता होती है। (उदा. मेम्कैश)।
- सर्वर पर चलने वाली अलग प्रक्रिया
- रस्ट प्रोसेसर संदेश को ऑफसेट करता है जब संदेश रेडिस को फ्लश किया जाता है, इसका मतलब है कि यह रेडिस में होने की गारंटी है, लेकिन इस बात की कोई गारंटी नहीं है कि रूबी द्वारा संदेश संसाधित किया जाता है, इसका मतलब है कि सर्वर क्रैश के मामले में, वहां एक मौका है कि कुछ संदेश जो रेडिस में थे, लेकिन संसाधित नहीं हुए संसाधित नहीं हैं।
साइडकीक और काफ्का
साइडकीक का उपयोग करने से हमें अपनी प्रसंस्करण पाइपलाइन को काफ्का में स्थानांतरित करने में काफी मदद मिली। अब हम साइडकीक से लगभग पूरी तरह से दूर हो गए हैं और सीधे हमारे काफ्का ड्राइवर के माध्यम से सब कुछ संभाल रहे हैं, लेकिन यह एक अन्य लेख के लिए है।
यह सुखद अंत प्रेम कहानी को समाप्त करता है। हमें उम्मीद है कि आपने प्रदर्शन और स्केलिंग पर इस परिप्रेक्ष्य का आनंद लिया है, और ऐपसिग्नल को स्केल करने का हमारा अनुभव। हमें उम्मीद है कि यह कहानी हमने अपने स्टैक के आसपास लिए गए निर्णयों पर, बदले में, आपकी मदद करेगी।
हमारे काफ्का सेटअप के बारे में अगला एपिसोड कब प्रकाशित होगा, इस पर नज़र रखने के लिए बाकी ब्लॉग देखें या हमें फॉलो करें। और अगर आप एक ऐसा ऑल-इन-वन एपीएम ढूंढ रहे हैं जो वास्तव में डेवलपर्स द्वारा डेवलपर्स के लिए है, तो आइए हमें ढूंढते हैं।