अपाचे कैसेंड्रा के साथ डेटा रीडिंग लेटेंसी में दस गुना कमी के लिए ओपन-सोर्स समाधान

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

पिछले साल, कैसंड्रा की इंस्टाग्राम सपोर्ट टीम ने कैसांद्रा में डेटा पढ़ने में विलंबता को कम करने के उद्देश्य से एक परियोजना पर काम करना शुरू किया, जिसे इंजीनियरों ने रॉकेंड्रा कहा। इस लेख में, लेखक बताता है कि इस परियोजना को लागू करने के लिए टीम को क्या प्रेरित किया गया था, जो कठिनाइयों को दूर करना था, और प्रदर्शन मेट्रिक्स जो कि इंजीनियर आंतरिक और बाह्य क्लाउड वातावरण दोनों का उपयोग करते हैं।

संक्रमण के लिए मैदान

इंस्टाग्राम सक्रिय रूप से और व्यापक रूप से अपाचे कैसेंड्रा को एक महत्वपूर्ण-मूल्य भंडारण सेवा के रूप में उपयोग करता है। अधिकांश इंस्टाग्राम अनुरोध ऑनलाइन होते हैं, इसलिए, लाखों इंस्टाग्राम उपयोगकर्ताओं के लिए एक विश्वसनीय और सुखद उपयोगकर्ता अनुभव प्रदान करने के लिए, SLAs सिस्टम के प्रदर्शन पर बहुत मांग है।

इंस्टाग्राम पांच-नौ विश्वसनीयता रेटिंग का पालन करता है। इसका मतलब यह है कि किसी भी समय विफलताओं की संख्या 0.001% से अधिक नहीं हो सकती है। प्रदर्शन को बेहतर बनाने के लिए, अभियंता विभिन्न कैसंड्रा समूहों के थ्रूपुट और अक्षांशों की सक्रिय रूप से निगरानी करते हैं, और सुनिश्चित करते हैं कि सभी अनुरोधों में से 99% एक निश्चित संकेतक (देरी P99) में फिट होते हैं।

नीचे एक ग्राफ़ दिखाया गया है जो कैसंड्रा कॉम्बैट क्लस्टर में से किसी एक के लिए क्लाइंट-साइड डिले है। ब्लू औसत रीड स्पीड (5 एमएस) को इंगित करता है, और नारंगी 25-60 एमएस से लेकर 99% के लिए रीड स्पीड को इंगित करता है। इसके परिवर्तन क्लाइंट ट्रैफ़िक पर अत्यधिक निर्भर हैं।





अध्ययन में पाया गया कि देरी के तेज विस्फोट जेवीएम कचरा कलेक्टर के काम के कारण बड़े पैमाने पर हैं। कैसेंड्रा सर्वर द्वारा "दुनिया को रोकने" पर खर्च किए गए समय के प्रतिशत को मापने के लिए इंजीनियरों ने "सीएम के स्टॉप का प्रतिशत" नामक एक मीट्रिक पेश किया, और ग्राहक के अनुरोधों से इनकार किया। यहाँ समय की मात्रा (प्रतिशत में) दिखाने वाला ऊपर का चार्ट है जो कैसंड्रा कॉम्बैट सर्वर में से एक के उदाहरण का उपयोग करके एसएम स्टॉप पर गया था। पीक लोड के समय सबसे छोटे ट्रैफिक के समय इंडिकेटर 1.25% से लेकर 2.5% तक होता है।

ग्राफ से पता चलता है कि यह कैसंड्रा सर्वर का उदाहरण क्लाइंट अनुरोधों को परोसने के बजाय अपना 2.5% समय कचरा इकट्ठा करने में खर्च कर सकता है। कलेक्टर के निवारक कार्यों का स्पष्ट रूप से P99 देरी पर महत्वपूर्ण प्रभाव पड़ा और इसलिए यह स्पष्ट हो गया कि यदि हम CM स्टॉप दर को कम करने में सक्षम थे, तो इंजीनियर P99 विलंब दर को काफी कम कर सकते हैं।

निर्णय

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

इंजीनियर्स खरोंच से सब कुछ नहीं करना चाहते थे, और इसलिए एक आधार के रूप में रॉक्सडीबी लेने का फैसला किया।

RocksDB कुंजी-मूल्य संग्रहण के लिए एक उच्च-प्रदर्शन, ओपन-सोर्स एम्बेडेड डेटाबेस है। यह C ++ में लिखा गया है, और इसके API में C ++, C और Java के लिए आधिकारिक भाषा बाइंडिंग है। RocksDB उच्च प्रदर्शन के लिए अनुकूलित है, विशेष रूप से SSDs जैसे तेज ड्राइव पर। यह व्यापक रूप से उद्योग में MySQL, mongoDB, और अन्य लोकप्रिय डेटाबेस के लिए एक भंडारण इंजन के रूप में उपयोग किया जाता है।

कठिनाइयों

RocksDB पर नए भंडारण इंजन को लागू करने की प्रक्रिया में, इंजीनियरों ने तीन कठिन कार्यों का सामना किया और उन्हें हल किया।

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

दूसरी कठिनाई यह थी कि कैसेंड्रा ने संरचित डेटा प्रकारों और टेबल स्कीमाओं का समर्थन किया था, जबकि रॉक्सडीबी केवल कुंजी-मूल्य इंटरफेस प्रदान करता था। इंजीनियरों ने ध्यान से कोडिंग और डिकोडिंग एल्गोरिदम को रॉकस्डीबी डेटा संरचनाओं के भीतर कैसंड्रा डेटा मॉडल का समर्थन करने के लिए परिभाषित किया और दो डेटाबेस के बीच समान प्रश्नों के शब्दार्थ की निरंतरता सुनिश्चित की।

तीसरी कठिनाई किसी भी वितरित डेटाबेस घटक के लिए डेटा धाराओं के साथ काम करने के लिए इस तरह के एक महत्वपूर्ण घटक से जुड़ी थी। जब भी कैसंड्रा क्लस्टर से एक नोड जोड़ा जाता है या हटाया जाता है, तो क्लस्टर के भीतर लोड को संतुलित करने के लिए विभिन्न नोड्स के बीच डेटा को सही ढंग से वितरित करने की आवश्यकता होती है। इन तंत्रों का मौजूदा कार्यान्वयन मौजूदा डेटाबेस इंजन से विस्तृत डेटा प्राप्त करने पर आधारित था। इसलिए, इंजीनियरों को उन्हें एक-दूसरे से अलग करना पड़ा, एक अमूर्त परत बनाई गई और रॉकबीडी एपीआई का उपयोग करके प्रसंस्करण धाराओं के लिए एक नया विकल्प लागू किया। धाराओं के उच्च प्रवाह को प्राप्त करने के लिए, समर्थन टीम अब पहले डेटा को अस्थायी sst फ़ाइलों में वितरित करती है, और फिर फ़ाइलों को "निगल" करने के लिए विशेष RocksDB API का उपयोग करती है, जिससे उन्हें RocksDB उदाहरण में एक साथ लोड किया जा सकता है।

प्रदर्शन संकेतक

लगभग एक साल के विकास और परीक्षण के बाद, इंजीनियरों ने कार्यान्वयन के पहले संस्करण को पूरा किया और इसे कई इंस्टाग्राम इंस्टाग्राम कैसेंड्रा समूह पर सफलतापूर्वक "रोल आउट" किया। लड़ाकू समूहों में से एक पर, P99 देरी 60 एमएस से 20 एमएस तक गिर गई। टिप्पणियों से यह भी पता चला है कि इस क्लस्टर में एसएम स्टॉप 2.5% से 0.3% तक गिर गया, यानी लगभग 10 गुना!

इंजीनियर यह भी जाँचना चाहते थे कि क्या रॉकसंड्रा सार्वजनिक क्लाउड वातावरण में अच्छा प्रदर्शन कर सकता है। सहायता टीम ने AWS में एक कैसंड्रा क्लस्टर की स्थापना की, जिसमें तीन i3.8 xlarge EC2 इंस्टेंस का उपयोग किया गया, जिनमें से प्रत्येक में 32-कोर प्रोसेसर, 244 जीबी रैम और चार NVMe फ्लैश ड्राइव का एक शून्य छापा था।

तुलनात्मक परीक्षणों के लिए, हमने फ्रेम के लिए NDBench , और डिफ़ॉल्ट टेबल स्कीमा का उपयोग किया।

TABLE emp ( emp_uname text PRIMARY KEY, emp_dept text, emp_first text, emp_last text ) 

इंजीनियरों ने 6 केबी (प्रत्येक सर्वर पर लगभग 500 जीबी डेटा संग्रहीत) की 250 मिलियन 6 पंक्तियों को पूर्व-लोड किया। इसके बाद, NDBench में 128 पाठकों और लेखकों को सेट करें।

सहायता टीम ने विभिन्न भारों का परीक्षण किया और औसत / P99 / P999 को मापा और विलंबता को पढ़ा और लिखा। नीचे दिए गए रेखांकन से पता चलता है कि रॉकसंड्रा ने काफी कम और अधिक स्थिर और विलंबित पढ़ने और लिखने को दिखाया।





इंजीनियरों ने बिना पढ़े लिखे मोड में लोड की जाँच की और पाया कि एक ही P99 रीड विलंब (2 एमएस) के साथ, रॉकसंड्रा सूचना पढ़ने की गति में 10 गुना से अधिक वृद्धि प्रदान करने में सक्षम है (रॉक के लिए 30 केएस के लिए 300 के / एस बनाम 30 के / सी के लिए) * 3.0)।

भविष्य की योजना

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

अगले चरण के रूप में, टीम सक्रिय रूप से C * कार्यक्षमता के लिए व्यापक समर्थन जोड़ने पर काम कर रही है, जैसे कि माध्यमिक अनुक्रमित, फिक्स, और बहुत कुछ। और इसके अलावा, इंजीनियरों ने अपाचे कैसंड्रा समुदाय को इन घटनाओं को आगे स्थानांतरित करने के लिए सी * में प्लग-इन डेटाबेस इंजन की वास्तुकला विकसित कर रहे हैं।