Cloudflare इतने बड़े पैमाने पर काम करता है कि यहाँ वर्षों तक काम करने के बाद भी यह वास्तविक नहीं लगता। दुनिया भर में हमारे पास हज़ारों सर्वर हैं जिनमें पेटाबाइट्स RAM और लाखों CPU कोर हैं, और यह सब अधिकतम तक इस्तेमाल किया जाता है। ये संसाधन जितने विशाल लगते हैं, उतने ही सीमित भी हैं, और जब आपको हर सेवा को हर नोड पर चलाने की आवश्यकता होती है, तो बर्बाद जगह के लिए कोई गुंजाइश नहीं बचती। इस पैमाने पर, छोटे सुधार बहुत बढ़ जाते हैं, इसलिए एक बार में 1% सुधार भी जश्न मनाने लायक है। और कुछ बदलाव कुल मिलाकर बहुत अधिक होते हैं: इस पोस्ट में, हम देखेंगे कि एक ही एल्गोरिदम में छोटे बदलावों ने हमारी Pingora-आधारित सेवाओं में से एक की मेमोरी खपत को काफी कम कर दिया। इससे हमें वैश्विक स्तर पर 100TB से अधिक RAM वापस पाने में मदद मिली, इसके अलावा DNS टीम पिछले महीने 100TB मेमोरी मुक्त करने में सफल रही थी।

बर्बाद न करें टीमों के बीच संसाधनों का न्यायसंगत बँटवारा बनाए रखना आसान नहीं है, खासकर बड़े संगठनों में। Cloudflare संतुलन बनाए रखने के तरीकों में से एक शानदार Performance टीम के अथक प्रयासों के माध्यम से है। यह कहानी Ivan द्वारा दर्ज किए गए एक टिकट से शुरू होती है, जिसमें उन्होंने पाया: Pingora Backend Router में pingora-ketama से अत्यधिक मेमोरी उपयोग। निष्कर्ष यह था कि हमारी आंतरिक लोड-बैलेंसिंग सेवा, Pingora Backend Router (हाँ, PBR), अपेक्षा से कहीं अधिक मेमोरी का उपयोग कर रही थी — विशेष रूप से pingora-ketama से जुड़ी संरचनाओं में, जो कंसिस्टेंट हैशिंग को संभालने के लिए हमारी ओपन-सोर्स लाइब्रेरी है। यह बताने के लिए कि हमने मेमोरी के इस अत्यधिक उपयोग को कैसे संबोधित किया, हमें यह बताना होगा कि कंसिस्टेंट हैशिंग आखिर क्या है, हम इसे PBR में क्यों उपयोग कर रहे हैं, और यह इतनी मेमोरी-भूखी कैसे बन गई। इस दौरान, हम कुछ Rust सीखेंगे और थोड़ा गणित भी।

कंसिस्टेंट हैशिंग कंसिस्टेंट हैशिंग कई सर्वरों में कार्यों को वितरित करने की एक व्यापक रूप से उपयोग की जाने वाली विधि है, जिसमें सर्वर जोड़ने या हटाने पर बड़े बदलावों की आवश्यकता नहीं होती। आंतरिक रूप से हम इसका उपयोग URL द्वारा कैश करने योग्य अनुरोधों को सर्वर तक रूट करने के लिए करते हैं। यह हमें प्रति डेटा सेंटर एक फ़ाइल की केवल एक प्रति संग्रहीत रखने की अनुमति देता है और प्रत्येक फ़ाइल का स्थान खोजने का एक स्थिर तरीका देता है। हमने इस सिस्टम का पहले भी उल्लेख किया है, लेकिन आइए समय निकालकर समझें कि यह एल्गोरिदम कैसे और क्यों उपयोग किया जाता है और यह कैसे काम करता है। कंसिस्टेंट हैशिंग की मुख्य अवधारणा यह है कि जबकि हैश फ़ंक्शन किसी भी प्रकार का इनपुट स्वीकार कर सकते हैं, उनका आउटपुट एक ही अहस्ताक्षरित पूर्णांक (हैश फ़ंक्शन के आधार पर 32, 64, या 128-बिट पूर्णांक) तक सीमित होता है। यह हमें कार्यों और सर्वरों को एक सुसंगत तरीके से एक-दूसरे से जोड़ने की अनुमति देता है। कंसिस्टेंट हैशिंग की अधिकांश चर्चाएँ आपको उस आउटपुट स्थान को एक सतत, वृत्ताकार रिंग के रूप में सोचने पर मजबूर करती हैं जो अपने अधिकतम मान से शून्य तक लपेटती है। यह चित्रण कुछ सुंदर विज़ुअलाइज़ेशन बनाता है, लेकिन यह पूर्णांक श्रेणियों की सरल अवधारणा को आवश्यकता से अधिक जटिल भी बना सकता है। हमारी चर्चा के लिए, हम अपने हैश फ़ंक्शन के 32-बिट आउटपुट को एक संख्या रेखा के रूप में दर्शाएँगे। अब, मान लें कि हमारे पास सर्वर A, B, और C का एक सेट है, और कार्यों t-z का एक सेट है। हम प्रत्येक को उनके प्रतिनिधि मानों के हैश के आधार पर संख्या रेखा पर मैप कर सकते हैं, जैसे सर्वर के लिए IP पते और कार्यों के लिए कैश कुंजियाँ। अब कार्यों को सर्वरों को सौंपना बस प्रत्येक कार्य के बाईं ओर पहला सर्वर खोजने की बात है। हम प्रत्येक सर्वर से जुड़े हैश के क्षेत्र को रंग करके इसे दृष्टिगत रूप से प्रस्तुत कर सकते हैं। ध्यान दें कि सर्वर C द्वारा कवर की गई सीमा शुरुआत तक लपेटती है, इसलिए यह विचार कि हैश एक रिंग में मौजूद होते हैं। और बस इतना ही। बुनियादी स्तर पर, कंसिस्टेंट हैशिंग इतना ही सरल है — लेकिन यह देखने में ज़्यादा समय नहीं लगता कि सुधार की गुंजाइश है। ध्यान दें कि हमारे उदाहरण में सर्वर A द्वारा कवर की गई सीमा B या C की तुलना में काफी बड़ी है। यह एक समस्या है क्योंकि किसी सर्वर द्वारा संभाले जाने वाले अनुरोधों का अनुपात संख्या रेखा पर उसकी सीमा के आकार के समानुपाती होगा। आदर्श रूप से हम यह गारंटी देना चाहेंगे कि प्रत्येक सर्वर का आकार समान हो, लेकिन चूँकि हैश अनिवार्य रूप से यादृच्छिक संख्याएँ हैं, हमें...