ہم نے Mythex کے سرورز ARM پر کیوں منتقل کیے

19 ستمبر کو ہم نے Mythex کا production backend x86 سرورز سے چھوٹے ARM پر مبنی AWS Graviton سرورز پر منتقل کیا، اور platform database بھی ایک Graviton instance پر لے گئے۔ وجہ سادہ تھی: بھاری کام، یعنی ہر صارف کی ایپ چلانا اور بنانا، ہم نے الگ تھلگ فی-project sandboxes میں منتقل کر دیا تھا، تو ہمارے بنیادی سرورز اپنی memory کا تقریباً ایک تہائی استعمال کر رہے تھے۔ چھوٹی ARM مشینیں اصل بوجھ کے لیے کافی ہیں اور ماہانہ سرور بل تقریباً 30 فیصد کم کرتی ہیں۔

اب ہمارے سرورز اصل میں کیا کرتے ہیں

پہلے backend سرورز خود بہت کام کرتے تھے۔ ستمبر کے وسط تک ہم نے مہنگے حصے، یعنی ہر project کا کوڈ چلانا، packages انسٹال کرنا، ایپس بنانا، ایک ایک project کے لیے نجی cloud sandboxes میں منتقل کر دیے۔ یہی ہر project کو اپنا الگ ماحول اور live preview دیتا ہے۔

جو ہمارے اپنے سرورز پر رہ گیا ہے وہ رابطہ کاری ہے: API، وہ orchestrator جو sandboxes اور publishing کو سنبھالتا ہے، authentication، billing، اور gateway۔ یہ کام مستقل اور ہلکا ہے۔ منتقلی کے بعد سرورز تقریباً 1.3 GB memory پر تھے، جبکہ مشینوں میں اس سے تقریباً تین گنا تھا۔

ARM کیوں

AWS کے Graviton processors، AWS کے ڈیزائن کردہ ARM chips ہیں۔ اسی قیمت پر آپ کو عام طور پر ایک مماثل x86 instance سے زیادہ capacity ملتی ہے، یا اتنی ہی capacity کم قیمت پر — اور ہمارے جیسے کام کے لیے (Node.js services، Docker، Postgres) ہمیں x86 سے کوئی چیز نہیں باندھتی۔

ہم نے منتقل کیا:

• دو app سرورز درمیانے x86 instances سے چھوٹے Graviton instances پر، جن میں سے ہر ایک میں 2 GB RAM ہے۔
• Platform database ایک چھوٹے x86 database instance سے اس کے Graviton ہم منصب پر۔

ایک اصل پیچیدگی: دو architectures کے لیے images

ہمارا staging ماحول اب بھی ایک چھوٹے x86 سرور پر چلتا ہے۔ Production اب ARM پر چلتا ہے۔ ایک کے لیے بنی container image دوسرے پر نہیں چلتی۔

اس لیے ہر image اب ایک tag کے تحت دونوں architectures کے لیے بنتی ہے، یعنی ایک multi-arch image۔ Docker ہر مشین پر خودکار طور پر درست variant چنتا ہے، اور deploy pipeline کو یہ جاننے کی ضرورت نہیں کہ وہ کس ماحول میں push کر رہی ہے۔ قیمت یہ ہے کہ CI build لمبا ہے؛ فائدہ یہ ہے کہ staging اور production بالکل ایک ہی tag سے بالکل ایک ہی کوڈ چلاتے ہیں۔

منتقلی سے پہلے rollback کی منصوبہ بندی

چلتی ہوئی سروس کے نیچے CPU architecture بدلنا ایسی تبدیلی ہے جسے آپ منٹوں میں واپس لینا چاہتے ہیں۔ تبدیلی سے پہلے ہم نے:

• پچھلا server template ورژن ایک نامزد rollback ہدف کے طور پر رکھا،
• database کا resize کرنے سے ٹھیک پہلے database کا snapshot لیا، اور
• منتقلی اور واپسی کے طریقے پر مشتمل ایک runbook لکھا۔

ہمیں rollback کی ضرورت نہیں پڑی۔ ہم پھر بھی اسی طرح کریں گے۔

ہم کس چیز پر نظر رکھیں گے

چھوٹے سرورز میں کم گنجائش ہوتی ہے۔ اس سے دو باتیں نکلتی ہیں:

1. اگر کبھی بھاری کام ان سرورز پر واپس آئے تو 2 GB کافی نہیں ہوگا۔ تب حل بڑا Graviton سائز ہوگا، x86 پر واپس جانا نہیں۔
2. چھوٹی مشینوں کو swap چاہیے۔ ایک ہفتے بعد ان میں سے ایک سرور memory کے دباؤ سے جم گیا، تکنیکی طور پر memory ختم ہوئے بغیر — گمشدہ swap file کی کہانی۔

ہم نے اس سے کیا سیکھا

• architecture بدلنے کے بعد دوبارہ ناپیں۔ کام کو sandboxes میں منتقل کرنے سے بدل گیا کہ ہمارے سرورز کو کیا چاہیے؛ instance کے سائز ابھی اس کے ساتھ نہیں پہنچے تھے۔
• جب images multi-arch ہوں تو ARM عام web stacks کے لیے کم خطرے والا فائدہ ہے۔
• Rollback پہلے لکھیں۔ یہ تبدیلی کو پرسکون بنا دیتا ہے، چاہے آپ اسے کبھی استعمال نہ کریں۔