النشر متعدد مناطق التوفر والبنى المتحمّلة للأعطال

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

منطقة التوفر مكان حقيقي

منطقة التوفر (Availability Zone) مركز بيانات واحد أو أكثر داخل منطقة AWS، له بنيته الخاصة للطاقة والتبريد والشبكة والاتصال المادي. ليست تقسيماً منطقياً ولا تسمية رفّ. وتشغّل AWS أكثر من 100 منطقة توفر حول العالم.

ورقمان يحدّدان سلوك مناطق التوفر، وكلاهما قرار تصميمي لا مصادفة:

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

وهذا الاقتران هو سبب نجاح Multi-AZ كلّه. لو كانت المسافة 5 كيلومترات لأسقطت عاصفة إقليمية عدّة مناطق معاً. ولو كانت 1000 كيلومتر لأضاف النسخ المتزامن عشرات المللي ثانية إلى كل تثبيت ولما فعّله أحد. المسافة مختارة كي تجعل التكرار عبر مناطق التوفر ذا معنى ومحتمل الكلفة في آن واحد.

واسم منطقة التوفر خاصّ بالحساب أيضاً. فـ us-east-1a في حسابك وus-east-1a في حساب زميلك عادةً منطقتان ماديّتان مختلفتان، لأن AWS تعشوِر الربط بينهما لتوزيع الحمل. والمعرّف الثابت هو AZ ID مثل use1-az1، وهو ما تقارنه حين تشارك subnets عبر الحسابات باستخدام AWS RAM.

التصنيف الذي يحسم كل شيء: موارد منطقة توفر ومنطقة وعالمية

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

كل مورد في AWS يقع في واحد من ثلاثة نطاقات بالضبط، والنطاق يخبرك بما يفعله عطل منطقة التوفر به.

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

وسطران يستحقّان نظرة أقرب لأنهما يوقعان الناس:

• وحدة EBS مورد منطقة توفر، ولقطتها مورد منطقة. لا تستطيع ربط وحدة في us-east-1a بنسخة في us-east-1b. لكنك تستطيع إنشاء وحدة جديدة في us-east-1b من لقطة تلك الوحدة، لأن بيانات اللقطة منسوخة عبر كل مناطق التوفر في المنطقة. وهذا التباين هو الطريقة التي تنقل بها تخزين الكتل بين مناطق التوفر، وهو تفصيل مفضّل في الاختبار.
• موازِن الحمل مورد منطقة، لكن عقده موارد مناطق توفر. تفعّل ALB أو NLB في subnets محدّدة، فتضع AWS عقدة موازِن حمل في كل منطقة توفر من تلك. فعّله في منطقة واحدة وتكون قد بنيت تبعية أحادية المنطقة باسم يوحي بالعكس. ويشترط ALB وجود subnets في منطقتَي توفر على الأقلّ لهذا السبب تحديداً.

طبقة الحوسبة: التوجيه ليس سعة

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

وما ليس تلقائياً هو وجود مكان تذهب إليه الحركة. امشِ على الأرقام.

تشغّل 6 نسخ على 3 مناطق توفر، نسختين لكل منطقة، وتمتصّ كل نسخة 20 بالمئة من حركة الذروة. فأنت في الذروة عند 6 × 20 = 120 بالمئة مما تحتاجه، وهو هامش يبدو مريحاً. والآن تتعطّل المنطقة B:

النسخ الباقية:  4
السعة:          4 × 20% = 80% من الذروة
العجز:          20% من الذروة، حتى تُطلَق البدائل وتجتاز فحوصات الصحة

فتُسقِط أو تؤخّر طلباً من كل خمسة لعدّة دقائق. أدّى موازِن الحمل عمله على أكمل وجه والموقع متدهور مع ذلك.

والقاعدة العامة أن تحجم للحمل مع فقد منطقة توفر كاملة، ويكتبها الناس AZ+1:

وهذا السبب الملموس لتوصية AWS بثلاث مناطق توفر بدل اثنتين. المنطقتان تجعلان التكرار يكلّفك الضعف، والثلاث تجعلانه يكلّفك النصف زيادةً.

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

وإعدادان يقرّران مدى تساوي توزيع الحمل:

• موازنة الحمل عبر مناطق التوفر (cross-zone) تتيح لعقدة موازِن الحمل في منطقة إرسال الحركة إلى أهداف في كل المناطق لا في منطقتها وحدها. وهي مفعّلة افتراضياً في ALB (ويمكن إطفاؤها لكل مجموعة أهداف) ومطفأة افتراضياً في NLB. ومع إطفائها وتفاوت أعداد الأهداف بين المناطق، تحصل منطقة فيها هدفان على الحصة نفسها التي تحصل عليها منطقة فيها ثمانية، فيعمل كل هدف من الهدفين أربعة أضعاف.
• فحوصات صحة ELB مقابل فحوصات صحة ASG. لا تراقب مجموعة Auto Scaling افتراضياً إلا فحوصات حالة EC2، وهي تقول إن النسخة تعمل لا إن تطبيقك يستجيب. فعّل فحوصات صحة ELB على المجموعة كي يُستبدَل الهدف الذي يفشل في فحص HTTP بدل أن يبقى قائماً يعيد أخطاءً.

طبقة البيانات: ثلاث طرق للنجاة من منطقة توفر

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

نشر Multi-AZ DB instance هو الكلاسيكي والأكثر اختباراً. يُبقي RDS نسخة احتياطية في منطقة توفر ثانية، وينسخ إليها كل تثبيت نسخاً متزامناً، وعند العطل يقلب سجلّ CNAME خلف نقطة نهايتك ليشير إلى النسخة المرقّاة. فيبقى تطبيقك على سلسلة الاتصال نفسها ولا يحتاج إلا إعادة الاتصال. ونتيجتان تتبعان كلمة «متزامن»:

• يرتفع تأخير الكتابة والتثبيت مقارنةً بالنشر في منطقة توفر واحدة، لأن كل تثبيت ينتظر المنطقة الثانية. وهذه الكلفة هي ثمن المتانة.
• النسخة الاحتياطية ليست خادماً احتياطياً تستطيع استعماله. لا تقبل أي اتصال. فإن طلب سيناريو تخفيف حمل القراءة، فالجواب نسخة قراءة أو Multi-AZ DB cluster، لا النسخة الاحتياطية أبداً.

ويسلك Aurora طريقاً آخر: وحدة تخزين العنقود نفسها تمتدّ على ثلاث مناطق توفر وتحمل ست نسخ من بياناتك، فلا وجود لنسخ متماثل على مستوى النسخ. وفقد منطقة توفر يزيل بعض النسخ لا التخزين، ولهذا تُرقّى نسخة قراءة في Aurora بهذه السرعة.

التبعيات أحادية المنطقة التي يتركها الناس قائمة

حتى البنية المتعدّدة المناطق المبنية بعناية تحمل عادةً بضع نقاط اختناق داخل منطقة توفر واحدة. وهذه أولاها بالتدقيق:

• NAT gateway. يُنشأ في subnet واحد، أي منطقة توفر واحدة. وجّه كل subnet خاصّ عبر NAT gateway واحد ويقطع عطل منطقة واحدة الوصول الصادر إلى الإنترنت عن الـ VPC كلها. انشر واحداً لكل منطقة توفر وأعطِ كل subnet خاصّ جدول توجيه يشير إلى البوابة في منطقته. وهذا يزيل أيضاً رسوم نقل البيانات بين مناطق التوفر، فيكون التصميم المتين أرخص غالباً.
• EFS One Zone. فئة تخزين أرخص، والاسم نفسه هو التحذير. فـ EFS Standard ينسخ عبر مناطق التوفر، وOne Zone لا ينسخ.
• وحدات instance store. مربوطة مادياً بالمضيف. ليست محصورة بمنطقة توفر فحسب، بل بعمر النسخة. وإيقاف النسخة يفقد البيانات.
• نسخة RDS في منطقة توفر واحدة مع نسخة قراءة في منطقة أخرى. تبدو Multi-AZ على المخطّط، لكن النسخة غير متزامنة والترقية عملية يدوية تستغرق دقائق. هذه خطة تعافٍ لا آلية تبديل عند الفشل.
• موازِن حمل مفعّل في subnet واحد. غطّيناه أعلاه، ومن السهل إنشاؤه سهواً في بيئة اختبار تصير إنتاجاً لاحقاً.

ما لا يفعله Multi-AZ

يحمي Multi-AZ من عطل البنية التحتية داخل منطقة توفر واحدة. وهذا وعد محدّد ومحدود. ولا يفعل شيئاً تجاه:

• التلف المنطقي. فـ DELETE بلا WHERE يُنسَخ نسخاً متزامناً إلى النسخة الاحتياطية خلال مللي ثوانٍ، فتصير النسختان خاطئتين بالتساوي. والتعافي يعني استعادة لنقطة زمنية أو لقطة.
• الحذف بالخطأ. حذف نسخة قاعدة البيانات يحذف نسختها الاحتياطية معها.
• أحداث على مستوى المنطقة كلها. فكل مناطق التوفر في الجدول أعلاه تسكن منطقة واحدة. والنجاة من فقد منطقة بنية أخرى، ويغطّي الدرس الأخير في هذا الموضوع الطرق الأربع لبنائها.
• نشر معطوب. فالكود الجديد الذي يعيد HTTP 500 يعيدها بالطريقة نفسها في المناطق الثلاث.

وهذه أنظف صياغة للحدّ تحتفظ بها في ذهنك: Multi-AZ توفر عالٍ ويحمي من أن تنكسر الأشياء. والنسخ الاحتياطي والنسخ عبر المناطق تعافٍ من الكوارث ويحمي من أن تكون الأشياء خاطئة. يفصل الاختبار بينهما باستمرار، وكذلك يجب أن يفعل تصميمك.

نصائح للاختبار

• عبارات «النجاة من عطل منطقة توفر» و«التوفر العالي» و«التبديل التلقائي عند الفشل» تشير إلى Multi-AZ. وعبارات «الحذف بالخطأ» و«تلف البيانات» و«الاستعادة إلى نقطة زمنية» و«انقطاع منطقة» تشير إلى النسخ الاحتياطي أو استراتيجية تعافٍ، ويكون Multi-AZ جواباً خاطئاً مهما بدا حامياً.
• أي جواب يقرأ من النسخة الاحتياطية في Multi-AZ DB instance خاطئ. والخيار موجود ليُرفَض. وتخفيف حمل القراءة نسخة قراءة أو Multi-AZ DB cluster.
• أرقام تمسك بها: تبديل Multi-AZ DB instance من 60 إلى 120 ثانية، وتبديل Multi-AZ DB cluster عادةً أقلّ من 35 ثانية، وتخزين Aurora 6 نسخ على 3 مناطق توفر، وALB يشترط منطقتَي توفر على الأقلّ.
• حين يصف النصّ انقطاعاً أصاب كل شيء رغم تعدّد مناطق التوفر، فتّش عن تبعية مشتركة داخل منطقة واحدة. وNAT gateway المفرد هو الكلاسيكي، وموازِن الحمل في subnet واحد هو الآخر.
• موازنة الحمل عبر مناطق التوفر: مفعّلة افتراضياً في ALB، ومطفأة افتراضياً في NLB. وتفاوت أعداد الأهداف بين المناطق مع إطفائها يعني حملاً غير متساوٍ.
• إن سأل سؤال عن مقدار السعة في كل منطقة توفر، فالجواب المقصود أن تكفي المناطق الباقية لحمل العمل كاملاً دون توسّع. هذا هو الثبات الساكن، ومبرّره أن Auto Scaling عملية على مستوى control plane.

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