🧒🏼 🤟🏻 👩🏻‍🍳 हाईलोअड ++, मिखाइल रायचेंको (मानवेच): लगभग जादू के बिना, या टरबेट वीडियो स्ट्रीम वितरित करना कितना आसान है ☔️ 🚢 🏇🏾

अगला हाईलोअड ++ सम्मेलन 6 और 7 अप्रैल, 2020 को सेंट पीटर्सबर्ग में आयोजित किया जाएगा। विवरण और टिकट यहां । हाईलाड ++ मॉस्को 2018. हॉल "दिल्ली + कलकत्ता"। 8 नवंबर, दोपहर 2 बजे। सार और प्रस्तुति ।

मैं VKontakte टीम में काम करता हूं और एक वीडियो प्रसारण प्रणाली विकसित कर रहा हूं।
रिपोर्ट में, मैं बैकएंड के विकास की विशेषताएं साझा करूंगा कि हमारी प्रणाली कैसे विकसित हुई है, और तकनीकी समाधान जो हम आए हैं: 

हमने वीडियो को बैकएंड और प्रसारण प्रक्रिया को कैसे प्रसारित किया;
वास्तुकला पर व्यापार और परिचालन आवश्यकताओं का प्रभाव;
"रुको" और "फिर से प्रयास करें" विफल हो जाएगा;
उपयोगकर्ताओं की संख्या से सरल कार्य कैसे जटिल होते हैं;
यूडीपी के बिना विलंबता कैसे कम करें;
हम दिन में 2 बार तनाव परीक्षण करते हैं, या क्लोवर ने हमारी मदद की।

मिखाइल रायचेंको (इसके बाद - MR): - थोड़ा सा भ्रमण। मैं आपको उन लोगों के बारे में बताऊंगा जो हमें स्ट्रीम करते हैं, लाइव (लाइव) के बारे में, जिसके बारे में हम वीडियो स्ट्रीम प्राप्त करते हैं और जिसे हम वितरित करते हैं। अंत में, मैं लाइव की वर्तमान वास्तुकला के बारे में बात करूंगा, इसकी सीमाओं और क्षमताओं के बारे में, साथ ही साथ वर्तमान वास्तुकला "क्लोवर" जैसे प्रभाव से कैसे बची।

लाइव प्रसारण के बारे में। रिपोर्ट की रूपरेखा

सबसे पहले, मैं लाइव प्रसारण के बारे में थोड़ी बात करता हूं और खुद को स्ट्रीम करता हूं, हमें वीडियो सामग्री भेजता है जिसे हम अन्य दर्शकों को दिखाते हैं।
. ? , , , , - - , - , . , : , – .
. , . . , , .
, , . , . , , , , , 2014-2015 . , .
. , .
, . , . , .
, . .
, , «», .

सभी प्रसारण सेवाएं कुछ इस तरह दिखती हैं:

हमारे पास कुछ स्ट्रीमर हैं, यह हमारे लिए एक आरटीएमपी स्ट्रीम भेजता है, और हम दर्शकों को दिखाते हैं - कुछ भी आश्चर्य की बात नहीं है, कुछ भी अलौकिक नहीं है।

वीडियो स्ट्रीम कहां से आती है? हमारे लिए यातायात का एक महत्वपूर्ण स्रोत हमारा मोबाइल एप्लिकेशन VKlife है। उसके बारे में क्या अच्छा है? इसमें, हम पूरी तरह से नियंत्रित कर सकते हैं कि हम वीडियो को कैसे एन्कोड करते हैं। हम ग्राहक पक्ष पर कई अनुकूलन कर सकते हैं, ताकि बाद में, न्यूनतम देरी के साथ, इसे हमारे दर्शकों को दिखाएं।

Minuses की: मोबाइल एप्लिकेशन नेटवर्क के शीर्ष पर काम करते हैं। यह 3 जी हो सकता है ... किसी भी मामले में, यह लगभग हमेशा मोबाइल नेटवर्क है, जो कुछ अंतराल का परिचय देता है - आपको इसके अतिरिक्त डेटा को एप्लिकेशन साइड पर बफर करने की आवश्यकता होती है, ताकि स्ट्रीम यथासंभव आसानी से चल सके।

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

तीसरी श्रेणी मीडिया सर्वर से RTMP स्ट्रीम है। ये बहुत छोटे मीडिया सर्वर हो सकते हैं, अर्थात्, एक घर का प्रारूप: एक व्यक्ति सड़क या कुछ और का दृश्य देखता है। या हमारे भागीदारों से काफी गंभीर प्रसारण: कुछ भी हो सकता है, ऐसी बहुत सारी धाराएँ नहीं हैं, लेकिन मूल रूप से वे हमारे लिए बहुत महत्वपूर्ण हैं।

कौन देख रहा है?

फिर, यह एक मोबाइल एप्लिकेशन है - यहां सब कुछ स्पष्ट है। सबसे बड़ी समस्या नेटवर्क लेटेंसी है। पेशेवरों से: हम खिलाड़ी को अनुकूलित कर सकते हैं - यह हमारे लिए सुविधाजनक है, अच्छा है, लेकिन हर जगह यह 100% नहीं है।

Vk.com पर वेब प्लेयर। यहां भी, सब कुछ सरल है - यह एक नियमित वेब प्लेयर है जिसे आप देखने के लिए खोल सकते हैं। Vk.com पर पर्याप्त रूप से बड़े दर्शक, प्रसारण पर बहुत सारे दर्शक। कुछ प्रसारण हमारे "वीडियो" अनुभाग में लटकाए जाते हैं - वहाँ हजारों (कभी-कभी बिना किसी पीआर) के हो सकते हैं, खासकर अगर यह दिलचस्प सामग्री है।

तदनुसार, चैनल दर्शकों के लिए काफी बड़े हैं जो एक वेब प्लेयर पर बैठे हैं। इसलिए, एक प्रसारण के लिए बहुत से ट्रैफ़िक शामिल हैं।

तीसरा किसी तीसरे पक्ष की साइट पर VKontakte वेब प्लेयर है। आप अपनी इच्छानुसार सब कुछ स्ट्रीमिंग शुरू कर सकते हैं, और अपनी वेबसाइट पर VKontakte वेब प्लेयर लटका सकते हैं। आप हमारे साथी बन सकते हैं यदि आपके पास दिलचस्प सामग्री है: आप इसे अपने दम पर लटका सकते हैं, आप हमारे साथ लटका सकते हैं - जैसा आप चाहें। आप अपने प्रसारण को इस तरह से व्यवस्थित कर सकते हैं, और सब कुछ काम करेगा।

वीडियो कॉल के साथ तुलना

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

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

साधारण वीडियो के साथ, स्थिति बिल्कुल विपरीत है। हमें बहुत अच्छी गुणवत्ता चाहिए। इसी समय, वीडियो आकार, बिटरेट और गुणवत्ता के अनुपात को कम करना वांछनीय है, ताकि न्यूनतम प्रवाह के साथ, सबसे अच्छा समाधान दें। पेशेवरों से: हम समय में सीमित नहीं हैं: वीडियो डाउनलोड करने के समय, हमारे पास वीडियो को अनुकूलित करने के लिए पर्याप्त समय है, देखें कि इसे सबसे अच्छे तरीके से कैसे संपीड़ित करें, कुछ करें, इसे कैश में खींचें, यदि आवश्यक हो - सामान्य तौर पर, सब कुछ पर्याप्त है ठीक।

लाइव में, स्थिति फिर से, विपरीत है: हमारे पास ट्रांसकोडिंग के लिए बहुत कम समय है। इसी समय, कुछ अवसर हैं, लेकिन प्रसारण के लिए कोई उम्मीद नहीं है। यदि हमारे पास समर्थन है या गुणवत्ता बहुत अच्छी नहीं है तो दर्शक हमें क्षमा करेंगे।

बहुत पहले संस्करण

यह काफी अपेक्षित है:

वास्तव में, यह थोड़ा अलग है:

"स्ट्रीमर - मीडिया सर्वर - कैश स्तर - दर्शक"। सिद्धांत रूप में, यह संस्करण आपको काफी दृढ़ता से स्केल करने की अनुमति देता है। मैं कहूंगा कि इसे पहले से ही हजारों दर्शकों को झेलना चाहिए। इसकी अन्य कमियां हैं ...

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

अवसंरचना आवश्यकताओं

क्या महत्वपूर्ण है?

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

प्रसारण बुनियादी ढांचा अब कैसा दिखता है?

नतीजतन, हम एक बहुत ही सरल लेकिन प्रभावी बुनियादी ढांचे में आए ...

– , ( , ). RTMP-, . , .
, , , , . . , , , – : , -, (. . ); -, .
. – , . , , . , ( , ).
, (edge-). , . !
– edge-, , . : , – .

दिलचस्प बात यह है? संतुलन! इस योजना में, हम संतुलन चुनते हैं, उन दर्शकों को भेजने की कोशिश करते हैं जो प्रत्येक धार सर्वर पर एक ही स्ट्रीम देखते हैं। कैश स्थानीयता यहां बहुत महत्वपूर्ण है, क्योंकि कई किनारे सर्वर हो सकते हैं; और यदि हम धारा के दृष्टिकोण से कैश के अस्थायी और इलाके दोनों का निरीक्षण नहीं करते हैं, तो हम आंतरिक परत को अधिभारित करेंगे। हम ऐसा नहीं चाहेंगे।

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

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

एज सर्वर की एक अन्य महत्वपूर्ण भूमिका सामग्री सुरक्षा है। सभी सामग्री सुरक्षा अनिवार्य रूप से वहां होती है। हमारे पास इसके लिए अपना खुद का नगनेक्स मॉड्यूल है। यह कुछ हद तक Security Link के समान है।

स्केलिंग और संतुलन

. , : , . edge-, . . . … , – , -- – , – , , , – ! – .
. , , , , : . ( ) , – , . , , , edge-.
, , , .

?

हमारे पास मुख्य प्रोटोकॉल में से एक RTMP था (न केवल इनपुट के लिए, बल्कि सामग्री वितरण के लिए भी)। मुख्य लाभ कम विलंबता है। यह आधा सेकंड, दूसरा, दो सेकंड हो सकता है। वास्तव में, लाभ वहां समाप्त हो जाते हैं ...

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

वह अच्छा कैसे है? यह थोड़ा पुराना होने के बावजूद बहुत सरल है। यह आपको CDN का उपयोग करने की अनुमति देता है, अर्थात, आपको HLS प्रोटोकॉल को वितरित करने के लिए केवल nginx की आवश्यकता है। यह निगरानी के संदर्भ में समझ में आता है।

यहाँ इसके फायदे हैं:

ऑपरेशन में आसानी - nginx एक प्रॉक्सी सर्वर के रूप में;
मेट्रिक्स की निगरानी करना और उसे ले जाना आसान है (यह आपके लिए अपनी वेबसाइट पर निगरानी रखने के लिए पर्याप्त है);
अब यह प्रोटोकॉल सामग्री वितरण के लिए मुख्य है।

महत्वपूर्ण ऋण:

उच्च विलंबता।

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

दूसरा बिंदु जो एचएलएस में देरी देता है, कैशिंग है। प्लेलिस्ट आंतरिक परत और किनारे के सर्वर पर कैश्ड है। यहां तक कि अगर हम कैश करते हैं, तो अपेक्षाकृत, दूसरे या आधे सेकंड के लिए बोलते हैं, तो यह लगभग 2-3 सेकंड की देरी है। कुल में, यह 12 से 18 सेकंड तक निकलता है - यह बहुत सुखद नहीं है, जाहिर है कि यह बेहतर है।

एचएलएस में सुधार

इन विचारों के साथ, हमने एचएलएस में सुधार करना शुरू किया। हमने इसे एक सरल तरीके से बेहतर बनाया: चलो अंतिम, अभी तक प्लेलिस्ट के मीडिया सेगमेंट को थोड़ा पहले दर्ज नहीं किया है। यही है, जैसे ही हमने अंतिम मीडिया खंड लिखना शुरू किया, हम तुरंत प्लेलिस्ट में इसकी घोषणा करते हैं। इस समय क्या हो रहा है? ..

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

दूसरा बिंदु: हम लगभग 5-8 सेकंड जीतते हैं। वे कहां से आते हैं? यह सेगमेंट का समय प्रति सेगमेंट 2 से 4 सेकंड है, साथ ही प्लेलिस्ट को कैश करने का समय (यह दूसरा 2-3 सेकंड है)। हमारी देरी कम हो रही है, इसके अलावा, काफी है। देरी को 12-15 सेकंड से घटाकर 5-7 किया जाता है।

इस दृष्टिकोण में और क्या अच्छा है? यह वास्तव में स्वतंत्र है! हमें केवल यह जांचने की आवश्यकता है कि खिलाड़ी इस दृष्टिकोण के अनुकूल हैं या नहीं। जो असंगत हैं, हम पुराने URL को भेजते हैं, और हम संगत खिलाड़ियों को नए URL में भेजते हैं। हमें पुराने ग्राहकों को अपग्रेड करने की आवश्यकता नहीं है जो इसका समर्थन करते हैं, जो महत्वपूर्ण भी है। हमें वास्तव में मोबाइल क्लाइंट में खिलाड़ियों को संशोधित करने, रिलीज करने की आवश्यकता नहीं है। हमें एक वेब प्लेयर विकसित करने की आवश्यकता नहीं है। यह काफी अच्छा लग रहा है!

Minuses की - आने वाली वीडियो स्ट्रीम को नियंत्रित करने की आवश्यकता। मोबाइल क्लाइंट के मामले में, हम इसे काफी आसानी से कर सकते हैं (जब स्ट्रीम मोबाइल क्लाइंट से आती है), या बिना ट्रांसकोड विफल, क्योंकि खिलाड़ी को पता होना चाहिए कि एक मीडिया सेगमेंट में कितना समय लगता है। और चूंकि हम इसे वास्तव में रिकॉर्ड करने से पहले इसकी घोषणा कर रहे हैं, इसलिए हमें यह जानना होगा कि इसे रिकॉर्ड करने में कितना समय लगेगा।

गुणवत्ता मैट्रिक्स

इस प्रकार, हमने एचएलएस में सुधार किया है। अब मैं बताना चाहता हूं कि हम कैसे निगरानी करते हैं और हम किस गुणवत्ता के मैट्रिक्स को शूट करते हैं:

मुख्य गुणवत्ता मीट्रिक में से एक प्रारंभ समय है। आदर्श रूप से, यह तब होता है जब आप प्रसारण से पहले मोबाइल क्लाइंट के माध्यम से स्क्रॉल करते हैं, बटन दबाते हैं, और यह तुरंत शुरू होता है। यदि आप बटन दबाने से पहले शुरू करते हैं, तो यह आदर्श होगा, लेकिन, दुर्भाग्यवश, जब आप दबाते हैं।
दूसरा बिंदु सिग्नल देरी है। हम मानते हैं कि कुछ सेकंड बहुत अच्छा है, 10 सेकंड सहन करने योग्य है, 20-30 सेकंड बहुत खराब है। यह महत्वपूर्ण क्यों है? उदाहरण के लिए, संगीत कार्यक्रमों और कुछ सार्वजनिक आयोजनों के लिए यह बिल्कुल महत्वहीन मीट्रिक है, कोई प्रतिक्रिया नहीं है; हम सिर्फ धारा दिखाते हैं - यह थोड़ा विलंब से बेहतर नहीं है। और एक धारा के लिए जहां किसी तरह का सम्मेलन हो रहा है या कोई व्यक्ति कुछ बताता है और वे उससे सवाल पूछते हैं, यह महत्वपूर्ण होने लगता है, क्योंकि वे टिप्पणियों में बहुत सारे सवाल पूछते हैं और मैं चाहता हूं कि दर्शकों को जल्द से जल्द प्रतिक्रिया मिले।

एक अन्य महत्वपूर्ण मीट्रिक बफरिंग और लैग है। वास्तव में, यह मीट्रिक न केवल क्लाइंट और गुणवत्ता के दृष्टिकोण से महत्वपूर्ण है, बल्कि इस दृष्टिकोण से भी कि हम एचएलएस की डिलीवरी को कितना "स्ट्रेच" कर सकते हैं, हम अपने सर्वर से कितना डेटा निचोड़ सकते हैं। इसलिए, हम खिलाड़ियों और "स्टील" में औसत बफर समय दोनों की निगरानी करते हैं।

खिलाड़ियों में गुणवत्ता का विकल्प समझ में आता है: अप्रत्याशित परिवर्तन हमेशा कष्टप्रद होते हैं।

तदनुसार, यह भी एक महत्वपूर्ण मीट्रिक है।

निगरानी

हमारे पास कई मॉनिटरिंग मेट्रिक्स हैं, लेकिन यहां मैंने उन मेट्रिक्स को चुना जो हमेशा काम करते हैं अगर कुछ गलत हुआ है:

-, . - , . , – , ( , – ).
/ . , , , , , . .
edge-. , , edge- .

«», ?

अब मैं आपको बताता हूं कि कैसे हमने "प्लेयर" जैसे एप्लिकेशन को संभाला जब हमने अपने इन्फ्रास्ट्रक्चर का उपयोग प्रश्नों और उत्तरों के साथ वीडियो स्ट्रीम को प्रसारित करने के लिए किया।

क्लोवर एक ऑनलाइन क्विज़ है। मेजबान कुछ कहता है, पूछता है: सवाल बाहर आते हैं - आप जवाब देते हैं। 12 सवाल, खेल के 10 मिनट, अंत में - किसी प्रकार का पुरस्कार। क्या इतना जटिल है? यह विकास है!

दाईं ओर यह ग्राफ है:

पीक [ग्राफ पर] "तिपतिया घास" की शुरुआत के समय एपीआई के संदर्भ में सर्वर पर लोड है। बाकी समय प्रसारण की सामान्य धारा है। यह दर्शकों की संख्या के बराबर नहीं हो सकता है। शायद यह अनुरोधों की संख्या और भार है।

यह कठिन है: 5 मिनट में एक मिलियन दर्शक चरम पर हमारे पास आए। वे प्रसारण देखना, पंजीकरण करना, किसी तरह की कार्रवाई करना, वीडियो का अनुरोध करना शुरू करते हैं ... यह एक बहुत ही सरल खेल प्रतीत होता है, लेकिन यह बहुत ही कम समय में होता है (अंतिम गेम सहित सभी क्रियाएं) - यह काफी उच्च भार देता है।

हमें किन सवालों और चुनौतियों का सामना करना पड़ा?

तेजी से विकास। कभी-कभी यह प्रति सप्ताह + 50% था। यदि, उदाहरण के लिए, आपके पास बुधवार को 200 हजार लोग हैं, तो शनिवार या रविवार को पहले से ही 300 हो सकते थे। यह बहुत है! समस्याएं सतह पर आने लगती हैं जो पहले दिखाई नहीं देती थीं।
2 . . , . , , , , , .
12 . , , , , , - , , …
, . , , 200-300 , 400-500.
- , , , 3-5 . ? «», , , , .

( 3 , ), , 3-5 . ? – , – exponential backoff, .

exponential on backoff: – , 2 , 4, 8. backend-.

«»?

-, . , – .
« ». , , , , «». , , -, , -, .
, – , «» . «». , , , … – . 10% «» – , 10% «» 100 – .
«» , , «» . – - . 100 – , 1 15 – .
. «» , , , . , , .
. , . , latency, .
. – , .
«» 1 . , , . . , , . .

?

वास्तुकला पूरी तरह से हमें सूट करता है, और मैं इसे सुरक्षित रूप से सुझा सकता हूं। एचएलएस कम से कम वेबसाइट और बाकी सब चीजों के लिए कम से कम बैकअप प्रोटोकॉल के लिए हमारे साथ मुख्य प्रोटोकॉल रहेगा। शायद हम एमपीईजी-डीएएचएस पर स्विच करेंगे।

RTMP छोड़ दिया। इस तथ्य के बावजूद कि यह कम देरी देता है, हमने फैसला किया कि हम एचएलएस को ट्यून करेंगे। शायद DASH सहित अन्य डिलीवरी वाहनों को एक विकल्प के रूप में देखें।

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

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

दरअसल, बस इतना ही। सभी को धन्यवाद!

प्रशन

दर्शकों से सवाल (बाद में - ए): - रिपोर्ट के लिए बहुत-बहुत धन्यवाद! केवल Odnoklassniki के स्पीकर ने बात की, और उन्होंने कहा कि उन्हें स्ट्रीमर, एनकोडर, एनकोडर को फिर से लिखना था ... क्या आप ऐसे समाधान का उपयोग करते हैं या स्टॉक का उपयोग करते हैं जो बाजार पर हैं (जैसे हार्मोनिक, आदि)?

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

तथा:- मैं एचएलएस पर आरटीएमपी को कम करने के बारे में एक सवाल पूछना चाहता था, लेकिन जैसा कि मैं इसे समझता हूं, आपने पहले ही जवाब दिया ... मुझे बताएं, क्या आपके समाधान खुले-स्रोत हैं?

एमआर: - हम इसे ओपनसोर्स में जारी करने पर विचार कर रहे हैं। हम इसे जारी करना चाहते हैं, लेकिन प्रश्न खुले स्रोत में रिलीज का समय है। स्रोत को इंटरनेट पर रखें - यह पर्याप्त नहीं है। आपको सोचने की जरूरत है, तैनाती के कुछ उदाहरण बनाएं। और किस प्रयोजन से पूछ रहे हो? उपयोग करना चाहते हैं?

A: - क्योंकि मैं भी Nginx-RTMP भर आया था! यह, हल्के ढंग से डालना है, बहुत लंबे समय तक समर्थित नहीं है। लेखक विशेष रूप से प्रश्नों का उत्तर नहीं देता है ...

MR: - यदि आप चाहें, तो आप मेल पर लिख सकते हैं। खुद के इस्तेमाल के लिए दें? हम सहमत हो सकते हैं। हम वास्तव में इसे खोलने की योजना बना रहे हैं।

तथा:- आपने यह भी कहा कि आप एचएलएस से डीएएसएच में स्थानांतरित कर सकते हैं। एचएलएस सूट नहीं करता है?

MR: - यह एक प्रश्न है कि हम क्या कर सकते हैं, या शायद नहीं। यह बहुत कुछ इस बात पर निर्भर करता है कि वैकल्पिक डिलीवरी के तरीकों (यानी यूडीपी) पर शोध के संदर्भ में हम क्या करेंगे। अगर हमें कुछ "पूरी तरह से" अच्छा लगता है, तो हम शायद एचएलएस को नहीं छूएंगे। यदि ऐसा लगता है कि MPEG-DASH अधिक आरामदायक है - शायद हम इसे स्थानांतरित कर देंगे। यह बहुत मुश्किल नहीं लगता है, लेकिन हम निश्चित नहीं हैं कि यह आवश्यक है या नहीं। गुणों और अन्य चीजों के बीच धाराओं के बीच तालमेल स्पष्ट रूप से बेहतर है। प्लसस हैं।

A: - अलर्ट के संबंध में। आपने इस तथ्य के बारे में बात की है कि यदि धाराएं स्ट्रीमिंग बंद कर देती हैं, तो यह तुरंत अलर्ट है। और आपने कुछ स्वतंत्र नहीं पकड़ा: प्रदाता गिर गया, मेगफॉन गिर गया, और लोगों ने स्ट्रीमिंग बंद कर दी? ..

MR:- आइए हम केवल यह कहें कि हम से स्वतंत्र कोई चीज मूल रूप से सभी तरह की छुट्टियां वगैरह हैं। हाँ उन्होंने किया। खैर, उन्होंने किया, हाँ। प्रशासकों ने देखा - आज छुट्टियां हैं, बाकी खूबियां बिलकुल ठीक हैं - उन्होंने शांत कर दिया।

ए: - और स्केलिंग के बारे में। यह किस स्तर पर है? उदाहरण के लिए, मैंने फोन से एक स्ट्रीम के लिए कहा - क्या मुझे तुरंत सही ऐश-सर्वर के साथ एक निश्चित लिंक प्राप्त होगा?

MR: - एक लिंक तुरंत आएगा और यदि आवश्यक हो, तो आपको स्विच करेगा (यदि किसी विशिष्ट सर्वर पर समस्याएं हैं)।

A: - कौन स्विच करेगा?

MR: - मोबाइल प्लेयर या वेब प्लेयर।

A: - वह धारा को फिर से चालू करेगा या क्या?

MR: - एक नया लिंक उसके पास आएगा जहां उसे लाइव स्ट्रीम जाना चाहिए। वह वहाँ जाएगा और धारा को फिर से पूछेगा।

तथा:- आपके पास किस स्तर पर कैश है? और प्लेलिस्ट, और विखंडू, या बस? ..

MR: - और प्लेलिस्ट, विखंडू! यह समय के संदर्भ में और समय की वापसी के संदर्भ में थोड़ा अलग है, लेकिन हम दोनों को कैश करते हैं।

A: - ऐश-सर्वर के निर्माण के बारे में? क्या आपके पास ऐसी स्थिति है कि आप एक प्रसारण पर 2 मिलियन दर्शकों को देखते हैं, कुछ के लिए समय नहीं है और जल्दी से कुछ ऐश-सर्वर उठाते हैं? या आप एक मार्जिन के साथ सब कुछ अग्रिम में बढ़ाते हैं?

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

ए: - आपने कहा था कि आप खिलाड़ी की ओर से वाद्य विलंब को मापते हैं। कैसे?

MR: - बहुत सरल है। विखंडू में (मीडिया सेगमेंट में) हमारे पास टाइमस्टैम्प है, मीडिया सेगमेंट के नाम पर - खिलाड़ी में हम इसे वापस करते हैं। यदि वह स्पष्ट रूप से बिल्कुल नहीं है, तो वह वापस लौटता है।

A: - मुझे याद है कि मैं WebRTC पर पेयरिंग चलाने की कोशिश कर रहा हूँ। क्यों मना कर दिया?

श्री:"मैं आपके लिए इस सवाल का जवाब नहीं दे सकता - यह मेरे बिना हुआ।" मैं यह नहीं कह सकता कि मैंने इसकी कोशिश क्यों की और मैं यह नहीं कह सकता कि मैंने क्यों मना किया।

ए: - रिसीवर और मीडिया सर्वर के बारे में। जैसा कि मैं इसे समझता हूं, आपके पास Nginx-RTMP हुआ करता था, अब वहां और आपके पास स्व-निर्मित समाधान हैं। वास्तव में, यह एक मीडिया सर्वर है जो अन्य मीडिया सर्वरों को प्रॉक्सी करता है, और वे पहले से ही कैश और किनारे पर हैं।

MR: - तो, वास्तव में नहीं। यह एक स्व-निर्मित समाधान है, लेकिन यह मीडिया सर्वर के संदर्भ में और रिसीवर के संदर्भ में अलग है। Nginx-RTMP - यह किसी प्रकार का हार्वेस्टर था जो दोनों कर सकता था। रिसीवर और मीडिया सर्वर के हमारे अंदरूनी बहुत अलग हैं - दोनों कोड और पूरे द्वारा। केवल एक चीज जो उन्हें एकजुट करती है वह है RTMP प्रोसेसिंग।

ए: - किनारों के बीच संतुलन के बारे में। यह कैसे होता है?

MR: - हम ट्रैफ़िक को मापते हैं, इसे इच्छित सर्वर पर भेजते हैं। मैं इस सवाल को थोड़ा समझ नहीं पाया ...

A: - मैं समझाऊंगा: उपयोगकर्ता खिलाड़ी के माध्यम से एक प्लेलिस्ट का अनुरोध करता है - वह आईपी या डोमेन द्वारा, उदाहरण के लिए, पथों या निरपेक्ष पथों के सापेक्ष पथ लौटाता है? ..

MR - - पथ सापेक्ष होते हैं

A: - अर्थात, एक उपयोगकर्ता द्वारा एक स्ट्रीम देखने पर कोई संतुलन नहीं है?

MR: - ऐसा होता है। काफी मुश्किल है। सर्वर को ओवरलोड करते समय हम 301 वें रीडायरेक्ट का उपयोग कर सकते हैं। यदि हम देखते हैं कि वहां सब कुछ पूरी तरह से खराब है, तो खंडों के लिए हम इसे दूसरे सर्वर पर भेज सकते हैं।

A: - लेकिन यह खिलाड़ी के तर्क में तार होना चाहिए?

श्री:- नहीं, बस इस हिस्से को सिलना नहीं चाहिए। 301 वें रीडायरेक्ट! बस, खिलाड़ी को 301 लिंक से बाहर निकलने में सक्षम होना चाहिए। हम इसे अधिभार के समय सर्वर साइड से दूसरे सर्वर पर भेज सकते हैं।

A: - अर्थात, वह सर्वर से पूछता है, और सर्वर उसे देता है?

MR: - हाँ। यह बहुत अच्छा नहीं है, इसलिए, खिलाड़ी के तर्क का उपयोग किसी एक सर्वर की विफलता के मामले में लिंक को फिर से रीट्वीट करने के लिए किया जाता है - यह पहले से ही खिलाड़ी के तर्क में है।

A: - और आपने सापेक्ष रूप से नहीं, बल्कि निरपेक्ष तरीके से काम करने की कोशिश की: जब आप खिलाड़ी से कुछ जादू करने का अनुरोध करते हैं, तो यह पता करें कि कहां संसाधन हैं और कहां नहीं, और पहले से ही प्लेलिस्ट को एक विशिष्ट सर्वर का संकेत दे रहे हैं?

श्री:- वास्तव में, यह एक कार्यशील समाधान की तरह दिखता है। अगर तुम आ गए होते तो हम दोनों का वज़न होता! लेकिन वर्तमान समाधान भी काम कर रहा है, इसलिए मैं वास्तव में एक से दूसरे में कूदना नहीं चाहता, हालांकि, शायद, यह भी एक कार्य समाधान की तरह दिखता है।

ए: - मुझे बताओ, क्या यह किसी तरह मल्टीकास्ट के साथ अनुकूल है? एचएलएस, जैसा कि मैं इसे समझता हूं, बिल्कुल कुछ भी नहीं ...

एमआर: - वर्तमान कार्यान्वयन में, हमारे पास शायद लाइव में मल्टीकास्ट के साथ सिस्टम में कुछ भी नहीं है। हम वहां मल्टीकास्ट की अवधारणा को शामिल नहीं करते हैं। शायद प्रशासन जादू की गहराई में, नेटवर्क के अंदर कुछ है, लेकिन यह हर किसी से छिपा हुआ है और किसी को नहीं पता ...

विज्ञापन का एक सा :)

हमारे साथ रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक ऑर्डर देकर या $ 4.99 से डेवलपर्स के लिए अपने दोस्तों के क्लाउड-आधारित VPS की अनुशंसा करके हमें समर्थन दें, आपके द्वारा आविष्कार किया गया एंट्री-लेवल सर्वर का एक अनूठा एनालॉग: VPS (KVM) E5-2697 3 (6 करोड़) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई $ 19 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

डेल R730xd एम्स्टर्डम में इक्विनिक्स टीयर IV डेटा सेंटर में 2 गुना सस्ता? केवल हमारे पास 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV नीदरलैंड के 199 डॉलर में से है!डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $ 99 से! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग सी?

हाईलोअड ++, मिखाइल रायचेंको (मानवेच): लगभग जादू के बिना, या टरबेट वीडियो स्ट्रीम वितरित करना कितना आसान है