टीएल;डीआर
- समस्या: बड़े पैमाने की वास्तुकला (आर्किटेक्चर) तैयार करने के लिए उपलब्धता, थ्रूपुट और परिचालन जटिलता के बीच संतुलन बनाना आवश्यक है।
- मुख्य निष्कर्ष: बिलकुल शुरुआती लोगों के लिए गूगल ड्राइव जैसा स्टोरेज: अपलोड, डाउनलोड, सिंक, चंक, वर्शन, शेयर, और जब दो फ़ोन ऑफलाइन एक ही फ़ाइल एडिट करें तो क्या होता है।
- परिणाम: उत्पादन वातावरण में विफलता से निपटने और प्रदर्शन लक्ष्यों को हासिल करने की सटीक रूपरेखा।
एक जादुई फ़ोल्डर सोचो। लैपटॉप पर उसमें एक फ़ोटो डालते हो। बस में फ़ोन खोलते हो और वही फ़ोटो पहले से वहाँ है। दफ़्तर में स्प्रेडशीट एडिट करते हो। घर पर टैबलेट नए नंबर दिखाता है। कुछ "सर्वर" जैसा नहीं लगता। लगता है एक ही फ़ोल्डर हर जगह एक साथ रहता है।
जब कोई कहता है "गूगल ड्राइव डिज़ाइन करो" तो यही प्रोडक्ट मतलब होता है। शीशे के नीचे जादू नहीं है। छह विचारों पर सावधानी से इंजीनियरिंग है: अपलोड, डाउनलोड, सिंक, चंक (टुकड़े), वर्शन, और शेयर। यह पोस्ट हर एक को वैसे समझाती है जैसे मैं एक होशियार छात्र को सिखाऊँ जिसने कभी सिस्टम डायग्राम नहीं खींचा।
लाइव सह-संपादन (एक ही गूगल डॉक में कई लोग एक साथ टाइप) दायरे से बाहर। वह अलग, कठिन प्रोडक्ट है। यहाँ हम साधारण फ़ाइलों का फ़ोल्डर डिज़ाइन करते हैं: पीडीएफ, फ़ोटो, ज़िप, ऑफिस दस्तावेज़।
जादुई फ़ोल्डर, सादे शब्दों में
तुम्हारे डिवाइस फ़ाइलों का असली घर नहीं हैं। असली घर क्लाउड में एक बड़ा, सावधान कंप्यूटर सिस्टम है। हर फ़ोन या लैपटॉप उन फ़ाइलों की एक कॉपी रखता है जिनकी तुम्हें परवाह है (या उनकी सूची, अगर वे बहुत बड़ी हों)। जब कुछ बदलते हो, डिवाइस क्लाउड को बताता है। जब क्लाउड किसी बदलाव के बारे में जानता है, वह तुम्हारे दूसरे डिवाइसों को बताता है। "हर जगह दिखने वाला फ़ोल्डर" उसी लूप से बनी भ्रांति है।
दो काम कभी फेल नहीं होने चाहिए:
१. बाइट्स गायब नहीं होने चाहिए। शादी का वीडियो अपलोड किया और खो गया तो वह बग नहीं, आपदा है।
२. नाम और "नवीनतम वर्शन कौन सा है" हर संबंधित डिवाइस पर एक होने चाहिए। अगर फ़ोन कहे budget.xlsx खाली है और लैपटॉप में पिछले हफ़्ते के नंबर हों, तो उपयोगकर्ता डेटा मिटा समझेंगे भले बाइट्स सुरक्षित हों।
नीचे की हर बात इन्हीं दो कामों के लिए है।
अपलोड: फ़ाइल को क्लाउड में रखना
अपलोड का मतलब: "मेरे डिवाइस से यह फ़ाइल ले जाओ और दूर, सुरक्षित जगह स्टोर करो।"
छोटी फ़ाइल (छोटा टेक्स्ट नोट) के लिए ऐप पूरी फ़ाइल एक बार में भेज सकता है। बड़ी फ़ाइल (अस्थिर मोबाइल डेटा पर २ जीबी वीडियो) के लिए एक लंबा भेजना अक्सर बीच में टूट जाता है। इसलिए ड्राइव जैसे गंभीर सिस्टम फिर से शुरू होने वाला अपलोड (resumable upload) इस्तेमाल करते हैं:
१. ऐप सर्वर से पूछता है: "मैं इतनी बड़ी फ़ाइल, इस नाम से, इस फ़ोल्डर में अपलोड करना चाहता हूँ।" २. सर्वर एक सेशन शुरू करता है और कहता है: "ठीक है। मुझे टुकड़े भेजो। कट जाए तो पूछना कहाँ तक पहुँचे थे।" ३. ऐप फ़ाइल टुकड़ों में भेजता है। वाई-फ़ाई ७०% पर मर जाए तो फिर जुड़कर ७०% से जारी रखता है, शून्य से नहीं।
बॉडी स्वीकार करने से पहले सर्वर साधारण नियम जाँचता है: क्या उपयोगकर्ता यहाँ लिख सकता है? क्या फ़ाइल आकार सीमा के अंदर है? क्या कोटा बचा है?
क्लास नोट: उपयोगकर्ता को "अपलोड पूरा" तब तक मत कहो जब तक दो बातें सच न हों: फ़ाइल के बाइट्स सुरक्षित स्टोर हो चुके हों, और उन बाइट्स की ओर इशारा करने वाली डेटाबेस पंक्ति सेव हो चुकी हो। सिर्फ़ एक बचाओगे तो भूतिया फ़ाइलें या अनाथ डेटा मिलेंगे।
डाउनलोड: फ़ाइल वापस लाना
डाउनलोड उलटा है: "इस फ़ाइल के बाइट्स दो ताकि मैं खोल सकूँ या सेव कर सकूँ।"
बड़े सिस्टम शायद ही कभी विशाल फ़ाइलें उन्हीं छोटे एपीआई सर्वरों से धकेलते हैं जो लॉगिन और फ़ोल्डर सूची संभालते हैं। आम पैटर्न यह है:
१. ऐप पूछता है: "क्या मैं फ़ाइल एक्स डाउनलोड कर सकता हूँ?" २. एपीआई अनुमति जाँचता है। ३. एपीआई बड़े फ़ाइल गोदाम की ओर एक अल्पकालिक विशेष लिंक (signed यूआरएल) देता है। ४. ऐप बाइट्स सीधे उस गोदाम से लाता है।
जिन सिंक ऐप्स के पास फ़ाइल का ज़्यादातर हिस्सा पहले से है, वे अक्सर पूरी फ़ाइल फिर नहीं लाते, सिर्फ़ बदले हुए टुकड़े लाते हैं (नीचे चंक देखो)।
सिंक: हर डिवाइस को ईमानदार रखना
सिंक जादुई फ़ोल्डर का दिल है। मतलब: कहीं कुछ बदले के बाद बाकी जगहें पकड़ लें।
एक साधारण कहानी:
१. लैपटॉप पर trip.jpg का नाम paris.jpg करते हो।
२. लैपटॉप क्लाउड से कहता है: "अब इस फ़ाइल का नाम paris.jpg है।"
३. क्लाउड वह तथ्य सेव करता है और फ़ोन को पिंग करता है: "इस फ़ोल्डर में कुछ बदला।"
४. फ़ोन बदलावों की सूची माँगता है, नाम बदल देखता है, और स्थानीय नाम अपडेट करता है।
अगर फ़ोन ऑफलाइन था (एयरप्लेन मोड), पिंग छूट गया। वापस ऑनलाइन आने पर वह कहता है: "मैं दुनिया को आखिरी बार बदलाव नंबर १२०० तक जानता था। उसके बाद क्या हुआ?" क्लाउड कैच-अप सूची भेजता है। उस नंबर को अक्सर कर्सर या change id कहते हैं। फ़ोल्डर के इतिहास में बुकमार्क समझो।
सिंक का मतलब "खुद को ईमेल से फ़ाइल भेजना" नहीं है। सिंक लगातार, अपने आप, और दोतरफ़ा होता है (जब प्रोडक्ट कई डिवाइस से एडिट की अनुमति दे)।
चंक: बड़ी फ़ाइलों को टुकड़ों में तोड़ना
एक टाइपो सुधारने पर ५० एमबी स्लाइड डेक फिर अपलोड करना मोबाइल डेटा और सब्र दोनों जलाता है।
इसलिए सिस्टम अक्सर फ़ाइल को चंक (टुकड़ों) में बाँटता है (इन्हें ब्लॉक भी कहते हैं)। क्लास में आम आकार प्रति चंक कुछ मेगाबाइट होता है।
एक लंबी ट्रेन के डिब्बे सोचो। हर डिब्बा एक चंक है। हर डिब्बे को एक उंगली की छाप (हैश) मिलती है: उसके सही बाइट्स से निकला छोटा कोड। वही बाइट्स हमेशा वही छाप देते हैं।
क्लाउड क्या रखता है:
- विशाल गोदाम (object storage) में कच्चे चंक ऑब्जेक्ट।
- हर वर्शन की रेसिपी: "report.pdf का वर्शन ७ चंक ए, फिर बी, फिर सी, उसी क्रम में है।"
जब एडिट करो और सिर्फ़ बीच बदले:
१. ऐप नए चंक फिर हैश करता है। २. बिना बदले चंक पहले से गोदाम में हैं। उन्हें फिर मत अपलोड करो। ३. सिर्फ़ नई छापें अपलोड होती हैं। ४. नई रेसिपी (वर्शन ८) छापों की नई क्रम सूची की ओर इशारा करती है।
यह क्यों ज़रूरी है:
- डेल्टा सिंक: सिर्फ़ बदला हुआ भेजो।
- डेडअप: दो फ़ाइलें एक जैसी चंक साझा करें (एक ही छाप) तो वह चंक एक बार स्टोर हो सकती है (कम से कम एक अकाउंट के अंदर)।
- पूरी कॉपी के बिना इतिहास: पुराने वर्शन अपनी रेसिपी रखते हैं। बिना बदले साझा चंक हर वर्शन के लिए दोहराए नहीं जाते।
फ़ाइल खोलने के लिए क्लाइंट रेसिपी पढ़ता है, गायब डिब्बे डाउनलोड करता है, फिर क्रम से जोड़ता है।
वर्शन: अनडू का निशान
उपयोगकर्ता पसंद करते हैं "मुझे पिछले मंगलवार की कॉपी चाहिए।" ड्राइव जैसा सिस्टम फ़ाइल के वर्शन रखता है।
हर सफल सेव एक नई वर्शन पंक्ति बना सकता है: किसने सेव किया, कब, आकार, चेकसम, और क्रम वाली चंक सूची। फ़ोल्डर पेड़ हर फ़ाइल नाम के वर्तमान वर्शन की ओर इशारा करता है। पुराने वर्शन इतिहास में रहते हैं जब तक रिटेंशन नीति उन्हें हटाए।
महत्वपूर्ण डिज़ाइन नियम: वर्शन को सिर्फ़ जोड़ने वाला (append-only) समझो। पुरानी रेसिपी को जगह पर ओवरराइट मत करो। नई पूरी तरह तैयार हो तब फ़ाइल को नए वर्शन की ओर मोड़ो। आधा अपलोड कभी "आधिकारिक फ़ाइल" न बने।
शेयर: दूसरों को अंदर आने देना
शेयर का मतलब: "यह व्यक्ति इस फ़ाइल या फ़ोल्डर को पढ़ (या एडिट) सकता है।"
पर्दे के पीछे यह एक ACL (एक्सेस कंट्रोल लिस्ट) है: पंक्तियाँ जो कहती हैं "उपयोगकर्ता बी के पास फ़ोल्डर Projects पर लेखक भूमिका है।" हर डाउनलोड और हर मेटाडेटा रीड इन नियमों की जाँच करे। साइन किया डाउनलोड लिंक अल्पकालिक और अनुमान लगाना कठिन हो, या सही व्यक्ति से जुड़ा हो, ताकि लीक लिंक हमेशा के लिए न जिए।
शेयर सिंक को भी प्रभावित करता है। टीममेट के साथ फ़ोल्डर शेयर करो तो उनके डिवाइस उस फ़ोल्डर के बदलाव सीखने लगें। पहुँच वापस लो तो उनके क्लाइंट वे बदलाव मिलना बंद करें (और प्रोडक्ट नीति के अनुसार स्थानीय कॉपी भी खो सकते हैं)।
संघर्ष: दो फ़ोन की कहानी
क्लास में मैं यह कहानी सुनाता हूँ।
तुम्हारे पास दो फ़ोन हैं। दोनों में जादुई फ़ोल्डर है। उड़ान में दोनों ऑफलाइन हो जाते हैं। फ़ोन ए पर notes.txt एडिट करके लिखते हो "दूध खरीदना।" फ़ोन बी पर वही notes.txt एडिट करके लिखते हो "अंडे खरीदना।" अभी कोई फ़ोन क्लाउड से बात नहीं कर सकता, इसलिए हर फ़ोन अपनी एडिट को सही मानता है।
लैंड करते हो। फ़ोन ए पहले ऑनलाइन आता है और अपना वर्शन अपलोड करता है। क्लाउड स्वीकार करता है। सर्वर पर notes.txt अब "दूध खरीदना" कहता है।
फ़ोन बी ऑनलाइन आकर "अंडे खरीदना" अपलोड करने की कोशिश करता है। क्लाउड वर्शन स्टैंप (etag या वर्शन आईडी) देखता है और कहता है: "तुम्हारा आधार पुराना था। किसी ने पहले ही नया वर्शन सेव कर दिया।"
प्रोडक्ट को क्या करना चाहिए?
बुरा विचार: चुपचाप सिर्फ़ आखिरी अपलोड रखो। फ़ोन ए वाले बिना चेतावनी "दूध खरीदना" खो देते हैं। यह डेटा खोने जैसा लगता है।
साधारण फ़ाइलों के लिए अच्छा विचार: दोनों रखो। पहला लेखक मुख्य फ़ाइल जीतता है। दूसरे लेखक के बाइट्स notes (फ़ोन बी से संघर्ष).txt जैसी चीज़ में बचें, या ऐप साफ़ संघर्ष स्क्रीन दिखाए ताकि इंसान चुने या हाथ से मर्ज करे।
शुद्ध टेक्स्ट के लिए सावधानी भरे टूल से ऑटो मर्ज आसान हो सकता है। बेतरतीब .xlsx या फ़ोटो के लिए मुफ़्त नहीं। सामान्य ड्राइव के लिए संघर्ष कॉपी प्लस उपयोगकर्ता का चुनाव ईमानदार है। लाइव मल्टी-कर्सर सह-संपादन वह दूसरा प्रोडक्ट है जिसे हमने दायरे से बाहर छोड़ा।
दो लोग ऑनलाइन एडिट करें तो भी वही विचार: सर्वर कमिट को क्रम में लेता है। पहला सफल सेव मुख्य पॉइंटर जीतता है। हारे को सुलझाने को कहा जाता है।
सिस्टम का सादा चित्र
पचास बक्सों की ज़रूरत नहीं। कुछ भूमिकाएँ काफी हैं:
तुम्हारे डिवाइस (वेब, डेस्कटॉप, फ़ोन)
|
लोड बैलेंसर
|
एपीआई सर्वर ---- "तुम कौन हो? फ़ोल्डर पेड़ क्या है? कौन एडिट कर सकता है?"
|
मेटाडेटा डेटाबेस (नाम, वर्शन, शेयर, बदलाव इतिहास)
|
ब्लॉक / चंक पथ ---- ऑब्जेक्ट स्टोरेज गोदाम (असली फ़ाइल के टुकड़े)
|
नोटिफिकेशन पथ (डिवाइस जगाओ: "कुछ बदला")
- एपीआई सर्वर लॉगिन, फ़ोल्डर सूची, अपलोड शुरू करना, शेयर, और "क्या यह अपलोड पूरा?" संभालते हैं।
- ऑब्जेक्ट स्टोरेज टिकाऊ चंक रखता है। बाइट्स को कई मशीनों और जगहों पर सुरक्षित रखने के लिए बना है।
- मेटाडेटा डेटाबेस नाम, पैरेंट, वर्तमान वर्शन और ACL की सच्चाई रखता है। इस हिस्से को मज़बूत सहमति चाहिए: दो डिवाइस "नवीनतम क्या है" पर असहमत न हों।
- नोटिफिकेशन (लॉन्ग पोल, पुश या ऐसा ही) सोए क्लाइंट जगाते हैं ताकि वे हर सेकंड "सब कुछ लिस्ट करो" न पीटें।
दिन एक का खिलौना संस्करण एक ऐप सर्वर और डिस्क फ़ोल्डर हो सकता है। डिस्क भर जाए, बॉक्स मर जाए, या तीन डिवाइस को भरोसेमंद बदलाव फैन-आउट चाहिए तो वह मर जाता है। ऊपर का चित्र वही परिपक्व आकार है जो इंटरव्यू में अपेक्षा होती है।
अपलोड फ़्लो, शुरू से अंत तक (एक बार फिर, धीरे)
१. क्लाइंट अपलोड सेशन बनाता है (नाम, पैरेंट फ़ोल्डर, आकार)। २. सर्वर लंबित प्रविष्टि लिखता है और बताता है चंक कैसे भेजें। ३. क्लाइंट चंक अपलोड करता है। सर्वर उन्हें गोदाम में रखता है। ४. जब सब चंक आ जाएँ और चेकसम मिलें, सर्वर नई वर्शन रेसिपी लिखता है और फ़ाइल पॉइंटर उसी ओर घुमाता है। ५. सर्वर बदलाव इवेंट प्रकाशित करता है। ६. दूसरे डिवाइस जागते हैं, नई रेसिपी लाते हैं, सिर्फ़ गायब चंक डाउनलोड करते हैं, स्थानीय फ़ाइल अपडेट करते हैं।
अगर चरण ४ चंक उतरने के बाद फेल हो, बाद में सफ़ाई जॉब बेकार चंक हटाती है। मुख्य पॉइंटर कभी आधा अपडेट मत छोड़ो।
"अच्छा" कैसा दिखता है
| लक्ष्य | सादा मतलब |
|---|---|
| टिकाऊपन | उपयोगकर्ता फ़ाइलें मशीन फेल होने पर भी बचें |
| मज़बूत मेटाडेटा | सब नवीनतम नाम और वर्शन पर सहमत |
| सस्ता सिंक | सिर्फ़ बदले चंक नेटवर्क पार करें |
| निष्पक्ष शेयर | हर संवेदनशील काम पर अनुमति जाँच |
| ईमानदार संघर्ष | दो एडिट मिलें तो चुपचाप ओवरराइट नहीं |
अगर पूछा जाए तो मोटे इंटरव्यू आंकड़े: करोड़ों दैनिक उपयोगकर्ता, प्रति व्यक्ति गीगाबाइट में मुफ़्त कोटा, सिस्टम-व्यापी औसत सैकड़ों अपलोड प्रति सेकंड, और इतना स्टोरेज अधिकार जितना एक एसक्यूएल डेटाबेस कभी कच्चे फ़ाइल शरीर के रूप में न रखे। ब्लॉब ऑब्जेक्ट स्टोरेज में रहते हैं। डेटाबेस उन ब्लॉब के बारे में छोटी सच्चाइयाँ रखते हैं।
दोस्त के लिए संक्षेप
कैफ़े में साठ सेकंड हों तो:
गूगल ड्राइव एक जादुई फ़ोल्डर है जो हर डिवाइस पर रहता लगता है। असल में हर डिवाइस एक कॉपी रखता है, और क्लाउड सिस्टम सच्चाई का स्रोत है। अपलोड फ़ाइल ऊपर भेजता है (बड़ी हो तो टुकड़ों में, नेटवर्क मरे तो फिर से शुरू करके)। डाउनलोड उसे वापस लाता है, अक्सर फ़ाइल गोदाम की ओर छोटे विशेष लिंक से। सिंक वह लूप है जो दूसरे डिवाइसों से कहता है "कुछ बदला" और आखिरी देखे बदलावों के बुकमार्क से उन्हें पकड़ने देता है। चंक फ़ाइलों को छाप वाले टुकड़ों में तोड़ते हैं ताकि छोटी एडिट पूरी फ़ाइल न भेजे, और इतिहास बिना बदले टुकड़े दोबारा इस्तेमाल करे। वर्शन "सेव के समय फ़ाइल कैसी थी" की सिर्फ़-जोड़ने वाली रेसिपी हैं। शेयर हर खोलने पर जाँची जाने वाली अनुमति सूची है। जब दो फ़ोन ऑफलाइन एडिट करें, दोनों एडिट मायने रखती हैं: सर्वर तक पहली पहुँची मुख्य फ़ाइल बनती है, दूसरी संघर्ष कॉपी या इंसान के लिए साफ़ चुनाव बने, चुपचाप नुकसान कभी नहीं।
बाइट्स बचाओ। नवीनतम पर सहमत रहो। सिर्फ़ बदला हुआ भेजो। दो एडिट टकराएँ तो सच बोलो।
यही डिज़ाइन है।