---
title: "تصميم البرمجيات لضمان التوافرية في السحابة"
description: "كيف تتجنبون نقاط الفشل الوحيدة في السحابة: الحوسبة والتخزين وقواعد البيانات، مع أمثلة من AWS لبناء تطبيقات عالية التوافرية."
canonical: https://oozou.com/ar/blog/designing-software-for-availability-in-the-cloud-6
locale: ar
date: 2020-05-09
author: "OOZOU Team"
---

# تصميم البرمجيات لضمان التوافرية في السحابة

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

Published: 2020-05-09 · Author: OOZOU Team (Engineering) · 8 min read

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

# المتانة (Durability)

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

# التوافرية (Availability)

نقصد بالتوافرية هنا مقياس احتمال أن يكون الشيء جاهزًا للاستخدام. وفي البرمجيات، تُقاس عادة بنسبة وقت تشغيل التطبيق (uptime) خلال فترة زمنية معينة. فمثلًا، التطبيق الذي تبلغ توافريته 99.995% على مدى سنة لا يتجاوز وقت توقفه المتوقع 0.005%، أي نحو نصف ساعة خلال 12 شهرًا. وغالبًا ما تتضمن اتفاقيات مستوى الخدمة (SLA) للتطبيقات المستضافة هذا الحساب في صورة وقت تشغيل ملزم تعاقديًا.

# نقاط الفشل الوحيدة (Single Points of Failure)

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

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

ورغم تزايد عدد الخدمات والخدمات المُدارة التي يقدمها مزودو الخدمات السحابية، فالأرجح أنكم تستخدمون عددًا قليلًا منها في أي وقت، وغالبًا ضمن فئات الحوسبة والتخزين وقواعد البيانات. سأستخدم AWS (Amazon Web Service) في أمثلتي، لكن هناك أوجه شبه مباشرة مع Google Cloud Platform وMicrosoft Azure. لنلقِ نظرة على كل فئة في سياق النشر على السحابة.

# الحوسبة (Compute)

لا يوجد حل واحد يناسب الجميع في الحوسبة. فتطبيقكم ونوع بياناتكم وحجمها وحجم الزيارات هي ما سيرشدكم إلى اختيار نوع موارد الحوسبة وحجمها المناسبين.
الخادم أو الـ instance الذي يعمل عليه تطبيقكم مزوّد أصلًا بكثير من التكرار (redundancy) المدمج. فخوادم Elastic Compute Cloud (EC2) مثلًا تتمتع بتكرار في الطاقة والشبكة والمعالج. تمثل الـ instances مكونات الخادم الخام مثل المعالج والذاكرة، وهناك قائمة طويلة من قوالب AMI (AWS Machine Image) للاختيار منها، من أنظمة تشغيل مُعدّة مسبقًا إلى تطبيقات مثبتة بالكامل.
ورغم أن هذه الإعدادات تقلل احتمال الفشل، يظل الـ instance واحدًا، وبالتالي يبقى نقطة فشل وحيدة محتملة. وإضافة طبقة أخرى من التكرار هنا تساعد على تقليل هذا الخطر. فمثلًا، وضع Application Load Balancer (ALB) أمام instance اثنين أو أكثر يشغّلان تطبيقكم يزيل نقطة الفشل الوحيدة على مستوى الخادم. يستطيع الـ ALB مراقبة سلامة كل الـ instances وتوجيه الزيارات بعيدًا عن أي instance متعثر. وهو أيضًا مكوّن أساسي في التوسع التلقائي (auto-scaling)، الذي يتبع قواعد مخصصة للتوسع أفقيًا بإضافة instances، كي يستوعب تطبيقكم ذروات الزيارات المتوقعة وغير المتوقعة، ثم الانكماش بإزالة instances حين يعود الحمل إلى طبيعته. ويمكن عمومًا إعداد موازنة الحمل لمنطقة توافر واحدة (Availability Zone أو AZ)، وهي مجموعة موارد عالية التوافرية تمتد عبر مركزي بيانات فعليين أو أكثر، مع تكرار في الطاقة والشبكة والتحكم البيئي. ولمزيد من التكرار، يمكنكم إعداد تطبيقكم ليمتد عبر عدة مناطق AZ ضمن منطقة جغرافية واحدة لزيادة المتانة. وتذكروا أن التكلفة ترتفع مع اتساع الانتشار.
الخلاصة:

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

# التخزين (Storage)

طريقة تخزين أصول تطبيق أعمالكم وبياناته وبياناته الوصفية (metadata) هي ما يحدد سرعة استجابتكم لانقطاع الخدمة أو الأعطال أو فقدان البيانات. والمضي دون استراتيجية تخزين جيدة غالبًا ما ينتهي بكارثة. وكما هو الحال مع التأمين، لا تظهر قيمتها الحقيقية إلا حين تحتاجونها.
هناك عدة نقاط يجب مراعاتها في التخزين عند التصميم من أجل التوافرية. فأثناء تشغيل تطبيقكم، يستهلك موارد التخزين المحلية على الـ instance (أو الـ instances) التي يُستضاف عليها. وهذا أكثر أنواع التخزين تقلبًا، ويجب اعتباره قابلًا للفقد إن خسرتم أحد الـ instances. فقدان البيانات غير الحرجة، كالتخزين المؤقت، يمكن تجاوزه عادة. لكن على التطبيقات السحابية أن تضمن تخزين البيانات الحرجة في مصادر أقل تقلبًا. فعلى AWS مثلًا، تستفيد قاعدة البيانات المستضافة ذاتيًا من تخزينها على EBS (Elastic Block Store)، وهو يشبه إلى حد ما قرصًا صلبًا أو SSD مركّبًا على الـ instance. تُنسخ وحدات EBS داخل منطقة AZ افتراضيًا، ويمكن نسخها احتياطيًا بسهولة وتلقائيًا عبر snapshot، ثم استعادتها واستخدامها عند تشغيل instances جديدة.
بعد ذلك تأتي خدمة Elastic File System (EFS)، وهي الأقرب إلى NAS (Network Attached Storage)، وتُستخدم حين تحتاج عدة instances أو خدمات إلى الوصول إلى بيانات الملفات نفسها، مثل السجلات والمجلدات والمستودعات والمستندات وغيرها. تتوسع وتنكمش تلقائيًا لتلائم حجم البيانات المتزايد أو المتناقص دون أي تدخل يدوي. ويمكن إعدادها لتمتد عبر عدة مناطق AZ.
وأخيرًا هناك Simple Storage Service (S3) التي يمكنها تخزين أي شيء تقريبًا. إنها خدمة تخزين على مستوى الكائنات (object storage) بمتانة وتوافرية عاليتين جدًا. تُعد S3 مثالية لأي كائنات تحتاج إلى تخزين طويل الأمد، ولها فئات تسعير تناسب نمط الوصول المطلوب. وكثيرًا ما تُستخدم لتخزين أصول التطبيقات والبيانات الثنائية والنسخ الاحتياطية لقواعد البيانات ولقطات التخزين وغيرها من المحتوى الثابت. تتوسع تلقائيًا وتُحتسب تكلفتها بحسب حجم البيانات المخزنة كل شهر. ولها مزايا كثيرة أخرى، منها الـ caching العالمي، والأرشفة طويلة الأمد، وصلاحيات وسياسات لكل كائن على حدة، بل واستضافة المواقع الثابتة.
الخلاصة:

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

# قاعدة البيانات (Database)

قد لا يكون لتطبيقكم وأعمالكم أصل أثمن من البيانات التي تجمعونها أو تقدمونها.
هناك فعليًا استراتيجيتان رئيسيتان لقواعد البيانات في السحابة: إما أن تستضيفوها بأنفسكم (على instance واحد أو أكثر مثلًا)، أو تعتمدوا على خدمة قواعد بيانات مُدارة بالكامل. يمكنكم التفكير في خدمة مُدارة مثل أحد الأنواع الكثيرة من RDS (Relational Database Service). فلا توجد instances تحتاجون إلى إدارتها وتوسيعها، وخدمات RDS عالية التوافرية افتراضيًا، ويمكن إعدادها للنشر عبر عدة مناطق AZ. ومع النسخ الاحتياطي إلى S3 مثلًا، تصبح بياناتكم جاهزة للاستعادة في أي موقع إن وقعت خسارة كارثية في أي منطقة. أما إن قررتم إدارة قاعدة بياناتكم بأنفسكم (مستضافة محليًا على instance من EC2 مثلًا)، فعليكم التعامل بأنفسكم مع تحديات التوافرية، مثل النسخ المتماثل (replication)، وإعداد master/slave، والتخزين، والنسخ الاحتياطي والاستعادة، إضافة إلى تحديثات البرمجيات وإدارة الأمان. أما مع RDS فتتولى الخدمة المُدارة ذلك كله تقريبًا. ويجب الموازنة بين التكلفة الإضافية لـ RDS وحجم الجهد اليدوي اللازم لإبقاء تطبيقكم يعمل.
الخلاصة:

- استخدام خدمة مُدارة يمنحكم توافرية عالية جاهزة
- المفاضلة تتعلق غالبًا بالتكلفة: الجهد اليدوي مقابل الراحة
- إن كانت بياناتكم مهمة لكم، فلا تخاطروا: النسخ الاحتياطي والأمان والتوسع

# الخلاصة النهائية

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

---

Contact OOZOU: hello@oozou.com · +66 2544 0000 · https://oozou.com/ar/contact

More for AI agents: https://oozou.com/llms.txt · every page has a markdown twin at its URL plus ".md"