چرا سرورهای Mythex را به ARM بردیم

در ۱۹ سپتامبر، بک‌اند production Mythex را از سرورهای x86 به سرورهای کوچک‌تر ARM مبتنی بر Graviton در AWS بردیم، و پایگاه‌داده‌ی پلتفرم را هم روی یک نمونه‌ی Graviton بردیم. محرک ساده بود: بعد از اینکه کارهای سنگین — اجرا و ساختن اپ هر کاربر — را به ساندباکس‌های ایزوله‌ی هر پروژه منتقل کردیم، سرورهای اصلی‌مان در اوج مصرف حدود یک‌سوم حافظه‌شان را استفاده می‌کردند. ماشین‌های کوچک‌تر ARM با بار واقعی جور بودند و صورتحساب ماهانه‌ی سرور را حدود ۳۰٪ کم کردند.

سرورهای ما حالا چه کاری می‌کنند

پیش‌تر، سرورهای بک‌اند خودشان کار زیادی را مستقیم انجام می‌دادند. حدود اواسط سپتامبر بخش‌های پرهزینه — اجرای کد هر پروژه، نصب بسته‌ها، ساختن اپ‌ها — را به ساندباکس‌های ابری خصوصی، یکی برای هر پروژه، منتقل کردیم. همین است که به هر پروژه یک محیط جدا و پیش‌نمایش زنده‌ی خودش می‌دهد.

آنچه روی سرورهای خودمان ماند هماهنگی است: API، ارکستراتوری که ساندباکس‌ها و انتشار را مدیریت می‌کند، احراز هویت، صورتحساب و gateway. این کار پایدار و سبک است. بعد از انتقال، سرورها حدود ۱٫۳ گیگابایت حافظه در اوج مصرف داشتند، روی ماشین‌هایی با حدود سه برابر آن.

چرا ARM

پردازنده‌های Graviton در AWS پردازنده‌های ARM هستند که خود AWS طراحی کرده. با هزینه‌ی برابر معمولاً ظرفیت بیشتری نسبت به یک نمونه‌ی x86 قابل مقایسه می‌گیرید، یا همان ظرفیت را ارزان‌تر — و برای باری مثل ما (سرویس‌های Node.js، Docker، Postgres) چیزی ما را به x86 وابسته نمی‌کند.

ما این‌ها را منتقل کردیم:

• دو سرور اپ از نمونه‌های x86 با اندازه‌ی متوسط به نمونه‌های کوچک Graviton با ۲ گیگابایت RAM برای هرکدام.
• پایگاه‌داده‌ی پلتفرم از یک نمونه‌ی کوچک پایگاه‌داده‌ی x86 به معادل Graviton آن.

یک پیچیدگی واقعی: image برای دو معماری

سرور staging ما هنوز روی یک سرور کوچک x86 اجرا می‌شود. production حالا روی ARM است. یک image کانتینر که برای یکی ساخته شده روی دیگری اجرا نمی‌شود.

پس حالا هر image برای هر دو معماری زیر یک تگ ساخته می‌شود — یک image چندمعماریه. Docker نسخه‌ی درست را روی هر ماشین خودکار انتخاب می‌کند، و pipeline استقرار لازم نیست بداند دارد به کدام محیط می‌فرستد. هزینه‌اش یک build طولانی‌تر در CI است؛ مزیتش این است که staging و production دقیقاً همان کد را از دقیقاً همان تگ اجرا می‌کنند.

برنامه‌ریزی بازگشت پیش از انتقال

تغییر معماری CPU زیر یک سرویس زنده تغییری است که بهتر است بشود آن را در دقایق برگرداند. پیش از تغییر:

• نسخه‌ی قبلی قالب سرور را به‌عنوان هدف بازگشت نام‌دار نگه داشتیم،
• درست قبل از تغییر اندازه‌ی پایگاه‌داده، یک snapshot از پایگاه‌داده گرفتیم، و
• یک runbook نوشتیم که انتقال و راه برگشت را پوشش می‌دهد.

به بازگشت نیاز پیدا نکردیم. باز هم همین‌طور انجامش می‌دادیم.

چیزهایی که مراقبش هستیم

سرورهای کوچک‌تر فضای کمتری دارند. دو چیز از این نتیجه می‌شود:

1. اگر کار سنگین دوباره روی این سرورها بیفتد، ۲ گیگابایت کافی نیست. راه حل آن یک اندازه‌ی بزرگ‌تر Graviton است، نه بازگشت به x86.
2. ماشین‌های کوچک به swap نیاز دارند. یک هفته بعد یکی از این سرورها از فشار حافظه یخ زد، بی‌آنکه از نظر فنی حافظه تمام شده باشد — داستان فایل swap که نبود.

آنچه از آن برداشتیم

• بعد از تغییر معماری دوباره اندازه بگیرید. انتقال کارها به ساندباکس‌ها آنچه سرورهای ما لازم داشتند را تغییر داد؛ اندازه‌ی نمونه‌ها عقب مانده بودند.
• ARM برای پشته‌های وب معمول یک برد کم‌ریسک است، وقتی image هایتان چندمعماریه باشند.
• اول بازگشت را بنویسید. حتی اگر هرگز از آن استفاده نکنید، تغییر را آرام‌تر می‌کند.