- مرحبا! دعني أخبرك بالمشكلات التي يتعين عليك حلها عندما تحتاج إلى إعداد خدمتك لأحمال تصل إلى عدة مئات من الجيجابت ، أو حتى تيرابت في الثانية. واجهتنا مثل هذه المشكلة لأول مرة في 2018 ، عندما كنا نستعد لبث كأس العالم FIFA.
لنبدأ بماهية بروتوكولات البث وكيف تعمل - خيار النظرة العامة الأكثر سطحية.
يعتمد أي بروتوكول دفق على بيان أو قائمة تشغيل. إنه ملف نصي صغير يحتوي على معلومات وصفية حول المحتوى. يصف نوع المحتوى - البث المباشر أو البث حسب الطلب (فيديو حسب الطلب). على سبيل المثال ، في حالة البث المباشر ، فهي مباراة كرة قدم أو مؤتمر عبر الإنترنت ، كما لدينا الآن معك ، وفي حالة VoD ، يتم إعداد المحتوى الخاص بك مسبقًا ويقع على خوادمك ، ويكون جاهزًا للتوزيع على المستخدمين. يصف نفس الملف مدة المحتوى ومعلومات حول إدارة الحقوق الرقمية.
كما يصف اختلافات المحتوى - مسارات الفيديو والمسارات الصوتية والترجمات. يمكن تمثيل مسارات الفيديو في برامج ترميز مختلفة. على سبيل المثال ، يتم دعم H.264 العام على أي جهاز. باستخدامه ، يمكنك تشغيل مقاطع الفيديو على أي مكواة في منزلك. أو هناك برامج ترميز HEVC و VP9 أكثر حداثة وأكثر كفاءة تتيح لك نقل 4K مع دعم HDR.
يمكن أيضًا تقديم مسارات الصوت في برامج ترميز مختلفة بمعدلات بت مختلفة. وقد يكون هناك العديد منها - المسار الصوتي الأصلي للفيلم باللغة الإنجليزية ، أو الترجمة إلى الروسية ، أو بين الجمل ، أو ، على سبيل المثال ، تسجيل حدث رياضي مباشرة من الاستاد بدون معلقين.
ماذا يفعل اللاعب بكل هذا؟ تتمثل مهمة المشغل ، أولاً وقبل كل شيء ، في تحديد أشكال المحتوى التي يمكنه تشغيلها ، وذلك ببساطة لأنه ليست كل برامج الترميز عالمية ، ولا يمكن تشغيلها كلها على جهاز معين.
بعد ذلك ، يحتاج إلى تحديد جودة الفيديو والصوت الذي سيبدأ من خلاله اللعب. يمكنه القيام بذلك بناءً على ظروف الشبكة ، إذا كان يعرفها ، أو على أساس بعض الاكتشافات البسيطة للغاية. على سبيل المثال ، ابدأ اللعب بجودة منخفضة ، وإذا سمحت الشبكة بذلك ، قم بزيادة الدقة ببطء.
في هذه المرحلة أيضًا ، يختار المسار الصوتي الذي سيبدأ التشغيل منه. افترض أن لديك اللغة الإنجليزية في نظام التشغيل الخاص بك. ثم يمكنه اختيار المسار الصوتي باللغة الإنجليزية افتراضيًا. ربما سيكون أكثر ملاءمة لك.
بعد ذلك ، يبدأ في إنشاء روابط لمقاطع الفيديو والصوت. في الواقع ، هذه روابط HTTP عادية ، كما هو الحال في جميع السيناريوهات الأخرى على الإنترنت. ويبدأ في تنزيل مقاطع الفيديو والصوت ، ووضعها في المخزن المؤقت واحدًا تلو الآخر واللعب بسلاسة. عادةً ما تكون مقاطع الفيديو هذه مدتها 2 ، 4 ، 6 ثوانٍ ، وربما 10 ثوانٍ حسب خدمتك.
ما هي النقاط المهمة هنا التي نحتاج إلى التفكير فيها عند تصميم شبكة CDN الخاصة بنا؟ بادئ ذي بدء ، لدينا جلسة مستخدم.
لا يمكننا فقط إعطاء ملف للمستخدم وننسى أمر هذا المستخدم. يعود باستمرار ويقوم بتنزيل مقاطع جديدة وجديدة إلى المخزن المؤقت الخاص به.
من المهم أن نفهم هنا أن وقت استجابة الخادم مهم أيضًا. إذا كنا نعرض نوعًا من البث المباشر في الوقت الفعلي ، فلا يمكننا إنشاء مخزن مؤقت كبير لمجرد أن المستخدم يريد مشاهدة الفيديو في أقرب وقت ممكن من الوقت الفعلي. من حيث المبدأ ، لا يمكن أن يكون المخزن المؤقت الخاص بك كبيرًا. وفقًا لذلك ، إذا لم يكن لدى الخادم وقت للرد بينما كان لدى المستخدم الوقت لعرض المحتوى ، فسيتم تجميد الفيديو ببساطة في مرحلة ما. بالإضافة إلى ذلك ، فإن المحتوى ثقيل جدًا. معدل البت القياسي لـ Full HD 1080p هو 3-5 ميجابت في الثانية. وفقًا لذلك ، على خادم جيجابت واحد ، لا يمكنك خدمة أكثر من 200 مستخدم في نفس الوقت. وهذه صورة مثالية ، لأنه ، كقاعدة عامة ، لا يتبع المستخدمون طلباتهم بالتساوي بمرور الوقت.
في أي مرحلة يتفاعل المستخدم بشكل عام مع شبكة CDN الخاصة بك؟ يحدث التفاعل بشكل أساسي في مكانين: عندما يقوم المشغل بتنزيل البيان (قائمة التشغيل) ، وعند تنزيل المقاطع.
لقد تحدثنا بالفعل عن البيانات ، هذه ملفات نصية صغيرة. لا توجد مشاكل خاصة في توزيع مثل هذه الملفات. إذا كنت ترغب في ذلك ، قم بتوزيعها من خادم واحد على الأقل. وإذا كانت شرائح ، فإنها تشكل غالبية حركة المرور الخاصة بك. سنتحدث عنهم.
يتم تقليل مهمة نظامنا بالكامل إلى حقيقة أننا نريد تكوين الرابط الصحيح لهذه الأجزاء واستبدال المجال الصحيح لبعض مضيف CDN لدينا هناك. في هذه المرحلة ، نستخدم الاستراتيجية التالية: على الفور في قائمة التشغيل نعطي مضيف CDN المطلوب ، حيث سيذهب المستخدم. هذا النهج يخلو من العديد من العيوب ، ولكن له فارق بسيط واحد مهم. تحتاج إلى التأكد من أن لديك آلية لنقل المستخدم بعيدًا عن مضيف إلى آخر بسلاسة أثناء التشغيل دون مقاطعة العرض. في الواقع ، تتمتع جميع بروتوكولات البث الحديثة بهذه الإمكانية ، يدعمها كل من HLS و DASH. فارق بسيط: في كثير من الأحيان ، حتى في المكتبات مفتوحة المصدر المشهورة جدًا ، لا يتم تنفيذ مثل هذا الاحتمال ، على الرغم من وجوده وفقًا للمعيار. كان علينا أن نرسل حزمًا إلى مكتبة Shaka مفتوحة المصدر ،إنه جافا سكريبت ، يستخدم لمشغل الويب ، لتشغيل DASH.
هناك مخطط آخر - مخطط anycast ، عندما تستخدم مجالًا واحدًا وتعطيه في جميع الروابط. في هذه الحالة ، لا تحتاج إلى التفكير في أي فروق دقيقة - فأنت تتخلى عن مجال واحد ، والجميع سعداء. (...)
الآن دعنا نتحدث عن كيفية تشكيل روابطنا.
من وجهة نظر الشبكة ، يتم تنظيم أي شركة كبيرة كنظام مستقل ، وغالبًا ما لا يكون نظامًا واحدًا. في الواقع ، النظام المستقل هو نظام لشبكات IP وأجهزة التوجيه التي يتحكم فيها مشغل واحد وتوفر سياسة توجيه واحدة مع الشبكة الخارجية ، مع الإنترنت. ياندكس ليست استثناء. شبكة Yandex هي أيضًا نظام مستقل ، ويتم الاتصال بالأنظمة المستقلة الأخرى خارج مراكز بيانات Yandex في نقاط التواجد. تصل الكابلات المادية لشركة Yandex ، والكابلات المادية لمشغلين آخرين إلى نقاط التواجد هذه ، ويتم تبديلها في الموقع ، على معدات حديدية. في مثل هذه النقاط لدينا الفرصة لوضع العديد من الخوادم ومحركات الأقراص الصلبة ومحركات أقراص الحالة الصلبة. هذا هو المكان الذي سنوجه فيه حركة المستخدم.
سوف نسمي هذه المجموعة من الخوادم الموقع. وفي كل موقع من هذه المواقع ، لدينا معرف فريد. سنستخدمه كجزء من اسم المجال للمضيفين على هذا الموقع وفقط للتعرف عليه بشكل فريد.
هناك العشرات من هذه المواقع في Yandex ، وهناك عدة مئات من الخوادم عليها ، وتأتي الروابط من عدة مشغلين إلى كل موقع ، لذلك لدينا أيضًا عدة مئات من الروابط.
كيف نختار الموقع الذي نرسل إليه مستخدم معين؟
لا توجد خيارات كثيرة في هذه المرحلة. يمكننا فقط استخدام عنوان IP لاتخاذ القرارات. يساعدنا فريق Yandex Traffic Team المنفصل في هذا الأمر ، والذي يعرف كل شيء عن كيفية عمل حركة المرور والشبكة في الشركة ، وهي التي تجمع مسارات المشغلين الآخرين حتى نتمكن من استخدام هذه المعرفة في عملية موازنة المستخدمين.
يجمع مجموعة من المسارات باستخدام BGP. لن نتحدث عن BGP بالتفصيل ، إنه بروتوكول يسمح للمشاركين في الشبكة عند حدود أنظمتهم الذاتية بالإعلان عن المسارات التي يمكن أن يخدمها نظامهم المستقل. يجمع فريق Traffic Team كل هذه المعلومات ، ويجمع ، ويحلل ، ويبني خريطة كاملة للشبكة بأكملها ، والتي نستخدمها لتحقيق التوازن.
نتلقى من فريق المرور مجموعة من شبكات IP والروابط التي يمكننا من خلالها خدمة العملاء. بعد ذلك ، نحتاج إلى فهم شبكة IP الفرعية المناسبة لمستخدم معين.
نقوم بذلك بطريقة بسيطة إلى حد ما - نبني شجرة بادئة. ثم تتمثل مهمتنا في استخدام عنوان IP الخاص بالمستخدم كمفتاح للعثور على الشبكة الفرعية الأكثر تطابقًا مع عنوان IP هذا.
عندما وجدناها ، لدينا قائمة بالروابط وأوزانها ومن خلال الروابط يمكننا تحديد الموقع الذي سنرسل إليه المستخدم بشكل فريد.
ما هو الوزن في هذا المكان؟ هذا مقياس يسمح لك بإدارة توزيع المستخدمين عبر مواقع مختلفة. يمكن أن يكون لدينا روابط ، على سبيل المثال ، بقدرات مختلفة. يمكن أن يكون لدينا رابط 100 جيجابت ورابط 10 جيجابت على نفس الموقع. من الواضح أننا نريد إرسال المزيد من المستخدمين إلى الرابط الأول ، لأنه أكثر اتساعًا. يأخذ هذا الوزن في الاعتبار هيكل الشبكة ، نظرًا لأن الإنترنت عبارة عن رسم بياني معقد لمعدات الشبكة المترابطة ، يمكن لحركة المرور الخاصة بك أن تسير في مسارات مختلفة ، ويجب أيضًا أخذ هذا الهيكل في الاعتبار.
تأكد من مشاهدة كيفية تنزيل المستخدمين للبيانات بالفعل. يمكن القيام بذلك على جانب الخادم والعميل. على الخادم ، نقوم بجمع اتصالات المستخدم بنشاط في سجلات معلومات TCP ، بالنظر إلى وقت الذهاب والإياب. من جانب المستخدم ، نحن نجمع بنشاط سجلات الأداء للمتصفح والمشغل. تحتوي سجلات الأداء هذه على معلومات مفصلة حول كيفية تنزيل الملفات من شبكة CDN الخاصة بنا.
إذا قمنا بتحليل كل هذا وتجميعه ، فبمساعدة هذه البيانات يمكننا تحسين الأوزان التي تم تحديدها في المرحلة الأولى بواسطة فريق المرور.
لنفترض أننا اخترنا ارتباطًا. هل يمكننا إرسال المستخدمين إلى هناك في هذه المرحلة؟ لا يمكننا ذلك ، لأن الوزن ثابت تمامًا على مدى فترة زمنية طويلة ، ولا يأخذ في الاعتبار أي ديناميكيات حقيقية للحمل. نريد أن نحدد في الوقت الفعلي ما إذا كان بإمكاننا الآن استخدام ارتباط تم تحميل 80٪ منه ، على سبيل المثال ، عندما يكون هناك ارتباط ذو أولوية أقل قليلاً في مكان قريب يتم تحميل 10٪ فقط. على الأرجح ، في هذه الحالة ، نريد فقط استخدام الثانية.
ما الذي يجب أخذه بعين الاعتبار في هذا المكان؟ يجب أن نأخذ في الاعتبار عرض النطاق الترددي للرابط ، وفهم حالته الحالية. قد يعمل أو يكون معيبًا من الناحية الفنية. أو ربما نرغب في نقلها إلى الخدمة حتى لا نسمح للمستخدمين بالذهاب إلى هناك وتقديمها ، وتوسيعها ، على سبيل المثال. يجب أن نأخذ دائمًا في الاعتبار الحمل الحالي لهذا الارتباط.
هناك بعض الفروق الدقيقة المثيرة للاهتمام هنا. يمكنك جمع معلومات حول تحميل الارتباط في عدة نقاط - على سبيل المثال ، على معدات الشبكة. هذه هي الطريقة الأكثر دقة ، ولكن مشكلتها هي أنه على معدات الشبكة لا يمكنك الحصول على فترة تحديث سريعة لهذا التنزيل. على سبيل المثال ، في Yandex ، تتنوع معدات الشبكة تمامًا ، ولا يمكننا جمع هذه البيانات أكثر من مرة في الدقيقة. إذا كان النظام مستقرًا إلى حد ما من حيث الحمل ، فهذه ليست مشكلة على الإطلاق. كل شيء سيعمل بشكل رائع. ولكن بمجرد حدوث تدفقات مفاجئة للحمل ، ليس لديك وقت للرد ، وهذا يؤدي ، على سبيل المثال ، إلى قطرات الحزمة.
من ناحية أخرى ، تعرف عدد البايتات التي تم إرسالها إلى المستخدم. يمكنك جمع هذه المعلومات على آلات التوزيع نفسها ، وعمل عداد للبايت مباشرة. لكنها لن تكون بهذه الدقة. لماذا ا؟
يوجد مستخدمون آخرون على شبكة CDN الخاصة بنا. لسنا الخدمة الوحيدة التي تستخدم آلات التوزيع هذه. وعلى خلفية حملنا ، فإن عبء الخدمات الأخرى ليس بهذه الأهمية. لكن حتى على خلفيتنا ، يمكن أن يكون ملحوظًا تمامًا. توزيعاتها لا تمر عبر دائرتنا ، لذلك لا يمكننا التحكم في هذه الحركة.
نقطة أخرى: حتى إذا كنت تعتقد على الجهاز المرسل أنك أرسلت حركة المرور إلى رابط معين ، فهذا بعيد كل البعد عن الحقيقة ، لأن BGP كبروتوكول لا يمنحك مثل هذا الضمان. وهناك طرق لزيادة احتمالية تخمينك بشكل صحيح ، لكن هذا موضوع لمناقشة أخرى.
لنفترض أننا حسبنا المقاييس ، وجمعنا كل شيء. الآن نحن بحاجة إلى خوارزمية لاتخاذ قرار عند الموازنة. يجب أن يحتوي على أربع خصائص مهمة:
- توفير النطاق الترددي للارتباط.
- منع التحميل الزائد للرابط ، ببساطة لأنه إذا قمت بتحميل ارتباط بنسبة 95٪ أو 98٪ ، فإن المخازن المؤقتة الموجودة على معدات الشبكة تبدأ في التدفق الزائد ، وتنخفض الحزمة ، وتبدأ عمليات إعادة الإرسال ، ولن يحصل المستخدمون على أي شيء جيد من ذلك.
- لتحذير الأحمال "المشبعة" ، سنتحدث عن هذا بعد قليل.
"في عالم مثالي ، سيكون من الرائع أن نتعلم إعادة استخدام رابط إلى مستوى معين نعتقد أنه صحيح. على سبيل المثال ، 85٪ تنزيل.
اتخذنا الفكرة التالية كأساس. لدينا فئتان مختلفتان من جلسات المستخدم. الفصل الأول عبارة عن جلسات جديدة ، عندما يفتح المستخدم الفيلم للتو ، لم يشاهد أي شيء بعد ، ونحاول معرفة مكان إرساله. أو الفئة الثانية ، عندما يكون لدينا جلسة حالية ، يتم تقديم المستخدم بالفعل على الرابط ، ويحتل جزءًا معينًا من النطاق الترددي ، ويتم تقديمه على خادم معين.
ماذا سنفعل بهم؟ نقدم قيمة احتمالية واحدة لكل فئة من هذه الدورة. سيكون لدينا قيمة تسمى Slowdown ، والتي تحدد النسبة المئوية للجلسات الجديدة التي لن نسمح بها على هذا الرابط. إذا كانت Slowdown تساوي صفرًا ، فإننا نقبل جميع الجلسات الجديدة ، وإذا كانت 50٪ ، فكل جلسة ثانية تقريبًا نرفض الخدمة على هذا الرابط. في الوقت نفسه ، ستتحقق خوارزمية الموازنة الخاصة بنا على مستوى أعلى من البدائل لهذا المستخدم. إسقاط - نفسه ، فقط للجلسات الحالية. يمكننا أخذ بعض جلسات المستخدم من الموقع في مكان آخر.
كيف نختار قيمة مقاييسنا الاحتمالية؟ لنأخذ النسبة المئوية لتحميل الرابط كأساس ، ثم كانت فكرتنا الأولى هي: دعنا نستخدم الاستيفاء الخطي متعدد التعريف.
أخذنا هذه الدالة ، التي لها عدة نقاط انكسار ، وننظر إلى قيمة معاملاتنا التي نستخدمها. إذا كان مستوى تنزيل الارتباط ضئيلاً ، فكل شيء على ما يرام ، والتباطؤ والإفلات يساوي الصفر ، فنسمح لجميع المستخدمين الجدد بالدخول. بمجرد أن يتجاوز مستوى التحميل حدًا معينًا ، نبدأ في رفض الخدمة لبعض المستخدمين على هذا الرابط. في مرحلة ما ، إذا استمر العبء في النمو ، نتوقف ببساطة عن إطلاق جلسات جديدة.
هناك فارق بسيط مثير للاهتمام هنا: الجلسات الحالية لها الأولوية في هذا المخطط. أعتقد أنه من الواضح سبب حدوث ذلك: إذا كان المستخدم قد زودك بالفعل بنمط تحميل ثابت ، فأنت لا تريد أن تأخذه إلى أي مكان ، لأنك بهذه الطريقة تزيد من ديناميكيات النظام ، وكلما كان النظام أكثر استقرارًا ، كان من الأسهل بالنسبة لنا التحكم فيه.
ومع ذلك ، قد يستمر التنزيل في الازدياد. في مرحلة ما ، يمكننا البدء في إزالة بعض الجلسات أو حتى إزالة الحمل تمامًا من هذا الرابط.
بهذا الشكل أطلقنا هذه الخوارزمية في المباريات الأولى لكأس العالم FIFA. ربما يكون من المثير للاهتمام رؤية الصورة التي رأيناها. كانت حول ما يلي.
حتى بالعين المجردة ، يمكن للمراقب الخارجي أن يفهم أن شيئًا ما ربما يكون خطأ هنا ، ويسألني: "أندريه ، هل أنت بخير؟" وإذا كنت مديري ، ستجري في أرجاء الغرفة وتصرخ: "أندريه ، يا إلهي! دحر كل شيء مرة أخرى! أعد كل شيء كما كان! " دعنا نخبرك بما يحدث هنا.
على المحور X ، الوقت ، على المحور Y ، نلاحظ مستوى تحميل الارتباط. هناك نوعان من الروابط التي تخدم نفس الموقع. من المهم أن نفهم أننا في هذه اللحظة استخدمنا فقط مخطط مراقبة حمل الارتباط الذي تمت إزالته من معدات الشبكة ، وبالتالي لم نتمكن من الاستجابة بسرعة لديناميكيات الحمل.
عندما نرسل المستخدمين إلى أحد الروابط ، هناك زيادة حادة في حركة المرور على هذا الرابط. الارتباط مثقل. قمنا بتفريغ التحميل ووجدنا أنفسنا على الجانب الأيمن من الدالة التي رأيناها في الرسم البياني السابق. ونبدأ في إسقاط المستخدمين القدامى والتوقف عن السماح بدخول مستخدمين جدد. إنهم بحاجة للذهاب إلى مكان ما ، ويذهبون ، بالطبع ، إلى الرابط التالي. في المرة الأخيرة ، ربما كانت أولوية أقل ، لكن الآن لديهم الأولوية.
الرابط الثاني يكرر نفس الصورة. نزيد الحمل بشكل حاد ، ونلاحظ أن الرابط محمّل بشكل زائد ، ونزيل الحمل ، وهذان الرابطان في طور مضاد من حيث مستوى التحميل.
ماذا يمكن ان يفعل؟ يمكننا تحليل ديناميكيات النظام ، ونلاحظ ذلك مع زيادة كبيرة في الحمل وترطيبه قليلاً. هذا بالضبط ما فعلناه. أخذنا اللحظة الحالية ، وأخذنا نافذة المراقبة إلى الماضي لبضع دقائق ، على سبيل المثال 2-3 دقائق ، ونظرنا في مقدار تغير تحميل الارتباط في هذه الفترة. سيطلق على الفرق بين القيم الدنيا والقصوى اسم الفاصل الزمني للتذبذب لهذا الارتباط. وإذا كانت فترة التذبذب كبيرة ، فسنضيف التخميد ، وبالتالي نزيد من تباطؤنا ونبدأ في تشغيل جلسات أقل.
تبدو هذه الوظيفة مماثلة للوظيفة السابقة تقريبًا ، مع وجود عدد أقل من الكسور. إذا كان لدينا فاصل زمني صغير لتنزيل التذبذبات ، فلن نضيف أي تذبذبات إضافية. وإذا بدأ الفاصل الزمني للتذبذب في النمو ، فإن extra_slowdown يأخذ قيمًا غير صفرية ، وسنضيفها لاحقًا إلى التباطؤ الرئيسي.
يعمل نفس المنطق عند القيم المنخفضة لفاصل التذبذب. إذا كان لديك الحد الأدنى من التقلبات على الرابط ، فعندئذٍ ، على العكس من ذلك ، تريد السماح لعدد أكبر قليلاً من المستخدمين هناك وتقليل التباطؤ وبالتالي الاستفادة بشكل أفضل من الارتباط الخاص بك.
لقد قمنا أيضًا بتنفيذ هذا الجزء. الصيغة النهائية تبدو هكذا. في الوقت نفسه ، نحن نضمن أن كلتا القيمتين - extra_slowdown و reduction_slowdown - لا تحتويان على قيمة غير صفرية في نفس الوقت ، لذلك تعمل واحدة منهما بفعالية. هذا هو الشكل الذي نجت فيه صيغة التوازن هذه من جميع مباريات كأس العالم FIFA. حتى في المباريات الأكثر شعبية ، عملت بشكل جيد: هذه "روسيا - كرواتيا" ، "روسيا - إسبانيا". خلال هذه المباريات ، قمنا بتوزيع سجل لأحجام حركة مرور Yandex - 1.5 تيرابايت في الثانية. مررنا بها بهدوء. منذ ذلك الحين ، لم تتغير الصيغة بأي شكل من الأشكال ، لأنه لم يكن هناك مثل هذا المرور على خدمتنا منذ ذلك الحين - حتى لحظة معينة.
ثم جاءنا وباء. تم إرسال الناس للجلوس في المنزل ، وفي المنزل يوجد إنترنت جيد وتلفزيون وجهاز لوحي والكثير من أوقات الفراغ. بدأت حركة المرور إلى خدماتنا تنمو بشكل طبيعي ، سريعًا وكبيرًا. الآن هذا النوع من العبء ، كما كان خلال كأس العالم ، هو روتيننا اليومي. لقد قمنا منذ ذلك الحين بتوسيع قنواتنا مع المشغلين قليلاً ، ولكن مع ذلك بدأنا في التفكير في التكرار التالي لخوارزمية لدينا ، وما يجب أن تكون وكيف يمكننا الاستفادة بشكل أفضل من شبكتنا.
ما هي عيوب الخوارزمية السابقة؟ لم نحل مشكلتين. لم نتخلص تمامًا من أحمال "المنشار". لقد قمنا بتحسين الصورة بشكل كبير واتساع هذه التقلبات ضئيل للغاية ، وقد زادت الفترة بشكل كبير ، مما يسمح أيضًا باستخدام أفضل للشبكة. لكن على الرغم من أنها تظهر من وقت لآخر ، تبقى. لم نتعلم كيفية الاستفادة من الشبكة إلى المستوى الذي نرغب فيه. على سبيل المثال ، لا يمكننا استخدام التكوين لتعيين الحد الأقصى لمستوى تحميل الارتباط المطلوب بنسبة 80-85٪.
ما هي الأفكار التي لدينا للتكرار التالي للخوارزمية؟ كيف نتصور الاستخدام المثالي للشبكة؟ يبدو أن أحد المجالات الواعدة هو الخيار عندما يكون لديك مكان واحد لاتخاذ القرارات بشأن حركة المرور. تقوم بجمع جميع المقاييس في مكان واحد ، ويأتي هناك طلب مستخدم لتنزيل الأجزاء ، وفي كل لحظة يكون لديك حالة كاملة من النظام ، فمن السهل جدًا عليك اتخاذ القرارات.
ولكن هناك فروق دقيقة هنا. أولاً ، ليس من المعتاد في Yandex كتابة "نقاط اتخاذ القرار المشتركة" ، لأنه ببساطة مع مستويات التحميل لدينا ، مع حركة المرور لدينا ، يصبح هذا المكان سريعًا عنق الزجاجة.
هناك فارق بسيط آخر - في Yandex من المهم أيضًا كتابة أنظمة تتسامح مع الأخطاء. غالبًا ما نغلق مراكز البيانات تمامًا ، بينما يجب أن يستمر المكون الخاص بك في العمل دون أخطاء ودون انقطاع. وفي هذا الشكل ، يصبح هذا المكان الفردي ، في الواقع ، نظامًا موزعًا تحتاج إلى التحكم فيه ، وهذه مهمة أصعب قليلاً من تلك التي نود حلها في هذا المكان.
نحن بالتأكيد بحاجة إلى مقاييس سريعة. بدونها ، الشيء الوحيد الذي يمكنك القيام به لتجنب معاناة المستخدم هو التقليل من استخدام الشبكة. لكن هذا لا يناسبنا أيضًا.
إذا نظرت إلى نظامنا على مستوى عالٍ ، يتضح لك أن نظامنا هو نظام ديناميكي مع ملاحظات. لدينا حمولة مخصصة ، وهي إشارة دخل. يأتي الناس ويذهبون. لدينا إشارة تحكم - القيمتان الأساسيتان اللتان يمكننا تغييرهما في الوقت الفعلي. بالنسبة لمثل هذه الأنظمة الديناميكية ذات التغذية الراجعة ، تم تطوير نظرية التحكم الآلي لفترة طويلة ، عدة عقود. وهي مكوناته التي نرغب في استخدامها لتحقيق الاستقرار في نظامنا.
نظرنا إلى مرشح كالمان. هذا شيء رائع يسمح لك ببناء نموذج رياضي للنظام ، وبمقاييس صاخبة أو في غياب بعض فئات المقاييس ، قم بتحسين النموذج باستخدام نظامك الحقيقي. ثم اتخذ قرارًا بشأن نظام حقيقي يعتمد على نموذج رياضي. لسوء الحظ ، اتضح أنه ليس لدينا العديد من فئات المقاييس التي يمكننا استخدامها ، ولا يمكن تطبيق هذه الخوارزمية.
لقد اقتربنا من الجانب الآخر ، وأخذنا كأساس مكونًا آخر لهذه النظرية - وحدة التحكم PID. لا يعرف شيئًا عن نظامك. وتتمثل مهمتها في معرفة الحالة المثالية للنظام ، أي مستوى التحميل المطلوب ، والحالة الحالية للنظام ، على سبيل المثال ، مستوى التحميل. وهو يعتبر أن الاختلاف بين هاتين الحالتين خطأ ، وباستخدام خوارزمياته الداخلية ، يتحكم في إشارة التحكم ، أي قيم التباطؤ والإفلات. والغرض منه هو تقليل الخطأ في النظام.
سنجرب جهاز التحكم PID هذا في الإنتاج من يوم لآخر. ربما في غضون أشهر قليلة سنتمكن من إخبارك بالنتائج.
في هذا ربما ننتهي من الشبكة. أود أن أخبركم عن كيفية توزيعنا لحركة المرور داخل الموقع نفسه ، عندما اخترناها بالفعل بين المضيفين. لكن ليس هناك وقت لذلك. ربما يكون هذا موضوعًا لتقرير كبير منفصل.
لذلك ، في السلسلة التالية ، ستتعلم كيفية الاستفادة المثلى من ذاكرة التخزين المؤقت على المضيفين ، وماذا تفعل مع حركة المرور الساخنة والباردة ، وكذلك من أين تأتي حركة المرور الدافئة ، وكيف يؤثر نوع المحتوى على الخوارزمية الخاصة بتوزيعه وأي مقطع فيديو يعطي أعلى ذاكرة تخزين مؤقت في الخدمة ، ومن من يغني أغنية.
لدي قصة أخرى مثيرة للاهتمام. في الربيع ، كما تعلم ، بدأ الحجر الصحي. لطالما كان لدى Yandex منصة تعليمية تسمى Yandex.Tutorial ، والتي تسمح للمعلمين بتحميل مقاطع الفيديو والدروس. يأتي الطلاب هناك ويشاهدون المحتوى. خلال الوباء ، بدأت Yandex في دعم المدارس ، ودعوتها بنشاط إلى نظامها الأساسي حتى يتمكن الطلاب من الدراسة عن بُعد. وفي مرحلة ما رأينا نموًا جيدًا في حركة المرور ، وصورة مستقرة إلى حد ما. لكن في إحدى أمسيات أبريل التي رأيناها على الرسوم البيانية شيئًا مثل التالي.
يوجد أدناه صورة حركة المرور على المحتوى التعليمي. رأينا أنه سقط بشكل حاد في مرحلة ما. بدأنا في الذعر ، لمعرفة ما يجري بشكل عام ، ما الذي تم كسره. ثم لاحظنا أن إجمالي عدد الزيارات إلى الخدمة بدأ في النمو. من الواضح أن شيئًا مثيرًا للاهتمام قد حدث.
في الواقع ، في تلك اللحظة حدث ما يلي.
هكذا يرقص الرجل بسرعة.
بدأ حفل Little Big ، وغادر جميع الطلاب لمشاهدته. لكن بعد نهاية الحفل ، عادوا واستمروا في الدراسة بنجاح. نرى مثل هذه الصور في كثير من الأحيان على خدمتنا. لذلك ، أعتقد أن عملنا ممتع للغاية. شكرا للجميع! ربما سأنتهي مع هذا حول CDN.