تصميم بنية سحابية قابلة للتوسع وعالية التوافر وخطط التعافي من الكوارث

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

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

1. التوسع والتوافر: مفهومان مختلفان

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

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

2. تحديد أهداف التوافر قبل التصميم

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

ويُعبَّر عن الإجابة بمؤشرين أساسيين: هدف وقت الاستعادة (RTO)، وهو أقصى مدة مقبولة لعودة النظام بعد العطل، وهدف نقطة الاستعادة (RPO)، وهو أقصى قدر مقبول من البيانات المفقودة مقيسًا بالزمن.

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

3. موازنة الأحمال وتوزيع الطلبات

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

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

4. التوسع التلقائي بحسب الطلب

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

وتُبنى قواعد التوسع على مؤشرات مثل استهلاك المعالج، أو عدد الطلبات لكل خادم، أو طول طابور المهام المنتظرة. ويمكن أيضًا جدولة التوسع مسبقًا للذرى المعروفة، كبداية الشهر أو المواسم.

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

5. تصميم تطبيق عديم الحالة

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

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

6. تعدد مناطق التوافر

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

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

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

7. التعافي من الكوارث على مستوى المنطقة

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

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

ولا قيمة لخطة لم تُختبر، فتجارب الاستعادة الدورية هي ما يكشف الثغرات قبل وقوع الحادث.

الخلاصة

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