Kiirendame internetipäringuid ja magame rahulikult

Netflix — internetittelevisiooni turuliider — ettevõte, mis on loonud ja aktiivselt arendab seda segmenti. Netflix on tuntud mitte ainult ulatusliku filmide ja sarjade katalooge poolest, mis on kergesti kättesaadavad peaaegu igast maailma nurgast ja igast ekraaniga seadmest, vaid ka usaldusväärse infrastruktuuri ja ainulaadse insenerikultuuri poolest.

Selge näide Netflixi lähenemisest keerukate süsteemide arendamisel ja hooldamisel esitles DevOops 2019 Sergei Fedorov — Netflixi arenduse direktor. Lobatchevi nimelise Nizhni Novgorodi Riikliku Ülikooli info- ja matemaatikateaduskonna vilistlane, Sergei on üks esimesi insenere Open Connectis — Netflixi CDN meeskonnas. Ta on ehitanud videoandmete jälgimise ja analüüsi süsteeme, loonud populaarse Interneti-ühenduse kiirusetesti teenuse FAST.com ja viimaseid aastaid on töötanud Interneti-päringute optimeerimise nimel, et Netflixi rakendus töötab kasutajatele võimalikult kiiresti.

Ettekanne sai parimaid arvustusi konverentsi osalejatelt ja oleme valmistanud teile selle tekstiversiooni.

Ettekandes rääkis Sergei põhjalikult

• sellest, mis mõjutab internetipäringute latentsust kliendi ja serveri vahel;
• kuidas seda latentsust vähendada;
• kuidas projekteerida, hooldada ja jälgida vigade suhtes vastupidavaid süsteeme;
• kuidas saavutada tulemusi lühikese aja jooksul ja minimaalsete äririskidega;
• kuidas analüüsida tulemusi ja õppida vigadest.

Nendele küsimustele on vastused vajalikud mitte ainult neile, kes töötavad suurtel korporatsioonidel.

Esitatud põhimõtteid ja tehnikaid peaks teadma ja rakendama igaüks, kes arendab ja hooldab internetitooteid.

Järgnevalt — rääkiv hääl esineja isikus.

Interneti kiirus

Interneti-päringute kiirus on otseselt seotud ettevõtlusega. Vaatame ostuvaldkonda: Amazon ütles 2009. aastal , et 100 ms viivitus toob kaasa 1% müügi languse.Mobiilsete seadmete arv kasvab ja koos nendega ka mobiilsete veebilehtede ja rakenduste arv. Kui teie leht laadib kauem kui 3 sekundit, kaotate umbes poole kasutajatest. Alates

juulist 2018. aastal arvestab Google teie lehe laadimiskiirusest oma otsingutulemustes: mida kiiremini leht, seda kõrgem on selle positsioon Googles. Ühenduse kiirus on samuti oluline ka finantsettevõtetes, kus viivitus on kriitiline. 2015. aastal lõpetas Hibernia Networks

viimased projektid. kaabli paigaldus New Yorgi ja Londoni vahel maksab 400 miljonit dollarit, et vähendada hilinemist linnade vahel 6 ms. Kujutage ette, 66 miljonit dollarit 1 ms edasilükkamise vähendamiseks!

Vastavalt uurimusele, ühenduse kiirus üle 5 Mbit/s enam otseselt ei mõjuta tavalise veebisaidi laadimise kiirust. Siiski on hilinemise ja lehe laadimise kiiruse vahel lineaarne seos:

Kuid Netflix ei ole tavaline toode. Hilinemise ja kiirusel on kasutajale mõju, see on aktiivne analüüsi ja arenduse valdkond. On rakenduse laadimine ja sisu valik, mis sõltuvad hilinemisest, kuid staatiliste elementide laadimine ja voogedastus sõltuvad samuti ühenduse kiirusest. Kvaliteedi teenuse analüüs ja optimeerimine kasutaja jaoks on aktiivne arendusteema mitmete Netflixi meeskondade seas. Üks ülesanne on vähendada päringute hilinemist Netflixi seadmete ja pilveinfrastruktuuri vahel.

Käesolevas aruandes keskendume hilinemise (latency) vähendamisele Netflixi infrastruktuuri näitel. Vaadakem praktiliselt, kuidas läheneda keerukate jaotatud süsteemide projekteerimise, arendamise ja haldamise protsessidele ning kulutada aega uuendustele ja tulemustele, mitte operatiivsete probleemide ja riketega seonduvatele diagnostikatele.

Netflixis

Tuhanded erinevad seadmed toetavad Netflixi rakendusi. Nende arendamisega tegeleb neli erinevat meeskonda, kes loovad eraldi versioonid Androidi, iOS-i, teleri ja veebibrauserite jaoks. Investeerime palju ressursse, et parandada ja isikupärastada kasutajaliidest. Selleks korraldame korraga sadu A/B teste.

Isikupärastamine toetatakse erinevatest mikroteenustest AWS-is, mis pakuvad kasutajale isikupäraseid andmeid, päringute suunamist, telemeetria, Big Data ja kodeerimise. Liiklusvisualiseerimine näeb välja selline:

Link videole koos demonstreerimisega (6:04-6:23)

Vasakul asub entry point ja seejärel jaotatakse liiklus mitmete sadade mikroteenuste vahel, mille taga on erinevad backendi meeskonnad.

Teine oluline komponent meie infrastruktuuris on Open Connect CDN, mis toimetab lõpuni kasutajani staatilist sisu – videoid, pilte, kliendi jaoks mõeldud koodi jne. CDN asub kohandatud serverites (OCA – Open Connect Appliance). Nendes on SSD- ja HDD-kettad, mida juhib optimeeritud FreeBSD koos NGINX-i ja teenuste kogumiga. Me projekteerime ja optimeerime riist- ja tarkvarakomponente nii, et selline CDN-server suudab edastada võimalikult palju andmeid kasutajatele.

Need serverid on Interneti liikluse vahetuspunktis (Internet eXchange – IX) sellised:

Internet Exchange võimaldab interneti teenusepakkujatel ja sisu tarnijatel omavahel "ühenduda", et vahetada andmeid internetis otse. Üle kogu maailma on umbes 70–80 Internet Exchange'i punkti, kus asuvad meie serverid, ja me teeme nende paigaldamise ja hooldamise ise.

Lisaks sellele pakume servereid otse interneti teenusepakkujatele, kes paigaldavad need oma võrgus, parandades Netflixi liikluse lokaliseerimist ja streaming-kvaliteeti kasutajatele.

AWS teenuste komplekt vastutab video päringute suunamise eest klientidelt CDN-serveritesse ning serverite konfigureerimise eest – sisu, tarkvara, seadistuste jms värskendamine. Selle jaoks ehitasime ka backbone-võrgu, mis ühendab serverid Internet Exchange'i punktides AWS-iga. Backbone-võrk on globaalne optiliste kiudude ja ruuterite võrk, mida saame projekteerida ja konfigureerida vastavalt meie vajadustele.

Ajal Sandvine'i hinnangud, meie CDN infrastruktuur toimetab tipptundidel umbes ⅛ osa maailma interneti liiklusest ja ⅓ liiklusest Põhja-Ameerikas, kus Netflix on eksisteerinud kõige kauem. Need on muljetavaldavad numbrid, kuid minu arust on kõige üllatavam saavutus see, et kogu CDN süsteem on välja töötatud ja hooldatud vähem kui 150 inimesest koosneva meeskonna poolt.

Alguses oli CDN infrastruktuur projekteeritud meediaandmete edastamiseks. Kuid aja jooksul saime aru, et saame seda kasutada ka dünaamiliste päringute optimeerimiseks klientidelt AWS-i pilve.

Internetikiirus

Täna on Netflixil 3 AWS piirkonda ja pilve päringute viivitus sõltub sellest, kui kaugel klient asub lähimast piirkonnast. Samuti on meil palju CDN-servereid, mida kasutatakse staatilise sisu edastamiseks. Kas seda infrastruktuuri saaks kasutada dünaamiliste päringute kiirendamiseks? Kahjuks ei saa me neid päringuid vahemälustada - API-d on isikupärased ja iga tulemus on ainulaadne.

Teeme CDN-serveris proksi ja hakkame läbi selle liiklust suunama. Kas see oleks kiirem?

Tehnilised üksikasjad

Kohandame meeles, kuidas võrgu protokollid töötavad. Täna kasutab suurem osa interneti liiklust HTTPs, mis sõltub alumiste tasemete protokollidest TCP ja TLS. Et klient saaks serveriga ühendust, peab ta tegema handshake'i ja turvalise ühenduse loomise jaoks peab klient vahetama sõnumeid serveriga kolm korda ning veel vähemalt ühe korra andmete edastamiseks. Kui ühe vahetuse viivitus (RTT) on 100 ms, siis vajame esimest bitsi andmete saamiseks 400 ms:

Kui sertifikaadid asuvad CDN-serveris, saame oluliselt vähendada kliendi ja serveri vahelise „kätlemise” aega, kui CDN on lähemal. Oletame, et viivitus CDN-serverisse on 30 ms. Siis vajame esimese bitsi saamiseks juba 220 ms:

Kuid kasu sellega ei lõppe. Pärast ühenduse loomist suurendab TCP congestion window'i (teabe kogus, mida saab selle ühenduse kaudu paralleelselt edastada). Kui andmepakett kaob, vähendavad traditsioonilised TCP protokollide rakendused (nt TCP New Reno) avatud „aken” poole võrra. Congestion window'i kasv ja kadumise taastumise kiirus sõltuvad taas serverisse suunatud viivitusest (RTT). Kui ühendus läheb ainult CDN-serverisse, siis taastumine toimub kiiremini. Samuti on andmepakettide kaotus tavaline nähtus, eriti traadita võrkudes.

Interneti läbilaskevõime võib vähendada, eriti tipptundidel kasutajate liikluse tõttu, mis võib tekitada „ummikuid“. Internetis ei ole võimalik anda ühele päringule prioriteeti teiste ees. Näiteks, prioriseerida väiksema mahuga ja viivitusest sõltuvad päringud „rasketest“ andmevoogudest, mis koormavad võrku. Kuid meie puhul võimaldab oma selgroo olemasolu seda teie päringu teel — CDN ja pilve vahel, ning me saame seda täielikult konfigureerida. Võime seadistada nii, et väikesed ja viivitusest sõltuvad paketid oleksid prioriseeritud, ja suured andmevood saadetakse veidi hiljem. Mida lähemal on CDN kliendile, seda suurem on efektiivsus.

Samuti mõjutavad viivitust rakendusprotokollid (OSI tasand 7). Uued protokollid, nagu HTTP/2, võimaldavad optimeerida samaaegsete päringute tõhusust. Kuid meil on Netflix, kus on kliente, kelle seadmed ei toeta uusi protokolle. Mitte kõiki kliente ei ole võimalik uuendada või optimaalselt seadistada. Sellegipoolest on CDN-proksi ja pilve vahel täielik kontroll ning võimalus kasutada uusi, optimaalseid protokolle ja seadistusi. Ebaefektiivne osa vanade protokollide osas toimib ainult kliendi ja CDN-serveri vahel. Veelgi enam, me saame teha päringute multipliiksust juba kehtestatud ühenduses CDN-i ja pilve vahel, parandades TCP tasandi ühenduse kasutust:

Mõõdame

Kuigi teooria lubab paranemist, ei kiirusta me süsteemi tootmisse käivitama. Selle asemel peame kõigepealt tõestama, et idee toimib praktikas. Selleks tuleb vastata mitmele küsimusele:

• Kiirus: kas proksi on kiirem?
• Usaldusväärsus: kas see katkeneb sagedamini?
• Tähtsus: kuidas integreerida rakendustega?
• Hind: palju maksab täiendava infrastruktuuri käivitamine?

Vaadake täpsemalt meie lähenemist esimese punkti hindamisel. Ülejäänud käsitletakse sarnasel viisil.

Küsimuste kiirusanalüüsi jaoks soovime saada andmeid kõikidelt kasutajatelt, kulutamata liigselt aega arendusele ja mitte purustades tootmist. Selleks on mitu lähenemist:

1. RUM või passiivne päringute mõõtmine. Me mõõdame kasutajate praeguste päringute täitmise aega ja tagame täieliku katvuse. Puuduseks on see, et signaal ei ole väga stabiilne mitmete tegurite tõttu, näiteks päringute erinevad suurused, serveri ja kliendi töötlemisaeg. Lisaks ei ole võimalik uut konfigureerimist testida ilma, et see mõjutaks tootmisprotsessi.
2. Laboratoorsed testid. Spetsiaalsed serverid ja infrastruktuur, mis jäljendavad kliente. Nende abil viime läbi vajalikke teste. Nii saame täieliku kontrolli mõõtmistulemuste üle ja selge signaali. Kuid seadmete ja kasutajate asukoha täielik katvus puudub (eriti ettevõttele, mis tegutseb üle kogu maailma ja toetab tuhandeid seadmemudeleid).

Kuidas saaksme kombineerida mõlema meetodi eeliseid?

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

1. Peale rakenduse laadimist ja esialgsete tegevuste lõpetamist käivitame meie proovid.
2. Kliendilt saadetakse päring serverile, et saada testirecept. Retsept koosneb URL-ade listist, kuhu tuleb teha HTTP(s) päring. Lisaks sellele konfigureerib retsept päringute parameetrid: viivitused päringute vahel, küsitava andmemaht, HTTP(s) päised jms. Me saame samaaegselt testida mitmeid erinevaid retsepte - probleemide korral määratakse juhuslikult, millist retsepti anda.
3. Proovi käivitamise aeg valitakse nii, et see ei kattuks kliendi aktiivsete võrguressursside kasutamisega. Sisuliselt valitakse aeg, mil klient ei ole aktiivne.
4. Pärast retsepti saamist teeb klient päringud iga URL-aadressi peale paralleelselt. Iga aadressi päring võib korduda - nn "pulsside". Esimese pulsi ajal mõõdame, kui kaua kulusühenduse loomine ja andmete edastamine. Teise pulsi ajal mõõdame andmete laadimise aega juba loodud ühenduse kaudu. Enne kolmandat pulti saame seada viivituse ja mõõta uuesti ühenduse loomise kiirus jne.

   Testi käigus mõõdame kõiki parameetreid, mida seade võib saada:

   • DNS päringu aeg;
   • TCP ühenduse loomise aeg;
   • TLS ühenduse loomise aeg;
   • esimese andmebaidi saamise aeg;
   • kokku laadimisaja;
   • tulemuse seisukood.
5. Kõikide pulsitsüklite lõppedes laadib proov analüüsiks kokku kõik mõõtmistulemused.

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

Tänane infrastruktuur osutus kasulikuks mitte ainult päringute jõudluse analüüsimiseks. Meil on hetkel 14 aktiivset retsepti, rohkem kui 6000 proovi sekundis, mis saavad andmeid kõikjatest nurkadest ja katab täielikult seadmeid. Kui Netflix ostaks sarnase teenuse kolmandatelt ettevõtetelt, maksaks see miljoneid dollareid aastas, kuid oluliselt halvemate katvuste korral.

Kontrollime teooriat praktikas: prototüüp

Sellise süsteemiga saime võimaluse hinnata CDN-proksi efektiivsust päringute latentsuse osas. Nüüd on vaja:

• luua proksi prototüüp;
• paigutada prototüüp CDN-i;
• määrata, kuidas suunata kliente konkreetse CDN-serveri proksile;
• võrrelda jõudlust AWS päringutega ilma proksita.

Ülesanne on võimalikult kiiresti hinnata pakutud lahenduse efektiivsust. Prototüübi implementeerimiseks valisime Go, tänu hea võrgu kogumite olemasolule. Iga CDN-serverisse paigaldasime proksi prototüübi staatilise binaarina, et minimeerida sõltuvusi ja lihtsustada integreerimist. Algse rakenduse puhul kasutasime maksimaalselt standardkomponente ja väiksemaid modifikatsioone HTTP/2 ühenduse haldamiseks ja päringute mitmeastmeliseks töötlemiseks.

AWS piirkondade vahel tasakaalu saavutamiseks kasutasime geograafilist DNS andmebaasi, sama, mida kasutatakse klienditasakaalu jaoks. CDN-serveri valimiseks kliendi jaoks kasutame TCP Anycasti Internet Exchange (IX) serverite jaoks. Sellisel juhul kasutame kõigi CDN-serverite jaoks ühte IP-aadressi, mille korral klient suunatakse kõige vähem IP hüppega CDN-serverisse. Meil ei ole kontrolli ISP-de juures asuvate CDN-serverite marsruutimise üle TCP Anycasti seadistamiseks, seetõttu rakendame sama loogikat, mille alusel kliendid suunatakse interneti pakkujate kaudu videostreamingu jaoks.

Nii et meil on kolm tüüpi teid päringu jaoks: pilve kaudu avatud internetti, läbi CDN-serveri IX-is või läbi CDN-serveri, mis asub interneti pakkuja juures. Meie eesmärk on mõista, milline tee on parem ja milline on kasu proksist võrreldes sellega, kuidas päringud lähevad tootmisse. Selleks kasutame katsete süsteemi järgmiselt:

Iga tee muutub eraldi sihtkohaks ja vaatame saadud aega. Analüüsimiseks ühendame proksi tulemused ühte rühma (valime parima aja IX ja ISP proksi vahel) ja võrdleme seda pilve päringute ajaga ilma proksita:

Nagu näha, olid tulemused ebamugavad - enamiku juhtumite korral annab proks hea kiiruskasvu, kuid on ka piisavalt palju kliente, kelle jaoks olukord halveneb.

Kokkuvõttes tegime mitmeid olulisi asju:

1. Hindasime oodatavat päringute jõudlust klientidelt pilve kaudu CDN proksi.
2. Saime andmeid tõelistelt klientidelt, kõikide seadme tüüpide kohta.
3. Mõistsime, et teooria ei kinnitunud 100% ja esialgne ettepanek CDN-proksi jaoks ei toimi.
4. Me ei riskinud - ei muutnud tootmisconfiguratsiooni klientide jaoks.
5. Me ei rikkunud midagi.

Prototüüp 2.0

Nüüd naaseme joonistustahvli juurde ja kordame protsessi uuesti.

Idee on - 100% proksi asemel määratleme iga kliendi jaoks kiireima tee ja suuname päringud sinna - see tähendab, et teeme seda, mida nimetatakse kliendi suunamiseks.

Kuidas seda rakendada? Me ei saa kasutada serveripoolset loogikat, kuna eesmärk on ühendada see server. Peame kuidagi tegema seda kliendi poolel. Ja ideaaljuhul tuleks see teha minimaalse keerulise loogikaga, et vältida laia kliendiplatvormide integreerimise küsimust.

Vastus on DNS-i kasutamine. Meie puhul on meil oma DNS-infrastruktuur ja me saame seadistada domeeninööri, mille jaoks meie serverid on autoriteetsed. See töötab nii:

1. Kliendi küsimus saadetakse DNS-serverisse, kasutades hosti, näiteks api.netflix.com.
2. Küsimus jõuab meie DNS-serverisse.
3. DNS-server teab, milline tee on selle kliendi jaoks kõige kiirem, ja annab vastavad IP-aadressid.

Lahenduses on lisaks veel üks keerukus: autoriteetsed DNS-teenuse pakkujad ei näe kliendi IP-aadressi ja saavad arvesse võtta ainult rekursiivse resolveri IP-aadressi, mida klient kasutab.

Seetõttu peab meie autoriteetne resolver võtma otsuse mitte üksikselle kliendi jaoks, vaid rühma klientide põhjal rekursiivse resolveri järgi.

Lahendamiseks kasutame samu proove, koondame saadud mõõtmiste tulemused klientidelt iga rekursiivse resolveri kohta ja otsustame, kuhu see rühm suunata — kas proxy kaudu IX kasutades TCP Anycast, läbi ISP proxy või otse pilve.

Me saame sellise süsteemi:

Saadud DNS-i suunamismudel võimaldab suunata kliente ajalooliste vaatlustelt põhinevate ühenduste kiirusest klientide ja pilve vahel.

Küsimus on jälle — kui efektiivselt see lähenemine töötab? Vastuse saamiseks kasutame jälle meie proovide süsteemi. Seetõttu seadistame hilise konfiguratsiooni, kus üks sihtkoht järgib DNS-i suunamist, teine — läheb otse pilve (praegune tootmine).

Kokkuvõttes võrdleme tulemusi ja saame efektiivsuse hinnangu:

Kokkuvõtteks saime teada mitu olulist asja:

1. Hindasime oodatavat päringute jõudlust klientidest pilve kasutades DNS-i suunamist.
2. Saime andmeid tõelistelt klientidelt, kõikide seadme tüüpide kohta.
3. Tõestasime pakutud idee efektiivsust.
4. Me ei riskinud - ei muutnud tootmisconfiguratsiooni klientide jaoks.
5. Me ei rikkunud midagi.

Nüüd keerulisest osast — käivitame tootmises.

Kergem osa on nüüd selja taga — meil on töötav prototüüp. Nüüd on keeruline osa — rakendada lahendus kogu Netflixi liikluse jaoks, kasutades 150 miljoni kasutaja, tuhandete seadmete, sadade mikroteenuste ja pidevalt muutuva toote ning infrastruktuuri jaoks. Netflixi serveritesse jõuab miljoneid päringuid sekundis ja meie teenust on lihtne rikkuda ühesuguse tegevusega. Samuti soovime suunata liiklust dünaamiliselt läbi tuhandete CDN serverite, internetis, kus kõik muutub ja katki läheb pidevalt ja kõige ebasobivamal hetkel.

Ja kõik see ajal on meeskonnas 3 inseneri, kes vastutavad süsteemi arendamise, juurutamise ja täieliku toe eest.

Seetõttu räägime edasi rahulikust ja tervislikust unest.

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

1. Vähendame potentsiaalsete rikke ulatust (blast radius).
2. Oleme valmis üllatusteks — ootame, et midagi läheb katki, vaatamata testimisele ja isiklikule kogemusele.
3. Aeglane degradeerumine (graceful degradation) — kui midagi ei tööta õigesti, peaks see automaatselt korda minema, ehkki mitte kõige tõhusamal viisil.

Selgus, et meie puhul, sellise probleemi käsitlemise lähenemisega, on võimalik leida lihtne ja tõhus lahendus ning oluliselt lihtsustada süsteemi hooldust. Meie mõistsime, et saame klienti lisada väikese koodilõigu ja jälgida võrgu päringute vigu, mis on põhjustatud ühendusprobleemidest. Vera võrgu vigade korral teeme otsese fallback lahenduse pilve. Selline lahendus ei nõua kliendi meeskondadelt suuri pingutusi, kuid vähendab oluliselt ootamatute rikke ja üllatuste riski meie jaoks.

Muidugi, hoolimata fallback lahendusest, järgime siiski ranget distsipliini arendamise käigus:

1. Proovide testimine.
2. A/B testimine või Canary testimine.
3. Aeglane vabastamine (progressive rollout).

Proovide osas on lähenemine kirjeldatud — muudatused testitakse kõigepealt seadistatud retsepti abil.

Canary testimiseks peame saama võrreldavad serveripaarid, millel saab võrrelda, kuidas süsteem töötab enne ja pärast muudatusi. Selleks valime meie arvukatest CDN saitidest serveripaarid, millel on sarnane liiklus:

Seejärel paneme muudatuste kogumi Canary-serveritesse. Tulemuste hindamiseks käivitame süsteemi, mis võrdleb umbes 100-150 mõõdikut Control-serveritega:

Kui Canary-testimine on edukas, teeme avalikkusele viidatud väljaande järk-järgult. Igal veebisaidil ei uuenda me servereid korraga — ühte veebisaiti kaotades põhjustab probleem palju suuremat mõju kasutajate teenusele kui sama arvu serverite kadumine, kuid erinevates kohtades.

Üldiselt sõltub sellise lähenemise tõhusus ja ohutus kogutud mõõdikutest nii kvaliteedi kui ka koguse poolest. Meie päringute kiirusete süsteemi jaoks kogume mõõdikud kõigilt võimalikelt komponentidelt:

• kliendilt — seansside ja päringute arv, tagasimakse määr;
• proksi — päringute arvu ja aja statistika;
• DNS — päringute arv ja tulemused;
• cloud edge — päringute töötlemise aeg ja arv pilves.

Kõik see kogutakse ühte pipeline'i ja olenevalt vajadustest otsustame, millised mõõdikud saata reaalajas analüüsiks ja millised Elasticsearchi või suurandmete jaoks detailsemaks diagnostikaks.

Jälgime

Meie juhul teeme muudatusi päringute kriitilisel teel kliendi ja serveri vahel. Samal ajal on kliendi, serveri ja interneti kaudu liikudes palju erinevaid komponente. Kliendis ja serveris toimuvaid muudatusi on pidevalt — kümnete meeskondade töö ja ökosüsteemi loomulike muutuste tulemusena. Me oleme keskel — probleemide diagnoosimisel on suur tõenäosus, et osaleme selles. Seetõttu peame selgelt mõistma, kuidas määrata, koguda ja analüüsida mõõdikuid probleemide kiireks lokaliseerimiseks.

Ideaalis on meil täielik juurdepääs kõigile mõõdikutüüpidele ja filtritele reaalajas. Kuid mõõdikuid on väga palju, seetõttu tekib kulude küsimus. Meie juhul jagame mõõdikud ja arendusvahendid järgmisteks:

Probleemide avastamiseks ja triage'iks kasutame oma avatud lähtekoodiga reaalajas süsteemi Atlas ja Lumen — visualiseerimiseks. See hoiab mälus kogutud mõõdikud, on usaldusväärne ja integreerub häirete süsteemiga. Lokaliseerimise ja diagnostika jaoks on meil juurdepääs logidele Elasticsearchis ja Kibanasse. Statistiliseks analüüsiks ja modelleerimiseks kasutame suurandmeid ja visualiseerimist Tableau's.

Tundub, et sellise lähenemisega on väga keeruline töötada. Kuid hierarhilise mõõdikute ja tööriistade organisatsiooni korral saame probleemi kiiresti analüüsida, probleemi tüübi määrata ja seejärel süveneda detailsetesse mõõdikutesse. Veakohte tuvastamiseks kulutame keskmiselt umbes 1-2 minutit. Pärast seda tegeleme juba konkreetse meeskonnaga diagnostikaga - alates kümnetest minutidest kuni mitme tunnini.

Isegi kui diagnostikat tehakse kiiresti, ei soovi me, et see juhtuks tihti. Ideaalses olukorras saame kriitilise teate ainult siis, kui teenusele on märkimisväärne mõju. Meie päringute kiirendamise süsteemis on meil vaid 2 alerta, mis aitavad meid teavitada:

• Client Fallback protsent - kliendikäitumise hindamine;
• Probe errorite protsent - andmed võrgu komponentide stabiilsusest.

Need kriitilised alertid jälgivad, kas süsteem töötab enamikule kasutajatest. Me vaatame, kui palju kliente kasutas fallback'i, kui nad ei suutnud päringute kiirendust saada. Meil on keskmiselt vähem kui 1 kriitiline teade nädalas, kuigi süsteemis toimub tohutult muudatusi. Miks piisab meile sellest?

1. On olemas client fallback juhul, kui meie proxy ei tööta.
2. On automaatne steering süsteem, mis reageerib probleemidele.

Viimase kohta natuke rohkem. Meie süsteemid, mis teevad proove, ja automaatne parima marsruudi määramise süsteem kliendi päringute jaoks pilve, võimaldavad automaatselt teatud probleemidega toime tulla.

Naaseme meie proovisüsteemi ja 3 marsruudi kategooria juurde. Lisaks laadimisaegadele saame vaadata ka andmete kohaletoimetamise fakti. Kui andmeid ei õnnestu laadida, saame vaadata erinevate marsruutide tulemusi ja määrata, kus ja mis on katki, ning kas saame seda automaatselt parandada, muutes päringu marsruuti.

Näited:

Seda protsessi on võimalik automatiseerida. Sisse lülitada steering süsteemi. Ja õpetada seda reageerima jõudluse ja usaldusväärsuse probleemidele. Kui midagi hakkab lagunema - reageerida, kui on parem võimalus. Samal ajal pole kohene reageerimine kriitiline, tänu fallback'ile klientidele.

Seega, süsteemi toetamise põhimõtted võiks kokku võtta järgmiselt:

• vähendame rikke ulatust;
• kogume mõõdikud;
• parandame rikkeid automaatselt, kui saame;
• kui ei suuda - teavitame;
• Töötame dashboards'i ja triage-tööriistade kallal kiireks reageerimiseks.

Õpitud õppetunnid

Prototüübi kirjutamiseks ei kulu palju aega. Meie puhul oli see valmis juba 4 kuu pärast. Sellega saime uusi mõõdikuid ja 10 kuu möödudes arenduse algusest said valminud esimesed production liiklusandmed. Siis algas igav ja väga keeruline töö: järkjärguline tootmine ja süsteemi skaleerimine, põhilise liikluse migratsioon ja õppimine vigadest. Samas ei toimu see efektiivne protsess lineaarselt — hoolimata kõigist pingutustest ei saa kõike ette ennustada. Oluliselt tõhusam on kiire iteratsioon ja reageerimine uutele andmetele.

Meie kogemusest saame soovitada järgmist:

1. Ärge uskuge oma intuitsiooni.

   Meie intuitsioon on meid pidevalt alt vedanud, hoolimata meie meeskonna liikmete suurest kogemusest. Näiteks ennustasime valesti oodatavat kiirusühet CDN-prokside kasutamisest või TCP Anycast'i käitumist.

2. Hankige andmed production'ist.

   Oluline on võimalikult kiiresti saada ligipääs vähemalt väikesele hulgale production andmetele. Ainult laboratoorses keskkonnas on peaaegu võimatu saada unikaalsete juhtumite, konfiguratsioonide ja seadetega. Kiire ligipääs tulemustele võimaldab kiiremini teada saada potentsiaalsetest probleemidest ja arvestada nendega süsteemi arhitektuuris.

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

   Järgige andmete kogumise ja analüüsimise printsiipe, kuid ärge võtke pimesi teiste tulemusi ja väiteid. Ainult teie saate täpselt teada, mis teie kasutajatele töötab. Teie süsteemid ja teie kliendid võivad oluliselt erineda teistest ettevõtetest. Tänu sellele, et analüüsitööriistad on praegu kergesti kättesaadavad ja kasutatavad. Teie saadud 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 tulemus erinev Facebooki, Uberi, Akamai tulemustest — sest meil on erinevad seadmed, kliendid ja andmevood.

4. Ärge püüdke järgida moe trende ilma vajaduse ja efektiivsuse hindamiseta.

   Alustage lihtsalt. Paremini on luua lihtne ja toimiv süsteem lühikese aja jooksul, kui kulutada tohutult aega teile vajalikest komponentidest loobumisele. Lahendage probleeme ja küsimusi, mis on teie mõõtmiste ja tulemuste põhjal olulised.

5. Valmistuge uute rakenduste jaoks.

   Nagu on keeruline ette näha kõiki probleeme, on keeruline ka ette ennustada eeliseid ja rakendusi. Võtke õppust start-up’idest — nende võime kohaneda klientide nõudmistega. Teie puhul — võite avastada uusi probleeme ja nende lahendusi. Meie projektis seadsime eesmärgiks vähendada päringute latentsust. Kuid analüüsi ja arutelude käigus mõistsime, et saame kasutada ka proxiservereid:

   • liiklusbalansseeringuks AWS piirkondade vahel ja kulude vähendamiseks;
   • CDN stabiilsuse modelleerimiseks;
   • DNS-i konfigureerimiseks;
   • TLS/TCP konfigureerimiseks.

Kokkuvõte

Minu ettekandes kirjeldasin, kuidas Netflix lahendab klientide ja pilve vaheliste internetipäringute kiirendamise ülesande. Kuidas me kogume andmeid klientide kaudu proovide süsteemi abil ja kasutame kogutud ajaloolisi andmeid, et suunata tootmispäringud klientidelt kõige kiirema marsruudi kaudu internetis. Kuidas me rakendame võrguprotokollide tööpõhimõtteid, meie CDN infrastruktuuri, selgroogvõrku ja DNS servereid, et seda ülesannet täita.

Siiski, meie lahendus on vaid näidis sellest, kuidas me Netflixis sellist süsteemi rakendasime. Mis töötas meie jaoks. Minu ettekande praktiline osa teie jaoks — arendamise ja toetamise põhimõtted, mida järgime ja millega saavutame häid tulemusi.

Meie probleemilahendus võib teile mitte sobida. Siiski jäävad teooria ja arendamise põhimõtted kehtima, isegi kui teil ei ole oma CDN infrastruktuuri või kui see erineb oluliselt meie omast.

Oluline on ka päringute kiirus ärile. Isegi lihtsa teenuse puhul tuleb teha valik: 'pilve' pakkujate, serverite asukoha, CDN ja DNS pakkujate vahel. Teie valik mõjutab internetipäringute efektiivsust teie klientide jaoks. Ja teie jaoks on oluline seda mõju mõõta ja mõista.

Alustage lihtsate lahendustega, muretsege, kuidas te toodet muudate. Õppige protsessi käigus ja täiustage süsteemi, lähtudes teie klientide, teie infrastruktuuri ja teie äri andmetest. Mõelge võimalikele ootamatutele rikkele disainimise käigus. Ja siis suudate kiirendada oma arendusprotsessi, parandada lahenduse efektiivsust, vältida liigset koormust toetusele ja rahulikult magada.

Sel aastal toimub konverents 6. kuni 10. juulini veebivormis. Sa saad esitada küsimusi DevOps'i ühele isale, John Willis'ile!

Allikas: habr.com