Netflix هي الشركة الرائدة في سوق التلفزيون عبر الإنترنت - الشركة التي أنشأت هذا القطاع وتعمل على تطويره بنشاط. لا تشتهر Netflix بكتالوجها الواسع من الأفلام والمسلسلات التلفزيونية المتاحة من كل ركن من أركان الكوكب تقريبًا وأي جهاز مزود بشاشة عرض فحسب، بل تشتهر أيضًا ببنيتها التحتية الموثوقة وثقافتها الهندسية الفريدة.
تم تقديم مثال واضح لنهج Netflix في تطوير ودعم الأنظمة المعقدة في DevOops 2019 - مدير التطوير في Netflix. خريج كلية الرياضيات الحاسوبية والرياضيات بجامعة ولاية نيجني نوفغورود. Lobachevsky، سيرجي هو أحد المهندسين الأوائل في فريق Open Connect - CDN في Netflix. قام ببناء أنظمة لمراقبة وتحليل بيانات الفيديو، وأطلق خدمة شائعة لتقييم سرعة الاتصال بالإنترنت FAST.com، وعمل خلال السنوات القليلة الماضية على تحسين طلبات الإنترنت بحيث يعمل تطبيق Netflix في أسرع وقت ممكن للمستخدمين.
حصل التقرير على أفضل التقييمات من المشاركين في المؤتمر، وقد أعددنا لكم نسخة نصية.
تحدث سيرجي في تقريره بالتفصيل
- حول ما يؤثر على تأخير طلبات الإنترنت بين العميل والخادم؛
- كيفية الحد من هذا التأخير؛
- وكيفية تصميم وصيانة ومراقبة الأنظمة المتسامحة مع الأخطاء؛
- كيفية تحقيق النتائج في وقت قصير، وبأقل قدر ممكن من المخاطر على العمل؛
- كيفية تحليل النتائج والتعلم من الأخطاء.
الإجابات على هذه الأسئلة ليست ضرورية فقط لأولئك الذين يعملون في الشركات الكبيرة.
يجب أن تكون المبادئ والتقنيات المقدمة معروفة وممارستها من قبل كل من يقوم بتطوير منتجات الإنترنت ودعمها.
التالي هو السرد من وجهة نظر المتحدث.
أهمية سرعة الإنترنت
ترتبط سرعة طلبات الإنترنت ارتباطًا مباشرًا بالأعمال. ولنتأمل هنا صناعة التسوق: أمازون في عام 2009 أن التأخير بمقدار 100 مللي ثانية يؤدي إلى خسارة 1% من المبيعات.
هناك المزيد والمزيد من الأجهزة المحمولة، تليها مواقع وتطبيقات الهاتف المحمول. إذا استغرق تحميل صفحتك أكثر من 3 ثوانٍ، فإنك تفقد حوالي نصف المستخدمين. مع يأخذ Google في الاعتبار سرعة تحميل صفحتك في نتائج البحث: كلما كانت الصفحة أسرع، ارتفع موضعها في Google.
تعد سرعة الاتصال مهمة أيضًا في المؤسسات المالية حيث يكون زمن الوصول أمرًا بالغ الأهمية. في عام 2015، شبكات هيبرنيا كابل بقيمة 400 مليون دولار بين نيويورك ولندن لتقليل زمن الوصول بين المدينتين بمقدار 6 مللي ثانية. تخيل 66 مليون دولار مقابل 1 مللي ثانية من زمن الوصول!
وفق ، لم تعد سرعات الاتصال التي تزيد عن 5 ميجابت/ثانية تؤثر بشكل مباشر على سرعة تحميل موقع الويب النموذجي. ومع ذلك، هناك علاقة خطية بين زمن الوصول للاتصال وسرعة تحميل الصفحة:
ومع ذلك، فإن Netflix ليس منتجًا نموذجيًا. يعد تأثير زمن الوصول والسرعة على المستخدم مجالًا نشطًا للتحليل والتطوير. يعتمد تحميل التطبيق واختيار المحتوى على زمن الوصول، لكن تحميل العناصر الثابتة والبث يعتمد أيضًا على سرعة الاتصال. يُعد تحليل العوامل الرئيسية التي تؤثر على تجربة المستخدم وتحسينها مجالًا نشطًا للتطوير للعديد من الفرق في Netflix. أحد الأهداف هو تقليل زمن انتقال الطلبات بين أجهزة Netflix والبنية التحتية السحابية.
سنركز في التقرير بشكل خاص على تقليل زمن الوصول باستخدام مثال البنية التحتية لـ Netflix. دعونا نفكر من الناحية العملية في كيفية التعامل مع عمليات تصميم وتطوير وتشغيل الأنظمة الموزعة المعقدة وقضاء الوقت في الابتكار والنتائج، بدلاً من تشخيص المشكلات والأعطال التشغيلية.
داخل نتفليكس
تدعم آلاف الأجهزة المختلفة تطبيقات Netflix. تم تطويرها بواسطة أربعة فرق مختلفة، والتي تقوم بإنشاء إصدارات منفصلة من العميل لأنظمة Android وiOS والتلفزيون ومتصفحات الويب. ونحن نبذل الكثير من الجهد لتحسين تجربة المستخدم وتخصيصها. وللقيام بذلك، نقوم بإجراء مئات من اختبارات A/B بالتوازي.
يتم دعم التخصيص من خلال مئات الخدمات الصغيرة في سحابة AWS، مما يوفر بيانات المستخدم المخصصة وإرسال الاستعلام والقياس عن بعد والبيانات الضخمة والتشفير. يبدو تصور حركة المرور كما يلي:
على اليسار توجد نقطة الدخول، ومن ثم يتم توزيع حركة المرور بين عدة مئات من الخدمات الصغيرة التي تدعمها فرق الواجهة الخلفية المختلفة.
عنصر آخر مهم في بنيتنا التحتية هو Open Connect CDN، الذي يوفر محتوى ثابتًا للمستخدم النهائي - مقاطع الفيديو والصور ورمز العميل وما إلى ذلك. يوجد CDN على خوادم مخصصة (OCA - Open Connect Appliance). يوجد بالداخل مصفوفات من محركات أقراص SSD وHDD التي تعمل بنظام FreeBSD المحسّن، مع NGINX ومجموعة من الخدمات. نقوم بتصميم وتحسين مكونات الأجهزة والبرامج بحيث يتمكن خادم CDN من إرسال أكبر قدر ممكن من البيانات إلى المستخدمين.
يبدو "جدار" هذه الخوادم عند نقطة تبادل حركة المرور على الإنترنت (Internet eXchange - IX) كما يلي:
يوفر تبادل الإنترنت القدرة لموفري خدمات الإنترنت وموفري المحتوى على "الاتصال" مع بعضهم البعض لتبادل البيانات بشكل مباشر على الإنترنت. هناك ما يقرب من 70 إلى 80 نقطة لتبادل الإنترنت حول العالم حيث يتم تثبيت خوادمنا، ونحن نقوم بتثبيتها وصيانتها بشكل مستقل:
بالإضافة إلى ذلك، نقوم أيضًا بتوفير الخوادم مباشرةً لموفري خدمة الإنترنت، والتي يقومون بتثبيتها في شبكتهم، مما يؤدي إلى تحسين توطين حركة مرور Netflix وجودة البث للمستخدمين:
مجموعة من خدمات AWS مسؤولة عن إرسال طلبات الفيديو من العملاء إلى خوادم CDN، بالإضافة إلى تكوين الخوادم نفسها - تحديث المحتوى، ورمز البرنامج، والإعدادات، وما إلى ذلك. بالنسبة للأخيرة، قمنا أيضًا ببناء شبكة أساسية تربط الخوادم في نقاط Internet Exchange مع AWS. الشبكة الأساسية هي شبكة عالمية من كابلات الألياف الضوئية وأجهزة التوجيه التي يمكننا تصميمها وتكوينها بناءً على احتياجاتنا.
في ، توفر البنية التحتية لـ CDN الخاصة بنا ما يقرب من ⅛ حركة مرور الإنترنت على مستوى العالم خلال ساعات الذروة و⅓ حركة المرور في أمريكا الشمالية، حيث كانت Netflix موجودة لفترة أطول. أرقام مثيرة للإعجاب، ولكن بالنسبة لي أحد أكثر الإنجازات المذهلة هو أن نظام CDN بأكمله تم تطويره وصيانته بواسطة فريق مكون من أقل من 150 شخصًا.
في البداية، تم تصميم البنية التحتية لـ CDN لتوصيل بيانات الفيديو. ومع ذلك، أدركنا بمرور الوقت أنه يمكننا أيضًا استخدامه لتحسين الطلبات الديناميكية من العملاء في سحابة AWS.
بخصوص تسريع الانترنت
اليوم، لدى Netflix 3 مناطق AWS، وسيعتمد زمن وصول الطلبات إلى السحابة على مدى بعد العميل عن أقرب منطقة. وفي الوقت نفسه، لدينا العديد من خوادم CDN التي تُستخدم لتقديم محتوى ثابت. هل هناك أي طريقة لاستخدام هذا الإطار لتسريع الاستعلامات الديناميكية؟ ومع ذلك، لسوء الحظ، من المستحيل تخزين هذه الطلبات مؤقتًا - حيث يتم تخصيص واجهات برمجة التطبيقات وكل نتيجة فريدة من نوعها.
لنقم بإنشاء وكيل على خادم CDN ونبدأ في إرسال حركة المرور من خلاله. هل سيكون أسرع؟
العتاد
دعونا نتذكر كيف تعمل بروتوكولات الشبكة. اليوم، تستخدم معظم حركة المرور على الإنترنت بروتوكولات HTTP، والتي تعتمد على بروتوكولات الطبقة السفلية TCP وTLS. لكي يتمكن العميل من الاتصال بالخادم، فإنه يقوم بالمصافحة، ولإنشاء اتصال آمن، يحتاج العميل إلى تبادل الرسائل مع الخادم ثلاث مرات ومرة أخرى على الأقل لنقل البيانات. مع زمن الوصول لكل رحلة ذهابًا وإيابًا (RTT) يبلغ 100 مللي ثانية، سيستغرق الأمر 400 مللي ثانية لتلقي أول بت من البيانات:
إذا وضعنا الشهادات على خادم CDN، فيمكن تقليل وقت المصافحة بين العميل والخادم بشكل كبير إذا كان CDN أقرب. لنفترض أن زمن الوصول لخادم CDN هو 30 مللي ثانية. ثم سيستغرق الأمر 220 مللي ثانية لتلقي البت الأول:
لكن المزايا لا تنتهي عند هذا الحد. بمجرد إنشاء الاتصال، يعمل بروتوكول TCP على زيادة نافذة الازدحام (كمية المعلومات التي يمكنه إرسالها عبر هذا الاتصال بالتوازي). في حالة فقدان حزمة بيانات، فإن التطبيقات الكلاسيكية لبروتوكول TCP (مثل TCP New Reno) تقلل "النافذة" المفتوحة بمقدار النصف. يعتمد نمو نافذة الازدحام وسرعة تعافيها من الخسارة مرة أخرى على التأخير (RTT) للخادم. إذا وصل هذا الاتصال إلى خادم CDN فقط، فسيكون هذا الاسترداد أسرع. وفي الوقت نفسه، يعد فقدان الحزم ظاهرة قياسية، خاصة بالنسبة للشبكات اللاسلكية.
قد ينخفض النطاق الترددي للإنترنت، خاصة خلال ساعات الذروة، بسبب حركة المرور من المستخدمين، مما قد يؤدي إلى ازدحام حركة المرور. ومع ذلك، لا توجد طريقة على الإنترنت لإعطاء الأولوية لبعض الطلبات على غيرها. على سبيل المثال، قم بإعطاء الأولوية للطلبات الصغيرة والحساسة لزمن الوصول على تدفقات البيانات "الثقيلة" التي تقوم بتحميل الشبكة. ومع ذلك، في حالتنا، يتيح لنا وجود شبكتنا الأساسية القيام بذلك على جزء من مسار الطلب - بين CDN والسحابة، ويمكننا تكوينها بالكامل. يمكنك التأكد من إعطاء الأولوية للحزم الصغيرة والحساسة لزمن الوصول، وأن تدفقات البيانات الكبيرة ستتأخر قليلاً. كلما اقتربت شبكة CDN من العميل، زادت الكفاءة.
تؤثر بروتوكولات مستوى التطبيق (OSI المستوى 7) أيضًا على زمن الوصول. تعمل البروتوكولات الجديدة مثل HTTP/2 على تحسين أداء الطلبات المتوازية. ومع ذلك، لدينا عملاء Netflix بأجهزة قديمة لا تدعم البروتوكولات الجديدة. لا يمكن تحديث كافة العملاء أو تكوينهم على النحو الأمثل. في الوقت نفسه، يوجد بين وكيل CDN والسحابة تحكم كامل وقدرة على استخدام البروتوكولات والإعدادات الجديدة المثالية. الجزء غير الفعال مع البروتوكولات القديمة سيعمل فقط بين العميل وخادم CDN. علاوة على ذلك، يمكننا تقديم طلبات تعدد الإرسال على اتصال تم إنشاؤه بالفعل بين CDN والسحابة، مما يحسن استخدام الاتصال على مستوى TCP:
نحن نقيس أو نحسب
على الرغم من أن النظرية تعد بالتحسينات، إلا أننا لا نتعجل على الفور لإطلاق النظام في الإنتاج. وبدلا من ذلك، يجب علينا أولا أن نثبت أن الفكرة سوف تنجح في الممارسة العملية. للقيام بذلك تحتاج إلى الإجابة على عدة أسئلة:
- سرعة: هل سيكون الوكيل أسرع؟
- دقة: هل سينكسر في كثير من الأحيان؟
- التعقيد: كيفية التكامل مع التطبيقات؟
- تكلفة: ما هي تكلفة نشر بنية تحتية إضافية؟
دعونا نفكر بالتفصيل في النهج الذي نتبعه في تقييم النقطة الأولى. ويتم التعامل مع الباقي بطريقة مماثلة.
لتحليل سرعة الطلبات، نريد الحصول على بيانات لجميع المستخدمين، دون قضاء الكثير من الوقت في التطوير ودون انقطاع الإنتاج. هناك عدة طرق لهذا:
- RUM، أو قياس الطلب السلبي. نحن نقيس وقت تنفيذ الطلبات الحالية من المستخدمين ونضمن التغطية الكاملة للمستخدم. العيب هو أن الإشارة ليست مستقرة جدًا بسبب العديد من العوامل، على سبيل المثال، بسبب اختلاف أحجام الطلبات ووقت المعالجة على الخادم والعميل. بالإضافة إلى ذلك، لا يمكنك اختبار تكوين جديد بدون تأثير في الإنتاج.
- اختبارات المعمل. خوادم وبنية تحتية خاصة تحاكي العملاء. بمساعدتهم نقوم بإجراء الاختبارات اللازمة. وبهذه الطريقة نحصل على السيطرة الكاملة على نتائج القياس وإشارة واضحة. ولكن لا توجد تغطية كاملة للأجهزة ومواقع المستخدمين (خاصة مع الخدمة العالمية والدعم لآلاف طرازات الأجهزة).
كيف يمكنك الجمع بين مزايا كلتا الطريقتين؟
لقد وجد فريقنا الحل. لقد كتبنا جزءًا صغيرًا من التعليمات البرمجية - عينة - والتي قمنا بدمجها في تطبيقنا. تسمح لنا المجسات بإجراء اختبارات الشبكة التي يتم التحكم فيها بالكامل من أجهزتنا. يعمل مثل هذا:
- بعد وقت قصير من تحميل التطبيق وإكمال النشاط الأولي، نقوم بتشغيل تحقيقاتنا.
- يقدم العميل طلبًا إلى الخادم ويتلقى "وصفة" للاختبار. الوصفة عبارة عن قائمة بعناوين URL التي يجب تقديم طلب HTTP (طلبات) إليها. بالإضافة إلى ذلك، تقوم الوصفة بتكوين معلمات الطلب: التأخير بين الطلبات، وكمية البيانات المطلوبة، ورؤوس HTTP(s)، وما إلى ذلك. وفي الوقت نفسه، يمكننا اختبار العديد من الوصفات المختلفة بالتوازي - عند طلب التكوين، نحدد بشكل عشوائي الوصفة التي سيتم إصدارها.
- يتم تحديد وقت إطلاق المسبار بحيث لا يتعارض مع الاستخدام النشط لموارد الشبكة على العميل. بشكل أساسي، يتم تحديد الوقت عندما لا يكون العميل نشطًا.
- بعد تلقي الوصفة، يقوم العميل بتقديم طلبات لكل عنوان من عناوين URL بالتوازي. يمكن تكرار الطلب لكل عنوان - ما يسمى. "نبضات". في النبضة الأولى، نقيس المدة التي يستغرقها إنشاء الاتصال وتنزيل البيانات. في النبضة الثانية، نقيس الوقت المستغرق لتحميل البيانات عبر اتصال تم إنشاؤه بالفعل. قبل الثالث، يمكننا ضبط التأخير وقياس سرعة إنشاء إعادة الاتصال، وما إلى ذلك.
نقوم أثناء الاختبار بقياس جميع المعلمات التي يمكن للجهاز الحصول عليها:
- وقت طلب DNS؛
- وقت إعداد اتصال TCP؛
- وقت إعداد اتصال TLS؛
- وقت استلام البايت الأول من البيانات؛
- إجمالي وقت التحميل
- كود نتيجة الحالة
- بعد اكتمال جميع النبضات، تقوم العينة بتحميل جميع القياسات للتحليل.
النقاط الرئيسية هي الحد الأدنى من الاعتماد على المنطق على العميل، ومعالجة البيانات على الخادم وقياس الطلبات المتوازية. وبالتالي، نحن قادرون على عزل واختبار تأثير العوامل المختلفة التي تؤثر على أداء الاستعلام، وتنويعها ضمن وصفة واحدة، والحصول على نتائج من عملاء حقيقيين.
لقد أثبتت هذه البنية الأساسية أنها مفيدة لأكثر من مجرد تحليل أداء الاستعلام. لدينا حاليًا 14 وصفة نشطة، أكثر من 6000 عينة في الثانية، نستقبل البيانات من جميع أنحاء الأرض وتغطية كاملة للجهاز. وإذا اشترت نتفليكس خدمة مماثلة من طرف ثالث، فإنها ستكلف ملايين الدولارات سنويا، مع تغطية أسوأ بكثير.
نظرية الاختبار في الممارسة العملية: النموذج الأولي
باستخدام مثل هذا النظام، تمكنا من تقييم فعالية وكلاء CDN عند زمن استجابة الطلب. الآن أنت بحاجة إلى:
- إنشاء نموذج أولي للوكيل؛
- وضع النموذج الأولي على CDN؛
- تحديد كيفية توجيه العملاء إلى وكيل على خادم CDN محدد؛
- قارن الأداء بالطلبات في AWS بدون وكيل.
وتتمثل المهمة في تقييم فعالية الحل المقترح في أسرع وقت ممكن. لقد اخترنا Go لتنفيذ النموذج الأولي نظرًا لتوفر مكتبات شبكات جيدة. على كل خادم CDN، قمنا بتثبيت النموذج الأولي للوكيل باعتباره ثنائيًا ثابتًا لتقليل التبعيات وتبسيط التكامل. في التنفيذ الأولي، استخدمنا المكونات القياسية قدر الإمكان وتعديلات طفيفة لتجميع اتصالات HTTP/2 وطلب تعدد الإرسال.
لتحقيق التوازن بين مناطق AWS، استخدمنا قاعدة بيانات DNS الجغرافية، وهي نفسها المستخدمة لتحقيق التوازن بين العملاء. لتحديد خادم CDN للعميل، نستخدم TCP Anycast للخوادم في Internet Exchange (IX). في هذا الخيار، نستخدم عنوان IP واحدًا لجميع خوادم CDN، وسيتم توجيه العميل إلى خادم CDN بأقل عدد من قفزات IP. في خوادم CDN المثبتة بواسطة مزودي الإنترنت (ISP)، ليس لدينا سيطرة على جهاز التوجيه لتكوين TCP Anycast، لذلك نستخدم ، والذي يوجه العملاء إلى موفري خدمة الإنترنت لبث الفيديو.
لذا، لدينا ثلاثة أنواع من مسارات الطلب: إلى السحابة عبر الإنترنت المفتوح، أو عبر خادم CDN في IX، أو عبر خادم CDN الموجود لدى مزود خدمة الإنترنت. هدفنا هو فهم الطريقة الأفضل، وما هي فائدة الوكيل مقارنة بكيفية إرسال الطلبات إلى الإنتاج. وللقيام بذلك، نستخدم نظام أخذ العينات على النحو التالي:
يصبح كل مسار هدفًا منفصلاً، وننظر إلى الوقت الذي حصلنا عليه. للتحليل، نقوم بدمج نتائج الوكيل في مجموعة واحدة (اختر أفضل وقت بين وكلاء IX و ISP)، ومقارنتها بوقت الطلبات إلى السحابة بدون وكيل:
كما ترون، كانت النتائج مختلطة - في معظم الحالات، يوفر الوكيل سرعة جيدة، ولكن هناك أيضًا عدد كافٍ من العملاء الذين سيتفاقم الوضع بالنسبة لهم بشكل كبير.
ونتيجة لذلك، قمنا بعدة أشياء مهمة:
- قمنا بتقييم الأداء المتوقع للطلبات المقدمة من العملاء إلى السحابة عبر وكيل CDN.
- لقد تلقينا بيانات من عملاء حقيقيين، من جميع أنواع الأجهزة.
- لقد أدركنا أن النظرية لم يتم تأكيدها بنسبة 100% وأن العرض الأولي باستخدام وكيل CDN لن يناسبنا.
- لم نتحمل المخاطر - ولم نغير تكوينات الإنتاج للعملاء.
- لم يتم كسر أي شيء.
النموذج 2.0
لذا، عد إلى لوحة الرسم وكرر العملية مرة أخرى.
الفكرة هي أنه بدلاً من استخدام وكيل 100%، سنحدد المسار الأسرع لكل عميل، وسنرسل الطلبات هناك - أي أننا سنفعل ما يسمى بتوجيه العميل.
كيفية تنفيذ هذا؟ لا يمكننا استخدام المنطق من جانب الخادم، لأن... الهدف هو الاتصال بهذا الخادم. يجب أن تكون هناك طريقة ما للقيام بذلك على العميل. ومن الناحية المثالية، قم بذلك مع الحد الأدنى من المنطق المعقد، حتى لا تحل مشكلة التكامل مع عدد كبير من منصات العملاء.
الجواب هو استخدام DNS. في حالتنا، لدينا البنية التحتية لنظام أسماء النطاقات (DNS) الخاصة بنا، ويمكننا إنشاء منطقة نطاق تكون خوادمنا فيها استبدادية. يعمل مثل هذا:
- يقدم العميل طلبًا إلى خادم DNS باستخدام مضيف، على سبيل المثال api.netflix.xom.
- يصل الطلب إلى خادم DNS الخاص بنا
- يعرف خادم DNS المسار الأسرع لهذا العميل ويصدر عنوان IP المقابل.
يحتوي الحل على تعقيد إضافي: لا يرى موفرو DNS الاستبداديون عنوان IP الخاص بالعميل ويمكنهم فقط قراءة عنوان IP الخاص بالمحلل العودي الذي يستخدمه العميل.
ونتيجة لذلك، يجب على المحلل الاستبدادي الخاص بنا أن يتخذ قرارًا ليس لعميل فردي، ولكن لمجموعة من العملاء بناءً على المحلل التكراري.
لحل هذه المشكلة، نستخدم نفس العينات، ونجمع نتائج القياس من العملاء لكل من وحدات الحل المتكررة ونقرر مكان إرسال هذه المجموعة منهم - وكيل من خلال IX باستخدام TCP Anycast، أو من خلال وكيل ISP، أو مباشرة إلى السحابة.
نحصل على النظام التالي:
يتيح لك نموذج توجيه DNS الناتج توجيه العملاء بناءً على الملاحظات التاريخية لسرعة الاتصالات من العملاء إلى السحابة.
ومرة أخرى، السؤال هو ما مدى فعالية هذا النهج؟ للإجابة، نستخدم نظام التحقيق الخاص بنا مرة أخرى. لذلك، نقوم بتكوين تكوين المقدم، حيث يتبع أحد الأهداف الاتجاه من توجيه DNS، ويذهب الآخر مباشرة إلى السحابة (الإنتاج الحالي).
ونتيجة لذلك، نقوم بمقارنة النتائج والحصول على تقييم للفعالية:
ونتيجة لذلك تعلمنا عدة أشياء مهمة:
- قمنا بتقييم الأداء المتوقع للطلبات المقدمة من العملاء إلى السحابة باستخدام توجيه DNS.
- لقد تلقينا بيانات من عملاء حقيقيين، من جميع أنواع الأجهزة.
- وقد تم إثبات فعالية الفكرة المقترحة.
- لم نتحمل المخاطر - ولم نغير تكوينات الإنتاج للعملاء.
- لم يتم كسر أي شيء.
الآن عن الجزء الصعب - نطلقه في الإنتاج
لقد انتهى الآن الجزء السهل - هناك نموذج أولي عملي. يتمثل الجزء الأصعب الآن في إطلاق حل لجميع حركة مرور Netflix، ونشره إلى 150 مليون مستخدم، وآلاف الأجهزة، ومئات الخدمات الصغيرة، ومنتج وبنية تحتية دائمة التغير. تتلقى خوادم Netflix ملايين الطلبات في الثانية، ومن السهل قطع الخدمة بإجراءات غير مبالية. في الوقت نفسه، نريد توجيه حركة المرور ديناميكيًا عبر الآلاف من خوادم CDN على الإنترنت، حيث يتغير شيء ما وينقطع باستمرار وفي أكثر اللحظات غير المناسبة.
ومع كل هذا، يضم الفريق 3 مهندسين مسؤولين عن التطوير والنشر والدعم الكامل للنظام.
لذلك سنواصل الحديث عن النوم المريح والصحي.
كيف تستمر في التطوير ولا تقضي كل وقتك في الدعم؟ يعتمد نهجنا على 3 مبادئ:
- نحن نقوم بتقليل الحجم المحتمل للأعطال (نصف قطر الانفجار).
- نحن نستعد للمفاجآت - نتوقع أن ينكسر شيء ما، على الرغم من الاختبارات والتجربة الشخصية.
- التدهور اللطيف - إذا لم يعمل شيء ما بشكل صحيح، فيجب إصلاحه تلقائيًا، حتى لو لم يكن بالطريقة الأكثر كفاءة.
اتضح أنه في حالتنا، مع هذا النهج للمشكلة، يمكننا إيجاد حل بسيط وفعال وتبسيط دعم النظام بشكل كبير. لقد أدركنا أنه يمكننا إضافة جزء صغير من التعليمات البرمجية إلى العميل ومراقبة أخطاء طلب الشبكة الناتجة عن مشكلات الاتصال. في حالة حدوث أخطاء في الشبكة، نقوم بالرجوع مباشرةً إلى السحابة. لا يتطلب هذا الحل جهدًا كبيرًا من فرق العملاء، ولكنه يقلل بشكل كبير من مخاطر الأعطال والمفاجآت غير المتوقعة بالنسبة لنا.
بالطبع، على الرغم من التراجع، إلا أننا نتبع نظامًا واضحًا أثناء التطوير:
- اختبار بسيط.
- اختبار A/B أو جزر الكناري.
- الطرح التدريجي.
مع العينات، تم وصف النهج - يتم اختبار التغييرات أولاً باستخدام وصفة مخصصة.
بالنسبة لاختبار الكناري، نحتاج إلى الحصول على أزواج مماثلة من الخوادم التي يمكننا من خلالها مقارنة كيفية عمل النظام قبل التغييرات وبعدها. للقيام بذلك، من بين مواقع CDN العديدة لدينا، نختار أزواجًا من الخوادم التي تستقبل حركة مرور مماثلة:
ثم نقوم بتثبيت الإصدار مع التغييرات على خادم Canary. لتقييم النتائج، نقوم بتشغيل نظام يقارن ما يقرب من 100-150 مقياسًا مع عينة من خوادم التحكم:
إذا نجح اختبار الكناري، فإننا نطلقه تدريجيًا على شكل موجات. نحن لا نقوم بتحديث الخوادم على كل موقع في نفس الوقت - ففقدان الموقع بأكمله بسبب المشكلات له تأثير أكبر على الخدمة للمستخدمين من فقدان نفس العدد من الخوادم في مواقع مختلفة.
بشكل عام، تعتمد فعالية وسلامة هذا النهج على كمية ونوعية المقاييس التي تم جمعها. بالنسبة لنظام تسريع الاستعلام الخاص بنا، نقوم بجمع المقاييس من جميع المكونات الممكنة:
- من العملاء - عدد الجلسات والطلبات ومعدلات التراجع؛
- الوكيل - إحصائيات حول عدد الطلبات ووقتها؛
- DNS - عدد الطلبات ونتائجها؛
- حافة السحابة - رقم ووقت معالجة الطلبات في السحابة.
يتم جمع كل هذا في مسار واحد، وبناءً على الاحتياجات، نقرر أي المقاييس سنرسلها إلى التحليلات في الوقت الفعلي، وأيها إلى Elasticsearch أو Big Data للحصول على تشخيصات أكثر تفصيلاً.
نحن نراقب
في حالتنا، نقوم بإجراء تغييرات على المسار الحرج للطلبات بين العميل والخادم. وفي الوقت نفسه، فإن عدد المكونات المختلفة الموجودة على العميل والخادم وعلى الطريق عبر الإنترنت هائل. تحدث التغييرات على العميل والخادم باستمرار - أثناء عمل عشرات الفرق والتغيرات الطبيعية في النظام البيئي. نحن في المنتصف - عند تشخيص المشكلات، هناك فرصة جيدة لأن نشارك. لذلك، نحتاج إلى أن نفهم بوضوح كيفية تحديد المقاييس وجمعها وتحليلها لعزل المشكلات بسرعة.
ومن الناحية المثالية، الوصول الكامل إلى جميع أنواع المقاييس والمرشحات في الوقت الحقيقي. ولكن هناك الكثير من المقاييس، وبالتالي فإن مسألة التكلفة تطرح. في حالتنا، نقوم بفصل المقاييس وأدوات التطوير على النحو التالي:
لاكتشاف المشكلات وفرزها، نستخدم نظام الوقت الفعلي مفتوح المصدر الخاص بنا и - للتصور. يقوم بتخزين المقاييس المجمعة في الذاكرة، وهو موثوق به ويتكامل مع نظام التنبيه. للتوطين والتشخيص، لدينا إمكانية الوصول إلى السجلات من Elasticsearch وKibana. للتحليل الإحصائي والنمذجة، نستخدم البيانات الضخمة والتصور في Tableau.
يبدو أن هذا النهج صعب للغاية للعمل معه. ومع ذلك، من خلال تنظيم المقاييس والأدوات بشكل هرمي، يمكننا تحليل المشكلة بسرعة، وتحديد نوع المشكلة، ثم الانتقال إلى المقاييس التفصيلية. بشكل عام، نقضي حوالي 1-2 دقيقة للتعرف على مصدر العطل. بعد ذلك، نعمل مع فريق محدد على التشخيص - من عشرات الدقائق إلى عدة ساعات.
حتى لو تم التشخيص بسرعة، فإننا لا نريد أن يحدث هذا كثيرًا. ومن الناحية المثالية، لن نتلقى تنبيهًا بالغ الأهمية إلا عندما يكون هناك تأثير كبير على الخدمة. بالنسبة لنظام تسريع الاستعلام الخاص بنا، لدينا تنبيهان فقط لإعلامك:
- النسبة المئوية للعميل الاحتياطي - تقييم سلوك العميل؛
- النسبة المئوية لأخطاء التحقيق - بيانات استقرار مكونات الشبكة.
تراقب هذه التنبيهات الهامة ما إذا كان النظام يعمل لصالح غالبية المستخدمين. نحن ننظر إلى عدد العملاء الذين استخدموا الإجراء الاحتياطي إذا لم يتمكنوا من الحصول على تسريع الطلب. لدينا في المتوسط أقل من تنبيه بالغ الأهمية واحد في الأسبوع، على الرغم من وجود الكثير من التغييرات الجارية في النظام. لماذا هذا يكفي بالنسبة لنا؟
- هناك بديل للعميل إذا لم يعمل الوكيل الخاص بنا.
- يوجد نظام توجيه أوتوماتيكي يستجيب للمشاكل.
مزيد من التفاصيل حول هذا الأخير. يتيح لنا نظامنا التجريبي ونظام التحديد التلقائي للمسار الأمثل للطلبات من العميل إلى السحابة التعامل تلقائيًا مع بعض المشكلات.
دعنا نعود إلى نموذج التكوين وفئات المسار الثلاث. بالإضافة إلى وقت التحميل، يمكننا أن ننظر إلى حقيقة التسليم نفسه. إذا لم يكن من الممكن تحميل البيانات، فمن خلال النظر إلى النتائج عبر مسارات مختلفة، يمكننا تحديد مكان العطل وما الذي حدث، وما إذا كان بإمكاننا إصلاحه تلقائيًا عن طريق تغيير مسار الطلب.
الأمثلة على ذلك:
يمكن أتمتة هذه العملية. قم بإدراجه في نظام التوجيه. وتعليمه الاستجابة لمشاكل الأداء والموثوقية. إذا بدأ شيء ما في الانهيار، قم بالرد إذا كان هناك خيار أفضل. في الوقت نفسه، رد الفعل الفوري ليس بالغ الأهمية، وذلك بفضل التراجع عن العملاء.
وبالتالي يمكن صياغة مبادئ دعم النظام على النحو التالي:
- تقليل حجم الأعطال.
- جمع المقاييس؛
- نقوم بإصلاح الأعطال تلقائيًا إذا استطعنا؛
- إذا لم يكن الأمر كذلك، فإننا نخطرك؛
- نحن نعمل على لوحات المعلومات ومجموعة أدوات الفرز للاستجابة السريعة.
الدروس المستفادة
لا يستغرق الأمر الكثير من الوقت لكتابة نموذج أولي. وفي حالتنا، كان جاهزًا بعد 4 أشهر. بفضلها حصلنا على مقاييس جديدة، وبعد 10 أشهر من بدء التطوير، تلقينا أول حركة إنتاج. ثم بدأ العمل الشاق والصعب للغاية: إنتاج النظام وتوسيع نطاقه تدريجيًا، وترحيل حركة المرور الرئيسية والتعلم من الأخطاء. ومع ذلك، فإن هذه العملية الفعالة لن تكون خطية، فعلى الرغم من كل الجهود المبذولة، لا يمكن التنبؤ بكل شيء. يعد تكرار البيانات الجديدة والاستجابة لها بسرعة أكثر فعالية.
بناءً على تجربتنا، يمكننا أن نوصي بما يلي:
- لا تثق بحدسك.
لقد خذلنا حدسنا باستمرار، على الرغم من الخبرة الواسعة لأعضاء فريقنا. على سبيل المثال، توقعنا بشكل غير صحيح التسريع المتوقع من استخدام وكيل CDN، أو سلوك TCP Anycast.
- الحصول على البيانات من الإنتاج.
من المهم الوصول إلى كمية صغيرة على الأقل من بيانات الإنتاج في أسرع وقت ممكن. يكاد يكون من المستحيل الحصول على عدد الحالات والتكوينات والإعدادات الفريدة في ظروف المختبر. سيسمح لك الوصول السريع إلى النتائج بالتعرف بسرعة على المشكلات المحتملة وأخذها في الاعتبار في بنية النظام.
- لا تتبع نصائح الآخرين ونتائجهم - اجمع بياناتك الخاصة.
اتبع مبادئ جمع البيانات وتحليلها، ولكن لا تقبل بشكل أعمى نتائج وبيانات الآخرين. أنت وحدك من يمكنه معرفة ما يناسب مستخدميك بالضبط. قد تختلف أنظمتك وعملائك بشكل كبير عن الشركات الأخرى. ولحسن الحظ، أصبحت أدوات التحليل متاحة الآن وسهلة الاستخدام. قد لا تكون النتائج التي تحصل عليها هي ما تدعيه Netflix وFacebook وAkamai وغيرها من الشركات. في حالتنا، يختلف أداء TLS أو HTTP2 أو إحصائيات طلبات DNS عن نتائج Facebook وUber وAkamai - لأن لدينا أجهزة وعملاء وتدفقات بيانات مختلفة.
- لا تتبع اتجاهات الموضة دون داعٍ وقم بتقييم الفعالية.
ابدأ بالبساطة. من الأفضل إنشاء نظام عمل بسيط في وقت قصير بدلاً من قضاء وقت طويل في تطوير المكونات التي لا تحتاج إليها. حل المهام والمشكلات المهمة بناءً على قياساتك ونتائجك.
- الاستعداد للتطبيقات الجديدة.
وكما أنه من الصعب التنبؤ بجميع المشاكل، فمن الصعب التنبؤ بالفوائد والتطبيقات مقدما. خذ إشارة من الشركات الناشئة - قدرتها على التكيف مع ظروف العملاء. في حالتك، قد تكتشف مشاكل جديدة وحلولها. في مشروعنا، وضعنا هدفًا لتقليل زمن استجابة الطلب. ومع ذلك، أثناء التحليل والمناقشات، أدركنا أنه يمكننا أيضًا استخدام الخوادم الوكيلة:
- ولموازنة حركة المرور عبر مناطق AWS وتقليل التكاليف؛
- لنموذج استقرار CDN؛
- لتكوين DNS؛
- لتكوين TLS/TCP.
اختتام
لقد وصفت في التقرير كيف تقوم Netflix بحل مشكلة تسريع طلبات الإنترنت بين العملاء والسحابة. كيف نقوم بجمع البيانات باستخدام نظام أخذ العينات عن العملاء، واستخدام البيانات التاريخية المجمعة لتوجيه طلبات الإنتاج من العملاء عبر أسرع مسار على الإنترنت. كيف نستخدم مبادئ بروتوكولات الشبكة والبنية التحتية لـ CDN والشبكة الأساسية وخوادم DNS لتحقيق هذه المهمة.
ومع ذلك، فإن الحل الذي نقدمه هو مجرد مثال لكيفية تطبيقنا لمثل هذا النظام في Netflix. ما نجح بالنسبة لنا. الجزء التطبيقي من تقريري لكم هو مبادئ التطوير والدعم التي نتبعها ونحقق نتائج جيدة.
حلنا للمشكلة قد لا يناسبك. ومع ذلك، تظل النظرية ومبادئ التصميم قائمة، حتى لو لم يكن لديك بنية تحتية لـ CDN خاصة بك، أو إذا كانت تختلف بشكل كبير عن بنيتنا.
تظل أهمية سرعة طلبات العمل مهمة أيضًا. وحتى بالنسبة لخدمة بسيطة، يتعين عليك الاختيار: بين موفري الخدمات السحابية، وموقع الخادم، وموفري CDN وDNS. سيؤثر اختيارك على فعالية استعلامات الإنترنت لعملائك. ومن المهم بالنسبة لك قياس وفهم هذا التأثير.
ابدأ بحلول بسيطة، واهتم بكيفية تغيير المنتج. تعلم أثناء تقدمك وقم بتحسين النظام استنادًا إلى البيانات الواردة من عملائك والبنية الأساسية لديك وأعمالك. فكر في إمكانية حدوث أعطال غير متوقعة أثناء عملية التصميم. وبعد ذلك يمكنك تسريع عملية التطوير وتحسين كفاءة الحلول وتجنب عبء الدعم غير الضروري والنوم بسلام.
هذا العام بتنسيق عبر الإنترنت. يمكنك طرح الأسئلة على أحد آباء DevOps، وهو جون ويليس نفسه!
المصدر: www.habr.com