Netflix minangka pimpinan ing pasar televisi Internet - perusahaan sing nggawe lan aktif ngembangake segmen iki. Netflix dikenal ora mung amarga katalog film lan serial TV sing kasedhiya saka meh kabeh pojok planet lan piranti apa wae sing duwe tampilan, nanging uga kanggo infrastruktur sing dipercaya lan budaya teknik sing unik.
Conto sing jelas babagan pendekatan Netflix kanggo ngembangake lan ndhukung sistem kompleks ditampilake ing DevOops 2019 - Direktur Pengembangan ing Netflix. Lulusan Fakultas Matematika Komputasi lan Matematika saka Universitas Negeri Nizhny Novgorod. Lobachevsky, Sergey salah sawijining insinyur pisanan ing Open Connect - tim CDN ing Netflix. Dheweke mbangun sistem kanggo ngawasi lan nganalisa data video, ngluncurake layanan populer kanggo ngevaluasi kacepetan sambungan Internet FAST.com, lan sawetara taun kepungkur wis ngupayakake ngoptimalake panjaluk Internet supaya aplikasi Netflix bisa digunakake kanthi cepet kanggo pangguna.
Laporan kasebut nampa review paling apik saka peserta konferensi, lan kita wis nyiapake versi teks kanggo sampeyan.
Ing laporan, Sergei ngandika rinci
- babagan apa sing mengaruhi wektu tundha panjaluk Internet antarane klien lan server;
- carane nyuda wektu tundha iki;
- carane ngrancang, njaga lan ngawasi sistem kesalahan-toleran;
- carane entuk asil ing wektu cendhak, lan karo resiko minimal kanggo bisnis;
- carane nganalisa asil lan sinau saka kesalahan.
Jawaban kanggo pitakonan kasebut dibutuhake ora mung dening wong-wong sing kerja ing perusahaan gedhe.
Prinsip lan teknik sing disedhiyakake kudu dingerteni lan ditindakake dening saben wong sing ngembangake lan ndhukung produk Internet.
Sabanjure yaiku narasi saka sudut pandang penutur.
Pentinge kacepetan internet
Kacepetan panjaluk Internet langsung ana hubungane karo bisnis. Coba industri blanja: Amazon ing 2009 yen wektu tundha 100ms nyebabake mundhut 1% saka dodolan.
Ana liyane lan liyane piranti seluler, ngiring dening situs seluler lan aplikasi. Yen kaca sampeyan butuh luwih saka 3 detik kanggo mbukak, sampeyan bakal kelangan setengah pangguna. KARO Google nganggep kacepetan loading kaca sampeyan ing asil panelusuran: luwih cepet kaca kasebut, luwih dhuwur posisine ing Google.
Kacepetan sambungan uga penting ing institusi finansial sing latensi kritis. Ing 2015, Hibernia Networks kabel $ 400 yuta antarane New York lan London kanggo nyuda latensi antarane kutha-kutha kanthi 6ms. Bayangake $66 yuta kanggo 1 ms pengurangan latensi!
Miturut , kacepetan sambungan ndhuwur 5 Mbit / s ora langsung mengaruhi kacepetan loading situs web khas. Nanging, ana hubungan linear antarane latensi sambungan lan kacepetan mbukak kaca:
Nanging, Netflix dudu produk sing umum. Dampak latensi lan kacepetan ing pangguna minangka area analisis lan pangembangan sing aktif. Ana loading aplikasi lan pilihan isi sing gumantung ing latensi, nanging ngemot unsur statis lan streaming uga gumantung ing kacepetan sambungan. Nganalisa lan ngoptimalake faktor kunci sing mengaruhi pengalaman pangguna minangka area pangembangan aktif kanggo sawetara tim ing Netflix. Salah sawijining tujuan yaiku nyuda latensi panjaluk antarane piranti Netflix lan infrastruktur awan.
Ing laporan kasebut, kita bakal fokus khusus kanggo nyuda latensi nggunakake conto infrastruktur Netflix. Ayo nimbang saka sudut pandang praktis carane nyedhaki proses desain, pangembangan lan operasi sistem distribusi sing rumit lan nglampahi wektu kanggo inovasi lan asil, tinimbang diagnosa masalah operasional lan kerusakan.
Nang Netflix
Ewonan piranti sing beda-beda ndhukung aplikasi Netflix. Aplikasi kasebut dikembangake dening patang tim sing beda-beda, saben tim nggawe versi klien sing kapisah kanggo Android, iOS, TV, lan browser web. Kita uga lagi kerja keras kanggo ningkatake lan nggawe pengalaman pangguna luwih pribadi, kanthi nglakokake atusan tes A/B kanthi paralel.
Personalisasi didhukung dening atusan microservices ing awan AWS, nyedhiyakake data pangguna pribadi, kiriman pitakon, telemetri, Big Data lan Encoding. Visualisasi lalu lintas katon kaya iki:
Ing sisih kiwa ana titik entri, banjur lalu lintas disebarake ing antarane sawetara atus layanan mikro sing didhukung dening tim backend sing beda.
Komponen penting liyane saka infrastruktur kita yaiku Open Connect CDN, sing ngirim konten statis menyang pangguna pungkasan - video, gambar, kode klien, lsp. CDN dumunung ing server khusus (OCA - Open Connect Appliance). Ing njero ana susunan drive SSD lan HDD sing dioptimalake FreeBSD, kanthi NGINX lan sakumpulan layanan. Kita ngrancang lan ngoptimalake komponen hardware lan piranti lunak supaya server CDN kasebut bisa ngirim data sabisa kanggo pangguna.
"Tembok" saka server kasebut ing titik ijol-ijolan lalu lintas Internet (Internet eXchange - IX) katon kaya iki:
Internet Exchange nyedhiyakake kemampuan kanggo panyedhiya layanan Internet lan panyedhiya konten kanggo "nyambung" karo siji liyane supaya luwih langsung ngganti data ing Internet. Ana kira-kira 70-80 titik Internet Exchange ing saindenging jagad ing ngendi server kita diinstal, lan kita nginstal lan njaga kanthi mandiri:
Kajaba iku, kita uga nyedhiyakake server langsung menyang panyedhiya Internet, sing diinstal ing jaringan, nambah lokalisasi lalu lintas Netflix lan kualitas streaming kanggo pangguna:
Sakumpulan layanan AWS tanggung jawab kanggo ngirim panjalukan video saka klien menyang server CDN, uga ngatur server dhewe - nganyari konten, kode program, setelan, lsp. Kanggo sing terakhir, kita uga mbangun jaringan backbone sing nyambungake server ing titik Internet Exchange karo AWS. Jaringan backbone minangka jaringan kabel lan router serat optik global sing bisa didesain lan dikonfigurasi adhedhasar kabutuhan.
Miturut , infrastruktur CDN kita ngirimake kira-kira β lalu lintas Internet ing donya sajrone jam sibuk lan β lalu lintas ing Amerika Utara, ing ngendi Netflix wis paling dawa. Nomer nyengsemaken, nanging kanggo kula siji saka prestasi paling apik tenan iku kabeh sistem CDN dikembangakΓ© lan maintained dening tim kurang saka 150 wong.
Kaping pisanan, infrastruktur CDN dirancang kanggo ngirim data video. Nanging, liwat wektu kita nyadari yen kita uga bisa nggunakake aplikasi kasebut kanggo ngoptimalake panjalukan dinamis saka klien ing awan AWS.
Babagan nyepetake Internet
Saiki, Netflix duwe 3 wilayah AWS, lan latensi panjaluk menyang awan bakal gumantung saka jarak pelanggan saka wilayah sing paling cedhak. Ing wektu sing padha, kita duwe akeh server CDN sing digunakake kanggo ngirim konten statis. Apa ana cara kanggo nggunakake kerangka iki kanggo nyepetake pitakon dinamis? Nanging, sayangΓ©, ora bisa nyimpen panjalukan kasebut - API dipersonalisasi lan saben asil unik.
Ayo nggawe proxy ing server CDN lan miwiti ngirim lalu lintas liwat. Apa bakal luwih cepet?
materi
Ayo elinga cara kerja protokol jaringan. Saiki, umume lalu lintas ing Internet nggunakake HTTP, sing gumantung marang protokol lapisan ngisor TCP lan TLS. Supaya klien bisa nyambung menyang server, iku nindakake salaman, lan kanggo nggawe sambungan aman, klien kudu ijol-ijolan pesen karo server kaping telu lan ing paling siji wektu liyane kanggo nransfer data. Kanthi latency per round trip (RTT) 100 ms, butuh 400 ms kanggo nampa bit pertama data:
Yen kita nyelehake sertifikat ing server CDN, wektu salaman antarane klien lan server bisa dikurangi kanthi signifikan yen CDN luwih cedhak. Ayo nganggep latensi menyang server CDN yaiku 30ms. Banjur bakal njupuk 220 ms kanggo nampa bit pisanan:
Nanging kaluwihan ora mungkasi ana. Sawise sambungan wis ditetepake, TCP nambah jendhela kemacetan (jumlah informasi sing bisa dikirim liwat sambungan kasebut kanthi paralel). Yen paket data ilang, banjur implementasi klasik saka protokol TCP (kaya TCP New Reno) nyuda mbukak "jendhela" dening setengah. Wutah saka jendhela rame, lan kacepetan Recovery saka mundhut maneh gumantung ing wektu tundha (RTT) kanggo server. Yen sambungan iki mung nganti server CDN, pemulihan iki bakal luwih cepet. Ing wektu sing padha, mundhut paket minangka fenomena standar, utamane kanggo jaringan nirkabel.
Bandwidth internet bisa uga suda, utamane nalika jam sibuk, amarga lalu lintas saka pangguna, sing bisa nyebabake macet. Nanging, ora ana cara ing Internet kanggo menehi prioritas kanggo sawetara panjaluk tinimbang liyane. Contone, menehi prioritas kanggo panjalukan cilik lan latensi-sensitif liwat aliran data "abot" sing mbukak jaringan. Nanging, ing kasus kita, duwe jaringan backbone dhewe ngidini kita nindakake iki ing bagean panyuwunan - antarane CDN lan awan, lan kita bisa ngatur kanthi lengkap. Sampeyan bisa mesthekake yen paket cilik lan latensi-sensitif diprioritasake, lan aliran data gedhe bakal cepet. Sing luwih cedhak CDN menyang klien, efisiensi sing luwih gedhe.
Protokol tingkat aplikasi (OSI Level 7) uga duwe pengaruh marang latensi. Protokol anyar kayata HTTP / 2 ngoptimalake kinerja panjalukan paralel. Nanging, kita duwe klien Netflix karo piranti lawas sing ora ndhukung protokol anyar. Ora kabeh klien bisa dianyari utawa dikonfigurasi kanthi optimal. Ing wektu sing padha, ing antarane proxy CDN lan awan ana kontrol lengkap lan kemampuan kanggo nggunakake protokol lan setelan sing anyar lan optimal. Sisih ora efektif karo protokol lawas mung bakal operate antarane klien lan server CDN. Kajaba iku, kita bisa nggawe panjalukan multiplex ing sambungan sing wis ana ing antarane CDN lan awan, nambah panggunaan sambungan ing tingkat TCP:
Kita ngukur
Sanajan kasunyatane teori kasebut njanjeni perbaikan, kita ora langsung cepet-cepet ngluncurake sistem kasebut ing produksi. Nanging, luwih dhisik kita kudu mbuktekake manawa ide kasebut bakal ditindakake. Kanggo nindakake iki, sampeyan kudu mangsuli sawetara pitakonan:
- Kacepetan: bakal proxy luwih cepet?
- Linuwih: Apa bakal luwih kerep rusak?
- Kompleksitas: carane nggabungake karo aplikasi?
- biaya: Pira regane kanggo masang infrastruktur tambahan?
Ayo kita nimbang kanthi rinci pendekatan kita kanggo netepake titik pisanan. Liyane ditangani kanthi cara sing padha.
Kanggo nganalisa kacepetan panjaluk, kita pengin entuk data kanggo kabeh pangguna, tanpa mbuwang akeh wektu kanggo pangembangan lan tanpa ngilangi produksi. Ana sawetara pendekatan kanggo iki:
- RUM, utawa pangukuran panyuwunan pasif. Kita ngukur wektu eksekusi panjalukan saiki saka pangguna lan njamin jangkoan pangguna lengkap. Kerugian kasebut yaiku sinyal kasebut ora stabil amarga akeh faktor, umpamane, amarga ukuran panyuwunan sing beda, wektu pangolahan ing server lan klien. Kajaba iku, sampeyan ora bisa nyoba konfigurasi anyar tanpa efek ing produksi.
- Tes laboratorium. Server lan infrastruktur khusus sing simulasi klien. Kanthi bantuan, kita nindakake tes sing dibutuhake. Kanthi cara iki, kita bisa ngontrol asil pangukuran lan sinyal sing jelas. Nanging ora ana jangkoan lengkap piranti lan lokasi pangguna (utamane karo layanan lan dhukungan ing saindenging jagad kanggo ewu model piranti).
Kepiye sampeyan bisa nggabungake kaluwihan saka loro cara kasebut?
Tim kita wis nemokake solusi. Kita nulis potongan kode cilik - conto - sing dibangun ing aplikasi kita. Probe ngidini kita nindakake tes jaringan sing dikontrol kanthi lengkap saka piranti kita. Kerjane kaya iki:
- Sakcepete sawise mbukak aplikasi lan ngrampungake kegiatan awal, kita mbukak probe.
- Klien nggawe panjaluk menyang server lan nampa "resep" kanggo tes kasebut. Resep kasebut minangka dhaptar URL sing kudu dijaluk HTTP. Kajaba iku, resep ngatur paramèter panyuwunan: telat ing antarane panjalukan, jumlah data sing dijaluk, header HTTP, lsp. Ing wektu sing padha, kita bisa nguji sawetara resep-resep sing beda-beda kanthi podo karo - nalika njaluk konfigurasi, kita kanthi acak nemtokake resep sing bakal diterbitake.
- Wektu peluncuran probe dipilih supaya ora konflik karo panggunaan sumber daya jaringan sing aktif ing klien. Ateges, wektu dipilih nalika klien ora aktif.
- Sawise nampa resep, klien nggawe panjalukan kanggo saben URL, kanthi paralel. Panjaluk kanggo saben alamat bisa diulang - sing diarani. "pulsa". Ing pulsa pisanan, kita ngukur suwene wektu kanggo nggawe sambungan lan ngundhuh data. Ing pulsa kapindho, kita ngukur wektu sing dibutuhake kanggo mbukak data liwat sambungan sing wis ditemtokake. Sadurunge sing katelu, kita bisa nyetel wektu tundha lan ngukur kacepetan nggawe sambungan maneh, lsp.
Sajrone tes, kita ngukur kabeh parameter sing bisa diduweni piranti:
- wektu panjalukan DNS;
- wektu persiyapan sambungan TCP;
- wektu persiyapan sambungan TLS;
- wektu nampa data byte pisanan;
- wektu loading total;
- kode asil status.
- Sawise kabeh pulsa wis rampung, sampel ngemot kabeh pangukuran kanggo analisis.
Titik utama yaiku katergantungan minimal ing logika ing klien, pangolahan data ing server lan pangukuran panjalukan paralel. Mangkono, kita bisa ngisolasi lan nguji pengaruh saka macem-macem faktor sing mengaruhi kinerja query, beda-beda ing resep siji, lan entuk asil saka klien nyata.
Infrastruktur iki wis kabukten migunani kanggo luwih saka analisis kinerja pitakon. Saiki kita duwe 14 resep aktif, luwih saka 6000 conto per detik, nampa data saka kabeh sudhut bumi lan jangkoan piranti lengkap. Yen Netflix tuku layanan sing padha saka pihak katelu, regane jutaan dolar saben taun, kanthi jangkoan sing luwih elek.
Tes teori ing praktik: prototipe
Kanthi sistem kasebut, kita bisa ngevaluasi efektifitas proksi CDN babagan latensi panyuwunan. Saiki sampeyan butuh:
- nggawe prototipe proxy;
- nyelehake prototipe ing CDN;
- nemtokake cara ngarahake klien menyang proxy ing server CDN tartamtu;
- Bandingake kinerja kanggo panjalukan ing AWS tanpa proxy.
Tugase yaiku ngevaluasi efektifitas solusi sing diusulake kanthi cepet. Kita milih Go kanggo ngleksanakake prototipe amarga kasedhiyan perpustakaan jaringan sing apik. Ing saben server CDN, kita nginstal prototipe proxy minangka binar statis kanggo nyilikake dependensi lan nyederhanakake integrasi. Ing implementasine awal, kita nggunakake komponen standar sabisa lan modifikasi cilik kanggo HTTP / 2 sambungan pooling lan njaluk multiplexing.
Kanggo ngimbangi antarane wilayah AWS, kita nggunakake database DNS geografis, sing padha digunakake kanggo ngimbangi klien. Kanggo milih server CDN kanggo klien, kita nggunakake TCP Anycast kanggo server ing Internet Exchange (IX). Ing pilihan iki, kita nggunakake siji alamat IP kanggo kabeh server CDN, lan klien bakal diarahake menyang server CDN karo nomer paling IP hop. Ing server CDN sing diinstal dening panyedhiya Internet (ISP), kita ora duwe kontrol liwat router kanggo ngatur TCP Anycast, mula kita nggunakake , sing ngarahake pelanggan menyang panyedhiya Internet kanggo streaming video.
Dadi, kita duwe telung jinis jalur panyuwunan: menyang awan liwat Internet sing mbukak, liwat server CDN ing IX, utawa liwat server CDN sing ana ing panyedhiya Internet. Tujuan kita yaiku kanggo ngerti cara sing luwih apik, lan apa keuntungan saka proxy, dibandhingake karo carane panjalukan dikirim menyang produksi. Kanggo nindakake iki, kita nggunakake sistem sampling kaya ing ngisor iki:
Saben dalan dadi target sing kapisah, lan kita ndeleng wektu sing entuk. Kanggo analisis, kita gabungke asil proxy dadi siji klompok (milih wektu paling apik antarane proxy IX lan ISP), lan mbandhingake karo wektu panjalukan menyang awan tanpa proxy:
Kaya sing sampeyan ngerteni, asile dicampur - ing pirang-pirang kasus, proxy menehi kacepetan sing apik, nanging ana uga sawetara klien sing bakal saya tambah akeh.
AkibatΓ©, kita nindakake sawetara perkara penting:
- Kita netepake kinerja sing dikarepake saka panjaluk saka klien menyang awan liwat proxy CDN.
- Kita nampa data saka klien nyata, saka kabeh jinis piranti.
- Kita nyadari yen teori kasebut ora dikonfirmasi 100% lan tawaran awal karo proxy CDN ora bisa digunakake kanggo kita.
- Kita ora njupuk risiko - kita ora ngganti konfigurasi produksi kanggo klien.
- Ora ana sing rusak.
Prototipe 2.0
Dadi, bali menyang papan gambar lan baleni proses maneh.
Ide iki tinimbang nggunakake proxy 100%, kita bakal nemtokake dalan paling cepet kanggo saben klien, lan kita bakal ngirim panjalukan ing kana - yaiku, kita bakal nindakake apa sing diarani setir klien.
Carane ngleksanakake iki? Kita ora bisa nggunakake logika ing sisih server, amarga ... Tujuane kanggo nyambung menyang server iki. Ana sawetara cara kanggo nindakake iki ing klien. Lan saenipun, nindakake iki kanthi jumlah minimal logika kompleks, supaya ora kanggo ngatasi masalah integrasi karo nomer akeh platform klien.
Jawaban iki nggunakake DNS. Ing kasus kita, kita duwe infrastruktur DNS dhewe, lan kita bisa nyetel zona domain sing server kita bakal otoriter. Kerjane kaya iki:
- Klien nggawe panjaluk menyang server DNS nggunakake host, contone api.netflix.xom.
- Panjaluk kasebut teka ing server DNS kita
- Server DNS ngerti dalan sing paling cepet kanggo klien iki lan ngetokake alamat IP sing cocog.
Solusi kasebut nduweni kerumitan tambahan: panyedhiya DNS otoriter ora ndeleng alamat IP klien lan mung bisa maca alamat IP saka solver rekursif sing digunakake klien.
AkibatΓ©, solver otoriter kita kudu nggawe keputusan ora kanggo klien individu, nanging kanggo klompok klien adhedhasar solver rekursif.
Kanggo ngatasi, kita nggunakake conto sing padha, nglumpukake asil pangukuran saka klien kanggo saben solver rekursif lan mutusake menyang ngendi ngirim klompok kasebut - proxy liwat IX nggunakake TCP Anycast, liwat proxy ISP, utawa langsung menyang awan.
Kita entuk sistem ing ngisor iki:
Model setir DNS sing diasilake ngidini sampeyan ngarahake klien adhedhasar pengamatan sajarah babagan kacepetan sambungan saka klien menyang awan.
Maneh, pitakonan yaiku carane efektif pendekatan iki? Kanggo njawab, kita nggunakake maneh sistem probe. Mulane, kita ngatur konfigurasi presenter, ing ngendi salah sawijining target ngetutake arah saka setir DNS, sing liyane langsung menyang awan (produksi saiki).
AkibatΓ©, kita mbandhingake asil lan entuk evaluasi efektifitas:
AkibatΓ©, kita sinau sawetara perkara penting:
- Kita netepake kinerja sing dikarepake saka panjaluk saka klien menyang awan nggunakake DNS Steering.
- Kita nampa data saka klien nyata, saka kabeh jinis piranti.
- Efektivitas ide sing diusulake wis kabukten.
- Kita ora njupuk risiko - kita ora ngganti konfigurasi produksi kanggo klien.
- Ora ana sing rusak.
Saiki babagan bagean sing angel - kita miwiti produksi
Sisih gampang saiki wis rampung - ana prototipe sing bisa digunakake. Saiki sing paling angel yaiku ngluncurake solusi kanggo kabeh lalu lintas Netflix, nyebarake menyang 150 yuta pangguna, ewonan piranti, atusan layanan mikro, lan produk lan infrastruktur sing terus-terusan. Server Netflix nampa mayuta-yuta panjalukan saben detik, lan iku gampang kanggo break layanan karo tumindak careless. Ing wektu sing padha, kita pengin ngarahake lalu lintas kanthi dinamis liwat ewonan server CDN ing Internet, ing ngendi ana owah-owahan lan rusak terus-terusan lan ing wektu sing paling ora pas.
Lan kabeh iki, tim duwe 3 insinyur sing tanggung jawab kanggo pangembangan, penyebaran lan dhukungan lengkap sistem kasebut.
Mulane, kita bakal terus ngomong babagan turu sing tenang lan sehat.
Kepiye carane nerusake pembangunan lan ora nggunakake kabeh wektu kanggo dhukungan? Pendekatan kita adhedhasar 3 prinsip:
- Kita nyuda skala potensial breakdowns (radius jeblugan).
- Kita lagi nyiapake kejutan - kita ngarepake manawa ana sing bakal rusak, sanajan ana tes lan pengalaman pribadi.
- Degradasi anggun - yen ana sing ora bisa ditindakake, mula kudu didandani kanthi otomatis, sanajan ora kanthi cara sing paling efisien.
Ternyata ing kasus kita, kanthi pendekatan iki kanggo masalah kasebut, kita bisa nemokake solusi sing prasaja lan efektif lan nyederhanakake dhukungan sistem kanthi signifikan. Kita temen maujud sing kita bisa nambah Piece cilik saka kode kanggo klien lan ngawasi kanggo kesalahan request jaringan disebabake masalah sambungan. Yen ana kesalahan jaringan, kita nggawe mundur langsung menyang awan. Solusi iki ora mbutuhake gaweyan sing signifikan kanggo tim klien, nanging nyuda resiko kerusakan lan kejutan sing ora dikarepake kanggo kita.
Mesthi wae, sanajan mundur, kita tetep ngetutake disiplin sing jelas sajrone pembangunan:
- Tes sampel.
- A / B testing utawa Canaries.
- Rollout progresif.
Kanthi conto, pendekatan kasebut wis diterangake - owah-owahan pisanan dites nggunakake resep khusus.
Kanggo tes kenari, kita kudu entuk pasangan server sing bisa dibandhingake, sing bisa mbandhingake cara kerja sistem sadurunge lan sawise owah-owahan. Kanggo nindakake iki, saka akeh situs CDN, kita milih pasangan server sing nampa lalu lintas sing padha:
Banjur kita nginstal mbangun kanthi owah-owahan ing server Canary. Kanggo ngevaluasi asil, kita mbukak sistem sing mbandhingake kira-kira 100-150 metrik karo conto server Kontrol:
Yen tes Canary sukses, mula diluncurake kanthi bertahap, kanthi gelombang. Kita ora nganyari server ing saben situs ing wektu sing padha - kelangan kabeh situs amarga masalah duwe pengaruh sing luwih penting ing layanan kanggo pangguna tinimbang kelangan jumlah server sing padha ing lokasi sing beda.
UmumΓ©, efektifitas lan safety pendekatan iki gumantung saka jumlah lan kualitas metrik sing diklumpukake. Kanggo sistem akselerasi pitakon, kita ngumpulake metrik saka kabeh komponen sing bisa ditindakake:
- saka klien - jumlah sesi lan panjalukan, tarif mundur;
- proxy - statistik babagan jumlah lan wektu panjalukan;
- DNS - nomer lan asil panjalukan;
- pinggiran maya - nomer lan wektu kanggo ngolah panjalukan ing mΓ©ga.
Kabeh iki diklumpukake dadi pipa siji, lan, gumantung saka kabutuhan, kita mutusake metrik sing bakal dikirim menyang analytics wektu nyata, lan menyang Elasticsearch utawa Big Data kanggo diagnosa sing luwih rinci.
Kita ngawasi
Ing kasus kita, kita nggawe owah-owahan ing path kritis panjalukan antarane klien lan server. Ing wektu sing padha, jumlah komponen beda ing klien, ing server, lan ing dalan liwat Internet gedhe tenan. Owah-owahan ing klien lan server terus-terusan - sajrone karya puluhan tim lan owah-owahan alami ing ekosistem. Kita ana ing tengah - nalika diagnosa masalah, ana kemungkinan sing apik yen kita bakal melu. Mula, kita kudu ngerti kanthi jelas carane nemtokake, ngumpulake lan nganalisa metrik kanggo ngisolasi masalah kanthi cepet.
Saenipun, akses lengkap menyang kabeh jinis metrik lan saringan ing wektu nyata. Nanging ana akeh metrik, mula pitakonan biaya muncul. Ing kasus kita, kita misahake metrik lan alat pangembangan kaya ing ngisor iki:
Kanggo ndeteksi lan nyoba masalah, kita nggunakake sistem real-time open-source ΠΈ - kanggo visualisasi. Iki nyimpen metrik agregat ing memori, dipercaya lan terintegrasi karo sistem tandha. Kanggo lokalisasi lan diagnostik, kita duwe akses menyang log saka Elasticsearch lan Kibana. Kanggo analisis statistik lan modeling, kita nggunakake data gedhe lan visualisasi ing Tableau.
Koyone pendekatan iki angel banget digarap. Nanging, kanthi ngatur metrik lan alat kanthi hierarkis, kita bisa kanthi cepet nganalisa masalah, nemtokake jinis masalah, banjur ngebor metrik sing rinci. UmumΓ©, kita nglampahi babagan 1-2 menit kanggo ngenali sumber risak. Sawise iki, kita kerja bareng karo tim khusus babagan diagnostik - saka puluhan menit nganti pirang-pirang jam.
Sanajan diagnosis ditindakake kanthi cepet, kita ora pengin kedadeyan kasebut asring. Saenipun, kita mung bakal nampa tandha kritis nalika ana impact pinunjul ing layanan. Kanggo sistem akselerasi pitakon, mung ana 2 tandha sing bakal menehi kabar:
- Persentase Fallback Klien - evaluasi prilaku pelanggan;
- persentasi kesalahan Probe - data stabilitas komponen jaringan.
Tandha kritis iki ngawasi apa sistem bisa digunakake kanggo mayoritas pangguna. We ndeleng carane akeh klien digunakake fallback yen padha ora bisa njaluk akselerasi request. Kita rata-rata kurang saka 1 tandha kritis saben minggu, sanajan ana akeh owah-owahan ing sistem kasebut. Yagene iki cukup kanggo kita?
- Ana fallback klien yen proxy kita ora bisa.
- Ana sistem setir otomatis sing nanggapi kanggo masalah.
Rincian liyane babagan sing terakhir. Sistem nyoba kita, lan sistem kanggo otomatis nemtokake path optimal kanggo panjalukan saka klien menyang maya, ngidini kita kanggo otomatis ngrampungake karo sawetara masalah.
Ayo bali menyang konfigurasi sampel lan 3 kategori path. Saliyane wektu loading, kita bisa ndeleng kasunyatan pangiriman dhewe. Yen ora bisa mbukak data, banjur kanthi ndeleng asil ing dalan sing beda-beda, kita bisa nemtokake endi lan apa sing rusak, lan apa kita bisa ndandani kanthi otomatis kanthi ngganti path request.
conto:
Proses iki bisa otomatis. Kalebu ing sistem setir. Lan mulang kanggo nanggapi masalah kinerja lan linuwih. Yen ana sing wiwit rusak, reaksi yen ana pilihan sing luwih apik. Ing wektu sing padha, reaksi langsung ora kritis, amarga mundur saka klien.
Dadi, prinsip dhukungan sistem bisa dirumusake kaya ing ngisor iki:
- nyuda ukuran breakdowns;
- ngumpulake metrik;
- Kita kanthi otomatis ndandani risak yen bisa;
- yen ora bisa, kita ngabari;
- Kita nggarap dashboard lan alat triase kanggo nanggepi cepet.
Piwulang sing Disinaoni
Ora butuh wektu akeh kanggo nulis prototipe. Ing kasus kita, wis siap sawise 4 sasi. Kanthi iku, kita nampa metrik anyar, lan 10 sasi sawise wiwitan pembangunan, kita nampa lalu lintas produksi pisanan. Banjur karya sing mboseni lan angel banget diwiwiti: mboko sithik ngasilake lan skala sistem, migrasi lalu lintas utama lan sinau saka kesalahan. Nanging, proses sing efektif iki ora bakal linier - sanajan kabeh upaya, kabeh ora bisa diprediksi. Luwih efektif kanggo ngulang lan nanggapi data anyar kanthi cepet.
Adhedhasar pengalaman kita, kita bisa menehi rekomendasi ing ngisor iki:
- Aja percaya intuisi sampeyan.
Intuisi kita gagal terus-terusan, sanajan pengalaman akeh anggota tim kita. Contone, kita salah prΓ©dhiksi kacepetan sing dikarepake saka nggunakake proxy CDN, utawa prilaku TCP Anycast.
- Entuk data saka produksi.
Penting kanggo entuk akses menyang paling sethithik data produksi kanthi cepet. Meh mokal kanggo entuk jumlah kasus unik, konfigurasi, lan setelan ing kahanan laboratorium. Akses cepet menyang asil bakal ngidini sampeyan sinau kanthi cepet babagan masalah potensial lan njupuk menyang akun ing arsitektur sistem.
- Aja nuruti saran lan asile wong liya - kumpulake data sampeyan dhewe.
Tindakake prinsip kanggo ngumpulake lan nganalisa data, nanging aja kanthi wuta nampa asil lan statement wong liya. Mung sampeyan bisa ngerti persis apa sing dianggo kanggo pangguna sampeyan. Sistem lan pelanggan sampeyan bisa uga beda banget karo perusahaan liyane. Untunge, alat analisis saiki kasedhiya lan gampang digunakake. Asil sing sampeyan entuk bisa uga ora kaya sing diklaim Netflix, Facebook, Akamai lan perusahaan liyane. Ing kasus kita, kinerja TLS, HTTP2 utawa statistik ing panjalukan DNS beda karo asil Facebook, Uber, Akamai - amarga kita duwe piranti, klien lan aliran data sing beda.
- Aja ngetutake tren fashion sing ora perlu lan evaluasi efektifitas.
Miwiti prasaja. Luwih becik nggawe sistem kerja sing gampang ing wektu sing cendhak tinimbang mbuwang wektu akeh kanggo ngembangake komponen sing ora dibutuhake. Ngatasi tugas lan masalah sing penting adhedhasar pangukuran lan asil sampeyan.
- Siapke aplikasi anyar.
Kaya angel kanggo prΓ©dhiksi kabeh masalah, angel prΓ©dhiksi keuntungan lan aplikasi luwih dhisik. Njupuk isyarat saka wiwitan - kemampuan kanggo adaptasi karo kahanan pelanggan. Ing kasus sampeyan, sampeyan bisa nemokake masalah anyar lan solusi. Ing proyek kita, kita nemtokake tujuan kanggo nyuda latensi panyuwunan. Nanging, sajrone analisis lan diskusi, kita nyadari yen kita uga bisa nggunakake server proxy:
- kanggo ngimbangi lalu lintas ing wilayah AWS lan nyuda biaya;
- kanggo model stabilitas CDN;
- kanggo ngatur DNS;
- kanggo ngatur TLS/TCP.
kesimpulan
Ing laporan kasebut, aku nerangake carane Netflix ngatasi masalah nyepetake panjaluk Internet antarane klien lan awan. Carane kita ngumpulake data nggunakake sistem sampling ing klien, lan nggunakake data sajarah diklumpukake kanggo rute panjalukan produksi saka klien liwat dalan paling cepet ing Internet. Kepiye cara nggunakake prinsip protokol jaringan, infrastruktur CDN, jaringan backbone, lan server DNS kanggo entuk tugas iki.
Nanging, solusi kita mung minangka conto babagan carane Netflix ngetrapake sistem kasebut. Apa makarya kanggo kita. Bagian sing ditrapake saka laporanku kanggo sampeyan yaiku prinsip pangembangan lan dhukungan sing kita tindakake lan entuk asil sing apik.
Solusi kanggo masalah kasebut bisa uga ora cocog karo sampeyan. Nanging, teori lan prinsip pembangunan tetep, sanajan sampeyan ora duwe infrastruktur CDN dhewe, utawa yen beda banget karo kita.
Pentinge kacepetan panjaluk bisnis uga tetep penting. Malah kanggo layanan sing prasaja sampeyan kudu milih: antarane panyedhiya awan, lokasi server, panyedhiya CDN lan DNS. Pilihan sampeyan bakal mengaruhi efektifitas pitakon Internet kanggo para pelanggan. Lan penting kanggo sampeyan ngukur lan ngerti pengaruh iki.
Miwiti karo solusi sing prasaja, peduli babagan carane ngganti produk. Sinau lan ngapikake sistem adhedhasar data saka pelanggan, infrastruktur, lan bisnis sampeyan. Mikir babagan kemungkinan rusak sing ora dikarepke sajrone proses desain. Banjur sampeyan bisa nyepetake proses pangembangan, nambah efisiensi solusi, ngindhari beban dhukungan sing ora perlu lan turu kanthi tentrem.
Taun iki ing format online. Sampeyan bisa takon marang salah sawijining bapak DevOps, John Willis dhewe!
Source: www.habr.com
