الاستقرار الثابت باستخدام مناطق توافر الخدمات

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

في تصميمات الاستقرار الثابت، يواصل النظام العام العمل حتى عندما تتعطل التبعية. ربما لا يرى النظام أي معلومات محدَّثة (مثل الأشياء الجديدة أو الأشياء المحذوفة أو الأشياء المعدَّلة) كان من المفترض أن توصلها التبعية الخاصة بها. لكن، يستمر كل شيء في العمل كما كان الأمر قبل تعطُّل التبعية. سنصف كيف بنينا Amazon Elastic Compute Cloud (EC2) بحيث يتمتع بالاستقرار الثابت. وبعد ذلك سنقدِّم تصميمين نموذجيين للاستقرار الثابت وجدناهما مفيدين في بناء أنظمة إقليمية عالية التوفر بالإضافة إلى مناطق توافر الخدمات.

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

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

في حالة تعطل منطقة توافر خدمات، لا يتطلب التصميم المعروض في الرسم السابق اتخاذ أي إجراءات. ستبدأ مثيلات EC2 في منطقة التوافر المعطلة الفشل في عمليات التحقق من السلامة، وسينقل Application Load Balancer المرور بعيدًا عنها. في الواقع، إن خدمة Elastic Load Balancing مُصممة وفقًا لهذا المبدأ. فإنها قد قدَّمت ما يكفي من سعة موازنة الأحمال لتحمل تعطل منطقة توافر دون الحاجة إلى التوسعة.

كما أننا نستخدم أيضًا هذا النمط عندما لا يكون هناك موازن أحمال أو خدمة HTTPS. على سبيل المثال، يمكن أن يتبع أسطول مثيلات EC2 يعالج الرسائل من صف انتظار Amazon Simple Queue Service (SQS) هذا النمط أيضًا. يتم نشر المثيلات في Auto Scaling group عبر عدة مناطق توافر، يتم التزويد المفرط فيها بشكل مناسب. في حالة تعطل إحدى مناطق توفر الخدمات، لا تفعل الخدمة شيئًا. تتوقف المثيلات المتعطلة عن عملها، وتتولى مثيلات أخرى الأمر.

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

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

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

نحن نتبع مبدأ استقلالية مناطق توافر الخدمات في Amazon EC2 في ممارسات النشر الخاصة بنا. في Amazon EC2، يتم نشر البرامج إلى الخوادم المادية التي تستضيف مثيلات EC2، وأجهزة التخزين المؤقت، وأدوات تحليل DNS، ومكونات مستوى التحكم في مسار إطلاق مثيل EC2، والعديد من المكونات الأخرى التي تعتمد عليها مثيلات EC2. تتبع عمليات النشر هذه تقويم نشر نطاقي. يعني هذا أن منطقتي توافر خدمات في نفس المنطقة ستتلقيان عمليات النشر المحددة في أيام مختلفة. نستخدم إطلاقًا ذا مراحل لعمليات النشر، عبر AWS. على سبيل المثال، نتبع أفضل الممارسات (بغض النظر عن الخدمة التي نجري النشر لها) التي تتمثل في نشر المربع الواحد أولاً، ثم 1/N من الخوادم، إلخ. لكن، في الحالة المحددة للخدمات التي تكون مثل تلك التي في Amazon EC2، تتجاوز عمليات النشر الخاصة بنا ذلك بخطوة وتكون متسقة بشكل مقصود مع حدود منطقة توافر الخدمات. وبهذه الطريقة، تؤثر مشكلة النشر في إحدى مناطق توافر الخدمات ويتم الإرجاع والإصلاح. ولا يؤثر ذلك في مناطق توافر الخدمات الأخرى، التي تواصل الأداء بشكل طبيعي.

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

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

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

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

في الأمثلة السابقة، حيث تستدعي خدمة إقليمية عالية التوفر خدمة إقليمية عالية التوفر أخرى، إن تم إرسال الطلب عبر النظام، فببعض الافتراضات المبسطة، تكون فرصة تجنب الطلب لمنطقة توافر الخدمات المعطلة هي 2/3 * 2/3 = 4/9. يعني هذا أن فرصة الطلب في عدم التأثر بالحدث أقل من فرصته في تأثره به. وفي المقابل، إذا بنينا الخدمة الخضراء بحيث تكون خدمة نطاقية كما هو الحال في المثال الحالي، يمكن للمضيفين في الخدمة البرتقالية استدعاء نقطة النهاية الخضراء في منطقة توافر الخدمات نفسها. بهذا التصميم، تكون فرص تجنب منطقة توافر الخدمات المعطلة 2/3. إن كانت N من الخدمات جزءًا من مسار الاستدعاء هذا، فسيكون المعدل العام لهذه الأرقام هو (2/3)^N بالنسبة إلى N من الخدمات الإقليمية في مقابل معدل ثابت قدره 2/3 بالنسبة إلى N من الخدمات النطاقية.

ولهذا السبب بنينا بوابة Amazon EC2 NAT كخدمة نطاقية. إن بوابة NAT هي إحدى ميزات Amazon EC2 التي تسمح بمرور الإنترنت الصادر من شبكة فرعية خاصة ولا تظهر كبوابة إقليمية باتساع VPC، بل كمورد نطاقي ينشئ له العملاء مثيلاً منفصلاً في منطقة توافر الخدمات كما يظهر في الرسم التالي. وتبقى بوابة NAT في مسار اتصال الإنترنت من أجل VPC، ومن ثمَّ فهي جزء من مستوى البيانات لأي مثيل EC2 في VPC. إن كان هناك عطل في منطقة توافر البيانات، فنحن نريد إبقاء العطل في داخل منطقة توافر الخدمات، بدلاً من نشره إلى المناطق الأخرى. في النهاية، نريد أن يعرف العميل الذي أنشأ تصميمًا مماثلاً لما ذكر فيما سبق في هذا المقال (أي، بتزويد أسطول عبر ثلاث مناطق توافر خدمات بسعة كافية في أي اثنين لحمل الحمل كاملاً) أن مناطق توافر الخدمات الأخرى لن تتأثر تمامًا بأي شيء يحدث في منطقة توافر الخدمات المعطلة. الطريقة الوحيدة المتاحة لنا لضمان ذلك هي أن تبقى كل المكونات الأساسية—مثل بوابة NAT—بالفعل في منطقة توافر الخدمات.

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

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

عند إجراء تصميم موجه إلى الخدمة ستتم إدارته في AWS، تعلمنا استخدام أحد هذين النمطين، أو كليهما:

• النمط الأبسط: إقليمية-استدعاءات-إقليمية. كثيرًا ما يكون هذا هو الخيار الأمثل من أجل الخدمات خارجية التوجيه، ومناسبًا لمعظم الخدمات الداخلية أيضًا. على سبيل المثال، عند بناء خدمات التطبيقات ذات المستوى الأعلى في AWS، مثل Amazon API Gateway وتقنيات AWS عديمة الخوادم، نستخدم هذا النمط لتقديم التوفر العالي في مواجهة أعطال مناطق توافر الخدمات.
• النمط الأكثر تعقيدًا: إقليمية-استدعاءات-نطاقية أو نطاقية-استدعاءات-نطاقية. عند تصميم مكونات مستوى البيانات الداخلي، وفي بعض الحالات الخارجي في Amazon EC2 (على سبيل المثال، أجهزة الشبكة أو البنية التحتية الأخرى التي تقع مباشرةً في مسار البيانات الحرجة) نتبع نمط استقلال مناطق توافر البيانات ونستخدم المثيلات المخزَّنة في مناطق توافر البيانات، بحيث يبقى مرور الشبكة في منطقة توافر الخدمات الخاصة به نفسها. يساعد هذا النمط ليس فقط في إبقاء الأعطال معزولة عن مناطق توافر الخدمات بل أيضًا له سمات حسنة تتعلق بتكلفة مرور الشبكة في AWS.

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