الخلاصة

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

من بين العلاجات التي أعلنتها AWS بعد عطل Kinesis شراء القدرة بطريقة تبدو معاكسة لشعار التوسع: استخدام آلات أقوى كي يقل عدد الخوادم المطلوبة. في تلك البنية، كان تقليل عدد الجيران يفسح مجالا للعمل.

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

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

من يدل الطلب على بابه؟

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

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

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

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

الإصلاح ينتظر دوره أيضا

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

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

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

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

دخل التسجيل إلى طابور تسجيل الدخول

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

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

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

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

دفع ثمن الحدود

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

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

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

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