Netflix mangrupikeun pamimpin pasar televisi Internét - perusahaan anu nyiptakeun sareng aktip ngembangkeun bagean ieu. Netflix dipikanyaho henteu ngan ukur pikeun katalog pilem sareng séri TV anu sayogi ti ampir unggal juru pangeusina sareng alat naon waé anu gaduh tampilan, tapi ogé pikeun infrastruktur anu dipercaya sareng budaya rékayasa anu unik.
Conto anu jelas ngeunaan pendekatan Netflix pikeun ngembangkeun sareng ngadukung sistem kompleks dibere dina DevOops 2019 - Diréktur Pangwangunan di Netflix. Lulusan Fakultas Matematika Komputasi sareng Matematika di Nizhny Novgorod State University. Lobachevsky, Sergey salah sahiji insinyur munggaran di Open Connect - tim CDN di Netflix. Anjeunna ngawangun sistem pikeun ngawaskeun sareng nganalisa data pidéo, ngaluncurkeun layanan populér pikeun ngevaluasi kacepetan sambungan Internét FAST.com, sareng salami sababaraha taun ka pengker parantos ngusahakeun ngaoptimalkeun paménta Internét supados aplikasi Netflix tiasa dianggo gancang-gancang pikeun pangguna.
laporan narima ulasan pangalusna ti pamilon konferensi, sarta kami geus disiapkeun versi téks pikeun anjeun.
Dina laporan na, Sergei spoke di jéntré
- ngeunaan naon mangaruhan reureuh tina requests Internet antara klien tur server;
- kumaha carana ngurangan reureuh ieu;
- kumaha mendesain, ngajaga jeung ngawas sistem kasalahan-toleran;
- kumaha carana ngahontal hasil dina waktu anu singget, sarta kalawan resiko minimal keur usaha;
- kumaha cara nganalisis hasil sareng diajar tina kasalahan.
Jawaban kana patarosan ieu diperyogikeun henteu ngan ukur ku anu damel di perusahaan ageung.
Prinsip sareng téknik anu ditepikeun kedah dipikanyaho sareng dipraktékkeun ku sadayana anu ngembangkeun sareng ngadukung produk Internét.
Satuluyna nya éta narasi tina jihat panyatur.
Pentingna speed internét
Laju paménta Internét langsung aya hubunganana sareng bisnis. Pertimbangkeun industri balanja: Amazon di 2009 yén reureuh 100ms nyababkeun leungitna 1% tina penjualan.
Aya seueur alat sélulér, dituturkeun ku situs sareng aplikasi sélulér. Upami halaman anjeun peryogi langkung lami ti 3 detik pikeun dimuat, anjeun kaleungitan sakitar satengah pangguna anjeun. JEUNG Google nganggap laju ngamuat halaman anjeun dina hasil pamilarian: langkung gancang halamanna, langkung luhur posisina di Google.
Laju sambungan ogé penting dina lembaga keuangan dimana latency penting. Dina 2015, Hibernia Networks kabel $ 400 juta antara New York jeung London pikeun ngurangan latency antara kota ku 6ms. Bayangkeun $66 juta pikeun 1 mdet pangurangan latency!
nurutkeun , speeds sambungan luhur 5 Mbit / s euweuh langsung mangaruhan speed loading sahiji ramatloka has. Sanajan kitu, aya hubungan linier antara latency sambungan jeung speed loading kaca:
Nanging, Netflix sanés produk biasa. Dampak latency sareng kagancangan dina pangguna mangrupikeun daérah anu aktip dina analisa sareng pamekaran. Aya beban aplikasi sareng pilihan eusi anu gumantung kana latency, tapi ngamuat elemen statik sareng streaming ogé gumantung kana laju sambungan. Nganalisis sareng ngaoptimalkeun faktor konci anu mangaruhan pangalaman pangguna mangrupikeun daérah pangembangan aktip pikeun sababaraha tim di Netflix. Salah sahiji tujuanana nyaéta pikeun ngirangan latency paménta antara alat Netflix sareng infrastruktur awan.
Dina laporan urang bakal museurkeun husus dina ngurangan latency ngagunakeun conto infrastruktur Netflix. Hayu urang nganggap tina sudut pandang praktis kumaha pendekatan kana prosés desain, pamekaran sareng operasi sistem anu disebarkeun rumit sareng nyéépkeun waktos pikeun inovasi sareng hasil, tinimbang ngadiagnosa masalah operasional sareng karusakan.
Di jero Netflix
Rébuan alat anu béda ngadukung aplikasi Netflix. Éta dikembangkeun ku opat tim anu béda, anu ngadamel vérsi klien anu misah pikeun Android, ios, TV sareng browser wéb. Sareng urang nyéépkeun seueur usaha pikeun ningkatkeun sareng nyaluyukeun pangalaman pangguna. Jang ngalampahkeun ieu, urang ngajalankeun ratusan tés A/B paralel.
Personalisasi dirojong ku ratusan microservices dina awan AWS, nyadiakeun data pamaké pribadi, dispatch query, telemétri, Big Data jeung Encoding. Visualisasi lalu lintas sapertos kieu:
Di kénca nyaéta titik éntri, lajeng lalulintas disebarkeun diantara sababaraha ratus microservices nu dirojong ku tim backend béda.
Komponén penting séjén tina infrastruktur kami nyaéta Open Connect CDN, anu nganteurkeun eusi statik ka pangguna akhir - pidéo, gambar, kode klien, jsb. CDN aya dina server khusus (OCA - Open Connect Appliance). Di jero aya susunan SSD sareng HDD drive anu ngajalankeun FreeBSD anu dioptimalkeun, sareng NGINX sareng sakumpulan jasa. Kami ngarancang sareng ngaoptimalkeun komponén hardware sareng software supados server CDN sapertos kitu tiasa ngirim data saloba mungkin ka pangguna.
"Tembok" tina server ieu dina titik bursa lalu lintas Internét (Internet eXchange - IX) sapertos kieu:
Internet Exchange nyadiakeun kamampuhan pikeun panyadia ladenan Internet sarta panyadia eusi pikeun "ngahubungkeun" saling pikeun leuwih langsung tukeur data dina Internét. Aya kira-kira 70-80 titik Internet Exchange di sakumna dunya dimana server kami dipasang, sareng kami sacara mandiri masang sareng ngajagaana:
Salaku tambahan, kami ogé nyayogikeun server langsung ka panyadia Internét, anu aranjeunna pasang dina jaringanna, ningkatkeun lokalisasi lalu lintas Netflix sareng kualitas streaming pikeun pangguna:
Sakumpulan jasa AWS tanggung jawab pikeun ngirim pamundut pidéo ti klien ka server CDN, ogé ngonpigurasikeun server sorangan - ngamutahirkeun eusi, kode program, setélan, jsb. Pikeun anu terakhir, kami ogé ngawangun jaringan tulang tonggong anu nyambungkeun server dina titik Internet Exchange sareng AWS. Jaringan tulang tonggong mangrupikeun jaringan global kabel serat optik sareng router anu urang tiasa ngarancang sareng ngonpigurasikeun dumasar kana kabutuhan urang.
on , infrastruktur CDN kami nganteurkeun kira-kira ⅛ patalimarga Internét sadunya dina jam-jam sibuk jeung ⅓ patalimarga di Amérika Kalér, tempat Netflix pangpanjangna. angka impressive, tapi keur kuring salah sahiji prestasi paling endah nyaeta sakabeh sistem CDN dimekarkeun tur dijaga ku tim kirang ti 150 jalma.
Dina awalna, infrastruktur CDN dirancang pikeun nganteurkeun data video. Nanging, kana waktosna urang sadar yén urang ogé tiasa ngagunakeunana pikeun ngaoptimalkeun paménta dinamis ti klien dina awan AWS.
Ngeunaan akselerasi Internét
Ayeuna, Netflix ngagaduhan 3 daérah AWS, sareng latency pamundut ka méga bakal gumantung kana sabaraha jauh palanggan ti daérah anu pangcaketna. Dina waktos anu sami, urang gaduh seueur server CDN anu dianggo pikeun nganteurkeun eusi statik. Naha aya cara pikeun ngagunakeun kerangka ieu pikeun nyepetkeun patarosan dinamis? Tapi, hanjakalna, mustahil pikeun cache pamundut ieu - API dipersonalisasi sareng unggal hasil unik.
Hayu urang nyieun proxy dina server CDN tur mimitian ngirim lalulintas ngaliwatan eta. Naha bakal langkung gancang?
Materiel
Hayu urang émut kumaha protokol jaringan jalan. Kiwari, kalolobaan patalimarga dina Internét nganggo HTTP, anu gumantung kana protokol lapisan handap TCP sareng TLS. Dina raraga pikeun klien pikeun nyambung ka server, éta ngalakukeun sasalaman, sarta pikeun nyieun sambungan aman, klien nu kudu tukeur pesen jeung server tilu kali sarta sahanteuna hiji deui waktu pikeun mindahkeun data. Kalawan latency per round trip (RTT) 100 mdet, urang bakal butuh 400 mdet pikeun nampa bit mimiti data:
Upami urang nempatkeun sertipikat dina server CDN, maka waktos sasalaman antara klien sareng server tiasa dikirangan sacara signifikan upami CDN langkung caket. Hayu urang anggap latency ka server CDN nyaeta 30ms. Teras peryogi 220 mdet pikeun nampi bit munggaran:
Tapi kauntungan henteu dugi ka dinya. Sakali sambungan geus diadegkeun, TCP ngaronjatkeun jandela kamacetan (jumlah informasi eta bisa ngirimkeun ngaliwatan sambungan éta dina paralel). Upami pakét data leungit, palaksanaan klasik tina protokol TCP (sapertos TCP New Reno) ngirangan "jandela" kabuka ku satengah. Tumuwuhna jandela kamacetan, sarta laju recovery na tina leungitna deui gumantung kana reureuh (RTT) ka server. Upami sambungan ieu ngan ukur dugi ka server CDN, pamulihan ieu bakal langkung gancang. Dina waktos anu sami, leungitna pakét mangrupikeun fenomena standar, khususna pikeun jaringan nirkabel.
Bandwidth Internét tiasa ngirangan, khususna dina jam-jam sibuk, kusabab lalu lintas ti pangguna, anu tiasa nyababkeun macét. Tapi, teu aya deui jalan dina Internét pikeun masihan prioritas kana sababaraha pamundut anu sanés. Contona, masihan prioritas kana requests leutik tur latency-sénsitip leuwih "beurat" aliran data nu ngamuat jaringan. Nanging, dina kasus urang, gaduh jaringan tulang tonggong sorangan ngamungkinkeun urang ngalakukeun ieu dina bagian tina jalur pamundut - antara CDN sareng awan, sareng urang tiasa ngonpigurasikeunana. Anjeun tiasa mastikeun yén pakét leutik sareng sénsitip latency diprioritaskeun, sareng aliran data ageung sakedik engké. Nu ngadeukeutan CDN ka klien, nu gede efisiensi.
Protokol tingkat aplikasi (OSI Level 7) ogé boga dampak dina latency. Protokol anyar sapertos HTTP / 2 tiasa ngaoptimalkeun kinerja pamundut paralel. Nanging, kami ngagaduhan klien Netflix sareng alat anu langkung lami anu henteu ngadukung protokol énggal. Henteu sakabéh klien bisa diropéa atawa ngonpigurasi optimal. Dina waktos anu sami, antara proxy CDN sareng awan aya kontrol lengkep sareng kamampuan ngagunakeun protokol sareng setélan anu énggal. Bagian teu epektip jeung protokol heubeul ngan bakal beroperasi antara klien tur server CDN. Leuwih ti éta, urang bisa nyieun requests multiplex dina sambungan geus ngadegkeun antara CDN jeung awan, ngaronjatkeun utilization sambungan dina tingkat TCP:
Urang ngukur
Najan kanyataan yén téori janji perbaikan, urang teu langsung rurusuhan pikeun ngajalankeun sistem dina produksi. Sabalikna, urang kedah ngabuktikeun heula yén ideu bakal dianggo dina prakna. Jang ngalampahkeun ieu anjeun kudu ngajawab sababaraha patarosan:
- kagancangan: bakal proxy jadi leuwih gancang?
- réliabilitas: Dupi éta langkung sering rusak?
- Kompléksitas: kumaha ngahijikeun sareng aplikasi?
- biaya: Sabaraha biaya nyebarkeun infrastruktur tambahan?
Hayu urang mertimbangkeun sacara rinci pendekatan urang pikeun meunteun titik kahiji. Sésana diurus ku cara anu sami.
Pikeun nganalisis laju pamundut, urang hoyong kéngingkeun data pikeun sadaya pangguna, tanpa nyéépkeun waktos pikeun pangwangunan sareng henteu ngalanggar produksi. Aya sababaraha pendekatan pikeun ieu:
- RUM, atanapi pangukuran pamundut pasip. Urang ngukur waktu palaksanaan requests ayeuna ti pamaké sarta mastikeun cakupan pamaké pinuh. Karugianna nyaéta sinyalna henteu stabil pisan kusabab seueur faktor, contona, kusabab ukuran pamundut anu béda, waktos ngolah dina server sareng klien. Salaku tambahan, anjeun moal tiasa nguji konfigurasi énggal tanpa pangaruh dina produksi.
- Tés laboratorium. server husus sarta infrastruktur nu simulate klien. Kalayan pitulungna kami ngalaksanakeun tés anu diperyogikeun. Ku cara ieu urang kéngingkeun kontrol pinuh kana hasil pangukuran sareng sinyal anu jelas. Tapi euweuh sinyalna lengkep alat jeung lokasi pamaké (utamana jeung layanan sakuliah dunya sarta rojongan pikeun rébuan model alat).
Kumaha anjeun tiasa ngagabungkeun kaunggulan duanana métode?
Tim kami parantos mendakan solusi. Urang nulis sapotong leutik kode - sampel - nu urang diwangun kana aplikasi urang. Panyilidikan ngamungkinkeun urang pikeun ngalakukeun tés jaringan anu dikontrol sapinuhna tina alat urang. Gawéna sapertos kieu:
- Teu lila sanggeus ngamuat aplikasi tur ngalengkepan kagiatan awal, urang ngajalankeun panyilidikan urang.
- Klién ngadamel pamenta ka server sareng nampi "resep" pikeun tés. Resepna mangrupikeun daptar URL dimana pamundut HTTP kedah dilakukeun. Salaku tambahan, resep ngonpigurasikeun parameter pamundut: telat antara pamundut, jumlah data anu dipénta, header HTTP, jsb. Dina waktos anu sami, urang tiasa nguji sababaraha resep anu paralel - nalika nyuhunkeun konfigurasi, urang sacara acak nangtukeun resep anu bakal dikaluarkeun.
- Waktu peluncuran usik dipilih ku kituna teu konflik jeung pamakéan aktip sumberdaya jaringan dina klien nu. Intina, waktos dipilih nalika klien henteu aktip.
- Saatos nampi resep, klien naroskeun ka unggal URL, paralel. Paménta ka unggal alamat tiasa diulang - anu disebut. "pulsa". Dina pulsa munggaran, urang ngukur sabaraha lila waktu nu diperlukeun pikeun nyieun sambungan tur ngundeur data. Dina pulsa kadua, urang ngukur waktu nu diperlukeun pikeun muka data ngaliwatan hiji sambungan geus ngadegkeun. Sateuacan anu katilu, urang tiasa nyetél reureuh sareng ngukur kagancangan ngadamel sambungan deui, jsb.
Salila tés, urang ngukur sadaya parameter anu tiasa dicandak ku alat:
- waktos pamundut DNS;
- waktos setelan sambungan TCP;
- waktos setelan sambungan TLS;
- waktos nampi bait munggaran data;
- total waktos loading;
- kode hasil status.
- Saatos sadayana pulsa parantos réngsé, sampel ngamuat sadaya pangukuran pikeun analisa.
Titik konci anu gumantungna minimal dina logika dina klien, ngolah data dina server jeung pangukuran requests paralel. Ku kituna, urang bisa ngasingkeun jeung nguji pangaruh rupa faktor mangaruhan kinerja query, rupa-rupa aranjeunna dina resep tunggal, sarta ménta hasil ti klien nyata.
Infrastruktur ieu geus kabuktian mangpaat pikeun leuwih ti ngan analisis kinerja query. Ayeuna kami gaduh 14 resep aktip, langkung ti 6000 conto per detik, nampi data ti sakumna penjuru bumi sareng sinyalna alat pinuh. Upami Netflix ngagaleuh jasa anu sami ti pihak katilu, éta bakal ngarugikeun jutaan dolar sataun, kalayan cakupan anu langkung parah.
Téori tés dina prakték: prototipe
Kalayan sistem sapertos kitu, kami tiasa ngevaluasi efektivitas proksi CDN dina latency pamundut. Ayeuna anjeun peryogi:
- nyieun prototipe proxy;
- nempatkeun prototipe dina CDN;
- nangtukeun kumaha ngarahkeun klien ka proxy dina server CDN husus;
- Bandingkeun kinerja kana pamundut di AWS tanpa proxy.
Tugasna nyaéta pikeun meunteun éféktivitas solusi anu diusulkeun gancang-gancang. Kami milih Go pikeun nerapkeun prototipe kusabab kasadiaan perpustakaan jaringan anu saé. Dina unggal server CDN, kami masang prototipe proxy salaku binér statik pikeun ngaleutikan kagumantungan sareng nyederhanakeun integrasi. Dina palaksanaan awal, kami dipaké komponén baku saloba mungkin jeung modifikasi minor pikeun HTTP / 2 sambungan pooling sarta ménta multiplexing.
Pikeun nyaimbangkeun antara daérah AWS, kami nganggo database DNS geografis, anu sami dianggo pikeun nyaimbangkeun klien. Pikeun milih server CDN pikeun klien, kami nganggo TCP Anycast pikeun server di Internet Exchange (IX). Dina pilihan ieu, kami nganggo hiji alamat IP pikeun sakabéh server CDN, sarta klien bakal diarahkeun ka server CDN kalawan jumlah pangsaeutikna hops IP. Dina server CDN anu dipasang ku panyadia Internét (ISP), kami henteu gaduh kontrol kana router pikeun ngonpigurasikeun TCP Anycast, janten kami nganggo , nu ngarahkeun konsumén ka panyadia Internet pikeun streaming video.
Janten, urang gaduh tilu jinis jalur pamundut: ka awan ngalangkungan Internét kabuka, ngalangkungan server CDN di IX, atanapi ngalangkungan server CDN anu aya di panyadia Internét. Tujuan kami nyaéta pikeun ngartos jalan mana anu langkung saé, sareng naon kauntungan tina proxy, dibandingkeun sareng kumaha paménta dikirim ka produksi. Jang ngalampahkeun ieu, kami nganggo sistem sampling sapertos kieu:
Masing-masing jalur janten udagan anu misah, sareng urang tingali dina waktosna. Pikeun analisa, urang ngagabungkeun hasil proksi kana hiji grup (pilih waktos pangsaéna antara proksi IX sareng ISP), sareng bandingkeun sareng waktos pamundut ka awan tanpa proksi:
Sakumaha anjeun tiasa tingali, hasilna dicampurkeun - dina kalolobaan kasus proxy méré speedup alus, tapi aya ogé sajumlah cukup klien pikeun saha kaayaan bakal worsen nyata.
Hasilna, urang ngalakukeun sababaraha hal penting:
- Urang ditaksir kinerja ekspektasi requests ti klien ka awan via proxy CDN.
- Kami nampi data ti klien nyata, tina sagala jinis alat.
- Kami sadar yén téori éta henteu 100% dikonfirmasi sareng tawaran awal sareng proxy CDN moal tiasa dianggo pikeun urang.
- Kami henteu nyandak résiko - kami henteu ngarobih konfigurasi produksi pikeun klien.
- Euweuh nu pegat.
Prototipe 2.0
Janten, balik deui ka papan gambar sareng malikan deui prosésna deui.
Ide éta tinimbang ngagunakeun 100% proxy, urang bakal nangtukeun jalur panggancangna pikeun tiap klien, sarta kami bakal ngirim requests aya - nyaeta, urang bakal ngalakukeun naon nu disebut klien steering.
Kumaha nerapkeun ieu? Kami henteu tiasa nganggo logika dina sisi server, sabab ... Tujuanana nyaéta pikeun nyambung ka server ieu. Perlu aya sababaraha cara pikeun ngalakukeun ieu dina klien. Jeung ideally, ngalakukeun ieu kalawan jumlah minimum logika kompléks, ku kituna teu ngajawab masalah integrasi jeung sajumlah badag platform klien.
Dina jawaban eta ngagunakeun DNS. Dina hal urang, urang gaduh infrastruktur DNS sorangan, sareng urang tiasa nyetél zona domain dimana server kami bakal otoriter. Gawéna sapertos kieu:
- Klién ngadamel pamundut ka server DNS nganggo host, contona api.netflix.xom.
- Paménta sumping ka server DNS kami
- Server DNS terang jalur mana anu panggancangna pikeun klien ieu sareng ngaluarkeun alamat IP anu saluyu.
Solusina ngagaduhan pajeulitna tambahan: panyadia DNS otoriter henteu ningali alamat IP klien sareng ngan ukur tiasa maca alamat IP tina rékursif rékursif anu dianggo ku klien.
Hasilna, solver otoriter urang kedah nyandak kaputusan sanes pikeun klien individu, tapi pikeun grup klien dumasar kana solver rekursif.
Pikeun ngabéréskeun, kami nganggo conto anu sami, agrégat hasil pangukuran tina klien pikeun tiap rékursif rékursif sareng mutuskeun dimana ngirim grup ieu di antarana - proxy ngaliwatan IX nganggo TCP Anycast, ngaliwatan proxy ISP, atanapi langsung ka awan.
Simkuring meunang sistem handap:
Model steering DNS anu dihasilkeun ngamungkinkeun anjeun langsung klien dumasar kana observasi sajarah laju sambungan ti klien ka awan.
Sakali deui, patarosan kumaha efektifna pendekatan ieu tiasa dianggo? Pikeun ngajawab, urang deui ngagunakeun sistem usik urang. Ku alatan éta, urang ngonpigurasikeun konfigurasi presenter, dimana salah sahiji udagan nuturkeun arah ti DNS steering, nu sejenna mana langsung ka awan (produksi ayeuna).
Hasilna, urang ngabandingkeun hasil sareng kéngingkeun evaluasi efektivitas:
Hasilna, urang diajar sababaraha hal penting:
- Urang ditaksir kinerja ekspektasi requests ti klien ka awan ngagunakeun DNS Steering.
- Kami nampi data ti klien nyata, tina sagala jinis alat.
- Éféktivitas gagasan anu diusulkeun parantos kabuktosan.
- Kami henteu nyandak résiko - kami henteu ngarobih konfigurasi produksi pikeun klien.
- Euweuh nu pegat.
Ayeuna ngeunaan bagian sesah - urang ngajalankeun eta dina produksi
Bagian anu gampang ayeuna parantos réngsé - aya prototipe anu tiasa dianggo. Ayeuna bagian anu sesah nyaéta ngaluncurkeun solusi pikeun sadaya lalu lintas Netflix, nyebarkeun ka 150 juta pangguna, rébuan alat, ratusan jasa mikro, sareng produk sareng infrastruktur anu kantos robih. Server Netflix nampi jutaan pamenta per detik, sareng gampang pikeun ngarecah jasa kalayan tindakan anu teu ati-ati. Dina waktu nu sarua, urang hayang dinamis ruteu lalulintas ngaliwatan rébuan server CDN on Internét, dimana hal robah sarta ngarecah terus jeung dina momen paling inopportune.
Sareng sadaya ieu, tim ngagaduhan 3 insinyur anu tanggung jawab pikeun pangwangunan, panyebaran sareng dukungan pinuh ku sistem.
Ku alatan éta, urang bakal neruskeun ngobrol ngeunaan sare tenang jeung séhat.
Kumaha neraskeun pangwangunan sareng henteu nyéépkeun waktos anjeun pikeun ngadukung? Pendekatan kami dumasar kana 3 prinsip:
- Urang ngurangan skala poténsi breakdowns (radius ledakan).
- Kami Nyiapkeun kejutan - kami ngarepkeun yén aya anu bakal rusak, sanaos tés sareng pangalaman pribadi.
- Degradasi anggun - upami aya anu henteu jalan leres, éta kedah dibenerkeun sacara otomatis, sanaos henteu ku cara anu paling éfisién.
Tétéla dina hal urang, kalawan pendekatan ieu masalah, urang bisa manggihan solusi basajan tur éféktif jeung nyata simplify rojongan sistem. Urang sadar yen urang bisa nambahkeun sapotong leutik kode ka klien tur ngawas kasalahan pamundut jaringan disababkeun ku masalah sambungan. Dina hal kasalahan jaringan, urang nyieun fallback langsung ka awan. Leyuran ieu teu merlukeun usaha signifikan pikeun tim klien, tapi greatly ngurangan résiko breakdowns kaduga jeung kejutan keur urang.
Tangtosna, sanaos mundur, urang tetep nuturkeun disiplin anu jelas nalika pangwangunan:
- Tés sampel.
- A / B nguji atawa Canaries.
- Rollout kutang.
Kalayan conto, pendekatan parantos dijelaskeun - perobahan munggaran diuji nganggo resep anu disaluyukeun.
Pikeun nguji kanaria, urang kedah kéngingkeun pasangan server anu tiasa dibandingkeun dimana urang tiasa ngabandingkeun kumaha sistem jalan sateuacan sareng saatos parobihan. Jang ngalampahkeun ieu, tina seueur situs CDN kami, kami milih pasangan server anu nampi lalu lintas anu sami:
Teras we masang ngawangun sareng parobihan dina server Canary. Pikeun meunteun hasil, kami ngajalankeun sistem anu ngabandingkeun sakitar 100-150 métrik sareng conto server Kontrol:
Upami uji Canary suksés, maka urang ngaleupaskeun sacara bertahap, dina gelombang. Kami henteu ngamutahirkeun server dina unggal situs dina waktos anu sami - kaleungitan sadaya situs kusabab masalah gaduh dampak anu langkung signifikan dina jasa pikeun pangguna tibatan kaleungitan jumlah server anu sami di lokasi anu béda.
Sacara umum, efektivitas sareng kasalametan pendekatan ieu gumantung kana kuantitas sareng kualitas métrik anu dikumpulkeun. Pikeun sistem akselerasi pamundut urang, urang ngumpulkeun métrik tina sakabéh komponén mungkin:
- ti klien - Jumlah sesi na requests, ongkos fallback;
- proxy - statistik dina jumlah jeung waktu requests;
- DNS - jumlah jeung hasil requests;
- ujung awan - jumlah jeung waktu pikeun ngolah requests dina awan.
Sadaya ieu dikumpulkeun kana pipa tunggal, sareng, gumantung kana kabutuhan, urang mutuskeun métrik mana anu dikirimkeun ka analytics real-time, sareng anu ka Elasticsearch atanapi Big Data pikeun diagnostik anu langkung rinci.
Urang ngawaskeun
Dina kasus urang, urang nyieun parobahan dina jalur kritis requests antara klien tur server. Dina waktos anu sami, jumlah komponén anu béda dina klien, dina server, sareng dina jalan ngalangkungan Internét ageung pisan. Parobahan dina klien tur server lumangsung terus - salila karya puluhan tim sarta parobahan alam dina ékosistem. Kami di tengah - nalika ngadiagnosa masalah, aya kasempetan anu hadé pikeun urang aub. Ku alatan éta, urang kudu jelas ngarti kumaha carana nangtukeun, ngumpulkeun jeung nganalisis metrics pikeun gancang ngasingkeun masalah.
Ideally, aksés pinuh ka sakabeh tipe metrics jeung saringan sacara real waktu. Tapi aya seueur métrik, janten patarosan biaya timbul. Dina kasus urang, urang misahkeun métrik sareng alat pamekaran sapertos kieu:
Pikeun ngadeteksi sareng ngémutan masalah, kami nganggo sistem real-time open-source kami sorangan и - pikeun visualisasi. Éta nyimpen métrik agrégat dina mémori, tiasa dipercaya sareng ngahiji sareng sistem peringatan. Pikeun lokalisasi sareng diagnostik, kami ngagaduhan aksés kana log ti Elasticsearch sareng Kibana. Pikeun analisa statistik sareng modeling, kami nganggo data ageung sareng visualisasi dina Tableau.
Sigana yén pendekatan ieu hésé pisan dianggo. Nanging, ku cara ngatur métrik sareng alat sacara hierarki, urang tiasa gancang nganalisis masalah, nangtukeun jinis masalah, teras ngebor kana métrik anu lengkep. Sacara umum, urang méakkeun ngeunaan 1-2 menit pikeun ngaidentipikasi sumber ngarecahna. Saatos ieu, urang damel sareng tim khusus dina diagnostik - tina puluhan menit dugi ka sababaraha jam.
Sanaos diagnosisna dilakukeun gancang, kami henteu hoyong ieu sering kajadian. Ideally, urang ngan bakal nampa hiji ngageter kritis lamun aya dampak signifikan dina jasa. Pikeun sistem akselerasi query kami, kami ngan ukur gaduh 2 panggeuing anu bakal ngabéjaan:
- perséntase Fallback klien - assessment kabiasaan customer;
- kasalahan Probe perséntase - data stabilitas komponén jaringan.
Panggeuing kritis ieu ngawaskeun naha sistemna jalan pikeun seuseueurna pangguna. Kami ningali sabaraha klien anu nganggo fallback upami aranjeunna henteu tiasa nampi akselerasi pamundut. Urang rata-rata kirang ti 1 ngageter kritis per minggu, sanajan aya ton parobahan lumangsung dina sistem. Naha ieu cekap pikeun urang?
- Aya fallback klien lamun proxy urang teu jalan.
- Aya sistem steering otomatis nu responds kana masalah.
Leuwih jéntré ngeunaan dimungkinkeun. Sistim percobaan kami, sarta sistem pikeun otomatis nangtukeun jalur optimal pikeun requests ti klien ka awan, ngamungkinkeun urang pikeun otomatis Cope jeung sababaraha masalah.
Hayu urang balik deui ka konfigurasi sampel urang jeung 3 kategori jalur. Salian waktos loading, urang tiasa ningali kanyataan pangiriman sorangan. Upami teu mungkin pikeun ngamuat data, maka ku ningali hasil sapanjang jalur anu béda-béda urang tiasa nangtoskeun dimana sareng naon anu rusak, sareng naha urang tiasa sacara otomatis ngalereskeunana ku cara ngarobih jalur pamundut.
conto:
Prosés ieu tiasa otomatis. Kaasup kana sistem setir. Sareng ngajarkeun éta pikeun ngabales masalah kinerja sareng réliabilitas. Upami aya anu mimiti rusak, réspon upami aya pilihan anu langkung saé. Dina waktu nu sarua, réaksi saharita teu kritis, hatur nuhun kana fallback on klien.
Ku kituna, prinsip pangrojong sistem bisa dirumuskeun saperti kieu:
- ngurangan skala breakdowns;
- ngumpulkeun métrik;
- Urang otomatis ngalereskeun breakdowns lamun urang bisa;
- lamun teu bisa, kami ngabéjaan;
- Kami nuju damel dina dasbor sareng set alat triage pikeun réspon gancang.
Pangajaran Diajar
Teu butuh loba waktu pikeun nulis prototipe. Dina kasus urang, éta siap sanggeus 4 bulan. Kalayan éta kami nampi métrik énggal, sareng 10 bulan saatos ngamimitian pangwangunan kami nampi lalu lintas produksi munggaran. Lajeng karya tedious sarta hésé pisan dimimitian: laun productize jeung skala sistem, migrasi lalulintas utama jeung diajar tina kasalahan. Sanajan kitu, prosés éféktif ieu moal linier - sanajan sagala usaha, sagalana teu bisa diprediksi. Éta langkung épéktip pikeun gancang ngulang sareng ngaréspon data énggal.
Dumasar pangalaman urang, urang tiasa nyarankeun ieu:
- Entong percanten ka intuisi anjeun.
Intuisi kami gagal terus-terusan, sanaos pangalaman anggota tim kami anu ageung. Contona, urang salah prediksi ekspektasi speedup tina ngagunakeun proxy CDN, atawa paripolah TCP Anycast.
- Kéngingkeun data tina produksi.
Kadé meunang aksés ka sahenteuna jumlah leutik data produksi gancang-gancang. Ampir teu mungkin pikeun ménta jumlah kasus unik, konfigurasi, sareng setelan dina kondisi laboratorium. Aksés gancang kana hasil bakal ngamungkinkeun anjeun gancang diajar ngeunaan masalah poténsial sareng tumut kana arsitéktur sistem.
- Entong nuturkeun naséhat sareng hasil batur - kumpulkeun data anjeun nyalira.
Turutan prinsip pikeun ngumpulkeun jeung nganalisis data, tapi ulah ambing narima hasil jeung pernyataan batur. Ngan anjeun tiasa terang persis naon anu dianggo pikeun pangguna anjeun. Sistem anjeun sareng palanggan anjeun tiasa béda sacara signifikan ti perusahaan sanés. Untungna, alat analisis ayeuna sayogi sareng gampang dianggo. Hasil anu anjeun pikahoyong tiasa henteu sapertos anu diklaim Netflix, Facebook, Akamai sareng perusahaan sanés. Dina kasus urang, kinerja TLS, HTTP2 atawa statistik on requests DNS béda ti hasil Facebook, Uber, Akamai - sabab urang boga alat béda, klien tur aliran data.
- Ulah nuturkeun tren fashion unnecessarily tur evaluate efektivitas.
Mimitian basajan. Éta langkung saé ngadamel sistem kerja saderhana dina waktos anu pondok tibatan nyéépkeun waktos anu ageung pikeun ngembangkeun komponén anu anjeun henteu peryogikeun. Ngabéréskeun tugas sareng masalah anu penting dumasar kana pangukuran sareng hasil anjeun.
- Siap pikeun aplikasi anyar.
Sagampil hese ngaduga sagala masalah, hese ngaduga kauntungan sarta aplikasi sateuacanna. Candak cue ti startups - kamampuhna pikeun adaptasi jeung kaayaan customer. Dina kasus anjeun, anjeun tiasa mendakan masalah anyar sareng solusina. Dina proyék kami, kami netepkeun tujuan pikeun ngirangan latency pamundut. Nanging, salami analisa sareng diskusi, urang sadar yén urang ogé tiasa nganggo server proxy:
- pikeun nyaimbangkeun lalu lintas di daérah AWS sareng ngirangan biaya;
- pikeun modél stabilitas CDN;
- pikeun ngonpigurasikeun DNS;
- pikeun ngonpigurasikeun TLS / TCP.
kacindekan
Dina laporan, kuring ngajelaskeun kumaha Netflix ngabéréskeun masalah ngagancangkeun paménta Internét antara klien sareng awan. Kumaha urang ngumpulkeun data ngagunakeun sistem sampling on klien, sarta ngagunakeun data sajarah dikumpulkeun pikeun requests produksi jalur ti klien ngaliwatan jalur panggancangna dina Internét. Kumaha kami nganggo prinsip protokol jaringan, infrastruktur CDN kami, jaringan tulang tonggong, sareng server DNS pikeun ngahontal tugas ieu.
Nanging, solusi kami ngan ukur conto kumaha kami di Netflix ngalaksanakeun sistem sapertos kitu. Naon digawé pikeun urang. Bagian anu diterapkeun tina laporan kuring pikeun anjeun nyaéta prinsip pangwangunan sareng dukungan anu kami tuturkeun sareng ngahontal hasil anu saé.
Solusi kami pikeun masalah éta moal cocog sareng anjeun. Nanging, téori sareng prinsip desain tetep, sanaos anjeun henteu gaduh infrastruktur CDN anjeun nyalira, atanapi upami éta béda sacara signifikan ti kami.
Pentingna laju paménta bisnis ogé tetep penting. Komo pikeun layanan basajan anjeun kudu nyieun pilihan: antara panyadia awan, lokasi server, CDN jeung panyadia DNS. Pilihan anjeun bakal mangaruhan efektivitas patarosan Internét pikeun konsumén anjeun. Sareng penting pikeun anjeun ngukur sareng ngartos pangaruh ieu.
Mimitian ku solusi basajan, paduli kumaha anjeun ngarobah produk. Diajar nalika anjeun angkat sareng ningkatkeun sistem dumasar kana data ti palanggan anjeun, infrastruktur anjeun, sareng bisnis anjeun. Pikirkeun kamungkinan karusakan anu teu kaduga dina prosés desain. Teras anjeun tiasa nyepetkeun prosés pangembangan anjeun, ningkatkeun efisiensi solusi, ngahindarkeun beban dukungan anu teu perlu sareng bobo kalayan damai.
taun ieu dina format online. Anjeun tiasa naroskeun patarosan ka salah sahiji bapa DevOps, John Willis nyalira!
sumber: www.habr.com