Netflix je lídrom na trhu internetovej televízie - spoločnosť, ktorá vytvorila a aktívne rozvíja tento segment. Netflix je známy nielen svojim rozsiahlym katalógom filmov a televíznych seriálov dostupných z takmer každého kúta planéty a akéhokoľvek zariadenia s displejom, ale aj spoľahlivou infraštruktúrou a jedinečnou inžinierskou kultúrou.
Jasný príklad prístupu Netflix k vývoju a podpore zložitých systémov bol predstavený na DevOops 2019 - Riaditeľ vývoja v Netflixe. Absolvent Fakulty výpočtovej matematiky a matematiky Štátnej univerzity v Nižnom Novgorode. Lobachevsky, Sergey, jeden z prvých inžinierov v tíme Open Connect - CDN v Netflixe. Vybudoval systémy na monitorovanie a analýzu video dát, spustil populárnu službu na hodnotenie rýchlosti internetového pripojenia FAST.com a posledné roky pracuje na optimalizácii internetových požiadaviek tak, aby aplikácia Netflix fungovala pre používateľov čo najrýchlejšie.
Správa získala od účastníkov konferencie najlepšie hodnotenia a my sme pre vás pripravili jej textovú verziu.
Vo svojej správe Sergej hovoril podrobne
- o tom, čo ovplyvňuje oneskorenie internetových požiadaviek medzi klientom a serverom;
- ako skrátiť toto oneskorenie;
- ako navrhovať, udržiavať a monitorovať systémy odolné voči chybám;
- ako dosiahnuť výsledky v krátkom čase as minimálnym rizikom pre podnikanie;
- ako analyzovať výsledky a poučiť sa z chýb.
Odpovede na tieto otázky potrebujú nielen tí, ktorí pracujú vo veľkých korporáciách.
Prezentované princípy a techniky by mal poznať a praktizovať každý, kto vyvíja a podporuje internetové produkty.
Nasleduje rozprávanie z perspektívy rečníka.
Dôležitosť rýchlosti internetu
Rýchlosť internetových požiadaviek priamo súvisí s podnikaním. Zoberme si nákupný priemysel: Amazon v roku 2009 že oneskorenie 100 ms má za následok stratu 1 % z predaja.
Mobilných zariadení je čoraz viac, nasledujú mobilné stránky a aplikácie. Ak sa vaša stránka načítava dlhšie ako 3 sekundy, prichádzate o približne polovicu používateľov. S Google berie do úvahy rýchlosť načítania vašej stránky vo výsledkoch vyhľadávania: čím rýchlejšia stránka, tým vyššia je jej pozícia v Google.
Rýchlosť pripojenia je dôležitá aj vo finančných inštitúciách, kde je latencia kritická. V roku 2015 Hibernia Networks kábel medzi New Yorkom a Londýnom v hodnote 400 miliónov dolárov na zníženie latencie medzi mestami o 6 ms. Predstavte si 66 miliónov dolárov za zníženie latencie o 1 ms!
Podľa , rýchlosti pripojenia nad 5 Mbit/s už priamo neovplyvňujú rýchlosť načítania typického webu. Existuje však lineárny vzťah medzi latenciou pripojenia a rýchlosťou načítania stránky:
Netflix však nie je typický produkt. Vplyv latencie a rýchlosti na používateľa je aktívnou oblasťou analýzy a vývoja. Existuje načítanie aplikácií a výber obsahu, ktoré závisia od latencie, ale načítanie statických prvkov a streamovanie závisí aj od rýchlosti pripojenia. Analýza a optimalizácia kľúčových faktorov, ktoré ovplyvňujú používateľskú skúsenosť, je aktívnou oblasťou vývoja pre niekoľko tímov v Netflixe. Jedným z cieľov je zníženie latencie požiadaviek medzi zariadeniami Netflix a cloudovou infraštruktúrou.
V správe sa zameriame konkrétne na zníženie latencie na príklade infraštruktúry Netflix. Uvažujme z praktického hľadiska, ako pristupovať k procesom návrhu, vývoja a prevádzky zložitých distribuovaných systémov a venovať čas inováciám a výsledkom, než diagnostikovať prevádzkové problémy a poruchy.
Vo vnútri Netflixu
Aplikácie Netflix podporujú tisíce rôznych zariadení. Vyvíjajú ich štyri rôzne tímy, ktoré vytvárajú samostatné verzie klienta pre Android, iOS, TV a webové prehliadače. A vynakladáme veľa úsilia na zlepšenie a prispôsobenie používateľskej skúsenosti. Aby sme to dosiahli, paralelne spúšťame stovky A/B testov.
Personalizáciu podporujú stovky mikroslužieb v cloude AWS, ktoré poskytujú personalizované používateľské údaje, odosielanie dopytov, telemetriu, veľké dáta a kódovanie. Vizualizácia premávky vyzerá takto:
Vľavo je vstupný bod a potom je prevádzka rozdelená medzi niekoľko stoviek mikroslužieb, ktoré sú podporované rôznymi backendovými tímami.
Ďalšou dôležitou súčasťou našej infraštruktúry je Open Connect CDN, ktorá dodáva koncovému používateľovi statický obsah – videá, obrázky, klientsky kód atď. CDN sa nachádza na vlastných serveroch (OCA - Open Connect Appliance). Vo vnútri sú polia SSD a HDD diskov s optimalizovaným FreeBSD s NGINX a sadou služieb. Navrhujeme a optimalizujeme hardvérové a softvérové komponenty tak, aby takýto CDN server mohol odosielať používateľom čo najviac dát.
„Stena“ týchto serverov v bode výmeny internetového prenosu (Internet eXchange - IX) vyzerá takto:
Internet Exchange poskytuje poskytovateľom internetových služieb a poskytovateľom obsahu možnosť vzájomne sa „spojiť“ a priamo si tak vymieňať údaje na internete. Na svete je približne 70 – 80 bodov Internet Exchange, kde sú nainštalované naše servery a nezávisle ich inštalujeme a udržiavame:
Okrem toho poskytujeme aj servery priamo poskytovateľom internetu, ktoré si inštalujú do svojej siete, čím zlepšujeme lokalizáciu prevádzky Netflix a kvalitu streamovania pre používateľov:
Sada služieb AWS je zodpovedná za odosielanie požiadaviek na video od klientov na servery CDN, ako aj za konfiguráciu samotných serverov - aktualizáciu obsahu, programového kódu, nastavení atď. Pre tú druhú sme vybudovali aj chrbticovú sieť, ktorá spája servery v bodoch Internet Exchange s AWS. Chrbtová sieť je globálna sieť optických káblov a smerovačov, ktoré môžeme navrhnúť a nakonfigurovať na základe našich potrieb.
Na Naša infraštruktúra CDN poskytuje približne ⅛ svetovej internetovej prevádzky počas špičky a ⅓ prevádzky v Severnej Amerike, kde je Netflix najdlhšie. Pôsobivé čísla, ale pre mňa jeden z najúžasnejších úspechov je, že celý systém CDN vyvíja a udržiava tím menej ako 150 ľudí.
Infraštruktúra CDN bola pôvodne navrhnutá na poskytovanie video dát. Postupom času sme si však uvedomili, že ho vieme využiť aj na optimalizáciu dynamických požiadaviek klientov v cloude AWS.
O zrýchlení internetu
Dnes má Netflix 3 oblasti AWS a latencia požiadaviek do cloudu bude závisieť od toho, ako ďaleko je zákazník od najbližšieho regiónu. Zároveň máme veľa serverov CDN, ktoré sa používajú na doručovanie statického obsahu. Existuje nejaký spôsob, ako použiť tento rámec na zrýchlenie dynamických dopytov? Tieto požiadavky však, žiaľ, nie je možné uložiť do vyrovnávacej pamäte – rozhrania API sú prispôsobené a každý výsledok je jedinečný.
Urobme proxy na serveri CDN a začnime cez neho posielať prenos. Bude to rýchlejšie?
Materiál
Pripomeňme si, ako fungujú sieťové protokoly. Dnes väčšina prevádzky na internete používa HTTPs, čo závisí od protokolov nižšej vrstvy TCP a TLS. Aby sa klient mohol pripojiť k serveru, vykoná handshake a nadviaže zabezpečené spojenie, klient si potrebuje vymeniť správy so serverom trikrát a ešte aspoň raz na prenos údajov. Pri latencii na spiatočnú cestu (RTT) 100 ms by nám príjem prvého bitu údajov trvalo 400 ms:
Ak certifikáty umiestnime na server CDN, potom sa môže výrazne skrátiť čas handshake medzi klientom a serverom, ak je CDN bližšie. Predpokladajme, že latencia k serveru CDN je 30 ms. Potom bude príjem prvého bitu trvať 220 ms:
Tým ale výhody nekončia. Po nadviazaní spojenia TCP zväčší okno preťaženia (množstvo informácií, ktoré môže paralelne prenášať cez toto spojenie). Ak dôjde k strate dátového paketu, klasické implementácie protokolu TCP (ako TCP New Reno) zmenšia otvorené „okno“ na polovicu. Rast okna preťaženia a rýchlosť jeho zotavenia zo straty opäť závisí od oneskorenia (RTT) na server. Ak toto pripojenie ide len k serveru CDN, bude toto obnovenie rýchlejšie. Strata paketov je zároveň štandardným javom najmä pre bezdrôtové siete.
Šírka internetového pásma môže byť znížená, najmä počas špičkových hodín, v dôsledku návštevnosti používateľov, čo môže viesť k dopravným zápcham. Na internete však neexistuje spôsob, ako dať prednosť niektorým požiadavkám pred inými. Uprednostnite napríklad malé a na oneskorenie citlivé požiadavky pred „ťažkými“ dátovými tokmi, ktoré zaťažujú sieť. V našom prípade nám to však umožňuje mať vlastnú chrbticovú sieť na časti cesty požiadavky – medzi CDN a cloudom a vieme ju plne nakonfigurovať. Môžete sa uistiť, že malé a na latenciu citlivé pakety majú prioritu a veľké dátové toky idú o niečo neskôr. Čím bližšie je CDN ku klientovi, tým väčšia je efektivita.
Protokoly na aplikačnej úrovni (OSI Level 7) majú tiež vplyv na latenciu. Nové protokoly ako HTTP/2 optimalizujú výkon paralelných požiadaviek. Máme však klientov Netflix so staršími zariadeniami, ktoré nepodporujú nové protokoly. Nie všetkých klientov je možné aktualizovať alebo optimálne nakonfigurovať. Zároveň medzi CDN proxy a cloudom existuje úplná kontrola a možnosť používať nové, optimálne protokoly a nastavenia. Neefektívna časť so starými protokolmi bude fungovať iba medzi klientom a serverom CDN. Okrem toho môžeme vytvárať multiplexné požiadavky na už vytvorené spojenie medzi CDN a cloudom, čím sa zlepšuje využitie pripojenia na úrovni TCP:
Meriame
Napriek tomu, že teória sľubuje vylepšenia, so spustením systému do výroby sa hneď neponáhľame. Namiesto toho musíme najskôr dokázať, že nápad bude fungovať v praxi. Ak to chcete urobiť, musíte odpovedať na niekoľko otázok:
- Rýchlosť: bude proxy rýchlejší?
- Spoľahlivosť: Rozbije sa to častejšie?
- zložitosť: ako sa integrovať s aplikáciami?
- Štát: Koľko stojí nasadenie ďalšej infraštruktúry?
Pozrime sa podrobne na náš prístup k hodnoteniu prvého bodu. Ostatné sa riešia podobným spôsobom.
Aby sme analyzovali rýchlosť požiadaviek, chceme získať údaje pre všetkých používateľov bez toho, aby sme trávili veľa času vývojom a bez prerušenia výroby. Existuje na to niekoľko prístupov:
- RUM, alebo pasívne meranie požiadavky. Meriame čas realizácie aktuálnych požiadaviek od používateľov a zabezpečujeme plné pokrytie používateľov. Nevýhodou je, že signál nie je veľmi stabilný kvôli mnohým faktorom, napríklad kvôli rôznym veľkostiam požiadaviek, dobe spracovania na serveri a klientovi. Okrem toho nemôžete testovať novú konfiguráciu bez účinku vo výrobe.
- Laboratórne testy. Špeciálne servery a infraštruktúra, ktoré simulujú klientov. S ich pomocou vykonáme potrebné testy. Získame tak plnú kontrolu nad výsledkami merania a jasný signál. Neexistuje však úplné pokrytie zariadení a umiestnení používateľov (najmä s celosvetovou službou a podporou pre tisíce modelov zariadení).
Ako môžete spojiť výhody oboch metód?
Náš tím našiel riešenie. Napísali sme malý kúsok kódu – vzorku – ktorý sme zabudovali do našej aplikácie. Sondy nám umožňujú vykonávať plne kontrolované sieťové testy z našich zariadení. Funguje to takto:
- Krátko po načítaní aplikácie a dokončení úvodnej aktivity spúšťame naše sondy.
- Klient odošle požiadavku na server a dostane „recept“ na test. Recept je zoznam adries URL, na ktoré je potrebné odoslať požiadavku HTTP(s). Okrem toho recept nakonfiguruje parametre požiadavky: oneskorenia medzi požiadavkami, množstvo požadovaných údajov, hlavičky HTTP(s) atď. Zároveň môžeme paralelne testovať niekoľko rôznych receptúr – pri požiadavke na konfiguráciu náhodne určíme, ktorý recept vydáme.
- Čas spustenia sondy je zvolený tak, aby nebol v konflikte s aktívnym využívaním sieťových prostriedkov na klientovi. V podstate sa čas vyberá, keď klient nie je aktívny.
- Po prijatí receptu klient paralelne zadáva požiadavky na každú z URL. Požiadavku na každú z adries je možné opakovať – tzv. „pulzy“. Pri prvom impulze meriame, ako dlho trvalo nadviazanie spojenia a stiahnutie dát. Pri druhom impulze meriame čas potrebný na načítanie dát cez už vytvorené spojenie. Pred treťou si môžeme nastaviť oneskorenie a merať rýchlosť nadviazania opätovného spojenia atď.
Počas testu meriame všetky parametre, ktoré môže zariadenie získať:
- čas požiadavky DNS;
- čas nastavenia pripojenia TCP;
- čas nastavenia pripojenia TLS;
- čas prijatia prvého bajtu dát;
- celkový čas načítania;
- kód výsledku stavu.
- Po dokončení všetkých impulzov vzorka načíta všetky merania na analýzu.
Kľúčovými bodmi sú minimálna závislosť od logiky na klientovi, spracovanie dát na serveri a meranie paralelných požiadaviek. Sme tak schopní izolovať a testovať vplyv rôznych faktorov ovplyvňujúcich výkon dotazu, meniť ich v rámci jedného receptu a získavať výsledky od skutočných klientov.
Táto infraštruktúra sa ukázala ako užitočná pre viac než len analýzu výkonu dotazov. V súčasnosti máme 14 aktívnych receptov, viac ako 6000 vzoriek za sekundu, prijímame dáta zo všetkých kútov zeme a máme plné pokrytie zariadení. Ak by Netflix kúpil podobnú službu od tretej strany, stálo by to milióny dolárov ročne s oveľa horším pokrytím.
Teória testovania v praxi: prototyp
S takýmto systémom sme boli schopní vyhodnotiť efektivitu CDN proxy na latenciu žiadosti. Teraz potrebujete:
- vytvoriť prototyp proxy;
- umiestnite prototyp na CDN;
- určiť, ako nasmerovať klientov na server proxy na konkrétnom serveri CDN;
- Porovnajte výkon s požiadavkami v AWS bez servera proxy.
Úlohou je čo najrýchlejšie vyhodnotiť efektivitu navrhovaného riešenia. Na implementáciu prototypu sme si vybrali Go kvôli dostupnosti dobrých sieťových knižníc. Na každý server CDN sme nainštalovali prototyp proxy ako statický binárny súbor, aby sme minimalizovali závislosti a zjednodušili integráciu. Pri prvotnej implementácii sme v maximálnej možnej miere použili štandardné komponenty a drobné úpravy pre združovanie pripojení HTTP/2 a multiplexovanie požiadaviek.
Na vyváženie medzi regiónmi AWS sme použili geografickú databázu DNS, rovnakú, ktorá sa používa na vyváženie klientov. Na výber CDN servera pre klienta používame TCP Anycast pre servery v Internet Exchange (IX). V tejto možnosti používame jednu IP adresu pre všetky servery CDN a klient bude presmerovaný na server CDN s najmenším počtom skokov IP. Na serveroch CDN nainštalovaných poskytovateľmi internetu (ISP) nemáme kontrolu nad smerovačom na konfiguráciu TCP Anycast, takže používame , ktorá nasmeruje zákazníkov k poskytovateľom internetu na streamovanie videa.
Máme teda tri typy ciest požiadaviek: do cloudu cez otvorený internet, cez CDN server v IX alebo cez CDN server u poskytovateľa internetu. Naším cieľom je pochopiť, ktorý spôsob je lepší a aké sú výhody servera proxy v porovnaní s tým, ako sa požiadavky odosielajú do produkcie. Na tento účel používame vzorkovací systém:
Každá z ciest sa stáva samostatným cieľom a my sa pozeráme na čas, ktorý sme dostali. Na analýzu skombinujeme výsledky proxy do jednej skupiny (vyberieme najlepší čas medzi proxy IX a ISP) a porovnáme ich s časom žiadostí do cloudu bez proxy:
Ako vidíte, výsledky boli zmiešané - vo väčšine prípadov poskytuje proxy dobré zrýchlenie, ale existuje aj dostatočný počet klientov, pre ktorých sa situácia výrazne zhorší.
V dôsledku toho sme urobili niekoľko dôležitých vecí:
- Posúdili sme očakávanú výkonnosť požiadaviek od klientov do cloudu cez CDN proxy.
- Získali sme dáta od reálnych klientov, zo všetkých typov zariadení.
- Uvedomili sme si, že teória sa nepotvrdila na 100% a prvotná ponuka s CDN proxy by pre nás nefungovala.
- Neriskovali sme – nemenili sme výrobné konfigurácie pre klientov.
- Nič nebolo zlomené.
Prototyp 2.0
Takže späť na rysovaciu dosku a celý proces zopakujte.
Myšlienka je taká, že namiesto 100% proxy určíme pre každého klienta najrýchlejšiu cestu a tam budeme posielať požiadavky – to znamená, že budeme robiť to, čomu sa hovorí klientské riadenie.
Ako to implementovať? Nemôžeme použiť logiku na strane servera, pretože... Cieľom je pripojiť sa k tomuto serveru. Musí existovať nejaký spôsob, ako to urobiť na klientovi. A v ideálnom prípade to urobte s minimálnym množstvom komplexnej logiky, aby ste nevyriešili problém integrácie s veľkým počtom klientskych platforiem.
Odpoveďou je použitie DNS. V našom prípade máme vlastnú DNS infraštruktúru a môžeme nastaviť doménovú zónu, pre ktorú budú naše servery autoritatívne. Funguje to takto:
- Klient odošle požiadavku na server DNS pomocou hostiteľa, napríklad api.netflix.xom.
- Požiadavka príde na náš server DNS
- Server DNS vie, ktorá cesta je pre tohto klienta najrýchlejšia a vydá zodpovedajúcu IP adresu.
Riešenie má ďalšiu zložitosť: autoritárski poskytovatelia DNS nevidia IP adresu klienta a môžu čítať iba IP adresu rekurzívneho prekladača, ktorý klient používa.
Výsledkom je, že náš autoritatívny riešiteľ musí urobiť rozhodnutie nie pre jednotlivého klienta, ale pre skupinu klientov na základe rekurzívneho riešiteľa.
Na riešenie používame rovnaké vzorky, agregujeme výsledky meraní od klientov pre každý z rekurzívnych resolverov a rozhodujeme sa, kam túto skupinu z nich pošleme – proxy cez IX pomocou TCP Anycast, cez proxy ISP alebo priamo do cloudu.
Získame nasledujúci systém:
Výsledný model riadenia DNS vám umožňuje nasmerovať klientov na základe historických pozorovaní rýchlosti pripojení od klientov do cloudu.
Opäť je tu otázka, ako efektívne bude tento prístup fungovať? Na odpoveď opäť používame náš systém sondy. Preto konfigurujeme konfiguráciu prezentéra, kde jeden z cieľov sleduje smer z DNS riadenia, druhý ide priamo do cloudu (aktuálna produkcia).
Výsledkom je porovnanie výsledkov a hodnotenie účinnosti:
Vďaka tomu sme sa naučili niekoľko dôležitých vecí:
- Hodnotili sme očakávaný výkon požiadaviek klientov do cloudu pomocou DNS Steering.
- Získali sme dáta od reálnych klientov, zo všetkých typov zariadení.
- Účinnosť navrhovanej myšlienky bola preukázaná.
- Neriskovali sme – nemenili sme výrobné konfigurácie pre klientov.
- Nič nebolo zlomené.
Teraz o zložitej časti – spúšťame to vo výrobe
Najjednoduchšia časť je teraz u konca - existuje funkčný prototyp. Teraz je najťažšou časťou spustenie riešenia pre všetku prevádzku Netflixu, nasadenie pre 150 miliónov používateľov, tisíce zariadení, stovky mikroslužieb a neustále sa meniaci produkt a infraštruktúra. Servery Netflix dostávajú milióny žiadostí za sekundu a je ľahké prerušiť službu neopatrným konaním. Zároveň chceme dynamicky smerovať prevádzku cez tisíce CDN serverov na internete, kde sa neustále a v najnevhodnejšom momente niečo mení a láme.
A s tým všetkým má tím 3 inžinierov zodpovedných za vývoj, nasadenie a plnú podporu systému.
Preto budeme aj naďalej hovoriť o pokojnom a zdravom spánku.
Ako pokračovať vo vývoji a netráviť všetok čas podporou? Náš prístup je založený na 3 princípoch:
- Znižujeme potenciálny rozsah porúch (polomer výbuchu).
- Pripravujeme prekvapenia – očakávame, že sa aj napriek testovaniu a osobným skúsenostiam niečo zlomí.
- Pôvabná degradácia – ak niečo nefunguje správne, malo by sa to automaticky opraviť, aj keď nie tým najefektívnejším spôsobom.
Ukázalo sa, že v našom prípade týmto prístupom k problému vieme nájsť jednoduché a efektívne riešenie a výrazne zjednodušiť podporu systému. Uvedomili sme si, že môžeme pridať malý kúsok kódu do klienta a monitorovať chyby sieťových požiadaviek spôsobené problémami s pripojením. V prípade chýb siete urobíme núdzový zásah priamo do cloudu. Toto riešenie nevyžaduje značné úsilie pre tímy klientov, ale výrazne znižuje riziko neočakávaných porúch a prekvapení pre nás.
Samozrejme, aj napriek núdzovej situácii sa pri vývoji riadime jasnou disciplínou:
- Vzorový test.
- A/B testovanie alebo Kanárske ostrovy.
- Postupné zavádzanie.
Pri vzorkách bol opísaný prístup – zmeny sa najskôr testujú pomocou prispôsobeného receptu.
Na testovanie kanárikov potrebujeme získať porovnateľné dvojice serverov, na ktorých môžeme porovnať, ako systém funguje pred a po zmenách. Aby sme to dosiahli, z našich mnohých stránok CDN vyberáme páry serverov, ktoré prijímajú porovnateľnú návštevnosť:
Potom nainštalujeme zostavu so zmenami na server Canary. Na vyhodnotenie výsledkov spúšťame systém, ktorý porovnáva približne 100 – 150 metrík so vzorkou serverov Control:
Ak bude testovanie Canary úspešné, tak ho vypúšťame postupne, vo vlnách. Neaktualizujeme servery na každej lokalite súčasne – strata celej lokality v dôsledku problémov má výraznejší dopad na službu pre používateľov ako strata rovnakého počtu serverov na rôznych miestach.
Vo všeobecnosti účinnosť a bezpečnosť tohto prístupu závisí od množstva a kvality zhromaždených metrík. Pre náš systém na zrýchlenie dopytov zhromažďujeme metriky zo všetkých možných komponentov:
- od klientov - počet sedení a požiadaviek, sadzby za záložné;
- proxy – štatistiky o počte a čase žiadostí;
- DNS - počet a výsledky požiadaviek;
- cloud edge - počet a čas spracovania požiadaviek v cloude.
To všetko sa zhromažďuje do jedného kanála a v závislosti od potrieb sa rozhodneme, ktoré metriky pošleme do analýzy v reálnom čase a ktoré do Elasticsearch alebo Big Data na podrobnejšiu diagnostiku.
Monitorujeme
V našom prípade robíme zmeny na kritickej ceste požiadaviek medzi klientom a serverom. Zároveň je množstvo rôznych komponentov na klientovi, na serveri a na ceste cez internet obrovské. Zmeny na klientovi a serveri prebiehajú neustále – počas práce desiatok tímov a prirodzených zmien v ekosystéme. Sme v strede – pri diagnostikovaní problémov je veľká šanca, že sa do toho zapojíme. Preto musíme jasne pochopiť, ako definovať, zhromažďovať a analyzovať metriky, aby sme rýchlo izolovali problémy.
V ideálnom prípade úplný prístup ku všetkým typom metrík a filtrov v reálnom čase. Existuje však veľa metrík, takže vyvstáva otázka nákladov. V našom prípade oddeľujeme metriky a vývojové nástroje takto:
Na detekciu a triedenie problémov používame náš vlastný open source systém v reálnom čase и - na vizualizáciu. Ukladá agregované metriky v pamäti, je spoľahlivý a integruje sa s výstražným systémom. Pre lokalizáciu a diagnostiku máme prístup k protokolom z Elasticsearch a Kibana. Na štatistickú analýzu a modelovanie používame veľké dáta a vizualizáciu v Tableau.
Zdá sa, že s týmto prístupom je veľmi ťažké pracovať. Avšak hierarchickým usporiadaním metrík a nástrojov môžeme rýchlo analyzovať problém, určiť typ problému a potom prejsť na podrobné metriky. Vo všeobecnosti venujeme asi 1-2 minúty identifikácii zdroja poruchy. Následne pracujeme s konkrétnym tímom na diagnostike – od desiatok minút až po niekoľko hodín.
Aj keď je diagnóza vykonaná rýchlo, nechceme, aby sa to stalo často. V ideálnom prípade dostaneme kritické upozornenie iba vtedy, keď dôjde k významnému vplyvu na službu. Pre náš systém na zrýchlenie dopytov máme iba 2 upozornenia, ktoré vás upozornia:
- Klient Fallback percento - hodnotenie správania zákazníkov;
- percento Chyby sondy - údaje o stabilite sieťových komponentov.
Tieto kritické upozornenia monitorujú, či systém funguje pre väčšinu používateľov. Pozeráme sa na to, koľko klientov použilo záložné riešenie, ak nemohli získať zrýchlenie požiadaviek. V priemere dostaneme menej ako 1 kritické upozornenie za týždeň, aj keď v systéme prebieha množstvo zmien. Prečo nám to stačí?
- Ak náš proxy server nefunguje, dôjde k záložnému klientovi.
- K dispozícii je automatický systém riadenia, ktorý reaguje na problémy.
Viac podrobností o tom druhom. Náš skúšobný systém a systém automatického určovania optimálnej cesty pre požiadavky od klienta do cloudu nám umožňuje automaticky sa vysporiadať s niektorými problémami.
Vráťme sa k našej vzorovej konfigurácii a 3 kategóriám ciest. Okrem času načítania sa môžeme pozrieť aj na samotný fakt doručenia. Ak nebolo možné načítať údaje, potom pri pohľade na výsledky po rôznych cestách môžeme určiť, kde a čo sa pokazilo a či to môžeme automaticky opraviť zmenou cesty požiadavky.
Príklady:
Tento proces je možné automatizovať. Zahrňte ho do systému riadenia. A naučiť ho reagovať na problémy s výkonom a spoľahlivosťou. Ak sa niečo začne lámať, reagujte, ak existuje lepšia možnosť. Okamžitá reakcia zároveň nie je kritická, a to vďaka núdzovému prístupu na klientov.
Princípy systémovej podpory teda možno formulovať takto:
- zníženie rozsahu porúch;
- zhromažďovanie metrík;
- Ak je to možné, automaticky opravujeme poruchy;
- ak to nie je možné, upozorníme vás;
- Pracujeme na dashboardoch a súprave nástrojov na triedenie pre rýchlu reakciu.
Ponaučenie
Napísanie prototypu nezaberie veľa času. V našom prípade to bolo hotové po 4 mesiacoch. S ním sme dostali nové metriky a 10 mesiacov po začatí vývoja sme dostali prvú produkčnú návštevnosť. Potom sa začala únavná a veľmi náročná práca: postupne produktovať a škálovať systém, migrovať hlavnú návštevnosť a učiť sa z chýb. Tento efektívny proces však nebude lineárny – napriek všetkému úsiliu sa nedá všetko predvídať. Oveľa efektívnejšie je rýchlo opakovať nové údaje a reagovať na ne.
Na základe našich skúseností môžeme odporučiť nasledovné:
- Neverte svojej intuícii.
Naša intuícia nás neustále zlyhávala, napriek rozsiahlym skúsenostiam členov nášho tímu. Nesprávne sme napríklad predpovedali očakávané zrýchlenie z používania servera proxy CDN alebo správania TCP Anycast.
- Získajte dáta z produkcie.
Je dôležité čo najrýchlejšie získať prístup aspoň k malému množstvu výrobných údajov. Je takmer nemožné získať počet jedinečných prípadov, konfigurácií a nastavení v laboratórnych podmienkach. Rýchly prístup k výsledkom vám umožní rýchlo sa dozvedieť o potenciálnych problémoch a zohľadniť ich v architektúre systému.
- Neriaďte sa radami a výsledkami iných ľudí – zbierajte svoje vlastné údaje.
Dodržujte zásady zberu a analýzy údajov, ale neprijímajte slepo výsledky a vyhlásenia iných ľudí. Len vy môžete presne vedieť, čo pre vašich používateľov funguje. Vaše systémy a vaši zákazníci sa môžu výrazne líšiť od iných spoločností. Našťastie sú teraz analytické nástroje dostupné a ľahko sa používajú. Výsledky, ktoré získate, nemusia byť také, ako tvrdia Netflix, Facebook, Akamai a ďalšie spoločnosti. V našom prípade sa výkon TLS, HTTP2 či štatistík o DNS požiadavkách líši od výsledkov Facebooku, Uberu, Akamai – máme totiž iné zariadenia, klientov a dátové toky.
- Nesledujte zbytočne módne trendy a vyhodnocujte efektivitu.
Začnite jednoducho. Je lepšie vytvoriť jednoduchý funkčný systém v krátkom čase, ako tráviť obrovské množstvo času vývojom komponentov, ktoré nepotrebujete. Riešte úlohy a problémy, na ktorých záleží, na základe vašich meraní a výsledkov.
- Pripravte sa na nové aplikácie.
Rovnako ako je ťažké predvídať všetky problémy, je ťažké predvídať výhody a aplikácie vopred. Vezmite si príklad zo startupov – ich schopnosť prispôsobiť sa podmienkam zákazníkov. Vo vašom prípade možno objavíte nové problémy a ich riešenia. V našom projekte sme si stanovili cieľ znížiť latenciu požiadaviek. Počas analýzy a diskusií sme si však uvedomili, že môžeme použiť aj proxy servery:
- vyvážiť prevádzku v regiónoch AWS a znížiť náklady;
- na modelovanie stability CDN;
- konfigurovať DNS;
- na konfiguráciu TLS/TCP.
Záver
V správe som opísal, ako Netflix rieši problém zrýchlenia internetových požiadaviek medzi klientmi a cloudom. Ako zhromažďujeme údaje pomocou vzorkovacieho systému o klientoch a používame zhromaždené historické údaje na smerovanie výrobných požiadaviek od klientov najrýchlejšou cestou na internete. Ako využívame princípy sieťových protokolov, našu CDN infraštruktúru, chrbticovú sieť a DNS servery na dosiahnutie tejto úlohy.
Naše riešenie je však len príkladom toho, ako sme v Netflixe implementovali takýto systém. Čo sa nám osvedčilo. Aplikovanou časťou mojej správy pre vás sú princípy rozvoja a podpory, ktoré dodržiavame a dosahujeme dobré výsledky.
Naše riešenie problému vám nemusí vyhovovať. Teória a princípy dizajnu však zostávajú zachované, aj keď nemáte vlastnú infraštruktúru CDN, alebo ak sa výrazne líši od našej.
Dôležitá zostáva aj rýchlosť obchodných požiadaviek. A dokonca aj pri jednoduchej službe si musíte vybrať: medzi poskytovateľmi cloudu, umiestnením servera, poskytovateľmi CDN a DNS. Vaša voľba ovplyvní efektivitu internetových dopytov pre vašich zákazníkov. A je dôležité, aby ste tento vplyv zmerali a pochopili.
Začnite s jednoduchými riešeniami, dajte si záležať na tom, ako meníte produkt. Učte sa za pochodu a vylepšujte systém na základe údajov od vašich zákazníkov, vašej infraštruktúry a vášho podnikania. Myslite na možnosť neočakávaných porúch počas procesu návrhu. A potom môžete urýchliť proces vývoja, zlepšiť efektivitu riešenia, vyhnúť sa zbytočnej záťaži podpory a pokojne spať.
Tento rok v online formáte. Môžete klásť otázky jednému z otcov DevOps, samotnému Johnovi Willisovi!
Zdroj: hab.com