Netflix on Interneti-televisiooni turu liider - ettevõte, mis lõi ja arendab seda segmenti aktiivselt. Netflix on tuntud mitte ainult oma ulatusliku filmide ja teleseriaalide kataloogi poolest, mis on saadaval peaaegu igast planeedi nurgast ja mis tahes ekraaniga seadmest, vaid ka oma usaldusväärse infrastruktuuri ja ainulaadse insenerikultuuri poolest.
DevOops 2019 esitleti selget näidet Netflixi lähenemisest keerukate süsteemide arendamiseks ja toetamiseks. - Netflixi arendusdirektor. Lõpetanud Nižni Novgorodi Riikliku Ülikooli arvutusmatemaatika ja matemaatika teaduskonna. Lobatševski, Sergei üks esimesi insenere Open Connecti – CDN-i meeskonnas Netflixis. Ta ehitas süsteeme videoandmete jälgimiseks ja analüüsimiseks, käivitas populaarse Interneti-ühenduse kiiruse hindamise teenuse FAST.com ja on viimased paar aastat tegelenud Interneti-päringute optimeerimisega, et Netflixi rakendus töötaks kasutajate jaoks võimalikult kiiresti.
Aruanne sai konverentsil osalejatelt parimaid hinnanguid ning oleme koostanud teile tekstiversiooni.
Sergei rääkis oma ettekandes üksikasjalikult
- selle kohta, mis mõjutab Interneti-päringute viivitust kliendi ja serveri vahel;
- kuidas seda viivitust vähendada;
- kuidas kavandada, hooldada ja jälgida veakindlaid süsteeme;
- kuidas saavutada tulemusi lühikese ajaga ja minimaalse riskiga ettevõttele;
- kuidas tulemusi analüüsida ja vigadest õppida.
Vastuseid neile küsimustele ei vaja ainult need, kes töötavad suurkorporatsioonides.
Esitatud põhimõtteid ja tehnikaid peaksid teadma ja praktiseerima kõik, kes internetitooteid arendavad ja toetavad.
Järgmine on jutustamine kõneleja vaatenurgast.
Interneti kiiruse tähtsus
Interneti-päringute kiirus on otseselt seotud äritegevusega. Mõelge ostutööstusele: Amazon 2009. aastal et 100 ms viivitus toob kaasa 1% müügikaotuse.
Üha rohkem on mobiilseadmeid, millele järgnevad mobiilisaidid ja -rakendused. Kui teie lehe laadimine võtab rohkem kui 3 sekundit, kaotate umbes pooled oma kasutajatest. KOOS Google võtab otsingutulemustes arvesse teie lehe laadimiskiirust: mida kiirem on leht, seda kõrgem on selle positsioon Google'is.
Ühenduse kiirus on oluline ka finantsasutustes, kus latentsusaeg on kriitiline. 2015. aastal Hibernia Networks 400 miljoni dollarine kaabel New Yorgi ja Londoni vahel, et vähendada linnade vahelist latentsust 6 ms võrra. Kujutage ette 66 miljonit dollarit 1 ms latentsusaja vähendamise eest!
Vastavalt , ühenduse kiirused üle 5 Mbit/s ei mõjuta enam otseselt tüüpilise veebisaidi laadimiskiirust. Ühenduse latentsusaja ja lehe laadimiskiiruse vahel on aga lineaarne seos:
Netflix pole aga tüüpiline toode. Latentsuse ja kiiruse mõju kasutajale on aktiivne analüüsi- ja arendusvaldkond. Seal on rakenduste laadimine ja sisu valik, mis sõltuvad latentsusest, kuid staatiliste elementide laadimine ja voogesitus sõltuvad ka ühenduse kiirusest. Kasutajakogemust mõjutavate võtmetegurite analüüsimine ja optimeerimine on Netflixi mitme meeskonna jaoks aktiivne arendusvaldkond. Üks eesmärke on vähendada päringute latentsust Netflixi seadmete ja pilvetaristu vahel.
Aruandes keskendume konkreetselt latentsusaja vähendamisele Netflixi infrastruktuuri näitel. Mõelgem praktilisest vaatenurgast, kuidas läheneda keeruliste hajutatud süsteemide projekteerimise, arendamise ja käitamise protsessidele ning kulutada aega innovatsioonile ja tulemustele, mitte aga tööprobleemide ja rikete diagnoosimisele.
Netflixi sees
Tuhanded erinevad seadmed toetavad Netflixi rakendusi. Neid arendavad neli erinevat meeskonda, kes teevad kliendist eraldi versioonid Androidi, iOS-i, TV ja veebibrauseri jaoks. Ja me kulutame palju jõupingutusi kasutajakogemuse täiustamiseks ja isikupärastamiseks. Selleks teeme paralleelselt sadu A/B-teste.
Isikupärastamist toetavad sajad AWS-i pilves olevad mikroteenused, mis pakuvad isikupärastatud kasutajaandmeid, päringute saatmist, telemeetriat, suurandmeid ja kodeerimist. Liikluse visualiseerimine näeb välja selline:
Vasakul on sisenemispunkt ja seejärel jaotatakse liiklus mitmesaja mikroteenuse vahel, mida toetavad erinevad taustameeskonnad.
Teine meie infrastruktuuri oluline komponent on Open Connect CDN, mis edastab lõppkasutajale staatilise sisu – videod, pildid, kliendikoodi jne. CDN asub kohandatud serverites (OCA – Open Connect Appliance). Sees on SSD- ja HDD-draivide massiivid, mis töötavad optimeeritud FreeBSD-ga koos NGINX-i ja teenuste komplektiga. Disainime ja optimeerime riist- ja tarkvarakomponente, et selline CDN-server saaks kasutajatele saata võimalikult palju andmeid.
Nende serverite "sein" Interneti-liikluse vahetuspunktis (Internet eXchange - IX) näeb välja selline:
Internet Exchange pakub Interneti-teenuse pakkujatele ja sisupakkujatele võimalust üksteisega "ühenduda", et Internetis andmeid otsesemalt vahetada. Üle maailma on ligikaudu 70–80 Interneti-vahetuspunkti, kuhu meie serverid on installitud, ning me paigaldame ja hooldame neid iseseisvalt:
Lisaks pakume ka otse Interneti-teenuse pakkujatele servereid, mille nad installivad oma võrku, parandades Netflixi liikluse lokaliseerimist ja kasutajate voogesituse kvaliteeti:
AWS-teenuste komplekt vastutab klientide videopäringute saatmise eest CDN-serveritesse, samuti serverite endi konfigureerimise eest - sisu, programmikoodi, seadete jne värskendamise eest. Viimase jaoks ehitasime ka magistraalvõrgu, mis ühendab AWS-iga Internet Exchange'i punktides olevad serverid. Põhivõrk on ülemaailmne fiiberoptiliste kaablite ja ruuterite võrk, mida saame kujundada ja konfigureerida vastavalt oma vajadustele.
Edasi , meie CDN-i infrastruktuur edastab tipptundidel ligikaudu ⅛ maailma Interneti-liiklusest ja ⅓ liiklusest Põhja-Ameerikas, kus Netflix on olnud kõige kauem. Muljetavaldavad numbrid, kuid minu jaoks on üks hämmastavamaid saavutusi see, et kogu CDN-süsteemi arendab ja hooldab vähem kui 150-liikmeline meeskond.
Algselt oli CDN-i infrastruktuur mõeldud videoandmete edastamiseks. Kuid aja jooksul mõistsime, et saame seda kasutada ka AWS-i pilves olevate klientide dünaamiliste päringute optimeerimiseks.
Interneti kiirendamisest
Tänapäeval on Netflixil 3 AWS-i piirkonda ja pilve päringute latentsus sõltub sellest, kui kaugel on klient lähimast piirkonnast. Samal ajal on meil palju CDN-servereid, mida kasutatakse staatilise sisu edastamiseks. Kas seda raamistikku saab kuidagi kasutada dünaamiliste päringute kiirendamiseks? Kahjuks on neid taotlusi aga võimatu vahemällu salvestada – API-d on isikupärastatud ja iga tulemus on kordumatu.
Teeme CDN-serveris puhverserveri ja hakkame selle kaudu liiklust saatma. Kas see on kiirem?
Materiel
Meenutagem, kuidas võrguprotokollid töötavad. Tänapäeval kasutab enamik Interneti-liiklust HTTP-sid, mis sõltuvad madalama kihi protokollidest TCP ja TLS. Selleks, et klient saaks serveriga ühenduse luua, teeb ta käepigistuse ning turvalise ühenduse loomiseks peab klient serveriga kolm korda sõnumeid vahetama ja andmete edastamiseks veel vähemalt korra. Kui edasi-tagasi reisi latentsusaeg (RTT) on 100 ms, kuluks meil esimese andmebiti saamiseks 400 ms:
Kui asetame sertifikaadid CDN-serverisse, siis CDN-i lähemal asumisel saab kliendi ja serveri vahelist käepigistuse aega oluliselt vähendada. Oletame, et CDN-serveri latentsusaeg on 30 ms. Siis kulub esimese biti vastuvõtmiseks 220 ms:
Kuid eelised ei lõpe sellega. Kui ühendus on loodud, suurendab TCP ülekoormuse akent (teabe hulka, mida ta saab selle ühenduse kaudu paralleelselt edastada). Kui andmepakett kaob, vähendavad TCP-protokolli klassikalised teostused (nagu TCP New Reno) avatud "akent" poole võrra. Ülekoormusakna kasv ja kaotusest taastumise kiirus sõltub jällegi serveri viivitusest (RTT). Kui see ühendus ulatub ainult CDN-serverini, on taastamine kiirem. Samal ajal on pakettide kadumine tavaline nähtus, eriti traadita võrkude puhul.
Interneti ribalaius võib väheneda, eriti tipptundidel, kasutajate liikluse tõttu, mis võib põhjustada liiklusummikuid. Internetis pole aga mingit võimalust anda ühtedele taotlustele eelisõigus teiste ees. Näiteks eelistage väikseid ja latentsustundlikke päringuid võrku koormavatele "rasketele" andmevoogudele. Kuid meie puhul võimaldab oma magistraalvõrk meil seda teha osal päringu teest – CDN-i ja pilve vahel ning me saame selle täielikult konfigureerida. Saate veenduda, et väikesed ja latentsustundlikud paketid on prioriteediks ning suured andmevood lähevad veidi hiljem. Mida lähemal on CDN kliendile, seda suurem on efektiivsus.
Rakendustaseme protokollid (OSI tase 7) mõjutavad ka latentsust. Uued protokollid, nagu HTTP/2, optimeerivad paralleelsete päringute toimivust. Siiski on meil Netflixi kliente vanemate seadmetega, mis uusi protokolle ei toeta. Kõiki kliente ei saa värskendada ega optimaalselt konfigureerida. Samal ajal on CDN-i puhverserveri ja pilve vahel täielik kontroll ja võimalus kasutada uusi optimaalseid protokolle ja sätteid. Vanade protokollidega ebaefektiivne osa töötab ainult kliendi ja CDN-serveri vahel. Lisaks saame teha multipleksitaotlusi juba loodud ühenduses CDN-i ja pilve vahel, parandades ühenduse kasutamist TCP tasemel:
Me mõõdame
Hoolimata sellest, et teooria tõotab täiustusi, ei torma me kohe süsteemi tootmisse käivitama. Selle asemel peame esmalt tõestama, et idee töötab praktikas. Selleks peate vastama mitmele küsimusele:
- Kiirus: kas puhverserver on kiirem?
- Usaldusväärsus: Kas see läheb sagedamini katki?
- Keerukus: kuidas rakendustega integreerida?
- Maksma: Kui palju maksab täiendava infrastruktuuri juurutamine?
Vaatleme üksikasjalikult oma lähenemisviisi esimese punkti hindamisel. Ülejäänutega tegeletakse sarnaselt.
Taotluste kiiruse analüüsimiseks soovime saada andmeid kõigi kasutajate kohta, kulutamata palju aega arendusele ja ilma tootmist rikkumata. Selleks on mitu lähenemisviisi:
- RUM ehk passiivse päringu mõõtmine. Mõõdame kasutajate praeguste päringute täitmisaega ja tagame täieliku kasutajakatte. Puuduseks on see, et signaal ei ole väga stabiilne paljude tegurite tõttu, näiteks erinevate päringu suuruste, serveri ja kliendi töötlemisaja tõttu. Lisaks ei saa te uut konfiguratsiooni katsetada ilma mõju tootmisprotsessis.
- Laboratoorsed uuringud. Spetsiaalsed serverid ja infrastruktuur, mis simuleerivad kliente. Nende abiga viime läbi vajalikud testid. Nii saame täieliku kontrolli mõõtmistulemuste üle ja selge signaali. Kuid seadmete ja kasutajate asukohtade täielik katvus puudub (eriti ülemaailmse teenuse ja tuhandete seadmemudelite toega).
Kuidas saate ühendada mõlema meetodi eelised?
Meie meeskond on leidnud lahenduse. Kirjutasime väikese koodilõigu – näidise –, mille ehitasime oma rakendusse. Sondid võimaldavad meil teha meie seadmetest täielikult kontrollitud võrguteste. See toimib järgmiselt:
- Vahetult pärast rakenduse laadimist ja esialgse tegevuse lõpetamist käivitame oma proovid.
- Klient esitab serverile päringu ja saab testi jaoks “retsepti”. Retsept on URL-ide loend, millele tuleb teha HTTP(de) päring. Lisaks konfigureerib retsept päringu parameetrid: päringutevahelised viivitused, küsitavate andmete hulk, HTTP(de) päised jne. Samal ajal saame paralleelselt testida mitut erinevat retsepti – seadistust küsides määrame juhuslikult, milline retsept väljastada.
- Proovi käivitamise aeg valitakse nii, et see ei oleks vastuolus kliendi võrguressursside aktiivse kasutamisega. Põhimõtteliselt valitakse aeg, mil klient ei ole aktiivne.
- Pärast retsepti saamist esitab klient paralleelselt päringuid igale URL-ile. Taotlust igale aadressile saab korrata – nn. "impulssid". Esimese impulsi korral mõõdame, kui kaua kulus ühenduse loomiseks ja andmete allalaadimiseks. Teise impulsi korral mõõdame aega, mis kulub andmete laadimiseks juba loodud ühenduse kaudu. Enne kolmandat saame määrata viivituse ja mõõta taasühenduse loomise kiirust jne.
Katse ajal mõõdame kõiki parameetreid, mida seade suudab saada:
- DNS-i päringu aeg;
- TCP-ühenduse seadistamise aeg;
- TLS-ühenduse seadistamise aeg;
- esimese andmebaidi vastuvõtmise aeg;
- kogu laadimisaeg;
- oleku tulemuse kood.
- Kui kõik impulsid on lõppenud, laadib proov analüüsiks kõik mõõtmised.
Põhipunktid on minimaalne sõltuvus kliendi loogikast, andmetöötlus serveris ja paralleelsete päringute mõõtmine. Seega suudame eristada ja testida erinevate päringu toimivust mõjutavate tegurite mõju, neid ühe retsepti piires varieerida ning saada tulemusi tegelikelt klientidelt.
See infrastruktuur on osutunud kasulikuks rohkem kui lihtsalt päringu toimivuse analüüsi jaoks. Praegu on meil 14 aktiivset retsepti, üle 6000 proovi sekundis, mis võtavad vastu andmeid kõigist maanurkadest ja täieliku seadme leviala. Kui Netflix ostaks sarnase teenuse kolmandalt osapoolelt, maksaks see aastas miljoneid dollareid ja palju halvema katvuse korral.
Testiteooria praktikas: prototüüp
Sellise süsteemiga saime hinnata CDN-i puhverserverite tõhusust päringu latentsusajal. Nüüd vajate:
- luua puhverserveri prototüüp;
- asetage prototüüp CDN-ile;
- määrata, kuidas suunata kliente konkreetse CDN-serveri puhverserverile;
- Võrrelge jõudlust ilma puhverserverita AWS-i taotlustega.
Ülesanne on võimalikult kiiresti hinnata pakutud lahenduse tõhusust. Prototüübi juurutamiseks valisime Go, kuna on olemas head võrguteegid. Igasse CDN-serverisse installisime prototüübi puhverserveri staatilise kahendfailina, et minimeerida sõltuvusi ja lihtsustada integreerimist. Esialgsel juurutamisel kasutasime HTTP/2-ühenduse ühendamiseks ja taotluste multipleksimiseks nii palju kui võimalik standardseid komponente ja väiksemaid muudatusi.
AWS-i piirkondade tasakaalustamiseks kasutasime geograafilist DNS-i andmebaasi, sama, mida kasutatakse klientide tasakaalustamiseks. Kliendi CDN-serveri valimiseks kasutame Internet Exchange'i (IX) serverite jaoks TCP Anycasti. Selle valiku puhul kasutame kõigi CDN-serverite jaoks ühte IP-aadressi ja klient suunatakse kõige väiksema IP-hüppe arvuga CDN-serverisse. Interneti-teenuse pakkujate (ISP-de) installitud CDN-serverites ei ole meil TCP Anycasti konfigureerimiseks ruuteri üle kontrolli, seega kasutame , mis suunab kliendid video voogesituse saamiseks Interneti-teenuse pakkujate juurde.
Seega on meil kolme tüüpi päringuteid: pilve avatud Interneti kaudu, IX-s asuva CDN-serveri kaudu või Interneti-teenuse pakkuja juures asuva CDN-serveri kaudu. Meie eesmärk on mõista, milline viis on parem ja mis kasu on puhverserverist võrreldes sellega, kuidas päringud tootmisse saadetakse. Selleks kasutame proovivõtusüsteemi järgmiselt:
Igast teest saab eraldi sihtmärk ja me vaatame kätte jõudnud aega. Analüüsiks ühendame puhverserveri tulemused ühte rühma (valime parima aja IX ja ISP puhverserveri vahel) ja võrdleme neid ilma puhverserverita pilve päringute ajaga:
Nagu näha, olid tulemused segased – enamasti annab puhver hea hoo, kuid on ka piisavalt palju kliente, kelle puhul olukord oluliselt halveneb.
Selle tulemusena tegime mitmeid olulisi asju:
- Hindasime CDN-i puhverserveri kaudu klientidelt pilve suunduvate päringute eeldatavat toimivust.
- Saime andmeid päris klientidelt, igat tüüpi seadmetelt.
- Saime aru, et teooria ei leidnud 100% kinnitust ja esialgne pakkumine CDN-i puhverserveriga meie jaoks ei tööta.
- Me ei võtnud riske – me ei muutnud klientide jaoks tootmiskonfiguratsioone.
- Midagi ei olnud katki.
Prototüüp 2.0
Niisiis, tagasi joonistuslauale ja korrake protsessi uuesti.
Idee on selles, et 100% puhverserveri kasutamise asemel määrame igale kliendile kõige kiirema tee ja saadame sinna päringud – ehk teeme seda, mida nimetatakse kliendijuhtimiseks.
Kuidas seda rakendada? Me ei saa serveri poolel loogikat kasutada, sest... Eesmärk on selle serveriga ühendus luua. Peab olema mingi viis seda kliendi peal teha. Ja ideaaljuhul tehke seda minimaalse keeruka loogikaga, et mitte lahendada suure hulga kliendiplatvormidega integreerimise probleemi.
Vastus on DNS-i kasutamine. Meie puhul on meil oma DNS-infrastruktuur ja saame seadistada domeenitsooni, mille jaoks meie serverid on autoritaarsed. See toimib järgmiselt:
- Klient esitab DNS-serverile päringu, kasutades hosti, näiteks api.netflix.xom.
- Päring saabub meie DNS-serverisse
- DNS-server teab, milline tee on selle kliendi jaoks kiireim, ja väljastab vastava IP-aadressi.
Lahendusel on täiendav keerukus: autoritaarsed DNS-i pakkujad ei näe kliendi IP-aadressi ja saavad lugeda ainult kliendi kasutatava rekursiivse lahendaja IP-aadressi.
Sellest tulenevalt peab meie autoritaarne lahendaja tegema otsuse mitte üksiku kliendi, vaid rekursiivse lahendaja alusel klientide rühma kohta.
Lahendamiseks kasutame samu näidiseid, koondame iga rekursiivse lahendaja jaoks klientide mõõtmistulemused ja otsustame, kuhu see rühm saata – puhverserver IX kaudu TCP Anycasti abil, ISP puhverserveri kaudu või otse pilve.
Saame järgmise süsteemi:
Saadud DNS-juhtimismudel võimaldab teil kliente suunata ajalooliste vaatluste põhjal klientidelt pilve suunduvate ühenduste kiiruse kohta.
Jällegi on küsimus selles, kui tõhusalt see lähenemisviis töötab? Vastamiseks kasutame taas oma sondisüsteemi. Seetõttu konfigureerime esitleja konfiguratsiooni, kus üks sihtmärkidest järgib DNS-i juhtimise suunda, teine läheb otse pilve (praegune tootmine).
Selle tulemusena võrdleme tulemusi ja saame hinnangu tõhususe kohta:
Selle tulemusena õppisime mitmeid olulisi asju:
- Hindasime DNS-juhtimise abil klientidelt pilve saadetavate päringute eeldatavat toimivust.
- Saime andmeid päris klientidelt, igat tüüpi seadmetelt.
- Väljapakutud idee tõhusus on tõestatud.
- Me ei võtnud riske – me ei muutnud klientide jaoks tootmiskonfiguratsioone.
- Midagi ei olnud katki.
Nüüd keerulisest osast – käivitame selle tootmises
Lihtne osa on nüüd läbi – olemas on töötav prototüüp. Nüüd on raske osa kogu Netflixi liikluse jaoks mõeldud lahenduse käivitamisest, mis on juurutatud 150 miljonile kasutajale, tuhandetele seadmetele, sadadele mikroteenustele ning pidevalt muutuvale tootele ja infrastruktuurile. Netflixi serverid saavad miljoneid päringuid sekundis ja hooletu tegevusega on teenust lihtne katkestada. Samal ajal tahame liiklust dünaamiliselt suunata läbi tuhandete Internetis asuvate CDN-serverite, kus pidevalt ja kõige ebasobivamal hetkel midagi muutub ja katkeb.
Ja kõige selle juures on meeskonnas 3 inseneri, kes vastutavad süsteemi arendamise, juurutamise ja täieliku toe eest.
Seetõttu räägime jätkuvalt kosutavast ja tervislikust unest.
Kuidas jätkata arengut ja mitte kulutada kogu aega toetusele? Meie lähenemisviis põhineb kolmel põhimõttel:
- Vähendame rikete võimalikku ulatust (lööklaine raadius).
- Valmistume üllatusteks – eeldame, et vaatamata katsetustele ja isiklikule kogemusele läheb midagi katki.
- Graatsiline halvenemine – kui miski ei tööta õigesti, tuleks see automaatselt parandada, isegi kui mitte kõige tõhusamal viisil.
Selgus, et meie puhul saame sellise lähenemisega probleemile leida lihtsa ja tõhusa lahenduse ning oluliselt lihtsustada süsteemituge. Saime aru, et saame kliendile lisada väikese koodijupi ja jälgida ühenduse probleemidest põhjustatud võrgupäringu vigu. Võrgutõrgete korral teeme tagasilöögi otse pilve. See lahendus ei nõua kliendimeeskondadelt märkimisväärset pingutust, kuid vähendab oluliselt meie jaoks ootamatute rikete ja ootamatuste ohtu.
Muidugi, vaatamata tagasilöögile, järgime arenduse käigus siiski selget distsipliini:
- Näidistest.
- A/B testimine või Kanaarid.
- Järkjärguline levitamine.
Proovidega on lähenemist kirjeldatud – muudatusi testitakse esmalt kohandatud retsepti abil.
Kanaari testimiseks peame hankima võrreldavad serveripaarid, millel saame võrrelda süsteemi toimimist enne ja pärast muudatusi. Selleks valime oma paljudelt CDN-saitidelt serveripaarid, mis saavad võrreldavat liiklust:
Seejärel installime muudatustega versiooni Canary serverisse. Tulemuste hindamiseks käitame süsteemi, mis võrdleb umbes 100–150 mõõdikut kontrollserverite näidisega.
Kui Canary testimine on edukas, vabastame selle järk-järgult, lainetena. Me ei uuenda igal saidil servereid korraga – probleemide tõttu terve saidi kaotamine mõjutab teenusele kasutajate jaoks oluliselt rohkem kui sama arvu serverite kaotamine erinevates asukohtades.
Üldiselt sõltub selle lähenemisviisi tõhusus ja ohutus kogutud mõõdikute kogusest ja kvaliteedist. Oma päringukiirendussüsteemi jaoks kogume mõõdikuid kõigist võimalikest komponentidest.
- klientidelt - seansside ja taotluste arv, varumäärad;
- puhverserver – päringute arvu ja aja statistika;
- DNS - päringute arv ja tulemused;
- cloud edge – päringute arv ja aeg pilves töötlemiseks.
Kõik see kogutakse ühte konveierisse ja vastavalt vajadustele otsustame, millised mõõdikud saata reaalajas analüütikasse ning millised Elasticsearchi või Big Datasse täpsema diagnostika jaoks.
Me jälgime
Meie puhul teeme muudatusi kliendi ja serveri vahelisel päringute kriitilisel teel. Samal ajal on erinevate komponentide hulk nii kliendis, serveris kui ka Interneti teel tohutult palju. Muutused kliendis ja serveris toimuvad pidevalt – kümnete meeskondade töö ja ökosüsteemi loomulike muutuste käigus. Oleme keskel – probleemide diagnoosimisel on hea võimalus, et oleme kaasatud. Seetõttu peame selgelt mõistma, kuidas probleemide kiireks eraldamiseks mõõdikuid määratleda, koguda ja analüüsida.
Ideaalis on täielik juurdepääs igat tüüpi mõõdikutele ja filtritele reaalajas. Kuid mõõdikuid on palju, seega tekib kulude küsimus. Meie puhul eraldame mõõdikud ja arendustööriistad järgmiselt.
Probleemide tuvastamiseks ja sorteerimiseks kasutame oma avatud lähtekoodiga reaalajas süsteemi и - visualiseerimiseks. See salvestab mällu koondatud mõõdikud, on usaldusväärne ja integreerub hoiatussüsteemiga. Lokaliseerimiseks ja diagnostikaks on meil juurdepääs Elasticsearchi ja Kibana logidele. Statistilise analüüsi ja modelleerimise jaoks kasutame Tableaus suurandmeid ja visualiseerimist.
Tundub, et selle lähenemisviisiga on väga raske töötada. Mõõdikute ja tööriistade hierarhiliselt korraldades saame aga probleemi kiiresti analüüsida, määrata probleemi tüübi ja seejärel uurida üksikasjalikke mõõdikuid. Üldiselt kulutame rikke allika tuvastamiseks umbes 1-2 minutit. Pärast seda töötame koos konkreetse meeskonnaga diagnostika kallal - kümnetest minutitest kuni mitme tunnini.
Isegi kui diagnoos tehakse kiiresti, ei taha me, et seda sageli juhtuks. Ideaalis saame kriitilise hoiatuse ainult siis, kui see mõjutab teenust oluliselt. Meie päringukiirendussüsteemi jaoks on meil ainult kaks hoiatust, mis teavitavad:
- Client Fallback protsent – hinnang kliendi käitumisele;
- protsent Probe errors – võrgukomponentide stabiilsusandmed.
Need kriitilised hoiatused jälgivad, kas süsteem töötab enamiku kasutajate jaoks. Vaatleme, kui paljud kliendid kasutasid tagavara, kui neil ei õnnestunud taotluskiirendust saada. Meil on keskmiselt vähem kui üks kriitiline hoiatus nädalas, kuigi süsteemis toimub palju muudatusi. Miks meile sellest piisab?
- Kui meie puhverserver ei tööta, on tegemist kliendi tagavaraga.
- Olemas on automaatne roolisüsteem, mis reageerib probleemidele.
Täpsemalt viimase kohta. Meie proovisüsteem ja süsteem kliendilt pilve suunduvate päringute optimaalse tee automaatseks määramiseks võimaldavad meil teatud probleemidega automaatselt toime tulla.
Pöördume tagasi näidiskonfiguratsiooni ja 3 teekategooria juurde. Lisaks laadimisajale saame vaadata kohaletoimetamise fakti ennast. Kui andmeid ei olnud võimalik laadida, siis erinevaid teid pidi tulemusi vaadates saame kindlaks teha, kus ja mis katki läks ning kas päringu teed muutes saame seda automaatselt parandada.
Näited:
Seda protsessi saab automatiseerida. Kaasake see roolisüsteemi. Ja õpetage seda reageerima jõudluse ja töökindluse probleemidele. Kui midagi hakkab purunema, siis reageerige, kui on parem variant. Samal ajal ei ole kohene reageerimine kriitilise tähtsusega, kuna see on klientide tagavaraks.
Seega saab süsteemitoe põhimõtted sõnastada järgmiselt:
- rikete ulatuse vähendamine;
- mõõdikute kogumine;
- Võimaluse korral parandame rikkeid automaatselt;
- kui ei saa, teavitame teid sellest;
- Töötame kiireks reageerimiseks armatuurlaudade ja triaažitööriistade komplektiga.
Õppetunnid
Prototüübi kirjutamine ei võta palju aega. Meie puhul oli see valmis 4 kuu pärast. Sellega saime uued mõõdikud ja 10 kuud pärast arenduse algust saime esimese tootmisliikluse. Seejärel algas tüütu ja väga raske töö: järk-järgult toota ja skaleerida süsteem, migreerida põhiliiklus ja õppida vigadest. See tõhus protsess ei ole aga lineaarne – vaatamata kõikidele pingutustele ei saa kõike ette ennustada. Palju tõhusam on kiiresti itereerida ja uutele andmetele reageerida.
Oma kogemuse põhjal saame soovitada järgmist:
- Ärge usaldage oma intuitsiooni.
Meie intuitsioon pettis meid pidevalt, vaatamata meie meeskonnaliikmete tohutule kogemusele. Näiteks ennustasime valesti CDN-i puhverserveri kasutamise või TCP Anycasti käitumise eeldatavat kiirust.
- Hankige andmed tootmisest.
Oluline on saada võimalikult kiiresti juurdepääs vähemalt väikesele hulgale tootmisandmetele. Laboritingimustes on peaaegu võimatu saada unikaalsete juhtumite, konfiguratsioonide ja seadistuste arvu. Kiire juurdepääs tulemustele võimaldab teil kiiresti teada saada võimalikest probleemidest ja võtta neid süsteemi arhitektuuris arvesse.
- Ärge järgige teiste nõuandeid ja tulemusi – koguge oma andmeid.
Järgige andmete kogumise ja analüüsimise põhimõtteid, kuid ärge aktsepteerige pimesi teiste inimeste tulemusi ja väljaütlemisi. Ainult teie saate täpselt teada, mis teie kasutajate jaoks töötab. Teie süsteemid ja kliendid võivad teistest ettevõtetest oluliselt erineda. Õnneks on analüüsivahendid nüüd saadaval ja neid on lihtne kasutada. Saadud tulemused ei pruugi olla need, mida Netflix, Facebook, Akamai ja teised ettevõtted väidavad. Meie puhul erineb TLS-i, HTTP2 või DNS-i päringute statistika jõudlus Facebooki, Uberi, Akamai tulemustest – kuna meil on erinevad seadmed, kliendid ja andmevood.
- Ärge järgige asjatult moesuundeid ja hinnake tõhusust.
Alusta lihtsast. Parem on teha lihtne töötav süsteem lühikese ajaga, kui kulutada tohutult aega mittevajalike komponentide väljatöötamisele. Lahendage oma mõõtmiste ja tulemuste põhjal olulisi ülesandeid ja probleeme.
- Olge valmis uuteks rakendusteks.
Nii nagu kõiki probleeme on raske ette näha, on raske ette ennustada ka eeliseid ja rakendusi. Võtke eeskuju idufirmadest – nende võimest kohaneda kliendi tingimustega. Teie puhul võite avastada uusi probleeme ja nende lahendusi. Oma projektis seadsime eesmärgiks vähendada päringu latentsust. Analüüsi ja arutelude käigus saime aga aru, et saame kasutada ka puhverservereid:
- tasakaalustada liiklust AWS-i piirkondade vahel ja vähendada kulusid;
- CDN-i stabiilsuse modelleerimiseks;
- DNS konfigureerimiseks;
- TLS/TCP konfigureerimiseks.
Järeldus
Aruandes kirjeldasin, kuidas Netflix lahendab klientide ja pilve vaheliste Interneti-päringute kiirendamise probleemi. Kuidas me kogume andmeid klientide valimisüsteemi abil ja kasutame kogutud ajaloolisi andmeid klientide tootmispäringute suunamiseks Internetis kiireima tee kaudu. Kuidas me kasutame selle ülesande täitmiseks võrguprotokollide, meie CDN-i infrastruktuuri, magistraalvõrgu ja DNS-serverite põhimõtteid.
Meie lahendus on aga vaid näide sellest, kuidas me Netflixis sellise süsteemi juurutasime. Mis meie jaoks töötas. Minu raporti rakenduslik osa teile on arendamise ja toetamise põhimõtted, mida järgime ja häid tulemusi saavutame.
Meie lahendus probleemile ei pruugi teile sobida. Teooria ja disainipõhimõtted jäävad siiski alles, isegi kui teil pole oma CDN-i infrastruktuuri või kui see erineb oluliselt meie omast.
Samuti jääb oluliseks äripäringute kiiruse tähtsus. Ja isegi lihtsa teenuse jaoks peate tegema valiku: pilveteenuse pakkujate, serveri asukoha, CDN-i ja DNS-i pakkujate vahel. Teie valik mõjutab teie klientide Interneti-päringute tõhusust. Ja teie jaoks on oluline seda mõju mõõta ja mõista.
Alustage lihtsatest lahendustest, hoolige sellest, kuidas toodet vahetate. Õppige töö käigus ja täiustage süsteemi oma klientide, infrastruktuuri ja ettevõtte andmete põhjal. Mõelge projekteerimise käigus ootamatute rikete võimalusele. Ja siis saate kiirendada oma arendusprotsessi, parandada lahenduste tõhusust, vältida tarbetut tugikoormust ja magada rahulikult.
Sel aastal veebivormingus. Küsimusi saab esitada ühele DevOpsi isale, John Willisele endale!
Allikas: www.habr.com