Netflix je lider na tržištu internetske televizije - kompanija koja je stvorila i aktivno razvija ovaj segment. Netflix je poznat ne samo po svom opsežnom katalogu filmova i TV serija dostupnih iz gotovo svakog kutka planete i bilo kojem uređaju s ekranom, već i po pouzdanoj infrastrukturi i jedinstvenoj inženjerskoj kulturi.
Jasan primjer Netflix pristupa razvoju i podršci složenih sistema predstavljen je na DevOops 2019. - Direktor razvoja u Netflixu. Diplomirao je na Fakultetu računarske matematike i matematike Državnog univerziteta Nižnji Novgorod. Lobačevski, Sergej jedan od prvih inženjera u Open Connect - CDN timu na Netflixu. Izgradio je sisteme za praćenje i analizu video podataka, pokrenuo popularni servis za procjenu brzine internet konekcije FAST.com, a posljednjih godina radi na optimizaciji internet zahtjeva kako bi Netflix aplikacija što brže radila za korisnike.
Izveštaj je dobio najbolje kritike učesnika konferencije, a mi smo za vas pripremili tekstualnu verziju.
U svom izvještaju, Sergej je govorio detaljno
- o tome šta utiče na kašnjenje Internet zahteva između klijenta i servera;
- kako smanjiti ovo kašnjenje;
- kako dizajnirati, održavati i nadgledati sisteme tolerantne na greške;
- kako postići rezultate u kratkom vremenu, uz minimalan rizik za poslovanje;
- kako analizirati rezultate i učiti iz grešaka.
Odgovori na ova pitanja nisu potrebni samo onima koji rade u velikim korporacijama.
Predstavljene principe i tehnike treba da znaju i praktikuju svi koji razvijaju i podržavaju Internet proizvode.
Sljedeća je naracija iz perspektive govornika.
Važnost brzine interneta
Brzina internet zahtjeva direktno je povezana s poslovanjem. Uzmite u obzir industriju kupovine: Amazon 2009 da kašnjenje od 100 ms rezultira gubitkom od 1% prodaje.
Sve je više mobilnih uređaja, zatim mobilnih stranica i aplikacija. Ako se vašoj stranici učitava duže od 3 sekunde, gubite otprilike polovinu korisnika. WITH Google uzima u obzir brzinu učitavanja vaše stranice u rezultatima pretrage: što je stranica brža, to je njena pozicija na Googleu viša.
Brzina konekcije je takođe važna u finansijskim institucijama gde je kašnjenje kritično. U 2015. godini, Hibernia Networks kabl od 400 miliona dolara između Njujorka i Londona za smanjenje kašnjenja između gradova za 6 ms. Zamislite 66 miliona dolara za smanjenje kašnjenja od 1 ms!
Prema , brzine veze veće od 5 Mbit/s više ne utiču direktno na brzinu učitavanja tipične web stranice. Međutim, postoji linearna veza 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 aplikacije i odabir sadržaja koji zavise od kašnjenja, ali učitavanje statičkih elemenata i streaming također zavise od brzine veze. Analiza i optimizacija ključnih faktora koji utiču na korisničko iskustvo je aktivno područje razvoja za nekoliko timova u Netflixu. Jedan od ciljeva je smanjenje kašnjenja zahtjeva između Netflix uređaja i cloud infrastrukture.
U izvještaju ćemo se posebno fokusirati na smanjenje latencije koristeći primjer Netflix infrastrukture. Razmotrimo sa praktične tačke gledišta kako pristupiti procesima dizajna, razvoja i rada složenih distribuiranih sistema i potrošiti vrijeme na inovacije i rezultate, umjesto na dijagnosticiranje operativnih problema i kvarova.
Unutar Netflixa
Hiljade različitih uređaja podržavaju Netflix aplikacije. Razvijaju ih četiri različita tima, koji prave zasebne verzije klijenta za Android, iOS, TV i web pretraživače. I ulažemo mnogo truda u poboljšanje i personalizaciju korisničkog iskustva. Da bismo to učinili, izvodimo stotine A/B testova paralelno.
Personalizaciju podržavaju stotine mikroservisa u AWS oblaku, pružajući personalizirane korisničke podatke, otpremu upita, telemetriju, velike podatke i kodiranje. Vizualizacija saobraćaja izgleda ovako:
Sa lijeve strane je ulazna tač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 isporučuje statički sadržaj krajnjem korisniku - video zapise, slike, klijentski kod, itd. CDN se nalazi na prilagođenim serverima (OCA - Open Connect Appliance). Unutra se nalaze nizovi SSD i HDD diskova koji koriste optimizovani FreeBSD, sa NGINX-om i skupom usluga. Dizajniramo i optimiziramo hardverske i softverske komponente kako bi takav CDN server mogao poslati što više podataka korisnicima.
“Zid” ovih servera na tački razmjene internet prometa (Internet eXchange - IX) izgleda ovako:
Internet Exchange pruža mogućnost provajderima Internet usluga i provajderima sadržaja da se međusobno „povežu“ kako bi direktnije razmenjivali podatke na Internetu. Postoji otprilike 70-80 Internet Exchange tačaka širom svijeta na kojima su instalirani naši serveri, a mi ih samostalno instaliramo i održavamo:
Osim toga, pružamo i servere direktno internet provajderima, koje oni instaliraju u svoju mrežu, poboljšavajući lokalizaciju Netflix prometa i kvalitet streaminga za korisnike:
Skup AWS servisa odgovoran je za slanje video zahtjeva od klijenata do CDN servera, kao i za konfiguraciju samih servera - ažuriranje sadržaja, programskog koda, postavki itd. Za ovo drugo, izgradili smo i okosnu mrežu koja povezuje servere u Internet Exchange tačkama sa AWS-om. Mreža okosnice je globalna mreža optičkih kablova i rutera koje možemo dizajnirati i konfigurisati na osnovu naših potreba.
By , naša CDN infrastruktura isporučuje otprilike ⅛ svjetskog internet prometa u vršnim satima i ⅓ prometa u Sjevernoj Americi, gdje je Netflix najduže prisutan. Impresivne brojke, ali za mene jedno od najnevjerovatnijih dostignuća je to što cijeli CDN sistem 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 ubrzanju interneta
Danas Netflix ima 3 AWS regije, a latencija zahtjeva prema oblaku ovisit će o tome koliko je korisnik udaljen od najbližeg regiona. Istovremeno, imamo mnogo CDN servera koji se koriste za isporuku statičkog sadržaja. Postoji li neki način da se koristi ovaj okvir za ubrzavanje dinamičkih upita? Međutim, nažalost, nemoguće je keširati ove zahtjeve - API-ji su personalizirani i svaki rezultat je jedinstven.
Napravimo proxy na CDN serveru i počnemo slati promet preko njega. Hoće li biti brže?
Materiel
Prisjetimo se kako mrežni protokoli rade. Danas većina saobraćaja na Internetu koristi HTTPs, što zavisi od protokola nižeg sloja TCP i TLS. Da bi se klijent povezao sa serverom, vrši rukovanje, a da bi uspostavio sigurnu vezu, klijent treba tri puta razmijeniti poruke sa serverom i barem još jednom za prijenos podataka. Uz kašnjenje po povratnom putu (RTT) od 100 ms, trebalo bi nam 400 ms da primimo prvi bit podataka:
Ako certifikate postavimo na CDN server, onda se vrijeme rukovanja između klijenta i servera može značajno smanjiti ako je CDN bliži. Pretpostavimo da je kašnjenje do CDN servera 30ms. Tada će biti potrebno 220 ms da primi prvi bit:
Ali prednostima tu nije kraj. Jednom kada je veza uspostavljena, TCP povećava prozor zagušenja (količina informacija koju može paralelno prenijeti preko te veze). Ako se izgubi paket podataka, onda klasične implementacije TCP protokola (poput TCP New Reno) smanjuju otvoreni „prozor“ za polovinu. Rast prozora zagušenja i brzina njegovog oporavka od gubitka opet zavisi od kašnjenja (RTT) do servera. Ako ova veza ide samo do CDN servera, ovaj oporavak će biti brži. Istovremeno, gubitak paketa je standardna pojava, posebno za bežične mreže.
Propusnost Interneta može biti smanjena, posebno u vršnim satima, zbog prometa korisnika, što može dovesti do saobraćajnih gužvi. Međutim, na Internetu ne postoji način da se nekim zahtjevima da prioritet nad drugima. Na primjer, dajte prioritet malim zahtjevima koji su osjetljivi na kašnjenje u odnosu na "teške" tokove podataka koji učitavaju mrežu. Međutim, u našem slučaju, posjedovanje vlastite okosne mreže nam omogućava da to učinimo na dijelu putanje zahtjeva - između CDN-a i oblaka, i možemo je u potpunosti konfigurirati. Možete osigurati da mali paketi i paketi osjetljivi na kašnjenje imaju prioritet, a veliki tokovi podataka idu malo kasnije. Što je CDN bliži klijentu, to je veća efikasnost.
Protokoli na nivou aplikacije (OSI nivo 7) takođe imaju uticaj na kašnjenje. Novi protokoli kao što je HTTP/2 optimizuju performanse paralelnih zahteva. 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. Istovremeno, između CDN proxyja i oblaka postoji potpuna kontrola i mogućnost korištenja novih, optimalnih protokola i postavki. Nedjelotvorni dio sa starim protokolima će raditi samo između klijenta i CDN servera. Štaviše, možemo napraviti multipleks zahtjeve na već uspostavljenoj vezi između CDN-a i oblaka, poboljšavajući korištenje veze na TCP nivou:
Merimo
Uprkos činjenici da teorija obećava poboljšanja, ne žurimo odmah da pokrenemo sistem u proizvodnji. Umjesto toga, prvo moramo dokazati da će ideja funkcionirati u praksi. Da biste to učinili morate odgovoriti na nekoliko pitanja:
- Brzina: hoće li proxy biti brži?
- Pouzdanost: Hoće li se češće lomiti?
- Poteškoća: kako se integrirati sa aplikacijama?
- trošak: Koliko košta postavljanje dodatne infrastrukture?
Razmotrimo detaljno naš pristup procjeni prve tačke. Ostalo se rješava na sličan način.
Da 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 pasivno mjerenje zahtjeva. Mjerimo vrijeme izvršenja trenutnih zahtjeva korisnika i osiguravamo potpunu pokrivenost korisnika. Nedostatak je što signal nije baš stabilan zbog mnogih faktora, na primjer, zbog različitih veličina zahtjeva, vremena obrade na serveru i klijentu. Osim toga, ne možete testirati novu konfiguraciju bez efekta u proizvodnji.
- Laboratorijski testovi. Specijalni serveri i infrastruktura koji simuliraju klijente. Uz njihovu pomoć vršimo potrebna ispitivanja. Na taj način dobijamo potpunu kontrolu nad rezultatima mjerenja i jasan signal. Ali ne postoji potpuna pokrivenost uređaja i lokacija korisnika (posebno sa servisom širom svijeta i podrškom za hiljade 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ćavaju da vršimo potpuno kontrolisane mrežne testove sa naših uređaja. Radi ovako:
- Ubrzo nakon učitavanja aplikacije i završetka početne aktivnosti, pokrećemo naše sonde.
- Klijent šalje zahtev serveru i dobija „recept“ za test. Recept je lista 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. Istovremeno, možemo paralelno testirati nekoliko različitih recepata - kada tražimo konfiguraciju, nasumično određujemo koji recept izdati.
- Vrijeme pokretanja sonde je odabrano tako da ne dođe u sukob s aktivnim korištenjem mrežnih resursa na klijentu. U suštini, vrijeme se bira kada klijent nije aktivan.
- Nakon prijema recepta, klijent paralelno postavlja zahtjeve za svaki od URL-ova. Zahtjev na svaku od adresa može se ponoviti - tzv. "impulsi". Na prvom impulsu 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 podesiti kašnjenje i izmjeriti brzinu uspostavljanja rekonekcije itd.
Tokom testiranja mjerimo sve parametre koje uređaj može dobiti:
- Vrijeme zahtjeva za DNS;
- Vrijeme postavljanja TCP veze;
- Vrijeme postavljanja TLS veze;
- vrijeme prijema prvog bajta podataka;
- ukupno vrijeme učitavanja;
- kod rezultata statusa.
- Nakon što su svi impulsi završeni, uzorak učitava sva mjerenja za analizu.
Ključne tačke su minimalna zavisnost od logike na klijentu, obrada podataka na serveru i merenje paralelnih zahteva. Tako smo u mogućnosti da izolujemo i testiramo uticaj različitih faktora koji utiču na performanse upita, da ih variramo u okviru jednog recepta i dobijemo rezultate od stvarnih klijenata.
Ova infrastruktura se pokazala korisnom za više od analize performansi upita. Trenutno imamo 14 aktivnih recepata, više od 6000 uzoraka u sekundi, primanje podataka sa svih strana svijeta i punu pokrivenost uređaja. Ako bi Netflix kupio sličnu uslugu od treće strane, to bi koštalo milione dolara godišnje, uz mnogo lošiju pokrivenost.
Teorija ispitivanja u praksi: prototip
Sa takvim sistemom, bili smo u mogućnosti da procenimo efikasnost CDN proksija na zahtev latencije. Sada trebate:
- kreirajte prototip proxyja;
- postavite prototip na CDN;
- odrediti kako usmjeriti klijente na proxy na određenom CDN serveru;
- Uporedite performanse sa zahtjevima u AWS-u bez proxyja.
Zadatak je da se što pre proceni efikasnost predloženog rešenja. Odabrali smo Go za implementaciju prototipa zbog dostupnosti dobrih mrežnih biblioteka. Na svakom CDN serveru smo instalirali prototip proxyja kao statičku binarnu datoteku kako bismo minimizirali zavisnosti i pojednostavili integraciju. U početnoj implementaciji koristili smo standardne komponente što je više moguće i manje modifikacije za prikupljanje HTTP/2 veze i multipleksiranje zahtjeva.
Da bismo balansirali između AWS regiona, koristili smo geografsku DNS bazu podataka, istu onu koja se koristila za balansiranje klijenata. Da bismo odabrali CDN server za klijenta, koristimo TCP Anycast za servere u Internet Exchange (IX). U ovoj opciji koristimo jednu IP adresu za sve CDN servere, a klijent će biti preusmjeren na CDN server sa najmanjim brojem IP skokova. Na CDN serverima instaliranim od strane Internet provajdera (ISP), nemamo kontrolu nad ruterom za konfiguraciju TCP Anycast-a, pa koristimo , koji korisnike usmjerava na internet provajdere za video streaming.
Dakle, imamo tri tipa putanja zahteva: do oblaka preko otvorenog Interneta, preko CDN servera u IX ili preko CDN servera koji se nalazi kod Internet provajdera. Naš cilj je da shvatimo koji je način bolji i koja je korist od proxyja u odnosu na to kako se zahtjevi šalju u produkciju. Da bismo to učinili, koristimo sistem uzorkovanja kako slijedi:
Svaka od staza postaje zasebna meta, a mi gledamo koliko smo dobili. Za analizu kombinujemo rezultate proxyja u jednu grupu (odabiremo najbolje vrijeme između IX i ISP proksija) i upoređujemo ih sa vremenom zahtjeva u oblak 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 kod kojih će se situacija značajno pogoršati.
Kao rezultat toga, uradili smo nekoliko važnih stvari:
- Procijenili smo očekivane performanse zahtjeva klijenata prema oblaku preko CDN proxyja.
- Dobijali smo podatke od stvarnih klijenata, sa svih vrsta uređaja.
- Shvatili smo da teorija nije 100% potvrđena i da početna ponuda sa CDN proxyjem neće raditi za nas.
- Nismo riskirali - nismo mijenjali proizvodne konfiguracije za klijente.
- Ništa nije pokvareno.
Prototip 2.0
Dakle, vratite se na ploču za crtanje i ponovite postupak iznova.
Ideja je da umjesto da koristimo 100% proxy, odredimo najbrži put za svakog klijenta, i tamo ćemo slati zahtjeve – odnosno raditi ono što se zove upravljanje klijentom.
Kako ovo implementirati? Ne možemo koristiti logiku na strani servera, jer... Cilj je da se povežete na ovaj server. Mora postojati neki način da se to uradi na klijentu. I idealno, uradite 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 serveri biti autoritarni. Radi ovako:
- Klijent postavlja zahtjev DNS serveru koristeći host, na primjer api.netflix.xom.
- Zahtjev stiže na naš DNS server
- DNS server zna koja je putanja najbrža za ovog klijenta i izdaje odgovarajuću IP adresu.
Rješenje ima dodatnu složenost: autoritarni DNS provajderi ne vide klijentovu IP adresu i mogu samo pročitati IP adresu rekurzivnog razrjeđivača koji klijent koristi.
Kao rezultat toga, naš autoritarni razrješavač mora donijeti odluku ne za pojedinačnog klijenta, već za grupu klijenata na osnovu rekurzivnog razrješača.
Za rješavanje, koristimo iste uzorke, agregiramo rezultate mjerenja od klijenata za svaki od rekurzivnih razrješavača i odlučujemo gdje ćemo poslati ovu grupu njih - proxy preko IX koristeći TCP Anycast, preko ISP proxyja ili direktno u oblak.
Dobijamo sledeći sistem:
Rezultirajući model upravljanja DNS-om omogućava vam da usmjeravate klijente na osnovu povijesnih zapažanja brzine konekcija od klijenata do oblaka.
Opet, pitanje je koliko će ovaj pristup djelotvorno funkcionirati? Da bismo odgovorili, ponovo koristimo naš sistem sonde. Stoga konfiguriramo konfiguraciju prezentera, gdje jedan od ciljeva prati smjer od DNS upravljanja, a drugi ide direktno u oblak (trenutna proizvodnja).
Kao rezultat, upoređujemo rezultate i dobijamo ocjenu efikasnosti:
Kao rezultat toga, naučili smo nekoliko važnih stvari:
- Procijenili smo očekivane performanse zahtjeva klijenata u oblak koristeći DNS Steering.
- Dobijali smo podatke od stvarnih klijenata, sa svih vrsta uređaja.
- Efikasnost predložene ideje je dokazana.
- Nismo riskirali - nismo mijenjali proizvodne konfiguracije za klijente.
- Ništa nije pokvareno.
Sada o težem dijelu - pokrećemo ga u proizvodnju
Lakši dio je sada gotov - postoji prototip koji radi. Sada je teži dio lansiranje rješenja za sav promet Netflixa, postavljanje na 150 miliona korisnika, hiljade uređaja, stotine mikroservisa i proizvod i infrastrukturu koja se stalno mijenja. Netflix serveri primaju milione zahtjeva u sekundi i lako je prekinuti uslugu nepažljivim djelovanjem. Istovremeno, želimo da dinamički usmjerimo promet kroz hiljade CDN servera na Internetu, gdje se nešto mijenja i lomi stalno iu najnepovoljnijem trenutku.
Uz sve to, tim ima 3 inženjera odgovorna za razvoj, implementaciju i punu podršku sistema.
Stoga ćemo nastaviti da pričamo o mirnom i zdravom snu.
Kako nastaviti razvoj i ne trošiti svo vrijeme na podršku? Naš pristup se zasniva na 3 principa:
- Smanjujemo potencijalnu skalu kvarova (radijus eksplozije).
- Spremamo se za iznenađenja - očekujemo da će se nešto pokvariti, uprkos testiranju i ličnom iskustvu.
- Graciozna degradacija - ako nešto ne radi kako treba, to treba automatski popraviti, čak i ako ne na najefikasniji način.
Pokazalo se da u našem slučaju ovakvim pristupom problemu možemo pronaći jednostavno i efikasno rješenje i značajno pojednostaviti sistemsku podršku. Shvatili smo da možemo dodati mali dio koda klijentu i nadgledati greške mrežnog zahtjeva uzrokovane problemima s vezom. U slučaju mrežnih grešaka, vraćamo se direktno na oblak. Ovo rješenje ne zahtijeva značajne napore timova klijenata, ali uvelike smanjuje rizik od neočekivanih kvarova i iznenađenja za nas.
Naravno, uprkos rezervnom, mi ipak slijedimo jasnu disciplinu tokom razvoja:
- Test uzorka.
- A/B testiranje ili Kanarinci.
- Progresivno uvođenje.
Sa uzorcima je opisan pristup - promjene se prvo testiraju prema prilagođenom receptu.
Za testiranje kanarinca, potrebno je da dobijemo uporedive parove servera na kojima možemo da uporedimo kako sistem radi pre i posle promena. Da bismo to učinili, sa naših brojnih CDN stranica, biramo parove servera koji primaju uporediv promet:
Zatim instaliramo build sa promjenama na Canary server. Da bismo procijenili rezultate, pokrećemo sistem koji upoređuje približno 100-150 metrika sa uzorkom kontrolnih servera:
Ako je testiranje Canaryca uspješno, onda ga oslobađamo postepeno, u valovima. Ne ažuriramo servere na svakoj stranici u isto vrijeme - gubitak cijele stranice zbog problema ima značajniji utjecaj na uslugu za korisnike od gubitka istog broja servera na različitim lokacijama.
Općenito, efikasnost i sigurnost ovog pristupa zavise od količine i kvaliteta prikupljenih metrika. Za naš sistem ubrzanja upita prikupljamo metriku od svih mogućih komponenti:
- od klijenata - broj sesija i zahtjeva, rezervne stope;
- proxy - statistika o broju i vremenu zahtjeva;
- DNS - broj i rezultati zahtjeva;
- cloud edge - broj i vrijeme za obradu zahtjeva u oblaku.
Sve se to skuplja u jedan pipeline i, ovisno o potrebama, odlučujemo koje ćemo metrike poslati u analitiku u realnom vremenu, a koje u Elasticsearch ili Big Data za detaljniju dijagnostiku.
Pratimo
U našem slučaju, vršimo promjene na kritičnom putu zahtjeva između klijenta i servera. Istovremeno, broj različitih komponenti na klijentu, na serveru i na putu kroz Internet je ogroman. Promjene na klijentu i serveru se dešavaju konstantno – tokom rada desetina timova i prirodnih promjena u ekosistemu. U sredini smo - kada dijagnosticiramo probleme, velika je šansa da ćemo biti uključeni. Stoga moramo jasno razumjeti kako definirati, prikupiti i analizirati metriku da bismo brzo izolirali probleme.
Idealno, potpuni pristup svim vrstama metrika i filtera u realnom vremenu. Ali ima mnogo metrika, pa se postavlja pitanje troškova. U našem slučaju odvajamo metriku i razvojne alate na sljedeći način:
Za otkrivanje i trijažiranje problema koristimo vlastiti sistem otvorenog koda u realnom vremenu и - za vizualizaciju. Pohranjuje agregirane metrike u memoriju, pouzdan je i integriše se sa sistemom za uzbunjivanje. Za lokalizaciju i dijagnostiku imamo pristup logovima iz Elasticsearch-a i Kibana. Za statističku analizu i modeliranje koristimo velike podatke i vizualizaciju u Tableau-u.
Čini se da je sa ovim pristupom veoma teško raditi. Međutim, hijerarhijskim organiziranjem metrike i alata, možemo brzo analizirati problem, odrediti vrstu problema, a zatim detaljne metrike. Općenito, trošimo oko 1-2 minute da identifikujemo izvor kvara. Nakon toga radimo sa određenim timom na dijagnostici - od desetina minuta do nekoliko sati.
Čak i ako se dijagnoza brzo postavi, ne želimo da se to dešava često. U idealnom slučaju, primićemo kritično upozorenje samo kada postoji značajan uticaj na uslugu. Za naš sistem ubrzanja upita imamo samo 2 upozorenja koja će obavijestiti:
- Client Fallback postotak - procjena ponašanja korisnika;
- procenat Greške sonde - podaci o stabilnosti mrežnih komponenti.
Ova kritična upozorenja prate da li sistem radi za većinu korisnika. Gledamo koliko je klijenata koristilo rezervni dio ako nisu mogli dobiti ubrzanje zahtjeva. U prosjeku imamo manje od 1 kritičnog upozorenja sedmično, iako se u sistemu dešava mnogo promjena. Zašto nam je ovo dovoljno?
- Postoji rezervni klijent ako naš proxy ne radi.
- Postoji automatski sistem upravljanja koji reaguje na probleme.
Više detalja o potonjem. Naš probni sistem, kao i sistem za automatsko određivanje optimalnog puta za zahteve od klijenta do oblaka, omogućava nam da se automatski nosimo sa nekim problemima.
Vratimo se na našu konfiguraciju uzorka i 3 kategorije staza. Osim vremena utovara, možemo pogledati i samu isporuku. Ako nije bilo moguće učitati podatke, onda gledanjem rezultata na različitim stazama možemo utvrditi gdje i šta je pokvareno i da li to možemo automatski popraviti promjenom putanje zahtjeva.
primjeri:
Ovaj proces se može automatizovati. Uključite ga u sistem upravljanja. I naučite ga da odgovori na probleme performansi i pouzdanosti. Ako nešto počne da se kvari, reagujte ako postoji bolja opcija. U isto vrijeme, trenutna reakcija nije kritična, zahvaljujući rezervnom pristupu klijentima.
Dakle, principi sistemske podrške mogu se formulisati na sljedeći način:
- smanjenje obima kvarova;
- prikupljanje metrike;
- Automatski popravljamo kvarove ako možemo;
- ako ne može, obavještavamo vas;
- Radimo na nadzornim pločama i trijažnim alatima za brzi odgovor.
Naučene lekcije
Za pisanje prototipa nije potrebno mnogo vremena. U našem slučaju, bio je spreman nakon 4 mjeseca. Sa njim smo dobili nove metrike, a 10 mjeseci nakon početka razvoja dobili smo prvi proizvodni promet. Tada je počeo zamoran i vrlo težak posao: postepeno proizvoditi i skalirati sistem, migrirati glavni promet i učiti iz grešaka. Međutim, ovaj efikasan proces neće biti linearan – uprkos svim naporima, ne može se sve predvidjeti. Mnogo je efikasnije brzo ponoviti i odgovoriti na nove podatke.
Na osnovu našeg iskustva, možemo preporučiti sljedeće:
- Ne vjerujte svojoj intuiciji.
Intuicija nas je stalno iznevjerila, uprkos ogromnom iskustvu članova našeg tima. Na primjer, pogrešno smo predvidjeli očekivano ubrzanje od korištenja CDN proxyja ili ponašanje TCP Anycast-a.
- Dobijte podatke iz proizvodnje.
Važno je dobiti pristup barem maloj količini proizvodnih podataka što je prije moguće. Gotovo je nemoguće dobiti broj jedinstvenih slučajeva, konfiguracija i postavki u laboratorijskim uvjetima. Brz pristup rezultatima će vam omogućiti da brzo saznate o potencijalnim problemima i uzmete ih u obzir u arhitekturi sistema.
- Ne slijedite tuđe savjete i rezultate – prikupite svoje podatke.
Pridržavajte se principa prikupljanja i analize podataka, ali ne prihvatajte slijepo rezultate i izjave drugih ljudi. Samo vi možete znati šta tačno funkcioniše za vaše korisnike. Vaši sistemi i vaši klijenti mogu se značajno razlikovati od drugih kompanija. Srećom, alati za analizu su sada dostupni i jednostavni za korištenje. Rezultati koje dobijete možda nisu ono što Netflix, Facebook, Akamai i druge kompanije tvrde. U našem slučaju, performanse TLS-a, HTTP2 ili statistike na DNS zahtjevima se razlikuju od rezultata Facebooka, Ubera, Akamaija - jer imamo različite uređaje, klijente i tokove podataka.
- Nemojte bespotrebno pratiti modne trendove i procijeniti učinkovitost.
Počni jednostavno. Bolje je napraviti jednostavan radni sistem za kratko vrijeme nego potrošiti ogromnu količinu vremena na razvoj komponenti koje vam nisu potrebne. Rješavajte važne zadatke i probleme na osnovu 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 primjenu. Uzmite primjer od startupa - njihovu sposobnost da se prilagode uvjetima kupaca. U vašem slučaju možete otkriti nove probleme i njihova rješenja. U našem projektu smo postavili cilj da smanjimo kašnjenje zahtjeva. Međutim, tokom analize i diskusija, shvatili smo da možemo koristiti i proxy servere:
- balansirati promet u AWS regijama i smanjiti troškove;
- modelirati stabilnost CDN-a;
- da konfigurišete DNS;
- da konfigurišete TLS/TCP.
zaključak
U izvještaju sam opisao kako Netflix rješava problem ubrzanja internetskih zahtjeva između klijenata i oblaka. Kako prikupljamo podatke koristeći sistem uzorkovanja o klijentima i koristimo prikupljene historijske podatke za usmjeravanje zahtjeva za proizvodnju od klijenata najbržim putem na Internetu. Kako koristimo principe mrežnih protokola, našu CDN infrastrukturu, okosnu mrežu i DNS servere da bismo postigli ovaj zadatak.
Međutim, naše rješenje je samo primjer kako smo u Netflixu implementirali takav sistem. Šta je radilo za nas. Primijenjeni dio mog izvještaja za vas su principi razvoja i podrške koje slijedimo i postižemo dobre rezultate.
Naše rješenje problema vam možda neće odgovarati. Međutim, teorija i principi dizajna ostaju, čak i ako nemate svoju CDN infrastrukturu, ili ako se ona značajno razlikuje od naše.
Važnost brzine poslovnih zahtjeva također ostaje važna. Čak i za jednostavnu uslugu morate napraviti izbor: između dobavljača u oblaku, lokacije servera, CDN i DNS provajdera. Vaš izbor će uticati na efikasnost internet upita za vaše klijente. I važno je da izmerite i razumete ovaj uticaj.
Počnite s jednostavnim rješenjima, vodite računa o tome kako mijenjate proizvod. Učite kako idete i poboljšajte sistem na osnovu podataka vaših klijenata, vaše infrastrukture i vašeg poslovanja. Razmislite o mogućnosti neočekivanih kvarova tokom procesa projektovanja. I tada možete ubrzati svoj razvojni proces, poboljšati efikasnost rješenja, izbjeći nepotrebno opterećenje podrške i mirno spavati.
Ove godine u online formatu. Možete postaviti pitanja jednom od očeva DevOps-a, samom Johnu Willisu!
izvor: www.habr.com