🥨 👨🏽‍🎓 🚨 هيوستن لدينا مشكلة. فشل تصميم النظام 🤚🏻 👨🏼‍🏫 🥝

في عام 1970 ، أطلق المهندسون الأمريكيون مركبة الفضاء أبولو 13 إلى القمر. يوجد على متن الطائرة ثلاث بطاريات لخلايا الوقود ، لا يوجد شيء يدعو للقلق ، كل شيء موثوق ومكرر بشكل متكرر. ولكن لا يمكن لأحد أن يتصور أن انفجار أسطوانة الأكسجين سيعطل بطاريتين من ثلاث بطاريات. مأساة! عاد رواد الفضاء إلى المنزل ، وتم إنتاج فيلم روائي طويل عن الحدث مع توم هانكس ، وعبارة رائد الفضاء جاك سويغرت: "هيوستن ، لدينا مشكلة!" ، ذهب في التاريخ.

قصة Apollo 13 هي دليل آخر على الحقيقة المعروفة أنه لا يمكنك الاستعداد لجميع المشاكل المحتملة. هذه خاصية طبيعية للعالم: يتم كسر الحديد بشكل دوري ، وتعطل الرمز ، والناس يرتكبون الأخطاء. من المستحيل القضاء على هذا تماما.

بالنسبة للأنظمة الموزعة الكبيرة ، يعد هذا السلوك طبيعيًا ، وهو نتيجة لاقتصاديات الحجم والإحصاءات. هذا هو السبب في أن Design for Failure (AWS) هو مبدأ التصميم الأساسي لخدمات السحابة AWS. تم بناء الأنظمة في البداية بطريقة تستعيد التشغيل بدوام كامل بأسرع ما يمكن وتقليل الضرر الناتج عن الأعطال المعروفة وغير المعروفة. في HighLoad ++ ، أظهر Vasily Pantyukhin ، باستخدام مشاكل واقعية مع الخدمات القتالية كمثال ، أنماط تصميم للأنظمة الموزعة التي يستخدمها مطورو AWS.

فاسيلي بانتيوكين (دجاجة) هو مهندس خدمات أمازون ويب في أوروبا والشرق الأوسط وأفريقيا. بدأ كمسؤول في Unix ، وعمل في Sun Microsystem لمدة 6 سنوات ، ودرّس الدورات التقنية ، ودرّس لمدة 11 عامًا مركزية البيانات في العالم في EMC. في فريق دولي ، قام بتصميم وتنفيذ مشاريع من كيب تاون إلى أوسلو. الآن يساعد الشركات الكبيرة والصغيرة للعمل في السحب العامة.

في عام 1949 ، تم التحقيق في حادث طائرة في قاعدة جوية بكاليفورنيا. أحد المهندسين الذين فعلوا ذلك كان إدوارد ميرفي. ووصف عمل الفنيين المحليين على النحو التالي: "إذا كانت هناك طريقتان للقيام بشيء وأحدهما يؤدي إلى كارثة ، فسيختار أحدهم هذه الطريقة".

في وقت لاحق ، بفضل آرثر بلوخ ، تم تسجيل البيان في التاريخ كواحد من قوانين مورفي. في روسيا - قانون اللؤم. جوهرها هو أنه لن يكون من الممكن تجنب الأعطال والأخطاء البشرية ، ويجب أن تتعايش معها بطريقة أو بأخرى. لهذا السبب ، عند التصميم ، نضع على الفور أعطال وإخفاقات المكونات الفردية في أنظمتنا.

تصميم الفشل

في تصميم الفشل ، نحاول تحسين ثلاث خصائص:

إمكانية الوصول (نفس "التسعة") ؛
الموثوقية - خاصية النظام لتوفير المستوى الضروري من الخدمة ؛
التسامح مع الخطأ - خاصية النظام لمنع حدوث المشاكل والتعافي بسرعة بعدها.

الموثوقية لها خاصية " المجهول المعروف ". نحن نحمي أنفسنا من المشاكل المعروفة ، لكننا لا نعرف متى ستحدث.

" أون المجهولة المعروفة" و أضاف أن خطأ التسامح - وهذه هي المشاكل المفاجئة التي لا نعرف عنها شيئا. ترتبط العديد من هذه المشاكل في السحابة باقتصاديات الحجم: ينمو النظام إلى الحجم عندما تظهر تأثيرات جديدة ومذهلة وغير متوقعة.

الفشل عادة ليس ظاهرة ثنائية. ملكيتها الرئيسية هي "نصف قطر الانفجار" أو مستوى تدهور الخدمة ، نصف قطر التدمير. مهمتنا هي تقليل "نصف قطر الانفجار" للأنظمة.

إذا أدركنا أنه لا يمكن تجنب المشاكل ، فيجب علينا الاستعداد لها بشكل استباقي. وهذا يعني أننا نصمم الخدمات بطريقة تجعلنا نتحكم في المشكلات ، وليس العكس ، في حالة حدوث مشكلات (بالتأكيد ستكون).

عندما نرد على مشكلة ، تسيطر علينا.

مستوى البيانات ومستوى التحكم

بالتأكيد ، لديك إلكترونيات في المنزل يتم التحكم فيها بواسطة جهاز تحكم عن بعد ، مثل جهاز تلفزيون. شاشة التلفزيون هي جزء من مستوى البيانات - الذي يؤدي الوظيفة مباشرة. جهاز التحكم عن بعد هو واجهة المستخدم - مستوى التحكم. يتم استخدامه لإدارة وتكوين الخدمة. في السحابة ، نحاول فصل مستوى البيانات ومستوى التحكم للاختبار والتطوير.

لا يرى المستخدمون ، في أغلب الأحيان ، مدى تعقيد مستوى التحكم. لكن الأخطاء في تصميمها وتنفيذها هي الأسباب الأكثر شيوعًا للإخفاقات الجماعية. هذا هو السبب في أن نصيحتي تركز على مستوى التحكم - في بعض الأحيان بشكل صريح ، وأحيانًا لا.

قصة مشكلة واحدة

في يوليو 2012 ، مرت عاصفة شديدة في ولاية فرجينيا الشمالية. يحتوي مركز البيانات على الحماية ومولدات الديزل والمزيد ، ولكن حدث ذلك أنه في أحد مراكز البيانات في إحدى مناطق التوافر (منطقة التوافر ، من الألف إلى الياء) في منطقة شمال فيرجينيا ، تم فقد الطاقة. تمت استعادة الكهرباء بسرعة ، لكن استعادة الخدمات استمرت لساعات.

سأخبرك عن الأسباب على سبيل المثال لأحد الخدمات الأساسية - CLB (Classic Load Balancer). إنه يعمل ببساطة: عندما تبدأ موازنًا جديدًا في كل منطقة توفر ، يتم إنشاء مثيلات منفصلة ، سيحل IP الخاص بها DNS.

عند فشل أحد المثيلات ، يتم إرسال رسالة حول هذا إلى قاعدة بيانات خاصة.

واستجابة لذلك ، تبدأ الإجراءات: حذف السجلات من DNS ، وبدء مثيل جديد وإضافة IP جديد إلى DNS.

ملاحظة: هذه هي الطريقة التي عمل بها النظام في الماضي ، والآن أصبح كل شيء مختلفًا بشكل أساسي.

كل شيء بسيط - لا يوجد شيء للكسر. ولكن خلال فشل جماعي ، عندما تنهار آلاف الحالات في نفس الوقت ، يظهر تراكم ضخم في قاعدة البيانات من الرسائل للمعالجة.

لكنها ساءت. مستوى التحكم هو نظام موزع. نظرًا لوجود خطأ ، تلقينا تكرارات وتضخم الآلاف من السجلات في قاعدة البيانات حتى مئات الآلاف. أصبح من الصعب للغاية العمل مع هذا.

عندما يحدث فشل في إحدى الحالات ، تتحول جميع حركة المرور إلى الأجهزة الباقية على الفور تقريبًا ويتضاعف الحمل (في المثال ، للبساطة ، هناك منطقتان فقط للوصول).

لا توجد موارد كافية ، يبدأ مثيل مباشر في التوسع تلقائيًا. تستغرق العملية وقتًا طويلاً نسبيًا. كل شيء يحدث في وقت الذروة وفي نفس الوقت مع عدد كبير من الحالات - الموارد المجانية لمنطقة التوافر تنفد. يبدأ "الكفاح" من أجل الموارد.

في شمال فيرجينيا ، فشلت الأتمتة في التعامل مع الفشل الهائل ، واستعاد المهندسون يدويًا (باستخدام البرامج النصية) الخدمات للعمل. مثل هذه المشاكل نادرة. خلال الاستجواب ، أثيرت أسئلة حول أسباب الفشل ، وقرروا أن الوضع لم يعد يجب أن يتكرر ويجب تغيير الخدمة بأكملها.

الأنماط الثمانية التي سأغطيها هي إجابات على بعض الأسئلة.

ملحوظة. هذه هي تجربتنا في تصميم الخدمة ، وليس الحكمة العالمية للاستخدام على نطاق واسع. يتم استخدام الأنماط في حالات محددة.

— . AWS . — , . . — . !

لتقليل تأثير الفشل ، الكثير من النهج. أحدها هو الإجابة على السؤال التالي: "كيف يمكنني التأكد من أن المستخدمين الذين لا يعرفون مشكلة ما لا يعرفون شيئًا عنها أثناء الفشل وأثناء الاسترداد؟"

لا تتلقى رسائلك الضخمة لدينا رسائل تعطل فحسب ، بل أيضًا رسائل أخرى ، على سبيل المثال ، حول التحجيم أو أن شخصًا ما يطلق موازنًا جديدًا. يجب عزل هذه الرسائل عن بعضها البعض ، وتجميعها وظيفياً: مجموعة منفصلة من رسائل الاسترداد بعد الفشل ، وإطلاق موازن جديد بشكل منفصل.

لنفترض أن عشرة مستخدمين لاحظوا مشكلة - سقطت إحدى عُقد موازناتهم. تعمل الخدمات بطريقة ما على الموارد المتبقية ، ولكن يتم الشعور بالمشكلة.

لدينا عشرة مستخدمين محبطين. يظهر الحادي عشر - لا يعرف أي شيء عن المشكلة ، ولكنه ببساطة يريد موازنًا جديدًا. إذا كان طلبه بوضع قائمة الانتظار للمعالجة ، فمن المرجح أنه لن ينتظر. بينما تكتمل إجراءات المعالجة الأخرى ، سينتهي وقت الطلب. بدلاً من عشرة مستخدمين محبطين ، سيكون لدينا أحد عشر.

لمنع حدوث ذلك ، نعطي الأولوية لبعض الطلبات - نضع قوائم الانتظار في الجزء العلوي ، على سبيل المثال ، طلبات الموارد الجديدة. مع حدوث فشل كبير ، لن يؤثر عدد صغير نسبيًا من هذه الطلبات على وقت الاسترداد لموارد العملاء الآخرين. ولكن في عملية الاسترداد ، سنقيّد عدد المستخدمين المشاركين في المشكلة.

وظيفة بدوام كامل

الاستجابة لتقارير المشاكل هي إطلاق إجراءات الاسترداد ، على وجه الخصوص ، العمل مع DNS. الفشل الجماعي هو أحمال ذروة ضخمة على مستوى التحكم. يساعد النمط الثاني طائرة التحكم على أن تكون أكثر استقرارًا ويمكن التنبؤ بها في مثل هذه الحالة.

نستخدم نهجًا يسمى العمل المستمر - العمل الدائم .

على سبيل المثال ، يمكن جعل نظام أسماء النطاقات أكثر ذكاءً قليلاً: سيتحقق باستمرار من مثيلات الموازن ، سواء كانت حية أم لا. ستكون النتيجة صورة نقطية في كل مرة: يستجيب المثيل - 1 ، ميت - 0.

يتحقق DNS من المثيلات كل بضع ثوان ، بغض النظر عما إذا كان النظام قد تم استعادته بعد فشل جماعي أو يعمل بشكل طبيعي. يقوم بنفس العمل - لا قمم ، كل شيء يمكن التنبؤ به ومستقر.

مثال مبسط آخر: نريد تغيير التكوين على أسطول كبير. في مصطلحاتنا ، الأسطول هو مجموعة من الأجهزة الافتراضية التي تقوم ببعض العمل معًا.

نضع تغييرات التكوين في مجموعة S3 ، وكل 10 ثوانٍ (على سبيل المثال) ندفع كل هذا التكوين إلى أسطولنا من الأجهزة الافتراضية. نقطتان مهمتان.

نفعل ذلك بانتظام ولا نكسر القاعدة أبدًا. إذا اخترت مقطعًا مدته 10 ثوانٍ ، فاضغط بهذه الطريقة فقط ، بغض النظر عن الموقف.
نعطي دائمًا التكوين بالكامل ، بغض النظر عما إذا كان قد تغير أم لا. تحدد مستوى البيانات (الأجهزة الافتراضية) نفسها ماذا تفعل به. نحن لا ندفع الدلتا. يمكن أن تصبح كبيرة جدًا مع حدوث اضطرابات أو تغييرات كبيرة. من المحتمل أن يساهم ذلك في عدم الاستقرار وعدم القدرة على التنبؤ.

عندما نؤدي نوعًا من العمل الدائم ، ندفع المزيد مقابل ذلك. على سبيل المثال ، تطلب 100 آلة افتراضية تكوينًا كل ثانية. يكلف حوالي 1200 دولار في السنة. هذا المبلغ هو في الأساس أقل من راتب المبرمج ، الذي يمكننا أن نعهد إليه بتطوير مستوى التحكم بنهج كلاسيكي - رد فعل على الفشل وتوزيع تغييرات التكوين فقط.

إذا قمت بتغيير التكوين كل بضع ثوانٍ ، كما في المثال ، فإن هذا بطيء. ولكن في كثير من الحالات ، يستغرق تغيير التكوين أو إطلاق الخدمات دقائق - لا تحل بضع ثوان أي شيء.

الثواني مهمة للخدمات التي يجب أن يتغير فيها التكوين على الفور ، على سبيل المثال ، عند تغيير إعدادات VPC. هنا لا ينطبق "العمل الدائم". هذا مجرد نمط وليس قاعدة. إذا لم يفلح ذلك في قضيتك ، فلا تستخدمها.

التحجيم الأولي

في مثالنا ، عندما يتعطل مثيل الموازن ، يتلقى المثال الثاني الباقي الحمل مضاعفًا على الفور تقريبًا ويبدأ في التوسع. في فشل هائل ، يأكل كمية هائلة من الموارد. يساعد النمط الثالث على التحكم في هذه العملية - للتوسع مسبقًا .

في حالة منطقتين للتوافر ، نقيس عند التخلص من أقل من 50٪.

إذا تم عمل كل شيء مقدمًا ، في حالة الفشل ، تكون الحالات المتبقية من الموازن جاهزة لقبول حركة المرور المضاعفة.

في السابق ، قمنا بقياس الاستخدام العالي فقط ، على سبيل المثال ، 80٪ والآن 45٪. النظام خاملاً معظم الوقت ويصبح أكثر تكلفة. لكننا مستعدون لتحمل هذا واستخدام النمط بنشاط ، لأن هذا هو التأمين. يجب عليك دفع رسوم التأمين ، ولكن في حالة وجود مشكلة خطيرة ، فإن الفوز يغطي جميع النفقات. إذا قررت استخدام النمط ، احسب جميع المخاطر والسعر مقدمًا.

العمارة الخلوية

هناك طريقتان لبناء وخدمات تحجيم: متراصة و هيكل العسل (خلية القاعدة). يتطور

المونوليث وينمو كحاوية كبيرة واحدة. نضيف موارد ، يتضخم النظام ، ونواجه حدودًا مختلفة ، وتصبح الخصائص الخطية غير خطية وتصبح مشبعة ، و "نصف قطر الانفجار" للنظام - النظام بأكمله.

إذا تم اختبار المونوليث بشكل سيئ ، فإنه يزيد من احتمال حدوث مفاجآت - "مجهول غير معروف". لكن لا يمكن اختبار كتلة متجانسة بالكامل. في بعض الأحيان ، سيكون عليك بناء منطقة وصول منفصلة ، على سبيل المثال ، لخدمة شعبية يتم بناؤها على أنها متراصة داخل منطقة الوصول (هذا هو الكثير من مراكز البيانات). بالإضافة إلى إنشاء عبء اختبار ضخم بطريقة أو بأخرى يشبه الحاضر ، فهذا مستحيل من وجهة نظر مالية.

لذلك ، في معظم الحالات ، نستخدم بنية خلوية - تكوين يتم فيه بناء نظام من خلايا ذات حجم ثابت. بإضافة الخلايا ، نقوم بتوسيعها.

تحظى البنية الخلوية بشعبية في سحابة AWS. يساعد على عزل مواطن الخلل وتقليل نصف قطر الانفجار.لخلية واحدة أو أكثر. يمكننا اختبار الخلايا متوسطة الحجم بالكامل ، وهذا يقلل بشكل خطير من المخاطر.

يتم استخدام نهج مماثل في بناء السفن: يتم تقسيم هيكل السفينة أو السفينة بواسطة أقسام إلى حجرات. في حالة وجود ثقب ، يتم غمر حجرة واحدة أو أكثر ، لكن السفينة لا تغرق. نعم ، لم يساعد ذلك تيتانيك ، لكننا نادرًا ما نواجه مشاكل في جبل الجليد.

سأوضح تطبيق نهج الشبكة باستخدام خدمة الأشكال البسيطة كمثال. هذه ليست خدمة AWS ، جئت بها بنفسي. هذه مجموعة من واجهات برمجة التطبيقات البسيطة للعمل بأشكال هندسية بسيطة. يمكنك إنشاء مثيل لشكل هندسي ، أو طلب نوع الشكل بمعرفه ، أو حساب كل المثيلات من نوع معين. على سبيل المثال ، put(triangle)يتم إنشاء كائن "مثلث" مع بعض المعرف عند الطلب .getShape(id)تُرجع نوع "مثلث" أو "دائرة" أو "معين".

لجعل الخدمة غائمة ، يجب استخدامها من قبل مستخدمين مختلفين في نفس الوقت. دعونا نجعلها متعددة المستأجرين.

بعد ذلك ، تحتاج إلى التوصل إلى طريقة للتقسيم - لفصل الأشكال إلى خلايا. هناك العديد من الخيارات لاختيار مفتاح التقسيم. أبسط واحد في الشكل الهندسي : جميع المعينات في الخلية الأولى ، والدوائر في الثانية ، والمثلثات في الثالثة.

هذه الطريقة لها إيجابيات وسلبيات.

إذا كانت هناك دوائر أقل بشكل ملحوظ من الأشكال الأخرى ، فستبقى الخلية المقابلة غير مستغلة بالكامل (توزيع غير متساوٍ).
بعض طلبات API سهلة التنفيذ. على سبيل المثال ، بعد حساب جميع الكائنات في الخلية الثانية ، نجد عدد الدوائر في النظام.
الاستعلامات الأخرى أكثر تعقيدًا. على سبيل المثال ، للعثور على شكل هندسي حسب الهوية ، عليك المرور عبر جميع الخلايا.

الطريقة الثانية هي استخدام معرف الكائنات حسب النطاقات : أول ألف كائن في الخلية الأولى ، والثانية في الثانية. لذا فإن التوزيع أكثر اتساقا ، ولكن هناك صعوبات أخرى. على سبيل المثال ، لحساب جميع المثلثات ، تحتاج إلى استخدام الطريقة scatter/gather: نوزع الطلبات في كل خلية ، نحسب المثلثات داخلها ، ثم نجمع الإجابات ، ونلخصها وننتج النتيجة.

الطريق الثالث - تقسيم المستأجر(للمستخدمين). هنا نواجه مشكلة كلاسيكية. عادة ما يكون هناك الكثير من المستخدمين "الصغار" في السحابة الذين يجربون شيئًا ما ولا يقومون عمليا بتحميل الخدمة. هناك مستخدمين mastodon. إنها قليلة ، لكنها تستهلك كمية هائلة من الموارد. لن يتناسب هؤلاء المستخدمون أبدًا مع أي خلية. عليك أن تتوصل إلى طرق صعبة لتوزيعها على العديد من الخلايا.

لا توجد طريقة مثالية ، كل خدمة فردية. الخبر السار هو أن الحكمة الدنيوية تعمل هنا - قطع الحطب أكثر ملاءمة على طول الألياف ، بدلاً من قطعها عبرها. في العديد من الخدمات ، تكون هذه "الألياف" أكثر أو أقل وضوحًا. ثم يمكنك تجربة والعثور على مفتاح التقسيم الأمثل.

الخلايا مترابطة (وإن كانت ضعيفة). لذلك ، يجب أن يكون هناك مستوى اتصال. غالبًا ما تسمى طبقة التوجيه أو التعيين. هناك حاجة لفهم الخلايا التي ترسل طلبات معينة إليها. يجب أن يكون هذا المستوى بسيطًا قدر الإمكان. حاول ألا تضع منطق الأعمال فيه.

يطرح السؤال عن حجم الخلايا: صغير - سيئ ، كبير - سيئ أيضًا. لا توجد نصيحة عالمية - قرر حسب الموقف.

في سحابة AWS ، نستخدم الخلايا المنطقية والمادية بأحجام مختلفة. هناك خدمات إقليمية بحجم خلية كبير ، وهناك خدمات المنطقة ، حيث تكون الخلايا أصغر.

ملحوظة. تحدثت عن microcells في Saint Highload ++ Online في أوائل أبريل من هذا العام. لقد ناقشت هناك بالتفصيل مثالاً للاستخدام المحدد لهذا النمط في خدمة Amazon EBS الأساسية.

متعدد المستأجرين

عندما يقوم مستخدم بتشغيل موازن جديد ، فإنه يتلقى مثيلات في كل منطقة توفر. بغض النظر عما إذا تم استخدام الموارد أم لا ، يتم تخصيصها وتنتمي حصريًا إلى هذا المستأجر من السحابة.

بالنسبة لـ AWS ، فإن هذا النهج غير فعال ، لأن استخدام موارد الخدمة في المتوسط منخفض جدًا. هذا يؤثر على التكلفة. بالنسبة لمستخدمي السحابة ، هذا ليس حلاً مرنًا. لا يمكنها التكيف مع الظروف المتغيرة بسرعة ، على سبيل المثال ، لتزويد الموارد بحمل متزايد بشكل غير متوقع في أقصر وقت.

كان CLB أول موازن في سحابة الأمازون. تستخدم الخدمات اليوم نهجًا متعدد المستأجرين ، مثل NLB (Network Load Balancer). أساس "محرك" خدمات الشبكة هذه هو HyperPlane. هذا هو داخلي ، غير مرئي للمستخدمين النهائيين ، أسطول ضخم من الأجهزة الافتراضية (العقد).

مزايا النهج متعدد المستأجرين أو النمط الخامس.

التسامح مع الخطأ أعلى بشكل أساسي . في HyperPlane ، هناك عدد كبير من العقد قيد التشغيل بالفعل وينتظرون التحميل. تعرف العقد حالة بعضها البعض - عندما تفشل بعض الموارد ، يتم توزيع الحمل على الفور بين الموارد المتبقية. حتى أن المستخدمين لا يلاحظون أعطال جماعية.
ذروة حماية الحمل . يعيش المستأجرون حياتهم الخاصة وعادة لا ترتبط أحمالهم مع بعضهم البعض. إجمالي متوسط الحمل على HyperPlane سلس للغاية.
الاستفادة من هذه الخدمات هو أفضل من حيث الأساس . لذلك ، توفير أداء أفضل ، فهي أرخص.

هذا يبدو رائع! لكن النهج المتعدد العوامل له عيوب. في الشكل ، أسطول HyperPlane مع ثلاثة مستأجرين (المعين والدوائر والمثلثات) ، والتي يتم توزيعها عبر جميع العقد .

هذا يثير مشكلة الجوار الصاخبة الكلاسيكية: العمل المدمر للمستأجر ، الذي يولد حركة مرور عالية أو سيئة ، من المحتمل أن يؤثر على جميع المستخدمين.

"نصف قطر الانفجار" في مثل هذا النظام هو كل المستأجرين. احتمالية وجود "جار صاخب" مدمر في منطقة توفر AWS الحقيقية ليست عالية. لكن يجب أن نكون مستعدين دائما للأسوأ. ندافع عن أنفسنا باستخدام نهج شبكة - نختار مجموعات من العقد كخلايا. في هذا السياق ، نسميها شظايا. الخلايا ، والأجزاء ، والأقسام - هنا هي نفسها.

في هذا المثال ، ستؤثر المعين ، باعتباره "جار صاخب" ، على مستأجر واحد فقط - مثلث. لكن المثلث سيكون مؤلمًا جدًا. لتنعيم التأثير ، قم بتطبيق النمط السادس - خلط القطع.

خلط القطع

نوزع المستأجرين بشكل عشوائي على العقد. على سبيل المثال ، يسقط المعين على عقد واحد و 3 و 6 ، ومثلث على 2 و 6 و 8. لدينا 8 عقد وشق من الحجم 3.

هنا تعمل التوافقات البسيطة. مع احتمال 54 ٪ ، سيكون هناك تقاطع واحد فقط بين المستأجرين.

سيؤثر "الجار الصاخب" على مستأجر واحد فقط ، وليس الحمل كله ، ولكن فقط 30 بالمائة.

ضع في اعتبارك تكوينًا قريبًا من 100 عقدة ، حجم الجزء 5. مع احتمال 77٪ ، لن يكون هناك تقاطعات على الإطلاق.

يمكن أن تقلل عملية التقطيع العشوائي بشكل كبير من "نصف قطر الانفجار". يتم استخدام هذا النهج في العديد من خدمات AWS.

"أسطول صغير يتسبب في أسطول كبير وليس العكس"

عند التعافي من فشل شامل ، نقوم بتحديث تكوين العديد من المكونات. السؤال النموذجي في هذه الحالة هو دفع أو تغيير تكوين متغير؟ من هو البادئ بالتغييرات: المصدر الذي يحتوي على تغييرات التكوين أم مستهلكيها؟ لكن هذه الأسئلة خاطئة. السؤال الصحيح هو أي أسطول أكبر؟

ضع في اعتبارك موقفًا بسيطًا: أسطولًا كبيرًا من الأجهزة الظاهرية الأمامية وعددًا معينًا من الخلفيات.

نستخدم نهجًا متشابكًا - ستعمل مجموعات من أمثلة الواجهة الأمامية مع واجهات خلفية معينة. للقيام بذلك ، حدد التوجيه - رسم الخرائط للواجهات الأمامية والواجهات الأمامية التي تعمل معها.

التوجيه الثابت غير مناسب. لا تعمل خوارزميات التجزئة بشكل جيد في حالات الفشل الجماعي ، عندما تحتاج إلى تغيير معظم المسارات بسرعة. لذلك من الأفضل استخدامهالتوجيه الديناميكي . بجانب الأساطيل الكبيرة لمثيلات الواجهة الأمامية والخلفية ، نضع خدمة صغيرة تتعامل فقط مع التوجيه. سوف يعرف ويعين خريطة أمامية وخلفية في أي وقت.

لنفترض أن لدينا تحطم كبير ، سقطت العديد من الأمثلة الأمامية. يبدأون في التعافي بشكل كبير ويطلبون في نفس الوقت تقريبًا تكوين الخرائط من خدمة التوجيه.

يتم قصف خدمة توجيه صغيرة بعدد كبير من الطلبات. لن يتعامل مع الحمل ، في أفضل الأحوال ، سوف يتحلل ، وفي أسوأ الأحوال سيموت.

لذلك ، من الصحيح عدم طلب تغييرات التكوين من خدمة صغيرة ، بل بناء نظامك بحيث "الطفل" نفسهبدأ تغييرات التكوين نحو أسطول كبير من الحالات .

نستخدم نمط العمل المستمر. سترسل خدمة التوجيه الصغيرة التكوين إلى جميع حالات الأسطول الأمامي مرة واحدة كل بضع ثوانٍ. لن يتمكن أبدًا من تحميل خدمة رائعة. النمط السابع يساعد على تحسين الاستقرار والمرونة .

الأنماط السبعة الأولى تعزز النظام. يعمل النمط الأخير بشكل مختلف.

إسقاط الحمل

فيما يلي رسم بياني كلاسيكي للتأخير مقابل الحمل. على الجانب الأيمن من الرسم البياني توجد "الركبة" ، عندما تؤدي الأحمال العالية للغاية حتى الزيادة الصغيرة إلى زيادة كبيرة في الكمون.

في الوضع العادي ، لا نأخذ خدماتنا أبدًا إلى الجانب الأيمن من الجدول. طريقة سهلة للتحكم في ذلك هي إضافة الموارد في الوقت المحدد. لكننا نستعد لأي مشاكل. على سبيل المثال ، يمكننا الانتقال إلى الجانب الأيمن من الرسم البياني للتعافي من فشل جماعي.

نضع مهلة العميل على الرسم البياني. يمكن لأي شخص أن يكون عميلاً ، على سبيل المثال ، مكون آخر داخل خدمتنا. من أجل البساطة ، نقوم برسم مخطط تأخير بنسبة 50 في المائة.

هنا نواجه حالة تسمى البنيوت . قد تكون على دراية بمصطلح التعتيم عند انقطاع الكهرباء في المدينة. يحدث براونوت عندما يعمل شيء ما ، ولكنه سيئ جدًا وبطيء لدرجة أنه لا يعمل على الإطلاق.

دعونا نلقي نظرة على اللون البني في المنطقة البنيّة. تلقت الخدمة طلبًا من العميل ومعالجته وإرجاع النتيجة. ومع ذلك ، في نصف الحالات ، انتهت مهلة العملاء بالفعل ولا أحد ينتظر النتيجة. في النصف الآخر ، تعود النتيجة بشكل أسرع من المهلة ، ولكن في نظام بطيء يستغرق الكثير من الوقت.

واجهنا مشكلة مزدوجة: نحن مثقلون بالفعل ونحن على الجانب الأيمن من الجدول الزمني ، ولكن في نفس الوقت ما زلنا "نقوم بتسخين الهواء" ، ونقوم بالكثير من العمل غير المجدي. كيف تتجنب ذلك؟

ابحث عن "الركبة" - نقطة الانعطاف على الرسم البياني . نقيس أو نقدر نظريا.

إسقاط حركة المرور التي تجبرنا على الذهاب إلى يمين نقطة الانعطاف .

يجب علينا ببساطة تجاهل جزء من الطلبات. نحن لا نحاول حتى معالجتها ، ولكننا نعيد خطأ على الفور إلى العميل. حتى مع التحميل الزائد ، يمكننا تحمل هذه العملية - إنها "رخيصة". لا يتم تلبية الطلبات ، يتم تقليل التوفر العام للخدمة. على الرغم من أن الطلبات المرفوضة ستتم معالجتها عاجلاً أم آجلاً بعد إعادة محاولة أو أكثر من العملاء.

وفي الوقت نفسه ، تتم معالجة جزء آخر من الطلبات بوقت استجابة منخفض مضمون. نتيجة لذلك ، نحن لا نقوم بعمل غير مفيد ، وما نقوم به ، نقوم به بشكل جيد.

ضغط موجز لأنماط تصميم أنظمة الفشل

العزلة والتنظيم . في بعض الأحيان يكون من المنطقي إعطاء الأولوية لأنواع معينة من الاستعلامات. على سبيل المثال ، مع حجم صغير نسبيًا من الطلبات لإنشاء موارد جديدة ، يمكن وضعها في أعلى قائمة الانتظار. من المهم أن هذا لا ينتهك المستخدمين الآخرين. في حالة انقطاع الخدمة بشكل كبير ، لن يشعر المستخدمون الذين ينتظرون استرداد مواردهم باختلاف كبير.

وظيفة بدوام كامل . الحد من تبديل أوضاع الخدمة أو القضاء عليه تمامًا. يعمل وضع واحد ، يعمل بشكل ثابت ومستمر ، بغض النظر عن حالات الطوارئ أو حالات العمل ، على تحسين استقرار مستوى التحكم وإمكانية التنبؤ به بشكل أساسي.

التحجيم الأولي. قم بالقياس مقدمًا بقيم التخلص الأقل. سيكون عليك دفع المزيد مقابل هذا ، ولكن هذا هو التأمين الذي يؤتي ثماره أثناء فشل النظام الخطير.

العمارة الخلوية . يفضل العديد من الخلايا المترابطة بشكل فضفاض على كتلة متجانسة. يقلل نهج الشبكة من "نصف قطر الانفجار" واحتمال حدوث أخطاء مفاجئة.

يعمل النهج متعدد العناصر على تحسين استخدام الخدمة بشكل كبير ، ويقلل من تكلفتها ويقلل من "نصف قطر الانفجار".

خلط القطع . هذا هو النهج الذي ينطبق على الخدمات متعددة المستأجرين. كما يسمح لك بالتحكم في "نصف قطر الانفجار".

"أسطول صغير يتسبب في أسطول كبير وليس العكس". نحن نحاول إنشاء خدمات بحيث تبدأ الخدمات الصغيرة في إجراء تغييرات على التكوينات الكبيرة. غالبًا ما نستخدمه مع نمط الحمل المستمر.

إسقاط الحمل . في حالات الطوارئ ، نحاول القيام بعمل مفيد فقط ، ونقوم به بشكل جيد. للقيام بذلك ، نتخلص من جزء من الحمل ، والذي لا يزال لا يمكننا تحمله.

— , Saint HighLoad++ Online. -- , Q&A-, , . - . , - .

telegram- @HighLoadChannel — , .

هيوستن لدينا مشكلة. فشل تصميم النظام