توجيه حركة مرور الفيديو في منطقة آسيا والمحيط الهادئ باستخدام etcd
نجحت منصة لبث الفيديو تخدم ثماني أسواق في منطقة آسيا والمحيط الهادئ في إيقاف خطأ متكرر في التوجيه عبر نقل الإعدادات الخاصة بكل منطقة إلى etcd. انخفض وقت انتشار تغييرات التوجيه إلى حوالي ثانية واحدة. أصبح بإمكان المحررين الآن تعزيز مجموعة موسيقية معينة لبضع ساعات دون المساس بالكود، وتوقفت المنصة عن إرسال بث طوكيو للمشاهدين في كوريا الجنوبية.
لماذا فشل النهج القديم
كان كل موجه (router) يقرأ ثلاث قيم لكل طلب: مجموعة المحتوى الرائج (trending pool)، والمحلل اللغوي الخاص بكل لغة (language-specific tokenizer)، وسلسلة التراجع (fallback chain). كانت القرارات التجارية — مثل الترويج لفنان جديد، أو الاستجابة لانقطاع إقليمي، أو اختبار خوارزمية توصية — هي التي تقود هذه القيم، وليس تغييرات الكود.
في البداية، كان كل نشر (deployment) يتضمن ملف JSON يحتوي على جدول التوجيه. وأثناء إحدى الحوادث، قام مهندس المناوبة بتعديل الملف على عقدة (node) واحدة لتوجيه حركة المرور إلى مجموعة احتياطية، لكنه لم يقم بتحديث العقد السبع الأخرى أبدًا. أدى ذلك إلى ظهور "انحراف في الإعدادات" (config drift): حيث كانت ثماني دول تعمل بجداول متباينة، ولم يكن هناك مصدر واحد يتحقق من "الحقيقة". استمر الخطأ الذي يرسل مشاهدين من سيول إلى طوكيو لأن الكود ظل كما هو؛ بل اختلف فقط الإعداد المخفي.
اختيار etcd كمصدر وحيد للحقيقة
قارن الفريق بين ثلاثة خيارات:
- SQLite/MySQL – كان سيجبر كل موجه على الاستعلام (polling) من قاعدة بيانات، مما يضيف تأخيرًا (latency) أو يغرق النظام بالاستعلامات.
- Consul – أداة قوية لاكتشاف الخدمات (service-discovery)، لكن المنصة لم تكن بحاجة إلى ميزات الشبكة الكاملة (mesh features) الخاصة بها.
- etcd – مخزن قيم ومفاتيح (key-value store) يتميز باتساق قوي (strongly consistent) مع خاصية watch التي تُخطر العملاء في اللحظة التي يتغير فيها المفتاح.
رجحت كفة خاصية watch. فبدلاً من أن يسأل كل موجه بشكل متكرر "هل تغير شيء ما؟"، ظلت الموجهات في حالة انتظار حتى يقوم etcd بدفع التحديث. اختفت حركة مرور الشبكة غير الضرورية، وتعرفت كل نسخة (instance) على التغيير في آن واحد.
أنماط تحافظ على سلامة النظام
لم يحل etcd وحده جميع المخاطر، لذا أضاف المهندسون ثلاثة أنماط تكميلية:
- Leases – يمكن للمحرر ضبط تعزيز مؤقت (على سبيل المثال، زيادة وزن مجموعة الكيبوب الكورية لمدة ست ساعات). تنتهي صلاحية عقد الإيجار (lease) تلقائيًا، لذا يختفي التعزيز دون الحاجة إلى تراجع يدوي.
- Compare-and-swap (CAS) – عندما يقوم شخصان بتعديل الإعداد نفسه في وقت واحد، تفشل عملية CAS بشكل صريح لأحدهما، مما يمنع عمليات الكتابة فوق البيانات (overwrites) الصامتة.
- Sidecar process – تواجه PHP صعوبة في التعامل مع الاتصالات طويلة الأمد. لذا يقوم "sidecar" صغير مكتوب بلغة Go على كل جهاز بمراقبة etcd وكتابة لقطة (snapshot) لجدول التوجيه في ملف ذاكرة مشتركة (
/dev/shm). تقرأ PHP ذلك الملف المحلي، مما يتجنب أي رحلة ذهاب وإياب عبر الشبكة (network round-trip) أثناء معالجة الطلبات.
مرونة مدمجة في البنية التحتية
يضيف التصميم الجديد عدة شبكات أمان:
- Zero-latency reads – يقرأ المسار السريع (hot path) في PHP من الذاكرة المحلية، لذا لا تتوقف الطلبات أبدًا بانتظار مخزن بعيد.
- Graceful degradation – في حال تعطل etcd، تستمر الموجهات في تقديم آخر إعداد جيد معروف، مما يمنع الانقطاع المفاجئ.
- Reliable updates – يتولى الـ sidecar منطق إعادة الاتصال ويضمن عدم تفويت أي تغيير، حتى لو انقطع الاتصال بـ etcd مؤقتًا.
ما الذي تغير على أرض الواقع
بعد عملية الانتقال، شهد الفريق انخفاضًا حادًا في الحوادث الناتجة عن بيانات التوجيه القديمة أو غير المتطابقة. تعرض وحدة تحكم (console) واحدة الآن الإعدادات الحالية، وأي تعديل ينتشر في جميع المناطق الثماني في غضون ثانية واحدة. كما أن التعزيزات المؤقتة تُحذف تلقائيًا عند انتهاء صلاحية عقدها، مما يلغي خطوات التنظيف اليدوية التي كانت تؤدي سابقًا إلى أخطاء بشرية.
وجهة نظر معارضة: تكلفة الـ sidecar
إضافة sidecar تعني وجود عملية ثانية لكل خادم وبيئة تشغيل Go في بيئة تعتمد بشكل أساسي على PHP. يقلق بعض المشغلين من استهلاك الذاكرة الإضافي والحاجة إلى مراقبة ملف ثنائي (binary) آخر. ولكن من الناحية العملية، يظل حجم الـ sidecar متواضعًا، وتفوق مكاسب الموثوقية — وخاصة ضمان عدم توقف PHP أبدًا بسبب استدعاء شبكة — الأعباء التشغيلية الإضافية.
ما يجب مراقبته لاحقًا
يجب على الفرق التي تدير خدمات متعددة المناطق مراقبة ما يلي:
- etcd health metrics – تعتمد طبقة التوجيه على مخزن واحد؛ لذا يجب مراقبة حالة النصاب القانوني (quorum status) والتأخير (latency).
- Lease expiration handling – يجب مطابقة أوقات العقود (lease times) مع النوافذ الزمنية للأعمال؛ فالعقود الطويلة جدًا تترك تعزيزات قديمة قائمة.
- Scaling the watch load – مع زيادة عدد الموجهات، تزداد اتصالات الـ watch؛ لذا يجب التخطيط لسعة خوادم etcd بناءً على ذلك.
الخلاصة
لأي خدمة تتطلب تغييرات سريعة ومنسقة في الإعدادات عبر مناطق متعددة، توفر بدائيات etcd المتمثلة في watch و lease و transaction بديلاً خفيف الوزن ومتسقاً بقوة للإعدادات القائمة على الملفات أو الشبكات (meshes) الثقيلة. لقد أدى تحويل الإعدادات إلى مخزن يعتمد على نظام الدفع (push-driven) وذاتي التنظيف إلى القضاء على فئة كاملة من الحوادث، ومنح المنصة تحكماً في الوقت الفعلي في منطق التوجيه الخاص بها.