Netflix ass de Leader am Internet Fernsehmarkt - d'Firma déi dëst Segment erstallt an aktiv entwéckelt. Netflix ass bekannt net nëmme fir säin extensiv Katalog vu Filmer an Fernsehserie verfügbar aus bal all Eck vum Planéit an all Apparat mat engem Display, awer och fir seng zouverlässeg Infrastruktur an eenzegaarteg Ingenieurskultur.
E kloert Beispill vun der Netflix Approche fir komplex Systemer z'entwéckelen an z'ënnerstëtzen gouf bei DevOops 2019 presentéiert - Direkter vun Entwécklung bei Netflix. Graduéierter vun der Fakultéit fir Computational Mathematik a Mathematik vun der Nizhny Novgorod State University. Lobachevsky, Sergey ee vun den éischten Ingenieuren am Open Connect - CDN Team bei Netflix. Hien huet Systemer fir d'Iwwerwaachung an d'Analyse vun Videodaten gebaut, e populäre Service lancéiert fir d'Internetverbindungsgeschwindegkeet FAST.com ze bewäerten, a fir déi lescht Jore schafft un der Optimisatioun vun Internet Ufroen, sou datt d'Netflix Applikatioun sou séier wéi méiglech fir d'Benotzer funktionnéiert.
De Rapport krut déi bescht Kritik vun Konferenz Participanten, a mir hunn eng Text Versioun fir Iech virbereet.
A sengem Bericht huet de Sergei am Detail geschwat
- iwwer wat d'Verspéidung vun den Internet Ufroen tëscht dem Client an dem Server beaflosst;
- wéi dës Retard ze reduzéieren;
- wéi Feeler-tolerant Systemer ze designen, erhalen an iwwerwaachen;
- wéi Resultater a kuerzer Zäit ze erreechen, a mat minimale Risiko fir d'Geschäft;
- wéi Dir Resultater analyséiert a vu Feeler léiert.
Äntwerten op dës Froen sinn net nëmme gebraucht vun deenen, déi a grousse Firmen schaffen.
Déi presentéiert Prinzipien an Technike solle vu jidderengem bekannt a praktizéiert ginn, deen Internetprodukter entwéckelt an ënnerstëtzt.
Als nächst ass d'Erzielung aus der Perspektiv vum Spriecher.
D'Wichtegkeet vun der Internetgeschwindegkeet
D'Geschwindegkeet vun den Internet Ufroen ass direkt mat Geschäfter verbonnen. Betruecht d'Akaafsindustrie: Amazon am Joer 2009 datt eng 100ms Verspéidung zu engem Verloscht vun 1% vum Verkaf resultéiert.
Et gi méi a méi mobilen Apparater, gefollegt vu mobilen Siten an Uwendungen. Wann Är Säit méi laang wéi 3 Sekonnen dauert fir ze lueden, verléiert Dir ongeféier d'Halschent vun Äre Benotzer. MAT Google berücksichtegt d'Laaschtgeschwindegkeet vun Ärer Säit an de Sichresultater: wat méi séier d'Säit ass, wat méi héich seng Positioun am Google ass.
D'Verbindungsgeschwindegkeet ass och wichteg a Finanzinstituter wou latency kritesch ass. Am Joer 2015, Hibernia Networks e Kabel vun $ 400 Milliounen tëscht New York a London fir d'Latenz tëscht de Stied ëm 6ms ze reduzéieren. Stellt Iech vir $ 66 Millioune fir 1 MS Latenzreduktioun!
Nëmmen , Verbindungsgeschwindegkeet iwwer 5 Mbit/s beaflossen net méi direkt d'Laaschtgeschwindegkeet vun enger typescher Websäit. Wéi och ëmmer, et gëtt eng linear Relatioun tëscht Verbindungslatenz a Säit Luedegeschwindegkeet:
Wéi och ëmmer, Netflix ass keen typesche Produkt. Den Impakt vun Latenz a Geschwindegkeet op de Benotzer ass en aktiven Beräich vun der Analyse an der Entwécklung. Et gëtt Applikatioun Luede an Inhalt Selektioun déi op Latenz hänkt, awer Luede statesch Elementer a Streaming hänkt och vun der Verbindungsgeschwindegkeet of. D'Analyse an Optimisatioun vun de Schlësselfaktoren déi d'Benotzererfarung beaflossen ass en aktiven Entwécklungsberäich fir verschidden Teams bei Netflix. Ee vun den Ziler ass d'Latenz vun Ufroen tëscht Netflix Apparater an der Cloud Infrastruktur ze reduzéieren.
Am Bericht konzentréiere mir eis speziell op d'Reduktioun vun der latency mam Beispill vun der Netflix Infrastruktur. Loosst eis aus enger praktescher Siicht kucken wéi d'Prozesser vum Design, Entwécklung an Operatioun vu komplexe verdeelte Systemer unzegoen an Zäit op Innovatioun a Resultater verbréngen, anstatt operationell Probleemer an Decompte ze diagnostizéieren.
Bannen Netflix
Dausende vu verschiddenen Apparater ënnerstëtzen Netflix Apps. Si gi vu véier verschiddenen Teams entwéckelt, déi separat Versioune vum Client fir Android, iOS, TV a Webbrowser maachen. A mir verbréngen vill Effort fir d'Benotzererfarung ze verbesseren an ze personaliséieren. Fir dëst ze maachen, lafe mir Honnerte vun A / B Tester parallel.
Personaliséierung gëtt vun Honnerte vu Mikroservicer an der AWS Cloud ënnerstëtzt, déi personaliséiert Benotzerdaten, Ufroverschécken, Telemetrie, Big Data a Kodéierung ubidden. Traffic Visualiséierung gesäit esou aus:
Op der lénker Säit ass den Entréespunkt, an da gëtt de Verkéier ënner e puer honnert Mikroservicer verdeelt, déi vu verschiddene Backend-Teams ënnerstëtzt ginn.
En anere wichtege Bestanddeel vun eiser Infrastruktur ass den Open Connect CDN, deen statesche Inhalt un den Endbenotzer liwwert - Videoen, Biller, Clientcode, etc. Den CDN läit op personaliséierte Serveren (OCA - Open Connect Appliance). Bannen do sinn Arrays vun SSD an HDD fiert Lafen optimiséiert FreeBSD, mat NGINX an eng Rei vu Servicer. Mir designen an optimiséieren Hardware a Software Komponenten sou datt esou en CDN Server sou vill Donnéeë wéi méiglech un d'Benotzer schécken kann.
D'Mauer vun dëse Serveren um Internetverkéieraustauschpunkt (Internet eXchange - IX) gesäit esou aus:
Internet Exchange bitt d'Fäegkeet fir Internetservicer an Inhaltsanbieter mateneen ze "verbinden" fir méi direkt Daten um Internet auszetauschen. Et gi ongeféier 70-80 Internet Exchange Punkte ronderëm d'Welt wou eis Server installéiert sinn, a mir installéieren an ënnerhalen se onofhängeg:
Zousätzlech liwwere mir och Serveren direkt un Internet Ubidder, déi se an hirem Netz installéieren, d'Lokaliséierung vum Netflix Traffic an d'Qualitéit vum Streaming fir Benotzer verbesseren:
Eng Rei vun AWS Servicer ass verantwortlech fir Videoufroe vu Clienten op CDN Serveren ze verschécken, souwéi d'Servere selwer ze konfiguréieren - Inhalt aktualiséieren, Programmcode, Astellungen, etc. Fir déi lescht hu mir och e Backbone-Netzwierk gebaut, deen Serveren an Internet Exchange Points mat AWS verbënnt. De Backbone Reseau ass e globalt Netzwierk vu Glasfaserkabelen a Router, déi mir op eise Bedierfnesser designen a konfiguréieren.
By , liwwert eis CDN Infrastruktur ongeféier ⅛ vum Internetverkéier op der Welt während Spëtzestonnen an ⅓ vum Traffic an Nordamerika, wou Netflix am längste war. Beandrockend Zuelen, awer fir mech ass ee vun den erstaunlechsten Erreechen datt de ganze CDN System vun engem Team vu manner wéi 150 Leit entwéckelt an erhale gëtt.
Am Ufank gouf d'CDN Infrastruktur entwéckelt fir Videodaten ze liwweren. Wéi och ëmmer, mat der Zäit hu mir gemierkt datt mir et och benotze kënnen fir dynamesch Ufroe vu Clienten an der AWS Cloud ze optimiséieren.
Iwwer Internet Beschleunegung
Haut huet Netflix 3 AWS Regiounen, an d'Latenz vun Ufroen un d'Wollek hänkt dovun of wéi wäit de Client vun der nooste Regioun ass. Zur selwechter Zäit hu mir vill CDN Server déi benotzt gi fir statesch Inhalt ze liwweren. Gëtt et e Wee fir dëse Kader ze benotzen fir dynamesch Ufroen ze beschleunegen? Wéi och ëmmer, leider ass et onméiglech dës Ufroen ze cache - APIe si personaliséiert an all Resultat ass eenzegaarteg.
Loosst eis e Proxy um CDN Server maachen a fänken de Traffic duerch ze schécken. Wäert et méi séier sinn?
Material
Loosst eis drun erënneren wéi Netzwierkprotokoller funktionnéieren. Haut benotzt de meeschte Verkéier um Internet HTTPs, wat hänkt vun den ënneschten Schichtprotokollen TCP an TLS of. Fir e Client un de Server ze verbannen, mécht en Handshake, a fir eng sécher Verbindung opzebauen, muss de Client dräimol Messagen mam Server austauschen an op d'mannst nach eng Kéier fir Daten ze transferéieren. Mat enger Latenz pro Ronn Rees (RTT) vun 100 ms, géif et eis 400 ms huelen fir déi éischt Bit vun Daten ze kréien:
Wa mir d'Zertifikater op den CDN Server setzen, da kann d'Handshakezäit tëscht dem Client an dem Server wesentlech reduzéiert ginn wann den CDN méi no ass. Loosst eis unhuelen datt d'Latenz op den CDN Server 30ms ass. Dann dauert et 220 ms fir dat éischt Bit ze kréien:
Awer d'Virdeeler enden net do. Wann eng Verbindung etabléiert ass, erhéicht TCP d'Staufenster (d'Quantitéit un Informatioun déi se iwwer dës Verbindung parallel iwwerdroe kann). Wann en Datepaket verluer geet, da reduzéieren klassesch Implementatioune vum TCP Protokoll (wéi TCP New Reno) déi oppe "Fënster" ëm d'Halschent. De Wuesstum vun der Staufenster, an d'Geschwindegkeet vu senger Erhuelung vum Verloscht hänkt erëm vun der Verzögerung (RTT) op de Server of. Wann dës Verbindung nëmmen esou wäit wéi den CDN Server geet, wäert dës Erhuelung méi séier sinn. Zur selwechter Zäit ass Paketverloscht e Standard Phänomen, besonnesch fir drahtlose Netzwierker.
D'Internetbandbreedung kann reduzéiert ginn, besonnesch an de Spëtzestonnen, wéinst Verkéier vu Benotzer, wat zu Stau féieren kann. Wéi och ëmmer, et gëtt kee Wee um Internet fir e puer Ufroe virun aneren Prioritéit ze ginn. Zum Beispill gitt Prioritéit fir kleng a latency-sensibel Ufroen iwwer "schwéier" Datestroum, déi d'Netzwierk lueden. Wéi och ëmmer, an eisem Fall, mat eisem eegene Backbone-Netzwierk, erlaabt eis dëst op en Deel vum Ufrowee ze maachen - tëscht der CDN an der Wollek, a mir kënnen et voll konfiguréieren. Dir kënnt sécherstellen datt kleng a latency-sensibel Päck prioritär prioritär sinn, a grouss Datefloss ginn e bësse méi spéit. Wat de CDN méi no beim Client ass, wat méi Effizienz ass.
Applikatioun Niveau Protokoller (OSI Level 7) hunn och en Impakt op latency. Nei Protokoller wéi HTTP/2 optimiséieren d'Performance vu parallele Ufroen. Wéi och ëmmer, mir hunn Netflix Cliente mat méi alen Apparater déi déi nei Protokoller net ënnerstëtzen. Net all Cliente kënnen aktualiséiert oder optimal konfiguréiert ginn. Zur selwechter Zäit tëscht dem CDN Proxy an der Wollek gëtt et komplett Kontroll an d'Fäegkeet fir nei optimal Protokoller an Astellungen ze benotzen. Den ineffektiven Deel mat alen Protokoller funktionnéiert nëmmen tëscht dem Client an dem CDN Server. Ausserdeem kënne mir Multiplex Ufroen op enger scho etabléierter Verbindung tëscht der CDN an der Wollek maachen, d'Verbindungsnotzung um TCP Niveau verbesseren:
Mir moossen
Trotz der Tatsaach, datt d'Theorie Verbesserungen versprécht, presséiert mir net direkt de System an der Produktioun ze starten. Amplaz musse mir als éischt beweisen datt d'Iddi an der Praxis funktionnéiert. Fir dëst ze maachen, musst Dir e puer Froen beäntweren:
- Speed: wäert e Proxy méi séier sinn?
- Zuverlässegkeet: Breet et méi dacks?
- Komplexitéit: wéi mat Applikatiounen ze integréieren?
- Käschte vun: Wéi vill kascht et fir zousätzlech Infrastrukturen anzesetzen?
Loosst eis am Detail eis Approche fir den éischte Punkt ze bewäerten. De Rescht gëtt op eng ähnlech Manéier behandelt.
Fir d'Geschwindegkeet vun Ufroen ze analyséieren, wëlle mir Daten fir all Benotzer kréien, ouni vill Zäit op Entwécklung ze verbréngen an ouni d'Produktioun ze briechen. Et gi verschidde Approche fir dëst:
- RUM, oder passiv Ufro Mooss. Mir moossen d'Ausféierungszäit vun aktuellen Ufroe vun de Benotzer a suerge fir voll Benotzerdeckung. Den Nodeel ass datt d'Signal net ganz stabil ass wéinst ville Faktoren, zum Beispill wéinst verschiddene Ufrogréissten, Veraarbechtungszäit um Server a Client. Zousätzlech kënnt Dir eng nei Konfiguratioun ouni Effekt an der Produktioun testen.
- Laboratoire Tester. Spezial Serveren an Infrastruktur déi Clienten simuléieren. Mat hirer Hëllef maache mir déi néideg Tester. Esou kréie mir voll Kontroll iwwer d'Messresultater an e kloert Signal. Awer et gëtt keng komplett Ofdeckung vun Apparater a Benotzerplazen (besonnesch mat engem weltwäite Service an Ënnerstëtzung fir Dausende vun Apparatmodeller).
Wéi kënnt Dir d'Virdeeler vu béide Methoden kombinéieren?
Eis Equipe huet eng Léisung fonnt. Mir hunn e klengt Stéck Code geschriwwen - eng Probe - déi mir an eiser Applikatioun agebaut hunn. Sonde erlaben eis voll kontrolléiert Netzwierk Tester vun eisen Apparater ze maachen. Et funktionnéiert esou:
- Kuerz no der Luede vun der Applikatioun an der Ofschloss vun der initialer Aktivitéit, lafe mir eis Sonden.
- De Client mécht eng Ufro un de Server a kritt e "Rezept" fir den Test. D'Rezept ass eng Lëscht vun URLen op déi eng HTTP(en) Ufro muss gemaach ginn. Zousätzlech konfiguréiert d'Rezept Ufroparameter: Verspéidungen tëscht Ufroen, Betrag vun ugefrote Donnéeën, HTTP(en) Header, etc. Zur selwechter Zäit kënne mir e puer verschidde Rezepter parallel testen - wann Dir eng Konfiguratioun ufroen, bestëmmen mir zoufälleg wéi ee Rezept erausginn.
- D'Sondstartzäit gëtt ausgewielt fir net mat der aktiver Notzung vun Netzwierkressourcen um Client ze konflikt. Wesentlech gëtt d'Zäit ausgewielt wann de Client net aktiv ass.
- Nom Rezept kritt de Client Ufroe fir jiddereng vun den URLen parallel. D'Ufro un jiddereng vun den Adressen kann widderholl ginn - de sougenannte. "Puls". Um éischte Puls moosse mir wéi laang et gedauert huet fir eng Verbindung opzebauen an Daten erofzelueden. Um zweete Puls moosse mir d'Zäit déi et brauch fir Daten iwwer eng schonn etabléiert Verbindung ze lueden. Virun der drëtter kënne mir e Verzögerung setzen an d'Geschwindegkeet moossen fir eng Reconnection z'etabléieren, etc.
Wärend dem Test moosse mir all d'Parameteren déi den Apparat ka kréien:
- DNS Ufro Zäit;
- TCP Verbindung Setup Zäit;
- TLS Verbindung Setup Zäit;
- Zäit fir den éischte Byte vun Daten ze kréien;
- total Luede Zäit;
- Status Resultat Code.
- Nodeems all Impulser ofgeschloss sinn, lued d'Probe all Miessunge fir d'Analyse.
D'Schlësselpunkte sinn minimal Ofhängegkeet vun der Logik vum Client, Datenveraarbechtung um Server an d'Miessung vu parallele Ufroen. Sou kënne mir den Afloss vu verschiddene Faktoren isoléieren an testen, déi d'Ufroleistung beaflossen, se an engem eenzege Rezept variéieren an Resultater vun echte Clienten kréien.
Dës Infrastruktur huet bewisen nëtzlech fir méi wéi just Ufro Leeschtung Analyse. De Moment hu mir 14 aktiv Rezepter, méi wéi 6000 Proben pro Sekonn, déi Daten aus allen Ecker vun der Äerd a voller Apparatofdeckung kréien. Wann Netflix en ähnlechen Service vun enger Drëtter kaaft, da géif et Millioune Dollar pro Joer kaschten, mat vill méi schlechter Ofdeckung.
Testtheorie an der Praxis: Prototyp
Mat esou engem System konnte mir d'Effizienz vun CDN Proxyen op Ufro latency evaluéieren. Elo braucht Dir:
- e Prototyp Prototyp erstellen;
- Plaz de Prototyp op engem CDN;
- bestëmmen wéi Clienten op e Proxy op engem spezifeschen CDN Server direkten;
- Vergläicht Leeschtung mat Ufroen an AWS ouni Proxy.
D'Aufgab ass d'Effektivitéit vun der proposéierter Léisung sou séier wéi méiglech ze evaluéieren. Mir hunn Go gewielt fir de Prototyp ëmzesetzen wéinst der Disponibilitéit vu gudde Netzwierkbibliothéiken. Op all CDN Server hu mir de Prototyp Proxy als statesche Binär installéiert fir Ofhängegkeeten ze minimiséieren an d'Integratioun ze vereinfachen. An der initialer Ëmsetzung hu mir Standardkomponenten sou vill wéi méiglech benotzt a kleng Ännerungen fir HTTP/2 Verbindungspooling an Ufro Multiplexing.
Fir tëscht AWS Regiounen ze balancéieren, hu mir eng geographesch DNS Datebank benotzt, déiselwecht déi benotzt gouf fir Clienten ze balanséieren. Fir e CDN Server fir de Client ze wielen, benotze mir TCP Anycast fir Serveren am Internet Exchange (IX). An dëser Optioun benotze mir eng IP Adress fir all CDN Server, an de Client gëtt op den CDN Server mat der mannsten Unzuel vun IP Hopfen geleet. An CDN Serveren installéiert vun Internet Ubidder (ISPs), hu mir keng Kontroll iwwer de Router fir TCP Anycast ze konfiguréieren, also benotze mir , déi Clienten un Internet Ubidder fir Video Streaming riicht.
Also, mir hunn dräi Aarte vun Ufro Weeër: an d'Wollek iwwer den oppenen Internet, iwwer en CDN Server am IX, oder iwwer en CDN Server bei engem Internet Provider. Eist Zil ass et ze verstoen wéi eng Manéier besser ass, a wat de Virdeel vun engem Proxy ass, am Verglach mat wéi Ufroe fir d'Produktioun geschéckt ginn. Fir dëst ze maachen, benotze mir e Samplingsystem wéi follegt:
Jiddereng vun de Weeër gëtt eng separat Zil, a mir kucken op der Zäit mir krut. Fir d'Analyse kombinéiere mir d'Proxyresultater an eng Grupp (wielt déi bescht Zäit tëscht IX an ISP Proxyen), a vergläicht se mat der Zäit vun Ufroen un d'Wollek ouni Proxy:
Wéi Dir gesitt, sinn d'Resultater gemëscht - an de meeschte Fäll gëtt de Proxy e gudde Geschwindegkeet, awer et ginn och eng genuch Zuel vu Clienten fir déi d'Situatioun wesentlech verschlechtert.
Als Resultat hu mir e puer wichteg Saachen gemaach:
- Mir hunn d'erwaart Leeschtung vun Ufroe vu Clienten op d'Wollek iwwer e CDN Proxy bewäert.
- Mir kruten Daten vun echte Clienten, vun all Typ vun Apparater.
- Mir hu gemierkt datt d'Theorie net 100% bestätegt war an d'initial Offer mat engem CDN Proxy net fir eis funktionnéiert.
- Mir hunn keng Risiken geholl - mir hunn d'Produktiounskonfiguratioune fir Clienten net geännert.
- Näischt war gebrach.
Prototyp 2.0
Also, zréck op d'Zeechnenbrett a widderhuelen de Prozess nach eng Kéier.
D'Iddi ass, datt amplaz vun engem benotzen 100% Proxy, wäerte mir déi schnellsten Wee fir all Client bestëmmen, a mir wäerten Ufroen do schécken - dat ass, mir wäerten maachen wat Client Steering genannt gëtt.
Wéi dëst ëmzesetzen? Mir kënnen d'Logik net op der Serversäit benotzen, well ... D'Zil ass mat dësem Server ze verbannen. Et muss e Wee sinn fir dëst op de Client ze maachen. An am Idealfall, maacht dat mat engem Minimum vu komplexer Logik, fir net d'Fro vun der Integratioun mat enger grousser Zuel vu Clientplattformen ze léisen.
D'Äntwert ass DNS ze benotzen. An eisem Fall hu mir eis eegen DNS Infrastruktur, a mir kënnen eng Domain Zone astellen, fir déi eis Serveren autoritär sinn. Et funktionnéiert esou:
- De Client mécht eng Ufro un den DNS-Server mat engem Host, zum Beispill api.netflix.xom.
- D'Ufro kënnt op eisen DNS Server
- Den DNS-Server weess wéi ee Wee fir dëse Client am schnellsten ass an déi entspriechend IP Adress erausginn.
D'Léisung huet eng zousätzlech Komplexitéit: autoritär DNS Ubidder gesinn d'IP Adress vum Client net a kënnen nëmmen d'IP Adress vum rekursive Resolver liesen deen de Client benotzt.
Als Resultat muss eisen autoritäre Resolver eng Entscheedung treffen net fir en individuellen Client, mee fir eng Grupp vu Clienten op Basis vum rekursive Resolver.
Fir ze léisen, benotze mir déiselwecht Proben, aggregéiert d'Messresultater vu Cliente fir jiddereng vun de rekursive Resolveren an entscheeden wou dës Grupp vun hinnen ze schécken - e Proxy duerch IX mat TCP Anycast, duerch en ISP Proxy, oder direkt an d'Wollek.
Mir kréien de folgende System:
De resultéierende DNS Lenkungsmodell erlaabt Iech Clienten op Basis vun historeschen Observatioune vun der Geschwindegkeet vun de Verbindunge vu Clienten op d'Wollek ze dirigéieren.
Nach eng Kéier ass d'Fro wéi effektiv dës Approche funktionnéiert? Fir ze beäntweren, benotze mir erëm eise Sondesystem. Dofir konfiguréiere mir d'Presentatorkonfiguratioun, wou ee vun den Ziler d'Richtung vun der DNS-Steering follegt, deen aneren direkt an d'Wollek (aktuell Produktioun) geet.
Als Resultat vergläiche mir d'Resultater a kréien eng Bewäertung vun der Effektivitéit:
Als Resultat hu mir e puer wichteg Saachen geléiert:
- Mir hunn d'erwaart Leeschtung vun Ufroe vu Clienten op d'Wollek mat DNS Steering bewäert.
- Mir kruten Daten vun echte Clienten, vun all Typ vun Apparater.
- D'Effektivitéit vun der proposéierter Iddi gouf bewisen.
- Mir hunn keng Risiken geholl - mir hunn d'Produktiounskonfiguratioune fir Clienten net geännert.
- Näischt war gebrach.
Elo iwwer de schwéieren Deel - mir starten et an der Produktioun
Den einfachen Deel ass elo eriwwer - et gëtt e funktionnéierende Prototyp. Elo lancéiert den haarden Deel eng Léisung fir den ganzen Netflix Traffic, deployéiert op 150 Millioune Benotzer, Dausende vun Apparater, Honnerte vu Mikroservicer, an en ëmmer verännert Produkt an Infrastruktur. Netflix Serveren kréien Millioune Ufroen pro Sekonn, an et ass einfach de Service mat suergfälteg Handlung ze briechen. Zur selwechter Zäit wëlle mir de Traffic dynamesch duerch Dausende vun CDN Serveren um Internet verleeden, wou eppes ännert a stänneg an am onopportune Moment brécht.
A mat all deem huet d'Team 3 Ingenieuren verantwortlech fir d'Entwécklung, Deployment a voll Ënnerstëtzung vum System.
Dofir wäerte mir weider iwwer erhuelsamen a gesonde Schlof schwätzen.
Wéi weider Entwécklung an net all Är Zäit op Ënnerstëtzung verbréngen? Eis Approche baséiert op 3 Prinzipien:
- Mir reduzéieren d'potenziell Skala vun Decompte (Sprengradius).
- Mir preparéieren eis op Iwwerraschungen - mir erwaarden datt eppes brécht, trotz Testen a perséinlecher Erfahrung.
- Graceful Degradatioun - wann eppes net richteg funktionnéiert, soll et automatesch fixéiert ginn, och wann net op déi effizient Manéier.
Et huet sech erausgestallt datt an eisem Fall, mat dëser Approche zum Problem, mir eng einfach an effektiv Léisung fannen an d'Systemsupport wesentlech vereinfachen. Mir hu gemierkt datt mir e klengt Stéck Code fir de Client addéiere kënnen an iwwerwaachen fir Netzwierkerfrofehler verursaacht duerch Verbindungsproblemer. Am Fall vun Netzwierkfehler maache mir e Réckfall direkt an d'Wollek. Dës Léisung erfuerdert kee wesentlechen Effort fir Clientéquipen, awer reduzéiert de Risiko vun onerwaarten Decompte an Iwwerraschungen staark fir eis.
Natierlech, trotz dem Réckfall, verfollege mir trotzdem eng kloer Disziplin wärend der Entwécklung:
- Prouf Test.
- A / B Testen oder Kanaren.
- Progressiv Ausféierung.
Mat Proben ass d'Approche beschriwwe ginn - Ännerungen ginn als éischt mat engem personaliséierte Rezept getest.
Fir Kanaresch Tester musse mir vergläichbar Pairen vu Serveren kréien, op deenen mir kënne vergläichen wéi de System virun an no den Ännerungen funktionnéiert. Fir dëst ze maachen, vun eise villen CDN Sites, wielt mir Pairen vu Serveren déi vergläichbar Traffic kréien:
Da installéiere mir de Build mat den Ännerungen um Kanaresch Server. Fir d'Resultater ze evaluéieren, lafen mir e System deen ongeféier 100-150 Metriken mat enger Probe vu Kontrollserver vergläicht:
Wann Kanaresch Testen erfollegräich ass, da verëffentleche mir et graduell, a Wellen. Mir aktualiséieren keng Serveren op all Site zur selwechter Zäit - e ganze Site ze verléieren wéinst Problemer huet e méi groussen Impakt op de Service fir d'Benotzer wéi d'selwecht Zuel vu Serveren op verschiddene Plazen ze verléieren.
Am Allgemengen hänkt d'Effektivitéit a Sécherheet vun dëser Approche vun der Quantitéit an der Qualitéit vun de gesammelten Metriken of. Fir eise Query Beschleunigungssystem sammele mir Metriken aus all méigleche Komponenten:
- vu Clienten - Zuel vu Sessiounen an Ufroen, Réckfallsraten;
- Proxy - Statistiken iwwer d'Zuel an d'Zäit vun Ufroen;
- DNS - Zuel a Resultater vun Ufroen;
- Cloud Rand - Zuel an Zäit fir d'Veraarbechtung vun Ufroen an der Wollek.
All dëst gëtt an eng eenzeg Pipeline gesammelt, an, ofhängeg vun de Bedierfnesser, entscheede mir wéi eng Metriken an Echtzäitanalyse geschéckt ginn, a wéi eng Elasticsearch oder Big Data fir méi detailléiert Diagnostik.
Mir iwwerwaachen
An eisem Fall maache mir Ännerungen op de kritesche Wee vun Ufroen tëscht dem Client an dem Server. Zur selwechter Zäit ass d'Zuel vu verschiddene Komponenten um Client, um Server, an um Wee duerch den Internet enorm. Ännerungen um Client a Server geschéien dauernd - während der Aarbecht vun Dosende vun Équipen an natierlech Ännerungen am Ökosystem. Mir sinn an der Mëtt - wann Dir Problemer diagnostizéieren, ass et eng gutt Chance datt mir involvéiert sinn. Dofir musse mir kloer verstoen wéi mir Metriken definéieren, sammelen an analyséieren fir séier Probleemer ze isoléieren.
Idealerweis voll Zougang zu all Zorte vu Metriken a Filteren an Echtzäit. Awer et gi vill Metriken, sou datt d'Fro vun de Käschten entstinn. An eisem Fall trenne mir Metriken an Entwécklungsinstrumenter wéi follegt:
Fir Probleemer z'entdecken an ze triage benotze mir eisen eegene Open-Source Echtzäitsystem и - fir Visualiséierung. Et späichert aggregéiert Metriken an der Erënnerung, ass zouverlässeg an integréiert mam Alarmsystem. Fir Lokalisatioun an Diagnostik hu mir Zougang zu Logbicher vun Elasticsearch a Kibana. Fir statistesch Analyse a Modelléierung benotze mir grouss Daten a Visualiséierung am Tableau.
Et schéngt, datt dës Approche ganz schwéier ass mat ze schaffen. Wéi och ëmmer, andeems mir Metriken an Tools hierarchesch organiséieren, kënne mir séier e Problem analyséieren, d'Zort vum Problem bestëmmen, an dann an detailléiert Metriken erofhuelen. Am Allgemengen verbrénge mir ongeféier 1-2 Minutten fir d'Quell vum Decompte z'identifizéieren. Duerno schaffe mir mat engem spezifeschen Team un der Diagnostik - vun zéng Minutten bis e puer Stonnen.
Och wann d'Diagnos séier gemaach gëtt, wëlle mir net datt dat dacks geschitt. Idealerweis wäerte mir nëmmen eng kritesch Alarm kréien wann et e wesentlechen Impakt op de Service ass. Fir eise Query Beschleunigungssystem hu mir nëmmen 2 Alarmer déi matdeelen:
- Client Fallback Prozentsaz - Bewäertung vum Client Verhalen;
- Prozentsaz Sonde Feeler - Stabilitéit Daten vun Reseau Komponente.
Dës kritesch Alarmer iwwerwaachen ob de System fir d'Majoritéit vun de Benotzer funktionnéiert. Mir kucken wéi vill Cliente Fallback benotzt hunn wa se net fäeg sinn Ufro Beschleunegung ze kréien. Mir duerchschnëttlech manner wéi 1 kritesch Alarm pro Woch, och wann et eng Tonn vun Ännerungen am System sinn. Firwat geet dat fir eis duer?
- Et gëtt e Client Réckfall wann eise Proxy net funktionnéiert.
- Et gëtt en automatesche Lenksystem deen op Probleemer reagéiert.
Méi Detailer iwwer déi lescht. Eise Testsystem, an de System fir automatesch den optimale Wee fir Ufroe vum Client an d'Wollek ze bestëmmen, erlaabt eis automatesch mat e puer Probleemer ze këmmeren.
Loosst eis zréck op eis Probekonfiguratioun an 3 Weekategorien. Zousätzlech zu der Luedezäit kënne mir d'Tatsaach vun der Liwwerung selwer kucken. Wann et net méiglech war d'Donnéeën ze lueden, da kënne mir duerch d'Resultater laanscht verschidde Weeër bestëmmen, wou a wat gebrach ass, an ob mir se automatesch fixéiere kënnen andeems de Ufrowee geännert gëtt.
Beispiller:
Dëse Prozess kann automatiséiert ginn. Gitt et an de Lenksystem. A léiert et op Leeschtung an Zouverlässegkeet Problemer ze reagéieren. Wann eppes ufänkt ze briechen, reagéiert wann et eng besser Optioun gëtt. Zur selwechter Zäit ass eng direkt Reaktioun net kritesch, dank dem Réckfall op Clienten.
Also, kënnen d'Prinzipien vun System Ënnerstëtzung wéi follegt formuléiert ginn:
- Reduktioun vun der Skala vun Decompte;
- sammelen Metriken;
- Mir reparéieren automatesch Pann wa mir kënnen;
- wann et net kann, mir matdeelen Iech;
- Mir schaffen un Dashboards an Triage Toolset fir séier Äntwert.
Lektioune geléiert
Et brauch net vill Zäit fir e Prototyp ze schreiwen. An eisem Fall war et no 4 Méint fäerdeg. Mat et krute mir nei Metriken, an 10 Méint nom Start vun der Entwécklung krute mir den éischte Produktiounsverkéier. Dunn huet déi langweileg a ganz schwiereg Aarbecht ugefaang: lues a lues de System produktéieren an skala, den Haaptverkéier migréieren a vu Feeler léieren. Wéi och ëmmer, dësen effektive Prozess wäert net linear sinn - trotz all Efforten kann alles net virausgesot ginn. Et ass vill méi effektiv fir séier ze iteréieren an op nei Donnéeën ze reagéieren.
Baséierend op eiser Erfahrung, kënne mir déi folgend recommandéieren:
- Vertrau net Är Intuition.
Eis Intuition huet eis stänneg gescheitert, trotz der grousser Erfahrung vun eise Teammemberen. Zum Beispill hu mir déi erwaart Geschwindegkeet falsch virausgesot vun engem CDN Proxy ze benotzen, oder d'Behuele vun TCP Anycast.
- Kritt Daten aus der Produktioun.
Et ass wichteg Zougang zu op d'mannst eng kleng Quantitéit vun Produktioun Daten esou séier wéi méiglech ze kréien. Et ass bal onméiglech d'Zuel vun eenzegaartege Fäll, Konfiguratiounen an Astellungen an Labo Konditiounen ze kréien. Schnell Zougang zu de Resultater erlaabt Iech séier iwwer potenziell Problemer ze léieren an se an der Systemarchitektur berücksichtegen.
- Follegt net aner Leit hir Rotschléi a Resultater - sammelt Är eege Donnéeën.
Follegt d'Prinzipien fir Daten ze sammelen an ze analyséieren, awer akzeptéiert net blann aner Leit hir Resultater an Aussoen. Nëmmen Dir kënnt genau wëssen wat fir Är Benotzer funktionnéiert. Är Systemer an Är Clienten kënne wesentlech anescht sinn wéi aner Firmen. Glécklecherweis sinn Analyse Tools elo verfügbar an einfach ze benotzen. D'Resultater déi Dir kritt ass vläicht net wat Netflix, Facebook, Akamai an aner Firmen behaapten. An eisem Fall ënnerscheet d'Performance vun TLS, HTTP2 oder Statistiken iwwer DNS-Ufroe vun de Resultater vu Facebook, Uber, Akamai - well mir verschidden Apparater, Clienten an Datefloss hunn.
- Follegt net Moudetrends onnéideg an evaluéiert d'Effektivitéit.
Start einfach. Et ass besser en einfachen Aarbechtssystem a kuerzer Zäit ze maachen wéi vill Zäit ze verbréngen fir Komponenten ze entwéckelen déi Dir net braucht. Léist Aufgaben a Probleemer déi wichteg sinn op Basis vun Äre Miessunge a Resultater.
- Bereet Iech fir nei Uwendungen.
Just wéi et schwéier ass all d'Problemer virauszesoen, ass et schwéier d'Virdeeler an Uwendungen am Viraus virauszesoen. Huelt e Hiweis vu Startups - hir Fäegkeet sech un d'Clientbedéngungen unzepassen. An Ärem Fall kënnt Dir nei Probleemer an hir Léisungen entdecken. An eisem Projet hu mir en Zil gesat fir Ufrolatenz ze reduzéieren. Wéi och ëmmer, wärend der Analyse an den Diskussiounen hu mir gemierkt datt mir och Proxy Server benotze kënnen:
- fir de Verkéier iwwer AWS Regiounen ze balanséieren an d'Käschte ze reduzéieren;
- CDN Stabilitéit ze modelléieren;
- DNS ze konfiguréieren;
- fir TLS / TCP ze konfiguréieren.
Konklusioun
Am Bericht hunn ech beschriwwen wéi Netflix de Problem léist fir Internet Ufroen tëscht Clienten an der Wollek ze beschleunegen. Wéi mir Daten sammelen mat engem Samplingsystem op Clienten, a benotzen déi gesammelt historesch Donnéeën fir Produktiounsufroe vu Clienten duerch de schnellsten Wee am Internet ze routen. Wéi mir d'Prinzipien vun Netzwierkprotokollen, eis CDN Infrastruktur, Backbone Netzwierk an DNS Server benotze fir dës Aufgab z'erreechen.
Wéi och ëmmer, eis Léisung ass just e Beispill vu wéi mir bei Netflix esou e System ëmgesat hunn. Wat fir eis geschafft huet. Den ugewandten Deel vu mengem Bericht fir Iech sinn d'Prinzipien vun der Entwécklung an der Ënnerstëtzung déi mir verfollegen a gutt Resultater erreechen.
Eis Léisung fir de Problem passt Iech vläicht net. Wéi och ëmmer, d'Theorie an d'Designprinzipien bleiwen, och wann Dir keng eegen CDN Infrastruktur hutt, oder wann se wesentlech vun eis ënnerscheet.
D'Wichtegkeet vun der Geschwindegkeet vun de Geschäftsfuerderunge bleift och wichteg. An och fir en einfachen Service musst Dir e Choix maachen: tëscht Cloud Ubidder, Serverplaz, CDN an DNS Ubidder. Äre Choix beaflosst d'Effektivitéit vun Internet Ufroe fir Är Clienten. An et ass wichteg fir Iech dësen Afloss ze moossen an ze verstoen.
Start mat einfache Léisungen, këmmere sech ëm wéi Dir de Produit ännert. Léiert wéi Dir gitt a verbessert de System baséiert op Daten vun Äre Clienten, Är Infrastruktur an Ärem Geschäft. Denkt un d'Méiglechkeet vun onerwaarten Decompte während dem Designprozess. An da kënnt Dir Ären Entwécklungsprozess beschleunegen, d'Léisungseffizienz verbesseren, onnéideg Ënnerstëtzungslaascht vermeiden a friddlech schlofen.
Dëst Joer am Online-Format. Dir kënnt Froen un ee vun de Pappe vun DevOps stellen, dem John Willis selwer!
Source: will.com