جوش ایونز نیٹ فلکس مائیکرو سروسز کی افراتفری اور رنگین دنیا کے بارے میں بات کرتے ہیں، بالکل بنیادی باتوں سے شروع کرتے ہوئے - مائیکرو سروسز کی اناٹومی، تقسیم شدہ نظاموں سے وابستہ چیلنجز، اور ان کے فوائد۔ اس بنیاد پر تعمیر کرتے ہوئے، وہ ثقافتی، تعمیراتی، اور آپریشنل طریقوں کی کھوج کرتا ہے جو مائیکرو سروس کی مہارت کا باعث بنتے ہیں۔
آپریشنل ڈرفٹ کے برعکس، سروس کی بین الاقوامی کاری کے لیے نئی زبانوں کا تعارف اور کنٹینرز جیسی نئی ٹیکنالوجیز ماحول میں نئی پیچیدگیوں کو شامل کرنے کے شعوری فیصلے ہیں۔ میری آپریشنز ٹیم نے Netflix کے لیے بہترین ٹکنالوجی کے روڈ میپ کو معیاری بنایا، جو Java اور EC2 کی بنیاد پر پہلے سے طے شدہ بہترین طریقوں میں پکایا گیا تھا، لیکن جیسے جیسے کاروبار بڑھتا گیا، ڈویلپرز نے Python، Ruby، Node-JS، اور Docker جیسے نئے اجزاء شامل کرنا شروع کر دیے۔
مجھے بہت فخر ہے کہ ہم سب سے پہلے ایسے تھے جنہوں نے کسٹمر کی شکایات کا انتظار کیے بغیر اپنی پروڈکٹ کے بہترین کام کرنے کی وکالت کی۔ یہ سب کافی آسان سے شروع ہوا - ہمارے پاس Python میں آپریٹنگ پروگرام اور روبی میں کچھ بیک آفس ایپلی کیشنز تھے، لیکن چیزیں اس وقت بہت زیادہ دلچسپ ہو گئیں جب ہمارے ویب ڈویلپرز نے اعلان کیا کہ وہ JVM کو ختم کرنے جا رہے ہیں اور ویب کو منتقل کرنے جا رہے ہیں۔ نوڈ سافٹ ویئر پلیٹ فارم پر درخواست۔ js. ڈوکر کے تعارف کے بعد، چیزیں بہت زیادہ پیچیدہ ہوگئیں۔ ہم نے منطق کی پیروی کی اور جو ٹیکنالوجیز ہم لے کر آئے وہ حقیقت بن گئیں جب ہم نے انہیں صارفین کے لیے لاگو کیا کیونکہ وہ بہت زیادہ معنی خیز تھیں۔ میں آپ کو بتاتا ہوں کہ ایسا کیوں ہے۔
API گیٹ وے میں دراصل عظیم اسکرپٹس کو ضم کرنے کی صلاحیت ہے جو UI ڈویلپرز کے لیے اختتامی نقطہ کے طور پر کام کر سکتی ہے۔ انہوں نے ان میں سے ہر ایک اسکرپٹ کو اس طرح تبدیل کیا کہ تبدیلیاں کرنے کے بعد وہ انہیں پروڈکشن اور پھر صارف کے آلات پر تعینات کر سکیں، اور یہ تمام تبدیلیاں API گیٹ وے میں چلنے والے اختتامی پوائنٹس کے ساتھ ہم آہنگ ہو گئیں۔
تاہم، اس نے ایک نیا یک سنگی بنانے کا مسئلہ دہرایا جہاں API سروس کوڈ کے ساتھ اس طرح اوورلوڈ کیا گیا تھا کہ مختلف ناکامی کے منظرنامے پیش آئے۔ مثال کے طور پر، کچھ اینڈ پوائنٹس کو ہٹا دیا گیا تھا، یا اسکرپٹس نے تصادفی طور پر کسی چیز کے اتنے زیادہ ورژن بنائے ہیں کہ ورژن نے API سروس کی تمام دستیاب میموری کو لے لیا ہے۔
ان اختتامی نقطوں کو لینا اور انہیں API سروس سے باہر نکالنا منطقی تھا۔ ایسا کرنے کے لیے، ہم نے Node.js اجزاء بنائے جو Docker کنٹینرز میں چھوٹے ایپلی کیشنز کے طور پر چلتے تھے۔ اس نے ہمیں ان نوڈ ایپلی کیشنز کی وجہ سے ہونے والی کسی بھی پریشانی اور کریش کو الگ کرنے کی اجازت دی۔
ان تبدیلیوں کی قیمت کافی بڑی ہے اور درج ذیل عوامل پر مشتمل ہے:
- پیداواری ٹولز۔ نئی ٹیکنالوجیز کے انتظام کے لیے نئے ٹولز کی ضرورت ہوتی ہے کیونکہ UI ٹیم، ایک موثر ماڈل بنانے کے لیے بہت اچھی اسکرپٹس کا استعمال کرتے ہوئے، انفراسٹرکچر کو سنبھالنے میں زیادہ وقت نہیں لگاتا تھا، انہیں صرف اسکرپٹ لکھنے اور ان کی فعالیت کو چیک کرنا ہوتا تھا۔
مواقع کی بصیرت اور چھانٹنا - ایک اہم مثال کارکردگی ڈرائیور کی معلومات کو کھولنے کے لیے درکار نئے ٹولز ہیں۔ یہ جاننا ضروری تھا کہ پروسیسر پر کتنا قبضہ ہے، میموری کیسے استعمال ہو رہی ہے، اور اس معلومات کو جمع کرنے کے لیے مختلف ٹولز کی ضرورت تھی۔ - بیس امیجز کا فریگمنٹیشن - سادہ بیس AMI زیادہ بکھرا ہوا اور مخصوص ہو گیا ہے۔
- نوڈ مینجمنٹ۔ کوئی آف دی شیلف فن تعمیر یا ٹیکنالوجی دستیاب نہیں ہے جو آپ کو کلاؤڈ میں نوڈس کا نظم کرنے کی اجازت دے، اس لیے ہم نے Titus بنایا، ایک کنٹینر مینجمنٹ پلیٹ فارم جو توسیع پذیر اور قابل اعتماد کنٹینر کی تعیناتی اور Amazon AWS کے ساتھ کلاؤڈ انضمام فراہم کرتا ہے۔
- لائبریری یا پلیٹ فارم کی نقل۔ پلیٹ فارم کی اسی بنیادی فعالیت کے ساتھ نئی ٹیکنالوجیز فراہم کرنے کے لیے اسے کلاؤڈ بیسڈ Node.js ڈویلپر ٹولز میں نقل کرنے کی ضرورت ہے۔
- سیکھنے کا وکر اور صنعتی تجربہ۔ نئی ٹیکنالوجیز کا تعارف لامحالہ نئے چیلنجز پیدا کرتا ہے جن پر قابو پانا اور ان سے سیکھنا ضروری ہے۔
اس طرح، ہم خود کو ایک "پکی سڑک" تک محدود نہیں رکھ سکتے تھے اور اپنی ٹیکنالوجیز کو آگے بڑھانے کے لیے مسلسل نئے طریقے بناتے تھے۔ اخراجات کو کم رکھنے کے لیے، ہم نے سنٹرلائزڈ سپورٹ کو محدود کیا اور JVM، نئے نوڈس، اور Docker پر توجہ مرکوز کی۔ ہم نے موثر اثرات کو ترجیح دی، ٹیموں کو ان کے فیصلوں کی لاگت کے بارے میں آگاہ کیا، اور ان کی حوصلہ افزائی کی کہ وہ پہلے سے تیار کردہ اعلیٰ اثر والے حلوں کو دوبارہ استعمال کرنے کے طریقے تلاش کریں۔ ہم نے اس نقطہ نظر کا استعمال اس وقت کیا جب سروس کا غیر ملکی زبانوں میں ترجمہ بین الاقوامی کلائنٹس تک مصنوعات کی فراہمی کے لیے کیا۔ مثالوں میں نسبتاً آسان کلائنٹ لائبریریاں شامل ہیں جو خود بخود تیار کی جا سکتی ہیں، تاکہ ازگر کا ورژن، روبی ورژن، جاوا ورژن وغیرہ بنانا کافی آسان ہو۔
ہم مسلسل ثابت شدہ ٹیکنالوجیز کو استعمال کرنے کے مواقع تلاش کر رہے تھے جنہوں نے خود کو ایک جگہ اور اسی طرح کے دیگر حالات میں ثابت کیا تھا۔
آئیے آخری عنصر کے بارے میں بات کرتے ہیں - تبدیلیاں، یا تغیرات۔ دیکھیں کہ ہماری پروڈکٹ کی کھپت ہفتے کے دن اور دن بھر میں گھنٹے کے حساب سے کیسے مختلف ہوتی ہے۔ آپ کہہ سکتے ہیں کہ صبح 9 بجے نیٹ فلکس کے لیے سب سے مشکل وقت ہوتا ہے، جب سسٹم پر لوڈ زیادہ سے زیادہ ہو جاتا ہے۔
ہم کس طرح سافٹ ویئر ایجادات کے نفاذ کی تیز رفتاری حاصل کر سکتے ہیں، یعنی نظام میں مسلسل نئی تبدیلیاں کرتے ہوئے، سروس ڈیلیوری میں رکاوٹیں پیدا کیے بغیر اور اپنے صارفین کو تکلیف پہنچائے بغیر؟ Netflix نے اسے Spinnaker کے استعمال کے ذریعے حاصل کیا، جو ایک نیا عالمی کلاؤڈ بیسڈ مینجمنٹ اور مسلسل ترسیل (CD) پلیٹ فارم ہے۔
تنقیدی طور پر، Spinnaker کو ہمارے بہترین طریقوں کو مربوط کرنے کے لیے ڈیزائن کیا گیا تھا تاکہ جب ہم پروڈکشن میں پرزوں کو تعینات کرتے ہیں، تو ہم آؤٹ پٹ کو براہ راست اپنی میڈیا ڈیلیوری ٹیکنالوجی میں ضم کر سکتے ہیں۔
ہم اپنی ڈیلیوری پائپ لائن میں دو ٹیکنالوجیز کو شامل کرنے میں کامیاب رہے ہیں جن کی ہم بہت قدر کرتے ہیں: خودکار کینری تجزیہ اور مرحلہ وار تعیناتی۔ کینری تجزیہ کا مطلب یہ ہے کہ ہم ٹریفک کی ایک چال کو کوڈ کے نئے ورژن کی طرف بھیجتے ہیں، اور باقی پروڈکشن ٹریفک کو پرانے ورژن کے ذریعے منتقل کرتے ہیں۔ پھر ہم چیک کرتے ہیں کہ نیا کوڈ کام کے ساتھ کس طرح مقابلہ کرتا ہے - موجودہ سے بہتر یا بدتر۔
حیران کن رول آؤٹ کا مطلب یہ ہے کہ اگر ایک علاقے میں رول آؤٹ میں مسائل ہیں، تو ہم دوسرے علاقے میں رول آؤٹ پر چلے جاتے ہیں۔ اس صورت میں، اوپر دی گئی چیک لسٹ کو پروڈکشن پائپ لائن میں شامل کیا جانا چاہیے۔ میں آپ کا کچھ وقت بچاؤں گا اور آپ کو مشورہ دوں گا کہ آپ میری پچھلی گفتگو دیکھیں، انجینئرنگ گلوبل نیٹ فلکس آپریشنز ان دی کلاؤڈ، اگر آپ اس موضوع میں مزید گہرائی میں جانے میں دلچسپی رکھتے ہیں۔ تقریر کی ویڈیو ریکارڈنگ سلائیڈ کے نیچے دیے گئے لنک پر جا کر دیکھی جا سکتی ہے۔
بات کے اختتام پر، میں نیٹ فلکس کی تنظیم اور فن تعمیر کے بارے میں مختصراً بات کروں گا۔ بالکل شروع میں ہمارے پاس الیکٹرانک ڈیلیوری نامی اسکیم تھی، جو NRDP 1.x میڈیا اسٹریمنگ کا پہلا ورژن تھا۔ "بیک اسٹریم" کی اصطلاح یہاں استعمال کی جا سکتی ہے کیونکہ ابتدائی طور پر صارف صرف بعد میں پلے بیک کے لیے ڈیوائس پر مواد ڈاؤن لوڈ کر سکتا تھا۔ Netflix کا پہلا ڈیجیٹل ڈیلیوری پلیٹ فارم، 2009 میں، کچھ اس طرح نظر آیا۔
صارف کے آلے میں Netflix ایپلیکیشن تھی، جس میں NRDP پلیٹ فارم - Netflix ریڈی ڈیوائس پلیٹ فارم پر مبنی UI انٹرفیس، سیکیورٹی ماڈیولز، سروس ایکٹیویشن اور پلے بیک شامل تھا۔
اس وقت یوزر انٹرفیس بہت آسان تھا۔ اس میں وہ تھا جسے Queque Reader کہا جاتا تھا، اور صارف Queque میں کچھ شامل کرنے کے لیے سائٹ پر جائے گا اور پھر اپنے آلے پر شامل مواد کو دیکھے گا۔ مثبت بات یہ تھی کہ فرنٹ اینڈ ٹیم اور بیک اینڈ ٹیم کا تعلق ایک ہی الیکٹرانک ڈیلیوری آرگنائزیشن سے تھا اور آپس میں قریبی ورکنگ ریلیشن شپ تھی۔ پے لوڈ XML کی بنیاد پر بنایا گیا تھا۔ اسی وقت، DVD کے کاروبار کے لیے Netflix API بنایا گیا، جس نے فریق ثالث کی ایپلی کیشنز کو ہماری سروس کی طرف ٹریفک بھیجنے کی ترغیب دی۔
تاہم، Netflix API ایک جدید صارف انٹرفیس کے ساتھ ہماری مدد کرنے کے لیے اچھی طرح سے تیار تھا، جس میں تمام مواد کا میٹا ڈیٹا، کونسی فلمیں دستیاب تھیں اس کے بارے میں معلومات، جس نے واچ لسٹ بنانے کی صلاحیت پیدا کی۔ اس میں JSON اسکیما، HTTP رسپانس کوڈ پر مبنی ایک عام REST API تھا، وہی جو جدید فن تعمیر میں استعمال ہوتا ہے، اور OAuth سیکیورٹی ماڈل، جو اس وقت فرنٹ اینڈ ایپلیکیشن کے لیے درکار تھا۔ اس نے اسٹریمنگ مواد کی ترسیل کے عوامی ماڈل سے نجی میں منتقل ہونا ممکن بنایا۔
منتقلی کے ساتھ مسئلہ فریگمنٹیشن تھا، کیونکہ اب ہمارا سسٹم آپریشن کے مکمل طور پر مختلف اصولوں کی بنیاد پر دو سروسز چلاتا ہے - ایک Rest، JSON اور OAuth پر، دوسری RPC، XML پر اور NTBA ٹوکن سسٹم پر مبنی یوزر سیکیورٹی میکانزم۔ یہ پہلا ہائبرڈ فن تعمیر تھا۔
ہماری دونوں ٹیموں کے درمیان بنیادی طور پر ایک فائر وال تھا کیونکہ ابتدائی طور پر API کا NCCP کے ساتھ بہت اچھا پیمانہ نہیں تھا اور اس کی وجہ سے ٹیموں کے درمیان جھگڑا ہوا۔ اختلافات خدمات، پروٹوکول، سرکٹس، سیکیورٹی ماڈیولز میں تھے اور ڈویلپرز کو اکثر بالکل مختلف سیاق و سباق کے درمیان سوئچ کرنا پڑتا تھا۔
اس سلسلے میں، میری کمپنی کے ایک سینئر انجینئر سے بات ہوئی، جن سے میں نے سوال پوچھا: "صحیح طویل مدتی فن تعمیر کیا ہونا چاہئے؟" اور اس نے جوابی سوال کیا: "آپ شاید زیادہ فکر مند ہیں۔ تنظیمی نتائج کے بارے میں - کیا ہوتا ہے اگر ہم ان چیزوں کو ضم کر دیں، اور وہ اس چیز کو توڑ دیں جو ہم نے اچھا کرنا سیکھا ہے؟ یہ نقطہ نظر کانوے کے قانون سے بہت زیادہ مطابقت رکھتا ہے: "وہ تنظیمیں جو ڈیزائن کے نظام کو ایک ایسے ڈیزائن سے مجبور کرتی ہیں جو اس تنظیم کے مواصلاتی ڈھانچے کو نقل کرتا ہے۔" یہ ایک بہت ہی تجریدی تعریف ہے، اس لیے میں زیادہ مخصوص کو ترجیح دیتا ہوں: "سافٹ ویئر کا کوئی بھی ٹکڑا اس تنظیمی ڈھانچے کی عکاسی کرتا ہے جس نے اسے بنایا ہے۔" ایرک ریمنڈ کا میرا پسندیدہ اقتباس یہ ہے: "اگر آپ کے پاس ڈویلپرز کی چار ٹیمیں ایک کمپائلر پر کام کر رہی ہیں، تو آپ کو چار پاس کمپائلر ملے گا۔" ٹھیک ہے، نیٹ فلکس کے پاس چار پاس کمپائلر ہے، اور ہم اسی طرح کام کرتے ہیں۔
ہم کہہ سکتے ہیں کہ اس معاملے میں دم کتے کو ہلا رہی ہے۔ ہماری پہلی ترجیح حل نہیں بلکہ تنظیم ہے؛ یہ وہ تنظیم ہے جو ہمارے پاس موجود فن تعمیر کو چلاتی ہے۔ دھیرے دھیرے، خدمات کے ایک ہوج پاج سے، ہم ایک ایسے فن تعمیر کی طرف چلے گئے جسے ہم نے بلیڈ رنر کہا، کیونکہ یہاں ہم کنارے کی خدمات اور NCCP کی زوول پراکسی، API گیٹ وے، اور متعلقہ فنکشنل میں براہ راست الگ اور مربوط ہونے کی صلاحیت کے بارے میں بات کر رہے ہیں۔ "ٹکڑوں" کو مزید جدید سیکورٹی، ری پلے، ڈیٹا چھانٹنا، وغیرہ خصوصیات کے ساتھ نئی مائیکرو سروسز میں تبدیل کر دیا گیا ہے۔
اس طرح، یہ کہا جا سکتا ہے کہ محکمانہ ڈھانچے اور کمپنی کی حرکیات نظام کے ڈیزائن کی تشکیل میں اہم کردار ادا کرتی ہیں اور ایک ایسا عنصر ہیں جو تبدیلی کو فروغ دیتا ہے یا اس میں رکاوٹ ڈالتا ہے۔ مائیکرو سروسز کا فن تعمیر پیچیدہ اور نامیاتی ہے، اور اس کی صحت نظم و ضبط اور متعارف افراتفری پر مبنی ہے۔
تھوڑا سا اشتہار
ہمارے ساتھ رہنے کے لیے آپ کا شکریہ۔ کیا آپ کو ہمارے مضامین پسند ہیں؟ مزید دلچسپ مواد دیکھنا چاہتے ہیں؟ آرڈر دے کر یا دوستوں کو مشورہ دے کر ہمارا ساتھ دیں، , انٹری لیول سرورز کا ایک انوکھا اینالاگ، جو ہم نے آپ کے لیے ایجاد کیا تھا: (RAID1 اور RAID10 کے ساتھ دستیاب، 24 کور تک اور 40GB DDR4 تک)۔
ایمسٹرڈیم میں Equinix Tier IV ڈیٹا سینٹر میں Dell R730xd 2 گنا سستا؟ صرف یہاں نیدرلینڈ میں! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 سے! کے بارے میں پڑھا
ماخذ: www.habr.com