Transcript
00:00:00एक बाइट की असल कीमत क्या हो सकती है?
00:00:02खैर, क्लाउडफ्लेयर के पैमाने पर हर एंट्री पर एक बाइट बर्बाद होने से
00:00:04उनके पूरे फ्लीट की 250 गीगाबाइट से ज़्यादा
00:00:06मेमोरी खर्च होती है,
00:00:08और हाल ही में उन्होंने वास्तव में प्रति एंट्री मेमोरी को आधा कर दिया,
00:00:11जिससे 100 टेराबाइट मेमोरी खाली हो गई।
00:00:13इस दौर में, यह बहुत सारा पैसा है।
00:00:15उन्होंने वास्तव में अपने कैशिंग सिस्टम में
00:00:17पाँच बहुत सरल बदलाव करके ऐसा किया,
00:00:18और साथ ही डीएनएस को भी तेज़ बना दिया,
00:00:21तो चलिए देखते हैं कि उन्होंने यह कैसे किया।
00:00:27अब, आपने शायद पहले 1.1.1.1 के बारे में सुना होगा।
00:00:30यह क्लाउडफ्लेयर का पब्लिक डीएनएस रिजॉल्वर है,
00:00:32और यह उस डोमेन को लेकर काम करता है जहाँ आप जाना चाहते हैं,
00:00:34जैसे betterstack.com,
00:00:35और यह पता लगाता है कि उस डोमेन का असली आईपी वास्तव में क्या है।
00:00:39अब, असल में यह काम करने वाली चीज़,
00:00:40इसे बिग पाइनएप्पल कहा जाता है और यह रस्ट में लिखी गई है,
00:00:42और जैसा कि आप अंदाज़ा लगा सकते हैं,
00:00:43यह सॉफ़्टवेयर का एक बेहद व्यस्त हिस्सा है,
00:00:46जो किसी भी समय 250 अरब से ज़्यादा डीएनएस कैश एंट्री को स्टोर करता है।
00:00:50यह सुनिश्चित करता है कि अगर कोई किसी दूसरे व्यक्ति के दो सेकंड बाद
00:00:52betterstack.com पर जाना चाहता है,
00:00:53तो इसे पूरे डीएनएस पदानुक्रम से दोबारा नहीं गुजरना पड़ता,
00:00:56बल्कि यह जवाब को मेमोरी में रखता है और सीधे वापस दे देता है।
00:00:59लेकिन जैसा कि मैंने शुरुआत में बताया,
00:01:01250 अरब कैश एंट्री का मतलब है कि प्रति एंट्री एक बर्बाद बाइट
00:01:04लगभग 250 गीगाबाइट रैम की कीमत चुकाती है,
00:01:07और यही कारण है कि इन पाँच बदलावों का इतना बड़ा प्रभाव पड़ा।
00:01:10सबसे पहले, हमारे पास क्षमता की लागत है।
00:01:12यहाँ बताया गया है कि कैश एंट्री पहले कैसी दिखती थी।
00:01:14टाइमस्टैम्प, जीने का समय, हिट काउंटर,
00:01:16और फिर कई सारे वेक्टर।
00:01:17उत्तर रिकॉर्ड का एक वेक्टर,
00:01:18अथॉरिटी रिकॉर्ड का एक वेक्टर,
00:01:20अतिरिक्त रिकॉर्ड का एक वेक्टर,
00:01:21त्रुटियों का एक वेक्टर,
00:01:22और बहुत कुछ।
00:01:23आप में से जो लोग रस्ट से परिचित नहीं हैं,
00:01:25वेक्टर बढ़ने वाली सूची के लिए सिर्फ एक पसंदीदा डेटा प्रकार है,
00:01:27और यह मेमोरी में तीन चीज़ें भी है।
00:01:29एक पॉइंटर, एक लंबाई, और एक क्षमता।
00:01:31यह वह जगह है जो बढ़ने के लिए आरक्षित है,
00:01:32ताकि जब भी आप इसमें कुछ जोड़ें तो इसे दोबारा आवंटित न करना पड़े।
00:01:35जो कि बहुत उपयोगी है यदि चीज़ वास्तव में बढ़ती है।
00:01:38लेकिन उन्होंने वास्तविक डीएनएस कैश प्रविष्टियों को देखा,
00:01:40और उन्हें एहसास हुआ कि सब कुछ सिर्फ कैश में लिखा गया था,
00:01:42और फिर कभी छुआ नहीं गया।
00:01:44इसे केवल पढ़ा जा रहा था,
00:01:45इसलिए ये वेक्टर वास्तव में कभी नहीं बढ़े।
00:01:47इसका मतलब है कि ज़रूरत से ज़्यादा हीप स्पेस आवंटित है,
00:01:49जो बस बेकार पड़ा है।
00:01:50आठ आइटम की क्षमता वाला एक वेक्टर है,
00:01:52लेकिन केवल पाँच ही संग्रहीत हैं,
00:01:53तीन स्लॉट खाली रह जाते हैं,
00:01:55और क्षमता फ़ील्ड स्वयं एक उपयोग आकार है,
00:01:57जो मेमोरी के आठ बाइट हैं,
00:01:58जिसकी उनके लिए कोई ज़रूरत नहीं है।
00:02:00अब इसके लिए समाधान बेहद आसान था।
00:02:02बस एक वेक्टर को एक बॉक्स से बदल दें,
00:02:04क्योंकि एक बॉक्स का आकार उस आकार पर तय होता है जिस पर यह बनाया गया था,
00:02:07इसलिए इसे क्षमता फ़ील्ड की आवश्यकता नहीं है,
00:02:08और यह वही संग्रहीत करता है जो वहाँ है।
00:02:10इसे अतिरिक्त भविष्य की क्षमता आवंटित करने की आवश्यकता नहीं है।
00:02:13उन्होंने यह भी महसूस किया कि वे ठीक यही बचत लागू कर सकते हैं
00:02:15स्ट्रिंग फ़ील्ड पर भी,
00:02:16चूंकि वे अनिवार्य रूप से U8 का एक वेक्टर हैं,
00:02:18ताकि वह पाठ बढ़ या सिकुड़ सके,
00:02:20लेकिन अगर आपको इसकी आवश्यकता नहीं है,
00:02:21तो आप बस एक बॉक्स स्ट्रिंग स्लाइस का उपयोग कर सकते हैं,
00:02:23यानी यह स्ट्रिंग बदलने नहीं जा रही है।
00:02:26कुल मिलाकर, एक कैश प्रविष्टि पर,
00:02:27आठ वेक्टर और स्ट्रिंग फ़ील्ड थे,
00:02:29इसलिए उन्हें एक बॉक्स से बदलने पर प्रति फ़ील्ड आठ बाइट्स की बचत हुई,
00:02:31और प्रति प्रविष्टि 64 बाइट्स,
00:02:33साथ ही अतिरिक्त हीप स्पेस को भी समाप्त कर दिया गया
00:02:35जो एक वेक्टर भविष्य की वृद्धि के लिए आरक्षित रखता है,
00:02:36जिसका अर्थ है कि जब 250 अरब कैश प्रविष्टियों तक बढ़ाया गया तो संयुक्त बचत 15 टेराबाइट से अधिक हो गई।
00:02:39जब 250 अरब कैश प्रविष्टियों तक बढ़ाया गया तो संयुक्त बचत 15 टेराबाइट से अधिक हो गई।
00:02:42यह सब एक साधारण डेटा प्रकार के बदलाव से हुआ।
00:02:45हालाँकि हमारे अगले बदलाव के लिए,
00:02:46उन्होंने वास्तव में उन सूचियों में से कुछ को देखा,
00:02:48और बस पूछा, क्या हमें वास्तव में उनकी आवश्यकता है?
00:02:50एक डीएनएस प्रतिक्रिया में तीन प्रविष्टियाँ होती हैं,
00:02:52उत्तर, प्राधिकरण, और अतिरिक्त,
00:02:54और जैसा कि हमने पहले देखा,
00:02:55इन्हें कैश किया गया था जैसे वे आए थे,
00:02:57तीन अलग-अलग सूचियाँ,
00:02:58और भले ही हमने परिवर्तन 1 में क्षमता फ़ील्ड को हटा दिया,
00:03:01प्रत्येक सूची अभी भी एक पॉइंटर और एक लंबाई है,
00:03:03तो आठ बाइट्स प्लस आठ बाइट्स गुना तीन,
00:03:05जो कुल मिलाकर 48 बाइट्स है,
00:03:07और तीन अलग-अलग हीप आवंटन।
00:03:09लेकिन जब उन्होंने देखा कि इन सूचियों का उपयोग
00:03:10वास्तव में कैसे किया जा रहा था,
00:03:12तो उन्हें एहसास हुआ कि वे हमेशा एक साथ पढ़े जाते थे,
00:03:13हमेशा एक साथ लिखे जाते थे,
00:03:14और वे हमेशा ठीक उसी क्रम में होते हैं।
00:03:16इसलिए तीन सूचियों के बजाय,
00:03:17वे इसे दो विभाजकों वाली एक सूची के रूप में मान सकते हैं।
00:03:20तो तीन सूचियाँ रिकॉर्ड की एक सूची बन जाती हैं,
00:03:22साथ ही दो छोटे ऑफ़सेट जो कहते हैं कि उत्तर यहाँ समाप्त होते हैं,
00:03:25और प्राधिकरण यहाँ समाप्त होता है,
00:03:26और चूंकि डीएनएस प्रतिक्रिया में कभी भी चार अरब रिकॉर्ड नहीं होने वाले हैं,
00:03:29एक 16-बिट अहस्ताक्षरित पूर्णांक ऑफ़सेट के लिए पर्याप्त होगा,
00:03:33जो प्रत्येक केवल दो बाइट है।
00:03:34इसका मतलब है कि कुल मिलाकर,
00:03:35उन्होंने दो पूरे 16-बाइट हेडर को दो 2-बाइट नंबरों से बदल दिया,
00:03:39इसलिए प्रति प्रविष्टि 28 बाइट्स की बचत हुई,
00:03:41और इससे रस्ट को फ़ील्ड के बीच कुछ अतिरिक्त रिक्ति को हटाने में भी मदद मिलती है,
00:03:44जिससे संरचना केवल हटाए गए फ़ील्ड की तुलना में छोटी हो जाती है।
00:03:47उन्होंने इस अवधारणा को और आगे बढ़ाया,
00:03:49और कई बुलियन फ़ील्ड को एक ही बिट फ़्लैग में विलीन कर दिया।
00:03:52नंबर तीन पर चलते हैं,
00:03:53क्या होगा यदि हम एक ही नाम को दो बार कहना बंद कर दें?
00:03:55प्रत्येक डीएनएस रिकॉर्ड एक स्वामी होता है,
00:03:57जो कि डोमेन नाम है जिससे वह रिकॉर्ड संबंधित है।
00:04:00तो जब आप betterstack.com पर क्वेरी करते हैं और आपको अपने रिकॉर्ड वापस मिलते हैं,
00:04:03तो प्रत्येक पर betterstack.com लिखा होता है।
00:04:05लेकिन वह जानकारी एक तरह से अनावश्यक है।
00:04:08आप वह हैं जिसने सवाल पूछा,
00:04:09इसलिए यह पहले से ही डोमेन नाम जानता है।
00:04:11और क्लाउडफ्लेयर वास्तव में उस क्वेरी डोमेन को पहले से ही कैश कुंजी के रूप में संग्रहीत कर रहा था,
00:04:14तो उन्हें मालिक के रूप में इसे फिर से स्टोर करने की आवश्यकता क्यों है?
00:04:17खैर, वे नहीं करते।
00:04:17इसलिए क्लाउडफ्लेयर ने इस फ़ील्ड को एक वैकल्पिक बॉक्स नाम में बदल दिया,
00:04:20जहाँ यदि स्वामी क्वेरी से मेल खाता है,
00:04:22आप कुछ भी स्टोर नहीं करते,
00:04:23लेकिन अगर यह वास्तव में अलग है,
00:04:24जो कि CNAMEChains जैसे कुछ मामलों में हो सकता है,
00:04:27आप पहले की तरह मालिक को स्टोर करते हैं।
00:04:29ऐसा करके, सामान्य मामलों के लिए जहाँ वे मेल खाते हैं,
00:04:32वे प्रति रिकॉर्ड एक पूरा हीप आवंटन बचाते हैं,
00:04:34इसलिए यह बचत केवल यह देखने का मामला था कि उनके कैश में कौन सा डेटा था
00:04:37और यह महसूस करना कि डुप्लिकेट मूल्य थे।
00:04:39बचत संख्या चार के लिए, हमारे पास आईपी पते द्वारा 144 है।
00:04:43उनका रिकॉर्ड डेटा ए रिकॉर्ड, 4 ए रिकॉर्ड, टेक्स्ट का एक रस्ट एनम था,
00:04:47SVCB, और NAPTR, एक प्रकार उन सभी को कवर करता है।
00:04:51लेकिन यहाँ एनम के साथ समस्या है।
00:04:52वे हमेशा अपने सबसे बड़े प्रकार जितने बड़े होते हैं।
00:04:54उस प्रकार का प्रत्येक मूल्य स्थान की समान मात्रा लेता है,
00:04:57चाहे इसकी आवश्यकता हो या नहीं।
00:04:58उस मामले में, NAPTR सबसे बड़ा मान है, जो 136 बाइट्स लेता है,
00:05:03और जब आप एनम में टैग और पैडिंग जोड़ते हैं, तो यह 144 बाइट्स हो जाता है।
00:05:07यदि आप इसकी तुलना उस चीज़ से करें जिसकी A रिकॉर्ड को आवश्यकता होती है, जो सिर्फ एक साधारण IPv4 पता है,
00:05:12तो उसके लिए केवल चार बाइट्स की आवश्यकता होगी।
00:05:13इसका मतलब है कि उस कैश में हर A रिकॉर्ड 144 बाइट के डिब्बे में बैठा था,
00:05:17केवल उनमें से चार का उपयोग करते हुए,
00:05:19और A तथा 4A रिकॉर्ड वास्तविक ट्रैफ़िक का अधिकांश हिस्सा हैं।
00:05:22क्लाउडफ्लेयर के अपने बेंचमार्क मिक्स में, यह 56% A रिकॉर्ड, 25% 4A है, इसलिए कैश का अधिकांश हिस्सा सिर्फ पैडिंग था।
00:05:29इसके लिए हमारा भरोसेमंद समाधान बॉक्स था।
00:05:32उन्होंने बड़े वेरिएंट्स को बॉक्स कर दिया और A तथा 4A को इनलाइन छोड़ दिया, क्योंकि यह छोटा और सामान्य है,
00:05:36इसलिए अब टेक्स्ट, SVCB, और NAPTR एक पॉइंटर के पीछे हैं,
00:05:40इसलिए एनम को केवल बचे हुए सबसे बड़े वाले जितना बड़ा होना पड़ता है, जो कि वह 16 बाइट का IPv6 पता है।
00:05:45कुल मिलाकर, A या 4A रिकॉर्ड के लिए, प्रत्येक में 120 बाइट्स की बचत होती है।
00:05:50लेकिन इस बदलाव का वास्तव में एक ट्रेड-ऑफ़ है।
00:05:52जब आप किसी वेरिएंट को बॉक्स करते हैं, तो उसका डेटा कैश प्रविष्टि के अंदर बैठने से हटकर,
00:05:55हीं और पूरी तरह से हीप के अपने क्षेत्र में बैठने के लिए चला जाता है,
00:05:58और इससे आपको दो नई लागतें चुकानी पड़ती हैं।
00:06:00पहली लागत एलोकैटर की है।
00:06:02क्लाउडफ्लेयर जेमालॉक का उपयोग करता है, और जेमालॉक आपको पूछे गए बाइट्स की सटीक संख्या नहीं देता है,
00:06:06यह आवंटन को निश्चित आकार के डिब्बों में समूहित करता है और आपको निकटतम तक गोल कर देता है।
00:06:10इसलिए एक टेक्स्ट रिकॉर्ड जो 32 बाइट्स मांगता है वह 32-बाइट बिन में उतरता है और कुछ भी बर्बाद नहीं करता है,
00:06:15लेकिन एक MX रिकॉर्ड 40 मांगता है, उसे 48 बाइट्स तक पूर्णांकित किया जाता है, और चुपचाप आपके 8 बाइट्स का नुकसान हो जाता है।
00:06:21दूसरी लागत स्थानीयता (लोकेलिटी) की है।
00:06:22बॉक्सिंग से पहले, किसी प्रविष्टि के लिए सभी रिकॉर्ड डेटा मेमोरी के एक सन्निहित ब्लॉक में बैठे थे,
00:06:27और बॉक्सिंग के बाद, प्रत्येक कहीं और रहता है, और इसे पढ़ने का मतलब एक पॉइंटर का अनुसरण करना है,
00:06:31और यदि वह पॉइंटर प्रविष्टि के बाकी हिस्सों से बहुत दूर उतरता है,
00:06:34तो आपके CPU को केवल इसे पढ़ने के लिए पूरी तरह से एक नया कैश लाइन प्राप्त करना होगा।
00:06:37इसलिए जब बॉक्सिंग ने पैडिंग की समस्या को ठीक कर दिया, तो इसने अपनी खुद की एक समस्या पैदा कर दी,
00:06:41और तभी क्लाउडफ्लेयर ने सोचा, क्या होगा यदि हम उन्हें रस्ट प्रकारों के रूप में बिल्कुल भी संग्रहीत न करें?
00:06:45खैर, यह बदलाव नंबर पांच है।
00:06:46क्लाउडफ्लेयर ने इसे एक मध्यम मार्ग के रूप में वर्णित किया, कैश प्रविष्टि के बाकी हिस्सों को सामान्य संरचित
00:06:50फ़ील्ड के रूप में रखें, लेकिन रिकॉर्ड डेटा को लें और इसे कच्चे बाइट्स के रूप में संग्रहीत करें।
00:06:54इसलिए प्रति रिकॉर्ड एक एनम या बॉक्स के बजाय, पूरी प्रविष्टि को एक सिंगल बॉक्स U8 सरणी मिलती है,
00:07:00जिसमें प्रत्येक रिकॉर्ड को 2-बाइट लंबाई उपसर्ग के रूप में लिखा जाता है, जिसके बाद उसका डेटा होता है।
00:07:03यह उन दोनों लागतों को पूर्ववत कर देता है जिनके बारे में हमने अभी बात की थी।
00:07:06वे सभी अलग-अलग बॉक्स किए गए आवंटन सभी रिकॉर्ड डेटा के लिए एक आवंटन में ढह जाते हैं,
00:07:10इसलिए अब जेमालॉक बिन में प्रति रिकॉर्ड राउंडिंग अप नहीं है,
00:07:13और यह सब फिर से सन्निहित रूप से पैक किया गया है, ताकि आप उस कैश स्थानीयता को वापस पा सकें जो बॉक्सिंग ने छीन ली थी।
00:07:18और एक अतिरिक्त बोनस के रूप में, यह लुकअप को भी तेज बनाता है।
00:07:21पहले, प्रत्येक कैश हिट पर, आपके पास मेमोरी में एक पार्स किया हुआ रिकॉर्ड बैठा होता था,
00:07:25और किसी भी चीज़ को भेजने से पहले आपको इसे फ़ील्ड-दर-फ़ील्ड वापस DNS वायर प्रारूप में सीरियलाइज़ करना पड़ता था।
00:07:30हालाँकि अब, यह पहले से ही DNS वायर प्रारूप में है, इसलिए अधिकांश रिकॉर्ड प्रकार सीधे बफर से
00:07:35बाहर जाने वाले संदेश में कॉपी हो जाते हैं।
00:07:37केवल वही जिन्हें अभी भी पार्सिंग की आवश्यकता है वे रिकॉर्ड हैं जिनमें डोमेन नाम शामिल हैं,
00:07:40इसलिए CNAME, NS, MX, और SOA,
00:07:43और ऐसा इसलिए है क्योंकि DNS नाम संपीड़न का मतलब है कि आपको वैसे भी उन नामों को फिर से लिखना होगा।
00:07:47इसलिए यह अंतिम परिवर्तन मेमोरी को काट देता है और हॉट पाथ से बहुत सारे काम को हटा देता है।
00:07:51तो वहाँ हम जाते हैं, यह कैश में 5 निम्न-स्तरीय परिवर्तन हैं,
00:07:54जो संयुक्त होने पर प्रति-प्रविष्टि पदचिह्न को 953 बाइट्स से घटाकर 420 कर देते हैं,
00:08:00इसलिए 56% छोटा, और प्रति-प्रविष्टि वास्तव में आवंटित मेमोरी 1.1 किलोबाइट से
00:08:05घटकर 461 बाइट्स हो गई, यानी 58% की कटौती।
00:08:09इसके शीर्ष पर, उनका इंसर्ट थ्रूपुट भी 43% बढ़ गया,
00:08:12625,000 प्रविष्टियों प्रति सेकंड से बढ़कर 893,000 हो गया,
00:08:17और लुकअप भी 19% तेज हो गए, 828 नैनोसेकंड से घटकर 670 हो गए।
00:08:23उन्होंने इस साल प्रोडक्शन में इन बदलावों को शुरू किया,
00:08:25और उनकी P99 रेजिडेंट मेमोरी 9.3 गीकबाइट से घटकर 5.3 हो गई,
00:08:29तो वास्तविक ट्रैफ़िक पर 43% की कटौती,
00:08:32जो फ़लीट-व्यापी रूप से लगभग 100 टेराबाइट मेमोरी मुक्त है,
00:08:35या उस Gen 13 सर्वर के RAM के मूल्य का 130 गुना है।
00:08:38अब वे एक बड़ा कैश रखने के लिए उस अतिरिक्त स्थान का उपयोग करने की योजना बना रहे हैं,
00:08:41चीजों को और भी तेज कर रहा है।
00:08:43मुझे यह ब्लॉग पोस्ट वास्तव में पसंद है क्योंकि यह एक ऐसे निर्णय को उजागर करता है जो हमें करना होगा।
00:08:46क्या हमें इसमें से किसी भी चीज़ को बनाने से पहले बैठकर सभी अनुकूलन पर काम करना चाहिए था,
00:08:50या क्या वह समय से पहले का अनुकूलन होता?
00:08:52और मैं कल्पना करता हूं कि 2018 में वापस जब यह बनाया गया था,
00:08:55क्लाउडफ्लेयर के लिए रैम की लागत उतनी महत्वपूर्ण नहीं थी जितनी आज है।
00:08:59पूरी पोस्ट एक महान लेख है, इसलिए मैं इसे नीचे लिंक कर दूंगा।
00:09:02मुझे टिप्पणियों में बताएं कि आप इसके बारे में क्या सोचते हैं,
00:09:03जब आप वहां हों तो सदस्यता लें,
00:09:04और हमेशा की तरह, अगले में मिलते हैं।
00:09:05अगले में मिलते हैं।
Community Posts
No posts yet. Be the first to write about this video!
Write about this video