Netflix este liderul pe piața de televiziune pe internet - compania care a creat și dezvoltă activ acest segment. Netflix este cunoscut nu numai pentru catalogul său extins de filme și seriale TV disponibile din aproape fiecare colț al planetei și orice dispozitiv cu afișaj, ci și pentru infrastructura sa de încredere și cultura inginerească unică.
Un exemplu clar al abordării Netflix pentru dezvoltarea și susținerea sistemelor complexe a fost prezentat la DevOops 2019 - Director de dezvoltare la Netflix. Absolvent al Facultății de Matematică Computațională și Matematică a Universității de Stat Nijni Novgorod. Lobachevsky, Sergey unul dintre primii ingineri din Open Connect - echipa CDN de la Netflix. A construit sisteme de monitorizare și analiză a datelor video, a lansat un serviciu popular de evaluare a vitezei conexiunii la Internet FAST.com, iar în ultimii câțiva ani lucrează la optimizarea solicitărilor de pe Internet, astfel încât aplicația Netflix să funcționeze cât mai repede posibil pentru utilizatori.
Raportul a primit cele mai bune recenzii de la participanții la conferință și v-am pregătit o versiune text.
În raportul său, Serghei a vorbit în detaliu
- despre ceea ce afectează întârzierea cererilor de Internet între client și server;
- cum să reduceți această întârziere;
- modul de proiectare, întreținere și monitorizare a sistemelor tolerante la erori;
- cum să obțineți rezultate într-un timp scurt și cu risc minim pentru afacere;
- cum să analizezi rezultatele și să înveți din greșeli.
Răspunsurile la aceste întrebări sunt necesare nu numai de cei care lucrează în marile corporații.
Principiile și tehnicile prezentate ar trebui să fie cunoscute și practicate de toți cei care dezvoltă și susțin produse Internet.
Urmează narațiunea din perspectiva vorbitorului.
Importanța vitezei internetului
Viteza solicitărilor de internet este direct legată de afaceri. Luați în considerare industria de cumpărături: Amazon în 2009 că o întârziere de 100 ms duce la o pierdere de 1% din vânzări.
Există tot mai multe dispozitive mobile, urmate de site-uri și aplicații mobile. Dacă pagina dvs. durează mai mult de 3 secunde pentru a se încărca, pierdeți aproximativ jumătate dintre utilizatori. CU Google ține cont de viteza de încărcare a paginii dvs. în rezultatele căutării: cu cât pagina este mai rapidă, cu atât este mai mare poziția acesteia în Google.
Viteza conexiunii este, de asemenea, importantă în instituțiile financiare unde latența este critică. În 2015, Hibernia Networks un cablu de 400 de milioane de dolari între New York și Londra pentru a reduce latența dintre orașe cu 6 ms. Imaginați-vă 66 de milioane de dolari pentru 1 ms de reducere a latenței!
În conformitate cu , vitezele de conectare de peste 5 Mbit/s nu mai afectează direct viteza de încărcare a unui site web tipic. Cu toate acestea, există o relație liniară între latența conexiunii și viteza de încărcare a paginii:
Cu toate acestea, Netflix nu este un produs tipic. Impactul latenței și vitezei asupra utilizatorului este o zonă activă de analiză și dezvoltare. Există încărcarea aplicațiilor și selectarea conținutului care depind de latență, dar încărcarea elementelor statice și streaming depind și de viteza conexiunii. Analizarea și optimizarea factorilor cheie care influențează experiența utilizatorului este o zonă activă de dezvoltare pentru mai multe echipe de la Netflix. Unul dintre obiective este reducerea latenței solicitărilor dintre dispozitivele Netflix și infrastructura cloud.
În raport ne vom concentra în mod special pe reducerea latenței folosind exemplul infrastructurii Netflix. Să luăm în considerare, din punct de vedere practic, cum să abordăm procesele de proiectare, dezvoltare și operare a sistemelor complexe distribuite și să petrecem timp pe inovație și rezultate, mai degrabă decât să diagnosticăm problemele și defecțiunile operaționale.
În interiorul Netflix
Mii de dispozitive diferite acceptă aplicațiile Netflix. Sunt dezvoltate de patru echipe diferite, care realizează versiuni separate ale clientului pentru Android, iOS, TV și browsere web. Și depunem mult efort pentru îmbunătățirea și personalizarea experienței utilizatorului. Pentru a face acest lucru, rulăm sute de teste A/B în paralel.
Personalizarea este susținută de sute de microservicii din cloudul AWS, oferind date personalizate ale utilizatorilor, trimiterea interogărilor, telemetrie, Big Data și codificare. Vizualizarea traficului arată astfel:
În stânga este punctul de intrare, iar apoi traficul este distribuit între câteva sute de microservicii care sunt suportate de diferite echipe de backend.
O altă componentă importantă a infrastructurii noastre este Open Connect CDN, care furnizează conținut static utilizatorului final - videoclipuri, imagini, cod client etc. CDN-ul este localizat pe servere personalizate (OCA - Open Connect Appliance). În interior există matrice de unități SSD și HDD care rulează FreeBSD optimizat, cu NGINX și un set de servicii. Proiectăm și optimizăm componente hardware și software astfel încât un astfel de server CDN să poată trimite cât mai multe date utilizatorilor.
„Peretele” acestor servere la punctul de schimb de trafic Internet (Internet eXchange - IX) arată astfel:
Internet Exchange oferă furnizorilor de servicii Internet și furnizorilor de conținut capacitatea de a se „conecta” între ei pentru a schimba mai direct date pe Internet. Există aproximativ 70-80 de puncte Internet Exchange în întreaga lume unde sunt instalate serverele noastre și le instalăm și le menținem în mod independent:
În plus, oferim servere direct furnizorilor de internet, pe care le instalează în rețeaua lor, îmbunătățind localizarea traficului Netflix și calitatea streamingului pentru utilizatori:
Un set de servicii AWS este responsabil pentru trimiterea solicitărilor video de la clienți către serverele CDN, precum și pentru configurarea serverelor în sine - actualizarea conținutului, codul programului, setările etc. Pentru acesta din urmă, am construit și o rețea de coloană vertebrală care conectează serverele din punctele Internet Exchange cu AWS. Rețeaua backbone este o rețea globală de cabluri de fibră optică și routere pe care le putem proiecta și configura în funcție de nevoile noastre.
Pe , infrastructura noastră CDN furnizează aproximativ ⅛ din traficul de internet din lume în timpul orelor de vârf și ⅓ din traficul din America de Nord, unde Netflix a existat cel mai mult timp. Cifre impresionante, dar pentru mine una dintre cele mai uimitoare realizări este că întregul sistem CDN este dezvoltat și întreținut de o echipă de mai puțin de 150 de oameni.
Inițial, infrastructura CDN a fost concepută pentru a furniza date video. Cu toate acestea, de-a lungul timpului ne-am dat seama că îl putem folosi și pentru a optimiza cererile dinamice de la clienți în cloud-ul AWS.
Despre accelerarea Internetului
Astăzi, Netflix are 3 regiuni AWS, iar latența solicitărilor către cloud va depinde de cât de departe se află clientul de cea mai apropiată regiune. În același timp, avem multe servere CDN care sunt folosite pentru a furniza conținut static. Există vreo modalitate de a utiliza acest cadru pentru a accelera interogările dinamice? Cu toate acestea, din păcate, este imposibil să memorați aceste solicitări în cache - API-urile sunt personalizate și fiecare rezultat este unic.
Să facem un proxy pe serverul CDN și să începem să trimitem trafic prin el. Va fi mai rapid?
Material
Să ne amintim cum funcționează protocoalele de rețea. Astăzi, cel mai mare trafic de pe Internet folosește HTTP-urile, care depinde de protocoalele de nivel inferior TCP și TLS. Pentru ca un client să se conecteze la server, face o strângere de mână, iar pentru a stabili o conexiune securizată, clientul trebuie să schimbe mesaje cu serverul de trei ori și cel puțin încă o dată pentru a transfera date. Cu o latență per călătorie dus-întors (RTT) de 100 ms, ne-ar lua 400 ms pentru a primi primul bit de date:
Dacă plasăm certificatele pe serverul CDN, atunci timpul de strângere de mână între client și server poate fi redus semnificativ dacă CDN-ul este mai aproape. Să presupunem că latența la serverul CDN este de 30 ms. Apoi va dura 220 ms pentru a primi primul bit:
Dar avantajele nu se opresc aici. Odată ce o conexiune a fost stabilită, TCP mărește fereastra de congestie (cantitatea de informații pe care o poate transmite prin acea conexiune în paralel). Dacă un pachet de date este pierdut, atunci implementările clasice ale protocolului TCP (cum ar fi TCP New Reno) reduc „fereastra” deschisă la jumătate. Creșterea ferestrei de congestie și viteza de recuperare a acesteia de la pierdere depind din nou de întârzierea (RTT) la server. Dacă această conexiune ajunge doar până la serverul CDN, această recuperare va fi mai rapidă. În același timp, pierderea pachetelor este un fenomen standard, în special pentru rețelele wireless.
Lățimea de bandă a internetului poate fi redusă, mai ales în orele de vârf, din cauza traficului de la utilizatori, ceea ce poate duce la blocaje în trafic. Cu toate acestea, nu există nicio modalitate pe Internet de a acorda prioritate unor solicitări față de altele. De exemplu, acordați prioritate solicitărilor mici și sensibile la latență față de fluxurile de date „grele” care încarcă rețeaua. Cu toate acestea, în cazul nostru, a avea propria noastră rețea backbone ne permite să facem acest lucru pe o parte a căii de solicitare - între CDN și cloud și o putem configura complet. Vă puteți asigura că pachetele mici și sensibile la latență sunt prioritizate, iar fluxurile mari de date merg puțin mai târziu. Cu cât CDN-ul este mai aproape de client, cu atât eficiența este mai mare.
Protocoalele la nivel de aplicație (OSI Level 7) au, de asemenea, un impact asupra latenței. Noile protocoale, cum ar fi HTTP/2, optimizează performanța solicitărilor paralele. Cu toate acestea, avem clienți Netflix cu dispozitive mai vechi care nu acceptă noile protocoale. Nu toți clienții pot fi actualizați sau configurați optim. În același timp, între proxy-ul CDN și cloud există un control complet și capacitatea de a utiliza protocoale și setări noi, optime. Partea ineficientă cu protocoale vechi va funcționa doar între client și serverul CDN. Mai mult, putem face cereri multiplex pe o conexiune deja stabilită între CDN și cloud, îmbunătățind utilizarea conexiunii la nivel TCP:
Măsurăm
În ciuda faptului că teoria promite îmbunătățiri, nu ne grăbim imediat să lansăm sistemul în producție. În schimb, trebuie mai întâi să dovedim că ideea va funcționa în practică. Pentru a face acest lucru, trebuie să răspundeți la câteva întrebări:
- Viteză: va fi un proxy mai rapid?
- Încredere: Se va rupe mai des?
- Complexitate: cum se integrează cu aplicațiile?
- Costa: Cât costă implementarea unei infrastructuri suplimentare?
Să luăm în considerare în detaliu abordarea noastră de a evalua primul punct. Restul sunt tratate în mod similar.
Pentru a analiza viteza solicitărilor, ne dorim să obținem date pentru toți utilizatorii, fără a petrece mult timp pe dezvoltare și fără a întrerupe producția. Există mai multe abordări pentru aceasta:
- RUM sau măsurarea cererii pasive. Măsurăm timpul de execuție al solicitărilor curente de la utilizatori și asigurăm o acoperire completă a utilizatorilor. Dezavantajul este că semnalul nu este foarte stabil din cauza multor factori, de exemplu, datorită dimensiunilor diferitelor cereri, timpului de procesare pe server și client. În plus, nu puteți testa o nouă configurație fără efect în producție.
- Analize de laborator. Servere și infrastructură speciale care simulează clienți. Cu ajutorul lor efectuam testele necesare. În acest fel, obținem controlul deplin asupra rezultatelor măsurătorilor și un semnal clar. Dar nu există o acoperire completă a dispozitivelor și locațiilor utilizatorilor (în special cu un serviciu și suport la nivel mondial pentru mii de modele de dispozitive).
Cum poți combina avantajele ambelor metode?
Echipa noastră a găsit o soluție. Am scris o mică bucată de cod - un eșantion - pe care l-am integrat în aplicația noastră. Sondele ne permit să facem teste de rețea complet controlate de pe dispozitivele noastre. Funcționează așa:
- La scurt timp după încărcarea aplicației și finalizarea activității inițiale, rulăm sondele noastre.
- Clientul face o cerere către server și primește o „rețetă” pentru test. Rețeta este o listă de adrese URL la care trebuie făcută o solicitare HTTP(e). În plus, rețeta configurează parametrii de solicitare: întârzieri între solicitări, cantitatea de date solicitate, anteturi HTTP(e) etc. În același timp, putem testa mai multe rețete diferite în paralel - atunci când solicităm o configurație, determinăm aleatoriu ce rețetă să emitem.
- Ora de lansare a sondei este selectată pentru a nu intra în conflict cu utilizarea activă a resurselor de rețea pe client. În esență, ora este selectată când clientul nu este activ.
- După primirea rețetei, clientul face solicitări către fiecare dintre URL-uri, în paralel. Solicitarea către fiecare dintre adrese poate fi repetată - așa-numita. „pulsuri”. La primul puls, măsurăm cât timp a durat stabilirea unei conexiuni și descărcarea datelor. La al doilea impuls, măsurăm timpul necesar pentru încărcarea datelor printr-o conexiune deja stabilită. Înainte de a treia, putem seta o întârziere și măsura viteza de stabilire a unei reconectari etc.
În timpul testului, măsurăm toți parametrii pe care dispozitivul îi poate obține:
- timpul de solicitare DNS;
- Timpul de configurare a conexiunii TCP;
- Timp de configurare a conexiunii TLS;
- momentul primirii primului octet de date;
- timpul total de încărcare;
- codul rezultat al stării.
- După ce toate impulsurile s-au finalizat, eșantionul încarcă toate măsurătorile pentru analiză.
Punctele cheie sunt dependența minimă de logică pe client, procesarea datelor pe server și măsurarea cererilor paralele. Astfel, suntem capabili să izolăm și să testăm influența diferiților factori care afectează performanța interogărilor, să le variam într-o singură rețetă și să obținem rezultate de la clienți reali.
Această infrastructură s-a dovedit utilă pentru mai mult decât doar analiza performanței interogărilor. În prezent avem 14 rețete active, mai mult de 6000 de mostre pe secundă, primind date din toate colțurile pământului și acoperire completă a dispozitivului. Dacă Netflix ar cumpăra un serviciu similar de la o terță parte, ar costa milioane de dolari pe an, cu o acoperire mult mai proastă.
Testarea teoriei în practică: prototip
Cu un astfel de sistem, am putut evalua eficiența proxy-urilor CDN la latența la cerere. Acum ai nevoie de:
- creați un prototip proxy;
- plasați prototipul pe un CDN;
- stabiliți cum să direcționați clienții către un proxy pe un anumit server CDN;
- Comparați performanța cu solicitările din AWS fără un proxy.
Sarcina este de a evalua eficacitatea soluției propuse cât mai repede posibil. Am ales Go pentru a implementa prototipul datorită disponibilității unor biblioteci bune de rețea. Pe fiecare server CDN, am instalat proxy-ul prototip ca un binar static pentru a minimiza dependențele și a simplifica integrarea. În implementarea inițială, am folosit componente standard cât mai mult posibil și modificări minore pentru gruparea conexiunilor HTTP/2 și multiplexarea cererilor.
Pentru a echilibra regiunile AWS, am folosit o bază de date DNS geografică, aceeași folosită pentru echilibrarea clienților. Pentru a selecta un server CDN pentru client, folosim TCP Anycast pentru serverele din Internet Exchange (IX). În această opțiune, folosim o singură adresă IP pentru toate serverele CDN, iar clientul va fi direcționat către serverul CDN cu cel mai mic număr de hopuri IP. În serverele CDN instalate de furnizorii de internet (ISP), nu avem control asupra routerului pentru a configura TCP Anycast, așa că folosim , care direcționează clienții către furnizorii de internet pentru streaming video.
Deci, avem trei tipuri de căi de solicitare: către cloud prin Internet deschis, printr-un server CDN în IX sau printr-un server CDN situat la un furnizor de internet. Scopul nostru este să înțelegem care este calea mai bună și care este beneficiul unui proxy, în comparație cu modul în care solicitările sunt trimise în producție. Pentru a face acest lucru, folosim un sistem de eșantionare după cum urmează:
Fiecare dintre căi devine o țintă separată și ne uităm la timpul pe care îl avem. Pentru analiză, combinăm rezultatele proxy într-un singur grup (selectăm cel mai bun moment între proxy-urile IX și ISP) și le comparăm cu timpul solicitărilor către cloud fără un proxy:
După cum puteți vedea, rezultatele au fost mixte - în cele mai multe cazuri proxy-ul oferă o accelerare bună, dar există și un număr suficient de clienți pentru care situația se va înrăutăți semnificativ.
Drept urmare, am făcut câteva lucruri importante:
- Am evaluat performanța așteptată a solicitărilor de la clienți către cloud prin intermediul unui proxy CDN.
- Am primit date de la clienți reali, de pe toate tipurile de dispozitive.
- Ne-am dat seama că teoria nu a fost confirmată 100% și oferta inițială cu un proxy CDN nu ar funcționa pentru noi.
- Nu ne-am asumat riscuri - nu am schimbat configurațiile de producție pentru clienți.
- Nimic nu a fost spart.
Prototipul 2.0
Deci, înapoi la planșa de desen și repetați procesul din nou.
Ideea este că în loc să folosim un proxy 100%, vom determina cea mai rapidă cale pentru fiecare client și vom trimite cereri acolo - adică vom face ceea ce se numește client steering.
Cum să implementez acest lucru? Nu putem folosi logica din partea serverului, pentru că... Scopul este conectarea la acest server. Trebuie să existe o modalitate de a face acest lucru pe client. Și în mod ideal, faceți acest lucru cu o cantitate minimă de logică complexă, pentru a nu rezolva problema integrării cu un număr mare de platforme client.
Răspunsul este să folosești DNS. În cazul nostru, avem propria noastră infrastructură DNS și putem configura o zonă de domeniu pentru care serverele noastre vor fi autoritare. Funcționează așa:
- Clientul face o cerere către serverul DNS folosind o gazdă, de exemplu api.netflix.xom.
- Solicitarea ajunge la serverul nostru DNS
- Serverul DNS știe care cale este cea mai rapidă pentru acest client și emite adresa IP corespunzătoare.
Soluția are o complexitate suplimentară: furnizorii de DNS autoritari nu văd adresa IP a clientului și pot citi doar adresa IP a rezolutorului recursiv pe care îl folosește clientul.
Drept urmare, soluția noastră autoritara trebuie să ia o decizie nu pentru un client individual, ci pentru un grup de clienți bazat pe soluția recursiv.
Pentru a rezolva, folosim aceleași mostre, cumulăm rezultatele măsurătorilor de la clienți pentru fiecare dintre soluțiile recursive și decidem unde să trimitem acest grup de ei - un proxy prin IX folosind TCP Anycast, printr-un proxy ISP sau direct în cloud.
Obtinem urmatorul sistem:
Modelul de conducere DNS rezultat vă permite să direcționați clienții pe baza observațiilor istorice ale vitezei conexiunilor de la clienți la cloud.
Din nou, întrebarea este cât de eficient va funcționa această abordare? Pentru a răspunde, folosim din nou sistemul nostru de sonde. Prin urmare, configuram configurația prezentatorului, unde una dintre ținte urmează direcția de la direcția DNS, cealaltă merge direct în cloud (producția curentă).
Ca urmare, comparăm rezultatele și obținem o evaluare a eficacității:
Drept urmare, am învățat câteva lucruri importante:
- Am evaluat performanța așteptată a solicitărilor de la clienți către cloud folosind DNS Steering.
- Am primit date de la clienți reali, de pe toate tipurile de dispozitive.
- Eficacitatea ideii propuse a fost dovedită.
- Nu ne-am asumat riscuri - nu am schimbat configurațiile de producție pentru clienți.
- Nimic nu a fost spart.
Acum despre partea dificilă - o lansăm în producție
Partea ușoară s-a terminat acum - există un prototip funcțional. Acum partea grea este lansarea unei soluții pentru tot traficul Netflix, implementând la 150 de milioane de utilizatori, mii de dispozitive, sute de microservicii și un produs și o infrastructură în continuă schimbare. Serverele Netflix primesc milioane de solicitări pe secundă și este ușor să rupeți serviciul cu o acțiune neglijentă. În același timp, dorim să direcționăm dinamic traficul prin mii de servere CDN de pe Internet, unde ceva se schimbă și se rupe în mod constant și în cel mai inoportun moment.
Și cu toate acestea, echipa are 3 ingineri responsabili de dezvoltarea, implementarea și suportul complet al sistemului.
Prin urmare, vom continua să vorbim despre somn odihnitor și sănătos.
Cum să continui dezvoltarea și să nu-ți petreci tot timpul pe suport? Abordarea noastră se bazează pe 3 principii:
- Reducem amploarea potențială a defecțiunilor (raza exploziei).
- Ne pregătim pentru surprize - ne așteptăm să se rupă ceva, în ciuda testelor și experienței personale.
- Degradare grațioasă - dacă ceva nu funcționează bine, ar trebui să fie reparat automat, chiar dacă nu în cel mai eficient mod.
S-a dovedit că în cazul nostru, cu această abordare a problemei, putem găsi o soluție simplă și eficientă și putem simplifica semnificativ suportul sistemului. Ne-am dat seama că putem adăuga o mică bucată de cod la client și monitoriza erorile de solicitare a rețelei cauzate de probleme de conexiune. În cazul erorilor de rețea, facem o rezervă direct în cloud. Această soluție nu necesită efort semnificativ pentru echipele de clienți, dar reduce foarte mult riscul de avarii neașteptate și surprize pentru noi.
Bineînțeles, în ciuda retragerii, respectăm o disciplină clară în timpul dezvoltării:
- Test simplu.
- Testare A/B sau Canare.
- Lansare progresivă.
Cu mostre, abordarea a fost descrisă - modificările sunt mai întâi testate folosind o rețetă personalizată.
Pentru testarea Canary, trebuie să obținem perechi comparabile de servere pe care să putem compara modul în care funcționează sistemul înainte și după modificări. Pentru a face acest lucru, din numeroasele noastre site-uri CDN, selectăm perechi de servere care primesc trafic comparabil:
Apoi instalăm build-ul cu modificările pe serverul Canary. Pentru a evalua rezultatele, rulăm un sistem care compară aproximativ 100-150 de metrici cu un eșantion de servere de control:
Dacă testarea Canary are succes, atunci o lansăm treptat, în valuri. Nu actualizăm serverele de pe fiecare site în același timp - pierderea unui întreg site din cauza problemelor are un impact mai semnificativ asupra serviciului pentru utilizatori decât pierderea aceluiași număr de servere în locații diferite.
În general, eficacitatea și siguranța acestei abordări depind de cantitatea și calitatea valorilor colectate. Pentru sistemul nostru de accelerare a interogărilor, colectăm valori din toate componentele posibile:
- de la clienți - număr de sesiuni și solicitări, rate de rezervă;
- proxy - statistici privind numărul și timpul solicitărilor;
- DNS - numărul și rezultatele solicitărilor;
- cloud edge - numărul și timpul pentru procesarea cererilor în cloud.
Toate acestea sunt colectate într-o singură conductă și, în funcție de nevoi, decidem ce metrici să trimitem la analize în timp real și care la Elasticsearch sau Big Data pentru diagnostice mai detaliate.
Monitorizăm
În cazul nostru, facem modificări pe calea critică a cererilor dintre client și server. În același timp, numărul de componente diferite pe client, pe server și pe drumul prin Internet este enorm. Modificările la nivelul clientului și serverului apar în mod constant - în timpul muncii a zeci de echipe și schimbări naturale în ecosistem. Suntem la mijloc - atunci când diagnosticăm problemele, există șanse mari să fim implicați. Prin urmare, trebuie să înțelegem clar cum să definim, să colectăm și să analizăm valorile pentru a izola rapid problemele.
În mod ideal, acces complet la toate tipurile de valori și filtre în timp real. Dar există o mulțime de metrici, așa că se pune problema costului. În cazul nostru, separăm valorile și instrumentele de dezvoltare, după cum urmează:
Pentru a detecta și a identifica problemele, folosim propriul nostru sistem open-source în timp real и - pentru vizualizare. Stochează valorile agregate în memorie, este fiabil și se integrează cu sistemul de alertă. Pentru localizare și diagnosticare, avem acces la jurnalele de la Elasticsearch și Kibana. Pentru analiza statistică și modelare, folosim date mari și vizualizare în Tableau.
Se pare că această abordare este foarte greu de lucrat. Cu toate acestea, organizând ierarhic valorile și instrumentele, putem analiza rapid o problemă, determina tipul de problemă și apoi detaliem valorile detaliate. În general, petrecem aproximativ 1-2 minute pentru a identifica sursa defecțiunii. După aceasta, lucrăm cu o echipă specifică pentru diagnosticare - de la zeci de minute la câteva ore.
Chiar dacă diagnosticul se face rapid, nu vrem să se întâmple des. În mod ideal, vom primi o alertă critică numai atunci când există un impact semnificativ asupra serviciului. Pentru sistemul nostru de accelerare a interogărilor, avem doar 2 alerte care vor notifica:
- Client Fallback Procent - evaluarea comportamentului clientului;
- procent erori de sondă - date de stabilitate ale componentelor rețelei.
Aceste alerte critice monitorizează dacă sistemul funcționează pentru majoritatea utilizatorilor. Ne uităm la câți clienți au folosit alternativa dacă nu au putut obține accelerarea cererii. Avem în medie mai puțin de 1 alertă critică pe săptămână, chiar dacă există o mulțime de schimbări în sistem. De ce este suficient pentru noi?
- Există un client de rezervă dacă proxy-ul nostru nu funcționează.
- Există un sistem automat de direcție care răspunde la probleme.
Mai multe detalii despre acesta din urmă. Sistemul nostru de probă și sistemul de determinare automată a căii optime pentru solicitările de la client către cloud, ne permite să facem față automat unor probleme.
Să revenim la configurația noastră eșantion și la 3 categorii de căi. Pe lângă timpul de încărcare, ne putem uita la faptul livrării în sine. Dacă nu a fost posibilă încărcarea datelor, atunci analizând rezultatele de-a lungul diferitelor căi, putem determina unde și ce s-a rupt și dacă le putem remedia automat prin schimbarea căii de solicitare.
Exemple:
Acest proces poate fi automatizat. Includeți-l în sistemul de direcție. Și învață-l să răspundă la problemele de performanță și fiabilitate. Dacă ceva începe să se spargă, reacționează dacă există o opțiune mai bună. În același timp, o reacție imediată nu este critică, datorită recurgerii la clienți.
Astfel, principiile suportului sistemului pot fi formulate după cum urmează:
- reducerea amplorii defecțiunilor;
- colectarea valorilor;
- Reparăm automat defecțiunile dacă putem;
- dacă nu se poate, vă anunțăm;
- Lucrăm la tablouri de bord și la un set de instrumente de triaj pentru un răspuns rapid.
Lecții învățate
Nu este nevoie de mult timp pentru a scrie un prototip. În cazul nostru, a fost gata după 4 luni. Cu el am primit noi metrici, iar la 10 luni de la începerea dezvoltării am primit primul trafic de producție. Apoi a început munca plictisitoare și foarte dificilă: produceți treptat și scalați sistemul, migrați traficul principal și învățați din greșeli. Cu toate acestea, acest proces eficient nu va fi liniar - în ciuda tuturor eforturilor, totul nu poate fi prezis. Este mult mai eficient să repetați rapid și să răspundeți la date noi.
Pe baza experienței noastre, vă putem recomanda următoarele:
- Nu ai încredere în intuiția ta.
Intuiția noastră ne-a eșuat constant, în ciuda experienței vaste a membrilor echipei noastre. De exemplu, am prezis incorect accelerarea așteptată din utilizarea unui proxy CDN sau comportamentul TCP Anycast.
- Obțineți date din producție.
Este important să obțineți acces la cel puțin o cantitate mică de date de producție cât mai repede posibil. Este aproape imposibil să obțineți numărul de cazuri unice, configurații și setări în condiții de laborator. Accesul rapid la rezultate vă va permite să aflați rapid despre potențialele probleme și să le luați în considerare în arhitectura sistemului.
- Nu urmați sfaturile și rezultatele altora - colectați-vă propriile date.
Urmați principiile pentru colectarea și analiza datelor, dar nu acceptați orbește rezultatele și declarațiile altor persoane. Numai tu poți ști exact ce funcționează pentru utilizatorii tăi. Sistemele și clienții dvs. pot fi semnificativ diferite de alte companii. Din fericire, instrumentele de analiză sunt acum disponibile și ușor de utilizat. Este posibil ca rezultatele pe care le obțineți să nu fie cele susținute de Netflix, Facebook, Akamai și alte companii. În cazul nostru, performanța TLS, HTTP2 sau a statisticilor privind solicitările DNS diferă de rezultatele Facebook, Uber, Akamai - deoarece avem dispozitive, clienți și fluxuri de date diferite.
- Nu urmați în mod inutil tendințele modei și evaluați eficacitatea.
Începe simplu. Este mai bine să faci un sistem simplu de lucru într-un timp scurt decât să petreci o cantitate imensă de timp dezvoltând componente de care nu ai nevoie. Rezolvați sarcini și probleme care contează pe baza măsurătorilor și rezultatelor dvs.
- Pregătește-te pentru noi aplicații.
La fel cum este dificil să prezici toate problemele, este dificil să prezici în avans beneficiile și aplicațiile. Urmăriți-vă de la startup-uri - capacitatea lor de a se adapta la condițiile clienților. În cazul dvs., puteți descoperi noi probleme și soluțiile lor. În proiectul nostru, ne-am stabilit un obiectiv de a reduce latența solicitărilor. Cu toate acestea, în timpul analizei și discuțiilor, ne-am dat seama că putem folosi și servere proxy:
- pentru a echilibra traficul în regiunile AWS și a reduce costurile;
- pentru a modela stabilitatea CDN;
- pentru a configura DNS;
- pentru a configura TLS/TCP.
Concluzie
În raport, am descris modul în care Netflix rezolvă problema accelerării cererilor de internet între clienți și cloud. Cum colectăm date utilizând un sistem de eșantionare asupra clienților și utilizăm datele istorice colectate pentru a direcționa cererile de producție de la clienți prin cea mai rapidă cale de pe Internet. Cum folosim principiile protocoalelor de rețea, infrastructura noastră CDN, rețeaua principală și serverele DNS pentru a realiza această sarcină.
Cu toate acestea, soluția noastră este doar un exemplu al modului în care noi, cei de la Netflix, am implementat un astfel de sistem. Ce a funcționat pentru noi. Partea aplicată a raportului meu pentru dumneavoastră este principiile de dezvoltare și sprijin pe care le urmăm și obținem rezultate bune.
Soluția noastră la problemă poate să nu vă convină. Cu toate acestea, teoria și principiile de proiectare rămân, chiar dacă nu aveți propria infrastructură CDN, sau dacă aceasta diferă semnificativ de a noastră.
Importanta vitezei cererilor de afaceri ramane de asemenea importanta. Și chiar și pentru un serviciu simplu trebuie să faci o alegere: între furnizorii de cloud, locația serverului, furnizorii CDN și DNS. Alegerea dvs. va influența eficiența interogărilor de pe Internet pentru clienții dvs. Și este important pentru tine să măsori și să înțelegi această influență.
Începeți cu soluții simple, aveți grijă de modul în care schimbați produsul. Învățați pe măsură ce mergeți și îmbunătățiți sistemul pe baza datelor de la clienți, infrastructura și afacerea dvs. Gândiți-vă la posibilitatea unor defecțiuni neașteptate în timpul procesului de proiectare. Și apoi vă puteți accelera procesul de dezvoltare, îmbunătăți eficiența soluției, evita povara inutilă de asistență și dormi liniștit.
În acest an în format online. Puteți pune întrebări unuia dintre părinții DevOps, însuși John Willis!
Sursa: www.habr.com