في عام 2016 ، تحدثنا عن كيفية تعامل MegaFon.TV مع كل من أراد مشاهدة الموسم الجديد من Game of Thrones. لم يتوقف تطوير الخدمة عند هذا الحد ، وبحلول منتصف عام 2017 كان علينا التعامل مع الأحمال عدة مرات أكثر. في هذا المنشور ، سنخبرنا كيف ألهمنا هذا النمو السريع بتغيير جذري لنهج تنظيم CDN وكيف تم اختبار هذا النهج الجديد من قبل كأس العالم.
باختصار حول MegaFon.TV
MegaFon.TV هي خدمة OTT لعرض محتويات الفيديو المختلفة - الأفلام والبرامج التلفزيونية والقنوات التلفزيونية والبرامج المسجلة. من خلال MegaFon.TV ، يمكن الوصول إلى المحتوى على أي جهاز تقريبًا: على الهواتف والأجهزة اللوحية التي تعمل بنظامي iOS و Android ، على أجهزة التلفزيون الذكية LG و Samsung و Philips و Panasonic لسنوات مختلفة من الإصدار ، مع حديقة حيوان كاملة لنظام التشغيل (Apple TV و Android TV) ، في متصفحات سطح المكتب على أنظمة التشغيل Windows و MacOS و Linux ومتصفحات الجوال على iOS و Android ، وحتى على الأجهزة الغريبة مثل STB وأجهزة عرض Android للأطفال. لا توجد قيود على الأجهزة عمليًا - فقط توافر الإنترنت مع عرض النطاق الترددي 700 كيلوبت في الثانية هو المهم. حول كيفية تنظيم الدعم للعديد من الأجهزة ، سيكون هناك مقالة منفصلة في المستقبل.
معظم مستخدمي الخدمة هم من مشتركي MegaFon ، وهو ما يفسر بالعروض المربحة (وغالباً المجانية) المضمنة في خطة تعريفة المشترك. على الرغم من أننا نلاحظ أيضًا زيادة كبيرة في مستخدمي المشغلين الآخرين. وفقًا لهذا التوزيع ، يتم استهلاك 80٪ من حركة MegaFon.TV في شبكة MegaFon.
من الناحية المعمارية ، منذ إطلاق الخدمة ، تم توزيع المحتوى عبر CDN. لدينا
وظيفة منفصلة مخصصة لعمل هذا CDN. في ذلك ، تحدثنا عن كيف سمح لنا بالتعامل مع ذروة حركة المرور التي ذهبت إلى الخدمة في نهاية عام 2016 ، أثناء إصدار الموسم الجديد من Game of Thrones. في هذا المنشور ، سنتحدث عن المزيد من تطوير MegaFon.TV وعن المغامرات الجديدة التي سقطت في الخدمة جنبًا إلى جنب مع كأس العالم 2018.
نمو الخدمة. والمشاكل
مقارنة بأحداث آخر مشاركة ، بحلول نهاية عام 2017 ، زاد عدد مستخدمي Megafon.TV عدة مرات ، وأصبحت الأفلام والمسلسلات أيضًا ترتيبًا أكبر حجمًا. تم إطلاق وظائف جديدة ، ظهرت حزم جديدة ، متاحة "بالاشتراك". ذروة حركة المرور منذ "لعبة العروش" التي نراها كل يوم ، ازدادت نسبة الأفلام والبرامج التلفزيونية في إجمالي التدفق بشكل مطرد.
إلى جانب ذلك ، بدأت المشاكل في إعادة توزيع حركة المرور. بدأت المراقبة الخاصة بنا ، التي تم تكوينها لتنزيل أجزاء من أنواع مختلفة من حركة المرور بتنسيقات مختلفة ، بشكل متزايد في إنتاج أخطاء في تنزيل مقطع الفيديو حسب المهلة. في خدمة MegaFon.TV ، يبلغ طول القطعة 8 ثوانٍ. إذا لم يكن لدى القطعة وقت للتحميل في 8 ثوان ، فقد تحدث أخطاء.
كان من المتوقع أن تحدث ذروة الأخطاء في ساعات الذروة. كيف ينبغي أن يؤثر ذلك على المستخدمين؟ على الأقل ، يمكنهم ملاحظة تدهور جودة الفيديو. لا يمكن ملاحظتها دائمًا بالعين المجردة ، نظرًا لعدد كبير بما فيه الكفاية من ملفات تعريف معدل البت المتعدد. في أسوأ الأحوال ، يتجمد الفيديو.
بدأ البحث عن المشكلة. على الفور تقريبًا ، أصبح من الواضح أنه حدث خطأ رشاوي على خوادم EDGE الخاصة بـ CDN. هنا نحتاج إلى إجراء بحث صغير وإخبار كيفية عمل الخوادم مع حركة المرور المباشرة وحركة VOD. المخطط مختلف قليلاً. المستخدم الذي يأتي إلى خادم EDGE للمحتوى (قائمة تشغيل أو مقطع) ، إذا كان هناك محتوى في ذاكرة التخزين المؤقت ، يحصل عليه من هناك. خلاف ذلك ، يذهب خادم EDGE للمحتوى على Origin ، وتحميل القناة الرئيسية. جنبًا إلى جنب مع قائمة تشغيل أو مقطع ، يتم
توفير التحكم في
ذاكرة التخزين المؤقت: رأس
الحد الأقصى للعمر ، والذي يخبر خادم EDGE عن مقدار ذاكرة التخزين المؤقت لوحدة معينة من المحتوى. يكمن الاختلاف بين LIVE و VOD في الوقت الذي يستغرقه التخزين المؤقت للقطع. بالنسبة للقطع الحية ، يتم تعيين وقت قصير للتخزين المؤقت ، عادةً من 30 ثانية إلى عدة دقائق - ويرجع ذلك إلى قصر الوقت المناسب للمحتوى المباشر. يتم تخزين ذاكرة التخزين المؤقت هذه في ذاكرة الوصول العشوائي ، لأنك تحتاج إلى إعطاء قطع كبيرة وإعادة كتابة ذاكرة التخزين المؤقت. بالنسبة إلى أجزاء VOD ، يتم تعيين المزيد من الوقت ، من عدة ساعات إلى أسابيع وحتى أشهر - اعتمادًا على حجم مكتبة المحتوى وتوزيع طرق العرض الخاصة بها بين المستخدمين. أما بالنسبة لقوائم التشغيل ، فعادة ما يتم تخزينها مؤقتًا في مدة لا تزيد عن ثانيتين ، أو لا يتم تخزينها مؤقتًا على الإطلاق. تجدر الإشارة إلى أننا نتحدث فقط عن ما يسمى بوضع PULL لـ CDN ، والذي عملت فيه خوادمنا. لن يتم تبرير استخدام وضع PUSH في حالتنا بشكل كامل.
ولكن نعود إلى إيجاد المشكلة. كما لاحظنا بالفعل ، عملت جميع الخوادم في وقت واحد على إعادة كلا النوعين من المحتوى. في الوقت نفسه ، كان للخوادم نفسها تكوين مختلف. نتيجة لذلك ، تم تحميل بعض الأجهزة بشكل زائد باستخدام IOPS. لم يكن لدى Chunks الوقت للكتابة / القراءة بسبب الأداء الصغير والكمية وحجم الأقراص ومكتبة كبيرة من المحتوى. من ناحية أخرى ، بدأت الأجهزة الأكثر قوة التي تلقت المزيد من حركة المرور بالفشل في استخدام وحدة المعالجة المركزية. تم إنفاق موارد وحدة المعالجة المركزية على خدمة حركة مرور طبقة المقابس الآمنة (SSL) وأجزاء تم تسليمها عبر https ، في حين أن IOPS على الأقراص بالكاد وصل إلى 35 ٪.
ما هو مطلوب هو مخطط من شأنه ، بأقل تكلفة ، أن يجعل من الممكن استخدام القدرات المتاحة بطريقة مثلى. علاوة على ذلك ، بعد ستة أشهر ، كان من المقرر أن تبدأ كأس العالم ، ووفقًا للحسابات الأولية ، كان من المفترض أن تكون الذروة في حركة المرور الحية قد زادت ست مرات ...
نهج جديد لـ CDN
بعد تحليل المشكلة ، قررنا فصل VOD وحركة المرور الحية وفقًا لأجهزة PAD المختلفة المكونة من خوادم ذات تكوينات مختلفة. وأيضًا إنشاء وظيفة توزيع حركة المرور وموازنتها عبر مجموعات مختلفة من الخوادم. كان هناك ثلاث مجموعات من هذا القبيل في المجموع:
- الخوادم التي تحتوي على عدد كبير من الأقراص عالية الأداء الأكثر ملاءمة لتخزين محتوى VOD مؤقتًا. في الواقع ، ستكون أقراص SSI RI ذات السعة القصوى هي الأنسب ، ولكن لم يكن هناك أي منها متاح ، وسيستغرق الأمر الكثير من الميزانية لشراء المبلغ الصحيح. في النهاية ، تقرر استخدام أفضل ما هو متاح. احتوى كل خادم على ثمانية أقراص سعة 1 تيرابايت بسرعة 10 كيلو بايت في RAID5. من هذه الخوادم تم تصنيف VOD_PAD.
- خوادم تحتوي على كمية كبيرة من ذاكرة الوصول العشوائي للتخزين المؤقت لجميع التنسيقات الممكنة لتسليم الأجزاء الحية ، مع المعالجات القادرة على التعامل مع حركة مرور SSL ، وواجهات الشبكة "السميكة". استخدمنا التكوين التالي: معالجان من 8 نوى / 192 جيجابايت من ذاكرة الوصول العشوائي / 4 واجهات من 10 جيجابايت. من هذه الخوادم تم تجميع EDGE_PAD.
- مجموعة الخوادم المتبقية غير قادرة على معالجة حركة مرور VOD ، ولكنها مناسبة لكميات صغيرة من المحتوى المباشر. يمكن استخدامها كاحتياطي. من الخوادم تم تجميع RESERVE_PAD.
كان التوزيع على النحو التالي:
كانت وحدة المنطق الخاصة مسؤولة عن اختيار PAD التي كان من المفترض أن يتلقى المستخدم المحتوى منها. هنا مهامه:
- تحليل عنوان URL ، وتطبيق المخطط أعلاه لكل طلب دفق وإصدار PAD المطلوبة
- قم بإلغاء تحميل واجهات EDGE_PAD كل 5 دقائق ( وكان هذا خطأنا ) ، وعندما يتم الوصول إلى الحد ، قم بتغيير حركة المرور الزائدة إلى RESERVE_PAD. لتخفيف الحمل ، تم كتابة نص برمجي صغير يعرض البيانات التالية:
- الطابع الزمني - تاريخ ووقت تحديث بيانات التحميل (بتنسيق RFC 3339) ؛
- total_bandwidth - تحميل الواجهة الحالية (الإجمالي) ، كيلوبت في الثانية ؛
- rx_bandwidth - تحميل الواجهة الحالية (حركة المرور الواردة) ، كيلوبت في الثانية ؛
- tx_badwidth - تحميل الواجهة الحالية (حركة المرور الصادرة) ، كيلوبت في الثانية.
- توجيه حركة المرور في الوضع اليدوي إلى أي خادم PAD أو Origin في حالة المواقف غير المتوقعة ، أو إذا لزم الأمر ، العمل على أحد PAD. كان التكوين على الخادم بتنسيق yaml وسمح لأخذ كل حركة المرور إلى PAD المطلوب ، أو حركة المرور وفقًا لأحد المعلمات:
- نوع المحتوى
- تشفير الحركة
- المرور المدفوع
- نوع الجهاز
- نوع قائمة التشغيل
- المنطقة
كانت خوادم الأصل تعاني من نقص في SSD. لسوء الحظ ، عند تبديل حركة المرور إلى Origin ، ترك HIT_RATE على قطع VOD الكثير مما هو مرغوب (حوالي 30٪) ، لكنهم قاموا بمهمتهم ، لذلك لم نلاحظ أي مشاكل مع الحزم في CNN.
نظرًا لوجود عدد قليل من الخوادم لتهيئة EDGE_PAD ، فقد تقرر تخصيصها في المناطق ذات الحصة الأكبر من حركة المرور - موسكو ومنطقة فولغا. بمساعدة GeoDNS ، تم إرسال حركة المرور إلى منطقة Volga من مناطق مقاطعات Volga و Ural الفيدرالية. خدم محور موسكو الباقي. لم نحب حقًا فكرة توصيل حركة المرور إلى سيبيريا والشرق الأقصى من موسكو ، ولكن في المجموع تمثل هذه المناطق حوالي 1/20 من جميع حركة المرور ، وتبين أن قنوات MegaFon واسعة بما يكفي لمثل هذه الأحجام.
بعد وضع الخطة تم تنفيذ الأعمال التالية:
- في غضون أسبوعين ، تم تطوير وظيفة تبديل CDN
- استغرق تثبيت وتهيئة خوادم EDGE_PAD شهرًا ، بالإضافة إلى توسيع القنوات لها
- استغرق الأمر أسبوعين لتقسيم مجموعة الخوادم الحالية إلى قسمين ، بالإضافة إلى أسبوعين آخرين لتطبيق الإعدادات على جميع الخوادم على الشبكة ومعدات الخادم
- وأخيرًا ، تم قضاء الأسبوع على الاختبار (للأسف ، ليس تحت الحمل ، مما أثر في وقت لاحق)
اتضح أنه يوازي بعض الأعمال ، وفي النهاية استغرق كل ذلك ستة أسابيع.
النتائج الأولى والخطط المستقبلية
بعد الضبط ، كان الأداء الإجمالي للنظام 250 جيجابايت / ثانية. أظهر الحل مع نقل حركة VOD إلى خوادم منفصلة فورًا فعاليته بعد طرحه في الإنتاج. منذ بداية كأس العالم ، لم تكن هناك مشاكل في حركة مرور الفيديو حسب الطلب. عدة مرات ، لأسباب مختلفة ، اضطررت إلى تحويل حركة مرور VOD إلى Origin ، ولكن من حيث المبدأ ، تعاملت أيضًا. ربما هذا النظام ليس فعالًا جدًا بسبب الاستخدام الصغير جدًا لذاكرة التخزين المؤقت ، لأننا نجبر محركات الأقراص ذات الحالة الثابتة على الكتابة فوق المحتوى باستمرار. لكن الدائرة تعمل.
أما بالنسبة لحركة المرور الحية ، فقد ظهرت الأحجام المقابلة لاختبار قرارنا مع بداية كأس العالم. بدأت المشاكل عندما واجهنا في المرة الثانية تبديل حركة المرور عندما وصلنا إلى الحد الأقصى خلال مباراة روسيا ومصر. عندما نجح تبديل حركة المرور ، تدفقت كل شيء على PAD الاحتياطي. في هذه الدقائق الخمس ، كان عدد الطلبات (منحنى النمو) كبيرًا جدًا لدرجة أن شبكة CDN الاحتياطية انسدادت تمامًا وبدأت تتدفق في الأخطاء. في الوقت نفسه ، تم إصدار PAD الرئيسي خلال هذا الوقت وبدأ في الوقوف خاملاً قليلاً:
تم استخلاص 3 استنتاجات من هذا:
- خمس دقائق لا تزال كثيرة جدا. تقرر تخفيض فترة التفريغ إلى 30 ثانية. ونتيجة لذلك ، توقفت حركة المرور على الاستعداد PAD في النمو التشنجي:
- من الضروري على الأقل نقل المستخدمين بين أجهزة PAD في كل مرة يتم فيها تشغيل المفتاح. وهذا من شأنه أن يوفر نعومة إضافية للتبديل. قررنا تعيين ملف تعريف ارتباط لكل مستخدم (أو بالأحرى الجهاز) ، والذي بموجبه تفهم الوحدة المسؤولة عن التوزيع ما إذا كان يجب ترك المستخدم على PAD الحالي أو إذا كان يجب إجراء التبديل. هنا قد تكون التكنولوجيا حسب تقدير الشخص الذي ينفذها. ونتيجة لذلك ، فإننا لا نسقط حركة المرور على PAD الرئيسي.
- تم تعيين عتبة التبديل منخفضة للغاية ، ونتيجة لذلك ، ازدادت حركة المرور على PAD الاحتياطية مثل الانهيار الجليدي. في حالتنا ، كان هذا إعادة تأمين - لم نكن متأكدين تمامًا من أننا قمنا بضبط الخادم الصحيح (الفكرة التي تم أخذها من هبر بالمناسبة). تم زيادة العتبة إلى الأداء المادي لواجهات الشبكة.
استغرقت التحسينات ثلاثة أيام ، وبالفعل في مباراة روسيا وكرواتيا ، تحققنا مما إذا كان التحسين قد نجح. بشكل عام ، النتيجة أسعدتنا. في ذروته ، عالج النظام 215 جيجابت / ثانية لحركة مرور مختلطة. لم يكن هذا الحد النظري لأداء النظام - لا يزال لدينا هامش كبير. إذا لزم الأمر ، الآن يمكننا توصيل أي CDN خارجي ، إذا لزم الأمر ، و "التخلص" من حركة المرور الزائدة هناك. يعد هذا النموذج جيدًا عندما لا ترغب في دفع أموال قوية كل شهر لاستخدام CDN لشخص آخر.
تتضمن خططنا تطوير CDN. بادئ ذي بدء ، أود تمديد مخطط EDGE_PAD ليشمل جميع المقاطعات الفيدرالية - سيؤدي ذلك إلى استخدام أقل للقنوات. يتم أيضًا إجراء اختبارات دائرة تكرار VOD_PAD ، وتبدو بعض النتائج الآن مثيرة للإعجاب.
بشكل عام ، كل شيء تم القيام به خلال العام الماضي يقودني إلى التفكير في أن CDN للخدمة التي توزع محتوى الفيديو يجب أن يكون. وليس حتى لأنها تتيح لك توفير الكثير من المال ، بل لأن CDN تصبح جزءًا من الخدمة نفسها ، تؤثر بشكل مباشر على الجودة والوظائف. في مثل هذه الظروف ، فإن إعطائها في أيدي خاطئة أمر غير معقول على الأقل.