د انټرنیټ غوښتنې ګړندۍ کړئ او په ارامه خوب وکړئ

Netflix د انټرنیټ تلویزیون بازار کې مشر دی - هغه شرکت چې رامینځته کړی او په فعاله توګه دې برخې ته وده ورکوي. Netflix نه یوازې د دې د فلمونو او تلویزیون لړۍ پراخه کتلاګ لپاره پیژندل کیږي چې د سیارې نږدې هر کونج کې شتون لري او د نندارې سره هر وسیله شتون لري ، بلکه د دې د باور وړ زیربنا او ځانګړي انجینري کلتور لپاره هم پیژندل کیږي.

د پیچلو سیسټمونو پراختیا او ملاتړ لپاره د Netflix چلند روښانه مثال په DevOops 2019 کې وړاندې شو سرګي فیدوروف - په Netflix کې د پراختیا رییس. د نزني نووګورډ دولتي پوهنتون د کمپیوټري ریاضیاتو او ریاضیاتو پوهنځي فارغ شوی. لوباچوفسکي، سرګي په Netflix کې د Open Connect - CDN ټیم کې یو له لومړنیو انجینرانو څخه دی. هغه د ویډیو ډیټا د څارنې او تحلیل لپاره سیسټمونه جوړ کړل، د انټرنیټ اتصال سرعت ارزولو لپاره یو مشهور خدمت FAST.com پیل کړ، او د تیرو څو کلونو راهیسې د انټرنیټ غوښتنو اصلاح کولو لپاره کار کوي ترڅو د Netflix غوښتنلیک د کاروونکو لپاره ژر تر ژره کار وکړي.

راپور د کنفرانس ګډونوالو څخه غوره بیاکتنې ترلاسه کړې، او موږ ستاسو لپاره د متن نسخه چمتو کړې.

په خپل راپور کې، سرګي په تفصیل سره خبرې وکړې

• د هغه څه په اړه چې د پیرودونکي او سرور ترمنځ د انټرنیټ غوښتنو ځنډ اغیزه کوي؛
• دا ځنډ څنګه کم کړو؛
• د خطا زغمونکي سیسټمونو ډیزاین، ساتنه او څارنه څنګه؛
• څنګه په لنډ وخت کې پایلې ترلاسه کول، او سوداګرۍ ته د لږ خطر سره؛
• څنګه پایلې تحلیل کړئ او له غلطیو زده کړئ.

د دې پوښتنو ځوابونه نه یوازې د هغو کسانو لخوا چې په لویو شرکتونو کې کار کوي اړتیا لري.

وړاندې شوي اصول او تخنیکونه باید د هر چا لخوا وپیژندل شي او تمرین شي څوک چې د انټرنیټ محصولاتو وده او ملاتړ کوي.

بل د وینا کونکي له لید څخه روایت دی.

د انټرنیټ سرعت اهمیت

د انټرنیټ غوښتنو سرعت مستقیم په سوداګرۍ پورې اړه لري. د پیرود صنعت ته پام وکړئ: ایمیزون په 2009 کې خبرې وکړېچې د 100ms ځنډ پایله د پلور 1٪ له لاسه ورکوي.

دلته ډیر او ډیر ګرځنده وسایل شتون لري، د ګرځنده سایټونو او غوښتنلیکونو په تعقیب. که ستاسو پاڼه د پورته کولو لپاره له 3 ثانیو څخه ډیر وخت ونیسي، تاسو د خپلو کاروونکو نیمایي له لاسه ورکوئ. سره جولای ۲۰۲۱ ګوګل د لټون پایلو کې ستاسو د پاڼې د بارولو سرعت په پام کې نیسي: څومره چې پاڼه ګړندۍ وي، په ګوګل کې د هغې موقعیت لوړ وي.

د ارتباط سرعت په مالي ادارو کې هم مهم دی چیرې چې ځنډ خورا مهم دی. په 2015 کې، د هیبرنیا شبکې ختم شوی د نیویارک او لندن تر مینځ د 400 ملیون ډالرو کیبل د 6ms لخوا د ښارونو ترمینځ ځنډ کمولو لپاره. د 66 ms ځنډ کمولو لپاره 1 ملیون ډالر تصور کړئ!

د څيړنه، د ارتباط سرعت له 5 Mbit/s څخه پورته نور نور مستقیم د یوې عادي ویب پاڼې د بارولو سرعت اغیزه نه کوي. په هرصورت، د پیوستون ځنډ او د پاڼې د پورته کولو سرعت ترمنځ یو خطي اړیکه شتون لري:

په هرصورت، Netflix یو عادي محصول نه دی. په کارونکي باندې د ځنډ او سرعت اغیزه د تحلیل او پراختیا فعاله ساحه ده. د غوښتنلیک بار کول او د مینځپانګې انتخاب شتون لري چې په ځنډ پورې اړه لري ، مګر د جامد عناصرو بار کول او سټینګ کول هم د اتصال سرعت پورې اړه لري. د کلیدي فکتورونو تحلیل او اصلاح کول چې د کاروونکي تجربه اغیزه کوي په Netflix کې د ډیری ټیمونو لپاره د پراختیا فعاله ساحه ده. یو له اهدافو څخه د Netflix وسیلو او کلاوډ زیربنا ترمینځ د غوښتنو ځنډ کمول دي.

په راپور کې به موږ په ځانګړي ډول د Netflix زیربنا مثال په کارولو سره د ځنډ کمولو باندې تمرکز وکړو. راځئ چې د عملي نظر څخه په پام کې ونیسو چې څنګه د پیچلي ویشل شوي سیسټمونو ډیزاین ، پراختیا او عملیاتو پروسې ته نږدې شو او د عملیاتي ستونزو او ماتیدو تشخیص کولو پرځای په نوښت او پایلو وخت مصرف کړو.

د Netflix دننه

په زرګونو مختلف وسایل د Netflix ایپس ملاتړ کوي. دوی د څلورو مختلف ټیمونو لخوا رامینځته شوي ، کوم چې د Android ، iOS ، تلویزیون او ویب براوزرونو لپاره د پیرودونکي جلا نسخې رامینځته کوي. او موږ د کارونکي تجربې ښه کولو او شخصي کولو لپاره ډیرې هڅې مصرف کوو. د دې کولو لپاره، موږ په موازي ډول په سلګونو A/B ازموینې ترسره کوو.

شخصي کول د AWS کلاوډ کې د سلګونو مایکرو خدماتو لخوا ملاتړ کیږي ، د شخصي کارونکي ډیټا ، د پوښتنو لیږلو ، ټیلی میټري ، لوی ډیټا او کوډ کول چمتو کوي. د ټرافیک لید داسې ښکاري:

د مظاهرې سره د ویډیو لینک (6:04-6:23)

په ښي خوا کې د ننوتلو نقطه ده، او بیا ټرافیک د څو سوو مایکرو خدماتو ترمنځ ویشل کیږي چې د بیالبیلو پس منظر ټیمونو لخوا ملاتړ کیږي.

زموږ د زیربنا بله مهمه برخه د Open Connect CDN دی، کوم چې پای کارونکي ته جامد مواد وړاندې کوي - ویډیو، انځورونه، د پیرودونکي کوډ، او نور. CDN په ګمرکي سرورونو کې موقعیت لري (OCA - د نښلولو وسیله خلاص کړئ). دننه د SSD او HDD ډرایو لړۍ شتون لري چې مطلوب FreeBSD پرمخ وړي ، د NGINX او خدماتو سیټ سره. موږ د هارډویر او سافټویر برخې ډیزاین او اصلاح کوو ترڅو دا ډول CDN سرور کاروونکو ته د امکان تر حده ډیر معلومات واستوي.

د انټرنیټ ترافیک تبادلې نقطه کې د دې سرورونو "دیوال" (د انټرنیټ تبادله - IX) داسې ښکاري:

د انټرنیټ تبادله د انټرنیټ خدماتو چمتو کونکو او د مینځپانګې چمتو کونکو لپاره وړتیا چمتو کوي ترڅو یو بل سره "وصل" وکړي ترڅو په انټرنیټ کې مستقیم ډیټا تبادله کړي. په ټوله نړۍ کې نږدې 70-80 د انټرنیټ تبادلې نقطې شتون لري چیرې چې زموږ سرورونه نصب شوي، او موږ په خپلواکه توګه نصب او ساتو:

برسېره پردې، موږ د انټرنیټ چمتو کونکو ته مستقیم سرورونه هم چمتو کوو، کوم چې دوی په خپل شبکه کې نصبوي، د Netflix ټرافیک سیمه ایز کول او د کاروونکو لپاره د سټینګ کیفیت ښه کول:

د AWS خدماتو یوه سیټ د پیرودونکو څخه د CDN سرورونو ته د ویډیو غوښتنې لیږلو مسؤلیت لري ، په بیله بیا د سرورونو پخپله تنظیم کول - د مینځپانګې تازه کول ، د برنامې کوډ ، تنظیمات او نور. د وروستي لپاره، موږ د بیکبون شبکه هم جوړه کړه چې د انټرنیټ ایکسچینج پوائنټونو کې سرورونه د AWS سره وصل کوي. د بیکبون شبکه د فایبر آپټیک کیبلونو او روټرونو نړیواله شبکه ده چې موږ کولی شو د خپلو اړتیاو پراساس ډیزاین او ترتیب کړو.

د د ساندوین اټکلونه، زموږ د CDN زیربنا د نړۍ د انټرنیټ ترافیک نږدې ⅛ د لوړ ساعتونو په جریان کې او ⅓ په شمالي امریکا کې ترافیک وړاندې کوي ، چیرې چې Netflix تر ټولو اوږد دی. د پام وړ شمیرې، مګر زما لپاره یو له خورا حیرانتیا وړ لاسته راوړنو څخه دا دی چې د CDN ټول سیسټم د 150 څخه د کم خلکو د ټیم لخوا رامینځته شوی او ساتل کیږي.

په پیل کې، د CDN زیربنا د ویډیو ډاټا وړاندې کولو لپاره ډیزاین شوې وه. په هرصورت، د وخت په تیریدو سره موږ پوهیږو چې موږ کولی شو دا د AWS کلاوډ کې د پیرودونکو څخه متحرک غوښتنې غوره کولو لپاره هم وکاروو.

د انټرنیټ سرعت په اړه

نن ورځ، Netflix 3 AWS سیمې لري، او بادل ته د غوښتنو ځنډ به پدې پورې اړه ولري چې پیرودونکي له نږدې سیمې څخه څومره لرې دي. په ورته وخت کې، موږ ډیری CDN سرورونه لرو چې د جامد مینځپانګې وړاندې کولو لپاره کارول کیږي. ایا د متحرک پوښتنو ګړندی کولو لپاره د دې چوکاټ کارولو کومه لاره شتون لري؟ په هرصورت، له بده مرغه، د دې غوښتنو زیرمه کول ناممکن دي - APIs شخصي شوي او هره پایله ځانګړې ده.

راځئ چې په CDN سرور کې پراکسي جوړ کړو او د هغې له لارې د ترافیک لیږل پیل کړو. ایا دا به چټک وي؟

مواد

راځئ چې په یاد ولرو چې د شبکې پروتوکول څنګه کار کوي. نن ورځ، په انټرنیټ کې ډیری ترافیک HTTPs کاروي، کوم چې د ټیټ پرت پروتوکولونو TCP او TLS پورې اړه لري. د دې لپاره چې یو پیرودونکي له سرور سره وصل شي، دا لاسي صنایع کوي، او د خوندي پیوستون رامینځته کولو لپاره، پیرودونکي اړتیا لري چې درې ځله د سرور سره پیغامونه تبادله کړي او لږترلږه یو ځل د ډیټا لیږدولو لپاره. د 100 ms په هر دورې سفر (RTT) کې ځنډ سره، دا به موږ ته 400 ms وخت ونیسو چې د معلوماتو لومړی برخه ترلاسه کړو:

که موږ سندونه په CDN سرور کې ځای په ځای کړو، نو د پیرودونکي او سرور تر مینځ د لاس اخیستو وخت د پام وړ کم کیدی شي که چیرې CDN نږدې وي. راځئ فرض کړو چې د CDN سرور ته ځنډ 30ms دی. بیا به د لومړي بټ ترلاسه کولو لپاره 220 ms وخت ونیسي:

مګر ګټې هلته پای ته نه رسیږي. یوځل چې اړیکه جوړه شي، TCP د کنجشن کړکۍ زیاتوي (د هغه معلوماتو مقدار چې دا کولی شي په موازي ډول د دې اړیکې څخه لیږدول شي). که چیرې د ډیټا کڅوړه ورکه شي ، نو د TCP پروتوکول کلاسیک پلي کول (لکه د TCP نوي رینو) خلاص "کړکۍ" نیمه راټیټوي. د کنجیشن کړکۍ وده، او بیا د ضایع کیدو څخه د هغې د بیرته راګرځیدو سرعت سرور ته په ځنډ (RTT) پورې اړه لري. که دا اړیکه یوازې د CDN سرور ته لاړ شي، دا بیا رغونه به چټکه وي. په ورته وخت کې، د پیکټ ضایع یو معیاري پدیده ده، په ځانګړې توګه د بېسیم شبکې لپاره.

د انټرنیټ بینډ ویت ممکن کم شي ، په ځانګړي توګه د ساعتونو ساعتونو په جریان کې ، د کاروونکو ترافیک له امله ، کوم چې د ترافیک جام لامل کیدی شي. په هرصورت، په انټرنیټ کې هیڅ لاره شتون نلري چې ځینې غوښتنو ته د نورو په پرتله لومړیتوب ورکړي. د مثال په توګه، د "درو" ډیټا جریانونو په پرتله کوچني او ځنډ سره حساس غوښتنو ته لومړیتوب ورکړئ چې شبکه باروي. په هرصورت، زموږ په قضیه کې، زموږ د خپل بیکون شبکې درلودل موږ ته اجازه راکوي چې دا د غوښتنې لارې په برخه کې ترسره کړو - د CDN او بادل ترمنځ، او موږ کولی شو دا په بشپړه توګه تنظیم کړو. تاسو کولی شئ ډاډ ترلاسه کړئ چې کوچني او د ځنډ سره حساس پاکټونه لومړیتوب لري، او د لوی معلوماتو جریان یو څه وروسته ځي. هرڅومره چې CDN پیرودونکي ته نږدې وي ، هومره یې موثریت ډیر وي.

د غوښتنلیک کچې پروتوکولونه (OSI کچه 7) هم په ځنډ باندې اغیزه لري. نوي پروتوکولونه لکه HTTP/2 د موازي غوښتنو فعالیت غوره کوي. په هرصورت، موږ د زړو وسیلو سره د Netflix پیرودونکي لرو چې د نوي پروتوکولونو ملاتړ نه کوي. ټول پیرودونکي نشي کولی نوي یا په غوره توګه تنظیم شي. په ورته وخت کې، د CDN پراکسي او بادل ترمنځ بشپړ کنټرول او د نوي، غوره پروتوکولونو او ترتیباتو کارولو وړتیا شتون لري. د زړو پروتوکولونو سره غیر مؤثره برخه به یوازې د پیرودونکي او CDN سرور ترمنځ کار وکړي. برسېره پردې، موږ کولی شو د CDN او کلاوډ تر مینځ دمخه رامینځته شوي اړیکې باندې ملټي پلیکس غوښتنې وکړو ، د TCP په کچه د اتصال کارولو ته وده ورکول:

موږ اندازه کوو

د دې حقیقت سره سره چې تیوري د پرمختګونو ژمنه کوي، موږ سمدستي په تولید کې د سیسټم په لاره اچولو کې بیړه نه کوو. پرځای یې، موږ باید لومړی دا ثابت کړو چې دا نظر به په عمل کې کار وکړي. د دې کولو لپاره تاسو اړتیا لرئ څو پوښتنې ځواب کړئ:

• چټک: ایا پراکسي به چټکه وي؟
• باور: دا به ډیر ځله مات شي؟
• مشکل: څنګه د غوښتنلیکونو سره یوځای کول؟
• د لګښت: د اضافي زیربنا د ځای پرځای کولو لګښت څومره دی؟

راځئ چې د لومړي ټکي ارزولو لپاره زموږ چلند په تفصیل سره په پام کې ونیسو. پاتې نور په ورته ډول چلند کیږي.

د غوښتنو سرعت تحلیل کولو لپاره، موږ غواړو د ټولو کاروونکو لپاره ډاټا ترلاسه کړو، پرته له دې چې په پراختیا کې ډیر وخت مصرف کړي او د تولید ماتولو پرته. د دې لپاره څو لارې شتون لري:

1. RUM، یا غیر فعال غوښتنه اندازه کول. موږ د کاروونکو څخه د اوسني غوښتنو اجرا کولو وخت اندازه کوو او د کارونکي بشپړ پوښښ ډاډمن کوو. نیمګړتیا دا ده چې سیګنال د ډیری فاکتورونو له امله خورا باثباته ندي ، د مثال په توګه ، د مختلف غوښتنې اندازې له امله ، په سرور او پیرودونکي کې د پروسس کولو وخت. سربیره پردې ، تاسو نشئ کولی په تولید کې د تاثیر پرته نوي ترتیب ازموینه وکړئ.
2. لابراتوار ازموینې. ځانګړي سرورونه او زیربناوې چې پیرودونکي تقلید کوي. د دوی په مرسته موږ اړین ازموینې ترسره کوو. پدې توګه موږ د اندازه کولو پایلو او روښانه سیګنال باندې بشپړ کنټرول ترلاسه کوو. مګر د وسیلو او کارونکي ځایونو بشپړ پوښښ شتون نلري (په ځانګړي توګه د نړۍ په کچه خدمت او د زرګونو وسیلو ماډلونو ملاتړ سره).

تاسو څنګه کولی شئ د دواړو میتودونو ګټې سره یوځای کړئ؟

زموږ ټیم د حل لاره موندلې ده. موږ د کوډ یوه کوچنۍ ټوټه لیکلې - یوه نمونه - کوم چې موږ په خپل غوښتنلیک کې جوړ کړی. تحقیقات موږ ته اجازه راکوي چې زموږ د وسیلو څخه په بشپړ ډول کنټرول شوي شبکې ازموینې ترسره کړو. دا په دې ډول کار کوي:

1. د غوښتنلیک بارولو او د لومړني فعالیت بشپړولو سمدستي وروسته، موږ خپل تحقیقات پرمخ وړو.
2. پیرودونکي سرور ته غوښتنه کوي او د ازموینې لپاره "ترکیب" ترلاسه کوي. ترکیب د یو آر ایل لیست دی چې د HTTP (s) غوښتنه ورته اړتیا لري. سربیره پردې ، ترکیب د غوښتنې پیرامیټونه تنظیموي: د غوښتنو ترمینځ ځنډ ، د غوښتل شوي ډیټا مقدار ، HTTP(s) سرلیکونه او نور. په ورته وخت کې، موږ کولی شو څو مختلف ترکیبونه موازي ازموینه وکړو - کله چې د ترتیب غوښتنه وکړو، موږ په تصادفي ډول مشخص کوو چې کوم ترکیب باید صادر شي.
3. د پلټنې د پیل وخت ټاکل شوی ترڅو په مراجعینو کې د شبکې سرچینو فعال استعمال سره ټکر ونلري. په لازمي ډول، هغه وخت ټاکل کیږي کله چې پیرودونکي فعال نه وي.
4. د ترکیب ترلاسه کولو وروسته، پیرودونکي په موازي ډول هر یو URL ته غوښتنې کوي. د هرې پتې غوښتنه تکرار کیدی شي - ورته ویل کیږي. "دالونه". په لومړي نبض کې، موږ اندازه کوو چې د اتصال رامینځته کولو او ډیټا ډاونلوډ کولو لپاره څومره وخت نیولی. په دوهم نبض کې، موږ هغه وخت اندازه کوو چې دا د دمخه رامینځته شوي اتصال څخه د ډیټا بارولو لپاره اخلي. د دریم څخه دمخه، موږ کولی شو ځنډ وټاکو او د بیا نښلولو سرعت اندازه کړو، او نور.

   د ازموینې په جریان کې، موږ ټول هغه پیرامیټونه اندازه کوو چې وسیله یې ترلاسه کولی شي:

   • د DNS غوښتنې وخت؛
   • د TCP پیوستون تنظیم کولو وخت؛
   • د TLS اتصال تنظیم کولو وخت؛
   • د معلوماتو د لومړي بایټ ترلاسه کولو وخت؛
   • د بارولو ټول وخت؛
   • د وضعیت پایلې کوډ.
5. وروسته له دې چې ټول دالونه بشپړ شي، نمونه د تحلیل لپاره ټولې اندازې باروي.

کلیدي ټکي د پیرودونکي په منطق باندې لږترلږه انحصار ، په سرور کې د معلوماتو پروسس کول او د موازي غوښتنو اندازه کول دي. په دې توګه، موږ د دې توان لرو چې د مختلفو فکتورونو اغیزې جلا او ازموینه وکړو چې د پوښتنې فعالیت اغیزه کوي، دوی په یو واحد ترکیب کې توپیر کوي، او د اصلي پیرودونکو څخه پایلې ترلاسه کوي.

دا زیربنا یوازې د پوښتنو فعالیت تحلیل څخه ډیر ګټور ثابت شوي. اوس مهال موږ 14 فعال ترکیبونه لرو، په هره ثانیه کې له 6000 څخه ډیر نمونې، د ځمکې له ټولو کونجونو څخه ډاټا ترلاسه کوو او د وسایلو بشپړ پوښښ. که Netflix ورته خدمت د دریمې ډلې څخه واخلي، نو دا به په کال کې میلیونونه ډالر مصرف کړي، د خورا خراب پوښښ سره.

په عمل کې د ازموینې تیوري: پروټوټایپ

د داسې سیسټم سره، موږ وکولی شو د غوښتنې ځنډولو په اړه د CDN پراکسي اغیزمنتوب ارزونه وکړو. اوس تاسو اړتیا لرئ:

• د پراکسي پروټوټایپ جوړ کړئ؛
• پروټوټایپ په CDN کې ځای په ځای کړئ؛
• معلوم کړئ چې څنګه مراجعین په ځانګړي CDN سرور کې پراکسي ته لارښود کړئ؛
• د پراکسي پرته په AWS کې غوښتنو سره فعالیت پرتله کړئ.

دنده دا ده چې ژر تر ژره د وړاندیز شوي حل اغیزمنتیا ارزونه وکړي. موږ د ښه شبکې کتابتونونو شتون له امله د پروټوټایپ پلي کولو لپاره Go غوره کړ. په هر CDN سرور کې، موږ د پروټوټایپ پراکسي د جامد بائنری په توګه نصب کړی ترڅو انحصار کم کړي او ادغام ساده کړي. په ابتدايي تطبیق کې، موږ د HTTP/2 پیوستون پولینګ لپاره د امکان تر حده معیاري اجزاوې او کوچني بدلونونه کارولي او د ملټي پلیکسینګ غوښتنه کوو.

د AWS سیمو ترمنځ توازن لپاره، موږ د جغرافیایي DNS ډیټابیس کارولی، ورته ورته د پیرودونکو توازن لپاره کارول کیږي. د پیرودونکي لپاره د CDN سرور غوره کولو لپاره، موږ په انټرنیټ ایکسچینج (IX) کې د سرورونو لپاره TCP Anycast کاروو. په دې اختیار کې، موږ د ټولو CDN سرورونو لپاره یو IP پته کاروو، او پیرودونکي به د لږ شمیر IP هپس سره د CDN سرور ته لارښوونه وکړي. د انټرنیټ چمتو کونکو (ISPs) لخوا نصب شوي CDN سرورونو کې ، موږ د TCP Anycast تنظیم کولو لپاره د روټر کنټرول نه لرو ، نو موږ یې کاروو ورته منطق، کوم چې پیرودونکي د ویډیو سټینګ لپاره انټرنیټ چمتو کونکو ته لارښوونه کوي.

نو، موږ د غوښتنې درې ډوله لارې لرو: بادل ته د خلاص انټرنیټ له لارې، په IX کې د CDN سرور له لارې، یا د CDN سرور له لارې چې د انټرنیټ چمتو کونکي کې موقعیت لري. زموږ هدف دا دی چې پوه شو چې کومه لاره غوره ده، او د پراکسي ګټه څه ده، په پرتله چې څنګه غوښتنې تولید ته لیږل کیږي. د دې کولو لپاره، موږ په لاندې ډول د نمونې سیسټم کاروو:

هره لاره یو جلا هدف کیږي، او موږ هغه وخت ګورو چې موږ یې ترلاسه کوو. د تحلیل لپاره، موږ د پراکسي پایلې په یوه ګروپ کې سره یوځای کوو (د IX او ISP پراکسي ترمنځ غوره وخت وټاکو)، او دوی د پراکسي پرته کلاوډ ته د غوښتنې وخت سره پرتله کوو:

لکه څنګه چې تاسو لیدلی شئ، پایلې ګډې وې - په ډیری قضیو کې پراکسي ښه سرعت ورکوي، مګر د پیرودونکو کافي شمیر هم شتون لري چې وضعیت به د پام وړ خراب شي.

د پایلې په توګه، موږ څو مهم کارونه ترسره کړل:

1. موږ د CDN پراکسي له لارې کلاوډ ته د پیرودونکو څخه د غوښتنو متوقع فعالیت ارزولی.
2. موږ د ریښتیني پیرودونکو څخه معلومات ترلاسه کړل ، د هر ډول وسیلو څخه.
3. موږ پوهیږو چې تیوري 100٪ تایید شوې نه وه او د CDN پراکسي سره لومړنی وړاندیز به زموږ لپاره کار ونکړي.
4. موږ خطرونه نه دي اخیستي - موږ د پیرودونکو لپاره د تولید تشکیلات نه دي بدل کړي.
5. هیڅ شی مات شوی نه و.

پروټوټایپ 2.0

نو، بیرته د انځور کولو بورډ ته لاړ شئ او پروسه بیا بیا تکرار کړئ.

نظر دا دی چې د 100٪ پراکسي کارولو پرځای ، موږ به د هر پیرودونکي لپاره ترټولو ګړندۍ لاره وټاکو ، او موږ به هلته غوښتنې واستوو - دا دی ، موږ به هغه څه وکړو چې د پیرودونکي سټیرینګ په نوم یادیږي.

دا څنګه پلي کول؟ موږ نشو کولی د سرور اړخ کې منطق وکاروو، ځکه چې ... موخه د دې سرور سره نښلول دي. په پیرودونکي کې د دې کولو لپاره باید یو څه لاره وي. او په مثالي توګه ، دا د لږترلږه پیچلي منطق سره ترسره کړئ ، ترڅو د ډیری پیرودونکي پلیټ فارمونو سره د ادغام مسله حل نشي.

ځواب د DNS کارولو لپاره دی. زموږ په قضیه کې، موږ خپل د DNS زیربنا لرو، او موږ کولی شو یو ډومین زون جوړ کړو چې زموږ سرورونه به واکمن وي. دا په دې ډول کار کوي:

1. پیرودونکي د کوربه په کارولو سره د DNS سرور ته غوښتنه کوي ، د مثال په توګه api.netflix.xom.
2. غوښتنه زموږ د DNS سرور ته راځي
3. د DNS سرور پوهیږي چې کومه لاره د دې پیرودونکي لپاره ترټولو ګړندۍ ده او ورته IP پته مسله کوي.

حل یو اضافي پیچلتیا لري: مستبد DNS چمتو کونکي د پیرودونکي IP پته نه ګوري او یوازې د تکراري حل کونکي IP پته لوستلی شي چې پیرودونکي یې کاروي.

د پایلې په توګه، زموږ استبدادي حل کوونکی باید پریکړه وکړي چې د انفرادي پیرودونکي لپاره نه وي، مګر د مراجعینو د یوې ډلې لپاره چې د تکرار حل کونکي پر بنسټ وي.

د حل کولو لپاره، موږ ورته نمونې کاروو، د هر یو تکراري حل کونکي لپاره د پیرودونکو څخه د اندازه کولو پایلې راټولوو او پریکړه کوو چې د دوی دا ګروپ چیرته واستوو - د IX له لارې یو پراکسي د TCP Anycast په کارولو سره، د ISP پراکسي له لارې، یا مستقیم بادل ته.

موږ لاندې سیسټم ترلاسه کوو:

د DNS سټیرینګ ماډل تاسو ته اجازه درکوي د پیرودونکو څخه بادل ته د پیرودونکو څخه د ارتباط سرعت د تاریخي مشاهدو پراساس پیرودونکي مستقیم کړئ.

یوځل بیا ، پوښتنه دا ده چې دا چلند به څومره مؤثره کار وکړي؟ د ځواب لپاره، موږ بیا زموږ د تحقیقاتو سیسټم کاروو. له همدې امله ، موږ د وړاندیز کونکي ترتیب تنظیم کوو ، چیرې چې یو هدف د DNS سټیرینګ لارښود تعقیبوي ، بل مستقیم بادل ته ځي (اوسني تولید).

د پایلې په توګه، موږ پایلې پرتله کوو او د اغیزمنتیا ارزونه ترلاسه کوو:

د پایلې په توګه، موږ څو مهم شیان زده کړل:

1. موږ د DNS سټیرینګ په کارولو سره کلاوډ ته د پیرودونکو څخه د غوښتنو متوقع فعالیت ارزولی.
2. موږ د ریښتیني پیرودونکو څخه معلومات ترلاسه کړل ، د هر ډول وسیلو څخه.
3. د وړاندیز شوي نظر اغیزمنتوب ثابت شوی.
4. موږ خطرونه نه دي اخیستي - موږ د پیرودونکو لپاره د تولید تشکیلات نه دي بدل کړي.
5. هیڅ شی مات شوی نه و.

اوس د ستونزمن برخې په اړه - موږ دا په تولید کې پیل کوو

اسانه برخه اوس پای ته رسیدلې - یو کاري پروټوټایپ شتون لري. اوس سخته برخه د Netflix د ټولو ټرافیک لپاره د حل په لاره اچول دي، د 150 ملیون کاروونکو، په زرګونو وسیلو، په سلګونو مایکرو خدماتو، او تل بدلیدونکي محصول او زیربنا ته ځای په ځای کول دي. د Netflix سرورونه په هره ثانیه کې ملیونونه غوښتنې ترلاسه کوي، او د بې پروا عمل سره د خدماتو ماتول اسانه دي. په ورته وخت کې، موږ غواړو په متحرک ډول په انټرنیټ کې د زرګونو CDN سرورونو له لارې ټرافيک وګرځوو، چیرې چې یو څه بدلیږي او په دوامداره توګه او په خورا نا مناسب وخت کې ماتیږي.

او د دې ټولو سره سره، ټیم 3 انجنیران لري چې د سیسټم پراختیا، ځای پرځای کولو او بشپړ ملاتړ مسولیت لري.

له همدې امله، موږ به د آرام او سالم خوب په اړه خبرو ته دوام ورکړو.

څنګه پرمختګ ته دوام ورکړئ او خپل ټول وخت په ملاتړ مصرف نه کړئ؟ زموږ چلند په دریو اصولو ولاړ دی:

1. موږ د تخریب احتمالي پیمانه کموو (د چاودنې وړانګې).
2. موږ د حیرانتیا لپاره چمتووالی نیسو - موږ تمه لرو چې یو څه به مات شي، د ازموینې او شخصي تجربې سره سره.
3. زړه راښکونکی تخریب - که یو څه سم کار ونه کړي، دا باید په اتوماتيک ډول تنظیم شي، حتی که په خورا اغیزمنه توګه نه وي.

دا معلومه شوه چې زموږ په قضیه کې، ستونزې ته د دې تګلارې سره، موږ کولی شو یو ساده او اغیزمن حل ومومو او د سیسټم ملاتړ د پام وړ ساده کړو. موږ پوهیږو چې موږ کولی شو پیرودونکي ته د کوډ یوه کوچنۍ برخه اضافه کړو او د شبکې غوښتنې غلطیتونو لپاره څارنه وکړو چې د ارتباط ستونزو له امله رامینځته شوي. د شبکې د تېروتنې په صورت کې، موږ په مستقیم ډول بادل ته بیرته ستنیږو. دا حل د مراجعینو ټیمونو لپاره د پام وړ هڅو ته اړتیا نلري، مګر زموږ لپاره د غیر متوقع ماتیدو او حیرانتیا خطر خورا کموي.

البته، د بیرته راګرځیدو سره سره، موږ بیا هم د پراختیا په جریان کې یو واضح نظم تعقیب کوو:

1. نمونه ازموینه.
2. د A/B ازموینه یا کانریز.
3. پرمختللی رول آوټ.

د نمونو سره، چلند تشریح شوی - بدلونونه لومړی د دودیز شوي ترکیب په کارولو سره ازمول شوي.

د کانري ازموینې لپاره ، موږ اړتیا لرو د پرتلې جوړې سرورونه ترلاسه کړو په کوم کې چې موږ کولی شو پرتله کړو چې سیسټم څنګه د بدلونونو دمخه او وروسته کار کوي. د دې کولو لپاره، زموږ د ډیری CDN سایټونو څخه، موږ د سرورونو جوړه غوره کوو چې د پرتلې وړ ترافیک ترلاسه کوي:

بیا موږ د کانري سرور کې د بدلونونو سره جوړونه نصب کوو. د پایلو ارزولو لپاره، موږ یو سیسټم چلوو چې نږدې 100-150 میټریکونه د کنټرول سرورونو نمونې سره پرتله کوي:

که د کانري ازموینه بریالۍ وي ، نو موږ یې په تدریجي ډول په څپو کې خوشې کوو. موږ په ورته وخت کې په هر سایټ کې سرورونه نه تازه کوو - د ستونزو له امله د ټول سایټ له لاسه ورکول په مختلف ځایونو کې د ورته شمیر سرورونو له لاسه ورکولو په پرتله د کاروونکو لپاره خدمت باندې خورا مهم اغیزه لري.

په عموم کې، د دې طریقې اغیزمنتوب او خوندیتوب د راټول شویو میترونو مقدار او کیفیت پورې اړه لري. زموږ د پوښتنې سرعت سیسټم لپاره، موږ د ټولو ممکنه برخو څخه میټریک راټولوو:

• د پیرودونکو څخه - د غونډو او غوښتنو شمیر، د بیرته راستنیدو نرخونه؛
• پراکسي - د غوښتنو شمیر او وخت په اړه احصایې؛
• DNS - شمیر او د غوښتنو پایلې؛
• د بادل څنډه - په بادل کې د غوښتنو پروسس کولو لپاره شمیره او وخت.

دا ټول په یو واحد پایپ لاین کې راټول شوي ، او د اړتیاو پراساس ، موږ پریکړه کوو چې کوم میټریکونه د ریښتیني وخت تحلیلونو ته واستوو ، او کوم د لا زیاتو توضیحاتو لپاره Elasticsearch یا Big Data ته.

موږ څارنه کوو

زموږ په قضیه کې، موږ د مراجعینو او سرور ترمنځ د غوښتنو په جدي لاره کې بدلونونه کوو. په ورته وخت کې، په پیرودونکي، سرور او د انټرنیټ له لارې د مختلفو برخو شمیر خورا لوی دی. په پیرودونکي او سرور کې بدلونونه په دوامداره توګه پیښیږي - د لسګونو ټیمونو د کار په جریان کې او په اکوسیستم کې طبیعي بدلونونه. موږ په مینځ کې یو - کله چې ستونزې تشخیص کوو، یو ښه چانس دی چې موږ به پکې ښکیل شو. له همدې امله، موږ باید په روښانه توګه پوه شو چې څنګه د ستونزو د چټک جلا کولو لپاره میټریکونه تعریف، راټول او تحلیل کړو.

په مثالي توګه، په ریښتیني وخت کې ټولو ډولونو میټریکونو او فلټرونو ته بشپړ لاسرسی. مګر ډیری میټریکونه شتون لري، نو د لګښت پوښتنه راپورته کیږي. زموږ په قضیه کې، موږ د میټریک او پراختیا وسیلې په لاندې ډول جلا کوو:

د ستونزو موندلو او محاکمه کولو لپاره موږ خپل د خلاصې سرچینې ریښتیني وخت سیسټم کاروو اطلس и لمن - د لید لپاره. دا په حافظه کې راټول شوي میټریکونه ذخیره کوي، د اعتبار وړ دي او د خبرتیا سیسټم سره مدغم کیږي. د ځایی کولو او تشخیص لپاره، موږ د Elasticsearch او Kibana څخه لاګونو ته لاسرسی لرو. د احصایې تحلیل او ماډلینګ لپاره، موږ په جدول کې لوی معلومات او لید کاروو.

داسې ښکاري چې دا طریقه د کار کولو لپاره خورا ستونزمنه ده. په هرصورت، د میټریکونو او وسایلو په ترتیب سره تنظیم کولو سره، موږ کولی شو په چټکۍ سره یوه ستونزه تحلیل کړو، د ستونزې ډول وټاکو، او بیا په تفصیلي میټریکونو کې ډرل کړو. په عموم کې، موږ شاوخوا 1-2 دقیقې مصرف کوو ترڅو د ماتیدو سرچینه وپیژنو. له دې وروسته، موږ د یو ځانګړي ټیم سره د تشخیص په اړه کار کوو - له لسګونو دقیقو څخه څو ساعتونو پورې.

حتی که تشخیص په چټکۍ سره ترسره شي، موږ نه غواړو چې دا ډیری وختونه پیښ شي. په عین حال کې، موږ به یوازې یو مهم خبرتیا ترلاسه کړو کله چې په خدمت کې د پام وړ اغیزه وي. زموږ د پوښتنې سرعت سیسټم لپاره، موږ یوازې 2 خبرتیاوې لرو چې خبرتیا ورکوي:

• د پیرودونکي فال بیک سلنه - د پیرودونکي چلند ارزونه؛
• سلنه د تحقیقاتو غلطۍ - د شبکې اجزاو ثبات ډیټا.

دا مهم خبرتیاوې څارنه کوي چې ایا سیسټم د ډیری کاروونکو لپاره کار کوي. موږ ګورو چې څومره پیرودونکي فال بیک کارولی که دوی د غوښتنې سرعت ترلاسه کولو توان ونلري. موږ په اوسط ډول په هره اونۍ کې له 1 مهم خبرتیا څخه کم یو، که څه هم په سیسټم کې یو ټن بدلونونه روان دي. ولې دا زموږ لپاره کافي ده؟

1. که زموږ پراکسي کار ونکړي نو د پیرودونکي فال بیک شتون لري.
2. یو اتوماتیک سټیرینګ سیسټم شتون لري چې ستونزو ته ځواب ووایی.

د وروستي په اړه نور جزئیات. زموږ د محاکمې سیسټم، او سیسټم په اتوماتيک ډول د پیرودونکي څخه بادل ته د غوښتنو لپاره غوره لاره ټاکلو لپاره، موږ ته اجازه راکوي چې په اتوماتيک ډول د ځینو ستونزو سره مقابله وکړو.

راځئ چې زموږ د نمونې ترتیب او د 3 لارې کټګوریو ته راستون شو. د بار کولو وخت سربیره ، موږ کولی شو پخپله د تحویل حقیقت وګورو. که دا ممکنه نه وه چې ډیټا پورته کړئ، نو بیا د مختلفو لارو په اوږدو کې د پایلو په لیدلو سره موږ کولی شو معلومه کړو چې چیرته او څه مات شوي، او ایا موږ کولی شو د غوښتنې لارې بدلولو سره په اتوماتيک ډول حل کړو.

مثالونه:

دا پروسه په اتوماتيک ډول ترسره کیدی شي. دا په سټیرینګ سیسټم کې شامل کړئ. او دا د فعالیت او اعتبار ستونزو ته د ځواب ویلو لپاره درس ورکړئ. که یو څه مات شي، عکس العمل وکړئ که چیرې غوره اختیار شتون ولري. په ورته وخت کې، سمدستي غبرګون مهم نه دی، د پیرودونکو د بیرته راګرځیدو څخه مننه.

په دې توګه، د سیسټم ملاتړ اصول په لاندې ډول ترتیب کیدی شي:

• د ماتیدو اندازه کمول؛
• د میترونو راټولول
• موږ په اوتومات ډول ماتونه ترمیم کوو که موږ کولی شو؛
• که دا نشي کولی، موږ تاسو ته خبر ورکوو؛
• موږ د چټک غبرګون لپاره په ډشبورډونو او ټریج وسیلې کار کوو.

درسونه زده کړل

د پروټوټایپ لیکلو لپاره ډیر وخت نه نیسي. زموږ په قضیه کې، دا د 4 میاشتو وروسته چمتو شوی و. د دې سره موږ نوي میټریکونه ترلاسه کړل، او د پراختیا له پیل څخه 10 میاشتې وروسته موږ د تولید لومړی ټرافیک ترلاسه کړ. بیا ستړي او خورا ستونزمن کار پیل شو: په تدریجي ډول تولید او سیسټم اندازه کول، اصلي ټرافیک ته لیږدول او له غلطیو څخه زده کړه. په هرصورت، دا اغیزمنه پروسه به خطي نه وي - د ټولو هڅو سره سره، د هرڅه وړاندوینه نشي کیدی. دا خورا اغیزمنه ده چې ژر تر ژره تکرار او نوي معلوماتو ته ځواب ووایی.

زموږ د تجربې پراساس، موږ کولی شو لاندې سپارښتنې وکړو:

1. په خپل وجدان باور مه کوئ.

   زموږ د ټیم غړو د پراخې تجربې سره سره، زموږ پوهاوی موږ په دوامداره توګه ناکام شو. د مثال په توګه، موږ د CDN پراکسي کارولو څخه د متوقع سرعت، یا د TCP Anycast چلند په غلط ډول وړاندوینه کړې.

2. د تولید څخه ډاټا ترلاسه کړئ.

   دا مهمه ده چې ژر تر ژره لږترلږه د تولید ډیټا ته لاسرسی ومومئ. د لابراتوار شرایطو کې د ځانګړو قضیو ، تشکیلاتو او تنظیماتو شمیر ترلاسه کول نږدې ناممکن دي. پایلو ته ګړندي لاسرسی به تاسو ته اجازه درکړي ژر تر ژره د احتمالي ستونزو په اړه زده کړئ او د سیسټم جوړښت کې یې په پام کې ونیسئ.

3. د نورو خلکو مشورې او پایلې مه تعقیبوئ - خپل معلومات راټول کړئ.

   د معلوماتو راټولولو او تحلیل کولو اصول تعقیب کړئ، مګر د نورو خلکو پایلې او څرګندونې په پټه توګه مه منو. یوازې تاسو کولی شئ په سمه توګه پوه شئ چې ستاسو د کاروونکو لپاره څه کار کوي. ستاسو سیسټمونه او ستاسو پیرودونکي ممکن د نورو شرکتونو څخه د پام وړ توپیر ولري. خوشبختانه، د تحلیل وسیلې اوس شتون لري او کارول یې اسانه دي. هغه پایلې چې تاسو یې ترلاسه کوئ ممکن هغه څه نه وي چې Netflix، فیسبوک، اکامي او نور شرکتونه ادعا کوي. زموږ په قضیه کې، د DNS غوښتنو په اړه د TLS، HTTP2 یا احصایې فعالیت د فیسبوک، Uber، Akamai پایلو څخه توپیر لري - ځکه چې موږ مختلف وسایل، پیرودونکي او د معلوماتو جریان لرو.

4. په غیر ضروري توګه د فیشن رجحانات تعقیب مه کوئ او د اغیزمنتیا ارزونه وکړئ.

   ساده پیل کړئ. دا غوره ده چې په لنډ وخت کې یو ساده کاري سیسټم رامینځته کړئ د دې په پرتله چې تاسو اړتیا نلرئ د اجزاو رامینځته کولو ډیر وخت مصرف کړئ. هغه دندې او ستونزې حل کړئ چې ستاسو د اندازه کولو او پایلو پراساس مهم دي.

5. د نوي غوښتنلیکونو لپاره چمتو اوسئ.

   لکه څنګه چې د ټولو ستونزو وړاندوینه ستونزمنه ده، دا ستونزمنه ده چې مخکې له مخکې د ګټو او غوښتنلیکونو وړاندوینه وکړئ. د پیل څخه یو اشاره واخلئ - د پیرودونکو شرایطو سره د موافقت کولو وړتیا. ستاسو په قضیه کې، تاسو ممکن نوې ستونزې او د هغوی حلونه ومومئ. زموږ په پروژه کې، موږ د غوښتنې ځنډ کمولو لپاره هدف ټاکلی. په هرصورت، د تحلیل او بحثونو په جریان کې، موږ پوهیږو چې موږ کولی شو پراکسي سرورونه هم وکاروو:

   • په AWS سیمو کې د ترافیک توازن او لګښتونه کمول؛
   • د CDN ثبات ماډل کول؛
   • د DNS تنظیم کول؛
   • د TLS/TCP تنظیم کولو لپاره.

پایلې

په راپور کې، ما تشریح کړه چې څنګه Netflix د پیرودونکو او بادل ترمنځ د انټرنیټ غوښتنو ګړندي کولو ستونزه حل کوي. موږ څنګه په پیرودونکو کې د نمونې ورکولو سیسټم په کارولو سره ډاټا راټولوو، او د انټرنېټ ترټولو ګړندۍ لارې له لارې د پیرودونکو څخه د تولید غوښتنې الرښوونې لپاره راټول شوي تاریخي ډاټا کاروو. موږ څنګه د دې دندې د لاسته راوړلو لپاره د شبکې پروتوکولونو اصول، زموږ د CDN زیربنا، د بیکبون شبکه، او DNS سرورونه کاروو.

په هرصورت، زموږ حل یوازې یو مثال دی چې څنګه موږ په Netflix کې دا ډول سیسټم پلي کړ. زموږ لپاره څه کار وکړ. ستاسو لپاره زما د راپور پلي شوې برخه د پراختیا او ملاتړ اصول دي چې موږ یې تعقیب کوو او ښې پایلې ترلاسه کوو.

زموږ د ستونزې حل ممکن ستاسو لپاره مناسب نه وي. په هرصورت، تیوري او ډیزاین اصول پاتې دي، حتی که تاسو خپل CDN زیربنا نلرئ، یا که دا زموږ څخه د پام وړ توپیر ولري.

د سوداګریزو غوښتنو د سرعت اهمیت هم مهم پاتې دی. او حتی د ساده خدمت لپاره تاسو اړتیا لرئ یو انتخاب وکړئ: د کلاوډ چمتو کونکو ، سرور موقعیت ، CDN او DNS چمتو کونکو ترمینځ. ستاسو انتخاب به ستاسو د پیرودونکو لپاره د انټرنیټ پوښتنو اغیزې اغیزه وکړي. او دا ستاسو لپاره مهمه ده چې دا تاثیر اندازه کړئ او پوه شئ.

د ساده حلونو سره پیل کړئ، د دې په اړه پاملرنه وکړئ چې تاسو څنګه محصول بدل کړئ. لکه څنګه چې تاسو لاړ شئ زده کړئ او ستاسو د پیرودونکو، ستاسو زیربنا، او ستاسو سوداګرۍ څخه د معلوماتو پراساس سیسټم ته وده ورکړئ. د ډیزاین پروسې په جریان کې د غیر متوقع ماتیدو احتمال په اړه فکر وکړئ. او بیا تاسو کولی شئ خپل پرمختیایي پروسه ګړندۍ کړئ، د حل موثریت ته وده ورکړئ، د غیر ضروري مالتړ بار څخه مخنیوی وکړئ او په آرامۍ سره خوب وکړئ.

سږ کال کنفرانس به د جولای له 6 څخه تر 10 پورې ترسره شي په آنلاین بڼه. تاسو کولی شئ د DevOps پلرونو څخه یو ته پوښتنې وکړئ ، جان ویلیس پخپله!

سرچینه: www.habr.com