Kiirendame internetipäringuid ja magame rahulikult

Netflix on internetiteleviooni turgude liider, mis on loonud ja aktiivselt arendanud seda segmenti. Netflix on tuntud mitte ainult ulatusliku filmide ja sarjade katalogi poolest, mis on saadaval peaaegu igas maailma nurkas ja igas ekraaniga seadmes, vaid ka usaldusväärse infrastruktuuri ja ainulaadse insenerikultuuri poolest.

Selge näide Netflixi lähenemisest keerukate süsteemide arendamisele ja toetamisele esitas DevOops 2019 Sergei Fedorov — arenduse direktor Netflixis. Lobachevski NN Ülikooli VVK lõpetanud Sergei on üks esimesi insenere Open Connectis — Netflixi CDN meeskonnas. Ta on kujundanud videodaatade jälgimise ja analüüsi süsteeme, käivitanud populaarse tasuta Interneti-kiirusetesti FAST.com ning töötanud viimased paar aastat Interneti-päringute optimeerimise nimel, et Netflixi rakendus töötaks kasutajatele võimalikult kiiresti.

Ettekande puhul sai parimaid kommentaare konverentsi osalistelt ja oleme koostanud selle tekstiversiooni.

Ettekandes rääkis Sergei üksikasjalikult

• kuidas mõjutab viivitust interneti päringute vahel kliendi ja serveri vahel;
• kuidas seda viivitust vähendada;
• kuidas projekteerida, toetada ja jälgida viga-tolerante süsteeme;
• kuidas saavutada tulemusi lühikese aja jooksul, minimaalsete riskidega ettevõtlusele;
• kuidas analüüsida tulemusi ja õpiksite vigadest.

Need küsimused on olulised mitte ainult neile, kes töötavad suurtes korporatsioonides.

Need põhimõtted ja tehnikad peaksid olema tuttavad ja rakendatavad igaühele, kes arendab ja toetab veebitooteid.

Edasi — jutustus esinejalt.

Interneti kiirus

Interneti päringute kiirus on otseselt seotud äritegevusega. Vaatame ostuajalugu: ettevõte Amazon 2009. aastal ütles, et 100 ms viivitus põhjustab 1% müügist kadumise.

Mobiilseadmete arv pidevalt kasvab, tuues endaga kaasa ka mobiilsaid ja rakendusi. Kui teie leht laetakse üle kolme sekundi, kaotate umbes poole kasutajatest. Alates juulist 2018 arvestab Google teie lehe laadimiskiirus on otsingutulemustes: mida kiiremini leht, seda kõrgem on selle positsioon Google'is.

Ühenduse kiirus on samuti oluline finantsasutustes, kus viivitus on kriitiline. 2015. aastal lõpetas ettevõte Hibernia Networks lõpetanud kaabli paigaldamine New Yorgi ja Londoni vahel maksab 400 miljonit dollarit, et vähendada viivitust linnade vahel 6 ms võrra. Kujutage ette, et 66 miljonit dollarit iga 1 ms viivituse vähendamiseks!

Vastavalt uuringule, ühenduse kiirus üle 5 Mbit/s ei mõjuta enam otseselt tüüpilise veebisaidi laadimiskiirust. Siiski on viivituse ja lehe laadimiskiirusel lineaarne seos:

Kuid Netflix ei ole tüüpiline toode. Viivituse ja kiirus kui kasutaja kogemuse tegurid on aktiivne analüüsi ja arenduse valdkond. On rakenduse laadimine ja sisu valik, mis sõltuvad viivitusest, kuid staatiliste elementide laadimine ja voogedastus sõltuvad samuti ühenduse kiirusest. Kvaliteedi tagamise võtmetegurite analüüs ja optimeerimine on mitme Netflixi tiimi aktiivne arendusteema. Üks eesmärkidest on vähendada päringute viivitust Netflixi seadmete ja pilveinfrastruktuuri vahel.

Aruandes keskendume viivituse (latency) vähendamisele Netflixi infrastruktuuri näitel. Vaatame praktilisest vaatenurgast, kuidas läheneda keerukate jaotatud süsteemide projekteerimisele, arendamisele ja haldamisele, kulutades aega innovatsioonile ja tulemustele, mitte operatiivsete probleemide ja rikete diagnoosimisele.

Netflixis

Tuhanded erinevad seadmed toetavad Netflixi rakendusi. Nende arendamisega tegeleb neli erinevat meeskonda, kes loovad eraldi klientide versioone Androidi, iOS-i, TV ja veebibrauserite jaoks. Me investeerime palju ressursse kasutajaliidese täiustamisse ja isikupärastamisse. Selleks käivitame samal ajal sadu A/B teste.

Isikupärastamine toetub sadadele mikroteenustele AWS-is, mis pakuvad kasutajale kohandatud andmeid, päringute haldamist, telemeetria, Big Data ja kodeerimise funktsioone. Trafiku visualiseerimine näeb välja selline:

Ling video demonstreerimiseks (6:04-6:23)

Vasakul on entry point ja seejärel jaotatakse liiklus mitmete sajade mikroteenuste vahel, mida toetavad erinevad backend meeskonnad.

Veel olulisem komponent meie infrastruktuuris on Open Connect CDN, mis edastab lõppkasutajale staatilist sisu – videoid, pilte, kliendikoodi jne. CDN paikneb kohandatud serverites (OCA – Open Connect Appliance). Seal on SSD ja HDD ketaste rippmasiivid, mis töötavad optimeeritud FreeBSD, NGINX'i ja teenuste komplekti all. Kujundame ja optimeerime riist- ja tarkvarakomponente nii, et see CDN server suudaks edastada võimalikult palju andmeid kasutajatele.

Internetipunkti vahetus (Internet eXchange – IX) serverite 'seina' välimus on järgmine:

Internet Exchange pakub internetiteenuse pakkujate ja sisu tootjate võimalust 'ühenduda' üksteisega, et vahetada andmeid internetis otse. Üle kogu maailma on umbes 70-80 Internet Exchange punkti, kus asuvad meie serverid, ja me tegeleme nende paigaldamise ja hooldamisega ise:

Lisaks pakume otse internetiteenuse pakkujatele ka servereid, mida nad paigaldavad oma võrku, parandades Netflixi liikluse lokaliseerimist ja kasutajate voogesituse kvaliteeti:

AWS teenused, mis vastutavad video päringute suunamise eest klientidelt CDN serveritele ning serverite konfiguratsiooni, sealhulgas sisu, tarkvara ja seadistuste värskendamise eest. Viimase jaoks oleme ka ehitanud backbone-võrgu, mis ühendab servereid Internet Exchange punktides AWS-iga. Backbone-võrk on globaalne kiudoptiliste kaablite ja ruuterite võrk, mida saame projekteerida ja konfigureerida vastavalt oma vajadustele.

Kohal Sandvine’i hinnangud, meie CDN infrastruktuur edastab tipptundidel umbes ⅛ osa maailma internetitrafikust ja ⅓ trafikut Põhja-Ameerikas, kus Netflix on pikimalt tegutsenud. Imelised numbrid, kuid minu jaoks on üks kõige tähelepanuväärsemaid saavutusi see, et kogu CDN süsteemi arendab ja toetab vähem kui 150 inimesest koosnev meeskond.

Algusjärgus oli CDN infrastruktuur kavandatud videoteabe edastamiseks. Aja jooksul mõistsime aga, et saame seda kasutada ka dünaamiliste päringute optimeerimiseks AWS pilves.

Internetiga ühenduse kiirus

Täna on Netflixil 3 AWS piirkonda ning pilveteenuste päringute viivitused sõltuvad sellest, kui kaugel klient asub lähimast piirkonnast. Meil on ka palju CDN servereid, mida kasutatakse staatilise sisu edastamiseks. Kas saaksime seda infrastruktuuri kasutada, et kiirendada dünaamilisi päringuid? Kahjuks ei saa neid päringuid vahemälu salvestada — API-d on personaliseeritud ja iga tulemuse eelisõigus on ainulaadne.

Teeme CDN-serveris proxy ja hakkame liiklust selle kaudu suunama. Kas see oleks kiirem?

Materjal

Käidame meeles, kuidas võrgu protokollid töötavad. Täna kasutab suur enamus Interneti liiklust HTTPS, mis sõltub madalama taseme protokollidest TCP ja TLS. Et klient serveriga ühendust saada, peab ta tegema käepigistuse (handshake) ning turvalise ühenduse loomiseks peab klient vahetama sõnumeid serveriga kolm korda ja veel vähemalt ühe rahuldava korraga andmete edastamiseks. Kui ühe vahetuse (RTT) viivitus on 100 ms, siis vajame esimesse andmebitti jõudmiseks 400 ms:

Kui sertifikaadid on CDN-serveris, saame oluliselt vähendada «kätlemise» aega kliendi ja serveri vahel, kui CDN on lähemal. Oletame, et viivitus CDN-serverisse on 30 ms. Siis on esimese biti saamiseks vajalik aeg juba 220 ms:

Kuid eelised sellega ei lõppe. Pärast ühenduse loomist suurendab TCP congestion window'i (teabe hulka, mida see saab samaaegselt üle kanda). Kui andmepakett kaob, vähendavad klassikalised TCP protokollide teostused (nt TCP New Reno) avatud «akent» kahe korda. Congestion window'i kasv ja selle taastumise kiirus kaotuse tõttu sõltub jälle serverisse jõudmise viivitusest (RTT). Kui see ühendus läheb ainult CDN-serverisse, on taastumine kiirem. Samal ajal on andmepakettide kadumine tavaline nähtus, eriti traadita võrkudes.

Interneti läbilaskevõime võib kahaneda, eriti tipptundidel, kuna liiklus kasutajatelt tekitab 'ummikuid'. Internetis ei ole võimalik ühtede päringute prioriseerimist teiste suhtes. Näiteks anda prioritiseerida väikese mahuga ja viivitusest sõltuvad päringud võrreldes 'raskete' andmevoogudega, mis koormavad võrku. Kuid meie juhul võimaldab oma backbone-võrne olemasolu seda teha osalise teel päringu – CDN ja pilve vahel, ning saame seda täielikult konfigureerida. Saame seadistada, et väikesed ja viivitustest sõltuvad paketid prioriseeritaks, samas kui suured andmevood läheksid veidi hiljem. Mida lähemal on CDN kliendile, seda suurem on efektiivsus.

Samuti mõjutavad viivitust rakendustasandi protokollid (OSI tasemel 7). Uued protokollid, nagu HTTP/2, võimaldavad paralellpäringute jõudlust optimeerida. Kuid meil on Netflixis kliente, kelle seadmed ei toeta uusi protokolle. Kõiki kliente ei saa värskendada või optimaalselt seadistada. Samal ajal on CDN-proksi ja pilve vahel täielik kontroll ning võimalus kasutada uusi, optimaalseid protokolle ja seadeid. Ebaefektiivne osa vanade protokollide osas toimib ainult kliendi ja CDN-serveri vahel. Veelgi enam, me saame teha mitme päringu multipleximise juba loodud ühenduste kaudu CDN-i ja pilve vahel, parandades TCP tasandi ühenduse kasutamist:

Mõõdame

Kuigi teoreetiliselt lubatakse parendusi, ei kiirusta me kohe süsteemi käivitama. Selle asemel peame kõigepealt tõestama, et idee töötab praktikas. Selleks tuleb vastata mitmele küsimusele:

• Kiirus: Kas proksi on kiirem?
• Usaldusväärsus: Kas see katkevad sagedamini?
• Raskusaste: Kuidas integreerida rakendustega?
• Hind: Kui palju maksab täiendava infrastruktuuri juurutamine?

Uurime meie lähenemist esimese punkti hindamisele põhjalikult. Ülejäänud käsitletakse sarnasel viisil.

Küsimuste kiirusanalüüsi jaoks soovime saada andmeid kõigi kasutajate kohta, et mitte kulutada palju aega arendusele ja mitte rikkoa tootmist. Selleks on mitu lähenemist:

1. RUM ehk passiivne küsimuste mõõtmine. Mõõdame aktiivsete kasutajate küsimuste täitmise aega ja tagame täieliku kasutajate katvuse. Puuduseks on madal signaali stabiilsus, mille põhjustavad mitmed tegurid, näiteks erinevate küsimuste suurused, serveri ja kliendi töötlemise aeg. Pealegi ei saa me testida uut konfiguratsiooni tootmise mõju mõjutamata.
2. Laboritestid. Erilised serverid ja infrastruktuur, mis simuleerivad kliente. Nende abil teeme vajalikud testid. Nii saame tulemuste mõõtmiste üle täieliku kontrolli ja selge signaali. Kuid puudub täielik katvus seadmete ja kasutajate asukohtade osas (eriti teenuse puhul, mis katab kogu maailma ja toetab tuhandeid seadmete mudeleid).

Kuidas saaksime mõlema meetodi eelised kokku tuua?

Meie meeskond leidis lahenduse. Kirjutasime väikese koodi - proovi - mille integreerisime oma rakendusse. Proovid võimaldavad meil teostada täielikult kontrollitud võrku teste meie seadmetest. See töötab järgmiselt:

1. Varsti pärast rakenduse laadimist ja esialgse tegevuse lõpetamist käivitame meie proovid.
2. Kliendi serverile tehtud päringule vastatakse "retseptiga" testiks. Retsept on URL-ide nimekiri, millele tuleb teha HTTP(s) päring. Lisaks konfigureerib retsept päringute parameetrid: viivitused päringute vahel, küsitava andmemaht, HTTP(s) päised jne. Samuti saame samal ajal testida mitmeid erinevaid retsepte - konfiguratsiooni pärimise ajal määratakse juhuslikult, milline retsept välja anda.
3. Proovi käivitamise aeg valitakse nii, et see ei kattuks kliendi aktiivse võrguressursside kasutamisega. Ehkki, valitakse aeg, mil klient ei ole aktiivne.
4. Retsepti saamisel esitab klient päringud iga URL-aadressi kohta samaaegselt. Iga aadressi päringut võidakse korrata – nn „pulssidena“. Esimesel pulsil mõõdame, kui kaua kulus ühenduse loomisele ja andmete allalaadimisele. Teisel pulsil mõõdame andmete laadimise aega juba loodud ühenduse kaudu. Enne kolmandat pulssi võime seada viivituse ja mõõta uuesti ühenduse loomise kiirus jne.

   Testi ajal mõõdame kõiki parameetreid, mida seade saab:

   • DNS-päringu aeg;
   • TCP-ühenduse loomise aeg;
   • TLS-ühenduse loomise aeg;
   • esimese andmebaidi saamise aeg;
   • üldine laadimisaja;
   • tulemuse staatuse kood.
5. Kogu pulsside lõppedes laadib proov alla kõik mõõtmistulemused analüüsiks.

Peamised aspektid on minimaalne sõltuvus kliendi loogikast, andmete töötlemine serveris ja paralleelsete päringute mõõtmine. Selliselt saame isoleerida ja testida erinevate tegurite mõju päringute jõudlusele, varieerida neid ühe retsepti raames ning saada tulemusi reaalsetelt klientidelt.

Selline infrastruktuur on osutunud kasulikuks mitte ainult päringute jõudluse analüüsimiseks. Praegu on meil 14 aktiivset retsepti, üle 6000 proovi sekundis, mis saavad andmeid igast maailma nurgast ja katab täielikult seadmeid. Kui Netflix ostaks sarnase teenuse kolmandatelt ettevõtetelt, maksaks see miljoneid dollareid aastas, oluliselt halvemate kattega.

Katsume teooriat praktikas: prototüüp

Sellise süsteemiga saime hinnata CDN-proksi efektiivsust päringute latentsus. Nüüd tuleb:

• luua proksi prototüüp;
• paigutada prototüüp CDN-ile;
• määrata, kuidas suunata kliente proksile konkreetses CDN-serveris;
• võrrelda jõudlust AWS-i päringute puhul ilma proksita.

Ülesanne on võimalikult kiiresti hinnata ettepaneku tõhusust. Prototüübi teostamiseks valisime Go, kuna sellel on head võrguraamatukogud. Igal CDN-serveril installisime prototüübi proksina staatilise binaarina, et vähendada sõltuvusi ja lihtsustada integreerimist. Esialgses teostuses kasutasime maksimaalselt standardkomponente ja väikseid modifikatsioone HTTP/2 ühenduste basseinide ja päringute multiplitseerimise jaoks.

AWS regionide vaheliseks koormuse jaotamiseks kasutasime geograafilist DNS-andmebaasi, samasugust, mida kasutatakse klientide koormuse jagamiseks. CDN-serveri valimiseks kliendi jaoks kasutame TCP Anycasti Internet Exchange (IX) serverite jaoks. Sellisel juhul kasutame üht IP-aadressi kõigile CDN-serveritele, samal ajal suunatakse klient CDN-serverisse, millel on kõige vähem IP-hops'e. CDN-serverites, mis on paigaldatud interneti teenusepakkujate (ISP) juures, ei ole meil marsruuteri üle kontrolli TCP Anycasti seadistamiseks, seega rakendame sama loogikat, mille abil suunatakse kliente interneti teenusepakkujatesse videovaatamiseks.

Nii, meil on kolm teed päringu esitamiseks: pilve kaudu avatud interneti, CDN-serveri kaudu IX-s või Interneti-teenuse pakkuja juures asuva CDN-serveri kaudu. Meie eesmärk on mõista, milline tee on parem ja milline on proksi kasu võrreldes sellega, kuidas päringud suunatakse tootmisse. Selleks kasutame katsetussüsteemi järgmiselt:

Iga tee muutub eraldi sihtmärgiks ning vaatame, kui palju aega me saavutame. Analüüsiks ühendame proksi tulemused ühte gruppi (valime parima aja IX ja ISP proksi vahel) ning võrdleme seda pilve päringute ajaga ilma proksita:

Nagu näha, olid tulemused kahetised – enamikul juhtudel annab proksi hea kiirenduse, kuid on ka piisavalt kliente, kelle jaoks olukord halveneb oluliselt.

Kokkuvõttes tegime mitmeid olulisi asju:

1. Hindasime klientide oodatavat sõltumatut jõudlust pilve kaudu CDN proksi kaudu.
2. Saime andmeid reaalsetelt klientidelt kõikidest seadmetest.
3. Mõistsime, et teooria ei kinnitunud 100% ja algne ettepanek CDN proksi kasutamiseks meie jaoks ei toimi.
4. Ei riskinud - ei muutnud klientide tootmiskonfiguratsioone.
5. Mitte midagi ei katki.

Prototüüp 2.0

Nii et naaseme joonistetoimete juurde ja kordame protsessi uuesti.

Idee on see, et 100% proxy asemel määrame iga kliendi jaoks kõige kiirema tee ning suuname sinna päringud - see tähendab, et teeme seda, mida nimetatakse client steering.

Kuidas see ellu viia? Me ei saa kasutada loogikat serveri poolel, kuna eesmärk on just sellele serverile ühenduda. Peame seda kuidagi tegema kliendipoolsetel süsteemidel. Ja ideaaljuhul, teha seda minimaalse keeruka loogikaga, et mitte tegeleda laialdase klientide platvormide integreerimisega.

Vastus on DNS-i kasutamine. Meie puhul on meil oma DNS-infrastruktuur, ja me saame seadistada domeenitsooni, mille jaoks meie serverid on autoriteetsed. See töötab järgmiselt:

1. Kliendilt tuleb päring DNS-serverile, kasutades hosti, näiteks api.netflix.xom.
2. Päring jõuab meie DNS-serverisse
3. DNS-server teab, milline tee on sellele kliendile kõige kiirem ja annab vastava IP-aadressi.

Lahenduses on täiendav keerukus: autoriteetsed DNS-teenusepakkujad ei näe kliendi IP-aadressi ja saavad arvesse võtta ainult kliendi kasutatava rekursiivse resolveri IP-aadressi.

Seetõttu peab meie autoriteetne resolver langetama otsuse mitte ühe kliendi, vaid kliendigruppi põhjal rekursiivse resolveri alusel.

Lahenduse tarbeks kasutame samu proove, kogume mõõtmisandmed klientidelt iga rekursiivse resolveri kohta ja otsustame, kuhu seda gruppi suunata — kas IX kaudu proksiga TCP Anycast, ISP proksi kaudu või otse pilve.

Saame sellise süsteemi:

Saadud DNS steering mudel võimaldab suunata kliente ajalooliste vaatluste põhjal ühenduse kiirusest klientide ja pilve vahel.

Jällegi, küsimus on — kui tõhusalt see lähenemine töötab? Vastuse leidmiseks kasutame taas meie proovide süsteemi. Seetõttu seame üles konfigureerimise recency, kus üks sihtpunkt järgib DNS steering'i suunda, teine — läheb otse pilve (praegune tootmine).

Seetõttu võrreldame tulemusi ja saame tõhususe hindamise:

Kokkuvõttes saime teada mitmeid olulisi asju:

1. Hindame kliendipäringute oodatavat jõudlust pilve kaudu DNS Steering abil.
2. Saime andmeid reaalsetelt klientidelt kõikidest seadmetest.
3. Oleme tõestanud pakutud idee tõhusust.
4. Ei riskinud - ei muutnud klientide tootmiskonfiguratsioone.
5. Mitte midagi ei katki.

Nüüd keerulisest — käivitame tootmisprotsessis.

Kõige lihtsam on nüüd möödas — olemas toimiv prototüüp. Nüüd on keeruline osa — käivitada lahendus kogu Netflixi liiklusele, mis peab olema kohandatud 150 miljonile kasutajale, tuhandele seadmele, sadadele mikroteenustele ja pidevalt muutuvatele toodetele ning infrastruktuurile. Netflixi serveritele saabub miljoneid päringuid sekundis ning üks vale liigutus võib teenuse kergesti rikkuda. Samal ajal tahan dünaamiliselt suunata liiklust tuhandete CDN serverite kaudu internetis, kus midagi muutub ja murdub pidevalt ning kõige vähem sobival hetkel.

Ja kogu selle jooksul on tiimis 3 inseneri, kes vastutavad süsteemi väljatöötamise, juurutamise ja täieliku toe eest.

Seetõttu räägime nüüd rahulikust ja tervislikust unest.

Kuidas jätkata arendust, mitte kulutada kogu aega toe pakkumisele? Meie lähenemise aluseks on 3 põhimõtet:

1. Vähendame võimalike rikke ulatust (blast radius).
2. Valmistume üllatusteks — ootame, et midagi võib katki minna, hoolimata testimisest ja isiklikest kogemustest.
3. Aeglane degradeerimine (graceful degradation) — kui midagi ei tööta korralikult, peaks see automaatselt paranema, kuigi mitte kõige tõhusamal viisil.

Selgus, et meie puhul on sellise probleemilahenduse juures võimalik leida lihtne ja tõhus lahendus, mis oluliselt lihtsustab süsteemi hooldust. Saime aru, et saame lisada kliendile väikese koodilõigu ja jälgida võrgupäringute vigu, mis on põhjustatud ühenduse probleemidest. Võrguvigade korral teeme fallbacki otse pilve. Selline lahendus ei nõua kliimiteamilt suuri pingutusi, kuid vähendab oluliselt ootamatute tõrgete ja üllatuste riski meie jaoks.

Muidugi, hoolimata fallback'ist järgime siiski ranget distsipliini arenduse käigus:

1. Katsed proovide jaoks.
2. A/B testimine või Canaries.
3. Järkjärguline väljalaskmine (progressive rollout).

Proovide osas on lähenemine kirjeldatud — muudatusi testitakse esmalt seadistatud retsepti abil.

Canary-testimiseks vajame võrreldavaid serveripaaride rühmi, et näha, kuidas süsteem töötab enne ja pärast muudatusi. Selleks valime meie paljusid CDN site'idelt serveripaarid, mis saavad sarnast liiklust:

Seejärel paigaldame muudatused sisaldava koostise Canary serveritesse. Tulemuste hindamiseks käivitame süsteemi, mis võrreldab umbes 100–150 mõõdikut Control serverite valikuga:

Kui Canary-testimine on edukas, teeme järk-järgult, lainetena väljaande. Igal saidil ei uuenda me servereid samaaegselt — terve saidi kadumine probleemide korral mõjutab teenust kasutajatele rohkem kui sama palju servereid, kuid erinevates kohtades.

Üldiselt sõltub selle lähenemise tõhusus ja ohutus kogutud mõõdikutest ning nende kvaliteedist. Meie päringute kiirusüsteemi jaoks kogume mõõdikut kõikidest võimalikest komponentidest:

• klientidelt — seansside ja päringute arv, fallback rates;
• proksidest — päringute arvu ja keste statistika;
• DNS — päringute arv ja tulemused;
• cloud edge — päringute töötlemise hulk ja aeg pilves.

Kõik see koguneb ühte pipeline'i, ja sõltuvalt vajadustest otsustame, millised mõõdikud saata reaalajas analüüsiks ning millised Elasticsearchi või Big Data'sse süvadiagnoosimiseks.

Jälgime

Meie puhul teeme muudatusi päringute kriitilisel teel kliendi ja serveri vahel. Samal ajal on erinevate komponente kliendil, serveris ja internetis tohutult. Muudatused kliendil ja serveris toimuvad pidevalt — kümnete tiimide töö käigus ning ökosüsteemi looduslike muutuste tõttu. Oleme keskel — probleemide diagnoosimisel on suur võimalus, et osaleme selles. Seetõttu peame selgelt aru saama, kuidas mõõdikuid kindlaks teha, koguda ja analüüsida probleemide kiireks lokaliseerimiseks.

Ideaalis oleks täielik juurdepääs kõikidele mõõdikutele ja filtritele reaalajas. Kuid mõõdikute hulk on tohutu, seetõttu tekib küsimus kuludest. Meie puhul jagame mõõdikud ja arendustööriistad järgmiselt:

Probleemide avastamiseks ja triage'iks kasutame oma reaalajas avatud lähtekoodiga süsteemi. Atlas ja Lumen — visualiseerimiseks. See säilitab mälus kogutud mõõdikud, on usaldusväärne ja integreerub häiresüsteemiga. Lokaliseerimise ja diagnoosimise jaoks pääseme logidele Elasticsearch ja Kibana kaudu. Statistiliseks analüüsiks ja modelleerimiseks kasutame big data't ja visualiseerimist Tableau's.

Tundub, et sellise lähenemisega on väga keeruline töötada. Kuid hierarhilise mõõdikute ja tööriistade korralduse korral saame kiiresti probleemi analüüsida, määrata probleemi tüübi ning seejärel süveneda detailsetesse mõõdikutesse. Rikete allika leidmiseks kulutame tavaliselt umbes 1–2 minutit. Pärast seda töötame konkreetse meeskonnaga diagnoosi kallal — see võib võtta aega kümneid minuteid kuni mitu tundi.

Isegi kui diagnoosimine toimub kiiresti, ei soovi me, et see liiga tihti juhtuks. Ideaalis peaksime saama kriitilise häire ainult siis, kui see mõjutab teenust oluliselt. Meie päringute kiirusest tingitud süsteemil on ainult 2 häiret, mis teavitavad:

• Client Fallback protsent — hindab klientide käitumist;
• Probe errors protsent — andmed võrguelementide stabiilsuse kohta.

Need for critical alerts to monitor if the system operates for most users. We observe how many clients used the fallback when they could not receive request acceleration. On average, we have less than one critical alert per week, despite a huge number of changes occurring in the system. Why is this sufficient for us?

1. There is a client fallback in case our proxy does not work.
2. There is an automatic steering system that responds to issues.

More about this: Our probe system and automatic path optimization for requests from clients to the cloud allow us to automatically address some issues.

Let's return to our probe configuration and three categories of paths. Besides loading times, we can also look at the very fact of delivery. If data could not be loaded, by analyzing results across different paths, we can identify where and what broke and whether we can automatically fix it by changing the request path.

Näited:

Seda protsessi on võimalik automatiseerida. Integreerida see juhtimissüsteemi. Ja õpetada seda reageerima jõudluse ja usaldusväärsuse probleemidele. Kui midagi hakkab minema rikki — reageerida sellele, kui on parem lahendus. Samas ei ole kohene reageerimine kriitiline, kuna on olemas varufunktsioon kliendil.

Seega võib süsteemi toetamise põhimõtteid sõnastada nii:

• vähendame rikke ulatust;
• kogu statistikat;
• parandame rikkeid automaatselt, kui suudame;
• kui ei suuda — teavitame;
• töötame välja juhtpaneele ja triigeerimistööriistu kiireks reageerimiseks.

Tõstatatud õppetunnid

Prototüübi kirjutamiseks ei kulu palju aega. Meie puhul oli see valmis juba nelja kuu pärast. Sellega saime uusi statistikaid ja kümne kuu möödudes arenduse algusest saime esimese tootmisliikluse. Seejärel algas tülikas ja väga keeruline töö: süsteemi toodetuks muutmine ja skaleerimine, põhiliiklusest migreerimine ja vigadest õppimine. Samas ei ole see efektiivne protsess lineaarne — hoolimata kõigist pingutustest ei saa kõike ette näha. Oluliselt efektiivsem on kiire iteratsioon ja reageerimine uutele andmetele.

Meie kogemuste põhjal saame soovitada järgmist:

1. Ärge usaldage oma intuitsiooni.

   Meie intuitsioon on meid pidevalt petnud, hoolimata meeskonna liikmete suurest kogemusest. Näiteks, me ennustasime valesti oodatavat kiirendust CDN-proksi kasutamisest või TCP Anycast'i käitumist.

2. Saage andmed tootmisest.

   On oluline, et saaksite võimalikult kiiresti ligipääsu vähemalt väikesele hulgale tootmisandmetele. Unikaalsete juhtumite, konfiguratsioonide ja seadistuste saamine katsetingimustes on peaaegu võimatu. Kiire juurdepääs tulemustele võimaldab teil kiiremini teada saada potentsiaalsetest probleemidest ja arvesse võtta neid süsteemi arhitektuuris.

3. Ärge järgige teiste nõuandeid ja tulemusi — koguge oma andmeid.

   Järgige andmete kogumise ja analüüsi põhimõtteid, kuid ärge võtke pimesi teiste tulemusi ja väiteid. Ainult teie teate täpselt, mis töötab teie kasutajatele. Teie süsteemid ja teie kliendid võivad teistest ettevõtetest oluliselt erineda. On hea, et analüüsivahendid on nüüd saadaval ja lihtsalt kasutatavad. Teie tulemused võivad erineda sellest, mida väidavad Netflix, Facebook, Akamai ja teised ettevõtted. Meie puhul on TLS-i, HTTP2 või DNS-i päringute statistika erinev Facebooki, Uberi, Akamai omadest – kuna meil on erinevad seadmed, kliendid ja andmevoogud.

4. Ärge järgige moetrende ilma vajaduse ja tõhususe hindamiseta.

   Alustage lihtsast. Paremini on teha lihtne töötav süsteem lühikese ajaga, kui kulutada tohutult aega teile ebavajalike komponentide loomisele. Lahendage probleemid ja ülesanded, mis on oluliselt olulised teie mõõtmete ja tulemuste põhjal.

5. Olge valmis uuteks rakendusteks.

   Nii keeruline, kui on ette näha kõiki probleeme, on ka ette näha eeliseid ja rakendusi. Võtke eeskuju idufirmadelt — nende võime kohanduda klientide tingimustega. Teie puhul võib see tähendada, et avastate uusi probleeme ja lahendusi. Meie projektis seadsime eesmärgiks vähendada päringute viivitust. Siiski, analüüsi ja arutelude käigus mõistsime, et saame kasutada ka proksi servereid:

   • liikluse tasakaalustamiseks AWS regioonides ja kulude vähendamiseks;
   • CDN stabiilsuse modelleerimiseks;
   • DNS-i konfigureerimiseks;
   • TLS/TCP-i konfigureerimiseks.

Kokkuvõte

Minu ettekandes kirjeldasin, kuidas Netflix lahendab internetipäringute kiirendamise probleemi klientide ja pilve vahel. Kuidas kogume andmeid klientidelt, kasutades proove, ja kasutame kogutud ajaloolisi andmeid, et suunata tootmispäringud klientidelt kõige kiiremat teed pidi internetis. Kuidas kasutame võrguprotokollide tööpõhimõtteid, meie CDN infrastruktuuri, backbone-võrku ja DNS servereid, et seda ülesannet täita.

Kuid meie lahendus on vaid näidis sellest, kuidas me Netflixis sarnast süsteemi rakendasime. Mis meie puhul toimis. Minu ettekande rakenduslik osa teie jaoks on arendamise ja toetamise põhimõtted, mida järgime ning mille abil saavutame häid tulemusi.

Meie probleemilahendus ei pruugi teie jaoks sobida. Kuid teooria ja arendamise põhimõtted jäävad kehtima, isegi kui teil puudub oma CDN infrastruktuur või kui see erineb oluliselt meie omast.

Samuti jääb oluliseks päringute kiirus äri jaoks. Ja isegi lihtsa teenuse puhul tuleb teha valik: 'pilve' teenusepakkujate, serverite asukoha, CDN ja DNS teenusepakkujate vahel. Teie valik mõjutab internetipäringute tõhusust teie klientidele. Ja teie jaoks on oluline seda mõju mõõta ja mõista.

Alustage lihtsatest lahendustest, mõelge hoolikalt, kuidas te toodet muudate. Õppige protsessi käigus ja täiustage süsteemi oma klientide, teie infrastruktuuri ja teie äri andmete põhjal. Mõelge ootamatute rikete võimalusele projekteerimisprotsessi ajal. Aeg-ajalt suudate te kiirendada oma arendusprotsessi, parandada lahenduste efektiivsust, vältida liigset koormust tugiteenusele ja magada rahulikult.

Sel aastal konverents toimub 6.–10. juulil vahetusvormingus. Küsimusi saab esitada ühelt DevOpsi isalt, John Williselt!

Allikas: habr.com