لماذا نقلنا خوادم Mythex إلى ARM

في 19 سبتمبر نقلنا الواجهة الخلفية للإنتاج في Mythex من خوادم x86 إلى خوادم AWS Graviton الأصغر المبنية على ARM، ونقلنا قاعدة بيانات المنصة إلى نسخة Graviton أيضاً. كان السبب بسيطاً: بعد أن نقلنا العمل الثقيل، أي تشغيل كل تطبيق للمستخدمين وبنائه، إلى بيئات سحابية معزولة لكل مشروع، كانت خوادمنا الرئيسية تبلغ ذروة استخدامها للذاكرة عند نحو الثلث. وأجهزة ARM الأصغر تناسب الحمل الفعلي وتخفض فاتورة الخوادم الشهرية بنحو 30%.

ما الذي تفعله خوادمنا الآن؟

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

وما بقي على خوادمنا هو التنسيق: الواجهة البرمجية، والمنسّق الذي يدير البيئات والنشر، والمصادقة، والفوترة، والبوابة. هذا العمل ثابت وخفيف. وبعد النقل، كانت الخوادم تبلغ ذروة تقارب 1.3 GB من الذاكرة على أجهزة تملك نحو ثلاثة أضعاف ذلك.

لماذا ARM؟

معالجات Graviton من AWS هي شرائح ARM صممتها AWS. عند السعر نفسه تحصل عادة على قدرة أكبر من نسخة x86 مماثلة، أو القدرة نفسها بتكلفة أقل. ولحمل عمل مثل حملنا (خدمات Node.js وDocker وPostgres) لا شيء يربطنا بـ x86.

نقلنا:

• خادمي التطبيقات من نسخ x86 متوسطة الحجم إلى نسخ Graviton صغيرة بذاكرة 2 GB لكل منهما.
• قاعدة بيانات المنصة من نسخة قاعدة بيانات صغيرة على x86 إلى نظيرتها Graviton.

المعضلة الحقيقية الوحيدة: صور لمعماريتين

خادم الاختبار لدينا ما زال يعمل على خادم x86 صغير. والإنتاج يعمل الآن على ARM. وصورة الحاوية المبنية لمعمارية لن تعمل على الأخرى.

لذلك صارت كل صورة تُبنى لـ المعماريتين معاً تحت وسم واحد، أي صورة متعددة المعماريات. يختار Docker النسخة المناسبة على كل جهاز تلقائياً، ولا يحتاج خط النشر إلى معرفة البيئة التي يدفع إليها. الثمن هو بناء CI أطول؛ والفائدة أن الاختبار والإنتاج يشغّلان الكود نفسه تماماً من الوسم نفسه.

تخطيط التراجع قبل النقل

تغيير معمارية المعالج تحت خدمة حية هو نوع التغيير الذي تريد أن تستطيع التراجع عنه خلال دقائق. قبل التبديل:

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

لم نحتج إلى التراجع. ونفعل الشيء نفسه مرة أخرى.

ما الذي سنراقبه

الخوادم الأصغر تملك مساحة أقل. ويترتب على ذلك أمران:

1. إذا انتقل العمل الثقيل إلى هذه الخوادم يوماً ما، فـ 2 GB لن تكفي. الحل حينها هو حجم Graviton أكبر، لا العودة إلى x86.
2. الأجهزة الصغيرة تحتاج إلى swap. بعد أسبوع تجمّد أحد هذه الخوادم بسبب ضغط الذاكرة دون أن ينفد فعلياً من الذاكرة من الناحية التقنية، قصة ملف swap المفقود.

ما الذي استخلصناه

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