Убрзајте интернетске захтеве и мирно спавајте

Нетфлик је лидер на тржишту интернет телевизије - компанија која је створила и активно развија овај сегмент. Нетфлик је познат не само по свом опсежном каталогу филмова и ТВ серија доступних из готово сваког кутка планете и било ког уређаја са екраном, већ и по својој поузданој инфраструктури и јединственој инжењерској култури.

Јасан пример Нетфлик приступа развоју и подршци сложених система представљен је на ДевОопс 2019. Сергеј Федоров - Директор развоја у Нетфлик-у. Дипломирао на Факултету рачунарске математике и математике Нижњеновгородског државног универзитета. Лобачевски, Сергеј један од првих инжењера у Опен Цоннецт - ЦДН тиму на Нетфлик-у. Изградио је системе за праћење и анализу видео података, покренуо популаран сервис за процену брзине интернет конекције ФАСТ.цом, а последњих неколико година ради на оптимизацији интернет захтева како би Нетфлик апликација што брже радила за кориснике.

Извештај је добио најбоље критике учесника конференције, а ми смо за вас припремили текстуалну верзију.

У свом извештају, Сергеј је говорио детаљно

• о томе шта утиче на кашњење Интернет захтева између клијента и сервера;
• како смањити ово кашњење;
• како дизајнирати, одржавати и надгледати системе толерантне на грешке;
• како постићи резултате за кратко време, а уз минималан ризик за пословање;
• како анализирати резултате и учити из грешака.

Одговори на ова питања нису потребни само онима који раде у великим корпорацијама.

Представљене принципе и технике треба да знају и практикују сви који развијају и подржавају Интернет производе.

Следеће је нарација из перспективе говорника.

Важност брзине интернета

Брзина интернет захтева је директно повезана са пословањем. Узмите у обзир индустрију куповине: Амазон 2009 говорио једа кашњење од 100мс резултира губитком од 1% продаје.

Све је више мобилних уређаја, а затим мобилних сајтова и апликација. Ако се вашој страници учитава дуже од 3 секунде, губите око половине корисника. ВИТХ јул 2018 Гоогле узима у обзир брзину учитавања ваше странице у резултатима претраге: што је страница бржа, то је њена позиција на Гоогле-у виша.

Брзина везе је такође важна у финансијским институцијама где је кашњење критично. У 2015. Хиберниа Нетворкс готов кабл од 400 милиона долара између Њујорка и Лондона за смањење кашњења између градова за 6 мс. Замислите 66 милиона долара за смањење кашњења од 1 мс!

Према истраживање, брзине везе веће од 5 Мбит/с више не утичу директно на брзину учитавања типичне веб странице. Међутим, постоји линеарна веза између кашњења везе и брзине учитавања странице:

Међутим, Нетфлик није типичан производ. Утицај латенције и брзине на корисника је активна област анализе и развоја. Постоји учитавање апликације и избор садржаја који зависе од кашњења, али учитавање статичких елемената и стримовање такође зависе од брзине везе. Анализа и оптимизација кључних фактора који утичу на корисничко искуство је активна област развоја за неколико тимова у Нетфлик-у. Један од циљева је смањење кашњења захтева између Нетфлик уређаја и инфраструктуре облака.

У извештају ћемо се посебно фокусирати на смањење кашњења на примеру Нетфлик инфраструктуре. Хајде да размотримо са практичне тачке гледишта како приступити процесима пројектовања, развоја и рада сложених дистрибуираних система и потрошити време на иновације и резултате, уместо на дијагностиковање оперативних проблема и кварова.

Инсиде Нетфлик

Хиљаде различитих уређаја подржавају Netflix апликације. Развијају их четири различита тима, а сваки од њих креира засебне верзије клијената за... Android, iOS, ТВ и веб прегледачи. Такође вредно радимо на побољшању и персонализацији корисничког искуства. Да бисмо то постигли, паралелно спроводимо стотине А/Б тестова.

Персонализацију подржавају стотине микросервиса у АВС облаку, пружајући персонализоване корисничке податке, слање упита, телеметрију, велике податке и кодирање. Визуелизација саобраћаја изгледа овако:

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

Са леве стране је улазна тачка, а затим се саобраћај распоређује на неколико стотина микросервиса које подржавају различити позадински тимови.

Друга важна компонента наше инфраструктуре је Опен Цоннецт ЦДН, који испоручује статички садржај крајњем кориснику - видео записе, слике, клијентски код итд. ЦДН се налази на прилагођеним серверима (ОЦА - Опен Цоннецт Апплианце). Унутра се налазе низови ССД и ХДД дискова који користе оптимизовани ФрееБСД, са НГИНКС-ом и скупом услуга. Дизајнирамо и оптимизујемо хардверске и софтверске компоненте како би такав ЦДН сервер могао да шаље што више података корисницима.

„Зид“ ових сервера на тачки размене Интернет саобраћаја (Интернет еКсцханге - ИКС) изгледа овако:

Интернет Екцханге пружа могућност провајдерима Интернет услуга и провајдерима садржаја да се „повежу“ једни са другима како би директније размењивали податке на Интернету. Постоји око 70-80 Интернет Екцханге тачака широм света на којима су инсталирани наши сервери, а ми их самостално инсталирамо и одржавамо:

Поред тога, такође пружамо сервере директно интернет провајдерима, које они инсталирају у своју мрежу, побољшавајући локализацију Нетфлик саобраћаја и квалитет стримовања за кориснике:

Скуп АВС сервиса је одговоран за слање видео захтева од клијената до ЦДН сервера, као и за конфигурисање самих сервера – ажурирање садржаја, програмског кода, подешавања итд. За ово друго, такође смо изградили окосну мрежу која повезује сервере у Интернет Екцханге тачкама са АВС-ом. Мрежа окоснице је глобална мрежа оптичких каблова и рутера које можемо дизајнирати и конфигурисати на основу наших потреба.

На Сандвине процењује, наша ЦДН инфраструктура испоручује приближно ⅛ светског интернет саобраћаја током вршних сати и ⅓ саобраћаја у Северној Америци, где је Нетфлик најдуже присутан. Импресивни бројеви, али за мене једно од најневероватнијих достигнућа је то што цео ЦДН систем развија и одржава тим од мање од 150 људи.

У почетку је инфраструктура ЦДН-а била дизајнирана за испоруку видео података. Међутим, временом смо схватили да можемо да га користимо и за оптимизацију динамичких захтева клијената у АВС облаку.

О убрзању Интернета

Данас Нетфлик има 3 АВС региона, а кашњење захтева ка облаку зависиће од тога колико је корисник удаљен од најближег региона. Истовремено, имамо много ЦДН сервера који се користе за испоруку статичког садржаја. Постоји ли начин да се користи овај оквир за убрзавање динамичких упита? Међутим, нажалост, ове захтеве је немогуће кеширати - АПИ-ји су персонализовани и сваки резултат је јединствен.

Хајде да направимо прокси на ЦДН серверу и почнемо да шаљемо саобраћај преко њега. Хоће ли бити брже?

Материјал

Подсетимо се како функционишу мрежни протоколи. Данас већина саобраћаја на Интернету користи ХТТП, што зависи од протокола нижег слоја ТЦП и ТЛС. Да би се клијент повезао са сервером, врши руковање, а да би успоставио безбедну везу, клијент треба да размени поруке са сервером три пута и најмање још једном за пренос података. Са кашњењем по повратном путу (РТТ) од 100 мс, требало би нам 400 мс да примимо први бит података:

Ако сертификате поставимо на ЦДН сервер, онда се време руковања између клијента и сервера може значајно смањити ако је ЦДН ближи. Претпоставимо да је кашњење до ЦДН сервера 30 мс. Тада ће бити потребно 220 мс да примите први бит:

Али предности се ту не завршавају. Једном када је веза успостављена, ТЦП повећава прозор загушења (количина информација коју може паралелно да пренесе преко те везе). Ако се изгуби пакет података, онда класичне имплементације ТЦП протокола (попут ТЦП Нев Рено) смањују отворени „прозор“ за половину. Раст прозора загушења и брзина његовог опоравка од губитка поново зависи од кашњења (РТТ) до сервера. Ако ова веза иде само до ЦДН сервера, овај опоравак ће бити бржи. Истовремено, губитак пакета је стандардна појава, посебно за бежичне мреже.

Интернет пропусни опсег може бити смањен, посебно у вршним сатима, због саобраћаја корисника, што може довести до саобраћајних гужви. Међутим, на Интернету не постоји начин да се неким захтевима да приоритет у односу на друге. На пример, дајте приоритет малим захтевима који су осетљиви на кашњење у односу на „тешке“ токове података који учитавају мрежу. Међутим, у нашем случају, поседовање сопствене мреже окосница нам омогућава да то урадимо на делу путање захтева - између ЦДН-а и облака, и можемо је у потпуности конфигурисати. Можете се побринути да мали пакети и пакети осетљиви на кашњење имају приоритет, а велики токови података иду мало касније. Што је ЦДН ближи клијенту, то је већа ефикасност.

Протоколи на нивоу апликације (ОСИ ниво 7) такође имају утицај на кашњење. Нови протоколи као што је ХТТП/2 оптимизују перформансе паралелних захтева. Међутим, имамо Нетфлик клијенте са старијим уређајима који не подржавају нове протоколе. Не могу се сви клијенти ажурирати или оптимално конфигурисати. Истовремено, између ЦДН проксија и облака постоји потпуна контрола и могућност коришћења нових, оптималних протокола и подешавања. Неефикасни део са старим протоколима ће радити само између клијента и ЦДН сервера. Штавише, можемо да правимо мултиплекс захтеве на већ успостављеној вези између ЦДН-а и облака, побољшавајући коришћење везе на ТЦП нивоу:

Ми меримо

Упркос чињеници да теорија обећава побољшања, не журимо одмах да покренемо систем у производњи. Уместо тога, прво морамо доказати да ће идеја функционисати у пракси. Да бисте то урадили, морате одговорити на неколико питања:

• Брзина: да ли ће прокси бити бржи?
• Поузданост: Хоће ли се чешће ломити?
• Сложеност: како се интегрисати са апликацијама?
• Коштати: Колико кошта постављање додатне инфраструктуре?

Хајде да детаљно размотримо наш приступ процени прве тачке. Остало се решава на сличан начин.

Да бисмо анализирали брзину захтева, желимо да добијемо податке за све кориснике, без трошења много времена на развој и без прекида производње. Постоји неколико приступа за ово:

1. РУМ, или пасивно мерење захтева. Меримо време извршења тренутних захтева корисника и обезбеђујемо потпуну покривеност корисника. Недостатак је што сигнал није баш стабилан због многих фактора, на пример, због различитих величина захтева, времена обраде на серверу и клијенту. Поред тога, не можете тестирати нову конфигурацију без ефекта у производњи.
2. Лабораторијски тестови. Специјални сервери и инфраструктура који симулирају клијенте. Уз њихову помоћ вршимо неопходна испитивања. На овај начин добијамо потпуну контролу над резултатима мерења и јасан сигнал. Али не постоји потпуна покривеност уређаја и локација корисника (нарочито са сервисом широм света и подршком за хиљаде модела уређаја).

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

Наш тим је пронашао решење. Написали смо мали део кода - узорак - који смо уградили у нашу апликацију. Сонде нам омогућавају да вршимо потпуно контролисане мрежне тестове са наших уређаја. ради овако:

1. Убрзо након учитавања апликације и завршетка почетне активности, покрећемо наше сонде.
2. Клијент шаље захтев серверу и добија „рецепт“ за тест. Рецепт је листа УРЛ адреса до којих треба да се упути ХТТП(с) захтев. Поред тога, рецепт конфигурише параметре захтева: кашњења између захтева, количину тражених података, ХТТП(с) заглавља итд. Истовремено, можемо паралелно да тестирамо неколико различитих рецепата - када захтевамо конфигурацију, насумично одређујемо који рецепт да издамо.
3. Време покретања сонде се бира тако да не дође у сукоб са активним коришћењем мрежних ресурса на клијенту. У суштини, време се бира када клијент није активан.
4. Након пријема рецепта, клијент паралелно поставља захтеве за сваки од УРЛ-ова. Захтев на сваку од адреса може се поновити – тзв. „импулси“. На првом импулсу меримо колико је времена било потребно за успостављање везе и преузимање података. На другом импулсу меримо време потребно за учитавање података преко већ успостављене везе. Пре трећег можемо подесити кашњење и измерити брзину успостављања реконекције итд.

   Током теста меримо све параметре које уређај може да добије:

   • ДНС време захтева;
   • Време подешавања ТЦП везе;
   • време подешавања ТЛС везе;
   • време пријема првог бајта података;
   • укупно време учитавања;
   • статусни код резултата.
5. Након што су сви импулси завршени, узорак учитава сва мерења за анализу.

Кључне тачке су минимална зависност од логике на клијенту, обрада података на серверу и мерење паралелних захтева. Тако смо у могућности да изолујемо и тестирамо утицај различитих фактора који утичу на перформансе упита, да их варирамо у оквиру једног рецепта и добијемо резултате од стварних клијената.

Ова инфраструктура се показала корисном за више од анализе перформанси упита. Тренутно имамо 14 активних рецепата, више од 6000 узорака у секунди, примамо податке из свих крајева земље и пуну покривеност уређаја. Ако би Нетфлик купио сличну услугу од треће стране, то би коштало милионе долара годишње, уз много лошију покривеност.

Теорија испитивања у пракси: прототип

Са таквим системом, могли смо да проценимо ефикасност ЦДН проксија на захтев латенције. Сада вам треба:

• креирати прототип проксија;
• поставите прототип на ЦДН;
• одредити како да усмерите клијенте на проки на одређеном ЦДН серверу;
• Упоредите перформансе са захтевима у АВС-у без проксија.

Задатак је да се што пре процени ефикасност предложеног решења. Изабрали смо Го да имплементирамо прототип због доступности добрих мрежних библиотека. На сваком ЦДН серверу смо инсталирали прототип проксија као статичку бинарну датотеку да бисмо минимизирали зависности и поједноставили интеграцију. У почетној имплементацији користили смо стандардне компоненте колико год је то било могуће и мање модификације за прикупљање ХТТП/2 везе и мултиплексирање захтева.

Да бисмо балансирали између АВС региона, користили смо географску ДНС базу података, исту ону која се користила за балансирање клијената. Да бисмо изабрали ЦДН сервер за клијента, користимо ТЦП Аницаст за сервере у Интернет Екцханге (ИКС). У овој опцији користимо једну ИП адресу за све ЦДН сервере, а клијент ће бити усмерен на ЦДН сервер са најмањим бројем ИП скокова. У ЦДН серверима инсталираним од стране Интернет провајдера (ИСП), немамо контролу над рутером да бисмо конфигурисали ТЦП Аницаст, па користимо иста логика, који клијенте усмерава ка Интернет провајдерима за видео стриминг.

Дакле, имамо три типа путања захтева: до облака преко отвореног Интернета, преко ЦДН сервера у ИКС или преко ЦДН сервера који се налази код Интернет провајдера. Наш циљ је да разумемо који је начин бољи и која је корист од проксија у односу на то како се захтеви шаљу у продукцију. Да бисмо то урадили, користимо систем узорковања на следећи начин:

Сваки од путева постаје засебна мета, а ми гледамо колико смо добили. За анализу, комбинујемо резултате проксија у једну групу (изаберемо најбоље време између ИКС и ИСП проксија) и упоређујемо их са временом захтева ка облаку без проксија:

Као што видите, резултати су били мешовити - у већини случајева прокси даје добру брзину, али постоји и довољан број клијената за које ће се ситуација значајно погоршати.

Као резултат тога, урадили смо неколико важних ствари:

1. Процењивали смо очекиване перформансе захтева клијената ка облаку преко ЦДН проксија.
2. Добијали смо податке од стварних клијената, са свих врста уређаја.
3. Схватили смо да теорија није 100% потврђена и да почетна понуда са ЦДН проксијем неће радити за нас.
4. Нисмо ризиковали - нисмо мењали конфигурације производње за клијенте.
5. Ништа није покварено.

Прототип 2.0

Дакле, вратите се на таблу за цртање и поновите поступак изнова.

Идеја је да уместо коришћења 100% проксија одредимо најбржи пут за сваког клијента, и тамо ћемо слати захтеве – односно радићемо оно што се зове управљање клијентом.

Како ово спровести? Не можемо да користимо логику на страни сервера, јер... Циљ је да се повежете са овим сервером. Мора постојати неки начин да се то уради на клијенту. И идеално, урадите ово са минималном количином сложене логике, како не бисте решили питање интеграције са великим бројем клијентских платформи.

Одговор је да користите ДНС. У нашем случају имамо сопствену ДНС инфраструктуру и можемо да поставимо доменску зону за коју ће наши сервери бити ауторитарни. ради овако:

1. Клијент поставља захтев ДНС серверу користећи хост, на пример апи.нетфлик.ком.
2. Захтев стиже на наш ДНС сервер
3. ДНС сервер зна која је путања најбржа за овог клијента и издаје одговарајућу ИП адресу.

Решење има додатну сложеност: ауторитарни ДНС провајдери не виде ИП адресу клијента и могу само да прочитају ИП адресу рекурзивног разрешивача који клијент користи.

Као резултат тога, наш ауторитарни разрешивач мора да донесе одлуку не за појединачног клијента, већ за групу клијената на основу рекурзивног разрешивача.

Да бисмо решили, користимо исте узорке, агрегирамо резултате мерења од клијената за сваки од рекурзивних разређивача и одлучујемо где да пошаљемо ову групу њих – прокси преко ИКС користећи ТЦП Аницаст, преко проксија ИСП-а или директно у облак.

Добијамо следећи систем:

Добијени модел управљања ДНС-ом вам омогућава да усмеравате клијенте на основу историјских запажања брзине конекција од клијената до облака.

Опет, питање је колико ће овај приступ ефикасно функционисати? Да бисмо одговорили, поново користимо наш систем сонде. Стога, конфигуришемо конфигурацију презентера, где један од циљева прати правац од ДНС управљања, други иде директно у облак (тренутна производња).

Као резултат, упоређујемо резултате и добијамо процену ефикасности:

Као резултат тога, научили смо неколико важних ствари:

1. Проценили смо очекивани учинак захтева клијената ка облаку користећи ДНС Стееринг.
2. Добијали смо податке од стварних клијената, са свих врста уређаја.
3. Ефикасност предложене идеје је доказана.
4. Нисмо ризиковали - нисмо мењали конфигурације производње за клијенте.
5. Ништа није покварено.

Сада о тешком делу - покрећемо га у производњу

Лакши део је сада завршен - постоји радни прототип. Сада је тежи део лансирање решења за сав Нетфлик-ов саобраћај, које се примењује на 150 милиона корисника, хиљаде уређаја, стотине микросервиса и производ и инфраструктура која се стално мења. Нетфлик сервери примају милионе захтева у секунди и лако је прекинути услугу непажљивом акцијом. Истовремено, желимо да динамички усмеравамо саобраћај кроз хиљаде ЦДН сервера на Интернету, где се нешто мења и ломи стално иу најнеповољнијем тренутку.

Уз све ово, тим има 3 инжењера одговорна за развој, имплементацију и пуну подршку система.

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

Како наставити развој и не трошити све своје време на подршку? Наш приступ се заснива на 3 принципа:

1. Смањујемо потенцијалну скалу кварова (радијус експлозије).
2. Спремамо се за изненађења - очекујемо да ће се нешто покварити, упркос тестирању и личном искуству.
3. Грациозна деградација - ако нешто не ради како треба, требало би да се поправи аутоматски, чак и ако не на најефикаснији начин.

Показало се да у нашем случају оваквим приступом проблему можемо пронаћи једноставно и ефикасно решење и значајно поједноставити системску подршку. Схватили смо да можемо да додамо мали део кода клијенту и надгледамо грешке мрежног захтева узроковане проблемима са везом. У случају мрежних грешака, враћамо се директно на облак. Ово решење не захтева значајне напоре тимова клијената, али у великој мери смањује ризик од неочекиваних кварова и изненађења за нас.

Наравно, упркос резерви, ми ипак следимо јасну дисциплину током развоја:

1. Тест узорка.
2. А/Б тестирање или Канаринци.
3. Прогресивно увођење.

Са узорцима је описан приступ - промене се прво тестирају по прилагођеном рецепту.

За тестирање канаринаца, потребно је да добијемо упоредиве парове сервера на којима можемо да упоредимо како систем функционише пре и после промена. Да бисмо то урадили, са наших бројних ЦДН локација, бирамо парове сервера који примају упоредив саобраћај:

Затим инсталирамо буилд са изменама на Цанари сервер. Да бисмо проценили резултате, покрећемо систем који пореди приближно 100-150 метрика са узорком контролних сервера:

Ако је тестирање канаринца успешно, онда га ослобађамо постепено, у таласима. Не ажурирамо сервере на сваком сајту у исто време – губитак читавог сајта због проблема има значајнији утицај на услугу за кориснике од губитка истог броја сервера на различитим локацијама.

Генерално, ефикасност и сигурност овог приступа зависе од количине и квалитета прикупљених метрика. За наш систем убрзања упита прикупљамо метрику од свих могућих компоненти:

• од клијената - број сесија и захтева, резервне стопе;
• проки - статистика о броју и времену захтева;
• ДНС - број и резултати захтева;
• ивица облака - број и време за обраду захтева у облаку.

Све ово се скупља у један цевовод и, у зависности од потреба, одлучујемо које метрике ћемо послати у аналитику у реалном времену, а које у Еластицсеарцх или Биг Дата за детаљнију дијагностику.

Пратимо

У нашем случају, ми правимо промене на критичном путу захтева између клијента и сервера. Истовремено, број различитих компоненти на клијенту, на серверу и на путу кроз Интернет је огроман. Промене на клијенту и серверу се дешавају константно – током рада десетина тимова и природних промена у екосистему. У средини смо – када дијагностикујемо проблеме, постоји велика шанса да ћемо бити укључени. Стога, морамо јасно да разумемо како да дефинишемо, прикупимо и анализирамо метрику да бисмо брзо изоловали проблеме.

У идеалном случају, пун приступ свим врстама метрика и филтера у реалном времену. Али има много метрика, па се поставља питање трошкова. У нашем случају, ми одвајамо метрике и развојне алате на следећи начин:

За откривање и тријажу проблема користимо сопствени систем отвореног кода у реалном времену Атлас и Лумен - за визуелизацију. Он складишти агрегиране метрике у меморији, поуздан је и интегрише се са системом за узбуњивање. За локализацију и дијагностику имамо приступ евиденцијама са Еластицсеарцх-а и Кибана. За статистичку анализу и моделирање користимо велике податке и визуелизацију у Таблеау-у.

Чини се да је са овим приступом веома тешко радити. Међутим, хијерархијским организовањем метрика и алата, можемо брзо анализирати проблем, одредити врсту проблема, а затим детаљне метрике. Генерално, трошимо око 1-2 минута да идентификујемо извор квара. После овога радимо са одређеним тимом на дијагностици - од десетина минута до неколико сати.

Чак и ако се дијагноза брзо обави, не желимо да се ово дешава често. У идеалном случају, примићемо критично упозорење само када постоји значајан утицај на услугу. За наш систем убрзања упита имамо само 2 упозорења која ће обавестити:

• Цлиент Фаллбацк проценат - процена понашања купаца;
• проценат Грешке сонде – подаци о стабилности мрежних компоненти.

Ова критична упозорења прате да ли систем ради за већину корисника. Гледамо колико клијената је користило резервни део ако нису могли да добију убрзање захтева. У просеку имамо мање од 1 критичног упозорења недељно, иако се у систему дешава много промена. Зашто нам је ово довољно?

1. Постоји резервни клијент ако наш прокси не ради.
2. Постоји аутоматски систем управљања који реагује на проблеме.

Више детаља о последњем. Наш пробни систем, као и систем за аутоматско одређивање оптималне путање за захтеве од клијента до облака, омогућава нам да се аутоматски носимо са неким проблемима.

Вратимо се нашем узорку конфигурације и 3 категорије путања. Поред времена учитавања, можемо погледати и саму испоруку. Ако није било могуће учитати податке, онда гледајући резултате на различитим путањама можемо утврдити где и шта је покварено, и да ли то можемо аутоматски поправити променом путање захтева.

Примери:

Овај процес се може аутоматизовати. Укључите га у систем управљања. И научите га да реагује на проблеме са перформансама и поузданошћу. Ако нешто почне да се ломи, реагујте ако постоји боља опција. У исто време, тренутна реакција није критична, захваљујући резервним клијентима.

Дакле, принципи системске подршке могу се формулисати на следећи начин:

• смањење обима кварова;
• прикупљање метрике;
• Аутоматски поправљамо кварове ако можемо;
• ако не може, обавестићемо вас;
• Радимо на контролним таблама и тријажним алатима за брз одговор.

Научене лекције

За писање прототипа није потребно много времена. У нашем случају, био је спреман након 4 месеца. Са њим смо добили нове метрике, а 10 месеци након почетка развоја добили смо први производни саобраћај. Тада је почео заморан и веома тежак посао: постепено производити и скалирати систем, мигрирати главни саобраћај и учити из грешака. Међутим, овај ефикасан процес неће бити линеаран – упркос свим напорима, све се не може предвидети. Много је ефикасније брзо поновити и одговорити на нове податке.

На основу нашег искуства, можемо препоручити следеће:

1. Не верујте својој интуицији.

   Интуиција нас је стално изневерила, упркос огромном искуству чланова нашег тима. На пример, погрешно смо предвидели очекивано убрзање коришћења ЦДН проксија или понашање ТЦП Аницаст-а.

2. Добијте податке из производње.

   Важно је да добијете приступ барем малој количини производних података што је пре могуће. Скоро је немогуће добити број јединствених случајева, конфигурација и подешавања у лабораторијским условима. Брз приступ резултатима ће вам омогућити да брзо сазнате о потенцијалним проблемима и узмете их у обзир у архитектури система.

3. Не следите туђе савете и резултате – прикупљајте своје податке.

   Придржавајте се принципа за прикупљање и анализу података, али не прихватајте слепо резултате и изјаве других људи. Само ви можете знати шта тачно функционише за ваше кориснике. Ваши системи и ваши клијенти могу се значајно разликовати од других компанија. На срећу, алати за анализу су сада доступни и лаки за употребу. Резултати које добијете можда нису оно што Нетфлик, Фацебоок, Акамаи и друге компаније тврде. У нашем случају, перформансе ТЛС-а, ХТТП2 или статистике на ДНС захтевима се разликују од резултата Фејсбука, Убера, Акамаија – јер имамо различите уређаје, клијенте и токове података.

4. Немојте непотребно пратити модне трендове и проценити ефикасност.

   Почните једноставно. Боље је направити једноставан радни систем за кратко време него потрошити огромну количину времена на развој компоненти које вам нису потребне. Решите важне задатке и проблеме на основу ваших мерења и резултата.

5. Припремите се за нове апликације.

   Као што је тешко предвидети све проблеме, тешко је унапред предвидети предности и примене. Узмите пример од стартапова - њихову способност да се прилагоде условима купаца. У вашем случају можете открити нове проблеме и њихова решења. У нашем пројекту смо поставили циљ да смањимо кашњење захтева. Међутим, током анализе и дискусија, схватили смо да можемо користити и прокси сервере:

   • да уравнотежите саобраћај у АВС регионима и смањите трошкове;
   • за моделирање стабилности ЦДН-а;
   • да конфигуришете ДНС;
   • да конфигуришете ТЛС/ТЦП.

Закључак

У извештају сам описао како Нетфлик решава проблем убрзавања Интернет захтева између клијената и облака. Како прикупљамо податке користећи систем узорковања о клијентима и користимо прикупљене историјске податке за усмеравање производних захтева од клијената најбржим путем на Интернету. Како користимо принципе мрежних протокола, нашу ЦДН инфраструктуру, окосну мрежу и ДНС сервере да бисмо постигли овај задатак.

Међутим, наше решење је само пример како смо у Нетфлик-у имплементирали такав систем. Оно што је радило за нас. Примењени део мог извештаја за вас су принципи развоја и подршке које следимо и постижемо добре резултате.

Наше решење проблема вам можда неће одговарати. Међутим, теорија и принципи дизајна остају, чак и ако немате сопствену ЦДН инфраструктуру, или ако се она значајно разликује од наше.

Важност брзине пословних захтева такође остаје важна. Чак и за једноставну услугу, морате направити избор: између провајдера у облаку, локације сервера, ЦДН и ДНС провајдера. Ваш избор ће утицати на ефикасност интернет упита за ваше клијенте. И важно је да измерите и разумете овај утицај.

Почните са једноставним решењима, водите рачуна о томе како мењате производ. Учите како идете и побољшајте систем на основу података ваших клијената, ваше инфраструктуре и вашег пословања. Размислите о могућности неочекиваних кварова током процеса пројектовања. А онда можете да убрзате свој развојни процес, побољшате ефикасност решења, избегнете непотребно оптерећење подршке и мирно спавате.

Ове године конференција ће се одржати од 6. до 10. јула у онлајн формату. Можете поставити питања једном од очева ДевОпс-а, ​​самом Џону Виллису!

Извор: ввв.хабр.цом