تخطَّ إلى المحتوى
كل الرؤى

من داخل بنية ووردبريس + AWS للأخبار العاجلة

جعفر أبازيد

WordPress AWS Architecture Newsrooms
مستوى زيارات طبيعي يتحول إلى موجة هائلة من الزيارات مع خبر عاجل، داخل بنية ووردبريس + AWS للأخبار العاجلة، رؤى منطق

عندما يقع خبر عاجل، لا ترتفع أعداد الزيارات تدريجياً، بل تنفجر. صفحة كانت تخدم بضع مئات من القرّاء المتزامنين صباحاً قد تجد نفسها أمام عشرات الآلاف خلال دقائق. والمفارقة القاسية أن الصفحة الأكثر أهمية في الموقع، صفحة الخبر العاجل نفسها، تكون غالباً أول ما يتوقف عن الاستجابة.

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

لماذا يفشل الخادم الواحد؟

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

  • تبلغ قاعدة البيانات حدّها الأقصى. كل طلب يتجاوز الذاكرة المؤقتة Cache Miss يتحول إلى موجة من الاستعلامات. قاعدة البيانات التي تعاملت بسهولة مع زيارات الصباح تصل إلى سقف الاتصالات خلال ثوانٍ.
  • التدافع على الذاكرة المؤقتة (Cache stampede) الخبر جديد، ولم يُخزَّن بعد. وعندما يطلبه عشرة آلاف قارئ في اللحظة نفسها، يفشل الجميع في العثور عليه داخل الذاكرة المؤقتة وتتوجه الطلبات جميعها إلى الخادم الوحيد في الوقت ذاته.
  • يتعثر العمل التحريري. الخادم نفسه الذي يعجز عن خدمة القرّاء هو الخادم الذي يحاول المحررون من خلاله نشر التحديثات. فتتباطأ غرفة الأخبار في اللحظة التي تحتاج فيها إلى أن تكون أسرع ما يمكن.

زيادة حجم الخادم لا تحل المشكلة؛ بل تؤجلها فقط. الحل الحقيقي معماري: فصل النظام التحريري عن نظام التوزيع.

الفصل: ووردبريس لغرفة الأخبار، وAWS للأحمال

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

  • CloudFront يخدم القرّاء من شبكة Edge العالمية. الصفحات والوسائط تُخزَّن بالقرب من كل قارئ، ويتم تجهيزها مسبقاً بحيث تصل موجة الزيارات إلى Cache على Edge، لا إلى ووردبريس.
  • S3 يحتفظ بالوسائط والأصول الرقمية. يُرفع الفيديو أو معرض الصور مرة واحدة، ثم يُخدم من Object Storage بدلاً من قرص خادم ووردبريس.
  • Lambda تتولى الأعمال الديناميكية التي تتوسع مع الزيارات. Serverless Compute يتوسع تلقائياً عند وصول موجة الزيارات، ثم يتراجع بهدوء بعد انتهائها.
  • SNS وSES يتوليان إرسال إشعارات الأخبار العاجلة ورسائل النشرات البريدية، بحيث لا تجد مليون رسالة نفسها في طابور انتظار خلف خادم ويب يعاني تحت الضغط.
  • API Gateway يستقبل الطلبات القادمة من المستهلكين بنمط Headless، التطبيقات الأصلية ومنصات OTT وغيرها، من دون تعريض بيئة تشغيل ووردبريس مباشرة للإنترنت العام.

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

ما الذي استطاعت هذه البنية تحمله؟

أرقام من بيئة تشغيل فعلية، مع إخفاء هوية المؤسسة:

  • 50K قارئ متزامن في اختبارات الحمل
  • 20× من الحركة المعتادة أثناء الأخبار العاجلة
  • 100% نسبة توفر، من دون أي انقطاع سببه ارتفاع الأحمال
  • 5 سنوات في الإنتاج

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

المبادئ الأساسية إذا أردت بناء شيء مشابه

  1. جهّز Edge مسبقاً. لا تجعل أول عشرة آلاف قارئ يتسابقون نحو صفحة غير موجودة في Cache. يجب أن تعني عملية النشر أن الصفحة مخزنة على Edge، لا متاحة فقط على Origin.
  2. أبعد المحررين عن مسار القراءة. النظام الذي يكتب فيه الصحفيون يجب ألا يكون هو النظام الذي يضغط عليه القرّاء طوال اليوم.
  3. اجعل العمليات المكلفة قائمة على الأحداث. الإشعارات، وعمليات الترميز Transcoding، والتوزيع على المنصات الأخرى: نفّذها بشكل غير متزامن. لا ينبغي لأي شيء يواجه المستخدم مباشرة أن ينتظر اكتمالها.
  4. ادفع مقابل الزيارات، لا مقابل الخوف منها. إذا كانت فاتورة البنية التحتية ثابتة بينما الزيارات متقلبة، فأنت تدفع ثمن خوادم خاملة على سبيل الاحتياط. Serverless يعكس هذه المعادلة.

هذه البنية، والفريق الذي شغّلها، هي الأساس الذي تقوم عليه ممارسة ووردبريس + AWS في منطق.

إذا كانت الزيارات ترتفع لديكم تحديداً في اللحظات التي لا تحتمل التعثر، فلنتحدث.

هل هناك ما يدور في عقلك؟

سواء كنت تبحث عن حل لمشكلة ما أو تبني نظاماً يدوم للمستقبل، أخبرنا بما تعمل عليه، يسرّنا أن نساعدك.