How ShareChat engineers rebuilt a low-latency ML feature store on ScyllaDB after an initial scalability failure — and what they learned along the way कम लेटेनस मशीन लर्निंग फ़ीचर स्टोर की मांग पहले से कहीं अधिक है, लेकिन वास्तव में एक बड़े पैमाने पर लागू करना अभी भी एक चुनौती है. यह स्पष्ट हो गया जब ShareChat इंजीनियरों इवान Burmistrov और Andrei Manakov ने P99 CONF 23 चरण में भाग लिया और साझा किया कि वे ScyllaDB पर आधारित एक कम लेटेनस ML फ़ीचर स्टोर कैसे बनाए। यह एक "लोगों को सीखा" कहानी है, एक दृढ़ प्रदर्शन अनुकूलन के मूल्य पर एक नज़र - कुछ महत्वपूर्ण इंजीनियरिंग लेआउज़ के साथ। मूल सिस्टम कार्यान्वयन कंपनी की स्केलेबलता आवश्यकताओं से बहुत कम हो गया था। अंतिम लक्ष्य प्रति सेकंड 1 बिलियन सुविधाओं का समर्थन करना था, लेकिन सिस्टम केवल 1 मिलियन लोड के तहत विफल रहा। ShareChat: भारत का प्रमुख सोशल मीडिया प्लेटफॉर्म चुनौती की सीमा को समझने के लिए, ShareChat, भारत में अग्रणी सोशल मीडिया प्लेटफॉर्म के बारे में थोड़ा जानना महत्वपूर्ण है. ShareChat ऐप पर, उपयोगकर्ताओं को वीडियो, छवियों, गीतों और अधिक सहित 15 से अधिक अलग-अलग भाषाओं में सामग्री का पता लगाने और उपभोग करने में मदद मिलती है. ShareChat भी TikTok की तरह एक छोटे वीडियो प्लेटफॉर्म (Moj) का होस्ट करता है जो उपयोगकर्ताओं को रुझान टैग और प्रतियोगिताओं के साथ रचनात्मक होने के लिए प्रोत्साहित करता है. दोनों अनुप्रयोगों के बीच, वे एक तेजी से बढ़ती उपयोगकर्ता आधार की सेवा करते हैं जिसमें पहले से ही 325 मिलियन मासिक सक्रिय उपयोगकर्ता हैं. और उनके एआई-आधारित सामग्री सिफारिश इंजन उपयोगकर्ता भंडारण और भागीदारी को बढ़ावा देने के लिए आवश्यक हैं। ShareChat पर शॉपिंग यह कहानी एमएल फ़ीचर स्टोर के पीछे की प्रणाली पर ध्यान केंद्रित करती है छोटे आकार के वीडियो ऐप Moj. यह लगभग 20 मिलियन दैनिक सक्रिय उपयोगकर्ताओं, 100 मिलियन मासिक सक्रिय उपयोगकर्ताओं के लिए पूरी तरह से व्यक्तिगत फ़ीड प्रदान करती है. फ़ीड प्रति सेकंड 8,000 अनुरोधों की सेवा करते हैं, और प्रत्येक अनुरोध पर औसतन 2,000 सामग्री उम्मीदवारों को रैंक किया जाता है (उदाहरण के लिए, अनुशंसा करने के लिए 10 सर्वश्रेष्ठ वस्तुओं को खोजने के लिए)। इवान बर्मस्ट्रोव, ShareChat में मुख्य स्टाफ सॉफ्टवेयर इंजीनियर ने समझाया: हम विभिन्न 'आधारकों' के लिए सुविधाओं को गणना करते हैं. पोस्ट एक इकाई है, उपयोगकर्ता एक और है, और इतने पर। गणना के दृष्टिकोण से, वे काफी समान हैं. हालांकि, महत्वपूर्ण अंतर प्रत्येक प्रकार के इकाई के लिए सुविधाओं की संख्या में है. जब एक उपयोगकर्ता एक फ़ीड का अनुरोध करता है, तो हम उस एकल उपयोगकर्ता के लिए उपयोगकर्ता सुविधाओं को प्राप्त करते हैं. हालांकि, सभी पोस्टों को रैंक करने के लिए, हमें प्रत्येक उम्मीदवार (पोस्ट) के लिए सुविधाओं को रैंक करने की आवश्यकता है, इसलिए पोस्ट सुविधाओं द्वारा उत्पन्न प्रणाली पर कुल भार उपयोगकर्ता सुविधाओं द्वारा उत्पन्न होता है. यह अंतर हमारी कहानी में एक महत्वपूर्ण भूमिका निभाता है. हम विभिन्न 'आधारकों' के लिए सुविधाओं को गणना करते हैं. पोस्ट एक इकाई है, उपयोगकर्ता एक और है, और इतने पर। गणना के दृष्टिकोण से, वे काफी समान हैं. हालांकि, महत्वपूर्ण अंतर प्रत्येक प्रकार के इकाई के लिए सुविधाओं की संख्या में है. जब एक उपयोगकर्ता एक फ़ीड का अनुरोध करता है, तो हम उस एकल उपयोगकर्ता के लिए उपयोगकर्ता सुविधाओं को प्राप्त करते हैं. हालांकि, सभी पोस्टों को रैंक करने के लिए, हमें प्रत्येक उम्मीदवार (पोस्ट) के लिए सुविधाओं को रैंक करने की आवश्यकता है, इसलिए पोस्ट सुविधाओं द्वारा उत्पन्न प्रणाली पर कुल भार उपयोगकर्ता सुविधाओं द्वारा उत्पन्न होता है. यह अंतर हमारी कहानी में एक महत्वपूर्ण भूमिका निभाता है. क्यों प्रारंभिक सुविधा स्टोर आर्किटेक्चर स्केल करने में विफल रहा शुरुआत में, प्राथमिक ध्यान एक वास्तविक समय उपयोगकर्ता फ़ीचर स्टोर बनाने पर था क्योंकि उस बिंदु पर उपयोगकर्ता फ़ीचर सबसे महत्वपूर्ण थे. टीम ने उस लक्ष्य को ध्यान में रखते हुए फ़ीचर स्टोर का निर्माण करना शुरू कर दिया. लेकिन फिर प्राथमिकताएं बदल गईं और पोस्ट फ़ीचर भी केंद्रित हो गए. यह बदलाव हुआ क्योंकि टीम ने अपने पूर्ववर्ती के मुकाबले दो प्रमुख अंतरों के साथ एक पूरी तरह से नई रैंकिंग प्रणाली का निर्माण करना शुरू कर दिया: वास्तविक समय के करीब पोस्ट सुविधाएं अधिक महत्वपूर्ण थीं पदों की संख्या सैकड़ों से हजारों तक बढ़ी इवान ने समझाया: "जब हम इस नए सिस्टम का परीक्षण करने गए, तो यह दुखद रूप से विफल हो गया. प्रति सेकंड लगभग 1 मिलियन फ़ीचर पर, सिस्टम असंतोषित हो गया, लाटेंशन छत के माध्यम से चला गया और इतने पर। आखिरकार, समस्या यह थी कि सिस्टम आर्किटेक्चर ने पहले से एकत्र किए गए डेटा का उपयोग कैसे किया, जिसे टाइल कहा जाता है. उदाहरण के लिए, वे एक निश्चित मिनट या अन्य समय सीमा में एक पोस्ट के लिए पसंद की संख्या को एकत्र कर सकते हैं. यह उन्हें पिछले दो घंटों में कई पोस्टों के लिए पसंद की संख्या जैसे मीट्रिक्स की गणना करने की अनुमति देता है. यहाँ सिस्टम आर्किटेक्चर का एक उच्च स्तर का एक नज़र है. कच्चे डेटा (प्यार, क्लिक, आदि) के साथ कुछ वास्तविक समय विषय हैं. एक Flink नौकरी उन्हें टाइलों में एकत्र करती है और उन्हें ScyllaDB में लिखती है. फिर एक सुविधा सेवा है जो ScyllaDB से टाइलों का अनुरोध करती है, उन्हें एकत्र करती है और फ़ीड सेवा को परिणाम देता है. प्रारंभिक डेटाबेस योजना और टाइलिंग कॉन्फ़िगरेशन स्केलेबलता समस्याओं का कारण बन गया था. मूल रूप से, प्रत्येक इकाई के पास अपना खुद का विभाजन था, जिसमें पंक्तियों का टाइमस्टैम्प और फ़ीचर नाम क्लास्टिंग स्तंभों को क्रमबद्ध किया गया था. [ ]. टाइलों को एक मिनट, 30 मिनट और एक दिन के खंडों के लिए गणना की गई थी. एक घंटे, एक दिन, सात दिन या 30 दिन की मांग करने के लिए प्रति फ़ीचर औसतन लगभग 70 टाइलों को उठाने की आवश्यकता थी. इस NoSQL डेटा मॉडलिंग मास्टरक्लास में अधिक जानें यदि आप गणित करते हैं, तो यह स्पष्ट हो जाता है कि यह क्यों विफल हुआ. सिस्टम को प्रति सेकंड 22 अरब पंक्तियों को संभालने की आवश्यकता थी. हालांकि, डेटाबेस की क्षमता केवल 10 मिलियन पंक्तियों / सेकंड थी. प्रारंभिक सुविधा स्टोर अनुकूलन: डेटा मॉडलिंग और टाइलिंग परिवर्तन उस बिंदु पर, टीम ने एक अनुकूलन मिशन पर चलाया। प्रारंभिक डेटाबेस योजना को सभी सुविधा पंक्तियों को एक साथ संग्रहीत करने के लिए अद्यतन किया गया था, एक निश्चित समय स्टैम्प के लिए प्रोटोकॉल बफर के रूप में श्रृंखलाकृत किया गया था. चूंकि वास्तुकला पहले से ही एपैच फ्लिंक का उपयोग कर रहा था, नए टाइलिंग योजना के लिए संक्रमण काफी आसान था, डेटा पाइपलाइन बनाने में फ्लिंक की उन्नत क्षमताओं के लिए धन्यवाद। टीम ने टाइलिंग कॉन्फ़िगरेशन को भी अनुकूलित किया, पांच मिनट, तीन घंटे और पांच दिनों के लिए अतिरिक्त टाइलों को एक मिनट, 30 मिनट और एक दिन टाइलों में जोड़कर। डेटाबेस पक्ष पर अधिक पंक्तियों / सेकंड को संभालने के लिए, उन्होंने ScyllaDB संपीड़न रणनीति को बढ़ते से स्तरित करने के लिए बदल दिया। ]. यह विकल्प उनके पूछताछ पैटर्न को बेहतर ढंग से फिट करता था, प्रासंगिक पंक्तियों को एक साथ रखता था और पढ़ें आई / आई को कम करता था. परिणाम: ScyllaDB की क्षमता को प्रभावी रूप से दोगुना किया गया था. कॉम्पैक्शन रणनीतियों के बारे में अधिक जानें शेष भार को समायोजित करने का सबसे आसान तरीका ScyllaDB को 4x स्केल करना होगा. हालांकि, अधिक / बड़े क्लस्टर लागत बढ़ा देंगे और यह बस उनके बजट में नहीं था. इसलिए टीम ने ScyllaDB क्लस्टर को स्केल करने के बिना स्केल करने की क्षमता में सुधार करने पर ध्यान केंद्रित किया। डेटाबेस लोड को कम करने के लिए सुविधा स्टोर कैश स्थान में सुधार ScyllaDB पर लोड को कम करने का एक संभावित तरीका स्थानीय कैश हिट दर में सुधार करना था, इसलिए टीम ने शोध करने का फैसला किया कि यह कैसे प्राप्त किया जा सकता है। स्पष्ट विकल्प एक निरंतर हैशिंग दृष्टिकोण का उपयोग करना था, एक अच्छी तरह से ज्ञात तकनीक जो अनुरोध के बारे में कुछ जानकारी के आधार पर क्लाइंट से एक निश्चित प्रतिलिपि को निर्देशित करने के लिए थी। चूंकि टीम ने अपने Kubernetes सेटिंग में NGINX Ingress का उपयोग किया था, निरंतर हैशिंग के लिए NGINX की क्षमताओं का उपयोग करना एक प्राकृतिक विकल्प की तरह लग रहा था। यह सरल कॉन्फ़िगरेशन काम नहीं कर रहा था. विशेष रूप से: क्लाइंट उपसेट ने एक विशाल कुंजी remapping के लिए नेतृत्व किया - सबसे खराब स्थिति में 100% तक. चूंकि नोड कुंजी एक हैशि अंगूठी में बदला जा सकता है, यह ऑटोस्केलिंग के साथ वास्तविक जीवन परिदृश्यों का उपयोग करना असंभव था। एक अनुरोध के लिए एक हैश मूल्य प्रदान करना मुश्किल था क्योंकि Ingress सबसे स्पष्ट समाधान का समर्थन नहीं करता है: एक gRPC हेडर। लाटेनेशन को गंभीर रूप से खराब किया गया था, और यह स्पष्ट नहीं था कि किनारे की लाटेनेशन का कारण क्या था। पॉडों के एक उपसेट का समर्थन करने के लिए, टीम ने उनके दृष्टिकोण को संशोधित किया। उन्होंने एक दो-चरण हैश फ़ंक्शन बनाया: पहले एक इकाई हैश करना, फिर एक यादृच्छिक पूर्वावलोकन जोड़ना। जो इकाई को वांछित संख्या में वितरित करता है। सिद्धांत रूप में, यह दृष्टिकोण एक टकराव का कारण बन सकता है जब एक इकाई कई बार एक ही पॉड पर मैप की जाती है। Ingress एक परिवर्तनीय के रूप में gRPC हेडर का उपयोग करने का समर्थन नहीं करता है, लेकिन टीम ने एक समाधान पाया: पथ रीवरेटिंग का उपयोग करना और पथ में आवश्यक हैश कुंजी प्रदान करना। दुर्भाग्य से, लेटेनियस बिगड़ने के कारण की पहचान करने में काफी समय लगेगा, साथ ही दृश्यता में सुधार भी होगा. समय पर फ़ीचर स्टोर का पैमाना बढ़ाने के लिए एक अलग दृष्टिकोण की आवश्यकता थी. समय सीमा को पूरा करने के लिए, टीम ने फ़ीचर सेवा को 27 अलग-अलग सेवाओं में विभाजित किया और ग्राहक पर उनमें से सभी इकाइयों को मैन्युअल रूप से विभाजित किया. यह सबसे सुरुचिपूर्ण दृष्टिकोण नहीं था, लेकिन, यह सरल और व्यावहारिक था – और यह महान परिणाम प्राप्त करता था. कैश हिट दर में सुधार हुआ 95% और ScyllaDB लोड को प्रति सेकंड 18.4 मिलियन पंक्तियों तक कम किया गया. इस डिजाइन के साथ, ShareChat ने मार्च तक अपनी फ़ीचर स्टोर को प्रति सेकंड 1B फ़ीचर तक बढ़ाया. हालांकि, यह "पुराने स्कूल" तैनाती विभाजन दृष्टिकोण अभी भी आदर्श डिजाइन नहीं था. 27 तैनाती को बनाए रखना उबाऊ और अप्रभावी था. इसके अलावा, कैश हिट दर स्थिर नहीं थी, और स्केलिंग को प्रत्येक तैनाती में उच्च न्यूनतम पॉड की संख्या रखने के लिए सीमित किया गया था. इसलिए यद्यपि यह दृष्टिकोण तकनीकी रूप से उनकी जरूरतों को पूरा करता था, टीम ने एक बेहतर दीर्घकालिक समाधान की तलाश जारी रखी। अनुकूलन के अगले चरण: लगातार हैशिंग, सुविधा सेवा ऑप्टिमाइज़ेशन के एक और दौर के लिए तैयार, टीम ने विशेषता सेवा के साथ तैनात एक साइडकेयर, जिसे एन्वेयर प्रॉक्सी कहा जाता है, का उपयोग करके निरंतर हैशिंग दृष्टिकोण को फिर से देखा। टीम ने फिर सुविधा सेवा को अनुकूलित किया. वे: कैशिंग लाइब्रेरी (विक्टोरियामेट्रिक्स से फास्टकेच) को फायर किया और बैच लिखने और बेहतर निष्कासन को लागू किया ताकि म्यूटेक्स प्रतिबंध को 100 गुना कम किया जा सके। फॉर्क gprc-go और उच्च संयोग के दौरान विवाद से बचने के लिए विभिन्न कनेक्शनों पर बफर पूल लागू किया। एसोसिएशन दरों और जीसी चक्रों को कम करने के लिए ऑब्जेक्ट पॉलिंग और समायोजित कचरे संग्रहक (जीसी) पैरामीटर का उपयोग किया गया। अपने अवधारणा प्रमाण पत्र में 15% ट्रैफ़िक को संभालने के साथ, परिणाम आशाजनक थे: 98% कैश हिट दर, जिसने ScyllaDB पर लोड को 7.4M पंक्तियों / सेकंड तक कम कर दिया। एक उच्च प्रदर्शन विशेषता स्टोर का आकार देने से सीखा गया सबक यहां यह यात्रा एक टाइमलाइन परिप्रेक्ष्य से कैसी दिखती है: अंत में, Andrei ने टीम के इस परियोजना से सीखने वाले शीर्ष सबक (अब तक) को सारांशित किया: यहां तक कि जब ShareChat टीम ने अपने सिस्टम डिजाइन को नाटकीय रूप से बदल दिया, तो ScyllaDB, Apache Flink और VictoriaMetrics ने अच्छी तरह से काम किया। प्रत्येक अनुकूलन पिछले की तुलना में कठिन है - और कम प्रभाव पड़ता है। सरल और व्यावहारिक समाधान (जैसे फ़ीचर स्टोर को 27 तैनाती में विभाजित करना) वास्तव में काम करते हैं। सर्वश्रेष्ठ प्रदर्शन प्रदान करने वाला समाधान हमेशा उपयोगकर्ता के अनुकूल नहीं होता है. उदाहरण के लिए, उनकी संशोधित डेटाबेस योजना अच्छी तरह से प्रदर्शन करती है, लेकिन इसे बनाए रखना और समझना मुश्किल है. आखिरकार, उन्होंने इसके आसपास कुछ उपकरण लिखे ताकि इसके साथ काम करना आसान हो। कभी-कभी आपको डिफ़ॉल्ट लाइब्रेरी को फोर्क करने और सबसे अच्छा प्रदर्शन प्राप्त करने के लिए अपने विशिष्ट सिस्टम के लिए इसे समायोजित करने की आवश्यकता हो सकती है।
