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

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 Mbps престава да оказва директно влияние върху скоростта на зареждане на стандартен уебсайт. Въпреки това между закъснението на свързването и скоростта на зареждане на страницата се проследява линейна зависимост:

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

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

Вътре в Netflix

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

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

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

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

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

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

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

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

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

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

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

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

Днес Netflix разполага с три региона 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 сървъра, възстановяването ще бъде по-бързо. При това, загубата на пакети е стандартно явление, особено за безжични мрежи.

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

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

Измерваме

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

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

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

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

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 сървър, разположен при интернет доставчика. Целта ни е да разберем коя пътека е по-добра и какви са предимствата от прокси, в сравнение с начина, по който заявките се насочват в production. За целта използваме система за проби по следния начин:

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

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

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

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

Прототип 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.
Събрахме данни от реални клиенти, от всички видове устройства.
Докажахме ефективността на предложената идея.
Не рискувахме — не променяхме конфигурациите в production за клиентите.
Нищо не се счупи.

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

Най-лесното вече е зад нас — имаме работещ прототип. Сега сложната част е да внедрим решението за целия трафик на 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;
прокси — статистика за брой и време на заявките;
DNS — брой и резултати от заявките;
cloud edge — брой и време за обработка на заявките в облака.

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

Мониторинг

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

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

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

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

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

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

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

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

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

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

Примери:

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

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

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

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

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

На база на нашия опит, можем да ви посъветваме следното:

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

Заключение

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

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

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

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

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