Netflix je vodilni na trgu internetne televizije - podjetje, ki je ustvarilo in aktivno razvija ta segment. Netflix ni znan samo po svojem obsežnem katalogu filmov in TV serij, ki so na voljo iz skoraj vseh koncev planeta in katere koli naprave z zaslonom, ampak tudi po svoji zanesljivi infrastrukturi in edinstveni inženirski kulturi.
Jasen primer Netflixovega pristopa k razvoju in podpori kompleksnih sistemov je bil predstavljen na DevOops 2019 - Direktor razvoja pri Netflixu. Diplomiral na Fakulteti za računalniško matematiko in matematiko Državne univerze v Nižnem Novgorodu. Lobačevski, Sergej, eden prvih inženirjev v ekipi Open Connect - CDN pri Netflixu. Gradil je sisteme za spremljanje in analizo video podatkov, lansiral priljubljeno storitev za ocenjevanje hitrosti internetne povezave FAST.com, zadnja leta pa se ukvarja z optimizacijo internetnih zahtev, da bi aplikacija Netflix uporabnikom delovala čim hitreje.
Poročilo je prejelo najboljše kritike udeležencev konference, za vas smo pripravili besedilno različico.
V svojem poročilu je Sergej podrobno govoril
- o tem, kaj vpliva na zakasnitev internetnih zahtev med odjemalcem in strežnikom;
- kako zmanjšati to zamudo;
- kako načrtovati, vzdrževati in spremljati sisteme, odporne na napake;
- kako doseči rezultate v kratkem času in z minimalnim tveganjem za podjetje;
- kako analizirati rezultate in se učiti iz napak.
Odgovorov na ta vprašanja ne potrebujejo le tisti, ki delajo v velikih korporacijah.
Predstavljena načela in tehnike bi morali poznati in izvajati vsi, ki razvijajo in podpirajo internetne izdelke.
Sledi pripoved z govorčeve perspektive.
Pomen hitrosti interneta
Hitrost internetnih zahtev je neposredno povezana s poslovanjem. Razmislite o nakupovalni industriji: Amazon leta 2009 da zakasnitev 100 ms povzroči izgubo 1 % prodaje.
Vse več je mobilnih naprav, sledijo jim mobilne strani in aplikacije. Če se vaša stran nalaga dlje kot 3 sekunde, izgubite približno polovico svojih uporabnikov. Z Google upošteva hitrost nalaganja vaše strani v rezultatih iskanja: hitrejša ko je stran, višja je njena pozicija v Googlu.
Hitrost povezave je pomembna tudi v finančnih institucijah, kjer je zakasnitev kritična. Leta 2015 Hibernia Networks 400 milijonov dolarjev vreden kabel med New Yorkom in Londonom za zmanjšanje zakasnitve med mestoma za 6 ms. Predstavljajte si 66 milijonov dolarjev za 1 ms zmanjšanja zakasnitve!
Glede na , hitrost povezave nad 5 Mbit/s ne vpliva več neposredno na hitrost nalaganja običajnega spletnega mesta. Vendar pa obstaja linearna povezava med zakasnitvijo povezave in hitrostjo nalaganja strani:
Vendar pa Netflix ni tipičen izdelek. Vpliv zakasnitve in hitrosti na uporabnika je aktivno področje analize in razvoja. Nalaganje aplikacij in izbira vsebine sta odvisna od zakasnitve, vendar sta nalaganje statičnih elementov in pretakanje odvisna tudi od hitrosti povezave. Analiza in optimizacija ključnih dejavnikov, ki vplivajo na uporabniško izkušnjo, je aktivno področje razvoja več ekip pri Netflixu. Eden od ciljev je zmanjšati zakasnitev zahtev med napravami Netflix in infrastrukturo v oblaku.
V poročilu se bomo posebej osredotočili na zmanjšanje zakasnitve na primeru infrastrukture Netflix. Razmislimo s praktičnega vidika, kako pristopiti k procesom oblikovanja, razvoja in delovanja kompleksnih porazdeljenih sistemov ter porabiti čas za inovacije in rezultate, namesto da diagnosticiramo operativne težave in okvare.
Znotraj Netflixa
Na tisoče različnih naprav podpira aplikacije Netflix. Razvijajo jih štiri različne ekipe, ki izdelujejo ločene različice odjemalca za Android, iOS, TV in spletne brskalnike. In veliko truda vlagamo v izboljšanje in personalizacijo uporabniške izkušnje. Da bi to dosegli, izvajamo na stotine A/B testov vzporedno.
Personalizacijo podpira na stotine mikrostoritev v oblaku AWS, ki zagotavljajo prilagojene uporabniške podatke, pošiljanje poizvedb, telemetrijo, velike podatke in kodiranje. Vizualizacija prometa izgleda takole:
Na levi je vstopna točka, nato pa se promet porazdeli med več sto mikroservisov, ki jih podpirajo različne zaledne ekipe.
Druga pomembna komponenta naše infrastrukture je Open Connect CDN, ki končnemu uporabniku dostavlja statično vsebino – videe, slike, kodo odjemalca itd. CDN se nahaja na strežnikih po meri (OCA - Open Connect Appliance). V notranjosti so nizi pogonov SSD in HDD, ki poganjajo optimiziran FreeBSD, z NGINX in nizom storitev. Načrtujemo in optimiziramo komponente strojne in programske opreme, da lahko tak CDN strežnik uporabnikom pošlje čim več podatkov.
"Zid" teh strežnikov na točki izmenjave internetnega prometa (Internet eXchange - IX) izgleda takole:
Internetna izmenjava omogoča ponudnikom internetnih storitev in ponudnikom vsebine, da se »povezujejo« med seboj za bolj neposredno izmenjavo podatkov na internetu. Po vsem svetu je približno 70-80 točk internetne izmenjave, kjer so nameščeni naši strežniki, ki jih samostojno postavljamo in vzdržujemo:
Poleg tega nudimo tudi strežnike neposredno internetnim ponudnikom, ki jih le-ti namestijo v svoje omrežje, s čimer izboljšamo lokalizacijo Netflix prometa in kakovost pretakanja za uporabnike:
Niz storitev AWS je odgovoren za pošiljanje video zahtev odjemalcev do strežnikov CDN, kot tudi za konfiguracijo samih strežnikov - posodabljanje vsebine, programske kode, nastavitev itd. Za slednjo smo zgradili tudi hrbtenično omrežje, ki povezuje strežnike v Internet Exchange točkah z AWS. Hrbtenično omrežje je globalno omrežje optičnih kablov in usmerjevalnikov, ki jih lahko oblikujemo in konfiguriramo glede na naše potrebe.
Na , naša infrastruktura CDN zagotavlja približno ⅛ svetovnega internetnega prometa v konicah in ⅓ prometa v Severni Ameriki, kjer je Netflix prisoten najdlje. Impresivne številke, a zame je eden najbolj neverjetnih dosežkov ta, da celoten sistem CDN razvija in vzdržuje ekipa manj kot 150 ljudi.
Sprva je bila infrastruktura CDN zasnovana za dostavo video podatkov. Sčasoma pa smo ugotovili, da ga lahko uporabimo tudi za optimizacijo dinamičnih zahtev strank v oblaku AWS.
O internetnem pospeševanju
Danes ima Netflix 3 regije AWS, zakasnitev zahtevkov v oblak pa bo odvisna od tega, kako daleč je stranka od najbližje regije. Hkrati imamo veliko strežnikov CDN, ki se uporabljajo za dostavo statične vsebine. Ali obstaja kakšen način za uporabo tega ogrodja za pospešitev dinamičnih poizvedb? Vendar je na žalost teh zahtev nemogoče predpomniti – API-ji so prilagojeni in vsak rezultat je edinstven.
Naredimo proxy na strežniku CDN in začnimo pošiljati promet prek njega. Bo hitreje?
Material
Spomnimo se, kako delujejo omrežni protokoli. Danes večina internetnega prometa uporablja protokole HTTP, ki so odvisni od protokolov nižje plasti TCP in TLS. Da se odjemalec poveže s strežnikom, opravi rokovanje, za vzpostavitev varne povezave pa mora odjemalec s strežnikom trikrat izmenjati sporočila in vsaj še enkrat za prenos podatkov. Z zakasnitvijo na povratno potovanje (RTT) 100 ms bi potrebovali 400 ms, da prejmemo prvi bit podatkov:
Če certifikate postavimo na CDN strežnik, potem se lahko čas rokovanja med odjemalcem in strežnikom bistveno zmanjša, če je CDN bližje. Predpostavimo, da je zakasnitev do strežnika CDN 30 ms. Nato bo trajalo 220 ms, da prejmemo prvi bit:
A prednosti se tu ne končajo. Ko je povezava vzpostavljena, TCP poveča okno zastojev (količino informacij, ki jih lahko vzporedno prenese prek te povezave). Če se podatkovni paket izgubi, potem klasične izvedbe protokola TCP (kot je TCP New Reno) zmanjšajo odprto "okno" za polovico. Rast okna zastojev in hitrost njegovega okrevanja po izgubi je spet odvisna od zakasnitve (RTT) do strežnika. Če ta povezava sega samo do strežnika CDN, bo ta obnovitev hitrejša. Hkrati je izguba paketov standarden pojav, zlasti za brezžična omrežja.
Internetna pasovna širina je lahko zmanjšana, zlasti v konicah, zaradi prometa uporabnikov, kar lahko povzroči prometne zastoje. Vendar na internetu ni možnosti, da bi nekaterim zahtevam dali prednost pred drugimi. Na primer, dajte prednost majhnim in na zakasnitev občutljivim zahtevam pred "težkimi" podatkovnimi tokovi, ki obremenjujejo omrežje. V našem primeru pa nam lastno hrbtenično omrežje omogoča, da to naredimo na delu poti zahteve – med CDN in oblakom, in ga lahko v celoti konfiguriramo. Prepričate se lahko, da imajo prednost majhni paketi in paketi, ki so občutljivi na zakasnitev, veliki tokovi podatkov pa gredo nekoliko pozneje. Bližje kot je CDN stranki, večja je učinkovitost.
Na zakasnitev vplivajo tudi protokoli na ravni aplikacije (OSI Level 7). Novi protokoli, kot je HTTP/2, optimizirajo delovanje vzporednih zahtev. Vendar pa imamo odjemalce Netflix s starejšimi napravami, ki ne podpirajo novih protokolov. Vseh odjemalcev ni mogoče posodobiti ali optimalno konfigurirati. Hkrati je med CDN proxyjem in oblakom popoln nadzor in možnost uporabe novih, optimalnih protokolov in nastavitev. Neučinkovit del s starimi protokoli bo deloval samo med odjemalcem in strežnikom CDN. Poleg tega lahko izvajamo multipleksne zahteve na že vzpostavljeni povezavi med CDN in oblakom, kar izboljša izkoriščenost povezave na ravni TCP:
Merimo
Kljub temu, da teorija obljublja izboljšave, ne hitimo takoj z zagonom sistema v proizvodnji. Namesto tega moramo najprej dokazati, da bo ideja delovala v praksi. Če želite to narediti, morate odgovoriti na več vprašanj:
- Hitro: bo proxy hitrejši?
- Zanesljivost: Se bo pogosteje zlomil?
- Težavnost: kako se integrirati z aplikacijami?
- Stroški: Koliko stane postavitev dodatne infrastrukture?
Oglejmo si podrobno naš pristop k oceni prve točke. Ostali se obravnavajo na podoben način.
Za analizo hitrosti zahtevkov želimo pridobiti podatke za vse uporabnike, ne da bi porabili veliko časa za razvoj in brez prekinitve proizvodnje. Za to obstaja več pristopov:
- RUM ali merjenje pasivne zahteve. Merimo čas izvedbe trenutnih zahtev uporabnikov in zagotavljamo popolno pokritost uporabnikov. Pomanjkljivost je, da signal ni zelo stabilen zaradi številnih dejavnikov, na primer zaradi različnih velikosti zahtev, časa obdelave na strežniku in odjemalcu. Poleg tega ne morete preizkusiti nove konfiguracije brez učinka v proizvodnji.
- Laboratorijske preiskave. Posebni strežniki in infrastruktura, ki simulirajo odjemalce. Z njihovo pomočjo opravimo potrebne teste. Tako dobimo popoln nadzor nad rezultati meritev in jasen signal. Ni pa popolne pokritosti naprav in lokacij uporabnikov (zlasti s storitvijo po vsem svetu in podporo za tisoče modelov naprav).
Kako lahko združite prednosti obeh metod?
Naša ekipa je našla rešitev. Napisali smo majhen delček kode – vzorec – ki smo ga vgradili v našo aplikacijo. Sonde nam omogočajo izvajanje popolnoma nadzorovanih omrežnih testov iz naših naprav. Deluje takole:
- Kmalu po nalaganju aplikacije in zaključku začetne dejavnosti zaženemo svoje sonde.
- Odjemalec pošlje zahtevo strežniku in prejme "recept" za test. Recept je seznam URL-jev, na katere je treba poslati zahtevo HTTP(s). Poleg tega recept konfigurira parametre zahteve: zakasnitve med zahtevami, količino zahtevanih podatkov, glave HTTP(s) itd. Hkrati lahko testiramo več različnih receptov vzporedno - ob zahtevi po konfiguraciji naključno določimo, kateri recept bomo izdali.
- Čas zagona sonde je izbran tako, da ni v nasprotju z aktivno uporabo omrežnih virov na odjemalcu. V bistvu se izbere čas, ko odjemalec ni aktiven.
- Po prejemu recepta odjemalec vzporedno zahteva zahteve na vsakem od URL-jev. Povpraševanje na vsakega od naslovov se lahko ponovi – t.i. "stročnice". Ob prvem impulzu izmerimo, koliko časa je trajalo vzpostavljanje povezave in prenos podatkov. Na drugem impulzu izmerimo čas nalaganja podatkov preko že vzpostavljene povezave. Pred tretjim lahko nastavimo zakasnitev in merimo hitrost vzpostavljanja ponovne povezave itd.
Med testom izmerimo vse parametre, ki jih naprava lahko pridobi:
- čas zahteve DNS;
- čas vzpostavitve povezave TCP;
- čas vzpostavitve povezave TLS;
- čas prejema prvega bajta podatkov;
- skupni čas nalaganja;
- koda rezultata stanja.
- Ko so vsi impulzi zaključeni, vzorec naloži vse meritve za analizo.
Ključne točke so minimalna odvisnost od logike na odjemalcu, obdelava podatkov na strežniku in merjenje vzporednih zahtev. Tako lahko izoliramo in testiramo vpliv različnih dejavnikov, ki vplivajo na uspešnost poizvedbe, jih spreminjamo znotraj enega samega recepta in pridobimo rezultate od resničnih strank.
Ta infrastruktura se je izkazala za uporabno za več kot le analizo uspešnosti poizvedb. Trenutno imamo 14 aktivnih receptov, več kot 6000 vzorcev na sekundo, prejemanje podatkov z vseh koncev sveta in popolno pokritost naprave. Če bi Netflix kupil podobno storitev od tretje osebe, bi to stalo na milijone dolarjev na leto, z veliko slabšo pokritostjo.
Teorija testiranja v praksi: prototip
S takšnim sistemom smo lahko ocenili učinkovitost CDN proxyjev pri zakasnitvi zahteve. Zdaj potrebujete:
- ustvarite proxy prototip;
- postavite prototip na CDN;
- določiti, kako usmeriti odjemalce na proxy na določenem strežniku CDN;
- Primerjajte zmogljivost z zahtevami v AWS brez proxyja.
Naloga je čim hitreje oceniti učinkovitost predlagane rešitve. Za izvedbo prototipa smo izbrali Go zaradi razpoložljivosti dobrih omrežnih knjižnic. Na vsak strežnik CDN smo namestili prototipni proxy kot statično dvojiško datoteko, da zmanjšamo odvisnosti in poenostavimo integracijo. Pri začetni implementaciji smo v največji možni meri uporabili standardne komponente in manjše modifikacije za zbiranje povezav HTTP/2 in multipleksiranje zahtev.
Za uravnoteženje med regijami AWS smo uporabili geografsko zbirko podatkov DNS, enako kot za uravnoteženje strank. Za izbiro strežnika CDN za odjemalca uporabljamo TCP Anycast za strežnike v Internet Exchange (IX). Pri tej možnosti uporabljamo en naslov IP za vse strežnike CDN, odjemalec pa bo usmerjen na strežnik CDN z najmanjšim številom skokov IP. V strežnikih CDN, ki jih namestijo internetni ponudniki (ISP), nimamo nadzora nad usmerjevalnikom za konfiguracijo TCP Anycast, zato uporabljamo , ki stranke usmerja k internetnim ponudnikom za pretakanje videa.
Imamo torej tri vrste poti zahtev: v oblak prek odprtega interneta, prek strežnika CDN v IX ali prek strežnika CDN, ki se nahaja pri internetnem ponudniku. Naš cilj je razumeti, kateri način je boljši in kakšne so prednosti posrednika v primerjavi s tem, kako se zahteve pošiljajo v produkcijo. Za to uporabljamo naslednji sistem vzorčenja:
Vsaka od poti postane posebna tarča in gledamo na čas, ki smo ga dobili. Za analizo združimo rezultate proxyja v eno skupino (izberemo najboljši čas med proxyjem IX in ISP) in jih primerjamo s časom zahtevkov v oblak brez proxyja:
Kot lahko vidite, so bili rezultati mešani - v večini primerov proxy daje dobro pospešitev, vendar obstaja tudi zadostno število strank, pri katerih se bo stanje znatno poslabšalo.
Posledično smo naredili več pomembnih stvari:
- Ocenili smo pričakovano uspešnost zahtev odjemalcev v oblak prek proxyja CDN.
- Podatke smo prejeli od realnih strank, z vseh vrst naprav.
- Ugotovili smo, da teorija ni 100-odstotno potrjena in da začetna ponudba s CDN proxyjem ne bi delovala za nas.
- Nismo tvegali - nismo spreminjali proizvodnih konfiguracij za stranke.
- Nič ni bilo pokvarjeno.
Prototip 2.0
Torej, nazaj na risalno desko in ponovite postopek znova.
Ideja je, da namesto uporabe 100-odstotnega proxyja določimo najhitrejšo pot za vsako stranko in tja pošljemo zahteve – to pomeni, da bomo naredili to, kar se imenuje usmerjanje strank.
Kako to izvesti? Na strani strežnika ne moremo uporabiti logike, ker ... Cilj je vzpostaviti povezavo s tem strežnikom. Potreben je način, da to storite na stranki. In idealno je, da to storite z minimalno količino kompleksne logike, da ne rešite vprašanja integracije z velikim številom odjemalskih platform.
Odgovor je uporaba DNS. V našem primeru imamo lastno infrastrukturo DNS in lahko nastavimo domensko cono, za katero bodo naši strežniki avtoritarni. Deluje takole:
- Odjemalec pošlje zahtevo strežniku DNS z uporabo gostitelja, na primer api.netflix.xom.
- Zahteva prispe na naš DNS strežnik
- Strežnik DNS ve, katera pot je najhitrejša za tega odjemalca, in izda ustrezen naslov IP.
Rešitev ima dodatno zapletenost: avtoritarni ponudniki DNS ne vidijo odjemalčevega naslova IP in lahko preberejo samo naslov IP rekurzivnega razreševalnika, ki ga odjemalec uporablja.
Posledično se mora naš avtoritarni razreševalec odločiti ne za posameznega odjemalca, ampak za skupino odjemalcev na podlagi rekurzivnega razreševalca.
Za rešitev uporabimo iste vzorce, združimo rezultate meritev odjemalcev za vsakega od rekurzivnih razreševalcev in se odločimo, kam bomo poslali to skupino le-teh – proxy prek IX z uporabo TCP Anycast, prek proxyja ponudnika internetnih storitev ali neposredno v oblak.
Dobimo naslednji sistem:
Nastali model krmiljenja DNS vam omogoča usmerjanje odjemalcev na podlagi zgodovinskih opazovanj hitrosti povezav odjemalcev v oblak.
Spet je vprašanje, kako učinkovito bo ta pristop deloval? Za odgovor ponovno uporabimo naš sistem sond. Zato konfiguriramo konfiguracijo predstavitelja, kjer eden od ciljev sledi smeri iz krmiljenja DNS, drugi pa gre neposredno v oblak (trenutna produkcija).
Posledično primerjamo rezultate in dobimo oceno učinkovitosti:
Posledično smo se naučili več pomembnih stvari:
- Z DNS Steering smo ocenili pričakovano uspešnost zahtev odjemalcev v oblak.
- Podatke smo prejeli od realnih strank, z vseh vrst naprav.
- Učinkovitost predlagane ideje je dokazana.
- Nismo tvegali - nismo spreminjali proizvodnih konfiguracij za stranke.
- Nič ni bilo pokvarjeno.
Zdaj o težkem delu - lansiramo ga v proizvodnjo
Enostavnega dela je zdaj konec - obstaja delujoč prototip. Zdaj je težji del uvedba rešitve za ves Netflixov promet, uvedba na 150 milijonov uporabnikov, tisoče naprav, stotine mikrostoritev ter nenehno spreminjajoči se izdelek in infrastruktura. Strežniki Netflix prejmejo na milijone zahtev na sekundo in storitev je zlahka prekiniti z neprevidnim dejanjem. Hkrati pa želimo dinamično usmerjati promet skozi tisoče CDN strežnikov na internetu, kjer se nenehno in ob najbolj neprimernem trenutku nekaj spreminja in kvari.
In ob vsem tem ima ekipa 3 inženirje, odgovorne za razvoj, uvajanje in popolno podporo sistema.
Zato bomo še naprej govorili o mirnem in zdravem spancu.
Kako nadaljevati z razvojem in ne porabiti ves svoj čas za podporo? Naš pristop temelji na treh načelih:
- Zmanjšamo potencialni obseg okvar (radij eksplozije).
- Pripravljamo se na presenečenja - pričakujemo, da se bo kljub testiranju in osebnim izkušnjam kaj zalomilo.
- Elegantna degradacija – če nekaj ne deluje pravilno, je treba samodejno popraviti, četudi ne na najbolj učinkovit način.
Izkazalo se je, da lahko v našem primeru s takšnim pristopom k problemu najdemo enostavno in učinkovito rešitev ter bistveno poenostavimo sistemsko podporo. Ugotovili smo, da lahko odjemalcu dodamo majhen košček kode in spremljamo napake omrežne zahteve, ki jih povzročajo težave s povezavo. V primeru napak v omrežju izvedemo nadomestni povratek neposredno v oblak. Ta rešitev ne zahteva velikega napora za ekipe strank, vendar močno zmanjša tveganje nepričakovanih okvar in presenečenj za nas.
Seveda, kljub rezervi, kljub temu sledimo jasni disciplini pri razvoju:
- Vzorčni test.
- A/B testiranje ali kanarčki.
- Postopno uvajanje.
Z vzorci je opisan pristop - spremembe se najprej testirajo po prilagojeni recepturi.
Za kanarčkovo testiranje moramo pridobiti primerljive pare strežnikov, na katerih lahko primerjamo delovanje sistema pred in po spremembah. Da bi to naredili, iz naših številnih spletnih mest CDN izberemo pare strežnikov, ki prejemajo primerljiv promet:
Nato gradnjo s spremembami namestimo na strežnik Canary. Za ovrednotenje rezultatov zaženemo sistem, ki primerja približno 100–150 metrik z vzorcem nadzornih strežnikov:
Če je testiranje kanarčka uspešno, ga sproščamo postopoma, v valovih. Ne posodabljamo strežnikov na vsakem spletnem mestu hkrati - izguba celotnega spletnega mesta zaradi težav ima pomembnejši vpliv na storitev za uporabnike kot izguba enakega števila strežnikov na različnih lokacijah.
Na splošno sta učinkovitost in varnost tega pristopa odvisni od količine in kakovosti zbranih meritev. Za naš sistem pospeševanja poizvedb zbiramo metrike iz vseh možnih komponent:
- od strank - število sej in zahtevkov, rezervne stopnje;
- proxy - statistika števila in časa zahtevkov;
- DNS - število in rezultati zahtevkov;
- cloud edge - število in čas obdelave zahtevkov v oblaku.
Vse to je zbrano v enem samem cevovodu in glede na potrebe se odločimo, katere metrike bomo poslali v analitiko v realnem času in katere v Elasticsearch ali Big Data za podrobnejšo diagnostiko.
Spremljamo
V našem primeru delamo spremembe na kritični poti zahtev med odjemalcem in strežnikom. Hkrati pa je število različnih komponent na odjemalcu, na strežniku in na poti po internetu ogromno. Spremembe na odjemalcu in strežniku se dogajajo nenehno – med delom več deset ekip in naravnimi spremembami v ekosistemu. Smo v sredini – pri diagnosticiranju težav obstaja velika verjetnost, da bomo tudi mi vpleteni. Zato moramo jasno razumeti, kako opredeliti, zbrati in analizirati meritve za hitro izolacijo težav.
V idealnem primeru popoln dostop do vseh vrst meritev in filtrov v realnem času. Toda meritev je veliko, zato se postavlja vprašanje stroškov. V našem primeru ločimo meritve in razvojna orodja na naslednji način:
Za odkrivanje in sortiranje težav uporabljamo lasten odprtokodni sistem v realnem času и - za vizualizacijo. V pomnilnik shranjuje združene meritve, je zanesljiv in se integrira s sistemom za opozarjanje. Za lokalizacijo in diagnostiko imamo dostop do dnevnikov Elasticsearch in Kibana. Za statistično analizo in modeliranje uporabljamo velike podatke in vizualizacijo v Tableau.
Zdi se, da je s tem pristopom zelo težko delati. Vendar pa lahko s hierarhično organizacijo meritev in orodij hitro analiziramo težavo, določimo vrsto težave in se nato poglobimo v podrobne meritve. Na splošno porabimo približno 1-2 minuti, da ugotovimo vir okvare. Nato z določeno ekipo delamo na diagnostiki - od deset minut do nekaj ur.
Tudi če je diagnoza opravljena hitro, ne želimo, da bi se to dogajalo pogosto. V idealnem primeru bomo kritično opozorilo prejeli le, ko bo prišlo do pomembnega vpliva na storitev. Za naš sistem pospeševanja poizvedb imamo samo 2 opozorili, ki vas obvestita:
- Client Fallback percentage - ocena vedenja strank;
- odstotek Napake sonde - podatki o stabilnosti omrežnih komponent.
Ta kritična opozorila spremljajo, ali sistem deluje za večino uporabnikov. Pregledamo, koliko strank je uporabilo nadomestno storitev, če niso mogle pridobiti pospeševanja zahtev. V povprečju prejmemo manj kot 1 kritično opozorilo na teden, čeprav se v sistemu dogaja ogromno sprememb. Zakaj nam je to dovolj?
- Obstaja nadomestni odjemalec, če naš proxy ne deluje.
- Obstaja sistem samodejnega krmiljenja, ki se odziva na težave.
Več podrobnosti o slednjem. Naš poskusni sistem in sistem za samodejno določanje optimalne poti za zahteve od odjemalca do oblaka nam omogoča, da se z nekaterimi težavami samodejno spoprimemo.
Vrnimo se k naši vzorčni konfiguraciji in 3 kategorijam poti. Poleg časa nakladanja lahko pogledamo tudi samo dostavo. Če podatkov ni bilo mogoče naložiti, lahko s pregledovanjem rezultatov po različnih poteh ugotovimo, kje in kaj se je pokvarilo ter ali lahko to samodejno popravimo s spremembo poti zahteve.
Primeri:
Ta postopek je mogoče avtomatizirati. Vključite ga v krmilni sistem. In ga naučite, da se odzove na težave z zmogljivostjo in zanesljivostjo. Če se kaj začne kvariti, reagirajte, če obstaja boljša možnost. Hkrati pa takojšnja reakcija ni kritična, zahvaljujoč nadomestnim strankam.
Tako lahko načela sistemske podpore formuliramo na naslednji način:
- zmanjšanje obsega okvar;
- zbiranje metrik;
- Samodejno popravimo okvare, če lahko;
- če ne more, vas obvestimo;
- Delamo na nadzornih ploščah in naboru triažnih orodij za hiter odziv.
Naučena lekcija
Pisanje prototipa ne vzame veliko časa. V našem primeru je bil pripravljen po 4 mesecih. Z njim smo prejeli nove metrike, 10 mesecev po začetku razvoja pa prvi produkcijski promet. Nato se je začelo dolgočasno in zelo težko delo: postopna proizvodnja in skaliranje sistema, selitev glavnega prometa in učenje na napakah. Vendar ta učinkoviti proces ne bo linearen – kljub vsem prizadevanjem ni mogoče vsega predvideti. Veliko bolj učinkovito je hitro ponoviti in se odzvati na nove podatke.
Na podlagi naših izkušenj lahko priporočamo naslednje:
- Ne zaupajte svoji intuiciji.
Naša intuicija nas je nenehno izneverila, kljub bogatim izkušnjam članov naše ekipe. Na primer, napačno smo predvideli pričakovano pospešitev zaradi uporabe proxyja CDN ali obnašanje TCP Anycast.
- Pridobite podatke iz proizvodnje.
Pomembno je čim hitreje pridobiti dostop do vsaj majhne količine proizvodnih podatkov. Skoraj nemogoče je pridobiti število edinstvenih primerov, konfiguracij in nastavitev v laboratorijskih pogojih. Hiter dostop do rezultatov vam bo omogočil hitro spoznavanje morebitnih težav in njihovo upoštevanje v sistemski arhitekturi.
- Ne sledite nasvetom in rezultatom drugih ljudi – zbirajte svoje podatke.
Upoštevajte načela zbiranja in analiziranja podatkov, vendar ne sprejemajte slepo rezultatov in izjav drugih ljudi. Samo vi lahko natančno veste, kaj deluje za vaše uporabnike. Vaši sistemi in vaše stranke se lahko bistveno razlikujejo od drugih podjetij. Na srečo so orodja za analizo zdaj na voljo in enostavna za uporabo. Rezultati, ki jih dobite, morda niso takšni, kot trdijo Netflix, Facebook, Akamai in druga podjetja. V našem primeru se delovanje TLS, HTTP2 ali statistika na DNS zahtevah razlikuje od rezultatov Facebooka, Uberja, Akamaia – ker imamo drugačne naprave, odjemalce in tokove podatkov.
- Ne sledite po nepotrebnem modnim trendom in ocenite učinkovitost.
Začni preprosto. Bolje je narediti preprost delujoč sistem v kratkem času, kot porabiti ogromno časa za razvoj komponent, ki jih ne potrebujete. Rešite naloge in probleme, ki so pomembni na podlagi vaših meritev in rezultatov.
- Pripravite se na nove aplikacije.
Tako kot je težko predvideti vse težave, je težko vnaprej predvideti koristi in aplikacije. Zgledujte se po startupih – njihovi sposobnosti prilagajanja razmeram strank. V vašem primeru boste morda odkrili nove težave in njihove rešitve. V našem projektu smo si zastavili cilj zmanjšati zakasnitev zahtevka. Vendar smo med analizo in razpravami ugotovili, da lahko uporabljamo tudi proxy strežnike:
- za uravnoteženje prometa med regijami AWS in zmanjšanje stroškov;
- modelirati stabilnost CDN;
- za konfiguracijo DNS;
- za konfiguracijo TLS/TCP.
Zaključek
V poročilu sem opisal, kako Netflix rešuje problem pospeševanja internetnih zahtev med odjemalci in oblakom. Kako zbiramo podatke s sistemom vzorčenja o strankah in uporabljamo zbrane zgodovinske podatke za usmerjanje produkcijskih zahtev strank po najhitrejši poti v internetu. Kako uporabljamo načela omrežnih protokolov, našo infrastrukturo CDN, hrbtenično omrežje in strežnike DNS za dosego te naloge.
Vendar je naša rešitev le primer, kako smo pri Netflixu implementirali tak sistem. Kaj je pri nas delovalo. Aplikativni del mojega poročila za vas so načela razvoja in podpore, ki jim sledimo in dosegamo dobre rezultate.
Naša rešitev težave vam morda ne bo ustrezala. Teorija in principi oblikovanja pa ostajajo, tudi če nimate svoje CDN infrastrukture ali če se bistveno razlikuje od naše.
Pomemben ostaja tudi pomen hitrosti poslovnih zahtev. In tudi za preprosto storitev se morate odločiti: med ponudniki v oblaku, lokacijo strežnika, CDN in ponudniki DNS. Vaša izbira bo vplivala na učinkovitost internetnih poizvedb za vaše stranke. In pomembno je, da merite in razumete ta vpliv.
Začnite s preprostimi rešitvami, pazite na to, kako spremenite izdelek. Učite se sproti in izboljšajte sistem na podlagi podatkov vaših strank, vaše infrastrukture in vašega podjetja. Pomislite na možnost nepričakovanih okvar med postopkom načrtovanja. In potem lahko pospešite svoj razvojni proces, izboljšate učinkovitost rešitve, se izognete nepotrebnemu bremenu podpore in mirno spite.
To leto v spletni obliki. Vprašanja lahko postavite enemu od očetov DevOpsa, Johnu Willisu!
Vir: www.habr.com