Netflix je lídrem na trhu internetové televize – společnost, která vytvořila a aktivně rozvíjí tento segment. Netflix je známý nejen svým rozsáhlým katalogem filmů a televizních seriálů dostupných téměř ze všech koutů planety a jakýmkoli zařízením s displejem, ale také svou spolehlivou infrastrukturou a jedinečnou inženýrskou kulturou.
Jasný příklad přístupu Netflixu k vývoji a podpoře komplexních systémů byl představen na DevOops 2019 - Ředitel vývoje ve společnosti Netflix. Absolvent Fakulty výpočetní matematiky a matematiky Státní univerzity v Nižním Novgorodu. Lobačevskij, Sergey jeden z prvních inženýrů v týmu Open Connect - CDN v Netflixu. Vybudoval systémy pro sledování a analýzu video dat, spustil oblíbenou službu pro hodnocení rychlosti připojení k internetu FAST.com a posledních pár let pracuje na optimalizaci internetových požadavků tak, aby aplikace Netflix uživatelům fungovala co nejrychleji.
Zpráva získala od účastníků konference nejlepší hodnocení a my jsme pro vás připravili její textovou verzi.
Sergej ve své zprávě hovořil podrobně
- o tom, co ovlivňuje zpoždění internetových požadavků mezi klientem a serverem;
- jak toto zpoždění zkrátit;
- jak navrhovat, udržovat a monitorovat systémy odolné vůči chybám;
- jak dosáhnout výsledků v krátkém čase as minimálním rizikem pro podnikání;
- jak analyzovat výsledky a poučit se z chyb.
Odpovědi na tyto otázky potřebují nejen ti, kteří pracují ve velkých korporacích.
Prezentované principy a techniky by měl znát a praktikovat každý, kdo vyvíjí a podporuje internetové produkty.
Následuje vyprávění z perspektivy mluvčího.
Význam rychlosti internetu
Rychlost internetových požadavků přímo souvisí s podnikáním. Vezměme si nákupní průmysl: Amazon v roce 2009 že zpoždění 100 ms má za následek ztrátu 1 % tržeb.
Mobilních zařízení přibývá, následují mobilní stránky a aplikace. Pokud se vaše stránka načítá déle než 3 sekundy, přicházíte o polovinu uživatelů. S Google bere v úvahu rychlost načítání vaší stránky ve výsledcích vyhledávání: čím rychlejší stránka, tím vyšší pozice na Googlu.
Rychlost připojení je také důležitá ve finančních institucích, kde je kritická latence. V roce 2015 Hibernia Networks kabel za 400 milionů dolarů mezi New Yorkem a Londýnem ke snížení latence mezi městy o 6 ms. Představte si 66 milionů dolarů za 1 ms snížení latence!
Podle , rychlosti připojení nad 5 Mbit/s již přímo neovlivňují rychlost načítání typického webu. Mezi latencí připojení a rychlostí načítání stránky však existuje lineární vztah:
Netflix však není typický produkt. Vliv latence a rychlosti na uživatele je aktivní oblastí analýzy a vývoje. Načítání aplikací a výběr obsahu závisí na latenci, ale načítání statických prvků a streamování závisí také na rychlosti připojení. Analýza a optimalizace klíčových faktorů, které ovlivňují uživatelskou zkušenost, je aktivní oblastí vývoje pro několik týmů v Netflixu. Jedním z cílů je snížit latenci požadavků mezi zařízeními Netflix a cloudovou infrastrukturou.
Ve zprávě se zaměříme konkrétně na snížení latence na příkladu infrastruktury Netflix. Zvažme z praktického hlediska, jak přistupovat k procesům návrhu, vývoje a provozu složitých distribuovaných systémů a věnovat čas inovacím a výsledkům, spíše než diagnostikovat provozní problémy a poruchy.
Uvnitř Netflixu
Aplikace Netflix podporují tisíce různých zařízení. Vyvíjejí je čtyři různé týmy, které vytvářejí samostatné verze klienta pro Android, iOS, TV a webové prohlížeče. A vynakládáme mnoho úsilí na zlepšování a personalizaci uživatelského prostředí. Za tímto účelem provádíme paralelně stovky A/B testů.
Personalizaci podporují stovky mikroslužeb v cloudu AWS, které poskytují personalizovaná uživatelská data, odesílání dotazů, telemetrii, velká data a kódování. Vizualizace provozu vypadá takto:
Vlevo je vstupní bod a poté je provoz distribuován mezi několik stovek mikroslužeb, které jsou podporovány různými backendovými týmy.
Další důležitou součástí naší infrastruktury je Open Connect CDN, která dodává koncovému uživateli statický obsah – videa, obrázky, klientský kód atd. CDN se nachází na vlastních serverech (OCA - Open Connect Appliance). Uvnitř jsou pole SSD a HDD disků s optimalizovaným FreeBSD s NGINX a sadou služeb. Navrhujeme a optimalizujeme hardwarové a softwarové komponenty tak, aby takový CDN server mohl odesílat uživatelům co nejvíce dat.
„Zeď“ těchto serverů v místě výměny internetového provozu (Internet eXchange - IX) vypadá takto:
Internet Exchange poskytuje poskytovatelům internetových služeb a poskytovatelům obsahu možnost se vzájemně „propojit“ a přímo si vyměňovat data na internetu. Po celém světě je přibližně 70–80 bodů Internet Exchange, kde jsou nainstalovány naše servery, a my je nezávisle instalujeme a udržujeme:
Kromě toho poskytujeme také servery přímo poskytovatelům internetu, které si instalují do své sítě, čímž zlepšujeme lokalizaci provozu Netflix a kvalitu streamování pro uživatele:
Sada služeb AWS je zodpovědná za odesílání požadavků na video od klientů na servery CDN a také za konfiguraci samotných serverů – aktualizaci obsahu, programového kódu, nastavení atd. Pro posledně jmenované jsme také vybudovali páteřní síť, která propojuje servery v bodech Internet Exchange s AWS. Páteřní síť je globální síť optických kabelů a routerů, které můžeme navrhnout a nakonfigurovat na základě našich potřeb.
Na , naše infrastruktura CDN zajišťuje přibližně ⅛ světového internetového provozu ve špičce a ⅓ provozu v Severní Americe, kde je Netflix nejdéle. Působivá čísla, ale pro mě je jedním z nejúžasnějších úspěchů to, že celý systém CDN vyvíjí a udržuje tým méně než 150 lidí.
Infrastruktura CDN byla původně navržena tak, aby poskytovala video data. Postupem času jsme si ale uvědomili, že jej můžeme využít i k optimalizaci dynamických požadavků od klientů v cloudu AWS.
O zrychlení internetu
Dnes má Netflix 3 oblasti AWS a latence požadavků na cloud bude záviset na tom, jak daleko je zákazník od nejbližšího regionu. Zároveň máme mnoho CDN serverů, které se používají k doručování statického obsahu. Existuje nějaký způsob, jak použít tento rámec k urychlení dynamických dotazů? Tyto požadavky však bohužel není možné uložit do mezipaměti – API jsou personalizovaná a každý výsledek je jedinečný.
Vytvořme proxy na serveru CDN a začněme přes něj posílat provoz. Bude to rychlejší?
Materiál
Připomeňme si, jak fungují síťové protokoly. Dnes většina provozu na internetu používá HTTPs, což závisí na protokolech nižší vrstvy TCP a TLS. Aby se klient mohl připojit k serveru, provede handshake a k navázání zabezpečeného spojení si klient potřebuje vyměnit zprávy se serverem třikrát a ještě alespoň jednou pro přenos dat. Při latenci na zpáteční cestu (RTT) 100 ms by nám příjem prvního bitu dat trval 400 ms:
Umístíme-li certifikáty na server CDN, může se výrazně zkrátit doba handshake mezi klientem a serverem, pokud je CDN blíže. Předpokládejme, že latence k serveru CDN je 30 ms. Poté bude příjem prvního bitu trvat 220 ms:
Tím ale výhody nekončí. Jakmile je spojení navázáno, TCP zvětší okno zahlcení (množství informací, které může paralelně přenášet přes toto spojení). Pokud dojde ke ztrátě datového paketu, klasické implementace protokolu TCP (jako TCP New Reno) zmenší otevřené „okno“ na polovinu. Růst okna přetížení a rychlost jeho zotavení ze ztráty opět závisí na zpoždění (RTT) k serveru. Pokud toto připojení vede pouze k serveru CDN, bude tato obnova rychlejší. Ztráta paketů je přitom standardním jevem zejména u bezdrátových sítí.
Šířka internetového pásma může být snížena, zejména ve špičce, kvůli provozu od uživatelů, což může vést k dopravním zácpám. Na internetu však neexistuje způsob, jak upřednostnit některé požadavky před jinými. Upřednostněte například malé požadavky citlivé na latenci před „těžkými“ datovými toky, které zatěžují síť. V našem případě nám to ale vlastní páteřní síť umožňuje na části cesty požadavku – mezi CDN a cloudem, a můžeme ji plně nakonfigurovat. Můžete se ujistit, že malé pakety a pakety citlivé na latenci budou upřednostňovány a velké datové toky budou probíhat o něco později. Čím blíže je CDN klientovi, tím větší je efektivita.
Protokoly na aplikační úrovni (OSI Level 7) mají také vliv na latenci. Nové protokoly jako HTTP/2 optimalizují výkon paralelních požadavků. Máme však klienty Netflix se staršími zařízeními, která nové protokoly nepodporují. Ne všechny klienty lze aktualizovat nebo optimálně nakonfigurovat. Přitom mezi CDN proxy a cloudem je kompletní kontrola a možnost používat nové, optimální protokoly a nastavení. Neefektivní část se starými protokoly bude fungovat pouze mezi klientem a serverem CDN. Navíc můžeme provádět multiplexní požadavky na již vytvořené spojení mezi CDN a cloudem, což zlepšuje využití připojení na úrovni TCP:
Měříme
Navzdory tomu, že teorie slibuje vylepšení, nespěcháme hned se spuštěním systému do výroby. Místo toho musíme nejprve prokázat, že nápad bude fungovat v praxi. Chcete-li to provést, musíte odpovědět na několik otázek:
- Rychlost: bude proxy rychlejší?
- Spolehlivost: Bude se to častěji lámat?
- Složitost: jak se integrovat s aplikacemi?
- Stát: Kolik stojí nasazení další infrastruktury?
Podívejme se podrobně na náš přístup k posouzení prvního bodu. Zbytek se řeší podobným způsobem.
Abychom mohli analyzovat rychlost požadavků, chceme získat data pro všechny uživatele, aniž bychom trávili spoustu času vývojem a bez přerušení výroby. K tomu existuje několik přístupů:
- RUM, neboli pasivní měření požadavku. Měříme dobu realizace aktuálních požadavků od uživatelů a zajišťujeme plné pokrytí uživatelů. Nevýhodou je, že signál není příliš stabilní kvůli mnoha faktorům, například kvůli různé velikosti požadavků, době zpracování na serveru a na klientovi. Kromě toho nemůžete testovat novou konfiguraci bez efektu ve výrobě.
- Laboratorní testy. Speciální servery a infrastruktura, které simulují klienty. S jejich pomocí provádíme potřebné testy. Získáme tak plnou kontrolu nad výsledky měření a jasný signál. Neexistuje však úplné pokrytí zařízení a umístění uživatelů (zejména s celosvětovou službou a podporou pro tisíce modelů zařízení).
Jak můžete spojit výhody obou metod?
Náš tým našel řešení. Napsali jsme malý kousek kódu – ukázku – který jsme zabudovali do naší aplikace. Sondy nám umožňují provádět plně řízené síťové testy z našich zařízení. Funguje to takto:
- Krátce po načtení aplikace a dokončení počáteční aktivity spustíme naše sondy.
- Klient zadá požadavek na server a obdrží „recept“ na test. Recept je seznam adres URL, na které je třeba provést požadavek HTTP(s). Kromě toho recept nastavuje parametry požadavku: zpoždění mezi požadavky, množství požadovaných dat, hlavičky HTTP(s) atd. Zároveň můžeme paralelně testovat více různých receptur – při požadavku na konfiguraci náhodně určíme, který recept vydat.
- Čas spuštění sondy je zvolen tak, aby nebyl v konfliktu s aktivním využíváním síťových prostředků na klientovi. V zásadě se čas vybírá, když klient není aktivní.
- Po obdržení receptu klient paralelně zadává požadavky na každou z URL. Požadavek na každou z adres lze opakovat – tzv. „pulzy“. Při prvním pulzu změříme, jak dlouho trvalo navázání spojení a stažení dat. Při druhém impulsu změříme čas potřebný k načtení dat přes již navázané spojení. Před třetím si můžeme nastavit zpoždění a změřit rychlost navázání opětovného připojení atp.
Během testu měříme všechny parametry, které může zařízení získat:
- čas požadavku DNS;
- čas nastavení TCP spojení;
- čas nastavení připojení TLS;
- čas přijetí prvního bajtu dat;
- celková doba načítání;
- kód výsledku stavu.
- Po dokončení všech pulzů vzorek načte všechna měření pro analýzu.
Klíčovými body je minimální závislost na logice na klientovi, zpracování dat na serveru a měření paralelních požadavků. Jsme tak schopni izolovat a testovat vliv různých faktorů ovlivňujících výkon dotazů, měnit je v rámci jednoho receptu a získávat výsledky od skutečných klientů.
Tato infrastruktura se ukázala jako užitečná nejen pro analýzu výkonu dotazů. V současné době máme 14 aktivních receptur, více než 6000 vzorků za sekundu, přijímáme data ze všech koutů země a máme plné pokrytí zařízení. Pokud by Netflix koupil podobnou službu od třetí strany, stálo by to miliony dolarů ročně s mnohem horším pokrytím.
Teorie testování v praxi: prototyp
S takovým systémem jsme byli schopni vyhodnotit efektivitu CDN proxy na latenci požadavku. Nyní potřebujete:
- vytvořit prototyp proxy;
- umístěte prototyp na CDN;
- určit, jak nasměrovat klienty na server proxy na konkrétním serveru CDN;
- Porovnejte výkon s požadavky v AWS bez proxy.
Úkolem je co nejrychleji vyhodnotit efektivitu navrženého řešení. Pro implementaci prototypu jsme zvolili Go kvůli dostupnosti dobrých síťových knihoven. Na každý server CDN jsme nainstalovali prototyp proxy jako statický binární soubor, abychom minimalizovali závislosti a zjednodušili integraci. Při prvotní implementaci jsme v maximální možné míře použili standardní komponenty a drobné úpravy pro sdružování spojení HTTP/2 a multiplexování požadavků.
Abychom dosáhli rovnováhy mezi regiony AWS, použili jsme geografickou databázi DNS, stejnou, která se používá k vyvážení klientů. Pro výběr CDN serveru pro klienta používáme TCP Anycast pro servery v Internet Exchange (IX). V této možnosti používáme jednu IP adresu pro všechny CDN servery a klient bude přesměrován na CDN server s nejmenším počtem IP skoků. Na serverech CDN nainstalovaných poskytovateli internetu (ISP) nemáme kontrolu nad routerem pro konfiguraci TCP Anycast, takže používáme , která přesměrovává zákazníky k poskytovatelům internetu pro streamování videa.
Máme tedy tři typy cest požadavků: do cloudu přes otevřený internet, přes CDN server v IX nebo přes CDN server umístěný u poskytovatele internetu. Naším cílem je pochopit, který způsob je lepší a jaké jsou výhody proxy ve srovnání s tím, jak jsou požadavky odesílány do produkce. K tomu používáme vzorkovací systém takto:
Každá z cest se stává samostatným cílem a my se díváme na čas, který jsme dostali. Pro analýzu zkombinujeme výsledky proxy do jedné skupiny (vybereme nejlepší čas mezi proxy IX a ISP) a porovnáme je s dobou požadavků do cloudu bez proxy:
Jak vidíte, výsledky byly smíšené - ve většině případů proxy poskytuje dobré zrychlení, ale existuje také dostatečné množství klientů, pro které se situace výrazně zhorší.
V důsledku toho jsme udělali několik důležitých věcí:
- Hodnotili jsme očekávaný výkon požadavků od klientů do cloudu přes CDN proxy.
- Získali jsme data od skutečných klientů, ze všech typů zařízení.
- Uvědomili jsme si, že teorie nebyla 100% potvrzena a prvotní nabídka s CDN proxy by pro nás nefungovala.
- Neriskovali jsme – neměnili jsme produkční konfigurace pro klienty.
- Nic nebylo rozbité.
Prototyp 2.0
Vraťte se tedy k rýsovacímu prknu a celý proces opakujte znovu.
Myšlenka je taková, že místo použití 100% proxy určíme pro každého klienta nejrychlejší cestu a tam budeme posílat požadavky – to znamená, že budeme dělat to, čemu se říká klientské řízení.
Jak to implementovat? Nemůžeme použít logiku na straně serveru, protože... cílem je připojit se k tomuto serveru. Musí existovat nějaký způsob, jak to udělat na klientovi. A v ideálním případě to udělejte s minimálním množstvím složité logiky, abyste neřešili problém integrace s velkým počtem klientských platforem.
Odpověď je použít DNS. V našem případě máme vlastní infrastrukturu DNS a můžeme nastavit doménovou zónu, pro kterou budou naše servery autoritativní. Funguje to takto:
- Klient odešle požadavek na server DNS pomocí hostitele, například api.netflix.xom.
- Požadavek dorazí na náš DNS server
- DNS server ví, která cesta je pro tohoto klienta nejrychlejší, a vydá odpovídající IP adresu.
Řešení má další složitost: autoritativní poskytovatelé DNS nevidí IP adresu klienta a mohou číst pouze IP adresu rekurzivního resolveru, který klient používá.
V důsledku toho musí náš autoritářský resolver učinit rozhodnutí nikoli pro jednotlivého klienta, ale pro skupinu klientů na základě rekurzivního resolveru.
K řešení používáme stejné vzorky, agregujeme výsledky měření od klientů pro každý z rekurzivních resolverů a rozhodujeme se, kam tuto skupinu z nich poslat – proxy přes IX pomocí TCP Anycast, přes proxy ISP nebo přímo do cloudu.
Získáme následující systém:
Výsledný model řízení DNS vám umožňuje nasměrovat klienty na základě historických pozorování rychlosti připojení od klientů do cloudu.
Opět je otázkou, jak efektivně bude tento přístup fungovat? Abychom odpověděli, opět používáme náš systém sond. Proto nakonfigurujeme konfiguraci presenteru, kde jeden z cílů sleduje směr z DNS řízení, druhý jde přímo do cloudu (aktuální produkce).
V důsledku toho porovnáme výsledky a získáme hodnocení účinnosti:
Díky tomu jsme se naučili několik důležitých věcí:
- Hodnotili jsme očekávaný výkon požadavků od klientů do cloudu pomocí DNS Steering.
- Získali jsme data od skutečných klientů, ze všech typů zařízení.
- Účinnost navrhované myšlenky byla prokázána.
- Neriskovali jsme – neměnili jsme produkční konfigurace pro klienty.
- Nic nebylo rozbité.
Nyní o nejtěžší části – spustíme to ve výrobě
Nejjednodušší část je nyní u konce – existuje funkční prototyp. Nyní je nejtěžší spuštění řešení pro veškerý provoz Netflixu, nasazení pro 150 milionů uživatelů, tisíce zařízení, stovky mikroslužeb a neustále se měnící produkt a infrastrukturu. Servery Netflix dostávají miliony požadavků za sekundu a je snadné službu přerušit neopatrným jednáním. Zároveň chceme dynamicky směrovat provoz přes tisíce CDN serverů na internetu, kde se neustále a v tu nejméně vhodnou chvíli něco mění a láme.
A s tím vším má tým 3 inženýry odpovědné za vývoj, nasazení a plnou podporu systému.
Proto budeme nadále mluvit o klidném a zdravém spánku.
Jak pokračovat ve vývoji a netrávit veškerý čas na podpoře? Náš přístup je založen na 3 principech:
- Snížíme potenciální rozsah poruch (poloměr výbuchu).
- Připravujeme překvapení – očekáváme, že se i přes testování a osobní zkušenost něco zlomí.
- Půvabná degradace – pokud něco nefunguje správně, mělo by to být automaticky opraveno, i když ne tím nejefektivnějším způsobem.
Ukázalo se, že v našem případě s tímto přístupem k problému dokážeme najít jednoduché a efektivní řešení a výrazně zjednodušit podporu systému. Uvědomili jsme si, že můžeme přidat malý kousek kódu do klienta a sledovat chyby síťových požadavků způsobené problémy s připojením. V případě síťových chyb provedeme záložní zásah přímo do cloudu. Toto řešení nevyžaduje výrazné úsilí pro klientské týmy, ale výrazně snižuje riziko nečekaných poruch a překvapení pro nás.
Samozřejmě, i přes záložní řešení se během vývoje řídíme jasnou disciplínou:
- Ukázkový test.
- A/B testování nebo Kanárské ostrovy.
- Postupné zavádění.
U vzorků byl přístup popsán – změny jsou nejprve testovány pomocí přizpůsobeného receptu.
Pro testování kanárů potřebujeme získat srovnatelné dvojice serverů, na kterých můžeme porovnávat, jak systém funguje před a po změnách. Abychom toho dosáhli, z mnoha našich stránek CDN vybíráme páry serverů, které přijímají srovnatelný provoz:
Poté nainstalujeme sestavení se změnami na server Canary. K vyhodnocení výsledků používáme systém, který porovnává přibližně 100–150 metrik se vzorkem kontrolních serverů:
Pokud bude testování Canary úspěšné, tak jej uvolňujeme postupně, ve vlnách. Neaktualizujeme servery na každém webu současně – ztráta celého webu kvůli problémům má pro uživatele významnější dopad na službu než ztráta stejného počtu serverů na různých místech.
Obecně platí, že účinnost a bezpečnost tohoto přístupu závisí na množství a kvalitě shromážděných metrik. Pro náš systém zrychlení dotazů shromažďujeme metriky ze všech možných komponent:
- od klientů - počet relací a požadavků, sazba návratnosti;
- proxy - statistika počtu a času požadavků;
- DNS - počet a výsledky požadavků;
- cloud edge - počet a čas zpracování požadavků v cloudu.
To vše se shromažďuje do jednoho kanálu a v závislosti na potřebách se rozhodneme, které metriky odeslat do analýzy v reálném čase a které do Elasticsearch nebo Big Data pro podrobnější diagnostiku.
sledujeme
V našem případě provádíme změny na kritické cestě požadavků mezi klientem a serverem. Přitom množství různých komponent na klientovi, na serveru a na cestě přes internet je obrovské. Ke změnám na klientovi i serveru dochází neustále – během práce desítek týmů i přirozených změn v ekosystému. Jsme uprostřed – při diagnostikování problémů je velká šance, že se zapojíme. Proto musíme jasně pochopit, jak definovat, shromažďovat a analyzovat metriky, abychom rychle izolovali problémy.
V ideálním případě plný přístup ke všem typům metrik a filtrů v reálném čase. Ale existuje spousta metrik, takže vyvstává otázka nákladů. V našem případě oddělujeme metriky a vývojové nástroje takto:
K detekci a třídění problémů používáme náš vlastní open source systém v reálném čase и - pro vizualizaci. Ukládá agregované metriky v paměti, je spolehlivý a integruje se s výstražným systémem. Pro lokalizaci a diagnostiku máme přístup k protokolům z Elasticsearch a Kibana. Pro statistickou analýzu a modelování používáme velká data a vizualizaci v Tableau.
Zdá se, že s tímto přístupem je velmi obtížné pracovat. Díky hierarchickému uspořádání metrik a nástrojů však můžeme rychle analyzovat problém, určit typ problému a poté proniknout do podrobných metrik. Obecně strávíme asi 1-2 minuty určením zdroje poruchy. Poté pracujeme s konkrétním týmem na diagnostice - od desítek minut až po několik hodin.
I když je diagnóza provedena rychle, nechceme, aby se to stávalo často. V ideálním případě obdržíme kritické upozornění pouze tehdy, když dojde k významnému dopadu na službu. Pro náš systém zrychlení dotazů máme pouze 2 upozornění, která vás upozorní:
- Klient Fallback procento - hodnocení chování zákazníků;
- procento Chyby sondy - údaje o stabilitě síťových komponent.
Tyto kritické výstrahy sledují, zda systém funguje pro většinu uživatelů. Podíváme se na to, kolik klientů použilo záložní řešení, pokud nemohli získat akceleraci požadavků. V průměru dostaneme méně než 1 kritické upozornění za týden, i když v systému probíhá spousta změn. Proč nám to stačí?
- Pokud náš proxy nefunguje, dojde k nouzovému řešení klienta.
- K dispozici je automatický systém řízení, který reaguje na problémy.
Další podrobnosti o tom druhém. Náš zkušební systém a systém pro automatické určování optimální cesty pro požadavky od klienta do cloudu nám umožňuje automaticky se vypořádat s některými problémy.
Vraťme se k naší ukázkové konfiguraci a 3 kategoriím cest. Kromě doby načítání se můžeme podívat na samotný fakt doručení. Pokud nebylo možné načíst data, pak při pohledu na výsledky po různých cestách můžeme určit, kde a co se pokazilo a zda to můžeme automaticky opravit změnou cesty požadavku.
Příklady:
Tento proces lze automatizovat. Zahrňte jej do systému řízení. A naučit jej reagovat na problémy s výkonem a spolehlivostí. Pokud se něco začne lámat, reagujte, pokud existuje lepší možnost. Okamžitá reakce přitom není kritická díky záložním klientům.
Principy systémové podpory lze tedy formulovat takto:
- snížení rozsahu poruch;
- shromažďování metrik;
- Pokud je to možné, automaticky opravujeme poruchy;
- pokud to nejde, upozorníme vás;
- Pracujeme na řídicích panelech a sadě nástrojů pro třídění pro rychlou odezvu.
Ponaučení
Psaní prototypu nezabere mnoho času. V našem případě to bylo hotové po 4 měsících. S ním jsme obdrželi nové metriky a 10 měsíců po zahájení vývoje jsme získali první produkční provoz. Pak začala únavná a velmi obtížná práce: postupně produktovat a škálovat systém, migrovat hlavní provoz a učit se z chyb. Tento efektivní proces však nebude lineární – přes veškerou snahu nelze vše předvídat. Mnohem efektivnější je rychle iterovat a reagovat na nová data.
Na základě našich zkušeností můžeme doporučit následující:
- Nevěřte své intuici.
Naše intuice nás neustále selhávala, navzdory rozsáhlým zkušenostem členů našeho týmu. Nesprávně jsme například předpověděli očekávané zrychlení při použití CDN proxy nebo chování TCP Anycast.
- Získejte data z výroby.
Je důležité získat co nejrychleji přístup k alespoň malému množství výrobních dat. V laboratorních podmínkách je téměř nemožné získat počet unikátních případů, konfigurací a nastavení. Rychlý přístup k výsledkům vám umožní rychle se dozvědět o potenciálních problémech a zohlednit je v architektuře systému.
- Nenásledujte rady a výsledky jiných lidí – sbírejte svá vlastní data.
Dodržujte zásady pro sběr a analýzu dat, ale nepřijímejte slepě výsledky a prohlášení jiných lidí. Jen vy můžete přesně vědět, co pro vaše uživatele funguje. Vaše systémy a vaši zákazníci se mohou výrazně lišit od jiných společností. Naštěstí jsou nyní k dispozici analytické nástroje, které se snadno používají. Výsledky, které získáte, nemusí být takové, jaké tvrdí Netflix, Facebook, Akamai a další společnosti. V našem případě se výkon TLS, HTTP2 nebo statistiky DNS požadavků liší od výsledků Facebooku, Uberu, Akamai – máme totiž jiná zařízení, klienty a datové toky.
- Nesledujte zbytečně módní trendy a hodnoťte efektivitu.
Začněte jednoduše. Je lepší vytvořit jednoduchý fungující systém v krátkém čase, než trávit obrovské množství času vývojem komponent, které nepotřebujete. Vyřešte úkoly a problémy, které jsou důležité, na základě vašich měření a výsledků.
- Připravte se na nové aplikace.
Stejně jako je obtížné předvídat všechny problémy, je obtížné předem předvídat přínosy a aplikace. Vezměte si příklad ze startupů – jejich schopnost přizpůsobit se podmínkám zákazníků. Ve vašem případě možná objevíte nové problémy a jejich řešení. V našem projektu jsme si stanovili cíl snížit latenci požadavků. Během analýzy a diskusí jsme si však uvědomili, že můžeme použít i proxy servery:
- vyvážit provoz napříč regiony AWS a snížit náklady;
- modelovat stabilitu CDN;
- konfigurovat DNS;
- pro konfiguraci TLS/TCP.
Závěr
V reportáži jsem popsal, jak Netflix řeší problém zrychlení internetových požadavků mezi klienty a cloudem. Jak shromažďujeme data pomocí vzorkovacího systému o klientech a jak používáme shromážděná historická data ke směrování produkčních požadavků od klientů nejrychlejší cestou na internetu. Jak využíváme principy síťových protokolů, naši CDN infrastrukturu, páteřní síť a DNS servery k dosažení tohoto úkolu.
Naše řešení je však jen příkladem toho, jak jsme v Netflixu takový systém implementovali. Co se nám osvědčilo. Aplikovanou částí mé zprávy pro vás jsou zásady rozvoje a podpory, které dodržujeme a dosahujeme dobrých výsledků.
Naše řešení problému vám nemusí vyhovovat. Teorie a principy návrhu však zůstávají zachovány, i když nemáte vlastní infrastrukturu CDN, nebo se od té naší výrazně liší.
Důležitá zůstává také důležitost rychlosti obchodních požadavků. A dokonce i u jednoduché služby si musíte vybrat: mezi poskytovateli cloudu, umístěním serveru, poskytovateli CDN a DNS. Vaše volba ovlivní efektivitu internetových dotazů pro vaše zákazníky. A je důležité, abyste tento vliv změřili a pochopili.
Začněte jednoduchými řešeními, dejte si záležet na tom, jak produkt měníte. Učte se za pochodu a vylepšujte systém na základě dat od vašich zákazníků, vaší infrastruktury a vašeho podnikání. Myslete na možnost neočekávaných poruch během procesu návrhu. A pak můžete urychlit proces vývoje, zlepšit efektivitu řešení, vyhnout se zbytečné zátěži podpory a klidně spát.
tento rok v online formátu. Můžete se zeptat jednoho z otců DevOps, samotného Johna Willise!
Zdroj: www.habr.com