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

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

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

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

В доклада си Сергей говори подробно

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

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

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

Следва разказът от гледна точка на говорещия.

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

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

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

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

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

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

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

Вътре в Netflix

Хиляди различни устройства поддържат приложения на Netflix. Разработени са от четири различни екипа, които правят отделни версии на клиента за Android, iOS, TV и уеб браузъри. И ние полагаме много усилия за подобряване и персонализиране на потребителското изживяване. За да направим това, провеждаме стотици 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.

Относно интернет ускорението

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

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

материал

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

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

Но предимствата не свършват дотук. След като връзката е установена, TCP увеличава прозореца на задръстване (количеството информация, което може да предаде през тази връзка паралелно). Ако се загуби пакет от данни, тогава класическите реализации на TCP протокола (като TCP New Reno) намаляват отворения „прозорец“ наполовина. Нарастването на прозореца на задръстванията и скоростта на възстановяването му от загуба отново зависи от забавянето (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 връзки и мултиплексиране на заявки.

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

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

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

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

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

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

Прототип 2.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сега за трудната част - пускаме го в производство

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

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

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

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

Ние намаляваме потенциалния мащаб на повреди (радиус на взрив).
Готвим се за изненади - очакваме нещо да се счупи, въпреки тестовете и личния опит.
Грациозно влошаване - ако нещо не работи правилно, то трябва да бъде поправено автоматично, дори и да не е по най-ефективния начин.

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

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

Примерен тест.
A/B тестване или Canaries.
Прогресивно внедряване.

Подходът е описан с мостри - промените първо се тестват с помощта на персонализирана рецепта.

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

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

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

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

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

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

Ние наблюдаваме

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

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

За откриване и сортиране на проблеми ние използваме нашата собствена система с отворен код в реално време Атлас и Лумен - за визуализация. Той съхранява обобщени показатели в паметта, надежден е и се интегрира със системата за предупреждение. За локализация и диагностика имаме достъп до регистрационни файлове от Elasticsearch и Kibana. За статистически анализи и моделиране използваме големи данни и визуализация в Tableau.

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

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

Client Fallback percentage – оценка на клиентското поведение;
процент Грешки на сондата - данни за стабилност на мрежовите компоненти.

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

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

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

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

Примери:

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

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

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

Поуки

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

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

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

Заключение

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

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

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

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

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

Тази година конференцията ще се проведе от 6 до 10 юли в онлайн формат. Можете да задавате въпроси на един от бащите на DevOps, самия Джон Уилис!

Източник: www.habr.com

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