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

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

آئیے معلومات کو فلٹر کرنے کی کوشش کریں اور بنیادی فارمولہ لکھیں۔ ہم اپنی نئی فوٹو شیئرنگ سائٹ گرامینسٹا کو مرحلہ وار 1 سے 100 صارفین تک بڑھانے جا رہے ہیں۔

آئیے لکھتے ہیں کہ جب سامعین کی تعداد 10، 100، 1000، 10،000 اور 100،000 افراد تک بڑھ جائے تو کون سے مخصوص اقدامات کرنے کی ضرورت ہے۔

1 صارف: 1 مشین

تقریباً ہر ایپلیکیشن، خواہ وہ ویب سائٹ ہو یا موبائل ایپلیکیشن، کے تین اہم اجزاء ہوتے ہیں:

• API
• база данных
• کلائنٹ (موبائل ایپلیکیشن خود یا ویب سائٹ)

ڈیٹا بیس مستقل ڈیٹا کو محفوظ کرتا ہے۔ API اس ڈیٹا کو اور اس کے آس پاس کی درخواستیں پیش کرتا ہے۔ کلائنٹ صارف کو ڈیٹا منتقل کرتا ہے۔

میں اس نتیجے پر پہنچا کہ اگر کسی آرکیٹیکچرل نقطہ نظر سے، کلائنٹ اور API اداروں کو مکمل طور پر الگ کر دیا جائے تو کسی ایپلیکیشن کو سکیل کرنے کے بارے میں بات کرنا بہت آسان ہے۔

جب ہم پہلی بار ایپلیکیشن بنانا شروع کرتے ہیں تو تینوں اجزاء کو ایک ہی سرور پر چلایا جا سکتا ہے۔ کچھ طریقوں سے، یہ ہمارے ترقیاتی ماحول سے ملتا جلتا ہے: ایک انجینئر ڈیٹا بیس، API، اور کلائنٹ کو ایک ہی مشین پر چلاتا ہے۔

نظریہ میں، ہم اسے ایک ڈیجیٹل اوشین ڈراپلیٹ یا AWS EC2 مثال پر بادل میں تعینات کر سکتے ہیں، جیسا کہ ذیل میں دکھایا گیا ہے:

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

10 صارفین: ڈیٹا بیس کو الگ سطح پر منتقل کرنا

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

یہ نظام اب ایسا لگتا ہے:

100 صارفین: کلائنٹ کو الگ سطح پر منتقل کرنا

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

یہی وجہ ہے کہ میں کلائنٹ کو API سے الگ سمجھنا پسند کرتا ہوں۔ اس سے متعدد پلیٹ فارمز کے لیے تیار کرنے کے بارے میں سوچنا بہت آسان ہو جاتا ہے: ویب، موبائل ویب، iOS، اینڈرائیڈ، ڈیسک ٹاپ ایپلیکیشنز، تھرڈ پارٹی سروسز وغیرہ۔ یہ سب صرف ایک ہی API استعمال کرنے والے کلائنٹ ہیں۔

مثال کے طور پر، اب ہمارے صارفین اکثر موبائل ایپلیکیشن جاری کرنے کے لیے کہتے ہیں۔ اگر آپ کلائنٹ اور API اداروں کو الگ کرتے ہیں، تو یہ آسان ہو جاتا ہے۔

اس طرح کا نظام ایسا لگتا ہے:

1000 صارفین: لوڈ بیلنسر شامل کریں۔

چیزیں نظر آرہی ہیں۔ Graminsta کے صارفین زیادہ سے زیادہ تصاویر اپ لوڈ کر رہے ہیں۔ رجسٹریشن کی تعداد بھی بڑھ رہی ہے۔ ہمارے واحد API سرور کو تمام ٹریفک کو برقرار رکھنے میں مشکل پیش آرہی ہے۔ مزید لوہے کی ضرورت ہے!

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

ہم ویب کلائنٹ کے سامنے اور API کے سامنے الگ الگ لوڈ بیلنس رکھنے جا رہے ہیں۔ اس کا مطلب ہے کہ آپ API کوڈ اور ویب کلائنٹ کوڈ چلانے والی متعدد مثالیں چلا سکتے ہیں۔ لوڈ بیلنسر اس سرور کو درخواستیں بھیجے گا جو کم لوڈ ہے۔

یہاں ہمیں ایک اور اہم فائدہ ملتا ہے - فالتو پن۔ جب ایک مثال ناکام ہو جاتی ہے (شاید اوورلوڈ یا کریش ہو جاتی ہے)، تو ہم دوسرے لوگوں کے ساتھ رہ جاتے ہیں جو آنے والی درخواستوں کا جواب دیتے رہتے ہیں۔ اگر صرف ایک مثال کام کر رہی تھی، تو ناکامی کی صورت میں پورا نظام کریش ہو جائے گا۔

لوڈ بیلنسر خودکار اسکیلنگ بھی فراہم کرتا ہے۔ ہم اسے کنفیگر کر سکتے ہیں تاکہ پیک لوڈ سے پہلے واقعات کی تعداد میں اضافہ ہو، اور جب تمام صارفین سو رہے ہوں تو اسے کم کر سکیں۔

لوڈ بیلنسر کے ساتھ، API کی سطح کو تقریباً غیر معینہ مدت تک بڑھایا جا سکتا ہے، درخواستوں کی تعداد میں اضافے کے ساتھ ہی نئی مثالیں شامل کی جا سکتی ہیں۔

نوٹ. ابھی ہمارا سسٹم بالکل اسی طرح ہے جو PaaS کمپنیاں جیسے Heroku یا Elastic Beanstalk on the box پیش کرتے ہیں (جس کی وجہ سے وہ بہت مشہور ہیں)۔ ہیروکو ڈیٹا بیس کو الگ میزبان پر رکھتا ہے، آٹو اسکیلنگ لوڈ بیلنس کا انتظام کرتا ہے، اور آپ کو API سے الگ ویب کلائنٹ کی میزبانی کرنے کی اجازت دیتا ہے۔ ابتدائی مرحلے کے پروجیکٹس یا سٹارٹ اپس کے لیے ہیروکو استعمال کرنے کی یہ ایک بڑی وجہ ہے - آپ کو تمام بنیادی خدمات باکس سے باہر مل جاتی ہیں۔

10 صارفین: CDN

شاید ہمیں یہ کام شروع سے ہی کرنا چاہیے تھا۔ درخواستوں پر کارروائی کرنا اور نئی تصاویر کو قبول کرنا ہمارے سرورز پر بہت زیادہ دباؤ ڈالنا شروع کر رہا ہے۔

اس مرحلے پر، آپ کو جامد مواد - تصاویر، ویڈیوز اور بہت کچھ (AWS S3 یا Digital Ocean Spaces) کو ذخیرہ کرنے کے لیے کلاؤڈ سروس استعمال کرنے کی ضرورت ہے۔ عام طور پر، ہمارے API کو تصاویر پیش کرنے اور سرور پر تصاویر اپ لوڈ کرنے جیسی چیزوں کو سنبھالنے سے گریز کرنا چاہیے۔

کلاؤڈ ہوسٹنگ کا ایک اور فائدہ CDN ہے (AWS اس ایڈ آن کو کلاؤڈ فرنٹ کہتے ہیں، لیکن بہت سے کلاؤڈ اسٹوریج فراہم کرنے والے اسے باکس سے باہر پیش کرتے ہیں)۔ CDN خود بخود ہماری تصاویر کو دنیا بھر کے مختلف ڈیٹا سینٹرز میں محفوظ کر لیتا ہے۔

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

100 یوزرز: ڈیٹا لیئر کو اسکیل کرنا

CDN نے بہت مدد کی ہے: ٹریفک پوری رفتار سے بڑھ رہی ہے۔ مشہور ویڈیو بلاگر Mavid Mobrick نے ابھی ابھی ہمارے ساتھ رجسٹر کیا اور اپنی "کہانی" پوسٹ کی، جیسا کہ وہ کہتے ہیں۔ لوڈ بیلنسر کی بدولت، API سرورز پر CPU اور میموری کا استعمال کم رکھا گیا ہے (دس API مثالیں چل رہی ہیں)، لیکن ہمیں درخواستوں پر کافی ٹائم آؤٹ ملنا شروع ہو رہے ہیں... یہ تاخیر کہاں سے آ رہی ہے؟

میٹرکس میں تھوڑا سا کھودتے ہوئے، ہم دیکھتے ہیں کہ ڈیٹا بیس سرور پر CPU 80-90% بھرا ہوا ہے۔ ہم حد پر ہیں۔

ڈیٹا لیئر کو اسکیل کرنا شاید مساوات کا سب سے مشکل حصہ ہے۔ API سرور اسٹیٹ لیس درخواستیں پیش کرتے ہیں، لہذا ہم صرف مزید API مثالیں شامل کرتے ہیں۔ ناک اکثریت ڈیٹا بیس ایسا نہیں کر سکتے۔ ہم مقبول رشتہ دار ڈیٹابیس مینجمنٹ سسٹم (PostgreSQL، MySQL، وغیرہ) کے بارے میں بات کریں گے۔

کیشنگ۔

ہمارے ڈیٹا بیس کی کارکردگی کو بڑھانے کا ایک آسان ترین طریقہ یہ ہے کہ ایک نیا جزو متعارف کرایا جائے: کیش لیئر۔ کیشنگ کا سب سے عام طریقہ ان میموری کلیدی قدر کا ریکارڈ اسٹور ہے، جیسے Redis یا Memcached۔ زیادہ تر کلاؤڈز میں ان سروسز کا ایک منظم ورژن ہوتا ہے: AWS پر Elasticache اور Google Cloud پر Memorystore۔

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

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

ہم ڈیٹا بیس سے نتائج کو کلید کے ذریعے Redis میں کیش کریں گے۔ user:id 30 سیکنڈ کی میعاد کے ساتھ۔ اب، جب کوئی موبرک کے پروفائل پر جاتا ہے، تو ہم پہلے Redis کو چیک کرتے ہیں، اور اگر ڈیٹا موجود ہے، تو ہم اسے براہ راست Redis سے منتقل کرتے ہیں۔ اب سائٹ پر سب سے زیادہ مقبول پروفائل کی درخواستیں عملی طور پر ہمارے ڈیٹا بیس کو لوڈ نہیں کرتی ہیں۔

زیادہ تر کیشنگ سروسز کا ایک اور فائدہ یہ ہے کہ ڈیٹا بیس سرورز کے مقابلے ان کا پیمانہ کرنا آسان ہے۔ Redis میں بلٹ ان Redis کلسٹر موڈ ہے۔ لوڈ بیلنسر کی طرح1، یہ آپ کو اپنے Redis کیش کو متعدد مشینوں میں تقسیم کرنے کی اجازت دیتا ہے (اگر ضرورت ہو تو ہزاروں سرورز میں)۔

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

نقلیں پڑھیں

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

اب ہمارا نظام یہ ہے:

مزید اقدامات

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

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

ہم نیو ریلیک یا ڈیٹا ڈوگ جیسی مانیٹرنگ اور اینالیٹکس سروس بھی انسٹال کرنا چاہتے ہیں۔ اس سے آپ کو سست سوالات کی نشاندہی کرنے اور یہ سمجھنے میں مدد ملے گی کہ کہاں بہتری کی ضرورت ہے۔ جیسا کہ ہم پیمانہ کرتے ہیں، ہم رکاوٹوں کو تلاش کرنے اور انہیں ختم کرنے پر توجہ مرکوز کرنا چاہتے ہیں—اکثر پچھلے حصوں کے کچھ آئیڈیاز کا استعمال کرتے ہوئے۔

ذرائع

یہ پوسٹ ان میں سے ایک سے متاثر ہے۔ اعلی اسکیل ایبلٹی کے بارے میں میری پسندیدہ پوسٹس. میں پروجیکٹ کے ابتدائی مراحل کے لیے آرٹیکل کو کچھ زیادہ مخصوص بنانا چاہتا تھا اور اسے ایک وینڈر سے کھولنا چاہتا تھا۔ اگر آپ اس موضوع میں دلچسپی رکھتے ہیں تو ضرور پڑھیں۔

فوٹ نوٹ

1. اگرچہ ایک سے زیادہ مثالوں میں لوڈ کی تقسیم کے لحاظ سے یکساں ہے، Redis کلسٹر کا بنیادی نفاذ لوڈ بیلنسر سے بہت مختلف ہے۔ [واپسی]

ماخذ: www.habr.com