কেন আমরা Mythex-এর সার্ভার ARM-এ নিয়ে গেলাম

১৯ সেপ্টেম্বর আমরা Mythex-এর প্রোডাকশন backend x86 সার্ভার থেকে ছোট ARM-ভিত্তিক AWS Graviton সার্ভারে নিয়ে গেছি, এবং প্ল্যাটফর্ম database-ও একটি Graviton instance-এ সরিয়েছি। কারণটি সহজ: প্রতিটি ব্যবহারকারীর app চালানো ও বিল্ড করার ভারী কাজ যখন বিচ্ছিন্ন প্রতি-প্রজেক্ট sandbox-এ সরানো হলো, তখন আমাদের মূল সার্ভারগুলো তার মেমরির প্রায় এক-তৃতীয়াংশে পৌঁছাচ্ছিল। ছোট ARM মেশিন আসল চাপের সঙ্গে মানানসই এবং মাসিক সার্ভার বিল প্রায় ৩০% কমায়।

আমাদের সার্ভার এখন আসলে কী করে

আগে backend সার্ভারগুলো নিজেরাই অনেক কাজ করত। মধ্য-সেপ্টেম্বরের দিকে আমরা ব্যয়বহুল অংশগুলো, অর্থাৎ প্রতিটি প্রজেক্টের কোড চালানো, package ইনস্টল করা, app বিল্ড করা, প্রতি-প্রজেক্ট একটি করে private cloud sandbox-এ সরিয়েছি। প্রতিটি প্রজেক্টের নিজস্ব বিচ্ছিন্ন পরিবেশ ও live preview এভাবেই আসে।

আমাদের নিজস্ব সার্ভারে যা থেকে গেছে তা হলো সমন্বয়: API, sandbox ও publishing পরিচালনাকারী orchestrator, authentication, billing এবং gateway। এই কাজ স্থির ও হালকা। সরানোর পর সার্ভারগুলোর সর্বোচ্চ মেমরি ব্যবহার দাঁড়াল প্রায় ১.৩ GB, যেখানে মেশিনগুলোতে ছিল তার প্রায় তিনগুণ।

কেন ARM

AWS-এর Graviton প্রসেসর হলো AWS-এর নিজের নকশা করা ARM চিপ। একই খরচে সাধারণত একটি তুলনীয় x86 instance-এর চেয়ে বেশি ক্ষমতা পাওয়া যায়, অথবা কম খরচে একই ক্ষমতা। আর আমাদের মতো কাজের জন্য (Node.js সেবা, Docker, Postgres) x86-এর সঙ্গে আমাদের কিছুই বাঁধা নেই।

আমরা সরিয়েছি:

• দুটি app সার্ভার মাঝারি x86 instance থেকে ২ GB RAM-এর ছোট Graviton instance-এ।
• প্ল্যাটফর্ম database একটি ছোট x86 database instance থেকে তার Graviton সমতুল্যে।

একটিই আসল জটিলতা: দুই আর্কিটেকচারের জন্য image

আমাদের staging পরিবেশ এখনও একটি ছোট x86 সার্ভারে চলে। প্রোডাকশন এখন ARM-এ চলে। একটির জন্য বানানো container image অন্যটিতে চলে না।

তাই প্রতিটি image এখন একটি tag-এর অধীনে দুই আর্কিটেকচারের জন্যই বিল্ড হয়: একটি multi-arch image। Docker প্রতিটি মেশিনে সঠিক রূপটি নিজে বেছে নেয়, এবং deploy pipeline জানার দরকার পড়ে না সে কোন পরিবেশে পাঠাচ্ছে। এর মূল্য একটি দীর্ঘতর CI build; লাভ হলো staging ও প্রোডাকশন একই tag থেকে ঠিক একই কোড চালায়।

স্থানান্তরের আগেই rollback পরিকল্পনা

চলমান সেবার নিচে CPU আর্কিটেকচার বদলানো এমন একটি পরিবর্তন, যা কয়েক মিনিটের মধ্যে ফিরিয়ে নেওয়ার ব্যবস্থা থাকা উচিত। বদলানোর আগে আমরা:

• আগের সার্ভার template সংস্করণটি একটি নামকরা rollback লক্ষ্য হিসেবে রেখেছি,
• database resize করার ঠিক আগে একটি database snapshot নিয়েছি, এবং
• সরানো ও ফিরে আসার পথ, দুটিই ঢেকে একটি runbook লিখেছি।

Rollback আমাদের লাগেনি। তবু আমরা একই উপায়ে আবার করতাম।

আমরা কী নজর রাখব

ছোট সার্ভারে মাথার উপর জায়গা কম। এর থেকে দুটি বিষয় আসে:

1. ভারী কাজ আবার এই সার্ভারগুলোতে সরালে, ২ GB যথেষ্ট হবে না। তখন সমাধান হবে একটি বড় Graviton আকার, x86-এ ফিরে যাওয়া নয়।
2. ছোট মেশিনের swap দরকার। এক সপ্তাহ পরে এর একটি সার্ভার মেমরির চাপে জমে গিয়েছিল, যদিও আসলে মেমরি শেষ হয়নি, সোয়াপ ফাইল না থাকার গল্প।

এ থেকে আমরা যা নিয়েছি

• আর্কিটেকচার বদলের পর আবার মাপুন। ভারী কাজ sandbox-এ সরানো আমাদের সার্ভারের প্রয়োজন বদলে দিয়েছিল; instance-এর আকার তখনও সেটির সঙ্গে মেলেনি।
• সাধারণ web stack-এর জন্য ARM একটি কম ঝুঁকির লাভ, একবার আপনার image multi-arch হলে।
• আগে rollback লিখুন। আপনি এটি কখনও ব্যবহার না করলেও এটি পরিবর্তনটিকে শান্ত রাখে।