„Netflix“ yra internetinės televizijos rinkos lyderė – įmonė, sukūrusi ir aktyviai plėtojanti šį segmentą. „Netflix“ yra žinomas ne tik dėl savo plataus filmų ir TV serialų katalogo, pasiekiamo beveik iš visų planetos kampelių ir bet kurio įrenginio su ekranu, bet ir dėl patikimos infrastruktūros bei unikalios inžinerinės kultūros.
Aiškus „Netflix“ požiūrio į sudėtingų sistemų kūrimą ir palaikymą pavyzdys buvo pristatytas „DevOops 2019“ – „Netflix“ plėtros direktorius. Nižnij Novgorodo valstybinio universiteto Kompiuterinės matematikos ir matematikos fakulteto absolventas. Lobačevskis, Sergejus vienas pirmųjų „Open Connect“ inžinierių – „Netflix“ CDN komandos. Jis sukūrė vaizdo duomenų stebėjimo ir analizės sistemas, pradėjo populiarią interneto ryšio greičio vertinimo paslaugą FAST.com, o pastaruosius kelerius metus dirbo optimizuodamas interneto užklausas, kad „Netflix“ programa vartotojams veiktų kuo greičiau.
Pranešimas sulaukė geriausių konferencijos dalyvių įvertinimų, o mes jums paruošėme tekstinę versiją.
Savo pranešime Sergejus kalbėjo išsamiai
- apie tai, kas turi įtakos interneto užklausų vėlavimui tarp kliento ir serverio;
- kaip sumažinti šį vėlavimą;
- kaip kurti, prižiūrėti ir stebėti klaidų tolerantiškas sistemas;
- kaip pasiekti rezultatų per trumpą laiką ir su minimalia rizika verslui;
- kaip analizuoti rezultatus ir mokytis iš klaidų.
Atsakymų į šiuos klausimus reikia ne tik tiems, kurie dirba didelėse korporacijose.
Pateiktus principus ir būdus turėtų žinoti ir praktikuoti visi, kurie kuria ir palaiko interneto produktus.
Kitas yra pasakojimas iš kalbėtojo perspektyvos.
Interneto greičio svarba
Interneto užklausų greitis yra tiesiogiai susijęs su verslu. Apsvarstykite prekybos pramonę: „Amazon“ 2009 m kad 100 ms delsimas praranda 1 % pardavimų.
Atsiranda vis daugiau mobiliųjų įrenginių, o toliau seka mobiliosios svetainės ir programos. Jei jūsų puslapis įkeliamas ilgiau nei 3 sekundes, prarandate maždaug pusę naudotojų. SU Google atsižvelgia į Jūsų puslapio įkėlimo greitį paieškos rezultatuose: kuo greitesnis puslapis, tuo aukštesnė jo pozicija Google.
Ryšio greitis taip pat svarbus finansų įstaigose, kuriose delsa yra labai svarbi. 2015 m. „Hibernia Networks“. 400 milijonų dolerių vertės kabelis tarp Niujorko ir Londono, siekiant sumažinti delsą tarp miestų 6 ms. Įsivaizduokite 66 milijonus USD už 1 ms delsos sumažinimą!
Pagal , ryšio sparta, viršijanti 5 Mbit/s, nebeturi tiesioginės įtakos įprastos svetainės įkėlimo greičiui. Tačiau yra tiesinis ryšys tarp ryšio delsos ir puslapio įkėlimo greičio:
Tačiau „Netflix“ nėra įprastas produktas. Vėlavimo ir greičio įtaka vartotojui yra aktyvi analizės ir kūrimo sritis. Yra programų įkėlimas ir turinio pasirinkimas, kurie priklauso nuo delsos, tačiau statinių elementų įkėlimas ir srautinis perdavimas taip pat priklauso nuo ryšio greičio. Pagrindinių veiksnių, turinčių įtakos vartotojo patirčiai, analizė ir optimizavimas yra aktyvi kelių „Netflix“ komandų plėtros sritis. Vienas iš tikslų – sumažinti užklausų tarp „Netflix“ įrenginių ir debesų infrastruktūros delsą.
Ataskaitoje daugiausia dėmesio skirsime delsos mažinimui, naudodamiesi „Netflix“ infrastruktūros pavyzdžiu. Panagrinėkime praktiniu požiūriu, kaip žiūrėti į sudėtingų paskirstytų sistemų projektavimo, kūrimo ir eksploatavimo procesus ir skirti laiko naujovėms bei rezultatams, o ne veiklos problemų ir gedimų diagnostikai.
„Netflix“ viduje
Tūkstančiai skirtingų įrenginių palaiko „Netflix“ programas. Juos kuria keturios skirtingos komandos, kurios kuria atskiras kliento versijas Android, iOS, TV ir interneto naršyklėms. Mes dedame daug pastangų, kad pagerintume ir suasmenintume vartotojo patirtį. Norėdami tai padaryti, lygiagrečiai vykdome šimtus A/B testų.
Personalizavimą palaiko šimtai mikro paslaugų AWS debesyje, teikiančių suasmenintus vartotojo duomenis, užklausų siuntimą, telemetriją, didelius duomenis ir kodavimą. Eismo vizualizacija atrodo taip:
Kairėje yra įėjimo taškas, o tada srautas paskirstomas tarp kelių šimtų mikro paslaugų, kurias palaiko skirtingos užpakalinės programos.
Kitas svarbus mūsų infrastruktūros komponentas yra Open Connect CDN, kuris galutiniam vartotojui pateikia statinį turinį – vaizdo įrašus, vaizdus, kliento kodą ir kt. CDN yra pasirinktiniuose serveriuose (OCA – Open Connect Appliance). Viduje yra SSD ir HDD diskų masyvai, kuriuose veikia optimizuotas FreeBSD, su NGINX ir paslaugų rinkiniu. Projektuojame ir optimizuojame techninės ir programinės įrangos komponentus, kad toks CDN serveris galėtų siųsti kuo daugiau duomenų vartotojams.
Šių serverių „siena“ interneto srauto mainų taške (Internet eXchange – IX) atrodo taip:
„Internet Exchange“ suteikia galimybę interneto paslaugų teikėjams ir turinio teikėjams „jungtis“ vieniems su kitais, kad būtų galima tiesiogiai keistis duomenimis internete. Visame pasaulyje yra apie 70-80 interneto mainų taškų, kuriuose yra įdiegti mūsų serveriai, kuriuos mes savarankiškai įdiegiame ir prižiūrime:
Be to, tiesiogiai interneto tiekėjams teikiame serverius, kuriuos jie įdiegia savo tinkle, pagerindami „Netflix“ srauto lokalizaciją ir srautinio perdavimo kokybę vartotojams:
AWS paslaugų rinkinys yra atsakingas už vaizdo užklausų siuntimą iš klientų į CDN serverius, taip pat už pačių serverių konfigūravimą – turinio, programos kodo, nustatymų atnaujinimą ir kt. Pastariesiems taip pat sukūrėme pagrindinį tinklą, jungiantį serverius interneto mainų taškuose su AWS. Pagrindinis tinklas yra pasaulinis šviesolaidinių kabelių ir maršrutizatorių tinklas, kurį galime sukurti ir konfigūruoti pagal savo poreikius.
Apie , mūsų CDN infrastruktūra piko valandomis perduoda maždaug ⅛ pasaulio interneto srauto ir ⅓ srauto Šiaurės Amerikoje, kur „Netflix“ veikia ilgiausiai. Įspūdingi skaičiai, bet man vienas nuostabiausių pasiekimų yra tai, kad visą CDN sistemą kuria ir prižiūri mažiau nei 150 žmonių komanda.
Iš pradžių CDN infrastruktūra buvo sukurta vaizdo duomenims teikti. Tačiau laikui bėgant supratome, kad galime jį naudoti ir optimizuodami dinamines klientų užklausas AWS debesyje.
Apie interneto spartinimą
Šiandien „Netflix“ turi 3 AWS regionus, o užklausų į debesį delsa priklausys nuo to, kiek klientas yra nuo artimiausio regiono. Tuo pačiu metu turime daug CDN serverių, kurie naudojami statiniam turiniui pateikti. Ar yra koks nors būdas naudoti šią sistemą dinaminėms užklausoms paspartinti? Tačiau, deja, šių užklausų talpykloje išsaugoti neįmanoma – API yra personalizuotos ir kiekvienas rezultatas yra unikalus.
Sukurkime tarpinį serverį CDN serveryje ir pradėkime per jį siųsti srautą. Ar bus greičiau?
Materiel
Prisiminkime, kaip veikia tinklo protokolai. Šiandien didžioji dalis srauto internete naudoja HTTP, kuris priklauso nuo žemesnio sluoksnio protokolų TCP ir TLS. Kad klientas galėtų prisijungti prie serverio, jis paspaudžia rankos paspaudimą, o užmegzti saugų ryšį, klientas turi tris kartus apsikeisti pranešimais su serveriu ir dar bent vieną kartą, kad perduotų duomenis. Jei kelionės į abi puses delsa (RTT) yra 100 ms, mums prireiktų 400 ms, kad gautume pirmąjį duomenų bitą:
Jei sertifikatus patalpinsime į CDN serverį, tada rankos paspaudimo laikas tarp kliento ir serverio gali būti žymiai sumažintas, jei CDN yra arčiau. Tarkime, CDN serverio delsa yra 30 ms. Tada prireiks 220 ms, kol bus gautas pirmasis bitas:
Tačiau privalumai tuo nesibaigia. Užmezgus ryšį, TCP padidina perkrovos langą (informacijos kiekį, kurį jis gali lygiagrečiai perduoti tuo ryšiu). Jei duomenų paketas prarandamas, klasikiniai TCP protokolo diegimai (pvz., TCP New Reno) sumažina atvirą „langą“ per pusę. Perkrovos lango augimas ir jo atsigavimo po nuostolių greitis vėlgi priklauso nuo delsos (RTT) iki serverio. Jei šis ryšys tęsis tik iki CDN serverio, atkūrimas bus greitesnis. Tuo pačiu metu paketų praradimas yra įprastas reiškinys, ypač belaidžiuose tinkluose.
Interneto pralaidumas gali sumažėti, ypač piko valandomis, dėl vartotojų srauto, dėl kurio gali susidaryti kamščiai. Tačiau internete nėra galimybės vieniems prašymams teikti pirmenybę prieš kitus. Pavyzdžiui, pirmenybę teikite mažoms ir delsai jautrioms užklausoms, o ne „sunkiems“ duomenų srautams, kurie apkrauna tinklą. Tačiau mūsų atveju, turėdami savo pagrindinį tinklą, galime tai padaryti dalyje užklausos kelio – tarp CDN ir debesies, ir mes galime jį visiškai sukonfigūruoti. Galite įsitikinti, kad pirmenybė teikiama mažiems ir delsą jautriems paketams, o dideli duomenų srautai vyksta šiek tiek vėliau. Kuo CDN arčiau kliento, tuo didesnis efektyvumas.
Programos lygio protokolai (OSI 7 lygis) taip pat turi įtakos delsai. Nauji protokolai, tokie kaip HTTP/2, optimizuoja lygiagrečių užklausų našumą. Tačiau turime „Netflix“ klientų su senesniais įrenginiais, kurie nepalaiko naujų protokolų. Ne visi klientai gali būti atnaujinti arba optimaliai sukonfigūruoti. Tuo pačiu metu tarp CDN tarpinio serverio ir debesies yra visiška kontrolė ir galimybė naudoti naujus, optimalius protokolus ir nustatymus. Neveiksminga dalis su senais protokolais veiks tik tarp kliento ir CDN serverio. Be to, galime pateikti multipleksines užklausas jau užmegztam ryšiui tarp CDN ir debesies, pagerindami ryšio naudojimą TCP lygiu:
Matuojame
Nepaisant to, kad teorija žada patobulinimus, mes iš karto neskubame paleisti sistemos gamyboje. Vietoj to, pirmiausia turime įrodyti, kad idėja veiks praktiškai. Norėdami tai padaryti, turite atsakyti į kelis klausimus:
- Pagreitinti: ar tarpinis serveris bus greitesnis?
- Patikimumas: Ar jis dažniau lūžtų?
- Sudėtingumas: kaip integruoti su programomis?
- Kaina: Kiek kainuoja įdiegti papildomą infrastruktūrą?
Išsamiai apsvarstykime savo požiūrį į pirmojo punkto įvertinimą. Likusieji sprendžiami panašiai.
Norėdami išanalizuoti užklausų greitį, norime gauti duomenis apie visus vartotojus, neskiriant daug laiko kūrimui ir nesulaužant gamybos. Tam yra keli būdai:
- RUM arba pasyvios užklausos matavimas. Matuojame dabartinių vartotojų užklausų vykdymo laiką ir užtikriname visą vartotojų aprėptį. Trūkumas yra tas, kad signalas nėra labai stabilus dėl daugelio veiksnių, pavyzdžiui, dėl skirtingų užklausų dydžių, apdorojimo laiko serveryje ir kliente. Be to, negalite išbandyti naujos konfigūracijos be poveikio gamyboje.
- Laboratoriniai tyrimai. Specialūs serveriai ir infrastruktūra, imituojantys klientus. Su jų pagalba atliekame reikiamus tyrimus. Taip gauname visišką matavimo rezultatų kontrolę ir aiškų signalą. Tačiau nėra visos įrenginių ir naudotojų vietų aprėpties (ypač teikiant pasaulinę paslaugą ir tūkstančius įrenginių modelių).
Kaip galite sujungti abiejų metodų privalumus?
Mūsų komanda rado sprendimą. Parašėme nedidelę kodo dalį – pavyzdį – kurį įdėjome į savo programą. Zondai leidžia atlikti visiškai kontroliuojamus tinklo testus iš mūsų įrenginių. Tai veikia taip:
- Netrukus po to, kai įkeliame programą ir baigiame pradinę veiklą, atliekame tyrimus.
- Klientas pateikia užklausą serveriui ir gauna testo „receptą“. Receptas yra URL, kuriems reikia pateikti HTTP (-ų) užklausą, sąrašas. Be to, pagal receptą sukonfigūruojami užklausos parametrai: delsos tarp užklausų, prašomų duomenų kiekis, HTTP(-ių) antraštės ir kt. Tuo pačiu metu galime lygiagrečiai išbandyti kelis skirtingus receptus – prašydami konfigūracijos atsitiktinai nustatome, kurį receptą išduoti.
- Tyrimo paleidimo laikas parenkamas taip, kad neprieštarautų aktyviam kliento tinklo išteklių naudojimui. Iš esmės pasirenkamas laikas, kai klientas neaktyvus.
- Gavęs receptą, klientas lygiagrečiai pateikia užklausas kiekvienam URL. Prašymas į kiekvieną iš adresų gali būti kartojamas – vadinamasis. "impulsai". Pirmuoju impulsu išmatuojame, kiek laiko užtruko užmegzti ryšį ir atsisiųsti duomenis. Antruoju impulsu išmatuojame laiką, kurio reikia duomenims įkelti per jau sukurtą ryšį. Prieš trečiąjį galime nustatyti delsą ir išmatuoti perjungimo greitį ir pan.
Bandymo metu išmatuojame visus parametrus, kuriuos įrenginys gali gauti:
- DNS užklausos laikas;
- TCP ryšio nustatymo laikas;
- TLS ryšio nustatymo laikas;
- pirmojo duomenų baito gavimo laikas;
- bendras pakrovimo laikas;
- būsenos rezultato kodas.
- Pasibaigus visiems impulsams, mėginys įkelia visus matavimus analizei.
Pagrindiniai dalykai yra minimali priklausomybė nuo kliento logikos, duomenų apdorojimas serveryje ir lygiagrečių užklausų matavimas. Taigi galime išskirti ir išbandyti įvairių veiksnių, turinčių įtakos užklausos našumui, įtaką, juos keisti pagal vieną receptą ir gauti rezultatus iš tikrų klientų.
Ši infrastruktūra pasirodė naudinga ne tik užklausų našumo analizei. Šiuo metu turime 14 aktyvių receptų, daugiau nei 6000 mėginių per sekundę, gaunamus duomenis iš visų žemės kampelių ir visą įrenginio aprėptį. Jei „Netflix“ pirktų panašią paslaugą iš trečiosios šalies, ji kainuotų milijonus dolerių per metus, o aprėptis būtų daug prastesnė.
Testavimo teorija praktikoje: prototipas
Naudodami tokią sistemą galėjome įvertinti CDN tarpinių serverių efektyvumą pagal užklausos delsą. Dabar jums reikia:
- sukurti tarpinio serverio prototipą;
- įdėkite prototipą į CDN;
- nustatyti, kaip nukreipti klientus į tarpinį serverį konkrečiame CDN serveryje;
- Palyginkite našumą su užklausomis AWS be tarpinio serverio.
Užduotis – kuo greičiau įvertinti siūlomo sprendimo efektyvumą. Pasirinkome „Go“, kad įdiegtume prototipą, nes yra geros tinklo bibliotekos. Kiekviename CDN serveryje įdiegėme prototipo tarpinį serverį kaip statinį dvejetainį failą, kad sumažintume priklausomybes ir supaprastintume integravimą. Pradiniame diegime mes naudojome kiek įmanoma standartinius komponentus ir nedidelius HTTP/2 jungčių telkimo ir užklausų tankinimo pakeitimus.
Norėdami subalansuoti AWS regionus, naudojome geografinę DNS duomenų bazę, tą pačią, kuri buvo naudojama klientams subalansuoti. Norėdami pasirinkti CDN serverį klientui, mes naudojame TCP Anycast serveriams Internet Exchange (IX). Pasirinkę šią parinktį, mes naudojame vieną IP adresą visiems CDN serveriams, o klientas bus nukreiptas į CDN serverį su mažiausiu IP šuoliu skaičiumi. Interneto tiekėjų (IPT) įdiegtuose CDN serveriuose mes negalime valdyti maršrutizatoriaus, kad galėtume konfigūruoti TCP Anycast, todėl naudojame , kuri nukreipia klientus į interneto tiekėjus vaizdo transliacijai.
Taigi, turime trijų tipų užklausų kelius: į debesį per atvirą internetą, per CDN serverį IX arba per CDN serverį, esantį pas interneto tiekėją. Mūsų tikslas yra suprasti, kuris būdas yra geresnis ir kokia yra tarpinio serverio nauda, palyginti su tuo, kaip užklausos siunčiamos į gamybą. Norėdami tai padaryti, naudojame atrankos sistemą taip:
Kiekvienas kelias tampa atskiru taikiniu, ir mes žiūrime į gautą laiką. Analizei tarpinio serverio rezultatus sujungiame į vieną grupę (pasirenkame geriausią laiką tarp IX ir IPT tarpinių serverių) ir palyginame juos su užklausų į debesį be tarpinio serverio laiku:
Kaip matote, rezultatai buvo prieštaringi – daugeliu atvejų tarpinis serveris suteikia gerą pagreitį, tačiau yra ir pakankamai klientų, kuriems situacija gerokai pablogės.
Dėl to atlikome keletą svarbių dalykų:
- Įvertinome numatomą klientų užklausų į debesį našumą per CDN tarpinį serverį.
- Gavome duomenis iš tikrų klientų, iš visų tipų įrenginių.
- Supratome, kad teorija nepasitvirtino 100% ir pradinis pasiūlymas su CDN tarpiniu serveriu mums netiks.
- Mes nerizikavome – nekeitėme gamybos konfigūracijų klientams.
- Niekas nebuvo sulaužyta.
Prototipas 2.0
Taigi, grįžkite prie piešimo lentos ir pakartokite procesą iš naujo.
Idėja tokia, kad vietoj 100% tarpinio serverio mes nustatysime greičiausią kelią kiekvienam klientui ir ten siųsime užklausas – tai yra darysime tai, kas vadinama kliento valdymu.
Kaip tai įgyvendinti? Mes negalime naudoti logikos serverio pusėje, nes... Tikslas yra prisijungti prie šio serverio. Turi būti koks nors būdas tai padaryti klientui. Ir idealiu atveju darykite tai su minimalia sudėtinga logika, kad neišspręstumėte integracijos su daugybe klientų platformų problemos.
Atsakymas yra naudoti DNS. Mūsų atveju mes turime savo DNS infrastruktūrą ir galime nustatyti domeno zoną, kuriai mūsų serveriai bus autoritariniai. Tai veikia taip:
- Klientas pateikia užklausą DNS serveriui naudodamas pagrindinį kompiuterį, pvz., api.netflix.xom.
- Užklausa ateina į mūsų DNS serverį
- DNS serveris žino, kuris kelias yra greičiausias šiam klientui ir išduoda atitinkamą IP adresą.
Sprendimas turi papildomą komplikaciją: autoritariniai DNS tiekėjai nemato kliento IP adreso ir gali nuskaityti tik kliento naudojamo rekursinio sprendiklio IP adresą.
Dėl to mūsų autoritarinis sprendėjas turi priimti sprendimą ne už atskirą klientą, o už klientų grupę, rekursyviniu sprendimu.
Norėdami išspręsti, naudojame tuos pačius pavyzdžius, apibendriname klientų matavimo rezultatus kiekvienam rekursyviam skyrikliui ir nusprendžiame, kur siųsti šią jų grupę – tarpinį serverį per IX naudojant TCP Anycast, per IPT tarpinį serverį arba tiesiai į debesį.
Gauname tokią sistemą:
Gautas DNS valdymo modelis leidžia nukreipti klientus remiantis istoriniais klientų ir debesies ryšio greičio stebėjimais.
Vėlgi, kyla klausimas, ar šis metodas veiks efektyviai? Norėdami atsakyti, vėl naudojame savo zondo sistemą. Todėl konfigūruojame pranešėjo konfigūraciją, kai vienas iš taikinių seka DNS valdymo kryptį, kitas eina tiesiai į debesį (dabartinė gamyba).
Dėl to mes palyginame rezultatus ir gauname efektyvumo įvertinimą:
Dėl to sužinojome keletą svarbių dalykų:
- Įvertinome numatomą klientų užklausų į debesį našumą naudodami DNS valdymą.
- Gavome duomenis iš tikrų klientų, iš visų tipų įrenginių.
- Pasiūlytos idėjos efektyvumas įrodytas.
- Mes nerizikavome – nekeitėme gamybos konfigūracijų klientams.
- Niekas nebuvo sulaužyta.
Dabar apie sudėtingąją dalį – pradedame ją gaminti
Lengvoji dalis baigėsi – yra veikiantis prototipas. Dabar sudėtingiausia dalis yra pradėti sprendimą, skirtą visam „Netflix“ srautui, 150 milijonų vartotojų, tūkstančiams įrenginių, šimtams mikropaslaugų ir nuolat kintančio produkto bei infrastruktūros. „Netflix“ serveriai gauna milijonus užklausų per sekundę, o paslaugą lengva nutraukti neatsargiais veiksmais. Tuo pačiu norime dinamiškai nukreipti srautą per tūkstančius CDN serverių internete, kuriuose nuolat ir pačiu netinkamiausiu momentu kažkas keičiasi ir sugenda.
Ir visa tai komanda turi 3 inžinierius, atsakingus už sistemos kūrimą, diegimą ir visišką palaikymą.
Todėl ir toliau kalbėsime apie ramų ir sveiką miegą.
Kaip tęsti tobulėjimą ir neskirti viso savo laiko paramai? Mūsų požiūris grindžiamas 3 principais:
- Sumažiname galimą gedimų mastą (sprogimo spindulį).
- Ruošiamės staigmenoms – tikimės, kad kažkas suges, nepaisant išbandymų ir asmeninės patirties.
- Grakštus degradavimas – jei kažkas neveikia, tai turėtų būti automatiškai ištaisyta, net jei ne pačiu efektyviausiu būdu.
Paaiškėjo, kad mūsų atveju su tokiu požiūriu į problemą galime rasti paprastą ir efektyvų sprendimą bei gerokai supaprastinti sistemos palaikymą. Supratome, kad galime pridėti nedidelę kodo dalį prie kliento ir stebėti, ar nėra tinklo užklausų klaidų, kurias sukelia ryšio problemos. Tinklo klaidų atveju grįžtame tiesiai į debesį. Šis sprendimas nereikalauja didelių pastangų klientų komandoms, tačiau labai sumažina netikėtų gedimų ir netikėtumų mums riziką.
Žinoma, nepaisant atsarginių priemonių, kūrimo metu laikomės aiškios disciplinos:
- Bandymo pavyzdys.
- A/B testavimas arba Kanarai.
- Laipsniškas išleidimas.
Naudojant pavyzdžius, metodas buvo aprašytas – pakeitimai pirmiausia išbandomi pagal pritaikytą receptą.
Norėdami atlikti „canary“ testavimą, turime gauti palyginamas serverių poras, kuriose galėtume palyginti, kaip sistema veikia prieš ir po pakeitimų. Norėdami tai padaryti, iš daugelio mūsų CDN svetainių pasirenkame serverių poras, kurios gauna panašų srautą:
Tada įdiegiame pastatymą su pakeitimais Canary serveryje. Norėdami įvertinti rezultatus, paleidžiame sistemą, kuri lygina maždaug 100–150 metrikų su valdymo serverių pavyzdžiu:
Jei Kanarų bandymai pasiseka, tai išleidžiame palaipsniui, bangomis. Mes neatnaujiname serverių kiekvienoje svetainėje vienu metu – visos svetainės praradimas dėl problemų vartotojams daro didesnę įtaką paslaugai, nei praradus tą patį serverių skaičių skirtingose vietose.
Apskritai šio metodo efektyvumas ir saugumas priklauso nuo surinktų metrikų kiekio ir kokybės. Užklausų paspartinimo sistemai renkame visų galimų komponentų metriką:
- iš klientų – seansų ir užklausų skaičius, atsarginiai rodikliai;
- proxy – užklausų skaičiaus ir laiko statistika;
- DNS – užklausų skaičius ir rezultatai;
- debesies kraštas – užklausų apdorojimo debesyje skaičius ir laikas.
Visa tai surenkama į vieną konvejerį ir, atsižvelgdami į poreikius, nusprendžiame, kokias metrikas siųsti į realaus laiko analizę, o kurias – į Elasticsearch ar Big Data, kad būtų atlikta detalesnė diagnostika.
Stebime
Mūsų atveju atliekame pakeitimus kritiniame užklausų kelyje tarp kliento ir serverio. Tuo pačiu metu skirtingų komponentų kliente, serveryje ir kelyje per internetą skaičius yra didžiulis. Pokyčiai kliente ir serveryje vyksta nuolat – dešimčių komandų darbo ir natūralių ekosistemos pokyčių metu. Esame per vidurį – diagnozuojant problemas yra didelė tikimybė, kad dalyvausime. Todėl turime aiškiai suprasti, kaip apibrėžti, rinkti ir analizuoti metrikas, kad greitai atskirtume problemas.
Idealiu atveju visapusiška prieiga prie visų tipų metrikos ir filtrų realiuoju laiku. Tačiau metrikų yra daug, todėl kyla išlaidų klausimas. Mūsų atveju metriką ir kūrimo įrankius atskiriame taip:
Norėdami aptikti ir nustatyti problemas, naudojame savo atvirojo kodo realaus laiko sistemą и - vizualizacijai. Jis saugo apibendrintus duomenis atmintyje, yra patikimas ir integruojamas su įspėjimo sistema. Lokalizacijos ir diagnostikos tikslais turime prieigą prie žurnalų iš Elasticsearch ir Kibana. Statistinei analizei ir modeliavimui naudojame didelius duomenis ir vizualizaciją „Tableau“.
Atrodo, kad su šiuo metodu dirbti labai sunku. Tačiau hierarchiškai tvarkydami metriką ir įrankius galime greitai išanalizuoti problemą, nustatyti problemos tipą ir tada įsigilinti į išsamią metriką. Paprastai gedimo šaltiniui nustatyti skiriame apie 1–2 minutes. Po to diagnostikos srityje dirbame su konkrečia komanda – nuo dešimčių minučių iki kelių valandų.
Net jei diagnozė nustatoma greitai, nenorime, kad taip nutiktų dažnai. Idealiu atveju kritinį įspėjimą gausime tik tada, kai tai turės reikšmingą poveikį paslaugai. Mūsų užklausų paspartinimo sistemai turime tik 2 įspėjimus, kurie praneš:
- Client Fallback procentas – klientų elgesio įvertinimas;
- procentas Probe errors – tinklo komponentų stabilumo duomenys.
Šie kritiniai įspėjimai stebi, ar sistema veikia daugumai vartotojų. Mes žiūrime, kiek klientų naudojosi atsargine tvarka, jei negalėjo gauti užklausos paspartinimo. Vidutiniškai gauname mažiau nei 1 kritinį įspėjimą per savaitę, nors sistemoje vyksta daugybė pakeitimų. Kodėl mums to pakanka?
- Jei tarpinis serveris neveikia, yra kliento atsarginė priemonė.
- Yra automatinė vairo sistema, kuri reaguoja į problemas.
Daugiau informacijos apie pastarąjį. Mūsų bandomoji sistema ir sistema, automatiškai nustatanti optimalų užklausų kelią iš kliento į debesį, leidžia automatiškai susidoroti su kai kuriomis problemomis.
Grįžkime prie pavyzdinės konfigūracijos ir 3 kelių kategorijų. Be pakrovimo laiko, galime pažvelgti į patį pristatymo faktą. Jei nepavyko įkelti duomenų, tada žvelgdami į rezultatus skirtingais keliais galime nustatyti, kur ir kas sugedo, ir ar galime tai automatiškai ištaisyti pakeisdami užklausos kelią.
Pavyzdžiai:
Šis procesas gali būti automatizuotas. Įtraukite jį į vairo sistemą. Ir išmokyti reaguoti į našumo ir patikimumo problemas. Jei kažkas pradeda lūžti, reaguokite, jei yra geresnis pasirinkimas. Tuo pačiu metu neatidėliotina reakcija nėra kritinė dėl klientų atsargumo.
Taigi sistemos palaikymo principus galima suformuluoti taip:
- sumažinti gedimų mastą;
- metrikų rinkimas;
- Jei galime, gedimus taisome automatiškai;
- jei negali, mes jums pranešame;
- Mes dirbame su prietaisų skydeliais ir suskirstymo įrankių rinkiniu, kad galėtume greitai reaguoti.
Išmoktos pamokos
Prototipui parašyti nereikia daug laiko. Mūsų atveju jis buvo paruoštas po 4 mėnesių. Su juo gavome naujų metrikų, o praėjus 10 mėnesių nuo kūrimo pradžios sulaukėme pirmojo gamybos srauto. Tada prasidėjo varginantis ir labai sunkus darbas: palaipsniui gaminkite ir padidinkite sistemą, perkelkite pagrindinį srautą ir mokykitės iš klaidų. Tačiau šis efektyvus procesas nebus linijinis – nepaisant visų pastangų, visko negalima numatyti. Daug efektyviau yra greitai kartoti ir reaguoti į naujus duomenis.
Remdamiesi savo patirtimi, galime rekomenduoti:
- Nepasitikėk savo intuicija.
Mūsų intuicija mus nuolat žlugo, nepaisant didžiulės komandos narių patirties. Pavyzdžiui, neteisingai numatėme numatomą pagreitį naudojant CDN tarpinį serverį arba TCP Anycast elgesį.
- Gaukite duomenis iš gamybos.
Svarbu kuo greičiau gauti prieigą prie bent nedidelio kiekio gamybos duomenų. Laboratorinėmis sąlygomis beveik neįmanoma gauti unikalių atvejų, konfigūracijų ir nustatymų. Greita prieiga prie rezultatų leis greitai sužinoti apie galimas problemas ir į jas atsižvelgti sistemos architektūroje.
- Nesivadovaukite kitų patarimais ir rezultatais – rinkite savo duomenis.
Laikykitės duomenų rinkimo ir analizės principų, tačiau aklai nepriimkite kitų žmonių rezultatų ir teiginių. Tik jūs galite tiksliai žinoti, kas tinka jūsų vartotojams. Jūsų sistemos ir klientai gali labai skirtis nuo kitų įmonių. Laimei, analizės įrankiai dabar yra prieinami ir jais lengva naudotis. Gauti rezultatai gali būti ne tokie, kokių teigia „Netflix“, „Facebook“, „Akamai“ ir kitos įmonės. Mūsų atveju TLS, HTTP2 ar DNS užklausų statistikos našumas skiriasi nuo Facebook, Uber, Akamai rezultatų – nes turime skirtingus įrenginius, klientus ir duomenų srautus.
- Be reikalo nesivaikykite mados tendencijų ir įvertinkite efektyvumą.
Pradėkite paprastai. Geriau per trumpą laiką sukurti paprastą veikiančią sistemą, nei praleisti daug laiko kuriant nereikalingus komponentus. Išspręskite svarbias užduotis ir problemas remdamiesi savo matavimais ir rezultatais.
- Pasiruoškite naujoms programoms.
Kaip sunku numatyti visas problemas, taip sunku iš anksto numatyti naudą ir pritaikymą. Paimkite užuomina iš startuolių – jų gebėjimo prisitaikyti prie klientų sąlygų. Jūsų atveju galite atrasti naujų problemų ir jų sprendimų. Savo projekte nustatėme tikslą sumažinti užklausų delsą. Tačiau analizės ir diskusijų metu supratome, kad galime naudoti ir tarpinius serverius:
- subalansuoti srautą AWS regionuose ir sumažinti išlaidas;
- modeliuoti CDN stabilumą;
- sukonfigūruoti DNS;
- Norėdami sukonfigūruoti TLS/TCP.
išvada
Ataskaitoje aprašiau, kaip „Netflix“ sprendžia interneto užklausų tarp klientų ir debesies spartinimo problemą. Kaip mes renkame duomenis naudodami klientų atrankos sistemą ir naudojame surinktus istorinius duomenis klientų gamybos užklausoms nukreipti greičiausiu keliu internete. Kaip mes naudojame tinklo protokolų principus, mūsų CDN infrastruktūrą, pagrindinį tinklą ir DNS serverius, kad pasiektume šią užduotį.
Tačiau mūsų sprendimas yra tik pavyzdys, kaip mes „Netflix“ įdiegėme tokią sistemą. Kas mums pasiteisino. Mano pranešimo dalis, skirta jums, yra plėtros ir paramos principai, kuriais vadovaujamės ir pasiekiame gerų rezultatų.
Mūsų problemos sprendimas gali jums netikti. Tačiau teorija ir projektavimo principai išlieka, net jei neturite savo CDN infrastruktūros arba ji labai skiriasi nuo mūsų.
Taip pat išlieka svarbi verslo užklausų spartos svarba. Ir net norint gauti paprastą paslaugą reikia pasirinkti: tarp debesies tiekėjų, serverio vietos, CDN ir DNS teikėjų. Jūsų pasirinkimas turės įtakos interneto užklausų efektyvumui jūsų klientams. Ir jums svarbu išmatuoti ir suprasti šią įtaką.
Pradėkite nuo paprastų sprendimų, rūpinkitės tuo, kaip pakeisite produktą. Mokykitės ir patobulinkite sistemą remdamiesi duomenimis iš klientų, infrastruktūros ir verslo. Pagalvokite apie netikėtų gedimų galimybę projektavimo procese. Tada galėsite paspartinti kūrimo procesą, pagerinti sprendimų efektyvumą, išvengti nereikalingos palaikymo naštos ir ramiai miegoti.
Šiemet internetiniu formatu. Galite užduoti klausimus vienam iš DevOps tėvų, pačiam Johnui Willisui!
Šaltinis: www.habr.com