Netflix – лідэр рынку інтэрнэт-тэлебачання – кампанія, якая стварыла і актыўна развівае гэты сегмент. Netflix вядомы не толькі шырокім каталогам кіно і серыялаў, даступных з амаль любога кутка планеты і любой прылады з дысплеем, але і надзейнай інфраструктурай і ўнікальнай інжынернай культурай.
Наглядны прыклад Netflix падыходу да распрацоўкі і падтрымкі складаных сістэм на DevOops 2019 прадставіў - дырэктар па распрацоўцы ў Netflix. Выпускнік факультэта ВМК ННДУ ім. Лабачэўскага, Сяргей адзін з першых інжынераў у Open Connect – CDN каманды ў Netflix. Ён пабудаваў сістэмы маніторынгу і аналізу відэададзеных, запусціў папулярны сэрвіс для адзнакі хуткасці Інтэрнэт-злучэння FAST.com і апошнія некалькі гадоў працуе над аптымізацыяй Інтэрнэт запытаў, каб Netflix прыкладанне працавала як мага хутчэй для карыстачоў.
Даклад атрымаў найлепшыя водгукі ад удзельнікаў канферэнцыі, і мы падрыхтавалі для вас тэкставую версію.
У дакладзе Сяргей падрабязна расказаў
- пра тое, што ўплывае на затрымку інтэрнэт-запытаў паміж кліентам і серверам;
- як гэтую затрымку паменшыць;
- як праектаваць, падтрымліваць і маніторыць устойлівыя да памылак сістэмы;
- як дасягаць выніку ў сціслыя тэрміны, і мінімальнай рызыкай для бізнэсу;
- як аналізаваць вынікі і вучыцца на памылках.
Адказы на гэтыя пытанні патрэбны не толькі тым, хто працуе ў буйных карпарацыях.
Прадстаўленыя прынцыпы і тэхнікі павінен ведаць і практыкаваць кожны, хто распрацоўвае і падтрымлівае інтэрнэт-прадукты.
Далей - апавяданне ад асобы спікера.
Важнасць хуткасці інтэрнэту
Хуткасць інтэрнэт-запытаў напрамую звязана з бізнесам. Разгледзім сферу шопінгу: кампанія Amazon у 2009 году , Што затрымка ў 100 мс прыводзіць да страты 1% продажаў.
Усё больш становіцца мабільных прылад, а следам за імі мабільных сайтаў і дадаткаў. Калі ваша старонка загружаецца даўжэй за 3 секунд, вы губляеце каля паловы карыстальнікаў. З 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 і Encoding. Візуалізацыя трафіку выглядае так:
Злева знаходзіцца entry point, а затым трафік размяркоўваецца паміж некалькімі сотнямі мікрасэрвісаў, якія падтрымліваюцца рознымі backend камандамі.
Яшчэ адзін важны кампанент нашай інфраструктуры - гэта 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 network, якая злучае сэрвэра ў Internet Exchange кропках з AWS. Backbone network уяўляе з сябе глабальную сетку з оптавалакновых кабеляў і роўтэраў, якія мы можам праектаваць і канфігураваць зыходзячы з нашых патрэб.
Па , наша 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-сервера, гэтае аднаўленне будзе хутчэй. Пры гэтым страта пакетаў - стандартная з'ява, асабліва для бесправадных сетак.
Прапускная здольнасць інтэрнэту можа змяншацца, асабліва ў пікавыя гадзіны з-за трафіку ад карыстачоў, што можа прыводзіць да «коркаў». Пры гэтым у інтэрнэце няма спосабу даць прыярытэт адным запытам у адносінах да іншых. Напрыклад, даць прыярытэт маленькім па аб'ёме і адчувальным да затрымкі запытам па стаўленні да "цяжкіх" струменяў дадзеных, якія загружаюць сетку. Аднак у нашым выпадку наяўнасць уласнай backbone сеткі дазваляе гэта зрабіць на часткі шляху запыту - паміж CDN і воблакам, і мы яе можам цалкам канфігураваць. Можна зрабіць так, каб невялікія і залежныя ад затрымкі пакеты прыарытызаваць, а вялікія патокі дадзеных пайшлі крыху пазней. Чым бліжэй CDN да кліента – тым большая эфектыўнасць.
Яшчэ ўплыў на затрымку аказваюць пратаколы application узроўня (OSI Level 7). Новыя пратаколы, такія як HTTP/2, дазваляюць аптымізаваць прадукцыйнасць паралельных запытаў. Аднак у нас ёсць Netflix ёсць кліенты са старымі прыладамі, якія не падтрымліваюць новыя пратаколы. Не ўсе кліенты можна абнавіць, ці аптымальна наладзіць. Пры гэтым паміж CDN проксі і воблакам - поўны кантроль і магчымасць выкарыстоўваць новыя, аптымальныя пратаколы і налады. Неэфектыўная частка са старымі пратаколамі будзе дзейнічаць толькі паміж кліентам і CDN-серверам. Больш таго, мы можам рабіць мультыплекс запытаў на ўжо ўсталяванае злучэнне паміж CDN і воблакам, паляпшаючы ўтылізацыю злучэння на TCP узроўні:
Вымяраем
Нягледзячы на тое, што тэорыя абяцае паляпшэнні, мы не кідаемся адразу запускаць сістэму ў production. Замест гэтага мы павінны спачатку даказаць, што ідэя спрацуе на практыцы. Для гэтага трэба адказаць на некалькі пытанняў:
- Хуткасць: ці будзе проксі хутчэй?
- Надзейнасць: ці будзе часцей ламацца?
- Складанасць: як інтэграваць з праграмамі?
- Кошт: колькі каштуе разгортванне дадатковай інфраструктуры?
Разгледзім падрабязна наш падыход да адзнакі першага пункта. Астатнія разбіраюцца падобнай выявай.
Для аналізу хуткасці запытаў мы жадаем атрымаць дадзеныя для ўсіх карыстачоў, не марнаваць шмат часу на распрацоўку і не зламаць production. Для гэтага ёсць некалькі падыходаў:
- RUM, ці пасіўнае вымярэнне запытаў. Вымяраем час выканання бягучых запытаў ад карыстальнікаў і забяспечваем поўнае пакрыццё карыстальнікаў. Недахоп - не вельмі стабільны сігнал з-за мноства фактараў, напрыклад, з-за розных памераў запытаў, часу апрацоўкі на серверы і кліенце. Акрамя гэтага, нельга пратэсціраваць новую канфігурацыю без эфекту на production.
- Лабараторныя тэсты. Спецыяльныя сервера і інфраструктура, якія імітуюць кліентаў. З іх дапамогай праводзім неабходныя тэсты. Так мы атрымліваем поўны кантроль над вынікамі вымярэнняў і дакладны сігнал. Але няма поўнага пакрыцця прылад і размяшчэнні карыстальнікаў (асабліва з сэрвісам па ўсім свеце і падтрымкай тысяч мадэляў прылад).
Як можна аб'яднаць перавагі абодвух метадаў?
Наша каманда знайшла рашэнне. Мы напісалі невялікі кавалачак кода - пробу - які ўбудавалі ў наша дадатак. Пробы дазваляюць нам рабіць цалкам кантраляваныя сеткавыя тэсты з нашых прылад. Працуе гэта наступным чынам:
- Неўзабаве пасля загрузкі прыкладання і завяршэння пачатковай актыўнасці мы запускае нашы пробы.
- Кліент робіць запыт на сервер і атрымлівае "рэцэпт" цеста. Рэцэпт уяўляе сабой спіс з URL-адрасоў, да якіх трэба зрабіць HTTP(s) запыт. Апроч гэтага рэцэпт канфігуруе параметры запытаў: затрымкі паміж запытамі, аб'ём запытаных дадзеных, HTTP(s) headers і г.д. Пры гэтым мы можам паралельна тэставаць некалькі розных рэцэптаў - пры запыце на канфігурацыю мы выпадковым чынам вызначаецца, які рэцэпт выдаць.
- Час запуску пробы выбіраецца так, каб не канфліктаваць з актыўным выкарыстаннем сеткавых рэсурсаў на кліенце. Па сутнасці, выбіраецца час, калі кліент не актыўны.
- Пасля атрымання рэцэпту кліент робіць запыты на кожны з URL-адрасоў, паралельна. Запыт на кожны з адрасоў можа паўтарацца - т.зв. "пульсы". На першым пульсе мы вымяраем, колькі часу запатрабавалася для ўсталёўкі злучэння і запампоўкі дадзеных. На другім пульсе мы вымяраем час загрузкі дадзеных па ўжо ўсталяваным злучэнні. Перад трэцім мы можам паставіць затрымку і вымераць хуткасць устанаўлення паўторнага злучэння і да т.п.
Падчас тэсту мы вымяраем усе параметры, якія можа атрымаць прыладу:
- час DNS запыту;
- час усталёўкі злучэння па TCP;
- час усталёўкі злучэння па TLS;
- час атрымання першага байта даных;
- поўнае час загрузкі;
- статус код выніку.
- Пасля заканчэння ўсіх пульсаў проба загружае вынікі ўсіх вымярэнняў для аналітыкі.
Ключавымі момантамі з'яўляюцца мінімальная залежнасць ад логікі на кліенце, апрацоўкі даных на серверы і вымярэнні паралельных запытаў. Такім чынам, мы атрымліваем магчымасць ізаляваць і тэсціраваць уплыў розных фактараў, якія ўплываюць на прадукцыйнасць запытаў, вар'іраваць іх у межах аднаго рэцэпту, і атрымліваць вынікі з рэальных кліентаў.
Такая інфраструктура аказалася карыснай не толькі для аналізу прадукцыйнасці запытаў. У дадзеных момант у нас 14 актыўных рэцэптаў, больш за 6000 проб у секунду, якія атрымліваюць дадзеныя з усіх куткоў зямлі і поўным пакрыццём прылад. Калі б Netflix купляла б падобны сэрвіс у іншых кампаній, то ён каштаваў бы мільёны даляраў у год, пры нашмат горшым пакрыцці.
Правяраем тэорыю на практыцы: прататып
З такой сістэмай мы атрымалі магчымасць ацаніць эфектыўнасць CDN проксі на затрымку запытаў. Цяпер трэба:
- стварыць прататып проксі;
- размясціць прататып на CDN;
- вызначыць, як накіроўваць кліентаў да проксі на пэўным CDN серверы;
- параўнаць прадукцыйнасць з запытамі ў AWS без проксі.
Задача - як мага хутчэй ацаніць эфектыўнасць прапанаванага рашэння. Для рэалізацыі прататыпа мы абралі Go, дзякуючы наяўнасці добрых сеткавых бібліятэк. На кожным CDN-серверы мы ўсталявалі прататып проксі як static binary, каб мінімізаваць залежнасці і спрасціць інтэграцыю. У пачатковай рэалізацыі мы па максімуме выкарыстоўвалі стандартныя кампаненты і невялікія мадыфікацыі для 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 проксі.
- Атрымалі дадзеныя ад сапраўдных кліентаў, з усіх тыпаў прылад.
- Зразумелі, што тэорыя не пацвердзілася на 100% і пачатковая прапанова з CDN проксі для нас не спрацуе.
- Не рызыкавалі - не мянялі production канфігурацыі для кліентаў.
- Нічога не зламалі.
Прататып 2.0
Такім чынам, вяртаемся да чарцёжнай дошкі і паўтараем працэс нанова.
Ідэя - замест 100% проксі будзем для кожнага кліента вызначым самы хуткі шлях, і будзем туды накіроўваць запыты - гэта значыць будзем рабіць тое, што называецца client steering.
Як гэта рэалізаваць? Мы не можам выкарыстоўваць логіку на серверным баку, т.я. мэта - да гэтага сервера падлучыцца. Трэба нейкім чынам рабіць гэта на кліенце. І ідэальна, зрабіць гэта з мінімальнай колькасцю складанай логікі, каб не вырашаць пытанне інтэграцыі з вялікай колькасцю кліенцкіх платформаў.
Адказ - выкарыстанне DNS. У нашым выпадку ў нас ёсць свая DNS інфраструктура, і мы можам наладзіць даменную зону, для якой нашы серверы будуць аўтарытарнымі. Працуе гэта так:
- Кліент робіць запыт да DNS-сервера выкарыстоўваючы хост, напрыклад api.netflix.xom.
- Запыт паступае на наш DNS-сервер
- DNS-сервер ведае які шлях для гэтага кліента самы хуткі і выдае які адпавядае ip адрас.
У рашэнні ёсць дадатковая складанасць: аўтарытарныя DNS-правайдэры не бачаць IP-адрас кліента і могуць лічыць толькі IP-адрас рэкурсіўнага resolver, якім карыстаецца кліент.
У выніку, наш аўтарытарны resolver павінен прымаць рашэнне не для асобнага кліента, а для групы кліентаў на аснове рэкурсіўнага resolver.
Для рашэння мы выкарыстоўваем тыя ж пробы, агрэгуем вынікі вымярэнняў ад кліентаў па кожным з рэкурсіўных resolver і вырашаем, куды іх гэтую групу накіраваць - проксі праз IX з дапамогай TCP Anycast, праз ISP проксі або напрамую ў воблака.
Мы атрымліваем такую сістэму:
Атрыманая мадэль DNS steering дазваляе накіроўваць кліентаў на аснове гістарычных назіранняў аб хуткасці злучэнняў ад кліентаў да аблокі.
Зноў жа, пытанне - наколькі эфектыўна такі падыход будзе працаваць? Для адказу мы зноў выкарыстоўваем нашу сістэму спроб. Таму мы наладжваем канфігурацыю рэцэнта, дзе адзін з таргетаў варта кірунку ад DNS steering, іншы - ідзе напроста ў воблака (бягучы production).
У выніку параўноўваем вынікі і атрымліваем адзнаку эфектыўнасці:
У выніку мы даведаліся некалькі важных рэчаў:
- Ацанілі чаканую прадукцыйнасць запытаў ад кліентаў у воблака з выкарыстаннем DNS Steering.
- Атрымалі дадзеныя ад сапраўдных кліентаў, з усіх тыпаў прылад.
- Даказалі эфектыўнасць прапанаванай ідэі.
- Не рызыкавалі - не мянялі production канфігурацыі для кліентаў.
- Нічога не зламалі.
Зараз аб складаным - запускаем у production
Самае лёгкае зараз ззаду - ёсць які працуе прататып. Цяпер складаная частка – запусціць рашэнне для ўсяго Netflix трафіку, разгарнуць на 150 млн карыстальнікаў, тысячы прылад, сотні мікрасэрвісаў і пастаянна змяняюцца прадукт і інфраструктура. На серверы Netflix прыходзяць мільёны запытаў у секунду, і можна лёгка зламаць сэрвіс неасцярожным дзеяннем. Пры гэтым мы жадаем дынамічна накіроўваць трафік праз тысячы CDN сервераў, у інтэрнэце, дзе нешта змяняецца і ламаецца стала і ў самы непадыходны момант.
І пры гэтым, у камандзе – тры інжынера, адказныя за распрацоўку, разгортванне і поўную падтрымку сістэмы.
Таму далей будзем казаць аб спакойным і здаровым сне.
Як працягваць распрацоўку, а не марнаваць увесь час на падтрымку? У аснове нашага падыходу ляжаць 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 сістэму з адчыненым зыходным кодам и - Для візуалізацыі. Яна захоўвае агрэгаваныя метрыкі ў памяці, надзейная і інтэгруецца з alerting system. Для лакалізацыі і дыягностыкі мы маем доступ да логаў з Elasticsearch і Kibana. Для статыстычнага аналізу і мадэлявання - задзейнічаем big data і візуалізацыю ў Tableau.
Падаецца, што з такім падыходам вельмі складана працаваць. Аднак пры іерархічнай арганізацыі метрык і інструментаў, мы можам хутка прааналізаваць праблему, вызначыць тып праблемы і затым паглыбіцца ў дэталёвыя метрыкі. Для выяўлення крыніцы паломкі мы ў цэлым трацім каля 1-2 хвілін. Пасля гэтага мы ўжо працуем з канкрэтнай камандай над дыягностыкай - ад дзясяткаў хвілін да некалькіх гадзін.
Нават калі дыягностыка робіцца хутка, мы не жадаем, каб гэта адбывалася часта. У ідэальным выпадку мы будзем атрымліваць крытычны alert толькі тады, калі ёсьць значны ўплыў на сэрвіс. Для нашай сістэмы паскарэння запытаў у нас усяго 2 alert, якія будуць апавяшчаць:
- працэнт Client Fallback - ацэнка паводзін кліентаў;
- працэнт Probe errors - дадзеныя стабільнасці сеткавых кампанент.
Гэтыя critical alerts сочаць, ці працуе сістэма для большасці карыстальнікаў. Мы глядзім на тое, колькі кліентаў скарысталіся 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 інфраструктуру, backbone сетку, і DNS сервера, для дасягнення гэтай задачы.
Аднак, наша рашэнне – гэта ўсяго толькі прыклад таго, як мы ў Netflix рэалізавалі такую сістэму. Што спрацавала для нас. Прыкладная частка майго дакладу для вас - прынцыпы распрацоўкі і падтрымкі, якім мы ідзём і дасягаем добрых вынікаў.
Нашае рашэнне праблемы вам можа не падысці. Аднак тэорыя і прынцыпы распрацоўкі застаюцца, нават калі ў вас няма ўласнай CDN інфраструктуры, ці калі яна істотна адрозніваецца ад нашай.
Таксама застаецца важнасць хуткасці запытаў на бізнэс. І нават для простага сэрвісу трэба рабіць выбар: паміж "хмарнымі" правайдэрамі, месцазнаходжаннем сервераў, CDN і DNS правайдэрамі. Ваш выбар будзе ўплываць на эфектыўнасць інтэрнэт-запытаў для вашых кліентаў. І для вас важны гэты ўплыў вымяраць і разумець.
Пачынайце з простых рашэнняў, клапаціцеся пра тое, як вы змяняеце прадукт. Вучыцеся ў працэсе і ўдасканальвайце сістэму на аснове дадзеных з вашых кліентаў, вашай інфраструктуры, і вашага бізнесу. Думайце аб магчымасці нечаканых паломак у працэсе праектавання. І тады вы зможаце паскорыць ваш працэс распрацоўкі, палепшыць эфектыўнасць рашэння, пазбегнуць залішняй нагрузкі на падтрымку і спаць спакойна.
У гэтым годзе у анлайн-фармаце. Можна будзе задаць пытанні аднаму з бацькоў DevOps, самому Джону Уілісу!
Крыніца: habr.com