Infrastructure Scaling: Horizontal vs Vertical, Load Balancing & Auto-Scaling

**Netflix 190 ممالک میں 260 ملین سبسکرائبرز کو حقیقی وقت کی ڈیمانڈ کی بنیاد پر ہزاروں مثالوں کو متحرک طور پر سکیل کر کے خدمات فراہم کرتا ہے۔ ** اگرچہ زیادہ تر کاروبار Netflix پیمانے پر کام نہیں کرتے ہیں، اسکیلنگ کے اصول ایک جیسے ہیں: بنیادی ڈھانچے کی صلاحیت کو خود بخود ٹریفک کی طلب کے مطابق، دستی مداخلت کے بغیر اور بے کار وسائل کی ادائیگی کے بغیر۔ افقی اور عمودی اسکیلنگ، L4 اور L7 لوڈ بیلنسرز، اور رد عمل اور پیش گوئی کرنے والی آٹو اسکیلنگ کے درمیان آپ جو انتخاب کرتے ہیں وہ اس بات کا تعین کرتے ہیں کہ آیا آپ کا پلیٹ فارم خوبصورتی سے بڑھتا ہے یا دیوار سے ٹکراتا ہے۔

اہم ٹیک ویز

• سادگی کے لیے عمودی (بڑی مشینیں) شروع کریں، پھر افقی (مزید مشینوں) پر سوئچ کریں جب آپ کو زیادہ دستیابی کی ضرورت ہو یا سنگل مشین کی حد سے تجاوز کریں۔
• L7 لوڈ بیلنسرز جدید ایپلی کیشنز کے لیے ضروری مواد پر مبنی روٹنگ فراہم کرتے ہیں، جبکہ L4 بیلنسرز سادہ TCP تقسیم کے لیے خام تھرو پٹ پیش کرتے ہیں۔
• آٹو اسکیلنگ کی پالیسیوں کو میٹرک پر مبنی محرکات (CPU، میموری) کو معلوم ٹریفک پیٹرن کے لیے پیشن گوئی کی پیمائش کے ساتھ جوڑنا چاہیے
• ڈیٹا بیس اسکیلنگ ایپلیکیشن اسکیلنگ سے مختلف اصولوں کی پیروی کرتی ہے -- پڑھنے والے بھاری بوجھ کے لیے نقلیں پڑھیں، لکھنے والے بھاری بوجھ کے لیے تقسیم

---

افقی بمقابلہ عمودی اسکیلنگ

اسکیلنگ کا بنیادی فیصلہ یہ ہے کہ آیا موجودہ مشینوں کو بڑا (عمودی) بنایا جائے یا مزید مشینیں (افقی) شامل کی جائیں۔ ہر نقطہ نظر میں الگ الگ تجارت ہوتی ہے۔

عمودی طور پر کب پیمانہ کریں۔

کئی وجوہات کی بنا پر عمودی پیمانہ درست پہلا انتخاب ہے۔ اس کے لیے ایپلی کیشن میں کوئی تبدیلی نہیں، لوڈ بیلنس کنفیگریشن کی ضرورت نہیں ہے، اور ریاست کے تقسیم شدہ انتظام کی ضرورت نہیں ہے۔ خاص طور پر ڈیٹا بیس کے لیے، عمودی اسکیلنگ شارڈنگ، ریپلیکشن وقفہ، اور تقسیم شدہ لین دین کی پیچیدگی سے گریز کرتی ہے۔

عمودی طور پر پیمانہ کریں جب:

• آپ کی درخواست ابھی تک بے وطن نہیں ہے (سیشن میموری میں محفوظ ہیں، فائل سسٹم لکھتا ہے)
• آپ ایک ہی ڈیٹا بیس چلا رہے ہیں اور آپ نے کنکشن یا CPU کی حد نہیں ماری ہے۔
• اگلی مثال کا سائز افقی طور پر جانے کے لئے انجینئرنگ کے وقت سے سستا ہے۔
• آپ کو تعمیراتی تبدیلیوں کے بغیر فوری طور پر پیمانہ کرنے کی ضرورت ہے۔

عمودی طور پر اسکیلنگ بند کریں جب:

• آپ کو اعلی دستیابی کی ضرورت ہے (ایک مثال = ناکامی کا واحد نقطہ)
• سب سے بڑی دستیاب مثال کافی نہیں ہے۔
• آپ چوٹی کی صلاحیت کے لئے ادائیگی کر رہے ہیں جو وقت کا 90٪ بیکار رہتا ہے۔
• آپ کو تاخیر کے لیے جغرافیائی تقسیم درکار ہے۔

افقی طور پر کب پیمانہ کریں۔

افقی اسکیلنگ کے لیے آپ کی درخواست کو بے وطن ہونا ضروری ہے -- کسی بھی درخواست کو کسی بھی مثال کے ذریعے سنبھالا جا سکتا ہے۔ اس کا مطلب ہے:

• Redis یا ڈیٹا بیس میں محفوظ کردہ سیشنز، ان میموری میں نہیں۔
• فائل اپ لوڈز آبجیکٹ اسٹوریج (S3) میں محفوظ ہیں، مقامی ڈسک میں نہیں۔
• نقل کے بغیر کوئی مثال کے لیے مخصوص ترتیب یا مقامی کیشنگ نہیں۔
• مثال کے طور پر ختم کرنے کا خوبصورت ہینڈلنگ (صحت کی جانچ پڑتال، کنکشن ڈریننگ)

افقی پیمانے پر جب:

• زیادہ دستیابی ایک ضرورت ہے (آپ کا کاروبار منٹوں کے ڈاؤن ٹائم کو برداشت نہیں کرسکتا)
• ٹریفک متغیر ہے اور آٹو اسکیلنگ خاموشی کے دوران اسکیل کم کرکے لاگت کو بچا سکتی ہے
• آپ کو ڈاؤن ٹائم کے بغیر تعینات کرنے کی ضرورت ہے (مثال کے طور پر تعیناتیوں کو رولنگ)
• کارکردگی کی ضروریات واحد مشین کی گنجائش سے زیادہ ہیں۔

---

لوڈ بیلنسنگ ڈیپ ڈائیو

ایک لوڈ بیلنسر آنے والی ٹریفک کو متعدد بیک اینڈ سرورز میں تقسیم کرتا ہے۔ لوڈ بیلنس کی قسم اس بات کا تعین کرتی ہے کہ روٹنگ کے کون سے فیصلے ممکن ہیں۔

L4 (ٹرانسپورٹ لیئر) لوڈ بیلنسنگ

L4 لوڈ بیلنسرز TCP/UDP کی سطح پر کام کرتے ہیں۔ وہ پیکٹ کے مواد کا معائنہ کیے بغیر آئی پی ایڈریس اور پورٹ کی بنیاد پر کنکشن روٹ کرتے ہیں۔ وہ تیز، سادہ اور کسی بھی TCP پر مبنی پروٹوکول کو ہینڈل کرتے ہیں۔

بہترین برائے: خام TCP تقسیم، ڈیٹا بیس کنکشن پراکسینگ (PgBouncer)، غیر HTTP پروٹوکول، انتہائی اعلی تھرو پٹ ضروریات

حدود: یو آر ایل پاتھ، ہیڈرز یا کوکیز کی بنیاد پر روٹنگ کے فیصلے نہیں کر سکتے۔ SSL کو ختم نہیں کیا جا سکتا (بیک اینڈ پر کیا جانا چاہیے)۔

L7 (ایپلیکیشن لیئر) لوڈ بیلنسنگ

L7 لوڈ بیلنسرز HTTP سطح پر کام کرتے ہیں۔ وہ درخواست کے ہیڈر، یو آر ایل، کوکیز کا معائنہ کرتے ہیں، اور یہاں تک کہ باڈیز سے روٹنگ کے فیصلے کرنے کی درخواست کرتے ہیں۔ وہ SSL ختم کرنے، کمپریشن کو سنبھالتے ہیں، اور درخواستوں اور جوابات میں ترمیم کر سکتے ہیں۔

بہترین برائے: ویب ایپلیکیشنز، API گیٹ ویز، مواد پر مبنی روٹنگ، SSL ختم، A/B ٹیسٹنگ، کینری تعیناتیاں

لوڈ بیلنسنگ الگورتھم

صحت کی جانچ اور مکرم انحطاط

صحت کی جانچ اس بات کا تعین کرتی ہے کہ آیا بیک اینڈ سرور کو ٹریفک موصول ہونا چاہیے۔ انہیں احتیاط سے ترتیب دیں:

• ہیلتھ ہیلتھ چیک -- ایک مخصوص اینڈ پوائنٹ پر ایک سادہ TCP کنکشن چیک یا HTTP 200۔ سرور کے کریشز کو پکڑتا ہے لیکن ایپلیکیشن کی سطح کی ناکامیوں کو نہیں۔
• صحت کی گہری جانچ -- ڈیٹا بیس کنیکٹیویٹی، Redis کی دستیابی، اور بیرونی سروس تک رسائی کی تصدیق کرتی ہے۔ مزید مسائل پکڑتا ہے لیکن اگر غیر اہم انحصار کم ہو تو غلط منفی کا خطرہ ہوتا ہے۔
• فضائی مدت -- نئی مثالوں کو گرم ہونے کے لیے وقت درکار ہوتا ہے (جے آئی ٹی کی تالیف، کیشے کی آبادی)۔ لوڈ بیلنسر کی طرف سے مکمل ٹریفک بھیجنے سے پہلے ایک آغاز کی رعایتی مدت مقرر کریں۔
• ڈریننگ -- کسی مثال کو ہٹاتے وقت، نئی درخواستیں بھیجنا بند کردیں لیکن موجودہ درخواستوں کو مکمل ہونے دیں (کنکشن ڈریننگ)۔ عام طور پر 30-60 سیکنڈ۔

---

آٹو اسکیلنگ کی پالیسیاں

آٹو اسکیلنگ مانگ کی بنیاد پر مثالوں کی تعداد کو ایڈجسٹ کرتی ہے، دستی مداخلت کے بغیر ٹریفک سے مماثل صلاحیت۔

میٹرک پر مبنی اسکیلنگ

سب سے عام نقطہ نظر اسکیلنگ کی کارروائیوں کو متحرک کرتا ہے جب ایک میٹرک حد کو عبور کرتا ہے۔

پیشین گوئی کی پیمائش

اگر آپ کا ٹریفک پیشین گوئی کرنے والے نمونوں (روزانہ چوٹیوں، ہفتہ وار سائیکلوں، موسمی واقعات) کی پیروی کرتا ہے، تو ٹریفک کے آنے سے پہلے پیشین گوئی کرنے والی اسکیلنگ کی گنجائش۔ AWS آٹو اسکیلنگ پیش گوئی کرنے والی اسکیلنگ کو سپورٹ کرتی ہے جو تاریخی نمونوں اور پیمانے سے فعال طور پر سیکھتی ہے۔

پیش گوئی اور رد عمل کو یکجا کریں: معلوم نمونوں کے لیے پیشن گوئی کی پیمائش کا استعمال کریں (مارننگ ٹریفک ریمپ، بلیک فرائیڈے پری پروویژننگ) اور غیر متوقع اضافے کے لیے ری ایکٹیو اسکیلنگ۔

اسکیلنگ کے بہترین طریقے

1. تیزی سے اسکیل کریں، آہستہ میں پیمانہ کریں -- جارحانہ انداز میں مثالیں شامل کریں (1-2 منٹ کول ڈاؤن) لیکن پھڑپھڑانے سے بچنے کے لیے انہیں آہستہ آہستہ ہٹائیں (10-15 منٹ کول ڈاؤن)
2. متعدد میٹرکس کا استعمال کریں -- CPU یا میموری پر پیمانہ کریں یا ٹرگر کرنے والی پہلی میٹرک کا استعمال کرتے ہوئے
3. کم سے کم اور زیادہ سے زیادہ حدیں مقرر کریں -- اسکیلنگ کو صفر تک روکیں (کوئی دستیابی نہیں) یا غیر معینہ مدت تک اسکیلنگ (لاگت میں دھماکہ)
4. لوڈ ٹیسٹ کے دوران اسکیلنگ کی جانچ کریں -- اس بات کی تصدیق کریں کہ آٹو اسکیلنگ صحیح طریقے سے شروع ہوتی ہے اور نئی مثالیں متوقع وقت کے اندر ٹریفک کو پیش کرتی ہیں
5. اسکیلنگ کے واقعات کی نگرانی کریں -- کنفیگریشن کے مسائل یا کارکردگی کے بنیادی مسائل کا پتہ لگانے کے لیے بار بار اسکیلنگ پر الرٹ

---

ڈیٹا بیس اسکیلنگ کی حکمت عملی

ڈیٹا بیس افقی طور پر اس طرح نہیں ہوتے ہیں جس طرح ایپلیکیشن سرورز کرتے ہیں۔ تحریری کارروائیوں کے لیے اتفاق رائے کی ضرورت ہوتی ہے، اور مضبوط مستقل مزاجی تقسیم کے اختیارات کو محدود کرتی ہے۔

نقلیں پڑھیں

پرائمری ڈیٹا بیس سے نقل ڈیٹا کو کاپی کریں اور پڑھنے کے سوالات پیش کریں۔ وہ لکیری طور پر پڑھنے والے تھرو پٹ کو پیمانہ کرتے ہیں لیکن لکھنے کے تھرو پٹ میں مدد نہیں کرتے ہیں۔

عمل درآمد کے تحفظات:

• نقل کا وقفہ -- نقلیں آخر کار مطابقت رکھتی ہیں۔ تحریر کے فوراً بعد سوالات میں تبدیلی نظر نہیں آ سکتی۔ پڑھنے کے بعد لکھنے کے لیے بنیادی استعمال کریں۔
• کنکشن روٹنگ -- آپ کی ایپلیکیشن کو پرائمری کو ریپلیکاز اور رائٹ کو روٹ کرنے کے لیے منطق کی ضرورت ہے۔ ORMs اور کنکشن پراکسی (ProxySQL، PgBouncer) اسے خودکار کر سکتے ہیں۔
• فیل اوور -- اگر پرائمری ناکام ہوجاتی ہے تو ایک نقل کو فروغ دیا جاسکتا ہے۔ خودکار فیل اوور (AWS RDS Multi-AZ، AWS Aurora) ڈاؤن ٹائم کو سیکنڈ تک کم کر دیتا ہے۔

ٹیبل پارٹیشننگ

بڑی میزوں پر لکھنے والے بھاری کام کے بوجھ کے لیے، تقسیم کاری ایک واحد منطقی انٹرفیس کو برقرار رکھتے ہوئے میز کو چھوٹے جسمانی حصوں میں تقسیم کرتی ہے۔ تفصیلی تقسیم کی حکمت عملیوں کے لیے، ہماری ڈیٹا بیس آپٹیمائزیشن گائیڈ دیکھیں۔

کنکشن پولنگ

ڈیٹا بیس کنکشن بنانا مہنگا اور تعداد میں محدود ہے۔ کنکشن پولرز جیسے PgBouncer پول کنکشن بہت سے ایپلیکیشنز سے ڈیٹا بیس کنکشن کی ایک چھوٹی تعداد میں۔

پولنگ کے بغیر: 20 ایپلیکیشن مثالیں x 20 کنکشن ہر ایک = 400 ڈیٹا بیس کنکشن (ممکنہ طور پر PostgreSQL کی حد سے زیادہ)

PgBouncer کے ساتھ: 20 ایپلیکیشن مثالیں PgBouncer سے منسلک ہوتی ہیں، جو PostgreSQL سے 50-100 کنکشنز کو برقرار رکھتی ہے، ملٹی پلیکسنگ کی درخواستوں کو مؤثر طریقے سے۔

---

مائیکرو سروسز سڑنا

جب ایک سنگل ٹیم کے لیے بہت بڑا ہو جاتا ہے کہ وہ مؤثر طریقے سے ترقی کر سکے، مائیکرو سروسز سڑنا مختلف اجزاء کی آزادانہ پیمائش کی اجازت دیتا ہے۔

کب گلنا ہے۔

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

• مختلف اجزاء میں اسکیلنگ کی مختلف ضروریات ہوتی ہیں (تلاش کو 20 مثالوں کی ضرورت ہوتی ہے، چیک آؤٹ کی ضرورت ہوتی ہے 5)
• مختلف ٹیموں کو ریلیز کے شیڈول کو مربوط کیے بغیر آزادانہ طور پر تعینات کرنے کی ضرورت ہے۔
• ایک مخصوص جزو کو مختلف ٹیکنالوجی اسٹیک کی ضرورت ہوتی ہے (Python میں مشین لرننگ، Node.js میں API)
• کوڈ بیس کے سائز کی وجہ سے یک سنگی کی تعیناتی کا وقت 30 منٹ سے زیادہ ہے۔

پہلے کیا نکالنا ہے۔

---

اکثر پوچھے گئے سوالات

مجھے کیسے معلوم ہوگا کہ مجھے کب پیمانہ کرنے کی ضرورت ہے؟

چار کلیدی میٹرکس کی نگرانی کریں: CPU کا استعمال (مسلسل 70% سے اوپر)، میموری کا استعمال (80% سے اوپر)، ریسپانس ٹائم P95 (آپ کے SLO سے اوپر)، اور غلطی کی شرح (0.1% سے اوپر)۔ جب کوئی بھی میٹرک مسلسل اپنی حد کی خلاف ورزی کرتا ہے، تو آپ کو پیمانہ کرنے کی ضرورت ہوتی ہے۔ انتباہ کے ساتھ فعال نگرانی صارفین کے نوٹس لینے سے پہلے ان رجحانات کو پکڑ لیتی ہے۔ ہماری مانیٹرنگ گائیڈ دیکھیں۔

کیا آٹو اسکیلنگ یا پری پروویژننگ زیادہ سرمایہ کاری مؤثر ہے؟

غیر متوقع ٹریفک کے لیے آٹو اسکیلنگ زیادہ سرمایہ کاری مؤثر ہے کیونکہ آپ صرف اس وقت صلاحیت کے لیے ادائیگی کرتے ہیں جب آپ کو ضرورت ہو۔ پیش گوئی کی چوٹیوں (بلیک فرائیڈے، یومیہ رش) کے لیے پیشگی فراہمی بہتر ہے کیونکہ خودکار پیمانے پر صلاحیت کو بڑھانے میں 3-10 منٹ لگتے ہیں۔ سب سے زیادہ سرمایہ کاری مؤثر طریقہ دونوں کو یکجا کرتا ہے: متوقع چوٹیوں کے لیے پیشگی فراہمی، غیر متوقع اضافے کے لیے خودکار پیمانے، اور اپنی بنیادی صلاحیت کے لیے مخصوص مثالوں کا استعمال۔ ہماری کلاؤڈ کوسٹ آپٹیمائزیشن گائیڈ دیکھیں۔

کیا میں کنٹینرز (Docker/Kubernetes) یا روایتی VMs استعمال کروں؟

کنٹینرز تیزی سے شروع ہوتے ہیں (سیکنڈ بمقابلہ منٹ)، وسائل کو زیادہ مؤثر طریقے سے استعمال کرتے ہیں (فی میزبان زیادہ کثافت)، اور ترقی اور پیداوار میں مستقل ماحول فراہم کرتے ہیں۔ Kubernetes آرکیسٹریشن (آٹو اسکیلنگ، خود شفا یابی، رولنگ تعینات) لیکن اہم آپریشنل پیچیدگی کا اضافہ کرتا ہے۔ Kubernetes پر غور کرنے سے پہلے منظم کنٹینر سروسز (AWS ECS، Google Cloud Run) کے ساتھ شروع کریں۔

ڈیٹا کے نقصان کے بغیر میں ڈیٹا بیس فیل اوور کو کیسے ہینڈل کروں؟

صفر ڈیٹا کے نقصان کے فیل اوور کے لیے ہم وقت ساز نقل کا استعمال کریں -- پرائمری تحریر کو اس وقت تک تسلیم نہیں کرتا جب تک کہ نقل اس کی تصدیق نہ کرے۔ یہ لکھنے میں تاخیر کا اضافہ کرتا ہے (عام طور پر اسی علاقے میں 1-5ms) لیکن فیل اوور کے دوران ڈیٹا کے ضائع ہونے کی ضمانت نہیں دیتا ہے۔ AWS RDS Multi-AZ اور Aurora خودکار فیل اوور کے ساتھ منظم مطابقت پذیر نقل فراہم کرتے ہیں۔

---

آگے کیا ہے۔

اپنے موجودہ انفراسٹرکچر کا اندازہ اپنے نمو کے تخمینے کے مطابق کریں۔ اگر آپ ایک ہی سرور چلا رہے ہیں، تو یقینی بنائیں کہ آپ کی درخواست بے وطن ہے اور افقی اسکیلنگ کے لیے تیار ہے۔ اگر آپ پہلے سے ہی ایک سے زیادہ مثالیں چلا رہے ہیں، تو اپنی لوڈ بیلنس کنفیگریشن کو بہتر بنائیں اور آٹو اسکیلنگ کی پالیسیاں لاگو کریں۔

مکمل کارکردگی کے انجینئرنگ تناظر کے لیے، اپنے کاروباری پلیٹ فارم کو اسکیل کرنے پر ہماری ستون گائیڈ دیکھیں۔ اپنے پیمانے پر لاگت کو بہتر بنانے کے لیے، کلاؤڈ لاگت کی اصلاح پر ہماری گائیڈ پڑھیں۔

ECOSIRE AWS اور ملٹی کلاؤڈ ماحول پر کاروباری پلیٹ فارمز کے لیے توسیع پذیر انفراسٹرکچر کو ڈیزائن اور لاگو کرتا ہے۔ ہماری DevOps ٹیم سے رابطہ کریں انفراسٹرکچر اسکیلنگ اسسمنٹ کے لیے۔

---

شائع کردہ بذریعہ ECOSIRE — کاروباروں کو Odoo ERP، Shopify eCommerce، اور OpenClaw AI میں AI سے چلنے والے حل کے ساتھ پیمانے میں مدد کرنا۔