टीएल;डीआर

  • समस्या: बड़े पैमाने की वास्तुकला (आर्किटेक्चर) तैयार करने के लिए उपलब्धता, थ्रूपुट और परिचालन जटिलता के बीच संतुलन बनाना आवश्यक है।
  • मुख्य निष्कर्ष: शुरुआती लोगों के लिए वीडियो स्ट्रीमिंग का नक्शा: फिल्मकार एक मास्टर टेप छोड़ता है, प्लेटफ़ॉर्म कई क्वालिटी की कॉपियाँ बनाता है, दर्शकों के पास रखता है, और सीडीएन से चलाता है। सिर्फ ओरिजिनल क्यों काफी नहीं, और लागत का सहज अंदाज़ साधारण भाषा में।
  • परिणाम: उत्पादन वातावरण में विफलता से निपटने और प्रदर्शन लक्ष्यों को हासिल करने की सटीक रूपरेखा।

आप ऐप खोलते हैं, वीडियो पर टैप करते हैं, और वह चल पड़ता है। जादू लगता है। अंदर से यह पुराने फिल्म स्टूडियो जैसा है, बस गोदाम आधुनिक हैं।

यह चित्र सोचें। एक फिल्मकार फिल्म खत्म करके स्टूडियो के दरवाजे पर एक मास्टर टेप छोड़ देता है। स्टूडियो वह एक टेप हर घर नहीं भेजता। वह कई क्वालिटी में कई कॉपियाँ बनाता है, उन्हें दर्शकों के पास स्थानीय दुकानों में भेजता है, और जब कोई प्ले दबाता है तो पास की दुकान फिल्म के अगले कुछ मिनट सौंप देती है। पूरी प्रॉडक्ट एक कहानी में: अपलोड, कन्वर्ट, दर्शकों के पास स्टोर, प्ले।

यह पोस्ट वही रास्ता साधारण शब्दों में चलाती है। पहले क्लाउड वेंडर के नाम जानना ज़रूरी नहीं। अगर टेप की कहानी समझ आ गई, तो यूट्यूब-जैसा डिज़ाइन भी समझ आएगा।

बड़ी बात चार कदमों में

कदम साधारण मतलब फिल्म-स्टूडियो उपमा
अपलोड क्रिएटर बड़ा ओरिजिनल फ़ाइल प्लेटफ़ॉर्म को भेजता है फिल्मकार मास्टर टेप छोड़ता है
कन्वर्ट (ट्रांसकोड) मशीनें उस फ़ाइल को कई साइज़ और क्वालिटी में दोबारा लिखती हैं स्टूडियो कई रील बनाता है: साफ़ सिनेमा, छोटा फ़ोन, कमज़ोर नेट
स्टोर मास्टर और सभी कॉपियाँ सुरक्षित रखना मास्टर के लिए वॉल्ट, हर क्वालिटी के लिए शेल्फ
प्ले सीडीएन से दर्शक के पास के सर्वर से छोटे टुकड़े भेजना हर शहर की स्थानीय दुकान, न कि समुद्र पार एक ही गोदाम

सीडीएन (कंटेंट डिलीवरी नेटवर्क) इंटरनेट फ़ाइलों के लिए स्थानीय दुकानों का जाल है। दर्शक पास की दुकान से वीडियो लेते हैं ताकि प्ले जल्दी शुरू हो और मुख्य गोदाम हर रिक्वेस्ट से न टूटे।

कदम १: अपलोड (मास्टर छोड़ना)

जब कोई वीडियो अपलोड करता है, प्लेटफ़ॉर्म को पूरा फ़ाइल अपने मुख्य ऐप सर्वरों से नहीं धकेलना चाहिए। यह ऐसा है जैसे हर डिलीवरी ट्रक को फ्रंट ऑफिस से निकालें। ऑफिस जाम हो जाएगा।

बेहतर तरीका:

१. ऐप प्लेटफ़ॉर्म से पूछता है: "मैं वीडियो अपलोड करना चाहता हूँ। टाइटल और साइज़ यह है।" २. प्लेटफ़ॉर्म रिकॉर्ड बनाता है: "यह वीडियो है, स्टेटस अपलोडिंग।" ३. प्लेटफ़ॉर्म क्रिएटर को बड़े फ़ाइल गोदाम के लिए कम समय वाला अपलोड टिकट (अस्थायी लिंक) देता है। ४. फ़ोन या ब्राउज़र फ़ाइल सीधे उसी गोदाम को भेजता है। ५. अपलोड पूरा होने पर प्लेटफ़ॉर्म वीडियो को प्रोसेसिंग कहता है और कन्वर्शन शुरू करता है।

टिकट क्यों? ताकि भारी फ़ाइल उन छोटी "ऐप" मशीनों से न गुज़रे जिन्हें सिर्फ टाइटल, लॉगिन और स्टेटस संभालना है।

बड़ी फ़ाइलें अक्सर टुकड़ों में जाती हैं। अगर नेटवर्क ८०% पर टूट जाए, क्लाइंट सिर्फ गायब टुकड़े दोबारा भेजता है, पूरा शुरू नहीं करता। किताब अध्याय-अध्याय भेजने जैसा।

बाइट्स गिरते समय क्रिएटर टाइटल या विवरण बदल सकता है। लेकिन वीडियो "देखने लायक" तब तक नहीं जब तक कम से कम एक प्ले करने लायक कॉपी न बन जाए।

कदम २: कन्वर्ट (कई क्वालिटी बनाना)

यहाँ कन्वर्ट का मतलब ट्रांसकोड है: ओरिजिनल लेकर ऐसे फ़ॉर्मैट और बिटरेट में लिखना जो फ़ोन, टीवी और ब्राउज़र आसानी से चला सकें।

सिर्फ ओरिजिनल फ़ाइल क्यों नहीं स्ट्रीम करें?

शुरुआती को यही सवाल पूछना चाहिए, और जवाब डिज़ाइन का दिल है।

१. साइज़। फ़ोन की कच्ची रिकॉर्डिंग बहुत बड़ी हो सकती है। अकेले उसी मोटे फ़ाइल को स्ट्रीम करने से डेटा प्लान जलता है और धीमे नेट पर बफर कभी खत्म नहीं होता। २. डिवाइस अलग होते हैं। कमज़ोर ४जी पर मेट्रो का फ़ोन और फ़ाइबर पर लिविंग रूम टीवी को अलग "रील" चाहिए। एक मास्टर दोनों पर अच्छा नहीं बैठता। ३. प्ले के बीच नेट बदलता है। सिग्नल खराब होने पर प्लेयर छोटी कॉपी पर उतर सके, सुधरने पर फिर चढ़ सके। इसके लिए पहले से तैयार क्वालिटी की सीढ़ी चाहिए। ४. संगतता। फ़ोन, ब्राउज़र, टीवी एक ही वीडियो "भाषा" नहीं बोलते। कन्वर्शन हर क्लाइंट की समझ आने वाली संस्करण बनाती है।

इसलिए स्टूडियो हर घर को अकेला मास्टर टेप नहीं भेजता। वह बहुत सी कॉपियाँ तैयार करता है: खराब नेट के लिए मोटा ३६०p, सामान्य ७२०p, मज़बूत लिंक के लिए १०८०p या ऊपर, साथ में ऑडियो ट्रैक और छोटी प्लेलिस्ट (मैनिफेस्ट) जो उन विकल्पों की सूची रखती है।

प्लेयर प्लेलिस्ट पढ़ता है, शुरू की क्वालिटी चुनता है, और छोटे सेगमेंट (हर एक कुछ सेकंड) माँगता है। यह "पूरी फिल्म डाउनलोड करो, फिर चलाओ" नहीं है। यह "अगले कुछ सेगमेंट हाथ में रखो" है।

वीडियो को रेडी तब कह सकते हैं जब कम से कम उपयोगी सीढ़ी मौजूद हो (जैसे मध्यम क्वालिटी और ऑडियो)। ऊँची क्वालिटी बाद में पूरी होकर प्लेलिस्ट में जुड़ सकती है।

कदम ३: स्टोर (वॉल्ट और शेल्फ)

कन्वर्शन के बाद रखते हैं:

  • ओरिजिनल (मास्टर)। बाद में दोबारा कन्वर्ट, पाइपलाइन की गलती ठीक करने, या नई क्वालिटी जोड़ने के काम आता है।
  • कन्वर्ट की हुई कॉपियाँ (हर क्वालिटी के सेगमेंट और प्लेलिस्ट)।
  • छोटी चीज़ें: थंबनेल, शायद छोटा प्रीव्यू।

बाइट्स ऑब्जेक्ट स्टोरेज में रहते हैं (फ़ाइलों का विशाल गोदाम)। छोटे तथ्य डेटाबेस में: टाइटल, मालिक, अवधि, स्टेटस (uploading → processing → ready या failed), और प्लेलिस्ट कहाँ है।

स्टेटस ज़रूरी है। क्लाइंट अपलोड कॉल पर कन्वर्शन खत्म होने तक अटके नहीं रहने चाहिए। कन्वर्शन मिनटों ले सकती है। ऐप पूछता है या पुश पाता है: "अभी प्रोसेसिंग" फिर "रेडी।"

कदम ४: प्ले (दर्शक के पास स्थानीय दुकान)

जब दर्शक प्ले दबाता है:

१. ऐप एपीआई से मेटाडेटा लाता है (टाइटल, थंबनेल, रेडी है या नहीं)। २. प्लेयर प्लेलिस्ट यूआरएल खोलता है, अक्सर सीडीएन से। ३. प्लेयर पास के सीडीएन एज से सेगमेंट माँगता है। ४. अगर उस एज के पास सेगमेंट अभी नहीं है, वह एक बार मुख्य गोदाम से लाता है, फिर पास के अगले दर्शक के लिए कॉपी रख लेता है।

डिज़ाइन नियम: एपीआई के पास टिकट, स्टेट और नीति है। सीडीएन के पास प्ले का खुश रास्ता (बाइट्स) है। ऐप सर्वर हर फ़ोन को मल्टी-गीगाबाइट फ़ाइल नहीं भेजने चाहिए।

सेगमेंट के बीच क्वालिटी बदल सकती है। यही अडैप्टिव स्ट्रीमिंग है (इंटरव्यू में HLS और DASH सुनेंगे; दोनों "प्लेलिस्ट प्लस सेगमेंट" हैं)। RFC याद रखने की ज़रूरत नहीं। तस्वीर याद रखें: कॉपियों की सीढ़ी, छोटे टुकड़े, नेट बदलते ही स्विच।

लागत का सहज अंदाज़ (डरावने अंकों से पहले)

एक पल प्रॉडक्ट नाम भूल जाएँ। स्टूडियो मैनेजर की तरह सोचें।

वीडियो में पैसा कहाँ जाता है

१. दर्शकों तक बाइट्स पहुँचाना अक्सर सबसे महँगा होता है। हर प्ले आपके गोदाम से लोगों की ओर डेटा है। हिट वीडियो लाखों बार चलता है; हर प्ले पास की दुकान से एक और सफ़र है (या ठंडे मुख्य गोदाम से खींचना)। २. कॉपियाँ रखना एक ओरिजिनल रखने से ज़्यादा महँगा है। क्वालिटी की सीढ़ी जगह बढ़ाती है। आप शेल्फ का बिल भरते हैं, सिर्फ मास्टर वॉल्ट का नहीं। ३. कन्वर्शन सीपीयू समय खाती है। अपलोड बढ़े तो एनकोड फार्म मेहनत करते हैं। यह बिल असली है, लेकिन बड़े पैमाने पर प्लेबैक ट्रैफ़िक अक्सर हावी रहता है। ४. ऐप सर्वर (टाइटल और लॉगिन) आमतौर पर सस्ता हिस्सा हैं। ऐसा डिज़ाइन न करें जैसे वीडियो प्रॉडक्ट का मुख्य खर्च डेटाबेस हो।

"दर्शकों के पास रखना" पैसे और दर्द क्यों बचाता है

अगर पूरी दुनिया एक केंद्रीय गोदाम से खींचे:

  • दूर के दर्शक ज़्यादा इंतज़ार करते हैं।
  • केंद्रीय लिंक जाम हो जाता है।
  • वही लोकप्रिय फिल्म समुद्र पार बार-बार भेजने का बिल लगता है।

स्थानीय सीडीएन एज गर्म वीडियो दर्शकों के पास रखते हैं। ज़्यादातर प्ले पास की कॉपी पर लगते हैं। ठंडे, कम देखे वीडियो दूर रह सकते हैं। लोकप्रियता लंबी पूँछ है: कुछ वीडियो ज़्यादातर ट्रैफ़िक उठाते हैं; ज़्यादातर वीडियो मुश्किल से चलते हैं। समझदार प्लेटफ़ॉर्म एज की जगह उसी पर खर्च करते हैं जिसे लोग सच में देखते हैं।

सरल मानसिक हिसाब (मोटा अंदाज़, कोट नहीं)

मान लें लाखों लोग रोज़ कुछ वीडियो देखते हैं, और हर पूरा स्ट्रीम कुछ सौ मेगाबाइट है। लोग × वीडियो × साइज़ करें तो पेटाबाइट ट्रांसफर निकलता है। आउटबाउंड डेटा पर प्रति गीगाबाइट कुछ पैसे भी रोज़ का बड़ा बिल बना देते हैं। इसलिए इंटरव्यू में "सीडीएन लागत" बार-बार आता है, और इसलिए कन्वर्शन (छोटी फ़ाइलें, बेहतर कोडेक) और दर्शकों के पास कैश अपलोड फ़ॉर्म चमकाने से ज़्यादा मायने रखते हैं।

सटीक प्राइस शीट ज़रूरी नहीं। पंचलाइन ज़रूरी है: वीडियो में डिलीवरी और स्टोरेज अक्सर ऐप लेयर की लागत से आगे निकल जाते हैं।

पूरे रास्ते की एक तस्वीर

क्रिएटर का फ़ोन/ब्राउज़र
    |  १. अपलोड टिकट माँगना
    v
API (मेटाडेटा, ऑथ, स्टेटस)
    |  २. टिकट
    v
फ़ाइल गोदाम  <--- ३. बड़ा ओरिजिनल यहाँ उतरता है
    |
    v
कन्वर्ट वर्कर्स (कतार)  ---> कई क्वालिटी + प्लेलिस्ट + थंब
    |
    v
गोदाम की शेल्फ + CDN स्थानीय दुकानें
    |
    v
दर्शक का प्लेयर  <--- सबसे पास की दुकान से सेगमेंट

तीन प्लेन, हर एक एक वाक्य:

  • एपीआई प्लेन: कौन अपलोड कर सकता है, टाइटल क्या है, वीडियो रेडी है या नहीं।
  • बाइट प्लेन: गोदाम में ओरिजिनल और कन्वर्ट ऑब्जेक्ट।
  • एज प्लेन: देखने के लिए लोगों के पास सीडीएन कॉपियाँ।

सुरक्षा एक साँस में

  • अपलोड टिकट खत्म हो जाते हैं और सिर्फ एक ऑब्जेक्ट की ओर इशारा करते हैं।
  • प्राइवेट वीडियो को हमेशा के लिए पब्लिक यूआरएल नहीं, कम समय वाले प्लेबैक लिंक चाहिए।
  • गलत या ब्लॉक कंटेंट स्टेटस को टेकन-डाउन पर ला सकता है; प्लेलिस्ट और सेगमेंट देना बंद करें।
  • लाइव स्ट्रीमिंग चचेरा भाई है (वही परिवार: इनजेस्ट, पैकेज, सीडीएन) लेकिन समय ज़्यादा कसा हुआ। यह पोस्ट तैयार वीडियो (ऑन डिमांड) पर है, लाइव कॉन्सर्ट पर नहीं।

दोस्त को बताने वाला सार

यूट्यूब-जैसी स्ट्रीमिंग "एक फ़ाइल सर्वर पर रखो और उम्मीद करो" नहीं है।

क्रिएटर अस्थायी टिकट से मास्टर अपलोड करता है, फ्रंट ऑफिस से नहीं। मशीनें उस मास्टर को कई क्वालिटी में कन्वर्ट करती हैं ताकि किसी भी नेट पर फ़ोन और टीवी बिना पिघले चल सकें। प्लेटफ़ॉर्म मास्टर और कॉपियाँ स्टोर करता है, और छोटे डेटाबेस में स्टेटस रखता है। जब कोई प्ले दबाता है, पास का सीडीएन क्वालिटी की सीढ़ी से छोटे सेगमेंट देता है, नेट बदलते ही स्विच करता है।

सिर्फ ओरिजिनल इसलिए नहीं चलाते क्योंकि वह बहुत बड़ा, बहुत सख्त, और कमज़ोर नेट के लिए बहुत बेदर्द है। लागत दर्शकों के पीछे चलती है: बाइट्स की डिलीवरी और कॉपियों से भरी शेल्फ आमतौर पर उन सर्वरों से ज़्यादा मायने रखती हैं जो टाइटल रखते हैं। डिज़ाइन ऐसा हो कि भारी फ़ाइल ऐप लेयर से बचे, कन्वर्शन असिंक हो, और प्ले का खुश रास्ता एज पर रहे।

एक पंक्ति याद रखें: फिल्मकार एक टेप छोड़ता है; स्टूडियो कई रील बनाता है और उन्हें दर्शकों के पास रखता है।