Cloudflare अलोकप्रिय आइटम तक को मेमोरी में cache क्यों करता है
(blog.cloudflare.com)Cloudflare ने अपने ब्लॉग में बताया है कि cache strategy बदलकर उसने SSD पर write load को अधिकतम 25% तक कम किया। (अंग्रेज़ी) आम धारणा के विपरीत, Cloudflare ने कम access होने वाले आइटम भी जानबूझकर मेमोरी में cache करके यह लक्ष्य हासिल किया।
SSD write के प्रति संवेदनशील storage medium है। SSD में data store करने वाले flash memory cell को दोबारा लिखे जा सकने की संख्या सीमित होती है, और एक बार लिखे गए data को मिटाकर फिर से लिखना न केवल अपेक्षाकृत अधिक समय लेता है, बल्कि read operation को भी साथ में धीमा कर देता है। इसलिए SSD में खासकर write operation को कम करना एक महत्वपूर्ण optimization है।
Cloudflare अपने server पर high-performance NVMe SSD का बड़े पैमाने पर उपयोग करता है, इसलिए उसने स्वाभाविक रूप से इस पहलू पर ध्यान दिया। Cloudflare एक CDN कंपनी है, और CDN को मूल रूप से एक बड़े network cache के रूप में देखा जा सकता है। Cloudflare server के SSD में store होने वाली चीज़ें भी आखिरकार cached item ही हैं, और अवलोकन में यह सामने आया कि उनमें से बहुत-सी चीज़ें cache होने के बाद दोबारा कभी access ही नहीं होतीं; इन्हें तथाकथित “one-hit wonder” कहा जाता है। इसलिए ऐसे item को SSD पर लिखना टालना बेहतर होगा। जिन item पर केवल एक बार access होता है, उन्हें SSD पर न लिखने के प्रयोग से उत्साहजनक नतीजा मिला: SSD latency लगभग 5% तक कम हो गई।
समस्या यह थी कि इस विचार को वास्तविक service scale पर कैसे लागू किया जाए। पहली बार access पर cache न करना और दूसरी बार से cache करना, इसका मतलब source data पर access की मात्रा दोगुनी हो जाना है। स्वाभाविक है कि इससे तरह-तरह की लागत बढ़ेगी, और यह उद्देश्य के विपरीत होगा। इसलिए Cloudflare ने cache write को दो-स्तरीय hierarchy में बाँट दिया। शुरुआत में सभी item को ‘short-term cache’ के रूप में मेमोरी में cache किया जाता है, और फिर जिन item पर कई बार access होता है, केवल उन्हें “promote” करके ‘permanent cache’ यानी SSD पर लिखा जाता है। इससे कम access frequency वाले item अपने-आप cache से बाहर हो जाते हैं। read के मामले में अलग से चिंता करने की ज़रूरत नहीं थी, क्योंकि SSD से read करना operating system पहले से ही अच्छी तरह cache कर देता है।
बेशक, इस विचार को वास्तविक service में लागू करना सावधानी और रूढ़िवादी तरीके से किया जा रहा है। यह तरीका मूल रूप से काफी memory consume करता है, जिससे operating system के मौजूदा cache के साथ competition हो सकता है। या फिर server process को zero-downtime deployment तरीके से update करते समय अस्थायी memory shortage हो सकती है, जिससे अंततः service quality खराब हो सकती है। इसलिए इस विचार को फिलहाल केवल उन नए server पर धीरे-धीरे लागू किया जा रहा है जिनमें पर्याप्त memory जोड़ी गई है।
परिणाम सकारात्मक रहे हैं। cache capacity को tune करते हुए लागू करने पर SSD write 20% से लेकर अधिकतम 25% तक कम हुए, और इससे latency भी घटी। आगे चलकर Cloudflare इस technique को और अधिक server तक फैलाने, promotion algorithm को बेहतर बनाने, “demotion” भी जोड़ने, और केवल SSD ही नहीं बल्कि HDD को भी ध्यान में रखकर multi-tier hierarchy बनाने की योजना रखता है।
इस विचार को देखकर सबसे पहले Java की garbage collection technique याद आती है। अधिकतर garbage collection तरीकों की बुनियादी मान्यता यही होती है कि [ज़्यादातर object बहुत कम समय के लिए ही उपयोग में रहते हैं], जिसे तथाकथित ‘weak generational hypothesis’ कहा जाता है। संभव है कि ऊपर का विचार इसी सिद्धांत का एक परिवर्तित रूप में लागू उदाहरण हो।
3 टिप्पणियां
अच्छा लेख है, धन्यवाद.
लगता है Cloudflare ब्लॉग पर चुपचाप पढ़ने लायक बहुत-से लेख आते रहते हैं.
अच्छी कंपनी का टेक ब्लॉग कैसे चलाया जाता है https://hi.news.hada.io/topic?id=1698
शायद ऐसा इसलिए है क्योंकि Cloudflare में ब्लॉगिंग कंपनी की आंतरिक संस्कृति के रूप में अच्छी तरह स्थापित हो चुकी है.
बहुत दिलचस्प था, धन्यवाद।
वाह.. अनुवाद भी एक साथ हाहा, अच्छी जानकारी साझा करने के लिए धन्यवाद।