سرعت درخواست های اینترنت را افزایش دهید و با آرامش بخوابید

نتفلیکس رهبر بازار تلویزیون اینترنتی است - شرکتی که این بخش را ایجاد کرده و به طور فعال در حال توسعه است. نتفلیکس نه تنها به دلیل کاتالوگ گسترده فیلم ها و سریال های تلویزیونی که تقریباً از هر گوشه کره زمین و هر دستگاهی با نمایشگر در دسترس است، بلکه به دلیل زیرساخت های قابل اعتماد و فرهنگ مهندسی منحصر به فردش شناخته شده است.

نمونه واضحی از رویکرد Netflix برای توسعه و پشتیبانی از سیستم‌های پیچیده در DevOops 2019 ارائه شد. سرگئی فدوروف - مدیر توسعه در نتفلیکس. فارغ التحصیل دانشکده ریاضیات محاسباتی و ریاضیات دانشگاه دولتی نیژنی نووگورود. لوباچفسکی، سرگئی یکی از اولین مهندسان در Open Connect - تیم CDN در نتفلیکس. او سیستم‌هایی برای نظارت و تجزیه و تحلیل داده‌های ویدیویی ساخت، یک سرویس محبوب برای ارزیابی سرعت اتصال به اینترنت FAST.com راه‌اندازی کرد و در چند سال اخیر روی بهینه‌سازی درخواست‌های اینترنتی کار کرده است تا برنامه نتفلیکس در سریع‌ترین زمان ممکن برای کاربران کار کند.

این گزارش بهترین نقدها را از شرکت کنندگان کنفرانس دریافت کرد و ما نسخه متنی آن را برای شما آماده کرده ایم.

سرگئی در گزارش خود به تفصیل صحبت کرد

• در مورد اینکه چه چیزی بر تاخیر درخواست های اینترنتی بین مشتری و سرور تاثیر می گذارد.
• نحوه کاهش این تاخیر
• نحوه طراحی، نگهداری و نظارت بر سیستم های مقاوم به خطا؛
• چگونه می توان در زمان کوتاه و با حداقل خطر برای کسب و کار به نتایج دست یافت.
• چگونه نتایج را تجزیه و تحلیل کنیم و از اشتباهات درس بگیریم.

پاسخ به این سوالات نه تنها برای کسانی که در شرکت های بزرگ کار می کنند مورد نیاز است.

اصول و تکنیک های ارائه شده باید توسط همه کسانی که محصولات اینترنتی را توسعه و پشتیبانی می کنند، شناخته و اجرا کنند.

بعد روایت از منظر گوینده است.

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

سرعت درخواست های اینترنتی ارتباط مستقیمی با کسب و کار دارد. صنعت خرید را در نظر بگیرید: آمازون در سال 2009 صحبت کردکه یک تاخیر 100 میلی‌ثانیه منجر به از دست دادن 1 درصد از فروش می‌شود.

دستگاه های تلفن همراه بیشتر و بیشتر هستند و به دنبال آن سایت ها و برنامه های موبایل قرار دارند. اگر بارگذاری صفحه شما بیش از 3 ثانیه طول بکشد، تقریباً نیمی از کاربران خود را از دست داده اید. با جولای 2018 گوگل سرعت بارگذاری صفحه شما را در نتایج جستجو در نظر می گیرد: هر چه صفحه سریعتر باشد، موقعیت آن در گوگل بالاتر می رود.

سرعت اتصال در مؤسسات مالی که تأخیر حیاتی است نیز مهم است. در سال 2015 شبکه هایبرنیا تمام شده یک کابل 400 میلیون دلاری بین نیویورک و لندن برای کاهش تاخیر بین شهرها تا 6 میلی ثانیه. 66 میلیون دلار را برای 1 میلی ثانیه کاهش تاخیر تصور کنید!

طبق تحقیق، سرعت اتصال بالای 5 مگابیت بر ثانیه دیگر مستقیماً بر سرعت بارگذاری یک وب سایت معمولی تأثیر نمی گذارد. با این حال، یک رابطه خطی بین تاخیر اتصال و سرعت بارگذاری صفحه وجود دارد:

با این حال، نتفلیکس یک محصول معمولی نیست. تأثیر تأخیر و سرعت بر روی کاربر یک حوزه فعال تجزیه و تحلیل و توسعه است. بارگذاری برنامه و انتخاب محتوا وجود دارد که به تأخیر بستگی دارد، اما بارگیری عناصر استاتیک و جریان نیز به سرعت اتصال بستگی دارد. تجزیه و تحلیل و بهینه سازی عوامل کلیدی که بر تجربه کاربر تأثیر می گذارند، یک منطقه فعال توسعه برای چندین تیم در نتفلیکس است. یکی از اهداف کاهش تأخیر درخواست‌ها بین دستگاه‌های Netflix و زیرساخت ابری است.

در این گزارش به طور خاص بر روی کاهش تاخیر با استفاده از مثال زیرساخت نتفلیکس تمرکز خواهیم کرد. بیایید از منظر عملی نحوه رویکرد به فرآیندهای طراحی، توسعه و بهره برداری از سیستم های پیچیده توزیع شده را در نظر بگیریم و به جای تشخیص مشکلات و خرابی های عملیاتی، زمان صرف نوآوری و نتایج کنیم.

داخل نتفلیکس

هزاران دستگاه مختلف از برنامه های Netflix پشتیبانی می کنند. آنها توسط چهار تیم مختلف توسعه یافته اند که نسخه های جداگانه ای از مشتری را برای اندروید، iOS، تلویزیون و مرورگرهای وب می سازند. و ما تلاش زیادی را صرف بهبود و شخصی سازی تجربه کاربر می کنیم. برای این کار صدها تست A/B را به صورت موازی اجرا می کنیم.

شخصی‌سازی توسط صدها میکروسرویس در ابر AWS پشتیبانی می‌شود که داده‌های شخصی‌سازی شده کاربر، ارسال پرس و جو، تله متری، داده‌های بزرگ و رمزگذاری را ارائه می‌دهد. تجسم ترافیک به صورت زیر است:

پیوند به ویدیو با نمایش (6:04-6:23)

در سمت چپ نقطه ورود است، و سپس ترافیک بین چند صد میکروسرویس که توسط تیم‌های مختلف پشتیبانی می‌شوند، توزیع می‌شود.

یکی دیگر از اجزای مهم زیرساخت ما Open Connect CDN است که محتوای ثابت را به کاربر نهایی ارائه می دهد - فیلم ها، تصاویر، کد مشتری و غیره. CDN روی سرورهای سفارشی (OCA - Open Connect Appliance) قرار دارد. در داخل آرایه‌هایی از درایوهای SSD و HDD وجود دارد که FreeBSD بهینه‌سازی شده، با NGINX و مجموعه‌ای از خدمات را اجرا می‌کنند. ما قطعات سخت افزاری و نرم افزاری را طراحی و بهینه می کنیم تا چنین سرور CDN بتواند تا حد امکان داده ها را برای کاربران ارسال کند.

"دیوار" این سرورها در نقطه تبادل ترافیک اینترنت (Internet eXchange - IX) به شکل زیر است:

Internet Exchange این امکان را برای ارائه دهندگان خدمات اینترنت و ارائه دهندگان محتوا فراهم می کند تا با یکدیگر "ارتباط" داشته باشند تا مستقیماً داده ها را در اینترنت تبادل کنند. تقریباً 70 تا 80 نقطه تبادل اینترنت در سراسر جهان وجود دارد که سرورهای ما در آنها نصب شده اند و ما به طور مستقل آنها را نصب و نگهداری می کنیم:

علاوه بر این، ما همچنین سرورهایی را مستقیماً به ارائه دهندگان اینترنت ارائه می دهیم که آنها در شبکه خود نصب می کنند و محلی سازی ترافیک Netflix و کیفیت پخش را برای کاربران بهبود می بخشد:

مجموعه ای از خدمات AWS وظیفه ارسال درخواست های ویدیویی از مشتریان به سرورهای CDN و همچنین پیکربندی خود سرورها - به روز رسانی محتوا، کد برنامه، تنظیمات و غیره را بر عهده دارد. برای دومی، ما همچنین یک شبکه ستون فقرات ایجاد کردیم که سرورها را در نقاط تبادل اینترنت با AWS متصل می‌کند. شبکه ستون فقرات یک شبکه جهانی از کابل ها و مسیریاب های فیبر نوری است که می توانیم بر اساس نیاز خود طراحی و پیکربندی کنیم.

بر برآورد Sandvine، زیرساخت CDN ما تقریباً ⅛ از ترافیک اینترنت جهان را در ساعات اوج مصرف و ⅓ از ترافیک را در آمریکای شمالی ارائه می دهد، جایی که Netflix تقریباً طولانی ترین بوده است. اعداد قابل توجه، اما برای من یکی از شگفت انگیزترین دستاوردها این است که کل سیستم CDN توسط تیمی کمتر از 150 نفر توسعه و نگهداری می شود.

در ابتدا، زیرساخت CDN برای ارائه داده های ویدئویی طراحی شد. با این حال، با گذشت زمان متوجه شدیم که می توانیم از آن برای بهینه سازی درخواست های پویا از مشتریان در ابر AWS نیز استفاده کنیم.

درباره شتاب اینترنت

امروزه، نتفلیکس دارای 3 منطقه AWS است و تأخیر درخواست ها به ابر بستگی به فاصله مشتری از نزدیک ترین منطقه دارد. در عین حال، ما سرورهای CDN زیادی داریم که برای ارائه محتوای ثابت استفاده می شوند. آیا راهی برای استفاده از این چارچوب برای سرعت بخشیدن به پرس و جوهای پویا وجود دارد؟ با این حال، متأسفانه، ذخیره کردن این درخواست ها غیرممکن است - API ها شخصی هستند و هر نتیجه منحصر به فرد است.

بیایید یک پروکسی در سرور CDN ایجاد کنیم و شروع به ارسال ترافیک از طریق آن کنیم. سریعتر میشه؟

ماده

بیایید به یاد بیاوریم که پروتکل های شبکه چگونه کار می کنند. امروزه بیشتر ترافیک اینترنت از HTTP استفاده می کند که به پروتکل های لایه پایین تر TCP و TLS بستگی دارد. برای اینکه کلاینت به سرور وصل شود، دست دادن انجام می دهد و برای برقراری ارتباط ایمن، کلاینت باید سه بار و حداقل یک بار دیگر برای انتقال داده با سرور پیام رد و بدل کند. با تأخیر در هر رفت و برگشت (RTT) 100 میلی ثانیه، دریافت اولین بیت داده به 400 میلی ثانیه زمان نیاز دارد:

اگر گواهی‌ها را روی سرور CDN قرار دهیم، در صورت نزدیک‌تر شدن CDN، زمان دست دادن بین مشتری و سرور می‌تواند به میزان قابل توجهی کاهش یابد. فرض کنید تاخیر سرور CDN 30 میلی ثانیه است. سپس 220 میلی ثانیه طول می کشد تا اولین بیت را دریافت کنید:

اما مزایا به همین جا ختم نمی شود. هنگامی که یک اتصال برقرار شد، TCP پنجره ازدحام را افزایش می دهد (مقدار اطلاعاتی که می تواند از طریق آن اتصال به صورت موازی ارسال کند). اگر یک بسته داده گم شود، پیاده سازی های کلاسیک پروتکل TCP (مانند TCP New Reno) پنجره باز را به نصف کاهش می دهد. رشد پنجره تراکم، و سرعت بازیابی آن از ضرر دوباره به تاخیر (RTT) به سرور بستگی دارد. اگر این اتصال فقط تا سرور CDN پیش برود، این بازیابی سریعتر خواهد بود. در عین حال، از دست دادن بسته یک پدیده استاندارد است، به ویژه برای شبکه های بی سیم.

پهنای باند اینترنت به خصوص در ساعات اوج مصرف ممکن است به دلیل ترافیک کاربران کاهش یابد که می تواند منجر به ترافیک شود. با این حال، هیچ راهی در اینترنت برای اولویت دادن به برخی از درخواست ها بر برخی دیگر وجود ندارد. به عنوان مثال، به درخواست‌های کوچک و حساس به تأخیر نسبت به جریان‌های داده «سنگین» که شبکه را بارگذاری می‌کنند، اولویت بدهید. با این حال، در مورد ما، داشتن شبکه ستون فقرات خود به ما این امکان را می دهد که این کار را در بخشی از مسیر درخواست - بین CDN و ابر انجام دهیم، و ما می توانیم آن را به طور کامل پیکربندی کنیم. می‌توانید مطمئن شوید که بسته‌های کوچک و حساس به تأخیر اولویت‌بندی می‌شوند و جریان‌های داده بزرگ کمی دیرتر می‌روند. هر چه CDN به مشتری نزدیکتر باشد، کارایی بیشتری دارد.

پروتکل های سطح برنامه (OSI Level 7) نیز بر تأخیر تأثیر دارند. پروتکل های جدید مانند HTTP/2 عملکرد درخواست های موازی را بهینه می کند. با این حال، ما مشتریان Netflix با دستگاه های قدیمی تر داریم که از پروتکل های جدید پشتیبانی نمی کنند. همه کلاینت ها را نمی توان به روز کرد یا به طور بهینه پیکربندی کرد. در عین حال، بین پروکسی CDN و ابر کنترل کامل و امکان استفاده از پروتکل ها و تنظیمات جدید و بهینه وجود دارد. بخش ناکارآمد با پروتکل های قدیمی فقط بین مشتری و سرور CDN کار می کند. علاوه بر این، ما می‌توانیم درخواست‌های مالتی پلکس را روی یک اتصال از قبل ایجاد شده بین CDN و ابر انجام دهیم و استفاده از اتصال را در سطح TCP بهبود دهیم:

اندازه می گیریم

با وجود این واقعیت که این تئوری نوید بهبود را می دهد، ما بلافاصله برای راه اندازی سیستم در تولید عجله نمی کنیم. در عوض، ابتدا باید ثابت کنیم که این ایده در عمل جواب می دهد. برای این کار باید به چند سوال پاسخ دهید:

• سرعت: آیا پروکسی سریعتر خواهد بود؟
• قابلیت اطمینان: آیا بیشتر می شکند؟
• پیچیدگی: چگونه با برنامه ها یکپارچه شویم؟
• هزینه: هزینه استقرار زیرساخت های اضافی چقدر است؟

اجازه دهید رویکرد خود را برای ارزیابی اولین نکته به تفصیل بررسی کنیم. با بقیه به روشی مشابه برخورد می شود.

برای تجزیه و تحلیل سرعت درخواست ها، ما می خواهیم بدون صرف زمان زیادی برای توسعه و بدون شکستن تولید، داده هایی را برای همه کاربران به دست آوریم. چندین رویکرد برای این وجود دارد:

1. RUM یا اندازه‌گیری غیرفعال درخواست. ما زمان اجرای درخواست‌های فعلی کاربران را اندازه‌گیری می‌کنیم و از پوشش کامل کاربر اطمینان می‌دهیم. نقطه ضعف آن این است که سیگنال به دلیل بسیاری از عوامل، به عنوان مثال، به دلیل اندازه های مختلف درخواست، زمان پردازش روی سرور و مشتری، بسیار پایدار نیست. علاوه بر این، نمی‌توانید پیکربندی جدید را بدون تأثیر در تولید آزمایش کنید.
2. تست های آزمایشگاهی. سرورها و زیرساخت های ویژه ای که مشتریان را شبیه سازی می کند. با کمک آنها آزمایشات لازم را انجام می دهیم. به این ترتیب ما کنترل کاملی بر نتایج اندازه گیری و یک سیگنال واضح دریافت می کنیم. اما هیچ پوشش کاملی از دستگاه ها و مکان های کاربر وجود ندارد (به ویژه با خدمات جهانی و پشتیبانی از هزاران مدل دستگاه).

چگونه می توانید مزایای هر دو روش را ترکیب کنید؟

تیم ما راه حلی پیدا کرده است. ما یک کد کوچک - یک نمونه - نوشتیم که آن را در برنامه خود قرار دادیم. کاوشگرها به ما این امکان را می دهند که آزمایش های شبکه کاملاً کنترل شده را از دستگاه های خود انجام دهیم. اینطوری کار میکنه:

1. مدت کوتاهی پس از بارگذاری برنامه و تکمیل فعالیت اولیه، پروب های خود را اجرا می کنیم.
2. کلاینت درخواستی از سرور می کند و "دستور العمل" آزمایش را دریافت می کند. دستور العمل فهرستی از URLهایی است که درخواست HTTP باید به آنها ارسال شود. علاوه بر این، دستور العمل پارامترهای درخواست را پیکربندی می کند: تاخیر بین درخواست ها، مقدار داده های درخواستی، هدرهای HTTP و غیره. در همان زمان، می‌توانیم چندین دستور غذای مختلف را به صورت موازی آزمایش کنیم - هنگام درخواست پیکربندی، به‌طور تصادفی تعیین می‌کنیم که کدام دستور غذا را صادر کنیم.
3. زمان راه‌اندازی کاوشگر به گونه‌ای انتخاب می‌شود که با استفاده فعال از منابع شبکه در مشتری تضاد نداشته باشد. اساساً زمانی انتخاب می شود که مشتری فعال نباشد.
4. پس از دریافت دستور، مشتری به طور موازی درخواست هایی را برای هر یک از URL ها ارسال می کند. درخواست به هر یک از آدرس ها را می توان تکرار کرد - به اصطلاح. "نبض ها". در اولین پالس، مدت زمان برقراری اتصال و دانلود داده ها را اندازه می گیریم. در پالس دوم، زمان بارگذاری داده ها را روی یک اتصال از قبل ایجاد شده اندازه گیری می کنیم. قبل از سومی، می‌توانیم یک تاخیر تنظیم کنیم و سرعت برقراری اتصال مجدد و غیره را اندازه‌گیری کنیم.

   در طول آزمایش، ما تمام پارامترهایی را که دستگاه می تواند بدست آورد اندازه گیری می کنیم:

   • زمان درخواست DNS؛
   • زمان راه اندازی اتصال TCP؛
   • زمان راه اندازی اتصال TLS؛
   • زمان دریافت اولین بایت داده؛
   • کل زمان بارگذاری؛
   • کد نتیجه وضعیت
5. پس از اتمام تمام پالس ها، نمونه تمام اندازه گیری ها را برای تجزیه و تحلیل بارگذاری می کند.

نکات کلیدی حداقل وابستگی به منطق به مشتری، پردازش داده ها در سرور و اندازه گیری درخواست های موازی است. بنابراین، ما می‌توانیم تأثیر عوامل مختلف مؤثر بر عملکرد پرس‌وجو را جدا کرده و آزمایش کنیم، آنها را در یک دستورالعمل واحد تغییر دهیم و نتایجی را از مشتریان واقعی به‌دست آوریم.

این زیرساخت برای بیش از تجزیه و تحلیل عملکرد پرس و جو مفید است. در حال حاضر 14 دستور غذای فعال، بیش از 6000 نمونه در ثانیه، دریافت داده ها از تمام گوشه های زمین و پوشش کامل دستگاه داریم. اگر نتفلیکس سرویس مشابهی را از شخص ثالث خریداری می کرد، سالانه میلیون ها دلار هزینه داشت و پوشش بسیار بدتری داشت.

آزمایش تئوری در عمل: نمونه اولیه

با چنین سیستمی، ما توانستیم اثربخشی پروکسی های CDN را در تأخیر درخواست ارزیابی کنیم. حالا شما نیاز دارید:

• ایجاد یک نمونه اولیه پروکسی؛
• نمونه اولیه را روی CDN قرار دهید.
• تعیین نحوه هدایت مشتریان به پروکسی در یک سرور CDN خاص.
• عملکرد را با درخواست‌های AWS بدون پروکسی مقایسه کنید.

وظیفه ارزیابی اثربخشی راه حل پیشنهادی در سریع ترین زمان ممکن است. به دلیل در دسترس بودن کتابخانه های شبکه خوب، Go را برای پیاده سازی نمونه اولیه انتخاب کردیم. در هر سرور CDN، ما پروکسی نمونه اولیه را به عنوان یک باینری ثابت نصب کردیم تا وابستگی ها را به حداقل برسانیم و یکپارچگی را ساده کنیم. در پیاده سازی اولیه، تا حد امکان از اجزای استاندارد و تغییرات جزئی برای ادغام اتصال HTTP/2 و مالتی پلکس شدن درخواست استفاده کردیم.

برای ایجاد تعادل بین مناطق AWS، ما از یک پایگاه داده جغرافیایی DNS استفاده کردیم، همان پایگاه داده ای که برای متعادل کردن مشتریان استفاده می شود. برای انتخاب یک سرور CDN برای مشتری، از TCP Anycast برای سرورهای اینترنت اکسچنج (IX) استفاده می کنیم. در این گزینه برای تمام سرورهای CDN از یک آدرس IP استفاده می کنیم و کلاینت با کمترین تعداد IP hop به سرور CDN هدایت می شود. در سرورهای CDN نصب شده توسط ارائه دهندگان اینترنت (ISP)، ما کنترلی بر روتر برای پیکربندی TCP Anycast نداریم، بنابراین از همان منطق، که مشتریان را برای پخش ویدئو به ارائه دهندگان اینترنت هدایت می کند.

بنابراین، ما سه نوع مسیر درخواست داریم: به ابر از طریق اینترنت باز، از طریق یک سرور CDN در IX، یا از طریق یک سرور CDN واقع در یک ارائه دهنده اینترنت. هدف ما این است که بفهمیم کدام راه بهتر است و مزایای پروکسی در مقایسه با نحوه ارسال درخواست ها به تولید چیست. برای این کار از سیستم نمونه گیری به صورت زیر استفاده می کنیم:

هر یک از مسیرها به یک هدف جداگانه تبدیل می شوند و ما به زمانی که به دست آورده ایم نگاه می کنیم. برای تجزیه و تحلیل، ما نتایج پراکسی را در یک گروه ترکیب می کنیم (بهترین زمان را بین پراکسی های IX و ISP انتخاب می کنیم)، و آنها را با زمان درخواست ها به ابر بدون پراکسی مقایسه می کنیم:

همانطور که می بینید، نتایج متفاوت بود - در بیشتر موارد پروکسی سرعت خوبی را ارائه می دهد، اما تعداد کافی مشتری نیز وجود دارد که وضعیت برای آنها به طور قابل توجهی بدتر می شود.

در نتیجه چندین کار مهم انجام دادیم:

1. ما عملکرد مورد انتظار درخواست‌های مشتریان به ابر را از طریق یک پروکسی CDN ارزیابی کردیم.
2. ما داده ها را از مشتریان واقعی، از انواع دستگاه ها دریافت کردیم.
3. ما متوجه شدیم که این تئوری 100٪ تایید نشده است و پیشنهاد اولیه با یک پروکسی CDN برای ما کار نخواهد کرد.
4. ما ریسک نکردیم - تنظیمات تولید را برای مشتریان تغییر ندادیم.
5. هیچ چیز خراب نشد.

نمونه اولیه 2.0

بنابراین، به تخته طراحی برگردید و روند را دوباره تکرار کنید.

ایده این است که به جای استفاده از یک پروکسی 100٪، ما سریع ترین مسیر را برای هر مشتری تعیین می کنیم و درخواست ها را به آنجا ارسال می کنیم - یعنی کاری را انجام می دهیم که به آن هدایت مشتری می گویند.

چگونه این را پیاده سازی کنیم؟ ما نمی توانیم از منطق در سمت سرور استفاده کنیم، زیرا ... هدف اتصال به این سرور است. باید راهی برای انجام این کار روی مشتری وجود داشته باشد. و در حالت ایده آل، این کار را با حداقل منطق پیچیده انجام دهید تا مشکل ادغام با تعداد زیادی از پلتفرم های مشتری حل نشود.

جواب استفاده از DNS است. در مورد ما، ما زیرساخت DNS خود را داریم و می‌توانیم یک ناحیه دامنه ایجاد کنیم که سرورهای ما برای آن اقتدارگرا باشند. اینطوری کار میکنه:

1. کلاینت با استفاده از یک میزبان، برای مثال api.netflix.xom، درخواستی را به سرور DNS ارسال می کند.
2. درخواست به سرور DNS ما می رسد
3. سرور DNS می داند کدام مسیر برای این کلاینت سریعتر است و آدرس IP مربوطه را صادر می کند.

راه حل دارای پیچیدگی اضافی است: ارائه دهندگان DNS مستبد آدرس IP مشتری را نمی بینند و فقط می توانند آدرس IP حل کننده بازگشتی را که مشتری استفاده می کند بخوانند.

در نتیجه، حل‌کننده مستبد ما باید نه برای یک مشتری فردی، بلکه برای گروهی از مشتریان بر اساس حل‌کننده بازگشتی تصمیم بگیرد.

برای حل، از نمونه‌های یکسانی استفاده می‌کنیم، نتایج اندازه‌گیری مشتریان را برای هر یک از حل‌کننده‌های بازگشتی جمع‌بندی می‌کنیم و تصمیم می‌گیریم که این گروه از آنها را به کجا ارسال کنیم - یک پروکسی از طریق IX با استفاده از TCP Anycast، از طریق یک پروکسی ISP یا مستقیماً به ابر.

ما سیستم زیر را دریافت می کنیم:

مدل هدایت DNS به دست آمده به شما اجازه می دهد تا مشتریان را بر اساس مشاهدات تاریخی سرعت اتصالات از کلاینت ها به ابر هدایت کنید.

باز هم سوال این است که این رویکرد چقدر موثر عمل خواهد کرد؟ برای پاسخ، ما دوباره از سیستم کاوشگر خود استفاده می کنیم. بنابراین، پیکربندی ارائه‌دهنده را پیکربندی می‌کنیم، جایی که یکی از هدف‌ها جهت هدایت DNS را دنبال می‌کند، دیگری مستقیماً به ابر (تولید فعلی) می‌رود.

در نتیجه، نتایج را با هم مقایسه می کنیم و ارزیابی اثربخشی را دریافت می کنیم:

در نتیجه چندین چیز مهم یاد گرفتیم:

1. ما عملکرد مورد انتظار درخواست‌های مشتریان به ابر را با استفاده از DNS Steering ارزیابی کردیم.
2. ما داده ها را از مشتریان واقعی، از انواع دستگاه ها دریافت کردیم.
3. اثربخشی ایده پیشنهادی ثابت شده است.
4. ما ریسک نکردیم - تنظیمات تولید را برای مشتریان تغییر ندادیم.
5. هیچ چیز خراب نشد.

اکنون در مورد بخش دشوار - ما آن را در مرحله تولید راه اندازی می کنیم

بخش آسان اکنون به پایان رسیده است - یک نمونه اولیه کار وجود دارد. اکنون بخش سخت راه‌حلی برای تمام ترافیک نتفلیکس است که برای ۱۵۰ میلیون کاربر، هزاران دستگاه، صدها میکروسرویس، و یک محصول و زیرساخت همیشه در حال تغییر است. سرورهای نتفلیکس میلیون‌ها درخواست در ثانیه دریافت می‌کنند و به راحتی می‌توان با اقدام بی‌دقتی سرویس را شکست. در همان زمان، ما می خواهیم ترافیک را به صورت پویا از طریق هزاران سرور CDN در اینترنت هدایت کنیم، جایی که چیزی به طور مداوم و در نامناسب ترین لحظه تغییر می کند و می شکند.

و با همه اینها، تیم دارای 3 مهندس است که مسئول توسعه، استقرار و پشتیبانی کامل از سیستم هستند.

بنابراین، در ادامه در مورد خواب آرام و سالم صحبت خواهیم کرد.

چگونه توسعه را ادامه دهیم و تمام وقت خود را صرف پشتیبانی نکنیم؟ رویکرد ما بر 3 اصل استوار است:

1. مقیاس احتمالی خرابی ها (شعاع انفجار) را کاهش می دهیم.
2. ما برای شگفتی آماده می شویم - با وجود آزمایش و تجربه شخصی، انتظار داریم چیزی شکسته شود.
3. تنزل برازنده - اگر چیزی درست کار نمی کند، باید به طور خودکار تعمیر شود، حتی اگر به کارآمدترین راه نباشد.

معلوم شد که در مورد ما، با این رویکرد به مشکل، می توانیم یک راه حل ساده و موثر پیدا کنیم و پشتیبانی سیستم را به طور قابل توجهی ساده کنیم. متوجه شدیم که می‌توانیم یک کد کوچک به کلاینت اضافه کنیم و خطاهای درخواست شبکه ناشی از مشکلات اتصال را کنترل کنیم. در صورت بروز خطاهای شبکه، ما یک بازگشت مستقیم به ابر انجام می دهیم. این راه حل نیازی به تلاش قابل توجهی برای تیم های مشتری ندارد، اما خطر خرابی و غافلگیری غیرمنتظره را برای ما بسیار کاهش می دهد.

البته، با وجود عقب ماندگی، ما با این وجود از یک نظم واضح در طول توسعه پیروی می کنیم:

1. تست نمونه.
2. تست A/B یا قناری.
3. عرضه پیشرونده

با نمونه ها، این رویکرد شرح داده شده است - تغییرات ابتدا با استفاده از یک دستور العمل سفارشی آزمایش می شوند.

برای تست قناری، باید جفت سرورهای قابل مقایسه ای را بدست آوریم که بتوانیم نحوه عملکرد سیستم را قبل و بعد از تغییرات مقایسه کنیم. برای انجام این کار، از بین بسیاری از سایت های CDN خود، جفت سرورهایی را انتخاب می کنیم که ترافیک قابل مقایسه ای را دریافت می کنند:

سپس بیلد را با تغییرات روی سرور Canary نصب می کنیم. برای ارزیابی نتایج، سیستمی را اجرا می کنیم که تقریباً 100-150 معیار را با نمونه ای از سرورهای کنترل مقایسه می کند:

اگر آزمایش قناری موفقیت آمیز باشد، آن را به تدریج و به صورت امواج آزاد می کنیم. ما سرورها را در هر سایت به طور همزمان به روز نمی کنیم - از دست دادن کل سایت به دلیل مشکلات تأثیر مهم تری بر سرویس برای کاربران دارد تا از دست دادن همان تعداد سرور در مکان های مختلف.

به طور کلی، اثربخشی و ایمنی این رویکرد به کمیت و کیفیت معیارهای جمع آوری شده بستگی دارد. برای سیستم شتاب پرس و جو، ما معیارها را از تمام اجزای ممکن جمع آوری می کنیم:

• از مشتریان - تعداد جلسات و درخواست ها، نرخ بازگشتی؛
• پروکسی - آمار تعداد و زمان درخواست ها؛
• DNS - تعداد و نتایج درخواست ها.
• لبه ابری - تعداد و زمان برای پردازش درخواست ها در ابر.

همه این‌ها در یک خط لوله جمع‌آوری می‌شوند و بسته به نیاز، تصمیم می‌گیریم که کدام معیارها را به تجزیه و تحلیل بلادرنگ ارسال کنیم، و کدام را برای تشخیص دقیق‌تر به Elasticsearch یا Big Data ارسال کنیم.

نظارت می کنیم

در مورد ما، ما در حال ایجاد تغییرات در مسیر بحرانی درخواست ها بین مشتری و سرور هستیم. در عین حال، تعداد اجزای مختلف روی مشتری، سرور و در مسیر اینترنت بسیار زیاد است. تغییرات در مشتری و سرور به طور مداوم رخ می دهد - در طول کار ده ها تیم و تغییرات طبیعی در اکوسیستم. ما در وسط هستیم - هنگام تشخیص مشکلات، شانس خوبی وجود دارد که درگیر آن باشیم. بنابراین، ما باید به وضوح نحوه تعریف، جمع آوری و تجزیه و تحلیل معیارها را برای جداسازی سریع مشکلات درک کنیم.

در حالت ایده آل، دسترسی کامل به انواع معیارها و فیلترها در زمان واقعی. اما معیارهای زیادی وجود دارد، بنابراین سؤال هزینه مطرح می شود. در مورد ما، معیارها و ابزارهای توسعه را به صورت زیر جدا می کنیم:

برای شناسایی و تریاژ مشکلات ما از سیستم زمان واقعی منبع باز خود استفاده می کنیم قهرمانی که دنیا را روی شانههایش نگهداشته است и واحد تشعشع برابر مقدار نوری که از یک شمع معمولی بین المللی ساطع میگردد - برای تجسم این معیارهای جمع آوری شده را در حافظه ذخیره می کند، قابل اعتماد است و با سیستم هشدار ادغام می شود. برای بومی‌سازی و تشخیص، به گزارش‌های Elasticsearch و Kibana دسترسی داریم. برای تحلیل و مدل‌سازی آماری، از داده‌های بزرگ و تجسم در Tableau استفاده می‌کنیم.

به نظر می رسد کار با این رویکرد بسیار دشوار است. با این حال، با سازماندهی معیارها و ابزارها به صورت سلسله مراتبی، می‌توانیم به سرعت یک مسئله را تجزیه و تحلیل کنیم، نوع مشکل را تعیین کنیم و سپس به معیارهای دقیق بپردازیم. به طور کلی، ما حدود 1-2 دقیقه را صرف شناسایی منبع خرابی می کنیم. پس از این، ما با یک تیم خاص در تشخیص کار می کنیم - از ده ها دقیقه تا چند ساعت.

حتی اگر تشخیص به سرعت انجام شود، ما نمی خواهیم این اتفاق اغلب رخ دهد. در حالت ایده‌آل، فقط زمانی یک هشدار حیاتی دریافت می‌کنیم که تأثیر قابل‌توجهی بر سرویس داشته باشد. برای سیستم شتاب پرس و جو ما فقط 2 هشدار داریم که به شما اطلاع می دهد:

• درصد بازگشت مشتری - ارزیابی رفتار مشتری؛
• درصد خطاهای پروب - داده های پایداری اجزای شبکه.

این هشدارهای حیاتی نظارت می کنند که آیا سیستم برای اکثر کاربران کار می کند یا خیر. ما بررسی می‌کنیم که اگر نتوانستند شتاب درخواست را دریافت کنند، چند مشتری از بازگشت مجدد استفاده کردند. ما به طور متوسط ​​کمتر از 1 هشدار بحرانی در هفته داریم، حتی با وجود تغییرات زیادی در سیستم. چرا این برای ما کافی است؟

1. اگر پروکسی ما کار نکند یک بازگشت مشتری وجود دارد.
2. یک سیستم فرمان اتوماتیک وجود دارد که به مشکلات پاسخ می دهد.

جزئیات بیشتر در مورد دومی. سیستم آزمایشی ما، و سیستم تعیین خودکار مسیر بهینه برای درخواست‌های مشتری به ابر، به ما امکان می‌دهد به طور خودکار با برخی از مشکلات کنار بیاییم.

بیایید به پیکربندی نمونه و 3 دسته مسیر خود برگردیم. علاوه بر زمان بارگذاری، ما می توانیم به واقعیت تحویل نیز نگاه کنیم. اگر امکان بارگیری داده ها وجود نداشت، با مشاهده نتایج در مسیرهای مختلف می توانیم تعیین کنیم که کجا و چه چیزی خراب شده است و اینکه آیا می توانیم به طور خودکار با تغییر مسیر درخواست آن را برطرف کنیم.

مثال:

این فرآیند می تواند خودکار باشد. آن را در سیستم فرمان قرار دهید. و به آن آموزش دهید تا به مشکلات عملکرد و قابلیت اطمینان پاسخ دهد. اگر چیزی شروع به شکستن کرد، اگر گزینه بهتری وجود داشت واکنش نشان دهید. در عین حال، به لطف بازگشت به مشتریان، واکنش فوری حیاتی نیست.

بنابراین، اصول پشتیبانی سیستم را می توان به صورت زیر فرموله کرد:

• کاهش مقیاس خرابی؛
• جمع آوری معیارها؛
• اگر بتوانیم به طور خودکار خرابی ها را تعمیر می کنیم.
• اگر نمی تواند، به شما اطلاع می دهیم؛
• ما در حال کار بر روی داشبوردها و مجموعه ابزارهای تریاژ برای پاسخگویی سریع هستیم.

درس های آموخته شده

نوشتن یک نمونه اولیه زمان زیادی نمی برد. در مورد ما بعد از 4 ماه آماده شد. با آن معیارهای جدیدی دریافت کردیم و 10 ماه پس از شروع توسعه، اولین ترافیک تولید را دریافت کردیم. سپس کار خسته کننده و بسیار دشوار شروع شد: به تدریج سیستم را تولید و مقیاس کنید، ترافیک اصلی را مهاجرت کنید و از اشتباهات درس بگیرید. با این حال، این روند موثر خطی نخواهد بود - با وجود تمام تلاش ها، همه چیز قابل پیش بینی نیست. تکرار سریع و پاسخ به داده های جدید بسیار مؤثرتر است.

با توجه به تجربه ما می توانیم موارد زیر را توصیه کنیم:

1. به شهود خود اعتماد نکنید.

   شهود ما با وجود تجربه گسترده اعضای تیم، دائماً ما را ناکام می گذاشت. به عنوان مثال، ما به اشتباه سرعت مورد انتظار استفاده از یک پروکسی CDN یا رفتار TCP Anycast را پیش‌بینی کردیم.

2. دریافت داده از تولید

   دسترسی به حداقل مقدار کمی از داده های تولید در اسرع وقت بسیار مهم است. تقریباً غیرممکن است که تعداد موارد، تنظیمات و تنظیمات منحصر به فرد را در شرایط آزمایشگاهی بدست آوریم. دسترسی سریع به نتایج به شما این امکان را می دهد که به سرعت در مورد مشکلات احتمالی بیاموزید و آنها را در معماری سیستم در نظر بگیرید.

3. از توصیه ها و نتایج دیگران پیروی نکنید - داده های خود را جمع آوری کنید.

   اصول جمع آوری و تجزیه و تحلیل داده ها را رعایت کنید، اما نتایج و گفته های دیگران را کورکورانه نپذیرید. فقط شما می توانید دقیقاً بدانید چه چیزی برای کاربران شما کار می کند. سیستم شما و مشتریان شما ممکن است به طور قابل توجهی با سایر شرکت ها متفاوت باشد. خوشبختانه، ابزارهای تجزیه و تحلیل در حال حاضر در دسترس هستند و به راحتی قابل استفاده هستند. نتایجی که به دست می آورید ممکن است آن چیزی نباشد که Netflix، Facebook، Akamai و سایر شرکت ها ادعا می کنند. در مورد ما، عملکرد TLS، HTTP2 یا آمار در درخواست‌های DNS با نتایج فیس‌بوک، اوبر، آکامای متفاوت است - زیرا دستگاه‌ها، مشتریان و جریان‌های داده متفاوتی داریم.

4. روندهای مد را بی جهت دنبال نکنید و اثربخشی را ارزیابی کنید.

   ساده شروع کن بهتر است یک سیستم کار ساده در زمان کوتاه بسازید تا اینکه زمان زیادی را صرف توسعه اجزایی کنید که به آنها نیاز ندارید. بر اساس اندازه گیری ها و نتایج خود، وظایف و مسائل مهم را حل کنید.

5. برای برنامه های جدید آماده شوید.

   همانطور که پیش بینی همه مشکلات دشوار است، پیش بینی مزایا و کاربردها نیز از قبل دشوار است. از استارت‌آپ‌ها سرنخ بگیرید – توانایی آن‌ها برای انطباق با شرایط مشتری. در مورد شما، ممکن است مشکلات جدید و راه حل های آنها را کشف کنید. در پروژه خود، هدفی را برای کاهش تأخیر درخواست تعیین کردیم. با این حال، در طول تجزیه و تحلیل و بحث، متوجه شدیم که می توانیم از سرورهای پروکسی نیز استفاده کنیم:

   • برای ایجاد تعادل در ترافیک در مناطق AWS و کاهش هزینه ها؛
   • برای مدل سازی ثبات CDN.
   • برای پیکربندی DNS؛
   • برای پیکربندی TLS/TCP.

نتیجه

در این گزارش توضیح دادم که چگونه نتفلیکس مشکل تسریع درخواست‌های اینترنتی بین مشتریان و ابر را حل می‌کند. نحوه جمع‌آوری داده‌ها با استفاده از سیستم نمونه‌گیری روی مشتریان، و استفاده از داده‌های تاریخی جمع‌آوری‌شده برای مسیریابی درخواست‌های تولید از مشتریان از طریق سریع‌ترین مسیر در اینترنت. چگونه از اصول پروتکل های شبکه، زیرساخت CDN، شبکه ستون فقرات و سرورهای DNS برای دستیابی به این وظیفه استفاده می کنیم.

با این حال، راه حل ما فقط نمونه ای از نحوه پیاده سازی ما در نتفلیکس چنین سیستمی است. چیزی که برای ما کار کرد. بخش کاربردی گزارش من برای شما اصول توسعه و پشتیبانی است که ما از آنها پیروی می کنیم و به نتایج خوبی می رسیم.

راه حل ما برای مشکل ممکن است برای شما مناسب نباشد. با این حال، تئوری و اصول طراحی باقی می مانند، حتی اگر زیرساخت CDN خود را نداشته باشید، یا اگر تفاوت قابل توجهی با ما داشته باشید.

اهمیت سرعت درخواست های تجاری نیز همچنان مهم است. و حتی برای یک سرویس ساده باید انتخاب کنید: بین ارائه دهندگان ابر، مکان سرور، ارائه دهندگان CDN و DNS. انتخاب شما بر اثربخشی پرس و جوهای اینترنتی برای مشتریان شما تأثیر می گذارد. و اندازه گیری و درک این تأثیر برای شما مهم است.

با راه حل های ساده شروع کنید، به نحوه تغییر محصول اهمیت دهید. همانطور که می خواهید یاد بگیرید و سیستم را بر اساس داده های مشتریان، زیرساخت ها و کسب و کار خود بهبود بخشید. در مورد احتمال خرابی های غیرمنتظره در طول فرآیند طراحی فکر کنید. و سپس می توانید روند توسعه خود را تسریع کنید، کارایی راه حل را بهبود بخشید، از بار پشتیبانی غیر ضروری اجتناب کنید و با آرامش بخوابید.

امسال این همایش از 6 تا 10 تیرماه برگزار می شود در قالب آنلاین می توانید از یکی از پدران DevOps، خود جان ویلیس، سوال بپرسید!

منبع: www.habr.com