Netflix انٽرنيٽ ٽيليويزن مارڪيٽ ۾ اڳواڻ آهي - اها ڪمپني جيڪا ٺاهي ۽ فعال طور تي هن حصي کي ترقي ڪري رهي آهي. Netflix نه رڳو فلمن ۽ ٽي وي سيريز جي وسيع فهرست لاءِ سڃاتي وڃي ٿي جيڪا ڌرتيءَ جي لڳ ڀڳ هر ڪنڊ کان دستياب آهي ۽ ڪنهن به ڊوائيس سان ڊسپلي سان، پر ان جي قابل اعتماد انفراسٽرڪچر ۽ منفرد انجنيئرنگ ڪلچر لاءِ پڻ.
پيچيده سسٽم کي ترقي ۽ سپورٽ ڪرڻ لاءِ Netflix طريقي جو واضح مثال DevOops 2019 تي پيش ڪيو ويو - ڊائريڪٽر آف ڊولپمينٽ Netflix تي. Nizhny Novgorod اسٽيٽ يونيورسٽي جي ڪمپيوٽري رياضي ۽ رياضي جي فيڪلٽي جي گريجوئيٽ. Lobachevsky، سرجي اوپن ڪنيڪٽ ۾ پهريون انجنيئرن مان هڪ - Netflix تي CDN ٽيم. هن وڊيو ڊيٽا جي نگراني ۽ تجزيو ڪرڻ لاءِ سسٽم ٺاهيا، انٽرنيٽ ڪنيڪشن جي رفتار جو اندازو لڳائڻ لاءِ هڪ مشهور سروس FAST.com شروع ڪئي، ۽ گذريل ڪجهه سالن کان انٽرنيٽ جي درخواستن کي بهتر ڪرڻ تي ڪم ڪري رهيو آهي ته جيئن نيٽ فلڪس ايپليڪيشن استعمال ڪندڙن لاءِ جلد کان جلد ڪم ڪري.
رپورٽ کي ڪانفرنس جي شرڪت ڪندڙن کان بهترين تبصرا مليا، ۽ اسان توهان لاء هڪ ٽيڪسٽ ورزن تيار ڪيو آهي.
هن جي رپورٽ ۾، سرجي تفصيل سان ڳالهايو
- انهي بابت جيڪو ڪلائنٽ ۽ سرور جي وچ ۾ انٽرنيٽ جي درخواستن جي دير کي متاثر ڪري ٿو؛
- هن دير کي ڪيئن گھٽائڻ؛
- غلطي برداشت ڪندڙ سسٽم کي ڪيئن ڊزائين، برقرار رکڻ ۽ مانيٽر ڪرڻ؛
- مختصر وقت ۾ نتيجا ڪيئن حاصل ڪجي، ۽ ڪاروبار لاءِ گهٽ ۾ گهٽ خطري سان؛
- نتيجن جو تجزيو ڪيئن ڪجي ۽ غلطين مان سکو.
انهن سوالن جا جواب نه رڳو انهن کي گهربل آهن جيڪي وڏين ڪارپوريشنن ۾ ڪم ڪن ٿا.
پيش ڪيل اصولن ۽ ٽيڪنڪ کي ڄاڻڻ گهرجي ۽ هر ڪنهن جي طرفان مشق ڪيو وڃي جيڪو انٽرنيٽ پروڊڪٽس کي ترقي ۽ سپورٽ ڪري ٿو.
اڳتي هلي بيان آهي اسپيڪر جي نقطه نظر کان.
انٽرنيٽ جي رفتار جي اهميت
انٽرنيٽ جي درخواستن جي رفتار سڌو سنئون ڪاروبار سان لاڳاپيل آهي. شاپنگ انڊسٽري تي غور ڪريو: Amazon 2009 ۾ ته هڪ 100ms دير جي نتيجي ۾ 1% سيلز جي نقصان ۾.
اتي وڌيڪ ۽ وڌيڪ موبائيل ڊوائيسز آهن، جن جي پٺيان موبائل سائيٽون ۽ ايپليڪيشنون. جيڪڏهن توهان جو صفحو لوڊ ٿيڻ ۾ 3 سيڪنڊن کان وڌيڪ وقت وٺي ٿو، ته توهان پنهنجي استعمال ڪندڙن جو اڌ حصو وڃائي رهيا آهيو. سان گوگل ڳولا جي نتيجن ۾ توهان جي صفحي جي لوڊشيڊنگ جي رفتار کي حساب ۾ رکي ٿو: صفحو تيز، گوگل ۾ ان جي پوزيشن اعلي.
ڪنيڪشن جي رفتار پڻ اهم آهي مالي ادارن ۾ جتي ويڪرائي نازڪ آهي. 2015 ۾، Hibernia نيٽ ورڪ نيو يارڪ ۽ لنڊن جي وچ ۾ 400 ملين ڊالر جي ڪيبل، شهرن جي وچ ۾ 6ms تائين دير کي گهٽائڻ لاء. 66 ملين ڊالر جو تصور ڪريو 1 ايم ايس جي دير جي گھٽتائي لاءِ!
جي مطابق 5 Mbit/s کان مٿي ڪنيڪشن جي رفتار هاڻي سڌي طرح هڪ عام ويب سائيٽ جي لوڊشيڊنگ جي رفتار تي اثر انداز نه ٿيندي آهي. بهرحال، ڪنيڪشن جي دير ۽ صفحي جي لوڊشيڊنگ جي رفتار جي وچ ۾ هڪ لڪير تعلق آهي:
بهرحال، Netflix هڪ عام پيداوار نه آهي. استعمال ڪندڙ تي ويڪرائي ۽ رفتار جو اثر تجزيو ۽ ترقي جو هڪ سرگرم علائقو آهي. اتي ايپليڪيشن لوڊ ڪرڻ ۽ مواد جي چونڊ آهي جيڪا دير تي منحصر آهي، پر جامد عناصر لوڊ ڪرڻ ۽ اسٽريمنگ پڻ ڪنيڪشن جي رفتار تي منحصر آهي. انهن اهم عنصرن جو تجزيو ۽ بهتر ڪرڻ جيڪي صارف جي تجربي تي اثرانداز ٿين ٿا Netflix تي ڪيترن ئي ٽيمن لاءِ ترقي جو هڪ سرگرم علائقو آهي. انهن مان هڪ مقصد آهي Netflix ڊوائيسز ۽ ڪلائوڊ انفراسٽرڪچر جي وچ ۾ درخواستن جي دير کي گهٽائڻ.
رپورٽ ۾ اسان خاص طور تي Netflix انفراسٽرڪچر جو مثال استعمال ڪندي ويڪرائي کي گهٽائڻ تي ڌيان ڏينداسين. اچو ته هڪ عملي نقطه نظر کان غور ڪريون ته پيچيده ورهايل نظام جي ڊيزائن، ترقي ۽ آپريشن جي عملن کي ڪيئن پهچائجي ۽ آپريشنل مسئلن ۽ خرابين جي تشخيص ڪرڻ بجاءِ جدت ۽ نتيجن تي وقت گذاريو.
Netflix اندر
هزارين مختلف ڊوائيسز Netflix ايپس کي سپورٽ ڪن ٿيون. اهي چار مختلف ٽيمن پاران ٺاهيا ويا آهن، جيڪي Android، iOS، ٽي وي ۽ ويب برائوزرن لاء ڪلائنٽ جا الڳ ورزن ٺاهيندا آهن. ۽ اسان صارف جي تجربي کي بهتر ۽ ذاتي ڪرڻ تي تمام گهڻي ڪوشش ڪندا آهيون. هن کي ڪرڻ لاءِ، اسان متوازي ۾ سوين A/B ٽيسٽ هلون ٿا.
ذاتي ڪرڻ کي AWS ڪلائوڊ ۾ سوين مائڪرو سروسز جي مدد ڪئي وئي آهي، ذاتي صارف ڊيٽا مهيا ڪندي، پڇا ڳاڇا، ٽيليميٽري، بگ ڊيٽا ۽ انڪوڊنگ. ٽريفڪ جو تصور هن طرح نظر اچي ٿو:
کاٻي پاسي داخلا پوائنٽ آھي، ۽ پوء ٽريفڪ ڪيترن ئي سو microservices ۾ ورهايو ويو آھي جيڪي مختلف پس منظر ٽيمن جي مدد سان آھن.
اسان جي انفراسٽرڪچر جو ٻيو اهم حصو Open Connect CDN آهي، جيڪو جامد مواد آخر صارف تائين پهچائي ٿو - وڊيوز، تصويرون، ڪلائنٽ ڪوڊ وغيره. سي ڊي اين ڪسٽم سرورز تي واقع آهي (OCA - Open Connect Appliance). اندر اندر SSD ۽ HDD ڊرائيو جون صفون آهن جيڪي آپٽمائزڊ فري بي ايس ڊي هلائينديون آهن، NGINX ۽ خدمتن جي هڪ سيٽ سان. اسان هارڊويئر ۽ سافٽ ويئر جي اجزاء کي ڊزائين ۽ بهتر بڻايون ٿا ته جيئن هڪ CDN سرور استعمال ڪندڙن کي ممڪن حد تائين ڊيٽا موڪلي سگهي.
انٽرنيٽ ٽريفڪ ايڪسچينج پوائنٽ (انٽرنيٽ ايڪسچينج - IX) تي انهن سرورن جي ”ديوار“ هن طرح نظر اچي ٿي:
انٽرنيٽ ايڪسچينج انٽرنيٽ سروس فراهم ڪندڙن ۽ مواد فراهم ڪندڙن لاءِ هڪ ٻئي سان ”ڳنڍڻ“ جي صلاحيت فراهم ڪري ٿي ته جيئن انٽرنيٽ تي وڌيڪ سڌي طرح ڊيٽا مٽائي سگهجي. دنيا ۾ لڳ ڀڳ 70-80 انٽرنيٽ ايڪسچينج پوائنٽس آهن جتي اسان جا سرور نصب ٿيل آهن، ۽ اسان انهن کي آزاديءَ سان انسٽال ۽ برقرار رکون ٿا:
ان کان علاوه، اسان پڻ سرور مهيا ڪندا آهيون سڌو سنئون انٽرنيٽ فراهم ڪندڙن کي، جيڪي اهي انهن جي نيٽ ورڪ ۾ نصب ڪن ٿا، Netflix ٽرئفڪ جي لوڪلائيزيشن ۽ صارفين لاء اسٽريمنگ جي معيار کي بهتر بڻائي ٿو:
AWS خدمتن جو هڪ سيٽ ڪلائنٽ کان وڊيو درخواستن کي CDN سرورز ڏانهن موڪلڻ جو ذميوار آهي، انهي سان گڏ سرورز کي ترتيب ڏيڻ - مواد، پروگرام ڪوڊ، سيٽنگون، وغيره کي اپڊيٽ ڪرڻ. بعد ۾، اسان هڪ ريبون نيٽ ورڪ پڻ ٺاهيو جيڪو سرورز کي انٽرنيٽ ايڪسچينج پوائنٽس ۾ AWS سان ڳنڍي ٿو. بيڪ بون نيٽ ورڪ فائبر آپٽڪ ڪيبلز ۽ روٽرز جو هڪ عالمي نيٽ ورڪ آهي جنهن کي اسان پنهنجي ضرورتن جي بنياد تي ڊزائين ۽ ترتيب ڏئي سگهون ٿا.
پاران , اسان جو CDN انفراسٽرڪچر دنيا جي انٽرنيٽ ٽريفڪ جو تقريباً ⅛ چوٽي ڪلاڪن دوران ۽ ⅓ ٽريفڪ اتر آمريڪا ۾ پهچائي ٿو، جتي Netflix تمام گهڻي عرصي کان رهيو آهي. متاثر ڪندڙ انگ، پر منهنجي لاءِ سڀ کان وڌيڪ حيرت انگيز ڪاميابين مان هڪ اها آهي ته سمورو CDN سسٽم 150 کان گهٽ ماڻهن جي ٽيم ٺاهي ۽ سنڀاليو.
شروعات ۾، سي ڊي اين انفراسٽرڪچر کي ويڊيو ڊيٽا پهچائڻ لاءِ ٺاهيو ويو هو. جڏهن ته، وقت سان گڏ اسان اهو محسوس ڪيو ته اسان ان کي استعمال ڪري سگهون ٿا متحرڪ درخواستن کي بهتر ڪرڻ لاءِ ڪلائنٽ AWS ڪلائوڊ ۾.
انٽرنيٽ جي رفتار بابت
اڄ، Netflix وٽ 3 AWS علائقا آهن، ۽ بادل ڏانهن درخواستن جي دير تي منحصر هوندو ته گراهڪ ويجهي علائقي کان ڪيترو پري آهي. ساڳئي وقت، اسان وٽ ڪيترائي سي ڊي اين سرور آهن جيڪي جامد مواد پهچائڻ لاء استعمال ڪيا ويا آهن. ڇا هن فريم ورڪ کي استعمال ڪرڻ جو ڪو طريقو آهي متحرڪ سوالن کي تيز ڪرڻ لاءِ؟ بهرحال، بدقسمتي سان، انهن درخواستن کي ڪيش ڪرڻ ناممڪن آهي - APIs ذاتي ٿيل آهن ۽ هر نتيجو منفرد آهي.
اچو ته CDN سرور تي هڪ پراڪسي ٺاهي ۽ ان ذريعي ٽرئفڪ موڪلڻ شروع ڪريون. ڇا اهو تيز ٿي ويندو؟
مواد
اچو ته ياد رکون ته نيٽ ورڪ پروٽوڪول ڪيئن ڪم ڪن ٿا. اڄ، انٽرنيٽ تي اڪثر ٽرئفڪ HTTPs استعمال ڪري ٿو، جيڪو هيٺين پرت پروٽوڪول تي منحصر آهي TCP ۽ TLS. ڪلائنٽ لاءِ سرور سان ڳنڍڻ لاءِ، اهو هڪ هٿ ملائي ٿو، ۽ هڪ محفوظ ڪنيڪشن قائم ڪرڻ لاءِ، ڪلائنٽ کي ٽي ڀيرا سرور سان پيغامن جي مٽاسٽا ڪرڻ جي ضرورت آهي ۽ ڊيٽا کي منتقل ڪرڻ لاءِ گهٽ ۾ گهٽ هڪ وڌيڪ وقت. 100 ms جي هڪ راؤنڈ ٽرپ (RTT) جي دير سان، اهو اسان کي وٺي 400 ms ڊيٽا جي پهرين بٽ حاصل ڪرڻ لاء:
جيڪڏهن اسان سرٽيفڪيٽن کي CDN سرور تي رکون ٿا، ته پوءِ ڪلائنٽ ۽ سرور جي وچ ۾ هٿ ملائڻ جو وقت تمام گهٽ ٿي سگهي ٿو جيڪڏهن CDN ويجهو آهي. اچو ته فرض ڪريون CDN سرور جي ويڪرائي 30ms آهي. ان کان پوء ان کي 220 ms وٺي ويندي پهرين بٽ حاصل ڪرڻ لاء:
پر فائدا اتي ختم نه ڪندا آھن. هڪ ڀيرو ڪنيڪشن قائم ٿيڻ کان پوءِ، TCP ڪنجيشن ونڊو وڌائيندو آهي (اها معلومات جي مقدار جيڪا اها ان ڪنيڪشن تي متوازي طور تي منتقل ڪري سگهي ٿي). جيڪڏهن ڊيٽا پيڪٽ گم ٿي وڃي، ته پوءِ ٽي سي پي پروٽوڪول (جهڙوڪ ٽي سي پي نيو رينو) جا ڪلاسڪ لاڳو ڪرڻ کليل ”ونڊو“ کي اڌ کان گھٽ ڪري ٿو. ڪنجيشن ونڊو جي واڌ، ۽ ان جي ٻيهر بحالي جي رفتار جو دارومدار سرور ڏانهن دير (RTT) تي آهي. جيڪڏهن اهو ڪنيڪشن صرف CDN سرور تائين وڃي ٿو، هي وصولي تيز ٿي ويندي. ساڳئي وقت، پيڪٽ نقصان هڪ معياري رجحان آهي، خاص طور تي وائرلیس نيٽ ورڪن لاء.
انٽرنيٽ بينڊوڊٿ گھٽجي سگھي ٿي، خاص طور تي چوٽي جي ڪلاڪن دوران، صارفين جي ٽرئفڪ جي ڪري، جيڪا ٽرئفڪ جام ٿي سگھي ٿي. بهرحال، انٽرنيٽ تي ڪو به طريقو ناهي ته ڪجهه درخواستن کي ٻين تي ترجيح ڏي. مثال طور، ترجيح ڏيو ننڍڙن ۽ ويڪرائي حساس درخواستن کي ”هيوي“ ڊيٽا اسٽريمز تي جيڪي نيٽ ورڪ کي لوڊ ڪن ٿا. تنهن هوندي، اسان جي صورت ۾، اسان جي پنهنجي پٺتي نيٽ ورڪ هجڻ جي ڪري اسان کي اهو ڪرڻ جي اجازت ڏئي ٿو درخواست جي رستي جي حصي تي - CDN ۽ ڪلائوڊ جي وچ ۾، ۽ اسان ان کي مڪمل طور تي ترتيب ڏئي سگهون ٿا. توهان پڪ ڪري سگهو ٿا ته ننڍا ۽ ويڪرائي حساس پيڪيٽس کي ترجيح ڏني وئي آهي، ۽ وڏي ڊيٽا جي وهڪري ٿوري دير کان پوء وڃو. CDN جي ڪلائنٽ جي ويجهو آهي، ڪارڪردگي وڌيڪ.
ايپليڪيشن ليول پروٽوڪول (او ايس آءِ ليول 7) پڻ دير تي اثر انداز ٿين ٿا. نئون پروٽوڪول جهڙوڪ HTTP/2 متوازي درخواستن جي ڪارڪردگي کي بهتر بڻائي ٿو. بهرحال، اسان وٽ آهن Netflix ڪلائنٽ پراڻن ڊوائيسز سان جيڪي نئين پروٽوڪول کي سپورٽ نٿا ڪن. نه سڀئي ڪلائنٽ اپڊيٽ ٿي سگھن ٿا يا بهتر طور تي ترتيب ڏنل. ساڳئي وقت، سي ڊي اين پراکسي ۽ بادل جي وچ ۾ مڪمل ڪنٽرول ۽ نئين، بهتر پروٽوڪول ۽ سيٽنگون استعمال ڪرڻ جي صلاحيت آهي. پراڻي پروٽوڪول سان غير موثر حصو صرف ڪلائنٽ ۽ سي ڊي اين سرور جي وچ ۾ ڪم ڪندو. ان کان علاوه، اسان CDN ۽ ڪلائوڊ جي وچ ۾ اڳ ۾ ئي قائم ڪيل ڪنيڪشن تي ملٽي پلڪس درخواستون ڪري سگهون ٿا، TCP سطح تي ڪنيڪشن جي استعمال کي بهتر بڻائي:
اسان ماپون ٿا
ان حقيقت جي باوجود ته نظريو بهتري جو واعدو ڪري ٿو، اسان فوري طور تي پيداوار ۾ سسٽم شروع ڪرڻ لاء جلدي نٿا ڪريون. ان جي بدران، اسان کي پهريان ثابت ڪرڻ گهرجي ته اهو خيال عملي طور تي ڪم ڪندو. هن کي ڪرڻ لاء، توهان کي ڪيترن ئي سوالن جا جواب ڏيڻ جي ضرورت آهي:
- اسپيڊ: ڇا هڪ پراڪس تيز ٿيندو؟
- اعتبار: ڇا اهو وڌيڪ ڀڃندو؟
- مشڪل: ايپليڪيشنن سان ڪيئن ضم ٿيڻ؟
- جي قيمت: اضافي انفراسٽرڪچر کي ترتيب ڏيڻ جي قيمت ڪيتري آهي؟
اچو ته تفصيل سان غور ڪريون ته اسان جي پهرين نقطي جو اندازو لڳائڻ لاء. باقي ساڳئي طريقي سان ڊيل ڪيو ويو آهي.
درخواستن جي رفتار جو تجزيو ڪرڻ لاءِ، اسان چاهيون ٿا ته سڀني استعمال ڪندڙن لاءِ ڊيٽا حاصل ڪرڻ کان سواءِ، ترقي تي گھڻو وقت خرچ ڪرڻ ۽ پيداوار کي ٽوڙڻ کان سواءِ. ھن لاء ڪيترائي طريقا آھن:
- RUM، يا غير فعال درخواست جي ماپ. اسان صارفين جي موجوده درخواستن جي عمل جي وقت کي ماپ ڪريون ٿا ۽ مڪمل صارف ڪوريج کي يقيني بڻائين ٿا. نقصان اهو آهي ته سگنل تمام مستحڪم نه آهي ڪيترن ئي عنصر جي ڪري، مثال طور، مختلف درخواستن جي سائز جي ڪري، سرور تي پروسيسنگ وقت ۽ ڪلائنٽ. اضافي طور تي، توهان پيداوار ۾ اثر کان سواء نئين ترتيب جي جانچ نٿا ڪري سگهو.
- ليبارٽري ٽيسٽ. خاص سرور ۽ انفراسٽرڪچر جيڪي گراهڪن کي نقل ڪن ٿا. انهن جي مدد سان، اسان کي ضروري امتحان وٺي. هن طريقي سان اسان ماپ جي نتيجن ۽ واضح سگنل تي مڪمل ڪنٽرول حاصل ڪندا آهيون. پر ڊوائيسز ۽ صارف جي جڳهن جي ڪا به مڪمل ڪوريج نه آهي (خاص طور تي دنيا جي خدمت سان ۽ هزارين ڊوائيس ماڊلز جي مدد سان).
توهان ٻنهي طريقن جي فائدن کي ڪيئن گڏ ڪري سگهو ٿا؟
اسان جي ٽيم هڪ حل مليو آهي. اسان ڪوڊ جو ھڪڙو ننڍڙو ٽڪرو لکيو آھي - ھڪڙو نمونو - جيڪو اسان پنھنجي ايپليڪيشن ۾ ٺاھيو آھي. جاچ اسان کي اسان جي ڊوائيسز مان مڪمل طور تي ڪنٽرول ٿيل نيٽ ورڪ ٽيسٽ ڪرڻ جي اجازت ڏين ٿيون. اهو هن طرح ڪم ڪري ٿو:
- ايپليڪيشن کي لوڊ ڪرڻ ۽ شروعاتي سرگرمي کي مڪمل ڪرڻ کان پوء، اسان اسان جي تحقيقات کي هلائيندا آهيون.
- ڪلائنٽ سرور ڏانهن درخواست ڪري ٿو ۽ ٽيسٽ لاءِ ”ترڪيب“ وصول ڪري ٿو. ترڪيب URLs جي ھڪڙي فهرست آھي جنھن کي HTTP(s) جي درخواست ڪرڻ جي ضرورت آھي. ان کان علاوه، ترڪيب درخواست جي پيٽرولن کي ترتيب ڏئي ٿو: درخواستن جي وچ ۾ دير، درخواست ڪيل ڊيٽا جي مقدار، HTTP(s) هيڊر، وغيره. ساڳئي وقت، اسين متوازي طور تي ڪيترن ئي مختلف ترڪيبون کي جانچي سگھون ٿا - جڏهن ترتيب جي درخواست ڪريون ٿا، اسان بي ترتيب سان طئي ڪريون ٿا ته ڪهڙو نسخو جاري ڪيو وڃي.
- پروب لانچ جو وقت چونڊيو ويو آهي ته جيئن ڪلائنٽ تي نيٽ ورڪ وسيلن جي فعال استعمال سان تڪرار نه ٿئي. لازمي طور تي، وقت چونڊيو ويندو آهي جڏهن ڪلائنٽ فعال نه آهي.
- ترڪيب حاصل ڪرڻ کان پوء، ڪلائنٽ هر يو آر ايل کي درخواست ڪري ٿو، متوازي ۾. هر هڪ پتي جي درخواست کي بار بار ڪري سگهجي ٿو - جنهن کي سڏيو ويندو آهي. "دال". پهرين نبض تي، اسان اندازو لڳايو ته ڪنيڪشن قائم ڪرڻ ۽ ڊيٽا ڊائون لوڊ ڪرڻ ۾ ڪيترو وقت لڳو. ٻئين پلس تي، اسان وقت کي ماپ ڪريون ٿا جيڪو اڳ ۾ ئي قائم ڪيل ڪنيڪشن تي ڊيٽا لوڊ ڪرڻ ۾ وٺندو آهي. ٽئين کان پهريان، اسان دير ڪري سگهون ٿا ۽ ٻيهر ڪنيڪشن قائم ڪرڻ جي رفتار کي ماپ ڪري سگهون ٿا، وغيره.
امتحان دوران، اسان سڀني ماپن کي ماپ ڪريون ٿا جيڪي ڊوائيس حاصل ڪري سگھن ٿا:
- DNS درخواست جو وقت؛
- TCP ڪنيڪشن سيٽ اپ وقت؛
- TLS ڪنيڪشن سيٽ اپ وقت؛
- ڊيٽا جي پهرين بائيٽ حاصل ڪرڻ جو وقت؛
- مڪمل لوڊشيڊنگ وقت؛
- حالت جو نتيجو ڪوڊ.
- سڀني دال مڪمل ٿيڻ کان پوء، نموني تجزيي لاء سڀني ماپن کي لوڊ ڪري ٿو.
اھم نقطا آھن ڪلائنٽ تي منطق تي گھٽ انحصار، سرور تي ڊيٽا پروسيسنگ ۽ متوازي درخواستن جي ماپ. اهڙيء طرح، اسان مختلف عنصرن جي اثر کي الڳ ڪرڻ ۽ جانچڻ جي قابل آهيون جيڪي سوال جي ڪارڪردگي تي اثر انداز ڪندا آهن، انهن کي هڪ واحد نسخ ۾ مختلف ڪري، ۽ حقيقي مراجعين کان نتيجا حاصل ڪندا.
هي انفراسٽرڪچر صرف سوالن جي ڪارڪردگي جي تجزيي کان وڌيڪ ڪارائتو ثابت ٿيو آهي. في الحال اسان وٽ 14 فعال ترڪيبون آهن، في سيڪنڊ کان وڌيڪ 6000 نمونا، زمين جي سڀني ڪنڊن کان ڊيٽا حاصل ڪرڻ ۽ مڪمل ڊوائيس ڪوريج. جيڪڏهن Netflix هڪ ٽئين پارٽي کان ساڳي خدمت خريد ڪري، اهو هڪ سال ۾ لکين ڊالر خرچ ڪندو، تمام خراب ڪوريج سان.
عملي طور تي جاچ جو نظريو: پروٽوٽائپ
اهڙي سسٽم سان، اسان درخواست جي دير تي CDN پراکسيز جي اثرائتي جو جائزو وٺڻ جي قابل هئا. هاڻي توهان کي ضرورت آهي:
- هڪ پراکسي پروٽوٽائپ ٺاهيو؛
- پروٽوٽائپ کي سي ڊي اين تي رکو؛
- اهو طئي ڪيو ته ڪئين گراهڪن کي هڪ مخصوص CDN سرور تي پراکسي ڏانهن سڌو رستو ڏيکاريندي؛
- پراکسي کانسواءِ AWS ۾ درخواستن سان ڪارڪردگي جو مقابلو ڪريو.
ڪم اهو آهي ته تجويز ڪيل حل جي اثرائتي جو جائزو وٺڻ جيترو جلدي ممڪن ٿي سگهي. اسان سٺي نيٽ ورڪنگ لائبريرين جي دستيابي جي ڪري پروٽوٽائپ کي لاڳو ڪرڻ لاءِ Go چونڊيو. هر CDN سرور تي، اسان پروٽوٽائپ پراکسي کي هڪ مستحڪم بائنري طور نصب ڪيو انحصار کي گهٽائڻ ۽ انضمام کي آسان ڪرڻ لاءِ. شروعاتي عمل ۾، اسان معياري اجزاء استعمال ڪيو جيترو ممڪن آھي ۽ معمولي ترميمن لاءِ HTTP/2 ڪنيڪشن پولنگ ۽ درخواست ملٽي پلڪسنگ.
AWS علائقن جي وچ ۾ توازن قائم ڪرڻ لاءِ، اسان استعمال ڪيو هڪ جغرافيائي DNS ڊيٽابيس، ساڳيو ئي ڪلائنٽ کي بيلنس ڪرڻ لاءِ استعمال ڪيو ويو. ڪلائنٽ لاءِ CDN سرور چونڊڻ لاءِ، اسان انٽرنيٽ ايڪسچينج (IX) ۾ سرورز لاءِ TCP Anycast استعمال ڪندا آهيون. هن اختيار ۾، اسان سڀني CDN سرورز لاءِ هڪ IP پتو استعمال ڪندا آهيون، ۽ ڪلائنٽ کي هدايت ڪئي ويندي CDN سرور ڏانهن گهٽ ۾ گهٽ IP هپس جي تعداد سان. انٽرنيٽ فراهم ڪندڙ (ISPs) پاران نصب ڪيل CDN سرورز ۾، اسان وٽ TCP Anycast ترتيب ڏيڻ لاءِ روٽر تي ڪنٽرول نه آهي، تنهنڪري اسان استعمال ڪريون ٿا ، جيڪو صارفين کي وڊيو اسٽريمنگ لاءِ انٽرنيٽ فراهم ڪندڙن ڏانهن سڌو رستو ڏيکاريندو آهي.
تنهن ڪري، اسان وٽ ٽن قسمن جي درخواست جا رستا آهن: ڪلائوڊ ڏانهن کليل انٽرنيٽ ذريعي، IX ۾ هڪ CDN سرور ذريعي، يا هڪ انٽرنيٽ فراهم ڪندڙ تي واقع CDN سرور ذريعي. اسان جو مقصد اهو سمجهڻ آهي ته ڪهڙو طريقو بهتر آهي، ۽ هڪ پراکسي جو ڪهڙو فائدو آهي، انهي جي مقابلي ۾ ته ڪيئن درخواستون پيداوار ڏانهن موڪلي وينديون آهن. هن کي ڪرڻ لاء، اسان هيٺ ڏنل نموني سسٽم استعمال ڪندا آهيون:
هر هڪ رستو هڪ الڳ ٽارگيٽ بڻجي ويندو آهي، ۽ اسان کي نظر اچي ٿو جيڪو اسان کي مليو آهي. تجزيو لاءِ، اسان پراڪسي نتيجن کي ھڪڙي گروپ ۾ گڏ ڪريون ٿا (IX ۽ ISP پراڪسيز جي وچ ۾ بھترين وقت چونڊيو)، ۽ انھن کي پراڪسي کانسواءِ بادل ڏانھن درخواستن جي وقت سان ڀيٽ ڪريو:
جئين توهان ڏسي سگهو ٿا، نتيجن کي ملايو ويو آهي - اڪثر ڪيسن ۾ پراکسي هڪ سٺي رفتار ڏئي ٿي، پر اتي پڻ ڪافي تعداد ۾ گراهڪ آهن جن لاء صورتحال خراب ٿي ويندي.
نتيجي طور، اسان ڪيترائي اهم ڪم ڪيا:
- اسان CDN پراکسي ذريعي ڪلائنٽ کان ڪلائوڊ تائين درخواستن جي متوقع ڪارڪردگي جو اندازو لڳايو.
- اسان ڊيٽا حاصل ڪئي حقيقي گراهڪن کان، سڀني قسمن جي ڊوائيسز کان.
- اسان محسوس ڪيو ته نظريو 100٪ تصديق ٿيل نه هو ۽ هڪ CDN پراکسي سان ابتدائي آڇ اسان لاء ڪم نه ڪندي.
- اسان خطرو نه ورتو - اسان گراهڪن لاءِ پيداوار جي ترتيبن کي تبديل نه ڪيو.
- ڪجھ به نه ٽوڙيو ويو.
پروٽوٽائپ 2.0
تنهن ڪري، ڊرائنگ بورڊ ڏانهن واپس وڃو ۽ عمل کي ٻيهر ورجايو.
خيال اهو آهي ته 100٪ پراکسي استعمال ڪرڻ جي بدران، اسان هر ڪلائنٽ لاء تيز ترين رستو طئي ڪنداسين، ۽ اسان اتي درخواستون موڪلينداسين - اهو آهي، اسان اهو ڪنداسين جيڪو ڪلائنٽ اسٽيئرنگ سڏيو ويندو آهي.
ان تي عمل ڪيئن ڪجي؟ اسان سرور جي پاسي تي منطق استعمال نٿا ڪري سگهون، ڇاڪاڻ ته ... مقصد هن سرور سان ڳنڍڻ آهي. ڪلائنٽ تي اهو ڪرڻ لاء ڪجهه طريقو هجڻ گهرجي. ۽ مثالي طور تي، هن کي گهٽ ۾ گهٽ پيچيده منطق سان ڪريو، جيئن ته ڪلائنٽ پليٽ فارمن جي وڏي تعداد سان انضمام جي مسئلي کي حل نه ڪيو وڃي.
جواب DNS استعمال ڪرڻ آهي. اسان جي صورت ۾، اسان وٽ اسان جو پنهنجو DNS انفراسٽرڪچر آهي، ۽ اسان هڪ ڊومين زون قائم ڪري سگهون ٿا جنهن لاءِ اسان جا سرور بااختيار هوندا. اهو هن طرح ڪم ڪري ٿو:
- ڪلائنٽ هڪ ميزبان استعمال ڪندي DNS سرور کي درخواست ڪري ٿو، مثال طور api.netflix.xom.
- درخواست اسان جي DNS سرور تي اچي ٿي
- DNS سرور ڄاڻي ٿو ته ڪهڙو رستو هن ڪلائنٽ لاءِ تيز ترين آهي ۽ لاڳاپيل IP پتو جاري ڪري ٿو.
حل ۾ هڪ اضافي پيچيدگي آهي: بااختيار DNS فراهم ڪندڙ ڪلائنٽ جي IP پتي کي نه ڏسندا آهن ۽ صرف ٻيهر ورجائيندڙ حل ڪندڙ جو IP پتو پڙهي سگهن ٿا جيڪو ڪلائنٽ استعمال ڪري ٿو.
نتيجي طور، اسان جي بااختيار حل ڪندڙ کي فيصلو ڪرڻ گهرجي هڪ فرد ڪلائنٽ لاء نه، پر گراهڪن جي هڪ گروهه لاءِ مبني حل ڪندڙ جي بنياد تي.
حل ڪرڻ لاءِ، اسين ساڳيا نمونا استعمال ڪريون ٿا، ڪلائنٽ مان ماپ جا نتيجا مجموعا ڪريون ٿا ھر ھڪ ورجائيندڙ حل ڪندڙن لاءِ ۽ فيصلو ڪريون ٿا ته انھن جي ھن گروپ کي ڪٿي موڪليو وڃي - ھڪ پراڪسي IX ذريعي TCP Anycast ذريعي، ISP پراکسي ذريعي، يا سڌو بادل ڏانھن.
اسان هيٺ ڏنل سسٽم حاصل ڪندا آهيون:
نتيجو ڪندڙ DNS اسٽيئرنگ ماڊل توهان کي ڪلائنٽ کان ڪلائوڊ تائين ڪنيڪشن جي رفتار جي تاريخي مشاهدن جي بنياد تي ڪلائنٽ کي سڌو ڪرڻ جي اجازت ڏئي ٿو.
ٻيهر، سوال اهو آهي ته اهو طريقو ڪيترو اثرائتو ڪم ڪندو؟ جواب ڏيڻ لاء، اسان ٻيهر استعمال ڪندا آهيون اسان جي تحقيقاتي سسٽم. تنهن ڪري، اسان پيش ڪندڙ جي ترتيب کي ترتيب ڏيو ٿا، جتي هڪ مقصد DNS اسٽيرنگ کان هدايت جي پيروي ڪري ٿو، ٻيو سڌو سنئون بادل ڏانهن (موجوده پيداوار).
نتيجي طور، اسان نتيجن جو مقابلو ڪريون ٿا ۽ اثرائتي جو جائزو وٺون ٿا:
نتيجي طور، اسان ڪيترائي اهم شيون سکيا:
- اسان DNS اسٽيئرنگ استعمال ڪندي ڪلائنٽ کان ڪلائوڊ تائين درخواستن جي متوقع ڪارڪردگي جو جائزو ورتو.
- اسان ڊيٽا حاصل ڪئي حقيقي گراهڪن کان، سڀني قسمن جي ڊوائيسز کان.
- تجويز ڪيل خيال جي اثرائتي ثابت ٿي چڪي آهي.
- اسان خطرو نه ورتو - اسان گراهڪن لاءِ پيداوار جي ترتيبن کي تبديل نه ڪيو.
- ڪجھ به نه ٽوڙيو ويو.
هاڻي ڏکيو حصو بابت - اسان ان کي پيداوار ۾ شروع ڪيو
آسان حصو هاڻي ختم ٿي چڪو آهي - اتي هڪ ڪم ڪندڙ پروٽوٽائپ آهي. ھاڻي مشڪل حصو Netflix جي سموري ٽرئفڪ لاءِ حل شروع ڪري رھيو آھي، 150 ملين صارفين، ھزارين ڊيوائسز، سوين مائڪرو سروسز، ۽ ھڪ ھميشه بدلجندڙ پراڊڪٽ ۽ انفراسٽرڪچر کي ترتيب ڏيڻ. Netflix سرورز في سيڪنڊ لکين درخواستون وصول ڪن ٿا، ۽ بي پرواھ عمل سان خدمت کي ٽوڙڻ آسان آھي. ساڳي ئي وقت، اسان انٽرنيٽ تي هزارين CDN سرورز ذريعي متحرڪ طور تي ٽرئفڪ کي روٽ ڪرڻ چاهيون ٿا، جتي ڪا شيءِ تبديل ٿيندي رهي ٿي ۽ وقفي وقفي سان ۽ انتهائي غير مناسب وقت تي.
۽ ان سان گڏ، ٽيم وٽ 3 انجنيئر آهن جيڪي سسٽم جي ترقي، تعیناتي ۽ مڪمل مدد لاء ذميوار آهن.
تنهن ڪري، اسان آرام ۽ صحتمند ننڊ بابت ڳالهائڻ جاري رکون ٿا.
ڪيئن ترقي جاري رکڻ ۽ مدد تي پنهنجو سمورو وقت خرچ نه ڪيو؟ اسان جو طريقو 3 اصولن تي ٻڌل آهي:
- اسان ٽوڙڻ جي امڪاني پيماني کي گھٽائيندا آهيون (بلاسٽ ريڊيس).
- اسان حيرانگي لاءِ تياري ڪري رهيا آهيون - اسان اميد ڪريون ٿا ته ٽيسٽ ۽ ذاتي تجربي جي باوجود ، ڪجهه ڀڃي ويندو.
- شاندار تباهي - جيڪڏهن ڪا شيء صحيح ڪم نه ڪري، اهو خودڪار طريقي سان مقرر ڪيو وڃي، جيتوڻيڪ تمام موثر طريقي سان نه.
اهو ظاهر ٿيو ته اسان جي صورت ۾، هن مسئلي جي هن طريقي سان، اسان هڪ سادي ۽ موثر حل ڳولي سگهون ٿا ۽ خاص طور تي سسٽم سپورٽ کي آسان بڻائي سگهون ٿا. اسان محسوس ڪيو ته اسان ڪلائنٽ ۾ ڪوڊ جو هڪ ننڍڙو ٽڪرو شامل ڪري سگهون ٿا ۽ ڪنيڪشن جي مسئلن جي ڪري نيٽ ورڪ جي درخواست جي غلطي جي نگراني ڪري سگهون ٿا. نيٽ ورڪ جي غلطين جي صورت ۾، اسان سڌو سنئون بادل ڏانهن واپس آڻينداسين. اهو حل ڪلائنٽ ٽيمن لاءِ وڏي ڪوشش جي ضرورت ناهي، پر اسان لاءِ غير متوقع ڀڃڪڙي ۽ تعجب جي خطري کي تمام گهڻو گهٽائي ٿو.
يقينن، واپسي جي باوجود، اسان ترقي جي دوران واضح نظم جي پيروي ڪندا آهيون:
- نموني ٽيسٽ.
- A/B جاچ يا ڪينري.
- ترقي پسند رول آئوٽ.
نموني سان، طريقي سان بيان ڪيو ويو آهي - تبديليون پهريون ڀيرو هڪ ڪسٽمائيز ريزڪي استعمال ڪندي آزمائي رهيا آهن.
ڪينري جي جاچ لاءِ، اسان کي ضرورتن مطابق سرورن جا تقابلي جوڙا حاصل ڪرڻا پوندا جن تي اسين مقابلو ڪري سگھون ٿا ته سسٽم ڪيئن ڪم ڪري ٿو تبديلين کان اڳ ۽ پوءِ. ائين ڪرڻ لاءِ، اسان جي ڪيترن ئي CDN سائيٽن مان، اسان سرورن جا جوڙا چونڊون ٿا جيڪي نسبتاً ٽريفڪ وصول ڪن ٿا:
پوء اسان ڪينري سرور تي تبديلين سان تعمير کي انسٽال ڪريو. نتيجن جو جائزو وٺڻ لاءِ، اسان ھڪ سسٽم ھلائيندا آھيون جيڪو تقريباً 100-150 ميٽرڪ جو مقابلو ڪري ٿو ڪنٽرول سرور جي نموني سان:
جيڪڏهن ڪينري جاچ ڪامياب ٿئي ٿي، ته پوءِ اسان ان کي بتدريج، موجن ۾ ڇڏي ڏيون ٿا. اسان هر سائيٽ تي هڪ ئي وقت سرورز کي اپڊيٽ نه ڪندا آهيون - مسئلن جي ڪري پوري سائيٽ کي وڃائڻ مختلف هنڌن تي سرورن جو هڪ ئي تعداد وڃائڻ کان وڌيڪ صارفين جي خدمت تي وڌيڪ اهم اثر آهي.
عام طور تي، هن طريقي جي اثرائتي ۽ حفاظت جو دارومدار گڏ ڪيل ميٽرڪ جي مقدار ۽ معيار تي آهي. اسان جي پڇا ڳاڇا جي رفتار سسٽم لاءِ، اسان سڀني ممڪن حصن مان ميٽرڪ گڏ ڪريون ٿا:
- گراهڪن کان - سيشن ۽ درخواستن جو تعداد، واپسي جي شرح؛
- proxy - انگن اکرن ۽ درخواستن جو وقت؛
- DNS - درخواستن جو تعداد ۽ نتيجا؛
- ڪلائوڊ ايج - ڪلائوڊ ۾ درخواستن جي پروسيسنگ لاءِ نمبر ۽ وقت.
هي سڀ هڪ واحد پائپ لائن ۾ گڏ ڪيو ويو آهي، ۽، ضرورتن جي بنياد تي، اسان فيصلو ڪريون ٿا ته ڪهڙن ميٽرڪس کي حقيقي وقت جي اينالائيٽڪس ڏانهن موڪليو وڃي، ۽ ڪهڙو وڌيڪ تفصيلي تشخيص لاءِ Elasticsearch يا Big Data ڏانهن.
مانيٽر ڪريون ٿا
اسان جي صورت ۾، اسان ڪلائنٽ ۽ سرور جي وچ ۾ درخواستن جي نازڪ رستي تي تبديليون ڪري رهيا آهيون. ساڳئي وقت، ڪلائنٽ تي مختلف حصن جو تعداد، سرور تي، ۽ انٽرنيٽ ذريعي رستي تي تمام وڏو آهي. ڪلائنٽ ۽ سرور تي تبديليون مسلسل ٿينديون آهن - ڪيترن ئي ٽيمن جي ڪم جي دوران ۽ ماحولياتي نظام ۾ قدرتي تبديليون. اسان وچ ۾ آهيون - جڏهن مسئلن جي تشخيص، اتي هڪ سٺو موقعو آهي ته اسان شامل ٿينداسين. تنهن ڪري، اسان کي واضح طور تي سمجهڻ جي ضرورت آهي ته ڪيئن وضاحت ڪرڻ، گڏ ڪرڻ ۽ تجزيو ڪرڻ لاء ميٽرڪس کي تڪڙو تڪڙو الڳ ڪرڻ لاء.
مثالي طور تي، حقيقي وقت ۾ سڀني قسمن جي ميٽرڪس ۽ فلٽرن تائين مڪمل رسائي. پر اتي ڪيترائي ميٽرڪ آھن، تنھنڪري قيمت جو سوال پيدا ٿئي ٿو. اسان جي صورت ۾، اسان ميٽرڪ ۽ ترقي جا اوزار الڳ ڪريون ٿا:
مسئلن کي ڳولڻ ۽ ٽريج ڪرڻ لاءِ اسان پنهنجو اوپن سورس ريئل ٽائيم سسٽم استعمال ڪندا آهيون и - ڏسڻ لاء. اهو ميموري ۾ مجموعي ميٽرڪ محفوظ ڪري ٿو، قابل اعتماد آهي ۽ خبرداري سسٽم سان ضم ٿي. لوڪلائيزيشن ۽ تشخيص لاءِ، اسان وٽ ايلسٽسٽڪ سرچ ۽ ڪبانا کان لاگ تائين رسائي آهي. شمارياتي تجزيي ۽ ماڊلنگ لاءِ، اسان ٽيبلائو ۾ وڏي ڊيٽا ۽ تصوير استعمال ڪندا آهيون.
اهو لڳي ٿو ته هن طريقي سان ڪم ڪرڻ تمام ڏکيو آهي. بهرحال، ميٽرڪس ۽ اوزار کي ترتيب وار ترتيب ڏيڻ سان، اسان تڪڙو هڪ مسئلي جو تجزيو ڪري سگهون ٿا، مسئلي جو قسم طئي ڪري سگھون ٿا، ۽ پوءِ تفصيلي ميٽرڪس ۾ ڊرل ڪري سگھون ٿا. عام طور تي، اسان اٽڪل 1-2 منٽ خرچ ڪريون ٿا بريڪ ڊائون جو ذريعو سڃاڻڻ لاءِ. ان کان پوء، اسان تشخيص تي هڪ مخصوص ٽيم سان ڪم ڪريون ٿا - ڏهن منٽن کان ڪيترن ئي ڪلاڪن تائين.
جيتوڻيڪ تشخيص جلدي ٿي چڪو آهي، اسان نٿا چاهيون ته اهو اڪثر ٿئي. مثالي طور، اسان صرف هڪ نازڪ خبرداري حاصل ڪنداسين جڏهن خدمت تي هڪ اهم اثر آهي. اسان جي پڇا ڳاڇا جي رفتار واري نظام لاءِ، اسان وٽ صرف 2 الرٽ آھن جيڪي مطلع ڪندا:
- ڪلائنٽ فال بيڪ فيصد - گراهڪ جي رويي جو جائزو؛
- سيڪڙو پروب غلطيون - نيٽ ورڪ حصن جي استحڪام ڊيٽا.
اهي نازڪ خبرداري مانيٽر ڪن ٿا ته ڇا سسٽم اڪثريت استعمال ڪندڙن لاءِ ڪم ڪري رهيو آهي. اسان ڏسون ٿا ته ڪيترا گراهڪ استعمال ڪيا ويا واپسي جي صورت ۾ جيڪڏهن اهي درخواست جي رفتار حاصل ڪرڻ جي قابل نه هئا. اسان سراسري طور تي 1 نازڪ خبرداري في هفتي کان گھٽ آھي، جيتوڻيڪ اتي تبديلين جو ھڪڙو ٽين آھي سسٽم ۾. اهو اسان لاء ڪافي ڇو آهي؟
- اسان جي پراکسي ڪم نه ڪرڻ جي صورت ۾ هڪ ڪلائنٽ فال بيڪ آهي.
- اتي هڪ خودڪار اسٽيرنگ سسٽم آهي جيڪو مسئلن جو جواب ڏئي ٿو.
پوئين بابت وڌيڪ تفصيل. اسان جي آزمائشي نظام، ۽ خودڪار طريقي سان ڪلائنٽ کان ڪلائوڊ تائين درخواستن لاء بهترين رستو طئي ڪرڻ لاء، اسان کي خودڪار طريقي سان ڪجهه مسئلن کي منهن ڏيڻ جي اجازت ڏئي ٿو.
اچو ته اسان جي نموني جي ترتيب ۽ 3 واٽ جي زمرے ڏانھن موٽون. لوڊشيڊنگ وقت جي اضافي ۾، اسان پاڻ کي پهچائڻ جي حقيقت کي ڏسي سگهون ٿا. جيڪڏهن ڊيٽا لوڊ ڪرڻ ممڪن نه هو، ته پوءِ مختلف رستن تي نتيجن کي ڏسڻ سان اسان اهو طئي ڪري سگهون ٿا ته ڪٿي ۽ ڪهڙي ڀڃڪڙي آهي، ۽ ڇا اسان ان کي خودڪار طريقي سان درست ڪري سگھون ٿا درخواست جي رستي کي تبديل ڪندي.
مثال:
اهو عمل خودڪار ٿي سگهي ٿو. ان کي اسٽيرنگ سسٽم ۾ شامل ڪريو. ۽ ان کي سيکاريو ڪارڪردگي ۽ قابل اعتماد مسئلن جو جواب ڏيڻ. جيڪڏهن ڪجهه ڀڃڻ شروع ٿئي ٿو، رد عمل ڪريو جيڪڏهن ڪو بهتر اختيار آهي. ساڳئي وقت، هڪ فوري ردعمل نازڪ نه آهي، گراهڪن تي واپسي جي مهرباني.
اهڙيء طرح، نظام جي حمايت جي اصولن کي هيٺين ريت ڪري سگهجي ٿو:
- ڀڃڪڙي جي پيماني کي گهٽائڻ؛
- ميٽرڪ گڏ ڪرڻ؛
- اسان خودڪار طريقي سان خرابي جي مرمت ڪندا آهيون جيڪڏهن اسان ڪري سگهون ٿا؛
- جيڪڏهن اهو نه ٿي سگهي، اسان توهان کي مطلع ڪنداسين؛
- اسان جلدي جواب ڏيڻ لاءِ ڊيش بورڊ ۽ ٽريج ٽول سيٽ تي ڪم ڪري رهيا آهيون.
سکيا جا سبق
پروٽوٽائپ لکڻ ۾ گهڻو وقت نه ٿو لڳي. اسان جي حالت ۾، اهو 4 مهينن کان پوء تيار ٿي ويو. ان سان گڏ اسان نئين ميٽرڪ حاصل ڪئي، ۽ ترقي جي شروعات کان 10 مهينن بعد اسان کي پهريون پيداوار ٽرئفڪ ملي. پوءِ مشڪل ۽ تمام ڏکيو ڪم شروع ٿيو: تدريجي طور تي پيداوار ۽ سسٽم کي ماپ ڪريو، مکيه ٽرئفڪ کي لڏپلاڻ ڪريو ۽ غلطين مان سکو. بهرحال، اهو اثرائتو عمل لڪير نه ٿيندو - سڀني ڪوششن جي باوجود، هر شيء جي اڳڪٿي نه ٿي سگهي. اهو تمام گهڻو اثرائتو آهي جلدي ٻيهر ورجائڻ ۽ نئين ڊيٽا جو جواب ڏيڻ.
اسان جي تجربي جي بنياد تي، اسان ھيٺ ڏنل سفارش ڪري سگھون ٿا:
- توهان جي intuition تي اعتبار نه ڪريو.
اسان جي وجدان اسان کي مسلسل ناڪام ٿي، اسان جي ٽيم جي ميمبرن جي وسيع تجربو باوجود. مثال طور، اسان CDN پراکسي استعمال ڪرڻ، يا TCP Anycast جي رويي جي متوقع رفتار جي غلط اڳڪٿي ڪئي.
- پيداوار مان ڊيٽا حاصل ڪريو.
اهو ضروري آهي ته جيترو جلدي ممڪن ٿي سگهي گهٽ ۾ گهٽ پيداوار جي ڊيٽا جي هڪ ننڍڙي مقدار تائين رسائي حاصل ڪريو. ليبارٽري جي حالتن ۾ منفرد ڪيسن، ترتيبن ۽ سيٽنگن جو تعداد حاصل ڪرڻ تقريبا ناممڪن آهي. نتيجن تائين جلدي رسائي توهان کي جلدي ممڪن مسئلن جي باري ۾ سکڻ جي اجازت ڏيندو ۽ انهن کي سسٽم جي فن تعمير ۾ اڪائونٽ ۾ وٺي ويندي.
- ٻين ماڻهن جي صلاحن ۽ نتيجن جي پيروي نه ڪريو - پنهنجو ڊيٽا گڏ ڪريو.
ڊيٽا گڏ ڪرڻ ۽ تجزيو ڪرڻ جي اصولن تي عمل ڪريو، پر ٻين ماڻهن جي نتيجن ۽ بيانن کي انڌو نه ڪريو. صرف توهان ڄاڻو ٿا ته توهان جي استعمال ڪندڙن لاء ڇا ڪم ڪري ٿو. توهان جا سسٽم ۽ توهان جا گراهڪ شايد ٻين ڪمپنين کان مختلف هوندا. خوشقسمتيءَ سان، تجزيي جا اوزار ھاڻي دستياب ۽ استعمال ڪرڻ آسان آھن. نتيجا جيڪي توھان حاصل ڪندا آھن اھي نه آھن Netflix، Facebook، Akamai ۽ ٻيون ڪمپنيون دعويٰ ڪن ٿيون. اسان جي صورت ۾، TLS، HTTP2 جي ڪارڪردگي يا DNS درخواستن تي انگ اکر Facebook، Uber، Akamai جي نتيجن کان مختلف آهن - ڇاڪاڻ ته اسان وٽ مختلف ڊوائيسز، ڪلائنٽ ۽ ڊيٽا جي وهڪري آهي.
- غير ضروري طور تي فيشن جي رجحانات جي پيروي نه ڪريو ۽ اثرائتي جو جائزو وٺو.
سادو شروع ڪريو. اھو بھتر آھي تھ ٿورڙي وقت ۾ ھڪڙو سادو ڪم ڪرڻ وارو نظام ٺاھيو ان کان سواءِ ته گھڻو وقت خرچ ڪرڻ لاءِ انھن اجزاء کي ڊولپ ڪرڻ جن جي توھان کي ضرورت ناھي. توهان جي ماپن ۽ نتيجن جي بنياد تي ڪم ۽ مسئلا حل ڪريو.
- نئين ايپليڪيشنن لاءِ تيار ٿي وڃو.
جيئن ته سڀني مسئلن جي اڳڪٿي ڪرڻ ڏکيو آهي، اهو اڳ ۾ ئي فائدي ۽ ايپليڪيشنن جي اڳڪٿي ڪرڻ ڏکيو آهي. شروعات کان هڪ اشارو وٺو - انهن جي صلاحيت ڪسٽمر جي حالتن سان مطابقت ڪرڻ جي. توھان جي صورت ۾، توھان ڳولي سگھوٿا نوان مسئلا ۽ انھن جو حل. اسان جي پروجيڪٽ ۾، اسان درخواست جي دير کي گهٽائڻ لاء هڪ مقصد مقرر ڪيو. بهرحال، تجزيو ۽ بحثن دوران، اسان محسوس ڪيو ته اسان پڻ استعمال ڪري سگهون ٿا پراکسي سرور:
- AWS علائقن ۾ ٽرئفڪ کي توازن ڪرڻ ۽ خرچن کي گھٽائڻ؛
- CDN استحڪام کي ماڊل ڪرڻ لاء؛
- DNS ترتيب ڏيڻ لاء؛
- TLS/TCP ترتيب ڏيڻ لاءِ.
ٿڪل
رپورٽ ۾، مون بيان ڪيو ته ڪيئن Netflix ڪلائنٽ ۽ ڪلائوڊ جي وچ ۾ انٽرنيٽ جي درخواستن کي تيز ڪرڻ جو مسئلو حل ڪري ٿو. اسان ڪئين ڊيٽا گڏ ڪندا آهيون ڪلائنٽ تي نموني سسٽم استعمال ڪندي، ۽ گڏ ڪيل تاريخي ڊيٽا کي استعمال ڪريون روٽ جي پيداوار جي درخواستن کي ڪلائنٽ کان انٽرنيٽ تي تيز ترين رستي ذريعي. هن ڪم کي حاصل ڪرڻ لاءِ اسان ڪيئن استعمال ڪريون ٿا نيٽ ورڪ پروٽوڪول جا اصول، اسان جي CDN انفراسٽرڪچر، ريبون نيٽ ورڪ، ۽ DNS سرور.
بهرحال، اسان جو حل صرف هڪ مثال آهي ته ڪيئن اسان Netflix تي اهڙي نظام کي لاڳو ڪيو. ڇا اسان لاء ڪم ڪيو. توهان لاءِ منهنجي رپورٽ جو لاڳو ڪيل حصو ترقي ۽ حمايت جا اصول آهن جن تي اسان عمل ڪريون ٿا ۽ سٺا نتيجا حاصل ڪريون ٿا.
اسان جي مسئلي جو حل شايد توهان کي مناسب نه هجي. تنهن هوندي، نظريو ۽ ڊزائين جا اصول باقي آهن، جيتوڻيڪ توهان وٽ پنهنجو CDN انفراسٽرڪچر نه آهي، يا جيڪڏهن اهو اسان کان گهڻو مختلف آهي.
ڪاروباري درخواستن جي رفتار جي اهميت پڻ اهم رهي ٿي. ۽ جيتوڻيڪ هڪ سادي خدمت لاءِ توهان کي چونڊڻ جي ضرورت آهي: ڪلائوڊ فراهم ڪندڙن جي وچ ۾، سرور جي جڳهه، CDN ۽ DNS فراهم ڪندڙ. توهان جي پسند توهان جي گراهڪن لاءِ انٽرنيٽ جي سوالن جي اثرائتي تي اثر انداز ٿيندي. ۽ اهو ضروري آهي ته توهان هن اثر کي ماپڻ ۽ سمجهڻ لاء.
سادي حلن سان شروع ڪريو، خيال رکو ته توهان ڪيئن پراڊڪٽ کي تبديل ڪندا آهيو. سکو جيئن توهان وڃو ۽ سسٽم کي بهتر ڪريو توهان جي گراهڪن جي ڊيٽا جي بنياد تي، توهان جي انفراسٽرڪچر، ۽ توهان جي ڪاروبار. ڊزائن جي عمل دوران غير متوقع خرابي جي امڪان بابت سوچيو. ۽ پوء توهان پنهنجي ترقي جي عمل کي تيز ڪري سگهو ٿا، حل جي ڪارڪردگي کي بهتر بڻائي سگهو ٿا، غير ضروري سپورٽ جي بار کان بچڻ ۽ آرام سان سمهڻ.
هن سال آن لائن فارميٽ ۾. توھان سوال پڇي سگھو ٿا ھڪڙي پيءُ کان DevOps، جان وليس پاڻ!
جو ذريعو: www.habr.com