في هذا المنشور ، نود أن نشارك تفاصيل انقطاع الخدمة الذي حدث في منطقة شمال فيرجينيا (US-EAST-1) في 25 نوفمبر 2020.
تقوم Amazon Kinesis بجمع ومعالجة وتحليل البيانات المتدفقة في الوقت الفعلي. بالإضافة إلى الاستخدام المباشر من قبل العملاء ، فهي تشارك في عدد من خدمات AWS. كما عانت هذه الخدمات من انقطاع. كان الدافع (وليس السبب الرئيسي) لهذا الحدث هو الإضافة الصغيرة نسبيًا للسعة إلى الخدمة ، بدءًا من الساعة 2:44 صباحًا بتوقيت المحيط الهادي وتنتهي في الساعة 3:47 صباحًا.
حول جهاز Kinesis
يستخدم Kinesis عددًا كبيرًا من مجموعات الخلايا (الخلايا) "الخلفية" التي تعالج تدفقات البيانات. هذه هي أحصنة عمل Kinesis. هم مسؤولون عن التوزيع والوصول وتوسيع نطاق البث. يتم توزيع التدفقات بواسطة خوادم الواجهة الأمامية على خوادم خلفية باستخدام التجزئة. تمتلك مجموعة الواجهة الخلفية العديد من الأجزاء وتوفر تحجيمًا متسقًا وعزلًا للأعطال. العمل الأمامي في حالتنا صغير ، لكنه مهم. وهي مسؤولة عن المصادقة ، والاختناق ، وتوجيه الطلبات إلى أجزاء مؤشر الترابط الصحيحة على مجموعات الواجهة الخلفية.
كنا نضيف قدرات جديدة لأسطول الماكينات الأمامية. يشكل كل خادم أمامي ذاكرة تخزين مؤقت للبيانات ، بما في ذلك مالكي العضوية والأجزاء (بين مجموعات النهاية الخلفية) ، مما يشكل ما يسمى بخريطة الأجزاء. يحصل على هذه المعلومات عن طريق إرسال الطلبات إلى الخدمة التي توفر معلومات العضوية واسترداد بيانات التكوين من DynamoDB.
بالإضافة إلى ذلك ، يقوم كل خادم بمعالجة الرسائل باستمرار من خوادم الواجهة الأمامية لـ Kinesis. للقيام بذلك ، يتم إنشاء سلاسل الرسائل في نظام التشغيل لكل جهاز أمامي لكل خادم من خوادم الواجهة الأمامية. عند إضافة سعات جديدة ، تتعرف الخوادم التي تعمل بالفعل في حديقة الواجهة الأمامية على الأعضاء الجدد وتنشئ التدفقات المقابلة. يستغرق كل خادم أمامي موجود ما يصل إلى ساعة للتعرف على الأجهزة الجديدة.
التشخيص وحل المشكلات
في الساعة 5:15 صباحًا بتوقيت المحيط الهادي ، ظهرت رسائل الخطأ الأولى أثناء كتابة واسترجاع سجلات Kinesis. بدأت فرقنا على الفور في دراسة السجلات. ساد الشك فورًا في السعات الجديدة ، لكن بعض الأخطاء لم تكن مرتبطة بأي شكل من الأشكال بالآلات الجديدة ، والأرجح أنها لم تكن لتنتقل إلى أي مكان ، حتى لو أزلنا جميع السعات الجديدة.
ومع ذلك ، وكإجراء احترازي ، بدأنا مع ذلك في حذفها ، على طول الطريق في محاولة لتحديد سبب الأخطاء الأخرى. تنوعها الواسع أدى إلى إبطاء تشخيصنا. لقد رأينا أخطاءً في كل جانب من جميع أنواع المكالمات التي أجراها الأعضاء الحاليون والجدد في أسطول الماكينات الأمامية ، مما جعل من الصعب جدًا فصل الآثار الجانبية عن السبب الجذري.
اعتبارًا من الساعة 7:51 صباحًا بتوقيت المحيط الهادي ، قمنا بتضييق نطاق المشتبه بهم إلى عدد قليل من المرشحين فقط وقررنا أن أيًا من الأسباب المحتملة سيتطلب إعادة تشغيل كاملة للواجهة الأمامية. كان فريق Kinesis يعلم جيدًا أن هذه العملية يجب أن تكون بطيئة ومفصلة.
الحقيقة هي أن ملء بطاقة الجزء يتنافس مع معالجة الطلبات الواردة لموارد خادم الواجهة الأمامية. وبالتالي ، فإن إحضار خوادم الواجهة الأمامية احتياطيًا بسرعة كبيرة سيخلق تعارضًا بين العمليتين ويترك القليل جدًا لمعالجة الطلبات الواردة. النتيجة متوقعة: زيادة في معدلات الخطأ وزيادة في زمن الوصول. بالإضافة إلى ذلك ، يمكن اعتبار خوادم الواجهة الأمامية البطيئة علامة على أنها غير صحية ، مما قد يؤدي إلى إزالتها من قائمة الخوادم المتاحة ، مما يؤدي بدوره إلى إبطاء عملية الاسترداد.
تضمنت جميع الحلول الممكنة تغيير تكوين كل خادم أمامي وإعادة تشغيله. في حين أن مرشحنا الرئيسي لمصدر مشاكلنا (مشكلة يبدو أنها تضغط على الذاكرة) بدا واعدًا ، إذا كنا مخطئين ، فقد خاطرنا بمضاعفة وقت الاسترداد ، حيث سيتعين علينا إعادة إصلاح كل شيء وإعادة تشغيله. لتسريع إعادة التشغيل ، بالتوازي مع التحقيق ، بدأنا في إجراء تغييرات على تكوين خوادم الواجهة الأمامية ، مما يسمح لك بتلقي البيانات مباشرة من مخزن البيانات الوصفية في وقت التمهيد ، وليس من جيران الواجهة الأمامية.
سبب رئيسي
في الساعة 9:39 مساءً بتوقيت المحيط الهادي ، تمكنا أخيرًا من تأكيد السبب الجذري للتحطم. اتضح أنه لا علاقة له بالذاكرة. أدت إضافة سعات جديدة إلى تجاوز عدد مؤشرات الترابط على جميع خوادم الواجهة الأمامية الحد الأقصى الممكن ، الذي يسمح به تكوين النظام. نظرًا لتجاوز الحد ، تعذر إنشاء ذاكرة التخزين المؤقت (بطاقات الأجزاء). ونتيجة لذلك ، لم تتمكن خوادم الواجهة الأمامية من إعادة توجيه الطلبات إلى مجموعات النهاية الخلفية.
لم نرغب في زيادة حد مؤشر الترابط في نظام التشغيل دون إجراء اختبار أولي ، وبما أنه تمت إزالة السعة الإضافية بالفعل في ذلك الوقت ، فقد قررنا أن خطر تجاوز حد النظام على عدد سلاسل العمليات كان ضئيلاً للغاية واستمرنا في إعادة تشغيل الخوادم. بدأت المجموعة الأولى من الواجهات الجديدة في قبول حركة مرور Kinesis في الساعة 10:07 بتوقيت المحيط الهادئ.
تتكون مجموعة الأجهزة الأمامية من عدة آلاف من الخوادم ، وللأسباب الموضحة أعلاه ، يمكننا إضافة خوادم بمعدل لا يزيد عن بضع مئات في الساعة. واصلنا إضافة حركة المرور ببطء إلى الواجهة الأمامية ، مع ملاحظة الانخفاض المستمر في أخطاء خدمة Kinesis منذ منتصف النهار. ارتدت الخدمة تمامًا في الساعة 10:23 مساءً بتوقيت المحيط الهادئ.
ماذا تعلمنا
لقد تعلمنا العديد من الدروس من حادثة Kinesis ونخطط لإجراء تصحيحات في المستقبل القريب.
- , CPU . , , , . , . , .
- .
- , . , .
- -. - AWS ( CloudWatch) , -.
- (cellularization) ( , ). ( -) . Kinesis , , , . / , , .
أثر الانهيار أيضًا على بعض الخدمات التي تستخدم Kinesis. يستخدم
Amazon Cognito Kinesis Data Streams لجمع وتحليل أنماط الوصول إلى واجهة برمجة التطبيقات. في حين أن هذه المعلومات مفيدة للغاية لتشغيل خدمة Cognito ، إلا أنه لا يمكن ضمان تقديمها (أفضل جهد) . يتم تخزين البيانات مؤقتًا محليًا لمساعدة الخدمة على التعامل مع زمن الانتقال أو فترات قصيرة من عدم التوافر في خدمة Kinesis Data Streams.
لسوء الحظ ، كشف عدم توفر Kinesis Data Streams المطول عن خطأ كامن في رمز التخزين المؤقت الذي تسبب في بدء خوادم الويب Cognito في حظر المخازن المؤقتة لـ Kinesis Data Stream. نتيجةً لذلك ، واجه مستهلكو Cognito مواطن الخلل في واجهة برمجة التطبيقات وزيادة زمن الوصول لمجموعات مستخدمي Cognito ومجموعات الهوية. لم يتمكن المستخدمون الخارجيون من المصادقة أو الحصول على بيانات اعتماد AWS المؤقتة.
في المراحل المبكرة من الانقطاع ، حاول فريق Cognito التخفيف من تأثير أخطاء Kinesis عن طريق إضافة سعة إضافية وبالتالي زيادة قدرة التخزين المؤقت للمكالمات إلى Kinesis. في البداية ، كان لهذا تأثير إيجابي على الخدمة ، ولكن بحلول الساعة 7:01 بتوقيت المحيط الهادي ، زاد معدل الخطأ بشكل كبير. بالتوازي مع ذلك ، عمل الفريق على تقليل اعتماد Cognito على Kinesis. في الساعة 10:15 صباحًا ، تم نشر هذا الحل وبدأ معدل الخطأ في الانخفاض. بحلول الساعة 12:15 ظهرًا ، انخفض معدل الخطأ بشكل كبير ، وفي الساعة 2:18 مساءً بتوقيت المحيط الهادي ، كان Cognito يعمل بشكل طبيعي. لمنع تكرار هذه المشكلة ، قمنا بتعديل خوادم الويب Cognito. يمكنهم الآن تحمل أخطاء Kinesis API دون استنفاد مخازنهم المؤقتة (مما يؤدي إلى مشكلات المستخدم).
كلاود ووتشيستخدم Kinesis Data Streams لمعالجة المقاييس والسجلات. بدءًا من الساعة 5:15 صباحًا ، كانت CloudWatch تعاني من أخطاء متزايدة وأوقات انتقال لواجهات برمجة تطبيقات PutMetricData و PutLogEvents ، وتم وضع التنبيهات في الحالة
INSUFFICIENT_DATA. بينما استمرت معالجة بعض مقاييس CloudWatch أثناء انقطاع الخدمة ، وقع معظمها ضحية للعديد من الأخطاء وزيادة زمن الوصول.
في 5:47 صباحًا بتوقيت المحيط الهادي ، ظهرت أولى علامات الاسترداد مع تحسن وضع Kinesis Data Stream ، وبحلول الساعة 10:31 مساءً ، تعافت مقاييس وتنبيهات CloudWatch تمامًا. في الساعات التالية ، استمرت معالجة السجلات والمقاييس المتأخرة. بينما كانت CloudWatch تكافح مع الأخطاء ، لم يتمكن العملاء الداخليون والخارجيون من توصيل بيانات المقاييس إلى CloudWatch. نتيجة لذلك ، هناك فجوات في بيانات مقاييس CloudWatch.
في الوقت الحالي ، تعتمد خدمة CloudWatch على Kinesis لجمع المقاييس والسجلات ، لكن فريقها سينفذ قريبًا تغييرًا ، وبعد ذلك ستقوم CloudWatch بتخزين البيانات لمدة ثلاث ساعات في التخزين المحلي. سيسمح هذا التغيير للمستخدمين والخدمات المرتبطة بمقاييس CloudWatch (بما في ذلك AutoScaling) للوصول مباشرة إلى المقاييس التي تم جمعها حديثًا (في مخزن بيانات CloudWatch المحلي). تم تنفيذ هذه الفكرة بالفعل في منطقة US-EAST-1 ، وفي الأسابيع القادمة نخطط لنشرها عالميًا.
أصبحت خدمتان أخريان رهائن لمشاكل مقاييس CloudWatch:
- أولا، AutoScaling سياسات أظهرت بناء على مقاييس CloudWatch الكمون حتى 17:47، والنقطة التي بدأ CloudWatch على استعادة لياقته.
- -, Lambda. - CloudWatch. Lambda, , , CloudWatch . 6:15 PST , , -. : . 10:36 PST , .
شهدت أحداث CloudWatch و EventBridge زيادة في أخطاء API ووقت الاستجابة في معالجة الأحداث بدءًا من 5:15 صباحًا بالتوقيت الشرقي. بعد تحسين التوفر ، استأنف Kinesis EventBridge تسليم الأحداث الجديدة إلى المرسل إليهم ، أثناء معالجة الأحداث المتراكمة على طول الطريق.
تستخدم Elastic Container Service (ECS) و Elastic Kubernetes Service (EKS) EventBridge في مهام سير العمل الداخلية الخاصة بهم لإدارة مجموعات العملاء ومهامهم. وقد أثر هذا على توفير مجموعات جديدة ، وتأخر توسيع نطاق المجموعات الموجودة ، وأثر على إلغاء توفير المهام. بحلول الساعة 4:15 مساءً بتوقيت المحيط الهادي ، تم حل معظم هذه المشكلات.
إخطار العملاء
بالإضافة إلى الصعوبات في الخدمات ، في بداية الحادث ، واجهنا بعض التأخير في توصيل المعلومات حول حالة الخدمات للعملاء.
لدينا طريقتان للتواصل مع العملاء أثناء الأحداث التشغيلية:
- لوحة معلومات صحة الخدمة - لوحة معلومات يمكن الوصول إليها بشكل عام لتنبيه المشكلات التشغيلية الكبيرة ؛
- لوحة معلومات الصحة الشخصية - للإخطار المباشر للعملاء المتأثرين.
أثناء مثل هذه الأحداث ، نقوم عادةً بنشر المعلومات على Service Health Dashboard. ومع ذلك ، في هذه الحالة ، في بداية الانهيار ، لم نتمكن من تحديث المعلومات في Service Health Dashboard ، لأن الأداة المستخدمة لنشر التحديثات يتم استخدامها بواسطة Cognito المعطل.
لدينا طريقة احتياطية لتحديث Service Health Dashboard مع الحد الأدنى من تبعيات الخدمة. لقد عملت على النحو المنشود ، لكننا واجهنا بعض التأخير عند نشر المعلومات إلى Service Health Dashboard في بداية الحدث. النقطة المهمة هي أن أداة النسخ الاحتياطي هذه أقل آلية بكثير وأقل دراية لمشغلي مكتب المساعدة.
لضمان تسليم التحديثات في الوقت المناسب لجميع العملاء المتأثرين ، استفاد فريق الدعم من لوحة معلومات الصحة الشخصية لتنبيههم بمشكلات الخدمة المحتملة. وضعنا أيضًا لافتة عالمية تحتوي على معلومات محدثة في لوحة معلومات صحة الخدمة لإبقاء المستخدمين على اطلاع قدر الإمكان بالحادث. حتى نهاية الانهيار ، واصلنا استخدام مجموعة من Service Health Dashboard (مع ملخصات عن اللافتات العالمية وتفاصيل حول كيفية عمل خدمات معينة) و Personal Health Dashboard ، حيث حاولنا إبقاء العملاء متأثرين بمشاكل الخدمات محدثة. بناءً على خبرتنا ، قدمنا تمارين إلزامية مع نظام احتياطي لنشر الرسائل إلى لوحة معلومات صحة الخدمة في تدريب مهندس الدعم المنتظم.
...
أخيرًا ، أود أن أعتذر عن التأثير السلبي الذي أحدثه هذا الحادث على عملائنا. نحن نفخر بأنفسنا لتوفر Amazon Kinesis وندرك جيدًا مدى أهمية خدمات AWS هذه وغيرها لعملائنا وتطبيقاتهم / المستخدمين النهائيين وأعمالهم. سنبذل قصارى جهدنا للتعلم من هذا الحادث ونستخدمه لزيادة تحسين إمكانية الوصول.
ملاحظة
اقرأ أيضًا على مدونتنا: