اس مضمون میں انجینئرز کو بڑے پیمانے پر خدمات کے ساتھ کام کرنے میں مدد کرنے کے لیے کچھ عام نمونے شامل ہیں جن تک لاکھوں صارفین رسائی حاصل کرتے ہیں۔
مصنف کے تجربے میں، یہ ایک مکمل فہرست نہیں ہے، لیکن حقیقت میں مؤثر مشورہ تو، چلو شروع کرتے ہیں.
تعاون کے ساتھ ترجمہ کیا گیا۔ .
پہلی سطح
ذیل میں درج اقدامات لاگو کرنے کے لیے نسبتاً آسان ہیں لیکن ان کا اثر بہت زیادہ ہے۔ اگر آپ نے پہلے ان کی کوشش نہیں کی ہے، تو آپ نمایاں بہتری پر حیران رہ جائیں گے۔
بنیادی ڈھانچہ بطور کوڈ
مشورہ کا پہلا حصہ بنیادی ڈھانچے کو کوڈ کے طور پر نافذ کرنا ہے۔ اس کا مطلب ہے کہ آپ کے پاس پورے انفراسٹرکچر کو تعینات کرنے کے لیے ایک پروگرامی طریقہ ہونا چاہیے۔ یہ پیچیدہ لگتا ہے، لیکن ہم اصل میں درج ذیل کوڈ کے بارے میں بات کر رہے ہیں:
100 ورچوئل مشینوں کی تعیناتی۔
- Ubuntu کے ساتھ
- 2 جی بی ریم ہر ایک
- ان کے پاس درج ذیل کوڈ ہوگا۔
- ان پیرامیٹرز کے ساتھ
آپ اپنے بنیادی ڈھانچے میں ہونے والی تبدیلیوں کو ٹریک کر سکتے ہیں اور ورژن کنٹرول کا استعمال کرتے ہوئے فوری طور پر ان پر واپس جا سکتے ہیں۔
مجھ میں ماڈرنسٹ کا کہنا ہے کہ آپ مندرجہ بالا سب کو کرنے کے لیے Kubernetes/Docker کا استعمال کر سکتے ہیں، اور وہ ٹھیک ہے۔
اس کے علاوہ، آپ شیف، پپٹ یا ٹیرافارم کا استعمال کرتے ہوئے آٹومیشن فراہم کر سکتے ہیں۔
مسلسل انضمام اور ترسیل
توسیع پذیر سروس بنانے کے لیے، ہر پل کی درخواست کے لیے ایک بلڈ اور ٹیسٹ پائپ لائن کا ہونا ضروری ہے۔ یہاں تک کہ اگر ٹیسٹ بہت آسان ہے، تو یہ کم از کم اس بات کو یقینی بنائے گا کہ آپ جو کوڈ تعینات کرتے ہیں وہ مرتب کرتا ہے۔
اس مرحلے پر ہر بار آپ اس سوال کا جواب دیتے ہیں: کیا میری اسمبلی ٹیسٹ مرتب کرے گی اور پاس کرے گی، کیا یہ درست ہے؟ یہ ایک کم بار کی طرح لگ سکتا ہے، لیکن یہ بہت سے مسائل کو حل کرتا ہے.
ان ٹکڑوں کو دیکھنے سے زیادہ خوبصورت کوئی چیز نہیں ہے۔
اس ٹیکنالوجی کے لیے آپ Github، CircleCI یا Jenkins کا جائزہ لے سکتے ہیں۔
لوڈ بیلنسرز
لہذا، ہم ٹریفک کو ری ڈائریکٹ کرنے اور تمام نوڈس پر مساوی بوجھ کو یقینی بنانے کے لیے لوڈ بیلنسر چلانا چاہتے ہیں یا ناکامی کی صورت میں سروس جاری رہے گی۔
لوڈ بیلنسر عام طور پر ٹریفک کی تقسیم کا اچھا کام کرتا ہے۔ بہترین عمل یہ ہے کہ اوور بیلنس کیا جائے تاکہ آپ کو ناکامی کا ایک نقطہ بھی نہ پڑے۔
عام طور پر، لوڈ بیلنسرز آپ کے استعمال کردہ کلاؤڈ میں کنفیگر ہوتے ہیں۔
درخواستوں کے لیے RayID، ارتباطی ID یا UUID
کیا آپ کو کبھی اس طرح کے پیغام کے ساتھ درخواست کی غلطی کا سامنا کرنا پڑا ہے: "کچھ غلط ہو گیا. اس آئی ڈی کو محفوظ کریں اور ہماری سپورٹ ٹیم کو بھیجیں"?
ایک منفرد شناخت کنندہ، ارتباطی ID، RayID، یا مختلف حالتوں میں سے کوئی بھی، ایک منفرد شناخت کنندہ ہے جو آپ کو اس کی زندگی بھر درخواست کو ٹریک کرنے کی اجازت دیتا ہے۔ یہ آپ کو لاگز میں درخواست کے پورے راستے کو ٹریک کرنے کی اجازت دیتا ہے۔
صارف سسٹم A سے درخواست کرتا ہے، پھر A سے رابطہ کرتا ہے، جو C سے رابطہ کرتا ہے، اسے X میں اسٹور کرتا ہے، اور پھر درخواست A کو واپس کردی جاتی ہے۔
اگر آپ دور دراز سے ورچوئل مشینوں سے جڑیں اور درخواست کے راستے کو ٹریس کرنے کی کوشش کریں (اور دستی طور پر رابطہ کریں کہ کون سی کالیں کی جارہی ہیں) تو آپ پاگل ہو جائیں گے۔ منفرد شناخت کنندہ کا ہونا زندگی کو بہت آسان بنا دیتا ہے۔ یہ سب سے آسان چیزوں میں سے ایک ہے جو آپ وقت بچانے کے لیے کر سکتے ہیں جیسے جیسے آپ کی سروس بڑھتی ہے۔
اوسط سطح
یہاں کی نصیحت پچھلی تجاویز سے زیادہ پیچیدہ ہے، لیکن صحیح ٹولز کام کو آسان بناتے ہیں، یہاں تک کہ چھوٹی اور درمیانے درجے کی کمپنیوں کے لیے بھی سرمایہ کاری پر منافع فراہم کرتے ہیں۔
مرکزی لاگنگ
مبارک ہو! آپ نے 100 ورچوئل مشینیں تعینات کی ہیں۔ اگلے دن، CEO آتا ہے اور سروس کی جانچ کے دوران اسے موصول ہونے والی غلطی کی شکایت کرتا ہے۔ یہ اسی متعلقہ ID کی اطلاع دیتا ہے جس کے بارے میں ہم نے اوپر بات کی ہے، لیکن آپ کو 100 مشینوں کے لاگز کو تلاش کرنا پڑے گا تاکہ اس کو تلاش کیا جا سکے جس کی وجہ سے کریش ہوا۔ اور اسے کل کی پریزنٹیشن سے پہلے تلاش کرنے کی ضرورت ہے۔
اگرچہ یہ ایک تفریحی مہم جوئی کی طرح لگتا ہے، یہ یقینی بنانا بہتر ہے کہ آپ تمام میگزین کو ایک جگہ پر تلاش کرنے کی اہلیت رکھتے ہیں۔ میں نے ELK اسٹیک کی بلٹ ان فعالیت کا استعمال کرتے ہوئے لاگ کو سنٹرلائز کرنے کا مسئلہ حل کیا: یہ قابل تلاش لاگ جمع کرنے کی حمایت کرتا ہے۔ یہ واقعی ایک مخصوص جریدے کی تلاش کے مسئلے کو حل کرنے میں مدد کرے گا۔ بونس کے طور پر، آپ چارٹ اور اس جیسی دیگر تفریحی چیزیں بنا سکتے ہیں۔
ELK اسٹیک کی فعالیت
مانیٹرنگ ایجنٹس
اب جب کہ آپ کی سروس تیار اور چل رہی ہے، آپ کو یہ یقینی بنانا ہوگا کہ یہ آسانی سے چل رہی ہے۔ ایسا کرنے کا بہترین طریقہ کئی چلانا ہے۔ ایجنٹس، جو متوازی طور پر کام کرتے ہیں اور چیک کرتے ہیں کہ یہ کام کرتا ہے اور بنیادی کارروائیاں انجام دی جاتی ہیں۔
اس وقت آپ اسے چیک کریں۔ چلنے والی تعمیر اچھی محسوس ہوتی ہے اور ٹھیک کام کرتی ہے۔.
چھوٹے سے درمیانے درجے کے پروجیکٹس کے لیے، میں APIs کی نگرانی اور دستاویز کرنے کے لیے پوسٹ مین کی سفارش کرتا ہوں۔ لیکن عام طور پر، آپ صرف اس بات کو یقینی بنانا چاہتے ہیں کہ آپ کے پاس یہ جاننے کا طریقہ موجود ہے کہ بندش کب واقع ہوئی ہے اور بروقت اطلاع دی جائے۔
لوڈ پر منحصر آٹو اسکیلنگ
یہ بہت آسان ہے۔ اگر آپ کے پاس VM سروسنگ کی درخواستیں ہیں اور یہ 80% میموری کے استعمال کے قریب ہے، تو آپ یا تو اس کے وسائل کو بڑھا سکتے ہیں یا کلسٹر میں مزید VMs شامل کر سکتے ہیں۔ لوڈ کے تحت لچکدار طاقت کی تبدیلیوں کے لیے ان کارروائیوں کا خودکار عمل بہترین ہے۔ لیکن آپ کو ہمیشہ محتاط رہنا چاہیے کہ آپ کتنی رقم خرچ کرتے ہیں اور معقول حدیں مقرر کرتے ہیں۔
زیادہ تر کلاؤڈ سروسز کے ساتھ، آپ اسے زیادہ سرورز یا زیادہ طاقتور سرورز کا استعمال کرکے آٹو اسکیل پر کنفیگر کرسکتے ہیں۔
تجرباتی نظام
اپ ڈیٹس کو محفوظ طریقے سے رول آؤٹ کرنے کا ایک اچھا طریقہ یہ ہے کہ ایک گھنٹے کے لیے 1% صارفین کے لیے کچھ جانچنے کے قابل ہو۔ آپ نے یقیناً اس طرح کے میکانزم کو عمل میں دیکھا ہوگا۔ مثال کے طور پر، فیس بک سامعین کے کچھ حصوں کو مختلف رنگ دکھاتا ہے یا فونٹ کا سائز تبدیل کرتا ہے تاکہ یہ دیکھا جا سکے کہ صارفین ان تبدیلیوں کو کیسے سمجھتے ہیں۔ اسے A/B ٹیسٹنگ کہتے ہیں۔
یہاں تک کہ ایک نئی خصوصیت کو جاری کرنا بھی ایک تجربے کے طور پر شروع کیا جا سکتا ہے اور پھر اس کو جاری کرنے کا طریقہ طے کیا جا سکتا ہے۔ آپ کو "یاد رکھنے" یا اس فنکشن کی بنیاد پر فلائی پر کنفیگریشن کو تبدیل کرنے کی صلاحیت بھی ملتی ہے جو آپ کی خدمت میں تنزلی کا باعث بن رہی ہے۔
اعلی درجے کی سطح
یہاں ایسے نکات ہیں جن پر عمل درآمد کرنا کافی مشکل ہے۔ آپ کو شاید کچھ اور وسائل کی ضرورت ہوگی، لہذا ایک چھوٹی یا درمیانے درجے کی کمپنی کو اس کا انتظام کرنے میں مشکل پیش آئے گی۔
نیلے سبز کی تعیناتی۔
اس کو میں کھولنے کا "Erlang" طریقہ کہتا ہوں۔ جب ٹیلی فون کمپنیاں نمودار ہوئیں تو ایرلنگ بڑے پیمانے پر استعمال ہونے لگا۔ ٹیلی فون کالز کو روٹ کرنے کے لیے سافٹ سوئچز کا استعمال کیا جانے لگا۔ ان سوئچز پر سافٹ ویئر کا بنیادی مقصد یہ تھا کہ سسٹم اپ گریڈ کے دوران کالیں نہ آئیں۔ ایرلانگ کے پاس پچھلے کو کریش کیے بغیر نیا ماڈیول لوڈ کرنے کا ایک اچھا طریقہ ہے۔
یہ مرحلہ لوڈ بیلنس کی موجودگی پر منحصر ہے۔ آئیے تصور کریں کہ آپ کے پاس آپ کے سافٹ ویئر کا ورژن N ہے، اور پھر آپ ورژن N+1 کو تعینات کرنا چاہتے ہیں۔
آپ ہم کر سکتے تھے بس سروس بند کر دیں اور اگلے ورژن کو ایسے وقت میں رول آؤٹ کریں جو آپ کے صارفین کے لیے کام کرے اور کچھ ٹائم ٹائم حاصل کریں۔ لیکن فرض کریں کہ آپ کے پاس ہے۔ واقعی سخت SLA شرائط۔ لہذا، SLA 99,99% کا مطلب ہے کہ آپ آف لائن جا سکتے ہیں۔ صرف 52 منٹ فی سال۔
اگر آپ واقعی ایسے اشارے حاصل کرنا چاہتے ہیں، تو آپ کو ایک ہی وقت میں دو تعیناتیوں کی ضرورت ہے:
- وہ جو ابھی ہے (N)؛
- اگلا ورژن (N+1)۔
آپ لوڈ بیلنسر کو کہتے ہیں کہ ٹریفک کا ایک فیصد نئے ورژن (N+1) کی طرف ری ڈائریکٹ کرے جب کہ آپ رجعت کے لیے فعال طور پر نگرانی کرتے ہیں۔
یہاں ہمارے پاس سبز N کی تعیناتی ہے جو ٹھیک کام کرتی ہے۔ ہم اس تعیناتی کے اگلے ورژن پر جانے کی کوشش کر رہے ہیں۔
پہلے ہم یہ دیکھنے کے لیے ایک چھوٹا سا ٹیسٹ بھیجتے ہیں کہ آیا ہماری N+1 کی تعیناتی تھوڑی سی ٹریفک کے ساتھ کام کرتی ہے:
Наконец, у нас есть набор автоматических проверок, которые мы в конечном итоге запускаем до тех пор, пока наше развертывание не будет завершено. Если вы بہت بہت ہوشیار رہیں، آپ اپنی N کی تعیناتی کو ہمیشہ کے لیے محفوظ کر سکتے ہیں برے ریگریشن کی صورت میں فوری رول بیک کے لیے:
اگر آپ اس سے بھی زیادہ اعلی درجے پر جانا چاہتے ہیں، تو نیلے سبز کی تعیناتی میں ہر چیز کو خود بخود چلنے دیں۔
بے ضابطگی کا پتہ لگانے اور خود کار طریقے سے تخفیف
یہ دیکھتے ہوئے کہ آپ کے پاس مرکزی لاگنگ اور لاگ کا اچھا مجموعہ ہے، آپ پہلے ہی اعلیٰ اہداف مقرر کر سکتے ہیں۔ مثال کے طور پر، ناکامیوں کی پیشن گوئی فعال طور پر کریں۔ فنکشنز کو مانیٹر اور لاگز میں ٹریک کیا جاتا ہے اور مختلف خاکے بنائے جاتے ہیں - اور آپ پہلے سے اندازہ لگا سکتے ہیں کہ کیا غلط ہوگا:
ایک بار بے ضابطگیوں کا پتہ چل جانے کے بعد، آپ سروس فراہم کرنے والے کچھ سراگوں کی جانچ کرنا شروع کر دیتے ہیں۔ مثال کے طور پر، CPU لوڈ میں اضافہ اس بات کی نشاندہی کر سکتا ہے کہ ہارڈ ڈرائیو ناکام ہو رہی ہے، جبکہ درخواستوں میں اضافہ اس بات کی نشاندہی کر سکتا ہے کہ آپ کو پیمانہ بڑھانے کی ضرورت ہے۔ اس قسم کا شماریاتی ڈیٹا آپ کو سروس کو فعال بنانے کی اجازت دیتا ہے۔
ان بصیرت کے ساتھ، آپ کسی بھی جہت میں پیمائش کر سکتے ہیں اور مشینوں، ڈیٹا بیس، کنکشنز اور دیگر وسائل کی خصوصیات کو فعال اور رد عمل سے تبدیل کر سکتے ہیں۔
بس!
اگر آپ کلاؤڈ سروس کو بڑھا رہے ہیں تو ترجیحات کی یہ فہرست آپ کو بہت ساری پریشانیوں سے بچائے گی۔
اصل مضمون کا مصنف قارئین کو اپنے تبصرے چھوڑنے اور تبدیلیاں کرنے کی دعوت دیتا ہے۔ مضمون کو اوپن سورس کے طور پر تقسیم کیا گیا ہے، مصنف کی طرف سے درخواستیں کھینچیں۔ .
اس موضوع پر اور کیا پڑھنا ہے:
ماخذ: www.habr.com