الموثوقية والإتاحة والمرونة

التكرار من أجل التوافر

18 دقيقة الدرس 2 من 10

التكرار من أجل التوافر

كل نظام إنتاجي سيشهد في نهاية المطاف حالة فشل — خادم يتعطل، قرص يمتلئ، وصلة شبكية تنقطع. السؤال ليس هل سيحدث شيء ما، بل هل يواصل النظام خدمة المستخدمين عندما يحدث ذلك. التكرار (Redundancy) هو الانضباط الهندسي القائم على التخلص من نقاط الفشل الفردية بمضاعفة المكونات الحيوية، بحيث لا يتسبب أي فشل منفرد في إسقاط النظام بأكمله.

ما هي نقطة الفشل الفردية؟

نقطة الفشل الفردية (SPOF) هي أي مكون يؤدي فشله إلى توقف النظام بالكامل. من الأمثلة الكلاسيكية:

خادم ويب واحد بلا خادم احتياطي
قاعدة بيانات واحدة بلا نسخة طبق الأصل
محول شبكة واحد يربط جميع خوادم الرف
منطقة استضافة واحدة تحتضن كل بنيتك التحتية
مزوّد DNS واحد بلا مزوّد احتياطي

تحديد نقاط الفشل الفردية هو الخطوة الأولى في هندسة الموثوقية. ارسم بنيتك من البداية إلى النهاية واسأل: إذا اختفى هذا المكون الآن، ماذا سينكسر؟ أي مكون تكون إجابته "كل شيء" هو SPOF يجب معالجته.

تدقيق نقاط الفشل الفردية: تجوّل كل طبقة من طبقات مكدّسك — العميل، DNS، CDN، موزّع الحمل، طبقة التطبيق، الكاش، قاعدة البيانات، طابور الرسائل، تخزين الكائنات، واجهات برمجية خارجية. كل طبقة يجب أن تمتلك على الأقل نسختين مستقلتين قادرتين على معالجة الحركة، دون أي مصير مشترك بينهما.

أنواع التكرار

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

التكرار النشط-النشط (Active-Active)

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

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

التكرار النشط-السلبي (Active-Passive — الوضع الاحتياطي الساخن)

نسخة واحدة تتعامل مع كل الحركة (العقدة النشطة) بينما تظل نسخة أو أكثر متطابقة في وضع الاستعداد (العقدة السلبية) جاهزة للاستبدال الفوري. تستقبل عقد الاستعداد نفس البيانات من العقدة النشطة في الوقت الفعلي، لذا حالتها محدَّثة. عند فشل العقدة النشطة، يُرقّي آلية الفشل الاستبدالي (VIP، تحديث DNS، أو مدير مجموعة مثل Pacemaker) عقدة الاستعداد إلى نشطة.

هذا النموذج شائع لقواعد البيانات، إذ إن السماح لعقدتين بقبول الكتابة في آنٍ واحد سيؤدي إلى تعارضات العقل المنقسم. PostgreSQL مع Patroni، وMySQL Group Replication، وAmazon RDS Multi-AZ، كلها تستخدم النشط-السلبي على مستوى العقدة الرئيسية.

المقايضة: تستهلك العقدة السلبية موارد (معالج، ذاكرة، قرص، رسوم ترخيص) لكنها لا تعالج أي طلبات. أنت تدفع مقابل طاقة خاملة في مقابل فشل استبدالي سريع بلا فقد للبيانات.

الوضع الاحتياطي البارد / الدافئ

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

النشط-النشط (يسار): جميع العقد تخدم الحركة الحية، والفشل يُمتص فوراً. النشط-السلبي (يمين): عقدة واحدة تتعامل مع كل الحركة، وعقدة احتياطية منزامنة تستبدلها عند الفشل.

التكرار في كل طبقة

الأنظمة المرنة تُطبّق التكرار في كل طبقة من طبقات المكدّس بشكل مستقل، لأن خللاً في أي طبقة يمكن أن يكون نقطة الفشل الفردية التي تُسقط التوافر. إليك كيف تتراكم الطبقات عملياً:

موزّعات الحمل

موزّع الحملك نفسه نقطة فشل محتملة. مزودو الخدمة السحابية (AWS ALB/NLB، GCP Load Balancing، Cloudflare) يشغّلون عقداً مادية متعددة خلف عنوان IP افتراضي واحد أو عنوان Anycast. إذا كنت تشغّل موزّعات الحمل بنفسك (HAProxy، Nginx)، فأنت تحتاج على الأقل إلى اثنين في نمط نشط-سلبي مع عنوان IP عائم تديره keepalived (VRRP). دون ذلك، موزّع الحمل هو نقطة الفشل الفردية حتى لو كان لديك خوادم تطبيقات متعددة.

خوادم التطبيقات

أسهل طبقة يمكن جعلها مكررة. لأن خوادم التطبيقات الجيدة عديمة الحالة (تناولت ذلك سابقاً)، تشغّل ببساطة نسخاً متطابقة متعددة على مضيفين مادية مختلفة — ويُفضَّل أن تكون في مناطق توافر مختلفة. يفحص موزّع الحمل صحة كل نسخة ويتوقف عن التوجيه إلى النسخ غير الصحية خلال 10–30 ثانية من الفشل. شغّل على الأقل نسختين في الإنتاج؛ الثلاث أفضل حتى تتمكن من إيقاف واحدة للتحديثات المتدرجة دون النزول تحت N+1.

قواعد البيانات

قواعد البيانات هي الطبقة الأصعب للتكرار بسبب الحالة. النهج المعياري هو عقدة رئيسية مع نسخة قراءة واحدة أو أكثر. يمكن توزيع القراءات على النسخ، أما الكتابات فتذهب للعقدة الرئيسية فقط. إذا فشلت الرئيسية، تُرقَّى نسخة منها. خدمات مثل Amazon RDS Multi-AZ تُؤتمت هذا: نسخة احتياطية متزامنة في منطقة توافر مختلفة تحتفظ بنسخة ساخنة بتأخر نسخ أقل من ثانية، وتستغرق عملية الاستبدال حوالي 60–120 ثانية تلقائياً.

تأخر النسخ المتماثلة مهم. النسخ المتماثل غير المتزامن سريع وشائع الاستخدام، لكنه يسمح بفترة ضيقة حين تكون النسخة متأخرة عن الرئيسية. إذا تعطلت الرئيسية خلال تلك الفترة، يمكن فقدان الكتابات التي تمت مؤخراً. للبيانات المالية أو الحيوية، استخدم النسخ المتزامن — لا تُأكَّد الكتابة إلا بعد إتمامها على كلا العقدتين. المقايضة هي زيادة طفيفة في وقت استجابة الكتابة (~5–10 مللي ثانية للنسخة الاحتياطية في نفس المنطقة).

الكاشات (Redis، Memcached)

فشل الكاش عادةً أقل كارثية من فشل قاعدة البيانات — الطلبات تتراجع إلى الاستعلام من قاعدة البيانات بدلاً من الفشل كلياً. لكن موجة من حالات فقدان الكاش بعد تعطل عقدة كاش يمكن أن تُثقل قاعدة البيانات وتتسبب في تأثير متسلسل. شغّل Redis في Redis Sentinel (استبدال تلقائي لزوج رئيسي+نسخة) أو Redis Cluster (مُجزَّأ، لكل جزء رئيسيه ونسخته). Memcached لا يدعم النسخ الأصلي؛ استخدم التجزئة المتسقة حتى يؤدي فشل عقدة إلى فقدان جزء فقط من الكاش.

DNS وشبكة توصيل المحتوى (CDN)

DNS في حد ذاته مكرر وفق المواصفات (خوادم أسماء متعددة)، لكن مزوّد DNS الخاص بك يمكن أن يكون نقطة فشل فردية. إذا شهد Route53 أو Cloudflare انقطاعاً، يصبح نطاقك غير قابل للوصول. الشركات الكبيرة تستخدم مزوّدَي DNS مع تفويض. شبكات CDN مثل Cloudflare تعمل كخوادم وكيلة عكسية مكررة وتستطيع تقديم المحتوى المخزن حتى حين يكون الأصل معطلاً — هيّئ شبكة CDN الخاصة بك لعرض صفحة محتوى قديمة أو صفحة صيانة عند فشل الأصل بدلاً من إعادة خطأ 502 للمستخدمين.

مناطق التوافر والمناطق الجغرافية

منطقة التوافر (AZ) هي مركز بيانات مادي منفصل داخل منطقة السحابة — طاقة مستقلة، شبكات مستقلة، وتبريد مستقل. توزيع مواردك عبر 2–3 مناطق توافر في المنطقة لا يكلف تقريباً شيئاً إضافياً ويحمي من فشل مركز بيانات كامل. التكرار متعدد المناطق يحمي من الانقطاعات الإقليمية (نادرة لكن عالية التأثير). يتطلب إما نشطاً-نشطاً مع موازنة حمل عالمية وقاعدة بيانات متسقة عالمياً أو تتسامح مع الاتساق النهائي، أو نشطاً-سلبياً مع استبدال قائم على DNS ومؤشرات RPO/RTO يمكنك تقبّلها.

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

التكرار N+1 — الحد الأدنى العملي

القاعدة الذهبية في الصناعة هي تكرار N+1: إذا كنت تحتاج إلى N نسخة لمعالجة حركتك الحالية، شغّل N+1. تلك النسخة الإضافية تعني أنك تستطيع تحمّل فشل واحد دون تراجع الطاقة. لمستهدفات توافر أعلى، يمكنك استخدام N+2 (يتحمل فشلَين متزامنَين) أو 2N (مجموعة مكررة كاملة — كل مكون مُضاعَف بالكامل، فمجموعة الاستعداد وحدها تستطيع معالجة 100% من الحمل). 2N شائع للأنظمة الحيوية وهو النموذج الذي يستخدمه AWS لعروض قواعد بيانات متعددة مناطق التوافر.

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

المصير المشترك ونطاق الفشل المستقل

يجب ألا تشترك المكونات المكررة في وضع فشل مشترك — وإلا فما يبدو نسختين مستقلتين يمكن أن يفشلا معاً. يُسمى هذا المفهوم المصير المشترك (Shared Fate). أمثلة حقيقية حيث يُدمّر المصير المشترك قيمة التكرار:

نسختا قاعدة بيانات على نفس المضيف المادي — فشل عتاد واحد يُسقطهما معاً.
خادمَا تطبيق في نفس منطقة التوافر أثناء انقطاع الطاقة في تلك المنطقة.
العقدة الرئيسية والنسخة كلتاهما تستخدمان نفس حجم EBS (خطأ تهيئة نادر في السحابة).
جميع نسخك الاحتياطية في نفس حساب AWS — اختراق الحساب أو سياسة حذف خاطئة تُدمّر جميع النسخ الاحتياطية دفعة واحدة.

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

تكلفة التكرار

التكرار ليس مجانياً. تشغيل N+1 خوادم تطبيق يكلف تقريباً 50% أكثر من N. نسخة احتياطية متزامنة لقاعدة البيانات في منطقة توافر أخرى يُضاعف تكلفة قاعدة بياناتك الرئيسية. نقل البيانات عبر مناطق التوافر في AWS يكلف 0.01 دولار/جيجابايت — هامشي لمعظم أحمال العمل لكن جوهري للخدمات عالية الإنتاجية.

مبرر الأعمال واضح: قارن تكلفة التكرار بتكلفة التوقف. ساعة توقف واحدة لخدمة SaaS بإيرادات 10 مليون دولار سنوياً تُمثّل حوالي 1,140 دولار خسارة مباشرة — زائداً تكاليف الدعم، مخاطر التراجع عن الخدمة، وعقوبات SLA. بضع مئات من الدولارات شهرياً في بنية تحتية إضافية تكاد تكون دائماً أرخص من الحادثة الأولى التي تمنعها.

حسابيات التوافر: مكوّنان مستقلان لكل منهما 99% توافر، إذا كان يمكن لأحدهما أن يستبدل الآخر، يُعطيان توافراً مشتركاً قدره 1 - (0.01 × 0.01) = 99.99%. الثلاثة يُعطون 99.9999%. التكرار هو الرافعة الرئيسية للانتقال من اثنين من التسعات إلى أربعة من التسعات من التوافر.

الخلاصة الرئيسية

نقطة الفشل الفردية هي أي مكون يؤدي فشله إلى توقف النظام بالكامل. دقّق كل طبقة.
النشط-النشط يُشغّل جميع العقد المكررة بشكل حي — لا هدر في الطاقة، واستبدال فوري. استخدمه للطبقات عديمة الحالة.
النشط-السلبي يُبقي نسخة احتياطية منزامنة — استبدال سريع لكن بتكلفة طاقة خاملة. استخدمه للطبقات ذات الحالة كقواعد البيانات.
وزّع المكونات المكررة عبر نطاقات فشل مستقلة (مضيفون، مناطق توافر، مناطق جغرافية منفصلة) — المصير المشترك يُبطل الغرض من التكرار.
N+1 هو الحد الأدنى المقبول للتكرار في الإنتاج. استخدم 2N للطبقات الحيوية التي يجب أن تنجو من فشل مجموعة نسخ كاملة.
التكرار في كل طبقة — موزّعات الحمل، خوادم التطبيقات، الكاشات، قواعد البيانات، DNS — يتراكم ليُعطي توافر أربعة تسعات من مكونات ذات تسعتَين.