كيف تتفادى Neon انقطاعات مزودي السحابة بتصميم Lakebase

عندما يتعرض مزود سحابي كبير مثل AWS لعطل في مستوى التحكم (Control Plane) على نطاق إقليمي، فإن النتيجة المعتادة لخدمات قواعد البيانات المُدارة هي انقطاع واسع النطاق: لا يمكن إنشاء نسخ جديدة، ولا تخصيص عناوين IP، وتتعطل آليات تجاوز الفشل (Failover) لأنها تعتمد على نفس واجهات برمجة التطبيقات (APIs) المتعطلة. تم تصميم بنية 'Lakebase' من Neon تحديدًا لتجاوز سلسلة التبعية القاتلة هذه. بدلاً من التعامل مع مزود السحابة كمنسق فوري للموارد، تقوم Neon بتخصيص السعة مسبقًا وعزل نطاقات الفشل بحيث لا يتحول انقطاع إقليمي في AWS تلقائيًا إلى انقطاع إقليمي في Neon.

تتناول هذه المقالة الآليات المعمارية المحددة - الحوسبة عديمة الحالة (Stateless Compute)، والعزل الخلوي (Cell-Based Isolation)، والتخزين الموزع عبر مناطق التوافر (Zone-Redundant Storage)، وتقليل الاعتماد على مستوى التحكم (Control Plane) - التي تستخدمها Neon لاحتواء الأضرار. وهي تستند إلى مراجعات الأعطال المنشورة من Neon، ووثائق الهندسة المعمارية، وتحليلات خارجية لإظهار كيف صمدت هذه الاستراتيجيات خلال انقطاع AWS في مايو 2026 في منطقة us-east-1، وما تخبرنا به عن مرونة التصميم في العالم الحقيقي.

الرؤية الجوهرية: فصل متانة الحوسبة عن توفرها

تنطلق هندسة Neon من مبدأ سهل القول وصعب التنفيذ بأمان: لا يجب أن تعيش أي حالة دائمة (Durable State) على عقدة الحوسبة التي تشغل Postgres. في خدمات Postgres المُدارة التقليدية، يكتب محرك قاعدة البيانات البيانات على وحدة تخزين (Volume) ملحقة محليًا. إذا تعطلت النسخة أو العتاد الذي يعمل تحتها، فإن الاسترداد يتطلب إما نسخة احتياطية ساخنة (Hot Standby) مع حالة مكررة، أو إجراء استرداد من الأعطال (Crash Recovery) يعيد تشغيل سجل الكتابة المسبقة (WAL) من مخزن العقدة المعطلة. كلا المسارين يعتمدان على قدرة مزود السحابة على توفير نسخ بديلة وإرفاق وحدات تخزين - وهذه هي القدرة ذاتها التي يمكن أن تتدهور خلال الانقطاعات الإقليمية .

تلغي Neon هذه التبعية بنقل كل الحالة الدائمة إلى طبقة تخزين منفصلة ومتكررة عبر مناطق التوافر (AZs). عُقد حوسبة Postgres في Neon لا تحتفظ بأي بيانات على القرص المحلي؛ إنها تعالج الاستعلامات وتدفق سجلات (WAL) إلى أسطول من عُقد 'حافظ الأمان' (Safekeeper) و'خادم الصفحات' (Pageserver) التي تخزن كل تغيير بشكل دائم . هذا يعني أن عطل عقدة الحوسبة يوقف معالجة الاستعلامات للحظة، ولكن لا يتم فقدان أي بيانات. يمكن لعقدة حوسبة جديدة أن تتصل بنفس سجل التخزين وتستأنف العمل من حيث توقفت العقدة السابقة، دون انتظار إعادة إرفاق وحدة التخزين أو الاسترداد من الأعطال .

العاقبة العملية خلال انقطاع في توفير موارد AWS كبيرة: لا تحتاج Neon لاستدعاء واجهات برمجة تطبيقات EC2 تحت ضغط العطل لاستبدال عُقد الحوسبة الميتة. يمكنها سحب بديل من مجمع مُعد مسبقًا من النسخ الجاهزة للعمل وإرفاقه بحالة التخزين الحالية. يصبح الضعف في مستوى التحكم لدى مزود السحابة مجرد إزعاج تشغيلي وليس حالة طوارئ لتوفر البيانات.

العزل الخلوي: المنطقة الواحدة لا تعني نطاق فشل واحد

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

خلال انقطاع AWS في مايو 2026 في us-east-1، أثر عطل مزود السحابة بشكل خاص على قدرته على توفير نسخ جديدة وتخصيص عناوين IP . بالنسبة لتصميم أحادي الخلية، لكان ذلك حادثًا على مستوى المنطقة بالكامل. في تصميم Neon القائم على الخلايا، فقط الخلايا التي استنفدت مخزونها المؤقت من الحوسبة المُعدة مسبقًا هي التي تأثرت. أما الخلايا الأخرى، التي تحمل مخزونًا كافيًا من النسخ المُخصصة مسبقًا، فقد استمرت في العمل دون انقطاع .

تعكس هذه النتيجة خيار تصميم متعمد: يتم تحديد حجم الخلايا بحيث لا تصبح حدود موارد أي خلية بمثابة عنق زجاجة إقليمي. وقد عززت الدروس المعمارية السابقة هذا التفكير. قبل الانتقال إلى العزل الخلوي، كانت Neon تشغل مجموعة Kubernetes واحدة لكل منطقة، وأظهرت الاختبارات تدهورًا في الخدمة بعد 10,000 قاعدة بيانات متزامنة بسبب حدود ذاكرة etcd في EKS، وقيود تكوين الشبكة، وتحديد معدل واجهة برمجة تطبيقات Kubernetes . تزيل البنية القائمة على الخلايا هذه السقوف أحادية المجموعة تمامًا عن طريق توزيع الحمل عبر خلايا مستقلة لا تتفاعل مع بعضها البعض.

تقليل الاعتماد على مزود السحابة من خلال التخصيص المسبق والمحاكاة الافتراضية المخصصة

علاقة Neon بمزود السحابة الأساسي هي علاقة بعيدة عن قصد. فبدلاً من استدعاء واجهات برمجة تطبيقات EC2 عند الطلب كلما احتاجت قاعدة بيانات للبدء، تقوم Neon بتخصيص مجمعات من النسخ الكبيرة - غالبًا من النوع bare-metal - مسبقًا وتحتفظ بسعة احتياطية لاستيعاب انقطاعات التزويد . هذا المخزون الاحتياطي ليس مجمعًا دافئًا صغيرًا للمستأجرين ذوي الأولوية؛ إنه مكون هيكلي لكيفية جدولة النظام لموارد الحوسبة.

علاوة على هذه النسخ المُعدة مسبقًا، تشغل Neon طبقة محاكاة افتراضية خاصة بها تقوم بالتوسع الرأسي التلقائي (Vertically Autoscaling) وتعبئ نسخ Postgres متعددة على مضيف مادي واحد. هذا يتجاوز تبعيتين لمزود السحابة في آن واحد: واجهة برمجة تطبيقات توفير الآلات الافتراضية (النسخ قيد التشغيل بالفعل) ومسار إرفاق التخزين الكتلي (عُقد الحوسبة في Neon لا تستخدم وحدات تخزين سحابية من نوع Block) .

تتبع متانة البيانات النمط نفسه. تقيم جميع محتويات قاعدة البيانات في خدمة التخزين المرنة إقليميًا الخاصة بـNeon، والمدعومة بمخازن الكائنات (Object Stores) مثل Amazon S3 أو Azure Blob Storage، بدلاً من أجهزة التخزين الكتلية لمزود السحابة . واجهات برمجة تطبيقات تخزين الكائنات لها أنماط فشل مختلفة عن واجهات توفير الآلات الافتراضية، ومن الناحية العملية، أثبتت متانة تخزين الكائنات أثناء انقطاعات مستوى التحكم الإقليمية أنها أكثر مرونة بكثير. عندما تتعطل عقدة 'خادم الصفحات' (Pageserver) أو 'حافظ الأمان' (Safekeeper)، لا تُفقد أي حالة دائمة - يمكن لعقدة أخرى إعادة بناء الصفحات الضرورية من سجل (WAL) وتخزين الكائنات .

التخزين الموزع عبر مناطق التوافر هو الأساس، وليس إضافة متميزة

في العديد من خدمات قواعد البيانات المُدارة، يعتبر نسخ التخزين عبر مناطق توافر متعددة (Multi-AZ) ميزة مدفوعة تتطلب تكوينًا صريحًا. في Neon، كل قاعدة بيانات - بغض النظر عن فئة التسعير - مدعومة بتخزين كائنات موزع ومتكرر عبر مناطق التوافر مع ذواكر تخزين مؤقت NVMe SSD منتشرة عبر مناطق توافر متعددة . هذا يزيل النسخ المادي عبر المناطق كمسألة منفصلة، لأن طبقة التخزين نفسها متكررة بطبيعتها.

يوفر تصميم نسخ سجل (WAL) ضمانات متانة ملموسة: يتم نسخ عمليات الكتابة بشكل متزامن إلى 'حفظة الأمان' (Safekeepers) مع شرط النصاب القانوني (Quorum) (النسخ السداسي مع نصاب كتابة 4 من 6 هو أحد التكوينات المنشورة)، مما يعني أن منطقة توافر كاملة بالإضافة إلى نسخة متماثلة أخرى يمكن أن تتعطل دون فقدان البيانات . هذه ليست مرونة نظرية؛ إنها خاصية لمسار الكتابة يجب أن تتحقق قبل إقرار المعاملات (Transactions) للعميل.

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

أهداف التوفر وما تظهره البيانات

تقع مؤشرات مستوى الخدمة (SLIs) المنشورة لتوفر بنية Lakebase من Neon في نطاق 99.93% إلى 99.96% تقريبًا . تعكس هذه الأرقام تصميمًا يتم فيه التعافي من أعطال الحوسبة عن طريق استبدال العُقد عديمة الحالة بدلاً من التبديل إلى نسخ احتياطية ساخنة خاملة، وحيث تتحقق متانة التخزين من خلال النسخ المدعوم بمخزن الكائنات بدلاً من انعكاس القرص المتزامن.

يقدم سجل أعطال Neon الخاص معايرة مفيدة لهذه الأهداف. تسبب حادث في مايو 2025 في us-east-1 في 5.5 ساعة من عدم توفر عمليات بدء وإنشاء قاعدة البيانات عبر حدثين منفصلين، على الرغم من أن قواعد البيانات النشطة ظلت غير متأثرة . السبب الجذري - استنفاد عناوين IP في شبكات Kubernetes الفرعية الناتج عن الحمل الزائد على مستوى التحكم وسوء تكوين AWS CNI - كشف عن حد توسع تم تصميم البنية الخلوية لاحقًا لمنعه . في وقت سابق، في أغسطس 2024، أثر انقطاع في 'خادم الصفحات' (Pageserver) في us-east-1 على ما يقرب من 0.4% من مشاريع العملاء لمدة تصل إلى ساعتين بعد عطل نسخة EC2؛ لأن 'خوادم الصفحات' تعمل كذاكرة تخزين مؤقت محلية مدعومة بـ S3، فإن فقدان 'خادم الصفحات' عنى عدم توفر مؤقت وليس فقدانًا دائمًا للبيانات .

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

اختبار المرونة: كيف تتحقق Neon من صحة التصميم

تذكر مدونة Neon الهندسية أنه يتم اختبار النظام ضد سيناريوهات الفشل في العالم الحقيقي بما في ذلك انقطاعات تزويد مزود السحابة ومحاكاة فصل منطقة توفر كاملة . تختبر هذه التجارب مجمعات النسخ المُعدة مسبقًا وحدود العزل الخلوي التي من المفترض أن تحد من نطاق الضرر. الشكل العام لهندسة الفوضى (Chaos Engineering) الذي تصفه Neon يعكس الممارسات الراسخة: تحديد فرضية الحالة المستقرة حول كيفية تصرف النظام تحت الفشل، حقن خطأ متحكم به (مثل فصل منطقة توفر بأكملها أو استنفاد مخازن الحوسبة)، مراقبة ما إذا كانت الفرضية صحيحة، ثم التكرار على الهندسة المعمارية عندما لا تكون كذلك .

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

ماذا يعني هذا للفرق التي تقيم Postgres بدون خادم

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

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

بالنسبة للفرق التي تبني على بنية تحتية بدون خادم (Serverless)، يُظهر نهج Neon أن احتواء نطاق الضرر ليس فكرة لاحقة - إنه نتاج لقرارات معمارية تُتخذ عند حدود التخزين والحوسبة وهيكل نطاق الفشل قبل وقت طويل من حدوث العطل.