कैसे हमने CDN MegaFon.TV को 2018 विश्व कप हिट नहीं करने में मदद की

2016 में, हमने इस बारे में बात की कि कैसे मेगाफॉन.टीवी ने उन सभी के साथ मुकाबला किया जो गेम ऑफ थ्रोन्स के नए सीजन को देखना चाहते थे। सेवा का विकास नहीं रुका और 2017 के मध्य तक हमें कई गुना अधिक भार से निपटना पड़ा। इस पोस्ट में हम बताएंगे कि इस तरह की तेजी से विकास ने हमें सीडीएन के आयोजन के लिए दृष्टिकोण को मौलिक रूप से बदलने के लिए कैसे प्रेरित किया और इस नए दृष्टिकोण का विश्व कप द्वारा परीक्षण कैसे किया गया।

संक्षेप में MegaFon.TV के बारे में

MegaFon.TV विभिन्न वीडियो सामग्री - फिल्में, टीवी शो, टीवी चैनल और रिकॉर्ड किए गए कार्यक्रमों को देखने के लिए एक ओटीटी सेवा है। MegaFon.TV के माध्यम से, सामग्री तक पहुंच लगभग किसी भी डिवाइस पर प्राप्त की जा सकती है: आईओएस और एंड्रॉइड के साथ फोन और टैबलेट पर, स्मार्ट टीवी एलजी, सैमसंग, फिलिप्स, पैनासोनिक रिलीज के विभिन्न वर्षों में, पूरे ओएस चिड़ियाघर (एप्पल टीवी, एंड्रॉइड टीवी) के साथ। विंडोज़, मैकओएस, लिनक्स पर डेस्कटॉप ब्राउज़र, आईओएस और एंड्रॉइड पर मोबाइल ब्राउज़रों में और यहां तक ​​कि एसटीबी और बच्चों के एंड्रॉइड प्रोजेक्टर जैसे विदेशी उपकरणों पर भी। उपकरणों पर व्यावहारिक रूप से कोई प्रतिबंध नहीं है - केवल 700 केबीपीएस की बैंडविड्थ के साथ इंटरनेट की उपलब्धता महत्वपूर्ण है। हमने कितने उपकरणों के लिए समर्थन का आयोजन किया, इसके बारे में भविष्य में एक अलग लेख होगा।
सेवा के अधिकांश उपयोगकर्ता मेगाफॉन ग्राहक हैं, जो सब्सक्राइबर के टैरिफ प्लान में शामिल लाभदायक (और सबसे अधिक बार मुफ़्त) ऑफ़र द्वारा समझाया गया है। यद्यपि हम अन्य ऑपरेटरों के उपयोगकर्ताओं में एक महत्वपूर्ण वृद्धि पर भी ध्यान देते हैं। इस वितरण के अनुसार, MegaFon.TV यातायात का 80% MegaFon नेटवर्क के भीतर खपत होता है।

वास्तुकला में, सेवा के शुभारंभ के बाद से, सामग्री को सीडीएन के माध्यम से वितरित किया गया है। हमारे पास इस CDN के कार्य के लिए एक अलग पोस्ट है । इसमें, हमने इस बारे में बात की कि कैसे इसने हमें 2016 के अंत में गेम ऑफ थ्रोन्स के नए सीज़न की रिलीज़ के दौरान चरम ट्रैफ़िक को संभालने की अनुमति दी। इस पोस्ट में, हम MegaFon.TV के आगे के विकास और 2018 विश्व कप के साथ-साथ इस सेवा पर पड़ने वाले नए कारनामों के बारे में बात करेंगे।

सेवा वृद्धि। और समस्याएं

पिछली पोस्ट की घटनाओं की तुलना में, 2017 के अंत तक मेगफॉन.टीवी उपयोगकर्ताओं की संख्या में कई गुना वृद्धि हुई है, फिल्मों और श्रृंखला भी परिमाण का एक क्रम बन गया है। नई कार्यक्षमता लॉन्च की गई, नए पैकेज दिखाई दिए, जो "सदस्यता द्वारा" उपलब्ध थे। "गेम ऑफ थ्रोन्स" के बाद से ट्रैफ़िक की चोटियाँ अब हम हर दिन देखते हैं, कुल धारा में फिल्मों और टीवी शो के अनुपात में लगातार वृद्धि हुई है।

इसके साथ ही यातायात के पुनर्वितरण के साथ समस्याएं शुरू हुईं। हमारी निगरानी, ​​विभिन्न स्वरूपों में विभिन्न प्रकार के ट्रैफ़िक के लिए विखंडू को डाउनलोड करने के लिए कॉन्फ़िगर किया गया, तेजी से टाइमआउट द्वारा वीडियो चंक डाउनलोड करने में त्रुटियों का उत्पादन शुरू हुआ। MegaFon.TV सेवा में, चंक की लंबाई 8 सेकंड है। यदि चंक को 8 सेकंड में लोड करने का समय नहीं है, तो त्रुटियां हो सकती हैं।

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

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

लेकिन समस्या खोजने के लिए वापस। जैसा कि हमने पहले ही देखा है, सभी सर्वरों ने एक साथ दोनों प्रकार की सामग्री की वापसी पर काम किया। उसी समय, सर्वरों का स्वयं एक अलग विन्यास था। नतीजतन, कुछ मशीनों को IOPS का उपयोग करके ओवरलोड किया गया था। छोटे प्रदर्शन, मात्रा, डिस्क की मात्रा, सामग्री के बड़े पुस्तकालय के कारण चूजों को लिखने / पढ़ने का समय नहीं मिला। दूसरी ओर, अधिक शक्तिशाली मशीनें जो अधिक ट्रैफ़िक प्राप्त करती थीं, CPU उपयोग पर विफल होने लगीं। एसएसएल ट्रैफिक की सर्विसिंग और https के जरिए दिए जाने वाले चंक्स पर सीपीयू संसाधन खर्च किए गए, जबकि आईओएस पर डिस्क्स बमुश्किल 35% तक पहुंच पाए।

जो आवश्यक था वह एक ऐसी योजना थी जो न्यूनतम लागत पर, उपलब्ध क्षमताओं को एक इष्टतम तरीके से उपयोग करना संभव बनाती है। इसके अलावा, छह महीने बाद विश्व कप शुरू होना था, और प्रारंभिक गणना के अनुसार, लाइव ट्रैफ़िक में चोटियों को छह घंटे तक रहना चाहिए ...

सीडीएन के लिए नया दृष्टिकोण

समस्या का विश्लेषण करने के बाद, हमने अलग-अलग कॉन्फ़िगरेशन वाले सर्वरों से बने अलग-अलग PAD के अनुसार VOD को अलग करने और ट्रैफ़िक को लाइव करने का निर्णय लिया। और ट्रैफ़िक वितरण और सर्वरों के विभिन्न समूहों में इसके संतुलन का कार्य भी बनाते हैं। कुल तीन ऐसे समूह थे:

• बड़ी संख्या में उच्च-प्रदर्शन डिस्क वाले सर्वर वीओडी सामग्री को कैशिंग करने के लिए सबसे उपयुक्त हैं। वास्तव में, अधिकतम क्षमता के एसएसडी आरआई सबसे उपयुक्त होंगे, लेकिन कोई भी नहीं था, और सही राशि की खरीद में बहुत अधिक बजट लगेगा। अंत में, यह सबसे अच्छा उपयोग करने का निर्णय लिया गया जो उपलब्ध था। प्रत्येक सर्वर में RAID5 में आठ 1TB 10k SAS डिस्क शामिल थे। इन सर्वरों से VOD_PAD संकलित किया गया था।
  
• Ssl ट्रैफ़िक को संभालने में सक्षम प्रोसेसर, और "मोटी" नेटवर्क इंटरफेस के साथ लाइव चंक्स की डिलीवरी के लिए सभी संभव प्रारूपों को कैशिंग के लिए बड़ी मात्रा में रैम के साथ सर्वर। हमने निम्न कॉन्फ़िगरेशन का उपयोग किया: 8 कोर के 2 प्रोसेसर / 192 जीबी रैम / 10 जीबी के 4 इंटरफेस। इन सर्वरों से EDGE_PAD संकलित किया गया था।
  
• शेष सर्वर समूह वीओडी ट्रैफ़िक को संभालने में सक्षम नहीं है, लेकिन लाइव सामग्री के छोटे संस्करणों के लिए उपयुक्त है। उनका उपयोग आरक्षित के रूप में किया जा सकता है। सर्वर से RESERVE_PAD संकलित किया गया था।
  

वितरण इस प्रकार था:

एक विशेष लॉजिक मॉड्यूल पैड को चुनने के लिए जिम्मेदार था जिसमें से उपयोगकर्ता को सामग्री प्राप्त करनी थी। यहाँ उनके कार्य हैं:

• URL का विश्लेषण करें, प्रत्येक स्ट्रीम अनुरोध के लिए उपरोक्त योजना लागू करें और आवश्यक PAD जारी करें
  
• EDGE_PAD इंटरफेस से लोड को हटाने के लिए हर 5 मिनट ( और यह हमारी गलती थी ), और जब सीमा समाप्त हो जाती है, तो अतिरिक्त ट्रैफ़िक को RESERVE_PAD पर स्विच करें। लोड को राहत देने के लिए, एक छोटी सी पर्ल स्क्रिप्ट लिखी गई थी जो निम्नलिखित डेटा लौटाती है:
  - टाइमस्टैम्प - लोड डेटा को अपडेट करने की तिथि और समय (आरएफसी 3339 प्रारूप में);
  - Total_bandwidth - वर्तमान इंटरफ़ेस लोड (कुल), Kbps;
  - rx_bandwidth - वर्तमान इंटरफ़ेस लोड (आने वाले ट्रैफ़िक), Kbps;
  - tx_badwidth - वर्तमान इंटरफ़ेस लोड (आउटगोइंग ट्रैफ़िक), Kbps।
  
• अप्रत्याशित स्थितियों के मामले में किसी भी PAD या उत्पत्ति सर्वर के लिए मैन्युअल मोड में प्रत्यक्ष ट्रैफ़िक, या यदि आवश्यक हो, PAD में से किसी एक पर काम करें। यह सर्वर yaml प्रारूप में सर्वर पर था और पैरामीटर में से किसी एक के अनुसार सभी ट्रैफ़िक को वांछित PAD या ट्रैफ़िक में ले जाने की अनुमति दी गई थी:
  - सामग्री प्रकार
  - यातायात एन्क्रिप्शन
  - पेड ट्रैफिक
  - डिवाइस प्रकार
  - प्लेलिस्ट प्रकार
  - क्षेत्र
  

उत्पत्ति सर्वर को SSD के रूप में समझा गया है। दुर्भाग्यवश, जब ट्रैफ़िक को ओरिजिन पर स्विच किया जा रहा था, तो वीओडी चंक्स पर HIT_RATE वांछित (लगभग 30%) छोड़ा गया, लेकिन उन्होंने अपना कार्य किया, इसलिए हमने CNN में पैकेटसेट के साथ कोई समस्या नहीं देखी।

चूंकि EDGE_PAD कॉन्फ़िगरेशन के लिए कुछ सर्वर थे, इसलिए उन्हें यातायात के सबसे बड़े हिस्से वाले क्षेत्रों में आवंटित करने का निर्णय लिया गया था - मास्को और वोल्गा क्षेत्र। GeoDNS की मदद से वोल्गा क्षेत्र को वोल्गा और यूराल संघीय जिलों के क्षेत्रों में भेजा गया। मास्को हब ने बाकी काम किया। हमें वास्तव में मॉस्को से साइबेरिया और सुदूर पूर्व में यातायात पहुंचाने का विचार पसंद नहीं आया, लेकिन कुल मिलाकर इन क्षेत्रों में सभी ट्रैफ़िक का लगभग 1/20 हिस्सा है, और मेगाफ़ोन के चैनल ऐसे संस्करणों के लिए पर्याप्त रूप से विस्तृत हैं।
योजना के विकास के बाद, निम्नलिखित कार्य किए गए:

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

यह कुछ कार्यों को समानांतर करने के लिए निकला, और अंत में सभी छह सप्ताह लग गए।

पहले परिणाम और भविष्य की योजनाएँ

ट्यूनिंग के बाद, समग्र प्रणाली का प्रदर्शन 250 जीबी / एस था। अलग सर्वरों में VOD ट्रैफिक के हस्तांतरण के साथ समाधान ने उत्पादन में रोल आउट करने के बाद तुरंत अपनी प्रभावशीलता दिखाई। विश्व कप की शुरुआत के बाद से, वीओडी यातायात के साथ कोई समस्या नहीं हुई है। कई बार, विभिन्न कारणों से, मुझे वीओडी ट्रैफ़िक को उत्पत्ति पर स्विच करना पड़ा, लेकिन सिद्धांत रूप में, उन्होंने भी नकल की। शायद यह योजना कैश के बहुत कम उपयोग के कारण बहुत प्रभावी नहीं है, क्योंकि हम SSD को लगातार सामग्री को अधिलेखित करने के लिए मजबूर करते हैं। लेकिन सर्किट काम करता है।

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



इससे 3 निष्कर्ष निकाले गए:

1. पांच मिनट अभी भी बहुत है। यह उतारने की अवधि को 30 सेकंड तक कम करने का निर्णय लिया गया था। परिणामस्वरूप, स्टैंडबाय पैड पर ट्रैफ़िक तेजी से बढ़ना बंद हो गया:
   
   
2. हर बार PAD के बीच उपयोगकर्ताओं को स्थानांतरित करने के लिए यह आवश्यक है कि स्विच चालू हो। यह स्विचिंग की अतिरिक्त चिकनाई प्रदान करना चाहिए। हमने प्रत्येक उपयोगकर्ता (या बल्कि डिवाइस) को एक कुकी आवंटित करने का फैसला किया, जिसके अनुसार वितरण के लिए जिम्मेदार मॉड्यूल समझता है कि क्या उपयोगकर्ता को वर्तमान पैड पर छोड़ दिया जाना चाहिए या यदि स्विच किया जाना चाहिए। यहां प्रौद्योगिकी उसी व्यक्ति के विवेक पर हो सकती है जो इसे लागू करता है। नतीजतन, हम मुख्य PAD पर ट्रैफ़िक नहीं छोड़ते हैं।
   
3. स्विचिंग के लिए सीमा बहुत कम निर्धारित की गई थी, परिणामस्वरूप, बैकअप पैड पर ट्रैफ़िक हिमस्खलन की तरह बढ़ गया। हमारे मामले में, यह एक पुनर्बीमा था - हमें पूरी तरह से यकीन नहीं था कि हमने सही सर्वर ट्यूनिंग बनाया था (जिस के लिए विचार, वैसे, हैबर से लिया गया था)। थ्रेशोल्ड को नेटवर्क इंटरफेस के भौतिक प्रदर्शन में बढ़ाया गया है।
   

सुधार में तीन दिन लगे, और पहले से ही रूस-क्रोएशिया मैच में, हमने जाँच की कि क्या हमारे अनुकूलन ने काम किया है। सामान्य तौर पर, परिणाम ने हमें प्रसन्न किया। अपने चरम पर, सिस्टम ने मिश्रित यातायात के 215 Gbit / s को संसाधित किया। यह सिस्टम प्रदर्शन पर एक सैद्धांतिक सीमा नहीं थी - हमारे पास अभी भी पर्याप्त मार्जिन था। यदि आवश्यक हो, तो अब हम किसी भी बाहरी सीडीएन को कनेक्ट कर सकते हैं, यदि आवश्यक हो, और वहां अतिरिक्त ट्रैफ़िक को "बाहर फेंक"। ऐसा मॉडल अच्छा है जब आप किसी और की सीडीएन का उपयोग करने के लिए हर महीने ठोस पैसा नहीं देना चाहते हैं।

हमारी योजनाओं में CDN का और विकास शामिल है। शुरू करने के लिए, मैं EDGE_PAD योजना को सभी संघीय जिलों तक विस्तारित करना चाहूंगा - इससे चैनलों का उपयोग कम होगा। VOD_PAD अतिरेक सर्किट परीक्षण भी किए जा रहे हैं, और कुछ परिणाम अब बहुत प्रभावशाली दिखते हैं।

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