Netflix je lider na tržištu internetske televizije - tvrtka koja je stvorila i aktivno razvija ovaj segment. Netflix je poznat ne samo po opsežnom katalogu filmova i TV serija dostupnih iz gotovo svakog kutka planeta i bilo kojeg uređaja sa zaslonom, već i po svojoj pouzdanoj infrastrukturi i jedinstvenoj inženjerskoj kulturi.
Jasan primjer Netflixovog pristupa razvoju i podršci složenih sustava predstavljen je na DevOops 2019 - direktorica razvoja u Netflixu. Diplomirao je na Fakultetu računalne matematike i matematike Državnog sveučilišta u Nižnjem Novgorodu. Lobačevski, Sergej jedan od prvih inženjera u Open Connect - CDN timu na Netflixu. Izgradio je sustave za praćenje i analizu video podataka, pokrenuo popularni servis za procjenu brzine internetske veze FAST.com, a posljednjih nekoliko godina radi na optimizaciji internetskih zahtjeva kako bi aplikacija Netflix radila što brže za korisnike.
Izvješće je dobilo najbolje ocjene sudionika konferencije, a za vas smo pripremili tekstualnu verziju.
U svom izvješću Sergej je govorio detaljno
- o tome što utječe na kašnjenje internetskih zahtjeva između klijenta i poslužitelja;
- kako smanjiti ovo kašnjenje;
- kako dizajnirati, održavati i nadzirati sustave otporne na greške;
- kako postići rezultate u kratkom vremenu, a uz minimalan rizik za poslovanje;
- kako analizirati rezultate i učiti na greškama.
Odgovore na ova pitanja ne trebaju samo oni koji rade u velikim korporacijama.
Predstavljena načela i tehnike trebaju poznavati i prakticirati svi koji razvijaju i podržavaju internetske proizvode.
Slijedi pripovijedanje iz perspektive govornika.
Važnost brzine interneta
Brzina internetskih zahtjeva izravno je povezana s poslovanjem. Razmotrite industriju kupnje: Amazon u 2009 da kašnjenje od 100 ms rezultira gubitkom od 1% prodaje.
Sve je više mobilnih uređaja, a zatim i mobilnih stranica i aplikacija. Ako se vašoj stranici učitava duže od 3 sekunde, gubite otprilike polovicu korisnika. S Google uzima u obzir brzinu učitavanja vaše stranice u rezultatima pretraživanja: što je stranica brža, to je njezina pozicija na Googleu viša.
Brzina veze također je važna u financijskim institucijama gdje je kašnjenje kritično. Godine 2015. Hibernia Networks kabel od 400 milijuna dolara između New Yorka i Londona za smanjenje kašnjenja između gradova za 6 ms. Zamislite 66 milijuna dolara za 1 ms smanjenja latencije!
Prema , brzine veze iznad 5 Mbit/s više ne utječu izravno na brzinu učitavanja tipične web stranice. Međutim, postoji linearni odnos između kašnjenja veze i brzine učitavanja stranice:
Međutim, Netflix nije tipičan proizvod. Utjecaj latencije i brzine na korisnika aktivno je područje analize i razvoja. Postoji učitavanje aplikacija i odabir sadržaja koji ovise o kašnjenju, ali učitavanje statičkih elemenata i strujanje također ovise o brzini veze. Analiza i optimizacija ključnih čimbenika koji utječu na korisničko iskustvo aktivno je područje razvoja za nekoliko timova u Netflixu. Jedan od ciljeva je smanjiti latenciju zahtjeva između Netflix uređaja i cloud infrastrukture.
U izvješću ćemo se posebno usredotočiti na smanjenje latencije na primjeru Netflixove infrastrukture. Razmotrimo s praktičnog gledišta kako pristupiti procesima projektiranja, razvoja i rada složenih distribuiranih sustava i potrošiti vrijeme na inovacije i rezultate, umjesto na dijagnosticiranje operativnih problema i kvarova.
Unutar Netflixa
Tisuće različitih uređaja podržavaju Netflixove aplikacije. Razvijaju ih četiri različita tima, koji izrađuju zasebne verzije klijenta za Android, iOS, TV i web preglednike. I puno truda ulažemo u poboljšanje i personalizaciju korisničkog iskustva. Da bismo to učinili, paralelno izvodimo stotine A/B testova.
Personalizaciju podržavaju stotine mikroservisa u AWS oblaku, pružajući personalizirane korisničke podatke, slanje upita, telemetriju, Big Data i kodiranje. Vizualizacija prometa izgleda ovako:
S lijeve strane je ulazna točka, a zatim se promet raspoređuje na nekoliko stotina mikroservisa koje podržavaju različiti backend timovi.
Još jedna važna komponenta naše infrastrukture je Open Connect CDN, koji krajnjem korisniku isporučuje statični sadržaj - video zapise, slike, kod klijenta itd. CDN se nalazi na prilagođenim poslužiteljima (OCA - Open Connect Appliance). Unutra se nalaze nizovi SSD i HDD pogona koji pokreću optimizirani FreeBSD, s NGINX-om i skupom usluga. Dizajniramo i optimiziramo hardverske i softverske komponente kako bi takav CDN poslužitelj mogao poslati što više podataka korisnicima.
“Zid” ovih poslužitelja na točki razmjene internetskog prometa (Internet eXchange - IX) izgleda ovako:
Internet Exchange pruža mogućnost davateljima internetskih usluga i davateljima sadržaja da se međusobno "povežu" radi izravnije razmjene podataka na internetu. Postoji oko 70-80 Internet Exchange točaka diljem svijeta na kojima su instalirani naši poslužitelji, a mi ih samostalno instaliramo i održavamo:
Osim toga, pružateljima internetskih usluga izravno pružamo poslužitelje koje oni instaliraju u svoju mrežu, poboljšavajući lokalizaciju Netflix prometa i kvalitetu streaminga za korisnike:
Skup AWS usluga odgovoran je za slanje video zahtjeva od klijenata do CDN poslužitelja, kao i za konfiguraciju samih poslužitelja - ažuriranje sadržaja, programskog koda, postavki itd. Za potonje smo također izgradili okosnicu mreže koja povezuje poslužitelje u Internet Exchange točkama s AWS-om. Okosnica mreže je globalna mreža optičkih kabela i usmjerivača koje možemo dizajnirati i konfigurirati prema našim potrebama.
Na , naša CDN infrastruktura isporučuje približno ⅛ svjetskog internetskog prometa tijekom vršnih sati i ⅓ prometa u Sjevernoj Americi, gdje Netflix postoji najduže. Impresivne brojke, ali za mene je jedno od najnevjerojatnijih postignuća to što cijeli CDN sustav razvija i održava tim od manje od 150 ljudi.
U početku je CDN infrastruktura dizajnirana za isporuku video podataka. Međutim, s vremenom smo shvatili da ga možemo koristiti i za optimizaciju dinamičkih zahtjeva klijenata u AWS oblaku.
O internetskom ubrzanju
Danas Netflix ima 3 AWS regije, a latencija zahtjeva prema oblaku ovisit će o tome koliko je korisnik udaljen od najbliže regije. U isto vrijeme, imamo mnogo CDN poslužitelja koji se koriste za isporuku statičnog sadržaja. Postoji li neki način za korištenje ovog okvira za ubrzavanje dinamičkih upita? Međutim, nažalost, nemoguće je predmemorirati te zahtjeve - API-ji su personalizirani i svaki rezultat je jedinstven.
Napravimo proxy na CDN poslužitelju i počnimo slati promet preko njega. Hoće li biti brže?
materijal
Prisjetimo se kako rade mrežni protokoli. Danas većina prometa na Internetu koristi HTTPs, koji ovisi o protokolima nižeg sloja TCP i TLS. Kako bi se klijent spojio na poslužitelj, on radi rukovanje, a za uspostavljanje sigurne veze klijent treba tri puta razmijeniti poruke s poslužiteljem i barem još jednom za prijenos podataka. S latencijom po povratnom putu (RTT) od 100 ms, trebalo bi nam 400 ms da primimo prvi bit podataka:
Ako certifikate postavimo na CDN poslužitelj, tada se vrijeme rukovanja između klijenta i poslužitelja može značajno smanjiti ako je CDN bliži. Pretpostavimo da je latencija CDN poslužitelja 30 ms. Tada će trebati 220 ms da primi prvi bit:
No prednostima tu nije kraj. Nakon što je veza uspostavljena, TCP povećava prozor zagušenja (količinu informacija koju može paralelno prenijeti preko te veze). Ako se podatkovni paket izgubi, tada klasične implementacije TCP protokola (poput TCP New Reno) smanjuju otvoreni "prozor" za pola. Rast prozora zagušenja i brzina njegovog oporavka od gubitka opet ovisi o kašnjenju (RTT) prema poslužitelju. Ako ova veza ide samo do CDN poslužitelja, ovaj će oporavak biti brži. U isto vrijeme, gubitak paketa je standardna pojava, posebno za bežične mreže.
Internetska propusnost može biti smanjena, osobito tijekom vršnih sati, zbog prometa od korisnika, što može dovesti do prometnih gužvi. Međutim, na Internetu ne postoji način da se nekim zahtjevima da prednost nad drugima. Na primjer, dajte prednost malim zahtjevima koji su osjetljivi na kašnjenje u odnosu na "teške" tokove podataka koji opterećuju mrežu. Međutim, u našem slučaju posjedovanje vlastite okosnice mreže omogućuje nam da to radimo na dijelu putanje zahtjeva – između CDN-a i oblaka, a možemo ga u potpunosti konfigurirati. Možete se pobrinuti da mali paketi i paketi osjetljivi na kašnjenje imaju prioritet, a veliki tokovi podataka idu malo kasnije. Što je CDN bliže klijentu, veća je učinkovitost.
Protokoli aplikacijske razine (OSI razina 7) također utječu na latenciju. Novi protokoli kao što je HTTP/2 optimiziraju performanse paralelnih zahtjeva. Međutim, imamo Netflix klijente sa starijim uređajima koji ne podržavaju nove protokole. Ne mogu se svi klijenti ažurirati ili optimalno konfigurirati. U isto vrijeme, između CDN proxyja i oblaka postoji potpuna kontrola i mogućnost korištenja novih, optimalnih protokola i postavki. Neučinkovit dio sa starim protokolima radit će samo između klijenta i CDN poslužitelja. Štoviše, možemo postavljati multipleksne zahtjeve na već uspostavljenu vezu između CDN-a i oblaka, poboljšavajući iskorištenost veze na TCP razini:
Mjerimo
Unatoč činjenici da teorija obećava poboljšanja, ne žurimo odmah s puštanjem sustava u proizvodnju. Umjesto toga, prvo moramo dokazati da će ideja funkcionirati u praksi. Da biste to učinili, morate odgovoriti na nekoliko pitanja:
- Ubrzati: hoće li proxy biti brži?
- Pouzdanost: Hoće li se češće lomiti?
- složenost: kako se integrirati s aplikacijama?
- trošak: Koliko košta postavljanje dodatne infrastrukture?
Razmotrimo detaljno naš pristup procjeni prve točke. Ostatak se rješava na sličan način.
Kako bismo analizirali brzinu zahtjeva, želimo dobiti podatke za sve korisnike, bez trošenja puno vremena na razvoj i bez prekida proizvodnje. Za to postoji nekoliko pristupa:
- RUM ili mjerenje pasivnog zahtjeva. Mjerimo vrijeme izvršenja trenutnih zahtjeva korisnika i osiguravamo punu pokrivenost korisnika. Nedostatak je što signal nije baš stabilan zbog mnogih čimbenika, na primjer, zbog različitih veličina zahtjeva, vremena obrade na poslužitelju i klijentu. Osim toga, ne možete testirati novu konfiguraciju bez učinka u proizvodnji.
- Laboratorijska ispitivanja. Posebni poslužitelji i infrastruktura koji simuliraju klijente. Uz njihovu pomoć provodimo potrebna ispitivanja. Na taj način dobivamo potpunu kontrolu nad rezultatima mjerenja i jasan signal. Ali ne postoji potpuna pokrivenost uređaja i korisničkih lokacija (posebno s uslugom širom svijeta i podrškom za tisuće modela uređaja).
Kako možete kombinirati prednosti obje metode?
Naš tim je pronašao rješenje. Napisali smo mali dio koda - uzorak - koji smo ugradili u našu aplikaciju. Sonde nam omogućuju potpuno kontrolirane mrežne testove s naših uređaja. Djeluje ovako:
- Ubrzo nakon učitavanja aplikacije i dovršetka početne aktivnosti, pokrećemo naše sonde.
- Klijent postavlja zahtjev poslužitelju i dobiva "recept" za test. Recept je popis URL-ova na koje treba uputiti HTTP(s) zahtjev. Osim toga, recept konfigurira parametre zahtjeva: kašnjenja između zahtjeva, količinu traženih podataka, HTTP(s) zaglavlja, itd. Istodobno, možemo testirati više različitih recepata paralelno - prilikom zahtjeva za konfiguracijom nasumično određujemo koji ćemo recept izdati.
- Vrijeme pokretanja sonde odabrano je tako da nije u sukobu s aktivnim korištenjem mrežnih resursa na klijentu. Uglavnom, odabrano je vrijeme kada klijent nije aktivan.
- Nakon primitka recepta, klijent paralelno postavlja zahtjeve prema svakom od URL-ova. Zahtjev na svaku od adresa može se ponavljati – tzv. "mahunarke". Na prvom pulsu mjerimo koliko je vremena bilo potrebno za uspostavljanje veze i preuzimanje podataka. Na drugom impulsu mjerimo vrijeme potrebno za učitavanje podataka preko već uspostavljene veze. Prije trećeg možemo postaviti odgodu i izmjeriti brzinu uspostavljanja rekonekcije itd.
Tijekom testa mjerimo sve parametre koje uređaj može postići:
- vrijeme DNS zahtjeva;
- vrijeme postavljanja TCP veze;
- vrijeme postavljanja TLS veze;
- vrijeme prijema prvog bajta podataka;
- ukupno vrijeme učitavanja;
- šifra rezultata statusa.
- Nakon završetka svih impulsa, uzorak učitava sva mjerenja za analizu.
Ključne točke su minimalna ovisnost o logici na klijentu, obrada podataka na poslužitelju i mjerenje paralelnih zahtjeva. Stoga smo u mogućnosti izolirati i testirati utjecaj različitih čimbenika koji utječu na izvedbu upita, mijenjati ih unutar jednog recepta i dobiti rezultate od stvarnih klijenata.
Ova se infrastruktura pokazala korisnom za više od same analize izvedbe upita. Trenutno imamo 14 aktivnih recepata, više od 6000 uzoraka u sekundi, primamo podatke sa svih strana svijeta i punu pokrivenost uređaja. Kad bi Netflix kupio sličnu uslugu od treće strane, to bi koštalo milijune dolara godišnje, s puno lošijom pokrivenošću.
Teorija ispitivanja u praksi: prototip
S takvim sustavom uspjeli smo procijeniti učinkovitost CDN proxyja na latenciju zahtjeva. Sada trebate:
- stvoriti proxy prototip;
- postaviti prototip na CDN;
- odrediti kako usmjeriti klijente na proxy na određenom CDN poslužitelju;
- Usporedite izvedbu sa zahtjevima u AWS-u bez proxyja.
Zadatak je procijeniti učinkovitost predloženog rješenja što je brže moguće. Odabrali smo Go za implementaciju prototipa zbog dostupnosti dobrih mrežnih knjižnica. Na svakom CDN poslužitelju instalirali smo prototip proxyja kao statički binarni kako bismo smanjili ovisnosti i pojednostavili integraciju. U početnoj implementaciji koristili smo standardne komponente koliko god je to bilo moguće i manje modifikacije za HTTP/2 skupljanje veza i multipleksiranje zahtjeva.
Kako bismo balansirali između AWS regija, koristili smo geografsku DNS bazu podataka, istu onu koja se koristi za balansiranje klijenata. Za odabir CDN poslužitelja za klijenta koristimo TCP Anycast za poslužitelje u Internet Exchange (IX). U ovoj opciji koristimo jednu IP adresu za sve CDN poslužitelje, a klijent će biti usmjeren na CDN poslužitelj s najmanjim brojem IP skokova. U CDN poslužiteljima koje instaliraju pružatelji internetskih usluga (ISP-ovi), nemamo kontrolu nad usmjerivačem za konfiguriranje TCP Anycasta, pa koristimo , koji korisnike usmjerava na internetske pružatelje usluga za video streaming.
Dakle, imamo tri vrste puta zahtjeva: do oblaka putem otvorenog interneta, putem CDN poslužitelja u IX-u ili putem CDN poslužitelja koji se nalazi kod internetskog provajdera. Naš je cilj razumjeti koji je način bolji i koja je korist od proxyja u usporedbi s načinom na koji se zahtjevi šalju u proizvodnju. Da bismo to učinili, koristimo sljedeći sustav uzorkovanja:
Svaki od puteva postaje posebna meta, a mi gledamo na vrijeme koje smo dobili. Za analizu kombiniramo rezultate proxyja u jednu grupu (odaberimo najbolje vrijeme između IX i ISP proxyja) i uspoređujemo ih s vremenom zahtjeva prema oblaku bez proxyja:
Kao što vidite, rezultati su bili mješoviti - u većini slučajeva proxy daje dobro ubrzanje, ali postoji i dovoljan broj klijenata za koje će se situacija značajno pogoršati.
Kao rezultat toga, učinili smo nekoliko važnih stvari:
- Procijenili smo očekivanu izvedbu zahtjeva klijenata prema oblaku putem CDN proxyja.
- Dobili smo podatke od stvarnih klijenata, sa svih vrsta uređaja.
- Shvatili smo da teorija nije 100% potvrđena i početna ponuda s CDN proxyjem ne bi funkcionirala za nas.
- Nismo riskirali - nismo mijenjali proizvodne konfiguracije za klijente.
- Ništa nije bilo slomljeno.
Prototip 2.0
Dakle, vratite se na ploču za crtanje i ponovite postupak iznova.
Ideja je da umjesto korištenja 100% proxyja odredimo najbrži put za svakog klijenta i tamo ćemo slati zahtjeve – odnosno raditi ono što se zove upravljanje klijentima.
Kako to implementirati? Ne možemo koristiti logiku na strani poslužitelja, jer... Cilj je spojiti se na ovaj poslužitelj. Mora postojati neki način da se to učini na klijentu. I idealno, učinite to s minimalnom količinom složene logike, kako ne biste riješili problem integracije s velikim brojem klijentskih platformi.
Odgovor je korištenje DNS-a. U našem slučaju imamo vlastitu DNS infrastrukturu i možemo postaviti domensku zonu za koju će naši poslužitelji biti autoritarni. Djeluje ovako:
- Klijent šalje zahtjev DNS poslužitelju koristeći host, na primjer api.netflix.xom.
- Zahtjev stiže na naš DNS poslužitelj
- DNS poslužitelj zna koja je staza najbrža za ovog klijenta i izdaje odgovarajuću IP adresu.
Rješenje ima dodatnu složenost: autoritarni DNS pružatelji usluga ne vide klijentovu IP adresu i mogu čitati samo IP adresu rekurzivnog razlučivača koji klijent koristi.
Kao rezultat toga, naš autoritarni rezolver mora donijeti odluku ne za pojedinačnog klijenta, već za grupu klijenata na temelju rekurzivnog rezolvera.
Za rješavanje koristimo iste uzorke, agregiramo rezultate mjerenja od klijenata za svaki od rekurzivnih rezolvera i odlučujemo gdje poslati ovu grupu njih - proxy putem IX-a koristeći TCP Anycast, preko ISP proxyja ili izravno u oblak.
Dobivamo sljedeći sustav:
Rezultirajući DNS model upravljanja omogućuje vam usmjeravanje klijenata na temelju povijesnih promatranja brzine veza od klijenata do oblaka.
Opet, pitanje je koliko će ovaj pristup učinkovito djelovati? Za odgovor ponovno koristimo naš sustav sondi. Stoga konfiguriramo konfiguraciju prezentera, gdje jedan od ciljeva slijedi smjer DNS upravljanja, drugi ide izravno u oblak (trenutna proizvodnja).
Kao rezultat toga, uspoređujemo rezultate i dobivamo procjenu učinkovitosti:
Kao rezultat toga, naučili smo nekoliko važnih stvari:
- Procijenili smo očekivanu izvedbu zahtjeva klijenata prema oblaku koristeći DNS upravljanje.
- Dobili smo podatke od stvarnih klijenata, sa svih vrsta uređaja.
- Učinkovitost predložene ideje je dokazana.
- Nismo riskirali - nismo mijenjali proizvodne konfiguracije za klijente.
- Ništa nije bilo slomljeno.
Sada o teškom dijelu - lansiramo ga u proizvodnju
Lakši dio je sada gotov - postoji radni prototip. Sada je teži dio lansiranje rješenja za sav Netflixov promet, implementacija na 150 milijuna korisnika, tisuće uređaja, stotine mikroservisa i proizvoda i infrastrukture koji se stalno mijenjaju. Netflix poslužitelji primaju milijune zahtjeva u sekundi, a uslugu je lako prekinuti neopreznom radnjom. Istovremeno, želimo dinamički usmjeravati promet kroz tisuće CDN servera na Internetu, gdje se stalno i u najnepovoljnijem trenutku nešto mijenja i kvari.
Uz sve to, tim ima 3 inženjera odgovorna za razvoj, implementaciju i punu podršku sustava.
Stoga ćemo i dalje govoriti o mirnom i zdravom snu.
Kako nastaviti s razvojem i ne potrošiti sve svoje vrijeme na podršku? Naš pristup temelji se na 3 principa:
- Smanjujemo potencijalnu ljestvicu kvarova (radijus eksplozije).
- Spremamo se za iznenađenja - očekujemo da će se nešto pokvariti, unatoč testiranju i osobnom iskustvu.
- Graciozna degradacija - ako nešto ne radi kako treba, trebalo bi se automatski popraviti, čak i ako ne na najučinkovitiji način.
Pokazalo se da u našem slučaju ovakvim pristupom problemu možemo pronaći jednostavno i učinkovito rješenje te značajno pojednostaviti podršku sustavu. Shvatili smo da klijentu možemo dodati mali dio koda i pratiti pogreške mrežnog zahtjeva uzrokovane problemima s vezom. U slučaju mrežnih grešaka, vraćamo se izravno u oblak. Ovo rješenje ne zahtijeva značajan napor za klijentske timove, ali uvelike smanjuje rizik od neočekivanih kvarova i iznenađenja za nas.
Naravno, unatoč zamjeni, ipak slijedimo jasnu disciplinu tijekom razvoja:
- Uzorak testa.
- A/B testiranje ili Kanarinci.
- Progresivno uvođenje.
Uz uzorke je opisan pristup - promjene se najprije testiraju pomoću prilagođene recepture.
Za canary testiranje moramo dobiti usporedive parove servera na kojima možemo usporediti kako sustav radi prije i poslije promjena. Da bismo to učinili, s naših brojnih CDN stranica odabiremo parove poslužitelja koji primaju usporediv promet:
Zatim instaliramo build s promjenama na Canary server. Za procjenu rezultata, pokrećemo sustav koji uspoređuje približno 100-150 metrika s uzorkom kontrolnih poslužitelja:
Ako je Canary testiranje uspješno, tada ga puštamo postupno, u valovima. Ne ažuriramo poslužitelje na svakoj stranici u isto vrijeme - gubitak cijele stranice zbog problema ima značajniji utjecaj na uslugu za korisnike nego gubitak istog broja poslužitelja na različitim lokacijama.
Općenito, učinkovitost i sigurnost ovog pristupa ovisi o količini i kvaliteti prikupljenih metrika. Za naš sustav ubrzanja upita prikupljamo metriku iz svih mogućih komponenti:
- od klijenata - broj sesija i zahtjeva, povratne stope;
- proxy - statistika o broju i vremenu zahtjeva;
- DNS - broj i rezultati zahtjeva;
- cloud edge - broj i vrijeme obrade zahtjeva u oblaku.
Sve se to skuplja u jedan pipeline, a ovisno o potrebama odlučujemo koje ćemo metrike slati u analitiku u stvarnom vremenu, a koje u Elasticsearch ili Big Data za detaljniju dijagnostiku.
Pratimo
U našem slučaju, mijenjamo kritični put zahtjeva između klijenta i poslužitelja. Istovremeno, broj različitih komponenti na klijentu, na poslužitelju i na putu kroz Internet je ogroman. Promjene na klijentu i poslužitelju događaju se konstantno – tijekom rada desetaka timova i prirodnih promjena u ekosustavu. Mi smo u sredini - prilikom dijagnosticiranja problema, postoji dobra šansa da ćemo biti uključeni. Stoga moramo jasno razumjeti kako definirati, prikupiti i analizirati metrike da bismo brzo izolirali probleme.
Idealno, potpuni pristup svim vrstama metrika i filtara u stvarnom vremenu. No, ima puno metrika, pa se postavlja pitanje troškova. U našem slučaju, metriku i razvojne alate odvajamo na sljedeći način:
Za otkrivanje i sortiranje problema koristimo vlastiti sustav otvorenog koda u stvarnom vremenu и - za vizualizaciju. Pohranjuje agregirane metrike u memoriju, pouzdan je i integrira se sa sustavom upozorenja. Za lokalizaciju i dijagnostiku imamo pristup zapisima iz Elasticsearcha i Kibane. Za statističku analizu i modeliranje koristimo velike podatke i vizualizaciju u Tableau.
Čini se da je ovaj pristup vrlo težak za rad. Međutim, organiziranjem metrika i alata hijerarhijski, možemo brzo analizirati problem, odrediti vrstu problema, a zatim dubiti u detaljne metrike. Općenito, trošimo oko 1-2 minute da identificiramo izvor kvara. Nakon toga s određenim timom radimo dijagnostiku - od nekoliko desetaka minuta do nekoliko sati.
Čak i ako se dijagnoza napravi brzo, ne želimo da se to često događa. U idealnom slučaju, kritično upozorenje ćemo primiti samo kada postoji značajan utjecaj na uslugu. Za naš sustav ubrzanja upita, imamo samo 2 upozorenja koja će obavijestiti:
- Client Fallback postotak - procjena ponašanja kupaca;
- postotak Pogreške sonde - podaci o stabilnosti mrežnih komponenti.
Ova kritična upozorenja nadziru radi li sustav za većinu korisnika. Promatramo koliko je klijenata koristilo zamjenu ako nisu mogli dobiti ubrzanje zahtjeva. U prosjeku šaljemo manje od 1 kritičnog upozorenja tjedno, iako se u sustavu događa gomila promjena. Zašto nam je ovo dovoljno?
- Postoji rezervni klijent ako naš proxy ne radi.
- Postoji sustav automatskog upravljanja koji reagira na probleme.
Više detalja o potonjem. Naš probni sustav, te sustav za automatsko određivanje optimalnog puta za zahtjeve od klijenta do oblaka, omogućuje nam da se automatski nosimo s nekim problemima.
Vratimo se našoj oglednoj konfiguraciji i 3 kategorije puta. Osim vremena utovara, možemo promatrati i samu činjenicu isporuke. Ako nije bilo moguće učitati podatke, tada gledajući rezultate duž različitih putanja možemo utvrditi gdje je i što pokvareno, te možemo li to automatski popraviti promjenom putanje zahtjeva.
Primjeri:
Ovaj proces se može automatizirati. Uključite ga u sustav upravljanja. I naučite ga da reagira na probleme s performansama i pouzdanošću. Ako se nešto počne kvariti, reagirajte ako postoji bolja opcija. U isto vrijeme, trenutna reakcija nije kritična, zahvaljujući povratu na klijente.
Dakle, principi podrške sustavu mogu se formulirati na sljedeći način:
- smanjenje razmjera kvarova;
- prikupljanje metrike;
- Automatski popravljamo kvarove ako možemo;
- ako ne može, obavještavamo vas;
- Radimo na nadzornim pločama i skupu alata za trijažu za brzi odgovor.
Naučene lekcije
Za pisanje prototipa nije potrebno puno vremena. U našem slučaju je bio spreman nakon 4 mjeseca. Njime smo dobili novu metriku, a 10 mjeseci nakon početka razvoja prvi produkcijski promet. Zatim je započeo mukotrpan i vrlo težak posao: postupno proizvoditi i skalirati sustav, migrirati glavni promet i učiti na greškama. Međutim, ovaj učinkoviti proces neće biti linearan – unatoč svim naporima, ne može se sve predvidjeti. Mnogo je učinkovitije brzo ponavljati i odgovarati na nove podatke.
Na temelju našeg iskustva možemo preporučiti sljedeće:
- Ne vjerujte svojoj intuiciji.
Intuicija nas je konstantno iznevjerila, unatoč velikom iskustvu članova našeg tima. Na primjer, netočno smo predvidjeli očekivano ubrzanje korištenjem CDN proxyja ili ponašanje TCP Anycasta.
- Dobijte podatke iz proizvodnje.
Važno je što je prije moguće dobiti pristup barem maloj količini proizvodnih podataka. Gotovo je nemoguće dobiti broj jedinstvenih slučajeva, konfiguracija i postavki u laboratorijskim uvjetima. Brzi pristup rezultatima omogućit će vam brzo upoznavanje potencijalnih problema i njihovo uzimanje u obzir u arhitekturi sustava.
- Ne slijedite tuđe savjete i rezultate – prikupljajte vlastite podatke.
Slijedite načela prikupljanja i analize podataka, ali nemojte slijepo prihvaćati tuđe rezultate i izjave. Samo vi možete točno znati što odgovara vašim korisnicima. Vaši sustavi i vaši klijenti mogu se značajno razlikovati od drugih tvrtki. Srećom, alati za analizu sada su dostupni i jednostavni za korištenje. Rezultati koje dobijete možda nisu ono što tvrde Netflix, Facebook, Akamai i druge tvrtke. U našem slučaju, performanse TLS-a, HTTP2 ili statistike na DNS zahtjevima razlikuju se od rezultata Facebooka, Ubera, Akamaija – jer imamo drugačije uređaje, klijente i protoke podataka.
- Nemojte nepotrebno slijediti modne trendove i procijeniti učinkovitost.
Počnite jednostavno. Bolje je napraviti jednostavan radni sustav u kratkom vremenu nego trošiti ogromnu količinu vremena razvijajući komponente koje vam ne trebaju. Rješavajte zadatke i probleme koji su važni na temelju vaših mjerenja i rezultata.
- Pripremite se za nove aplikacije.
Kao što je teško predvidjeti sve probleme, teško je unaprijed predvidjeti prednosti i primjene. Ugledajte se na startupove - njihovu sposobnost prilagodbe uvjetima kupaca. U vašem slučaju, možda ćete otkriti nove probleme i njihova rješenja. U našem projektu postavili smo cilj smanjiti kašnjenje zahtjeva. Međutim, tijekom analize i rasprava, shvatili smo da možemo koristiti i proxy poslužitelje:
- uravnotežiti promet u AWS regijama i smanjiti troškove;
- modelirati stabilnost CDN-a;
- konfigurirati DNS;
- za konfiguraciju TLS/TCP.
Zaključak
U izvješću sam opisao kako Netflix rješava problem ubrzanja internetskih zahtjeva između klijenata i oblaka. Kako prikupljamo podatke pomoću sustava uzorkovanja o klijentima i koristimo prikupljene povijesne podatke za usmjeravanje zahtjeva za proizvodnju od klijenata najbržim putem na Internetu. Kako koristimo načela mrežnih protokola, našu CDN infrastrukturu, okosnicu mreže i DNS poslužitelje za postizanje ovog zadatka.
Međutim, naše rješenje samo je primjer kako smo mi u Netflixu implementirali takav sustav. Što nam je uspjelo. Primijenjeni dio mog izvješća za vas su principi razvoja i podrške koje slijedimo i ostvarujemo dobre rezultate.
Naše rješenje problema vam možda neće odgovarati. Međutim, teorija i principi dizajna ostaju, čak i ako nemate vlastitu CDN infrastrukturu ili ako se značajno razlikuje od naše.
Važnost brzine poslovnih zahtjeva također ostaje važna. Čak i za jednostavnu uslugu trebate napraviti izbor: između pružatelja usluga oblaka, lokacije poslužitelja, CDN i DNS pružatelja usluga. Vaš izbor će utjecati na učinkovitost internetskih upita za vaše klijente. I za vas je važno mjeriti i razumjeti ovaj utjecaj.
Počnite s jednostavnim rješenjima, vodite računa o tome kako mijenjate proizvod. Učite usput i poboljšajte sustav na temelju podataka vaših kupaca, vaše infrastrukture i vašeg poslovanja. Razmislite o mogućnosti neočekivanih kvarova tijekom procesa projektiranja. A tada možete ubrzati svoj razvojni proces, poboljšati učinkovitost rješenja, izbjeći nepotrebno opterećenje podrške i mirno spavati.
Ove godine u online formatu. Možete postavljati pitanja jednom od očeva DevOpsa, Johnu Willisu osobno!
Izvor: www.habr.com