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