🥇Ускоряваме интернет запитванията и спим спокойно

Netflix — лидер на пазара за интернет телевизия — компанията, която създаде и активно развива този сегмент. Netflix е известен не само с обширния каталог от филми и сериали, достъпни от почти всяка точка на света и на всяко устройство с дисплей, но и с надеждната инфраструктура и уникалната инженерна култура.

Нагледен пример за подхода на Netflix към разработването и поддръжката на сложни системи бе представен на DevOops 2019. Сергей Федоров — директор по разработката в Netflix. Завършил е Факултета по математика и информатика на ННГУ с името на Лобачевски, Сергей е един от първите инженери в Open Connect — екипа за CDN в Netflix. Той е построил системи за мониторинг и анализ на видеоданни, стартира популярната услуга за оценка на скоростта на интернет връзката FAST.com и през последните няколко години работи върху оптимизация на интернет заявките, за да работи приложението на Netflix колкото е възможно по-бързо за потребителите.

Докладът получи отлични отзиви от участниците в конференцията и ние подготвихме текстова версия за вас.

В доклада Сергей подробно разказа

за факторите, влияещи на закъснението на интернет заявките между клиента и сървъра;
как да намалим това закъснение;
как да проектираме, поддържаме и мониторим системи, устойчиви на грешки;
как да постигаме резултати в кратки срокове с минимален риск за бизнеса;
как да анализираме резултатите и да се поучаваме от грешките.

Отговорите на тези въпроси са нужни не само на хората, работещи в крупни корпорации.

Представените принципи и техники трябва да знае и прилага всеки, който разработва и поддържа интернет продукти.

По-нататък — разказ от лицето на говорителя.

Важността на скоростта на интернет

Скоростта на интернет заявките е пряко свързана с бизнеса. Нека разгледаме сферата на пазаруването: компанията Amazon през 2009 година каза,, че закъснение от 100 мс води до загуба от 1% от продажбите.

Все повече стават мобилните устройства, а заедно с тях и мобилните сайтове и приложения. Ако вашата страница се зарежда по-дълго от 3 секунди, вие губите около половината от потребителите. От юли 2018 година, Google взема предвид скоростта на зареждане на вашата страница в резултатите от търсене: колкото по-бързо е зареждането на страницата, толкова по-висока е нейната позиция в Google.

Скоростта на свързване също е важна и във финансовите организации, където закъснението е критично. През 2015 година компанията Hibernia Networks завърши кабелна връзка между Ню Йорк и Лондон за 400 милиона долара, с цел да се намали закъснението между двата града с 6 мс. Представете си, 66 милиона долара за 1 мс намаляване на закъснението!

Според изследване, скорост над 5 Мбит/с вече не оказва пряко влияние върху скоростта на зареждане на стандартен сайт. Однако между закъснението на връзката и скоростта на зареждане на страницата има линейна зависимост:

Обаче Netflix не е стандартен продукт. Влиянието на закъснението и скоростта върху потребителя е активна област на анализ и разработка. Има зареждане на приложения и избор на съдържание, зависещи от закъснението, но зареждането на статични елементи и стриймингът също зависят от скоростта на връзката. Анализът и оптимизацията на ключовите фактори, влияещи на качеството на услугата за потребителя, е активна сфера на разработка за няколко екипа в Netflix. Една от задачите е намаляване на закъснението на запитванията между устройствата на Netflix и облачната инфраструктура.

В доклада ще се фокусираме именно върху намаляването на закъснението (latency) на примера на инфраструктурата на Netflix. Ние ще разгледаме от практическа гледна точка как да подхождаме към процесите на проектиране, разработка и управление на сложни разпределени системи и да инвестираме време в иновации и резултати, вместо в диагностика на операционни проблеми и аварии.

Вътре в Netflix

Хиляди различни устройства поддържат приложенията на Netflix. Разработването им се осъществява от четири различни екипа, които създават отделни версии на клиента за Android, iOS, TV и уеб браузъри. И ние влагаме много усилия, за да подобрим и персонализираме потребителския интерфейс. За целта провеждаме стотици A/B тестове паралелно.

Персонализацията се поддържа чрез стотици микросервизи в облака AWS, осигуряващи персонализирани данни за потребителя, управление на запросите, телеметрия, Big Data и кодиране. Визуализацията на трафика изглежда така:

Линк към видео с демонстрация (6:04-6:23)

Отляво е входната точка, след което трафикът се разпределя между няколко стотици микросервизи, които се поддържат от различни бекенд екипи.

Още единствен важен компонент на нашата инфраструктура е Open Connect CDN, който доставя статично съдържание – видео, изображения, код за клиенти и т.н. CDN е разположена на персонализирани сървъри (OCA – Open Connect Appliance). Вътре са разположени массиви SSD и HDD дискове, управлявани от оптимизирана FreeBSD, с NGINX и набор от услуги. Проектираме и оптимизираме хардуерните и софтуерните компоненти така, че такъв CDN сървър да може да изпраща максимално количество данни на потребителите.

Стената от тези сървъри в точката за обмен на интернет трафик (Internet eXchange – IX) изглежда така:

Internet Exchange предоставя възможност на интернет доставчиците и доставчиците на съдържание да се свързват помежду си за по-пряк обмен на данни в интернет. По целия свят има около 70-80 точки Internet Exchange, където са установени нашите сървъри, и ние сами се грижим за тяхната инсталация и поддръжка:

Освен това, ние също предоставяме сървъри директно на интернет доставчиците, които те инсталират в своята мрежа, подобрявайки локализацията на трафика на Нетфликс и качеството на стриминга за потребителите:

Наборът от услуги на AWS отговаря за разпределението на видео заявките от клиентите към сървърите на CDN, а също така и за конфигурирането на самите сървъри – обновление на съдържанието, софтуерния код, настройките и т.н. За последното ние също изградихме backbone мрежа, която свързва сървърите в точките на Internet Exchange с AWS. Backbone мрежата представлява глобална мрежа от оптични влакна и рутери, които можем да проектираме и конфигурираме в зависимост от нашите нужди.

По оценките на Sandvine, нашата CDN инфраструктура доставя в пиковите часове около ⅛ част от глобалния интернет трафик и ⅓ от трафика в Северна Америка, където Netflix съществува най-дълго. Впечатляващи цифри, но за мен едно от най-удивителните постижения е, че цялата CDN система се разработва и поддържа от екип от по-малко от 150 човека.

Първоначално CDN инфраструктурата беше проектирана за доставка на видео данни. Въпреки това, с течение на времето осъзнахме, че можем да я използваме и за оптимизация на динамични заявки от клиенти в AWS облака.

За ускорение на интернет

Днес Netflix разполага с 3 региона AWS, а застряването на исканията в облака ще зависи от това колко далеч е клиентът от най-близкия регион. И ние имаме множество CDN сървъри, които се използват за доставяне на статично съдържание. Можем ли по някакъв начин да използваме тази инфраструктура, за да ускорим динамичните искания? За съжаление, кеширането на тези искания не е възможно — API-то е персонализирано и всеки резултат е уникален.

Нека направим прокси на CDN сървъра и започнем да пренасочваме трафика през него. Ще бъде ли по-бързо?

Матчасть

Нека си спомним как работят мрежовите протоколи. Днес голяма част от трафика в интернет използва HTTPs, който зависи от долните протоколи TCP и TLS. За да се свърже клиентът със сървъра, той прави handshake, и за да установи защитена връзка, клиентът трябва да обменя съобщения със сървъра три пъти и още поне веднъж, за да предаде данни. При закъснение от един обмен (RTT) от 100 мс, ще ни трябват 400 мс, за да получим първия бит данни:

Ако сертификатите са разположени на CDN сървъра, тогава времето за „рукопожатие“ между клиента и сървъра може да бъде съществено съкратено, ако CDN е по-близо. Да предположим, че закъснението до CDN сървъра е 30 мс. Тогава за получаването на първия бит ще ни трябват вече 220 мс:

Но предимствата не свършват дотук. След като връзката вече е установена, TCP увеличава congestion window (броя на информацията, която може да предава по тази връзка паралелно). Ако се загуби пакет данни, класическите реализации на TCP протокола (като TCP New Reno) намаляват отвореното „окно“ наполовина. Увеличението на congestion window и скоростта на възстановяване от загуба отново зависят от закъснението (RTT) до сървъра. Ако тази връзка е само до CDN сървъра, това възстановяване ще бъде по-бързо. При това, загубата на пакети е стандартно явление, особено за безжични мрежи.

Пропускната способност на интернет може да намалява, особено в пиковите часове заради трафика от потребителите, което може да доведе до "задръствания". В същото време, в интернет няма начин да се даде приоритет на едни заявки над други. Например, да се даде приоритет на малки по обем и чувствителни на закъснение заявки в сравнение с "тежки" потоци данни, които натоварват мрежата. Въпреки това, в нашия случай, наличието на собствена основна мрежа позволява да се направи това на част от пътя на заявката — между CDN и облака, и ние можем да я конфигурираме напълно. Може да се настроят малки и зависими от закъснение пакети да имат приоритет, а големите потоци данни да вървят малко по-късно. Колкото по-близо е CDN до клиента, толкова по-висока е ефективността.

Също така влияние върху закъснението оказват протоколите на ниво приложение (OSI ниво 7). Нови протоколи, като HTTP/2, позволяват оптимизация на производителността на паралелни заявки. Въпреки това, имаме клиенти на Netflix с остарели устройства, които не поддържат новите протоколи. Не всички клиенти могат да бъдат обновени или оптимално настроени. В същото време между проксито на CDN и облака — пълен контрол и възможност за използване на нови, оптимални протоколи и настройки. Неефективната част със старите протоколи ще действа само между клиента и сървъра на CDN. Освен това, можем да извършваме мултиплексиране на заявки по вече установена връзка между CDN и облака, подобрявайки използването на връзката на ниво TCP:

Измерваме

Въпреки че теорията обещава подобрения, ние не се впускаме веднага в пускането на системата в продукция. Вместо това, трябва първо да докажем, че идеята ще работи на практика. За това трябва да отговорим на няколко въпроса:

Скорост: ще бъде ли проксито по-бързо?
Надеждност: ще се чупи ли по-често?
Сложност: как да интегрираме с приложенията?
Цена: колко струва разгръщането на допълнителна инфраструктура?

Нека разгледаме подробно нашия подход към оценка на първата точка. Останалите се разглеждат по подобен начин.

За анализ на скоростта на заявките искаме да получим данни за всички потребители, без да харчим много време за разработка и без да счупим продукцията. За това има няколко подхода:

RUM, или пасивно измерване на заявките. Измерваме времето за изпълнение на текущите заявки от потребителите и осигуряваме пълно покритие на потребителите. Недостатък е, че сигналът не е много стабилен поради множество фактори, например различни размери на заявките, времето за обработка на сървъра и клиента. Освен това не можем да тестваме нова конфигурация без да повлияем на продукцията.
Лабораторни тестове. Специализирани сървъри и инфраструктура, имитираща клиенти. С тях провеждаме необходимите тестове. Така получаваме пълен контрол върху резултатите от измерванията и ясен сигнал. Но нямаме пълно покритие на устройства и местоположения на потребителите (особено ако услугата е глобална и поддържа хиляди модели устройства).

Как можем да обединим предимствата на двата метода?

Нашият екип намери решение. Написахме малък фрагмент код — проба — който вградихме в нашето приложение. Пробите ни позволяват да правим напълно контролирани мрежови тестове от нашите устройства. Работи по следния начин:

Скоро след зареждане на приложението и завършване на началната активност, стартираме нашите проби.
Клиентът прави заявка към сървъра и получава "рецепта" за теста. Рецептата не е нищо повече от списък с URL адреси, за които трябва да направим HTTP(s) заявка. Освен това, рецептата конфигурира параметрите на заявките: закъснения между заявките, обем на исканите данни, HTTP(s) заглавия и т.н. При това можем да тестваме паралелно няколко различни рецепти — при заявка за конфигурация, случайно определяме коя рецепта да предоставим.
Времето за стартиране на пробата се избира така, че да не противоречи на активно използване на мрежовите ресурси от клиента. Всъщност се избира време, когато клиентът не е активен.
След получаване на рецептата клиентът извършва заявки към всяка от URL адресите паралелно. Заявката към всеки адрес може да се повтаря — т.н. "пулсове". При първия пулс измерваме колко време е нужно за установяване на връзка и изтегляне на данни. При втория пулс измерваме времето за зареждане на данни по вече установената връзка. Преди третия можем да зададем закъснение и да измерим скоростта на повторното установяване на връзка и т.н.
По време на теста измерваме всички параметри, които устройството може да получи:
- време за DNS запитване;
- време за установяване на TCP свързване;
- време за установяване на TLS свързване;
- време за получаване на първия байт данни;
- общо време за зареждане;
- статус код на резултата.
След приключване на всички пулса пробата зарежда резултатите от всички измервания за аналитика.

Ключовите моменти са минимална зависимост от логиката на клиента, обработка на данни на сървера и измерване на паралелни запитвания. По този начин получаваме възможност да изолираме и тестваме влиянието на различни фактори, които влияят на производителността на запитванията, да ги варираме в рамките на една рецепта и да получим резултати от реални клиенти.

Тази инфраструктура се оказа полезна не само за анализ на производителността на запитванията. В момента имаме 14 активни рецепти, над 6000 проби в секунда, получаващи данни от всички краища на света и с пълно покритие на устройствата. Ако Netflix закупеше подобен сервис от трети компании, той щеше да струва милиони долари годишно, при много по-лошо покритие.

Тестваме теорията на практика: прототип

С подобна система получихме възможност да оценим ефективността на CDN прокси по отношение на закъснението на запитванията. Сега трябва да:

създадем прототип на прокси;
разместим прототипа на CDN;
определим как да насочим клиентите към прокси на конкретен CDN сървър;
сравним производителността с запитвания в AWS без прокси.

Задачата е да оценим ефективността на предложеното решение възможно най-бързо. За реализиране на прототипа избрахме Go, благодарение на наличието на добри мрежови библиотеки. На всеки CDN-сървър инсталирахме прототипа на прокси като статичен бинарен файл, за да минимализираме зависимостите и да опростим интеграцията. В началната реализация използвахме максимално стандартни компоненти и малки модификации за HTTP/2 connection pooling и request multiplexing.

За балансиране между AWS регионите използвахме географска DNS база данни, същата, която се използва за балансиране на клиентите. За избора на CDN сървър за клиента използваме TCP Anycast за сървърите в Internet Exchange (IX). В този вариант използваме един IP адрес за всички CDN сървъри, при което клиентът ще бъде насочен към CDN сървъра с най-малко количество IP hops. При CDN сървърите, разположени при интернет доставчиците (ISP), нямаме контрол над рутера за настройка на TCP Anycast, затова задействаме същата логика, по която клиентите се насочват към интернет доставчиците за видеострийминг.

И така, имаме три типа пътища за запитване: в облака чрез отворен интернет, през CDN сървър в IX или през CDN сървър, разположен при интернет доставчика. Нашата цел е да разберем кой път е най-добър и каква е ползата от проксито, в сравнение с начина, по който запитванията се насочват в продукцията. За целта използваме система за проби по следния начин:

Всеки от пътищата става отделна таргет и ние наблюдаваме времето, което получаваме. За анализа обединяваме резултатите от проксито в една група (избираме най-доброто време между IX и ISP прокси) и сравняваме с времето на запитванията в облака без прокси:

Както личи, резултатите са неясни — в повечето случаи проксито осигурява добро ускорение, но също така има значителен брой клиенти, при които ситуацията значително се влошава.

В резултат на това направихме няколко важни неща:

Оценихме очакваната производителност на запитванията от клиентите в облака чрез CDN прокси.
Получихме данни от настоящи клиенти, от всички типове устройства.
Разбрахме, че теорията не се потвърди на 100% и първоначалното предложение с CDN прокси не работи за нас.
Не рискувахме — не променяхме конфигурацията на продукцията за клиентите.
Нищо не се счупи.

Прототип 2.0

И така, връщаме се на чертожната дъска и повтаряме процеса отново.

Идеята е — вместо 100% прокси, да определим за всеки клиент най-бързия път и да насочваме запитванията там — т.е. да реализираме това, което се нарича client steering.

Как да го реализираме? Не можем да използваме логика на сървърната страна, тъй като целта е да се свържем с този сървър. Трябва да направим това по някакъв начин на клиента. И идеално, да го направим с минимално количество сложна логика, за да не решаваме проблема с интеграцията с многобройни клиентски платформи.

Отговорът е използването на DNS. В нашия случай имаме собствена DNS инфраструктура и можем да настроим домейн зона, за която нашите сървъри ще бъдат авторитетни. Работи така:

Клиентът прави заявка към DNS-сървъра, използвайки хост, например api.netflix.com.
Заявката постъпва на нашия DNS-сървър.
DNS-сървърът знае кой е най-бързият маршрут за този клиент и предоставя съответния IP адрес.

В решението има допълнителна сложност: авторитетните DNS доставчици не виждат IP адреса на клиента и могат да вземат предвид само IP адреса на рекурсивния резолвер, който клиентът използва.

В крайна сметка нашият авторитетен резолвер трябва да вземе решение не за отделния клиент, а за група клиенти на базата на рекурсивния резолвер.

За решаването използваме същите проби, агрегирайки резултатите от измерванията на клиентите по всеки от рекурсивните резолвери и решаваме накъде да насочим тази група - през прокси чрез IX с помощта на TCP Anycast, през ISP прокси или директно в облака.

Получаваме такава система:

Получената модел на DNS steering позволява насочване на клиентите на базата на исторически наблюдения за скорости на свързване от клиентите до облака.

Отново, въпросът е - колко ефективно ще работи този подход? За да отговорим, отново използваме нашата система за проби. Затова настройваме конфигурация, където една от целите следва посоката от DNS steering, а другата - отива директно в облака (текущото производство).

В крайна сметка сравняваме резултатите и получаваме оценка за ефективност:

В крайна сметка, научихме няколко важни неща:

Оценихме очакваната производителност на заявките от клиентите към облака, използвайки DNS Steering.
Получихме данни от настоящи клиенти, от всички типове устройства.
Докажахме ефикасността на предложената идея.
Не рискувахме — не променяхме конфигурацията на продукцията за клиентите.
Нищо не се счупи.

Сега за сложното - пускаме в продукция.

Най-лесното вече е зад гърба — имаме работещ прототип. Сега трудната част — да пуснем решението за целия трафик на Netflix, да го разположим на 150 милиона потребители, хиляди устройства, стотици микросервизи и постоянно променящи се продукти и инфраструктура. На сървърите на Netflix идват милиони заявки в секунда и лесно можем да повредим услугата с неосмотрително действие. В същото време искаме динамично да насочваме трафика през хиляди CDN сървъри, в интернет, където нещо постоянно се променя и разваля в най-неподходящия момент.

И въпреки всичко, в екипа има 3 инженера, отговорни за разработката, разполагането и пълната поддръжка на системата.

Затова по-нататък ще говорим за спокоен и здрав сън.

Как да продължим разработката, без да похарчим всичкото време за поддръжка? В основата на нашия подход стоят 3 принципа:

Намаляване на потенциалния мащаб на повредите (blast radius).
Подготовка за изненади — очакваме, че нещо ще се повреди, независимо от тестването и личния опит.
Постепенна деградация (graceful degradation) — ако нещо не работи както трябва, то трябва да се ремонтира автоматично, макар и не по най-ефективния начин.

Оказа се, че в нашия случай, с такъв подход към проблема, можем да намерим просто и ефективно решение и значително да опростим поддръжката на системата. Разбрахме, че можем да добавим малко парче код в клиента и да следим за грешки в мрежовите заявки, предизвикани от проблеми с връзката. При мрежови грешки правим fallback директно в облака. Такова решение не изисква значителни усилия от клиентските екипи, но значително намалява риска от неочаквани повреди и изненади за нас.

Разбира се, въпреки fallback, все пак следваме строга дисциплина по време на разработката:

Тест с проби.
A/B тестване или Canaries.
Постепенно пускане (progressive rollout).

С пробите подходът беше описан — промените първо се тестват с помощта на настроен рецепт.

За canary тестването ни трябват сравними двойки сървъри, на които можем да сравним как работи системата преди и след промените. За целта от нашите многобройни CDN сайтове правим изборка от двойки сървъри, които получават сравним трафик:

След това поставяме сборката с промените на Canary сървъри. За оценка на резултатите стартираме система, която сравнява около 100-150 метрики с извадка от Control сървъри:

Ако Canary тестването премине успешно, правим релиз постепенно, на вълни. На всеки от уебсайтовете не актуализираме сървъри едновременно — загубата на цял уебсайт в случай на проблеми оказва по-съществено влияние на услугата за потребителите, отколкото загубата на същото количество сървъри, но на различни места.

Като цяло, ефективността и безопасността на такъв подход зависи от количеството и качеството на събраните метрики. За нашата система за ускорение на заявките събираме метрики от всички възможни компоненти:

от клиенти — брой сесии и заявки, fallback rates;
прокси — статистика за броя и времето на заявките;
DNS — брой и резултати от заявките;
cloud edge — брой и време за обработка на заявките в облака.

Всичко това се събира в единен pipeline, и в зависимост от нуждите, решаваме какви метрики да изпращаме за real-time анализ, а какви — в Elasticsearch или Big Data за по-подробна диагностика.

Мониторинг

В нашия случай правим промени на критичния път на заявките между клиента и сървера. При това, броят на различните компоненти на клиента, на сървера и по пътя през интернет — е огромен. Промените на клиента и сървера са постоянни — по време на работа на десетки екипи и естествени промени в екосистемата. Ние сме в средата — при диагностика на проблеми, има голям шанс, че ще участваме в това. Затова е необходимо добре да разбираме как да определяме, събираме и анализираме метрики за бърза локализация на проблемите.

Идеално — пълен достъп до всички видове метрики и филтри в реално време. Но метриките са много, затова възниква въпросът за разходите. В нашия случай разделяме метриките и инструментите за разработка по следния начин:

За откриване и triage на проблеми използваме собствена real-time система с отворен код Atlas и Lumen — за визуализация. Тя съхранява агрегирани метрики в паметта, надеждна е и се интегрира с alerting system. За локализация и диагностика имаме достъп до логове с Elasticsearch и Kibana. За статистически анализ и моделиране — използваме big data и визуализация в Tableau.

Изглежда, че с такъв подход е много трудно да се работи. Обаче при йерархична организация на метриките и инструментите, можем бързо да анализираме проблема, да определим типа на проблема и след това — да задълбочим анализa на детайлните метрики. За да открием източника на повредата, изразходваме общо около 1-2 минути. След това вече работим с конкретен екип по диагностика — от десетки минути до няколко часа.

Дори и да направим диагностика бързо, не искаме това да се случва често. В идеалния случай ще получаваме критичен алерт само когато има значително влияние върху услугата. За нашата система за ускорение на запитванията имаме само 2 алерта, които ще известяват:

процент на Client Fallback — оценка на поведението на клиентите;
процент на Probe errors — данни за стабилността на мрежовите компоненти.

Тези критични алерти следят дали системата работи за повечето потребители. Наблюдаваме колко клиенти са се възползвали от fallback, ако не са могли да получат ускорение на запитванията. Средно имаме по-малко от 1 критично известие на седмица, въпреки че в системата се извършват огромен брой промени. Защо това е достатъчно за нас?

Съществува client fallback в случай, че нашият прокси не работи.
Има автоматична steering система, която реагира на проблемите.

За последното по-подробно. Нашата система за проби и системата за автоматично определяне на оптималния маршрут за запитванията от клиента към облака ни позволяват автоматично да се справяме с някои проблеми.

Да се върнем към нашата конфигурация на пробите и 3 категории маршрути. Освен времето за зареждане, можем да следим самия факт на доставка. Ако не успеем да заредим данните, гледайки резултатите по различни маршрути, можем да определим къде и какво е счупено и можем ли автоматично да го поправим, променяйки маршрута на запитването.

Примери:

Този процес може да се автоматизира. Да го включим в steering-системата. И да я научим да реагира на проблеми с производителността и надеждността. Ако нещо започне да се счупва — да реагира, ако има по-добра опция. При това моменталната реакция не е критична, благодарение на fallback на клиентите.

По този начин принципите на поддръжка на системата могат да бъдат формулирани така:

намаляваме мащаба на повредите;
събираме метрики;
автоматично поправяме повредите, ако можем;
ако не можем — известяваме;
Работим по dashboards и triage toolset за бърза реакция.

Извлечени уроци

За написването на прототип не е нужно много време. В нашия случай той беше готов само след 4 месеца. С него получихме нови метрики и след 10 месеца от началото на разработката получихме първия production трафик. След това започна трудна и много сложна работа: постепенно продуктизация и мащабиране на системата, мигриране на основния трафик и учене от грешките. Важно е да се отбележи, че този ефективен процес няма да бъде линеен — независимо от всички усилия, не може всичко да се предвиди. Бързата итерация и реакция на новите данни са много по-ефективни.

Въз основа на нашия опит, можем да препоръчаме следното:

Не се доверявайте на интуицията.
Нашата интуиция постоянно ни подвеждаше, въпреки огромния опит на членовете на екипа. Например, неправилно предсказахме очакваното ускорение от използването на CDN прокси или поведението на TCP Anycast.
Получавайте данни от production.
Важно е да получите достъп възможно най-бързо поне до малко количество production данни. Броят на уникалните случаи, конфигурации, настройки в лабораторни условия е почти невъзможен за получаване. Бързият достъп до резултатите ще позволи по-бързо да научите за потенциални проблеми и да ги вземете предвид в архитектурата на системата.
Не следвайте чужди съвети и резултати — събирайте свои данни.
Следвайте принципите за събиране и анализ на данни, но не приемайте сляпо чужди резултати и твърдения. Само вие можете да знаете точно какво работи за вашите потребители. Вашите системи и ваши клиенти могат да се различават съществено от други компании. За щастие, инструментите за анализ сега са достъпни и лесни за използване. Получените от вас резултати може да не съответстват на тези, заявявани от Netflix, Facebook, Akamai и други компании. В нашия случай, производителността на TLS, HTTP2 или статистиката за DNS запитвания е различна от резултатите на Facebook, Uber, Akamai — защото разполагаме с различни устройства, клиенти и потоци от данни.
Не се стремете към модни трендове без нужда и оценка на ефективността.
Започвайте с простото. По-добре е да изградите проста работеща система за кратко време, отколкото да инвестирате много време в разработването на ненужни компоненти. Решавайте задачи и проблеми, които са важни на основата на вашите измервания и резултати.
Бъдете готови за нови приложения.
Точно както е трудно да се предвидят всички проблеми - трудно е предварително да се предвидят предимствата и приложенията. Взете пример от стартиращите компании - тяхната способност да се адаптират към нуждите на клиентите. Във вашия случай - можете да откриете нови проблеми и техните решения. В нашия проект целта ни беше да намалим закъснението на заявките. Въпреки това, по време на анализа и обсъжданията, осъзнахме, че можем да прилагаме прокси сървъри също така:
- за баланс на трафика между AWS регионите и намаляване на разходите;
- за моделиране на стабилността на CDN;
- за конфигуриране на DNS;
- за конфигуриране на TLS/TCP.

Заключение

В доклада описах как Netflix решава проблема с ускоряването на интернет заявките между клиентите и облака. Как събираме данни с помощта на система за проби от клиентите и използваме събраните исторически данни, за да насочваме production заявките от клиентите по възможно най-бързия път в интернет. Как използваме принципите на работа на мрежовите протоколи, нашата CDN инфраструктура, основната мрежа и DNS сървърите за постигане на тази цел.

Въпреки това, нашето решение е само пример за това как в Netflix сме реализирали такава система. Какво проработи за нас. Приложната част на доклада ми за вас - принципите на разработка и поддръжка, които следваме, за да постигнем добри резултати.

Нашето решение на проблема може да не ви подхожда. Въпреки това, теорията и принципите на разработка остават, дори ако нямате собствена CDN инфраструктура, или ако тя значително се различава от нашата.

Също така остава важността на скоростта на заявките за бизнеса. Дори за основна услуга трябва да правите избор: между „облачни“ доставчици, местоположение на сървърите, CDN и доставчици на DNS. Вашият избор ще влияе на ефективността на интернет заявките за вашите клиенти. И за вас е важно да измервате и разбирате това влияние.

Започнете с прости решения, обърнете внимание на начина, по който променяте продукта. Учете се в процеса и усъвършенствайте системата на база данни от вашите клиенти, вашата инфраструктура и вашия бизнес. Мислете за възможността от неочаквани аварии в процеса на проектиране. И тогава ще можете да ускорите процесса на разработка, да подобрите ефективността на решението, да избегнете излишната натовареност на поддръжката и да спите спокойно.