"The Night the Sovereign Cloud Almost Died: A Tale of Latency, AI, and Kubernetes Survival"

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.
في تمام الساعة الثانية صباحاً، وتحت الضوء المنبعث من الشاشة فقط، كنت أُجري اختبارات الإجهاد على منصة SovereignStack—المشروع الذي استغرق تطويره ستة أشهر متواصلة من العمل المكثف. كانت الاختبارات القياسية تسير بسلاسة، ولكن فور إطلاق محاكاة لهجوم حجب الخدمة الموزع (DDoS)، انهارت الاستجابة البرمجية للنظام كلياً.

خلال 15 ثانية فقط، قفز معدل استهلاك المعالج إلى 95%، وتصاعد استهلاك الذاكرة بشكل حاد، فيما توقفت خدمة الذكاء الاصطناعي (Gemini AI)—المسؤولة عن التحليل الأمني الفوري—عن الاستجابة تماماً. كان من شأن هذا الانهيار، لو حدث أثناء التقييم الفعلي أمام الهيئة الوطنية للأمن السيبراني (NCA)، أن ينهي المشروع كاملاً. لم أكن أعلم حينها أن تلك الليلة ستعيد تشكيل رؤيتي المعمارية لبناء البرمجيات بشكل جذري.

كانت البنية الهندسية للنظام تبدو واعدة على الورق: واجهة مستخدم مبنية بـ React، وخلفية برمجة بـ Node.js/Express، مع إطار Kubernetes لإدارة الحاويات وعزلها، ونظام Vault لتشفير مفاتيح HMAC، إضافة إلى ربط مستمر بحزمة Gemini SDK لتحليل السجلات الأمنية بشكل لحظي. وبصفتها منصة سيادية (PaaS)، فإن أي خلل في المعالجة قد يؤدي لتسريب بيانات حكومية حساسة.

لم يكمن الخلل في الأدوات ذاتها، بل في التسلسل المتزامن لعمليات الطلب (Request Pipeline)؛ إذ كان كل طلب يمر بسلسلة خطية مجهدة: التحقق من مفتاح HMAC عبر Vault، ثم استعلام بيانات المستأجر من PostgreSQL، وتسجيل النشاط في Redis، وانتظار معالجة Gemini AI للسجلات، قبل إرسال الاستجابة النهائية للمستخدم. في بيئة التطوير المحلية، كانت العملية تستغرق نحو 200 مللي ثانية، وهو معدل ممتاز، لكن تحت ضغط آلاف الطلبات في الثانية، تحول هذا التأخير التراكمي إلى اختناق حاد في المعالجة (Throughput Bottleneck)، مما أدى لتكدس الطلبات وتجميد الخيوط البرمجية أثناء انتظار رد الذكاء الاصطناعي.

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

خلال 36 ساعة من العمل المتواصل، أعدت هيكلة النظام عبر ثلاث خطوات رئيسية:

1. تحويل المعالجة إلى نمط غير متزامن (Asynchronous Architecture): التخلص من الانتظار المباشر عبر إنشاء ناقل أحداث (Event Bus) معتمد على Redis Pub/Sub. بموجب هذا التصميم، يُرسل الخادم السجل إلى الناقل ويرد على المستخدم في أجزاء من الملي ثانية، بينما تتولى وحدات معالجة خلفية (Workers) تحليل السجلات وتخزين النتائج مؤقتاً في Redis Cache لمدة 10 دقائق لتجنب تكرار التحليل. انخفض زمن الاستجابة جراء ذلك من 200 مللي ثانية إلى أقل من 40 مللي ثانية.
2. إدارة جلسات المفاتيح (Session Caching): للحد من الضغط المفرط على خادم Vault الناتج عن التحقق المباشر مع كل طلب، أصبح الخادم يقرأ المفتاح مرة واحدة عند تشغيل الحاوية ويحفظه في ذاكرة محلية (Local Map) لمدة 5 دقائق، مع رفض أي توقيع غير مطابق فوراً، مما خفّض الحمل على Vault بنسبة 70%.
3. إدارة الذاكرة والحماية من الانهيار: لمنع أخطاء نفاد الذاكرة (OOM)، اعتمدت تقنية تجميع المخازن (Buffer Pooling) في Node.js لإعادة استخدام الكائنات المخصصة بدلاً من إنشائها باستمرار، مع تفعيل نمط قاطع الدائرة (Circuit Breaker) لإرجاع خطأ 503 فوراً إذا تجاوز الحمل 85%، منحاً للنظام فرصة للتعافي.

في تمام الساعة الخامسة صباحاً، أعدت تشغيل المنظومة وأجريت المحاكاة من جديد. أظهرت لوحة المراقبة استجابة مختلفة تماماً؛ ارتفع المؤشر مؤقتاً لكنه استقر بسرعة، حيث فعّلت أداة HPA في Kubernetes التوسع الأفقي للأحمال بنجاح. خلال 2.1 ثانية فقط، امتص النظام الصدمة واستقر، وبدأت سجلات Gemini AI تُعالج في الخلفية بشكل دوري كل 5 ثوانٍ دون أي أثر على سرعة الواجهة.

أثبتت هذه التجربة أن الأداء العالي في الأنظمة السيادية ليس مجرد تحسين تحسيني، بل هو خط الدفاع التشغيلي الأول. صرت أطرح عند كتابة أي وحدة برمجية أسئلة تتجاوز صحة الوظيفة المباشرة لتشمل: كيف ومتى تُدار أولويات التنفيذ تحت الضغط العالي؟ وعندما ترى منصة PaaS تستجيب في أقل من 50 مللي ثانية، فاعلم أن وراءها معمارية جرى صقلها عبر التعامل المباشر مع اختناقات الـ Event Loop وآليات التخزين المؤقت.

هل واجهتم تحديات معمارية مماثلة في التعامل مع اختناقات الأداء أو استدعاءات API أثناء ذروة الاستخدام؟ أرحب بمشاركة تجاربكم التقنية في هذا الصدد.