ترحيل بدون توقّف مع نموّ في الأداء بمقدار الضعف - قصّة تحوّل فيبي

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

كانت البنية التحتية القائمة عبارة عن إعداد أحادي الخادم على منصّة ReadyMage المُدارة، حيث تتشارك جميع الخدمات الموارد نفسها. فقد كانت Varnish وPHP وMariaDB وOpenSearch وRabbitMQ وRedis ولوحة إدارة Magento متمركزة معًا على مثيل واحد. وكان من شأن ارتفاع مفاجئ في الذاكرة من مفهرس أن يعطّل طلبات المستخدمين. وكان تحديث وحدة بإعدادات خاطئة قد يعطّل استجابات GraphQL دون ظهور خطأ واحد في سجلّات PHP. لم يكن هناك عطل كارثي، لكن المنصّة لم تكن متوائمة مع النطاق الذي كانت فيبي تتّجه إليه، وكانت الفجوة تتّسع.

بالنسبة إلى فيبي، تطلّب اختيار الشريك المناسب للبنية التحتية لترحيل متجر إلكتروني نشط ثقةً ليس في القدرة التقنية فحسب، بل في الخبرة الخاصة بالمنصّة. فدمج Magento مع ScandPWA، والتوجيه بلا رأس، وتبعيات مخطّط GraphQL، وقواعد Varnish VCL الخاصة بالـ PWA هو تركيبة قلّة من الفِرق مؤهّلة لتشغيلها بشكل صحيح.

وبعد تقييم شامل، منح عمقنا المجتمع في هندسة Magento وتوافق ScandPWA وهندسة السحابة على AWS فيبي الطمأنينة للمضي قدمًا.

بدلًا من ترحيل مطابق إلى مضيف جديد، صمّمنا بنية متعدّدة العُقَد مخصّصة لغرض محدّد تفصل كل مسؤولية خدمية وتقضي على نقاط الفشل المنفردة. فقد نُشرت ست عُقَد مخصّصة داخل شبكة افتراضية خاصة (VPC) عبر ثلاث مناطق توافر على AWS في منطقة الإمارات: عُقدة Bastion للوصول الآمن، وعُقدة Varnish للتخزين المؤقت للصفحات الكاملة، وعُقدة Web تشغّل Nginx وPHP-FPM خلف مجموعة تحجيم تلقائي (Auto Scaling Group)، وعُقدة Admin مخصّصة معزولة عن كل الزيارات، وعُقدة Services تضمّ OpenSearch وMariaDB وRedis وRabbitMQ دون أي انكشاف عام، وعُقدة Prerender للتصيير الذاتي الاستضافة لروبوتات محركات البحث.

ونُقلت ملفات الوسائط والتطبيق المشتركة إلى Amazon EFS، وجرى تركيبها عبر العُقَد لضمان وصول متّسق دون عبء النسخ المتكرّر. أمّا عملية التحويل نفسها فنُفّذت بدون أي توقّف. فقد خُفّضت مدد بقاء DNS (TTL) قبل أيام، وجرى التحقّق الكامل من البيئة الجديدة بالتوازي قبل تحويل أي زيارة، واستُخدمت Cloudflare طبقةً للتحكّم في الزيارات لتوجيه الطلبات الحيّة تدريجيًا إلى البنية التحتية الجديدة، فيما ظلّ إجراء التراجع جاهزًا للتفعيل طوال الوقت.

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

دقّق فريقنا كل وحدة Magento مثبّتة للتأكّد من توافقها مع Magento 2.4.6-p6 وPHP 8.1 وOpenSearch 2.12.0. وحيثما لم تتوفّر تصحيحات من المورّد، طُبّقت إصلاحات على مستوى الشيفرة مباشرة. وجرى ضبط إعدادات مجمّعات PHP-FPM، وتهيئة OPcache، ومعاملات Nginx FastCGI، وقواعد Varnish VCL، والإشراف على مستهلكي RabbitMQ، خصّيصًا لأنماط طلبات ScandPWA كثيفة الاعتماد على الـ API، وليس فقط لـ Magento القياسي.

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

نشرنا خدمة تصيير مسبق ذاتية الاستضافة على عُقدة m7i.large مخصّصة داخل الشبكة الافتراضية الخاصة. وجرى تحديث Nginx في طبقة الويب لتوجيه زيارات الروبوتات إلى خدمة التصيير المسبق الداخلية، وأُرسيت استراتيجية لتسخين التخزين المؤقت للصفحات ذات الأولوية العالية. وقد قضى النموذج الذاتي الاستضافة على زمن الاستجابة الخاص بالطرف الثالث، وأزال تصاعد التكلفة مع كل عملية تصيير، ومنح فيبي تحكّمًا كاملًا في كيفية تصيير الصفحات وموعده، وهي قدرة تدعم أداء تحسين محركات البحث على نطاق واسع بشكل مباشر.