Netflix estas la gvidanto en la interreta televida merkato - la kompanio, kiu kreis kaj aktive disvolvas ĉi tiun segmenton. Netflix estas konata ne nur pro sia ampleksa katalogo de filmoj kaj televidserioj haveblaj de preskaŭ ĉiu angulo de la planedo kaj ajna aparato kun ekrano, sed ankaŭ pro sia fidinda infrastrukturo kaj unika inĝenieristiko kulturo.
Klara ekzemplo de la Netflix-aliro por disvolvi kaj subteni kompleksajn sistemojn estis prezentita ĉe DevOops 2019. - Direktoro pri Disvolviĝo ĉe Netflix. Diplomiĝinto de la Fakultato de Komputila Matematiko kaj Matematiko de la Ŝtata Universitato de Niĵnij Novgorod. Lobachevsky, Sergey unu el la unuaj inĝenieroj en Open Connect - CDN-teamo ĉe Netflix. Li konstruis sistemojn por monitorado kaj analizo de videodatenoj, lanĉis popularan servon por taksi la rapidon de interreta konekto FAST.com, kaj dum la lastaj kelkaj jaroj laboras pri optimumigo de interretaj petoj por ke la aplikaĵo Netflix funkciu kiel eble plej rapide por uzantoj.
La raporto ricevis la plej bonajn recenzojn de kongresanoj, kaj ni preparis tekstan version por vi.
En sia raporto, Sergei parolis detale
- pri kio influas la malfruon de interretaj petoj inter la kliento kaj servilo;
- kiel redukti ĉi tiun malfruon;
- kiel desegni, konservi kaj monitori erar-toleremajn sistemojn;
- kiel atingi rezultojn en mallonga tempo, kaj kun minimuma risko por la komerco;
- kiel analizi rezultojn kaj lerni de eraroj.
Respondoj al ĉi tiuj demandoj bezonas ne nur tiuj, kiuj laboras en grandaj korporacioj.
La prezentitaj principoj kaj teknikoj devus esti konataj kaj praktikitaj de ĉiuj, kiuj disvolvas kaj subtenas Interretajn produktojn.
Poste estas la rakonto el la perspektivo de la parolanto.
La graveco de interreta rapideco
La rapideco de interretaj petoj rekte rilatas al komerco. Konsideru la komercan industrion: Amazon en 2009 ke 100ms prokrasto rezultigas perdon de 1% de vendoj.
Estas pli kaj pli da porteblaj aparatoj, sekvataj de porteblaj retejoj kaj aplikaĵoj. Se via paĝo ŝarĝas pli ol 3 sekundojn, vi perdas ĉirkaŭ duonon de viaj uzantoj. KUN Guglo konsideras la ŝarĝan rapidecon de via paĝo en serĉrezultoj: ju pli rapida la paĝo, des pli alta ĝia pozicio en Guglo.
Konektrapideco ankaŭ estas grava en financaj institucioj kie latencia estas kritika. En 2015, Hibernia Networks kablo de 400 milionoj da dolaroj inter Novjorko kaj Londono por redukti latentecon inter la urboj je 6ms. Imagu 66 milionojn da dolaroj por 1 ms de latenta redukto!
Laŭ , konektorapidecoj super 5 Mbit/s ne plu rekte influas la ŝarĝrapidecon de tipa retejo. Tamen, ekzistas linia rilato inter koneksa latenteco kaj paĝa ŝarĝrapideco:
Tamen, Netflix ne estas tipa produkto. La efiko de latenteco kaj rapideco sur la uzanto estas aktiva areo de analizo kaj disvolviĝo. Estas aplikaĵo-ŝarĝado kaj enhavelekto, kiuj dependas de latencia, sed ŝarĝado de senmovaj elementoj kaj streaming ankaŭ dependas de konektorapideco. Analizi kaj optimumigi la ŝlosilajn faktorojn, kiuj influas la uzantan sperton, estas aktiva areo de disvolviĝo por pluraj teamoj ĉe Netflix. Unu el la celoj estas redukti la latentecon de petoj inter Netflix-aparatoj kaj la nuba infrastrukturo.
En la raporto ni fokusos specife pri redukto de latenco uzante la ekzemplon de la Netflix-infrastrukturo. Ni konsideru de praktika vidpunkto kiel alproksimiĝi al la procezoj de dezajno, disvolviĝo kaj funkciado de kompleksaj distribuitaj sistemoj kaj pasigi tempon por novigado kaj rezultoj, anstataŭ diagnozi funkciajn problemojn kaj paneojn.
Ene de Netflix
Miloj da malsamaj aparatoj subtenas Netflix-aplikaĵojn. Ili estas evoluigitaj de kvar malsamaj teamoj, kiuj faras apartajn versiojn de la kliento por Android, iOS, televido kaj retumiloj. Kaj ni multe penas por plibonigi kaj personigi la uzantan sperton. Por fari tion, ni kuras centojn da A/B-testoj paralele.
Personigo estas subtenata de centoj da mikroservoj en la AWS-nubo, provizante personecigitajn uzantdatenojn, demand-sendon, telemetrion, Grandajn Datumojn kaj Kodigon. Trafika bildigo aspektas jene:
Maldekstre estas la enirpunkto, kaj tiam la trafiko estas distribuita inter kelkcent mikroservoj, kiuj estas subtenataj de malsamaj backend-teamoj.
Alia grava komponanto de nia infrastrukturo estas Open Connect CDN, kiu liveras statikan enhavon al la finuzanto - filmetoj, bildoj, klientokodo ktp. La CDN situas sur kutimaj serviloj (OCA - Open Connect Appliance). Ene estas aroj da SSD kaj HDD-diskoj kurantaj optimumigitan FreeBSD, kun NGINX kaj aro da servoj. Ni desegnas kaj optimumigas aparataron kaj programaron komponantojn por ke tia CDN-servilo povu sendi kiel eble plej multe da datumoj al uzantoj.
La "muro" de ĉi tiuj serviloj ĉe la interreta trafika interŝanĝo (Internet eXchange - IX) aspektas jene:
Interreta Interŝanĝo disponigas la kapablon por provizantoj de retservoj kaj provizantoj de enhavo "konekti" unu kun la alia por pli rekte interŝanĝi datumojn en la Interreto. Estas proksimume 70-80 punktoj de Interreta Interŝanĝo tra la mondo kie niaj serviloj estas instalitaj, kaj ni sendepende instalas kaj prizorgas ilin:
Krome, ni ankaŭ provizas servilojn rekte al interretaj provizantoj, kiujn ili instalas en sia reto, plibonigante la lokalizon de Netflix-trafiko kaj la kvaliton de streaming por uzantoj:
Aro da AWS-servoj respondecas pri sendado de videopetoj de klientoj al CDN-serviloj, kaj ankaŭ pri agordo de la serviloj mem - ĝisdatigi enhavon, programkodon, agordojn ktp. Por ĉi-lasta, ni ankaŭ konstruis spinan reton, kiu konektas servilojn en Interretaj Interŝanĝaj punktoj kun AWS. La spina reto estas tutmonda reto de optikaj kabloj kaj enkursigiloj, kiujn ni povas desegni kaj agordi laŭ niaj bezonoj.
Por , nia CDN-infrastrukturo liveras proksimume ⅛ de la interreta trafiko de la mondo dum pintaj horoj kaj ⅓ de la trafiko en Nordameriko, kie Netflix estis ĉirkaŭ la plej longe. Impresaj nombroj, sed por mi unu el la plej mirindaj atingoj estas, ke la tuta CDN-sistemo estas disvolvita kaj prizorgata de teamo de malpli ol 150 homoj.
Komence, la CDN-infrastrukturo estis dizajnita por liveri videodatenojn. Tamen, kun la tempo ni rimarkis, ke ni ankaŭ povas uzi ĝin por optimumigi dinamikajn petojn de klientoj en la AWS-nubo.
Pri Interreta akcelo
Hodiaŭ, Netflix havas 3 AWS-regionojn, kaj la latencia de petoj al la nubo dependos de kiom for la kliento estas de la plej proksima regiono. Samtempe, ni havas multajn CDN-servilojn, kiuj estas uzataj por liveri statikan enhavon. Ĉu ekzistas iu maniero uzi ĉi tiun kadron por akceli dinamikajn demandojn? Tamen, bedaŭrinde, estas neeble konservi ĉi tiujn petojn - API-oj estas personigitaj kaj ĉiu rezulto estas unika.
Ni faru prokurilon sur la CDN-servilo kaj komencu sendi trafikon tra ĝi. Ĉu ĝi estos pli rapida?
Materialo
Ni memoru kiel funkcias retaj protokoloj. Hodiaŭ, plej multe de la trafiko en la Interreto uzas HTTP-ojn, kiuj dependas de la malsuperaj tavolaj protokoloj TCP kaj TLS. Por ke kliento konektiĝu al la servilo, ĝi faras manpremon, kaj por establi sekuran konekton, la kliento bezonas interŝanĝi mesaĝojn kun la servilo tri fojojn kaj almenaŭ unu plian fojon por transdoni datumojn. Kun latenco por rondveturo (RTT) de 100 ms, ni bezonus 400 ms por ricevi la unuan pecon da datumoj:
Se ni metas la atestilojn sur la CDN-servilon, tiam la tempo de manpremo inter la kliento kaj la servilo povas esti signife reduktita se la CDN estas pli proksima. Ni supozu, ke la latenteco al la CDN-servilo estas 30ms. Tiam necesos 220 ms por ricevi la unuan biton:
Sed la avantaĝoj ne finiĝas tie. Post kiam konekto estis establita, TCP pliigas la obstrukciĝofenestron (la kvanto de informoj kiujn ĝi povas transdoni super tiu ligo paralele). Se datumpakaĵo estas perdita, tiam klasikaj efektivigoj de la TCP-protokolo (kiel TCP New Reno) reduktas la malfermitan "fenestron" je duono. La kresko de la obstrukciĝofenestro, kaj la rapideco de ĝia reakiro de perdo denove dependas de la malfruo (RTT) al la servilo. Se ĉi tiu konekto nur iras ĝis la CDN-servilo, ĉi tiu reakiro estos pli rapida. Samtempe, paka perdo estas norma fenomeno, precipe por sendrataj retoj.
Interreta bendolarĝo povas esti reduktita, precipe dum pinthoroj, pro trafiko de uzantoj, kiu povas konduki al trafikŝtopiĝo. Tamen, estas neniel en la Interreto doni prioritaton al iuj petoj super aliaj. Ekzemple, donu prioritaton al malgrandaj kaj latentec-sentemaj petoj super "pezaj" datumfluoj, kiuj ŝarĝas la reton. Tamen, en nia kazo, havi nian propran spinan reton permesas al ni fari tion sur parto de la peta vojo - inter la CDN kaj la nubo, kaj ni povas plene agordi ĝin. Vi povas certigi, ke malgrandaj kaj latentec-sentemaj pakoj estas prioritatitaj, kaj grandaj datumfluoj iras iom poste. Ju pli proksime la CDN estas al la kliento, des pli granda la efikeco.
Apliknivelaj protokoloj (OSI Nivelo 7) ankaŭ havas efikon al latencia. Novaj protokoloj kiel HTTP/2 optimumigas la agadon de paralelaj petoj. Tamen ni havas Netflix-klientojn kun pli malnovaj aparatoj, kiuj ne subtenas la novajn protokolojn. Ne ĉiuj klientoj povas esti ĝisdatigitaj aŭ optimume agorditaj. Samtempe, inter la CDN-prokurilo kaj la nubo estas kompleta kontrolo kaj la kapablo uzi novajn, optimumajn protokolojn kaj agordojn. La neefika parto kun malnovaj protokoloj nur funkcios inter la kliento kaj la CDN-servilo. Plie, ni povas fari multipleksajn petojn sur jam establita konekto inter la CDN kaj la nubo, plibonigante la uzadon de konekto ĉe la TCP-nivelo:
Ni mezuras
Malgraŭ tio, ke la teorio promesas plibonigojn, ni ne tuj rapidas lanĉi la sistemon en produktado. Anstataŭe, ni unue devas pruvi, ke la ideo funkcios praktike. Por fari tion, vi devas respondi plurajn demandojn:
- Rapido: ĉu prokurilo estos pli rapida?
- Fidindeco: Ĉu ĝi rompiĝos pli ofte?
- Malfacileco: kiel integri kun aplikoj?
- kosto de: Kiom kostas disfaldi plian infrastrukturon?
Ni konsideru detale nian aliron por taksi la unuan punkton. La ceteraj estas traktataj simile.
Por analizi la rapidecon de petoj, ni volas akiri datumojn por ĉiuj uzantoj, sen elspezi multan tempon por disvolviĝo kaj sen rompi produktadon. Estas pluraj aliroj por ĉi tio:
- RUM, aŭ pasiva peto-mezurado. Ni mezuras la ekzekuttempon de nunaj petoj de uzantoj kaj certigas plenan uzantan kovradon. La malavantaĝo estas, ke la signalo ne estas tre stabila pro multaj faktoroj, ekzemple pro malsamaj petaj grandecoj, prilaborado en la servilo kaj kliento. Krome, vi ne povas testi novan agordon sen efiko en produktado.
- Laboratoriaj provoj. Specialaj serviloj kaj infrastrukturo, kiuj simulas klientojn. Kun ilia helpo ni faras la necesajn provojn. Tiel ni ricevas plenan kontrolon de la mezurrezultoj kaj klaran signalon. Sed ne ekzistas kompleta priraportado de aparatoj kaj uzantlokoj (precipe kun tutmonda servo kaj subteno por miloj da aparataj modeloj).
Kiel vi povas kombini la avantaĝojn de ambaŭ metodoj?
Nia teamo trovis solvon. Ni skribis malgrandan kodon - specimenon - kiun ni enkonstruis en nian aplikaĵon. Sondoj permesas al ni fari plene kontrolitajn retajn testojn de niaj aparatoj. Ĝi funkcias tiel:
- Baldaŭ post ŝarĝo de la aplikaĵo kaj kompletigado de la komenca agado, ni rulas niajn enketojn.
- La kliento faras peton al la servilo kaj ricevas "recepton" por la testo. La recepto estas listo de URL-oj al kiuj HTTP(j) peto devas esti farita. Krome, la recepto agordas petajn parametrojn: prokrastoj inter petoj, kvanto de petitaj datumoj, HTTP(j) titoloj, ktp. Samtempe, ni povas testi plurajn malsamajn receptojn paralele - dum petado de agordo, ni hazarde determinas kiun recepton eldoni.
- La sonda lanĉa tempo estas elektita por ne konflikti kun la aktiva uzo de retaj rimedoj sur la kliento. Esence, la tempo estas elektita kiam la kliento ne estas aktiva.
- Post ricevi la recepton, la kliento faras petojn al ĉiu el la URL-oj, paralele. La peto al ĉiu el la adresoj povas esti ripetita - la t.n. "pulsoj". Je la unua pulso, ni mezuras kiom da tempo daŭris por establi konekton kaj elŝuti datumojn. Sur la dua pulso, ni mezuras la tempon necesan por ŝargi datumojn per jam establita konekto. Antaŭ la tria, ni povas agordi prokraston kaj mezuri la rapidecon establi rekonekton, ktp.
Dum la testo, ni mezuras ĉiujn parametrojn, kiujn la aparato povas akiri:
- DNS-petotempo;
- TCP-konekto agorda tempo;
- TLS-konekto agorda tempo;
- tempo de ricevado de la unua bajto de datumoj;
- tuta tempo de ŝarĝo;
- status-rezulta kodo.
- Post kiam ĉiuj pulsoj finiĝis, la specimeno ŝarĝas ĉiujn mezuradojn por analizo.
La ŝlosilaj punktoj estas minimuma dependeco de logiko sur la kliento, datumtraktado sur la servilo kaj la mezurado de paralelaj petoj. Tiel, ni povas izoli kaj testi la influon de diversaj faktoroj influantaj demandan rendimenton, varii ilin ene de ununura recepto kaj akiri rezultojn de realaj klientoj.
Ĉi tiu infrastrukturo pruvis utila por pli ol nur pridemanda agado-analizo. Nuntempe ni havas 14 aktivajn receptojn, pli ol 6000 specimenojn je sekundo, ricevantaj datumojn el ĉiuj anguloj de la tero kaj plenan aparaton priraportado. Se Netflix aĉetus similan servon de tria partio, ĝi kostus milionojn da dolaroj jare, kun multe pli malbona kovrado.
Testado de teorio en praktiko: prototipo
Kun tia sistemo, ni povis taksi la efikecon de CDN-prokuriloj laŭ peta latenco. Nun vi bezonas:
- krei prokuran prototipon;
- metu la prototipon sur CDN;
- determini kiel direkti klientojn al prokurilo sur specifa CDN-servilo;
- Komparu rendimenton al petoj en AWS sen prokurilo.
La tasko estas taksi la efikecon de la proponita solvo kiel eble plej rapide. Ni elektis Iru por efektivigi la prototipon pro la havebleco de bonaj interkonektaj bibliotekoj. Sur ĉiu CDN-servilo, ni instalis la prototipan prokurilon kiel statikan binaron por minimumigi dependecojn kaj simpligi integriĝon. En la komenca efektivigo, ni uzis normajn komponantojn kiel eble plej multe kaj malgrandajn modifojn por HTTP/2-konekto-kunigo kaj peti multipleksadon.
Por ekvilibrigi inter AWS-regionoj, ni uzis geografian DNS-datumbazon, la sama uzata por ekvilibrigi klientojn. Por elekti CDN-servilon por la kliento, ni uzas TCP Anycast por serviloj en Internet Exchange (IX). En ĉi tiu opcio, ni uzas unu IP-adreson por ĉiuj CDN-serviloj, kaj la kliento estos direktita al la CDN-servilo kun la plej malgranda nombro da IP-saltoj. En CDN-serviloj instalitaj de interretaj provizantoj (ISP-oj), ni ne havas kontrolon super la enkursigilo por agordi TCP Anycast, do ni uzas , kiu direktas klientojn al interretaj provizantoj por videofluado.
Do, ni havas tri specojn de petaj vojoj: al la nubo per la malferma Interreto, per CDN-servilo en IX, aŭ per CDN-servilo situanta ĉe interreta provizanto. Nia celo estas kompreni, kia vojo estas pli bona, kaj kio estas la avantaĝo de prokurilo, kompare kun kiel petoj estas senditaj al produktado. Por fari tion, ni uzas specimenan sistemon jene:
Ĉiu el la vojoj fariĝas aparta celo, kaj ni rigardas la tempon, kiun ni ricevis. Por analizo, ni kombinas la prokurajn rezultojn en unu grupon (elektu la plej bonan tempon inter IX kaj ISP-prokuriloj), kaj komparas ilin kun la tempo de petoj al la nubo sen prokurilo:
Kiel vi povas vidi, la rezultoj estis miksitaj - plejofte la prokurilo donas bonan akcelon, sed estas ankaŭ sufiĉa nombro da klientoj, por kiuj la situacio grave plimalboniĝos.
Kiel rezulto, ni faris plurajn gravajn aferojn:
- Ni taksis la atendatan agadon de petoj de klientoj al la nubo per CDN-prokurilo.
- Ni ricevis datumojn de realaj klientoj, de ĉiuj specoj de aparatoj.
- Ni rimarkis, ke la teorio ne estis 100% konfirmita kaj la komenca oferto kun CDN-prokurilo ne funkcius por ni.
- Ni ne riskis - ni ne ŝanĝis produktadajn agordojn por klientoj.
- Nenio estis rompita.
Prototipo 2.0
Do, revenu al la desegnotabulo kaj ripetu la procezon denove.
La ideo estas, ke anstataŭ uzi 100% prokurilon, ni determinos la plej rapidan vojon por ĉiu kliento, kaj ni sendos tien petojn - tio estas, ni faros tion, kion oni nomas kliento stirado.
Kiel efektivigi ĉi tion? Ni ne povas uzi logikon ĉe la servilo, ĉar... La celo estas konekti al ĉi tiu servilo. Devas esti iu maniero fari tion ĉe la kliento. Kaj ideale, faru ĉi tion kun minimuma kvanto de kompleksa logiko, por ne solvi la problemon de integriĝo kun granda nombro da klientplatformoj.
La respondo estas uzi DNS. En nia kazo, ni havas nian propran DNS-infrastrukturon, kaj ni povas starigi domajnan zonon por kiu niaj serviloj estos aŭtoritataj. Ĝi funkcias tiel:
- La kliento faras peton al la DNS-servilo uzante gastiganton, ekzemple api.netflix.xom.
- La peto alvenas al nia DNS-servilo
- La DNS-servilo scias, kiu vojo estas la plej rapida por ĉi tiu kliento kaj eldonas la respondan IP-adreson.
La solvo havas plian kompleksecon: aŭtoritataj DNS-provizantoj ne vidas la IP-adreson de la kliento kaj povas nur legi la IP-adreson de la rekursiva solvilo, kiun la kliento uzas.
Kiel rezulto, nia aŭtoritata solvilo devas fari decidon ne por individua kliento, sed por grupo de klientoj bazitaj sur la rekursiva solvilo.
Por solvi, ni uzas la samajn specimenojn, kunigas la mezurrezultojn de klientoj por ĉiu el la rekursiaj solvantoj kaj decidas kien sendi ĉi tiun grupon de ili - prokurilon per IX uzante TCP Anycast, per ISP-prokurilo aŭ rekte al la nubo.
Ni ricevas la sekvan sistemon:
La rezulta DNS-direkta modelo permesas vin direkti klientojn surbaze de historiaj observoj pri la rapideco de konektoj de klientoj al la nubo.
Denove, la demando estas kiom efike funkcios ĉi tiu aliro? Por respondi, ni denove uzas nian sondan sistemon. Sekve, ni agordas la agordon de prezentisto, kie unu el la celoj sekvas la direkton de DNS-direktado, la alia iras rekte al la nubo (nuna produktado).
Kiel rezulto, ni komparas la rezultojn kaj ricevas takson de la efikeco:
Kiel rezulto, ni lernis plurajn gravajn aferojn:
- Ni taksis la atendatan agadon de petoj de klientoj al la nubo uzante DNS Steering.
- Ni ricevis datumojn de realaj klientoj, de ĉiuj specoj de aparatoj.
- La efikeco de la proponita ideo estis pruvita.
- Ni ne riskis - ni ne ŝanĝis produktadajn agordojn por klientoj.
- Nenio estis rompita.
Nun pri la malfacila parto - ni lanĉas ĝin en produktado
La facila parto nun finiĝis - ekzistas funkcianta prototipo. Nun la malfacila parto estas lanĉi solvon por la tuta trafiko de Netflix, deplojante al 150 milionoj da uzantoj, miloj da aparatoj, centoj da mikroservoj, kaj ĉiam ŝanĝiĝanta produkto kaj infrastrukturo. Netflix-serviloj ricevas milionojn da petoj sekundo, kaj estas facile rompi la servon per senzorga ago. Samtempe, ni volas dinamike direkti trafikon tra miloj da CDN-serviloj en Interreto, kie io ŝanĝiĝas kaj rompas konstante kaj en la plej maloportuna momento.
Kaj kun ĉio ĉi, la teamo havas 3 inĝenierojn respondecajn pri la disvolviĝo, disfaldo kaj plena subteno de la sistemo.
Tial ni daŭre parolos pri trankvila kaj sana dormo.
Kiel daŭrigi disvolviĝon kaj ne pasigi vian tutan tempon por subteno? Nia aliro baziĝas sur 3 principoj:
- Ni reduktas la eblan skalon de paneoj (eksploda radiuso).
- Ni preparas nin por surprizoj - ni atendas ke io rompiĝos, malgraŭ testado kaj persona sperto.
- Gracia degradado - se io ne funkcias ĝuste, ĝi devus esti fiksita aŭtomate, eĉ se ne en la plej efika maniero.
Rezultis, ke en nia kazo, kun ĉi tiu aliro al la problemo, ni povas trovi simplan kaj efikan solvon kaj signife simpligi sisteman subtenon. Ni rimarkis, ke ni povus aldoni malgrandan kodon al la kliento kaj kontroli por retaj petaj eraroj kaŭzitaj de konektoproblemoj. En kazo de retaj eraroj, ni faras returniĝon rekte al la nubo. Ĉi tiu solvo ne postulas gravan penadon por klientteamoj, sed multe reduktas la riskon de neatenditaj paneoj kaj surprizoj por ni.
Kompreneble, malgraŭ la falo, ni tamen sekvas klaran disciplinon dum evoluo:
- Specimena testo.
- A/B-testado aŭ Kanarioj.
- Progresema lanĉo.
Kun specimenoj, la aliro estis priskribita - ŝanĝoj unue estas provitaj uzante personigitan recepton.
Por kanaria testado, ni devas akiri kompareblajn parojn da serviloj sur kiuj ni povas kompari kiel la sistemo funkcias antaŭ kaj post la ŝanĝoj. Por fari tion, el niaj multaj CDN-ejoj, ni elektas parojn da serviloj, kiuj ricevas kompareblan trafikon:
Poste ni instalas la konstruon kun la ŝanĝoj sur la Kanaria servilo. Por taksi la rezultojn, ni kuras sistemon, kiu komparas proksimume 100-150 metrikojn kun specimeno de Kontrolserviloj:
Se Kanaria testado sukcesas, tiam ni liberigas ĝin iom post iom, en ondoj. Ni ne ĝisdatigas servilojn en ĉiu retejo samtempe - perdi tutan retejon pro problemoj havas pli gravan efikon al la servo por uzantoj ol perdi la saman nombron da serviloj en malsamaj lokoj.
Ĝenerale, la efikeco kaj sekureco de ĉi tiu aliro dependas de la kvanto kaj kvalito de la kolektitaj metrikoj. Por nia demanda akcela sistemo, ni kolektas metrikojn de ĉiuj eblaj komponantoj:
- de klientoj - nombro da sesioj kaj petoj, rezervaj tarifoj;
- prokurilo - statistiko pri la nombro kaj tempo de petoj;
- DNS - nombro kaj rezultoj de petoj;
- nuba rando - nombro kaj tempo por prilabori petojn en la nubo.
Ĉio ĉi estas kolektita en ununuran dukton, kaj, depende de la bezonoj, ni decidas kiujn metrikojn sendi al realtempa analizo, kaj kiuj al Elasticsearch aŭ Big Data por pli detalaj diagnozoj.
Ni monitoras
En nia kazo, ni faras ŝanĝojn sur la kritika vojo de petoj inter la kliento kaj servilo. Samtempe, la nombro da malsamaj komponantoj sur la kliento, sur la servilo kaj survoje tra Interreto estas enorma. Ŝanĝoj sur la kliento kaj servilo okazas konstante - dum la laboro de dekoj da teamoj kaj naturaj ŝanĝoj en la ekosistemo. Ni estas en la mezo - dum diagnozado de problemoj, estas bona ŝanco ke ni partoprenos. Tial ni devas klare kompreni kiel difini, kolekti kaj analizi metrikojn por rapide izoli problemojn.
Ideale, plena aliro al ĉiuj specoj de metrikoj kaj filtriloj en reala tempo. Sed estas multaj metrikoj, do la demando pri kosto ŝprucas. En nia kazo, ni apartigas metrikojn kaj evoluilojn jene:
Por detekti kaj triadi problemojn ni uzas nian propran malfermfontan realtempan sistemon и - por bildigo. Ĝi stokas aldonitajn metrikojn en memoro, estas fidinda kaj integriĝas kun la alarma sistemo. Por lokalizado kaj diagnozo, ni havas aliron al protokoloj de Elasticsearch kaj Kibana. Por statistika analizo kaj modeligado, ni uzas grandajn datumojn kaj bildigon en Tableau.
Ŝajnas, ke ĉi tiu aliro estas tre malfacile labori. Tamen, organizante metrikojn kaj ilojn hierarkie, ni povas rapide analizi problemon, determini la tipon de problemo, kaj tiam bori malsupren en detalajn metrikojn. Ĝenerale, ni pasigas ĉirkaŭ 1-2 minutojn por identigi la fonton de la rompo. Post ĉi tio, ni laboras kun specifa teamo pri diagnozo - de dekoj da minutoj ĝis pluraj horoj.
Eĉ se la diagnozo estas farita rapide, ni ne volas, ke tio okazu ofte. Ideale, ni ricevos kritikan atentigon nur kiam estas grava efiko sur la servo. Por nia demanda akcela sistemo, ni havas nur 2 atentigojn, kiuj sciigos:
- Client Fallback percentage - takso de klienta konduto;
- procentaj Sondaj eraroj - stabilecdatenoj de retaj komponantoj.
Ĉi tiuj kritikaj alarmoj kontrolas ĉu la sistemo funkcias por la plimulto de uzantoj. Ni rigardas kiom da klientoj uzis replikon, se ili ne povis akiri petan akcelon. Ni averaĝas malpli ol 1 kritikan alarmon semajne, kvankam ekzistas multe da ŝanĝoj en la sistemo. Kial ĉi tio sufiĉas por ni?
- Estas kliento-returniĝo se nia prokurilo ne funkcias.
- Estas aŭtomata stira sistemo, kiu respondas al problemoj.
Pli da detaloj pri ĉi-lasta. Nia prova sistemo, kaj la sistemo por aŭtomate determini la optimuman vojon por petoj de la kliento al la nubo, permesas al ni aŭtomate trakti iujn problemojn.
Ni revenu al nia ekzempla agordo kaj 3 vojo-kategorioj. Krom la tempo de ŝarĝo, ni povas rigardi la fakton de livero mem. Se ne eblis ŝargi la datumojn, tiam rigardante la rezultojn laŭ malsamaj vojoj ni povas determini kie kaj kio rompiĝis, kaj ĉu ni povas aŭtomate ripari ĝin ŝanĝante la petan vojon.
ekzemploj:
Ĉi tiu procezo povas esti aŭtomatigita. Enmetu ĝin en la stirsistemon. Kaj instruu ĝin respondi al problemoj de rendimento kaj fidindeco. Se io komencas rompi, reagu se estas pli bona elekto. Samtempe, tuja reago ne estas maltrankviliga, danke al reago al klientoj.
Tiel, la principoj de sistemsubteno povas esti formulitaj jene:
- reduktante la skalon de paneoj;
- kolektado de metrikoj;
- Ni aŭtomate riparas paneojn se ni povas;
- se ĝi ne povas, ni sciigas vin;
- Ni laboras pri paneloj kaj triaj ilaro por rapida respondo.
Lecionoj lernitaj
Ne necesas multe da tempo por verki prototipon. En nia kazo, ĝi estis preta post 4 monatoj. Per ĝi ni ricevis novajn metrikojn, kaj 10 monatojn post la komenco de evoluo ni ricevis la unuan produktan trafikon. Tiam komenciĝis la teda kaj tre malfacila laboro: iom post iom produkti kaj grimpi la sistemon, migri la ĉefan trafikon kaj lerni de eraroj. Tamen, ĉi tiu efika procezo ne estos lineara - malgraŭ ĉiuj klopodoj, ĉio ne estas antaŭvidebla. Estas multe pli efika rapide ripeti kaj respondi al novaj datumoj.
Surbaze de nia sperto, ni povas rekomendi la jenajn:
- Ne fidu vian intuicion.
Nia intuicio malsukcesis nin konstante, malgraŭ la vasta sperto de niaj teamanoj. Ekzemple, ni malĝuste antaŭdiris la atendatan rapidiĝon de uzado de CDN-prokurilo aŭ la konduto de TCP Anycast.
- Akiru datumojn de produktado.
Gravas akiri aliron al almenaŭ malgranda kvanto da produktadaj datumoj kiel eble plej rapide. Estas preskaŭ neeble akiri la nombron da unikaj kazoj, agordoj kaj agordoj en laboratoriokondiĉoj. Rapida aliro al la rezultoj permesos vin rapide lerni pri eblaj problemoj kaj konsideri ilin en la sistema arkitekturo.
- Ne sekvu la konsilojn kaj rezultojn de aliaj homoj - kolektu viajn proprajn datumojn.
Sekvu la principojn por kolekti kaj analizi datumojn, sed ne blinde akceptu rezultojn kaj deklarojn de aliaj homoj. Nur vi povas scii precize kio funkcias por viaj uzantoj. Viaj sistemoj kaj viaj klientoj povas esti signife malsamaj de aliaj kompanioj. Feliĉe, analiziloj nun estas disponeblaj kaj facile uzeblaj. La rezultoj, kiujn vi ricevas, eble ne estas, kion asertas Netflix, Facebook, Akamai kaj aliaj kompanioj. En nia kazo, la agado de TLS, HTTP2 aŭ statistiko pri DNS-petoj diferencas de la rezultoj de Facebook, Uber, Akamai - ĉar ni havas malsamajn aparatojn, klientojn kaj datumfluojn.
- Ne sekvu modajn tendencojn nenecese kaj taksu efikecon.
Komencu simple. Pli bone estas fari simplan laborsistemon en mallonga tempo ol pasigi grandegan tempon disvolvante komponantojn, kiujn vi ne bezonas. Solvu taskojn kaj problemojn kiuj gravas surbaze de viaj mezuradoj kaj rezultoj.
- Preparu por novaj aplikoj.
Same kiel estas malfacile antaŭdiri ĉiujn problemojn, estas malfacile antaŭdiri la avantaĝojn kaj aplikojn. Rimarku noventreprenojn - ilian kapablon adaptiĝi al klientkondiĉoj. En via kazo, vi eble malkovros novajn problemojn kaj iliajn solvojn. En nia projekto, ni starigis celon redukti petan latenciadon. Tamen, dum la analizo kaj diskutoj, ni rimarkis, ke ni ankaŭ povas uzi prokurajn servilojn:
- ekvilibrigi trafikon tra AWS-regionoj kaj redukti kostojn;
- modeligi CDN-stabilecon;
- por agordi DNS;
- por agordi TLS/TCP.
konkludo
En la raporto, mi priskribis kiel Netflix solvas la problemon akceli interretajn petojn inter klientoj kaj la nubo. Kiel ni kolektas datumojn uzante specimenan sistemon pri klientoj, kaj uzas la kolektitajn historiajn datumojn por direkti produktadpetojn de klientoj tra la plej rapida vojo en la Interreto. Kiel ni uzas la principojn de retaj protokoloj, nia CDN-infrastrukturo, spina reto kaj DNS-serviloj por atingi ĉi tiun taskon.
Tamen, nia solvo estas nur ekzemplo de kiel ni ĉe Netflix efektivigis tian sistemon. Kio funkciis por ni. La aplikata parto de mia raporto por vi estas la principoj de disvolviĝo kaj subteno, kiujn ni sekvas kaj atingas bonajn rezultojn.
Nia solvo al la problemo eble ne konvenas al vi. Tamen, la teorio kaj dezajnoprincipoj restas, eĉ se vi ne havas vian propran CDN-infrastrukturon, aŭ se ĝi diferencas signife de la nia.
La graveco de la rapideco de komercaj petoj ankaŭ restas grava. Kaj eĉ por simpla servo vi devas elekti: inter nubaj provizantoj, serviloko, CDN kaj DNS-provizantoj. Via elekto influos la efikecon de interretaj demandoj por viaj klientoj. Kaj gravas por vi mezuri kaj kompreni ĉi tiun influon.
Komencu per simplaj solvoj, zorgu pri kiel vi ŝanĝas la produkton. Lernu dum vi iras kaj plibonigu la sistemon bazitan sur datumoj de viaj klientoj, via infrastrukturo kaj via komerco. Pensu pri la ebleco de neatenditaj paneoj dum la dezajna procezo. Kaj tiam vi povas akceli vian disvolvan procezon, plibonigi solvan efikecon, eviti nenecesan subtenan ŝarĝon kaj dormi trankvile.
Ĉi-jare en reta formato. Vi povas demandi demandojn al unu el la patroj de DevOps, John Willis mem!
fonto: www.habr.com