Netflix adalah pemimpin pasar televisi Internet - perusahaan yang menciptakan dan secara aktif mengembangkan segmen ini. Netflix dikenal tidak hanya karena katalog film dan serial TVnya yang luas yang tersedia dari hampir seluruh penjuru dunia dan perangkat apa pun yang memiliki layar, tetapi juga karena infrastrukturnya yang andal dan budaya teknik yang unik.
Contoh nyata pendekatan Netflix dalam mengembangkan dan mendukung sistem yang kompleks disajikan di DevOops 2019 - Direktur Pengembangan di Netflix. Lulusan Fakultas Matematika Komputasi dan Matematika Universitas Negeri Nizhny Novgorod. Lobachevsky, Sergey salah satu insinyur pertama di Open Connect - tim CDN di Netflix. Dia membangun sistem untuk memantau dan menganalisis data video, meluncurkan layanan populer untuk menilai kecepatan koneksi Internet FAST.com, dan selama beberapa tahun terakhir telah berupaya mengoptimalkan permintaan Internet sehingga aplikasi Netflix bekerja secepat mungkin bagi pengguna.
Laporan tersebut mendapat review terbaik dari peserta konferensi, dan kami telah menyiapkan versi teks untuk Anda.
Dalam laporannya, Sergei berbicara secara detail
- tentang apa yang mempengaruhi penundaan permintaan Internet antara klien dan server;
- bagaimana cara mengurangi penundaan ini;
- bagaimana merancang, memelihara dan memantau sistem yang toleran terhadap kesalahan;
- bagaimana mencapai hasil dalam waktu singkat, dan dengan risiko minimal terhadap bisnis;
- bagaimana menganalisis hasil dan belajar dari kesalahan.
Jawaban atas pertanyaan-pertanyaan tersebut dibutuhkan tidak hanya oleh mereka yang bekerja di perusahaan besar.
Prinsip dan teknik yang disajikan harus diketahui dan dipraktikkan oleh semua orang yang mengembangkan dan mendukung produk Internet.
Berikutnya adalah narasi dari sudut pandang pembicara.
Pentingnya kecepatan internet
Kecepatan permintaan Internet berhubungan langsung dengan bisnis. Pertimbangkan industri belanja: Amazon pada tahun 2009 bahwa penundaan 100 ms mengakibatkan hilangnya 1% penjualan.
Perangkat seluler kini semakin banyak, diikuti oleh situs dan aplikasi seluler. Jika laman Anda memerlukan waktu lebih dari 3 detik untuk dimuat, Anda kehilangan sekitar setengah pengguna Anda. DENGAN Google memperhitungkan kecepatan memuat halaman Anda dalam hasil pencarian: semakin cepat halaman tersebut, semakin tinggi posisinya di Google.
Kecepatan koneksi juga penting di lembaga keuangan yang mengutamakan latensi. Pada tahun 2015, Jaringan Hibernia kabel senilai $400 juta antara New York dan London untuk mengurangi latensi antar kota sebesar 6ms. Bayangkan $66 juta untuk pengurangan latensi 1 ms!
Menurut , kecepatan koneksi di atas 5 Mbit/s tidak lagi secara langsung memengaruhi kecepatan pemuatan situs web pada umumnya. Namun, ada hubungan linier antara latensi koneksi dan kecepatan pemuatan halaman:
Namun, Netflix bukanlah produk biasa. Dampak latensi dan kecepatan pada pengguna merupakan area analisis dan pengembangan yang aktif. Ada pemuatan aplikasi dan pemilihan konten yang bergantung pada latensi, tetapi memuat elemen statis dan streaming juga bergantung pada kecepatan koneksi. Menganalisis dan mengoptimalkan faktor-faktor utama yang memengaruhi pengalaman pengguna merupakan area pengembangan aktif untuk beberapa tim di Netflix. Salah satu tujuannya adalah mengurangi latensi permintaan antara perangkat Netflix dan infrastruktur cloud.
Dalam laporan ini kami akan fokus secara khusus pada pengurangan latensi menggunakan contoh infrastruktur Netflix. Mari kita pertimbangkan dari sudut pandang praktis bagaimana mendekati proses desain, pengembangan, dan pengoperasian sistem terdistribusi yang kompleks dan menghabiskan waktu untuk inovasi dan hasil, daripada mendiagnosis masalah dan kerusakan operasional.
Di dalam Netflix
Ribuan perangkat berbeda mendukung aplikasi Netflix. Mereka dikembangkan oleh empat tim berbeda, yang membuat versi klien terpisah untuk Android, iOS, TV, dan browser web. Dan kami menghabiskan banyak upaya untuk meningkatkan dan mempersonalisasi pengalaman pengguna. Untuk melakukan ini, kami menjalankan ratusan pengujian A/B secara paralel.
Personalisasi didukung oleh ratusan layanan mikro di AWS cloud, yang menyediakan data pengguna yang dipersonalisasi, pengiriman kueri, telemetri, Big Data, dan Encoding. Visualisasi lalu lintas terlihat seperti ini:
Di sebelah kiri adalah titik masuk, lalu lalu lintas didistribusikan ke beberapa ratus layanan mikro yang didukung oleh tim backend berbeda.
Komponen penting lainnya dari infrastruktur kami adalah Open Connect CDN, yang mengirimkan konten statis ke pengguna akhir - video, gambar, kode klien, dll. CDN terletak di server khusus (OCA - Open Connect Appliance). Di dalamnya terdapat rangkaian drive SSD dan HDD yang menjalankan FreeBSD yang dioptimalkan, dengan NGINX dan serangkaian layanan. Kami merancang dan mengoptimalkan komponen perangkat keras dan perangkat lunak sehingga server CDN dapat mengirimkan data sebanyak mungkin kepada pengguna.
"Dinding" server-server ini di titik pertukaran lalu lintas Internet (Internet eXchange - IX) terlihat seperti ini:
Internet Exchange memberikan kemampuan bagi penyedia layanan Internet dan penyedia konten untuk βterhubungβ satu sama lain untuk bertukar data secara lebih langsung di Internet. Ada sekitar 70-80 titik Internet Exchange di seluruh dunia tempat server kami dipasang, dan kami memasang serta memeliharanya secara mandiri:
Selain itu, kami juga menyediakan server langsung ke penyedia Internet, yang mereka pasang di jaringan mereka, sehingga meningkatkan lokalisasi lalu lintas Netflix dan kualitas streaming bagi pengguna:
Seperangkat layanan AWS bertanggung jawab untuk mengirimkan permintaan video dari klien ke server CDN, serta mengonfigurasi server itu sendiri - memperbarui konten, kode program, pengaturan, dll. Untuk yang terakhir, kami juga membangun jaringan tulang punggung yang menghubungkan server di titik Internet Exchange dengan AWS. Jaringan backbone adalah jaringan global kabel dan router serat optik yang dapat kami rancang dan konfigurasikan berdasarkan kebutuhan kami.
Pada , infrastruktur CDN kami menyalurkan sekitar β lalu lintas Internet dunia selama jam sibuk dan β lalu lintas di Amerika Utara, tempat Netflix paling lama beroperasi. Angka yang mengesankan, namun bagi saya salah satu pencapaian yang paling menakjubkan adalah keseluruhan sistem CDN dikembangkan dan dikelola oleh tim yang beranggotakan kurang dari 150 orang.
Awalnya, infrastruktur CDN dirancang untuk mengirimkan data video. Namun, seiring waktu kami menyadari bahwa kami juga dapat menggunakannya untuk mengoptimalkan permintaan dinamis dari klien di AWS cloud.
Tentang akselerasi Internet
Saat ini, Netflix memiliki 3 wilayah AWS, dan latensi permintaan ke cloud akan bergantung pada seberapa jauh jarak pelanggan dari wilayah terdekat. Pada saat yang sama, kami memiliki banyak server CDN yang digunakan untuk mengirimkan konten statis. Apakah ada cara untuk menggunakan kerangka kerja ini untuk mempercepat kueri dinamis? Namun, sayangnya, permintaan ini tidak dapat di-cache - API dipersonalisasi dan setiap hasil bersifat unik.
Mari membuat proxy di server CDN dan mulai mengirimkan lalu lintas melaluinya. Apakah akan lebih cepat?
Perlengkapan
Mari kita ingat cara kerja protokol jaringan. Saat ini, sebagian besar lalu lintas di Internet menggunakan HTTP, yang bergantung pada protokol lapisan bawah TCP dan TLS. Agar klien dapat terhubung ke server, ia melakukan jabat tangan, dan untuk membuat sambungan aman, klien perlu bertukar pesan dengan server tiga kali dan setidaknya satu kali lagi untuk mentransfer data. Dengan latensi per perjalanan pulang pergi (RTT) sebesar 100 ms, kami memerlukan waktu 400 ms untuk menerima bit data pertama:
Jika kita menempatkan sertifikat di server CDN, maka waktu jabat tangan antara klien dan server dapat dikurangi secara signifikan jika CDN lebih dekat. Anggaplah latensi ke server CDN adalah 30 ms. Maka diperlukan waktu 220 ms untuk menerima bit pertama:
Namun keuntungannya tidak hanya sampai di situ. Setelah koneksi dibuat, TCP meningkatkan jendela kemacetan (jumlah informasi yang dapat dikirimkan melalui koneksi tersebut secara paralel). Jika paket data hilang, implementasi klasik protokol TCP (seperti TCP New Reno) mengurangi βjendelaβ yang terbuka hingga setengahnya. Pertumbuhan jendela kemacetan, dan kecepatan pemulihannya dari kehilangan, sekali lagi bergantung pada penundaan (RTT) ke server. Jika koneksi ini hanya sampai ke server CDN, pemulihan ini akan lebih cepat. Pada saat yang sama, kehilangan paket merupakan fenomena standar, terutama untuk jaringan nirkabel.
Bandwidth internet dapat berkurang, terutama pada jam sibuk, akibat lalu lintas dari pengguna, sehingga dapat mengakibatkan kemacetan lalu lintas. Namun, tidak ada cara di Internet untuk memberikan prioritas pada beberapa permintaan dibandingkan permintaan lainnya. Misalnya, berikan prioritas pada permintaan kecil dan sensitif terhadap latensi dibandingkan aliran data βberatβ yang memuat jaringan. Namun, dalam kasus kami, memiliki jaringan tulang punggung sendiri memungkinkan kami melakukan ini pada bagian jalur permintaan - antara CDN dan cloud, dan kami dapat mengonfigurasinya sepenuhnya. Anda dapat memastikan bahwa paket kecil dan sensitif terhadap latensi diprioritaskan, dan aliran data yang besar akan diprioritaskan nanti. Semakin dekat CDN dengan klien, semakin besar efisiensinya.
Protokol tingkat aplikasi (OSI Level 7) juga berdampak pada latensi. Protokol baru seperti HTTP/2 mengoptimalkan kinerja permintaan paralel. Namun, kami memiliki klien Netflix dengan perangkat lama yang tidak mendukung protokol baru. Tidak semua klien dapat diperbarui atau dikonfigurasi secara optimal. Pada saat yang sama, antara proxy CDN dan cloud terdapat kontrol penuh dan kemampuan untuk menggunakan protokol dan pengaturan baru yang optimal. Bagian yang tidak efektif dengan protokol lama hanya akan beroperasi antara klien dan server CDN. Selain itu, kami dapat membuat permintaan multipleks pada koneksi yang sudah ada antara CDN dan cloud, sehingga meningkatkan pemanfaatan koneksi di tingkat TCP:
Kami mengukur
Terlepas dari kenyataan bahwa teori tersebut menjanjikan perbaikan, kami tidak segera terburu-buru meluncurkan sistem ke dalam produksi. Sebaliknya, pertama-tama kita harus membuktikan bahwa ide tersebut akan berhasil dalam praktiknya. Untuk melakukan ini, Anda perlu menjawab beberapa pertanyaan:
- Mempercepat: apakah proxy akan lebih cepat?
- Keandalan: Apakah akan lebih sering rusak?
- Kompleksitas: bagaimana cara berintegrasi dengan aplikasi?
- Biaya: Berapa biaya untuk menerapkan infrastruktur tambahan?
Mari kita pertimbangkan secara rinci pendekatan kita untuk menilai poin pertama. Sisanya ditangani dengan cara yang sama.
Untuk menganalisis kecepatan permintaan, kami ingin memperoleh data untuk semua pengguna, tanpa menghabiskan banyak waktu untuk pengembangan dan tanpa mengganggu produksi. Ada beberapa pendekatan untuk ini:
- RUM, atau pengukuran permintaan pasif. Kami mengukur waktu eksekusi permintaan saat ini dari pengguna dan memastikan cakupan pengguna sepenuhnya. Kekurangannya adalah sinyal tidak terlalu stabil karena banyak faktor, misalnya karena ukuran permintaan yang berbeda, waktu pemrosesan di server dan klien. Selain itu, Anda tidak dapat menguji konfigurasi baru tanpa berpengaruh pada produksi.
- Tes laboratorium. Server dan infrastruktur khusus yang mensimulasikan klien. Dengan bantuan mereka, kami melakukan tes yang diperlukan. Dengan cara ini kita mendapatkan kendali penuh atas hasil pengukuran dan sinyal yang jelas. Namun tidak ada cakupan perangkat dan lokasi pengguna yang lengkap (terutama dengan layanan di seluruh dunia dan dukungan untuk ribuan model perangkat).
Bagaimana Anda bisa menggabungkan keunggulan kedua metode tersebut?
Tim kami telah menemukan solusinya. Kami menulis sepotong kecil kode - contoh - yang kami buat ke dalam aplikasi kami. Probe memungkinkan kami melakukan pengujian jaringan yang dikontrol sepenuhnya dari perangkat kami. Cara kerjanya seperti ini:
- Segera setelah memuat aplikasi dan menyelesaikan aktivitas awal, kami menjalankan penyelidikan kami.
- Klien membuat permintaan ke server dan menerima βresepβ untuk pengujian. Resepnya adalah daftar URL yang perlu dibuatkan permintaan HTTP. Selain itu, resep ini mengonfigurasi parameter permintaan: penundaan antar permintaan, jumlah data yang diminta, header HTTP, dll. Pada saat yang sama, kami dapat menguji beberapa resep berbeda secara paralel - saat meminta konfigurasi, kami secara acak menentukan resep mana yang akan dikeluarkan.
- Waktu peluncuran probe dipilih agar tidak bertentangan dengan penggunaan aktif sumber daya jaringan pada klien. Intinya, waktu yang dipilih adalah saat klien tidak aktif.
- Setelah menerima resep, klien membuat permintaan ke masing-masing URL secara paralel. Permintaan ke masing-masing alamat dapat diulang - yang disebut. "pulsa". Pada pulsa pertama, kami mengukur berapa lama waktu yang dibutuhkan untuk membuat koneksi dan mendownload data. Pada pulsa kedua, kami mengukur waktu yang diperlukan untuk memuat data melalui koneksi yang sudah ada. Sebelum yang ketiga, kita dapat mengatur penundaan dan mengukur kecepatan penyambungan kembali, dll.
Selama pengujian, kami mengukur semua parameter yang dapat diperoleh perangkat:
- Waktu permintaan DNS;
- Waktu pengaturan koneksi TCP;
- Waktu pengaturan koneksi TLS;
- waktu penerimaan byte data pertama;
- total waktu pemuatan;
- kode hasil status.
- Setelah semua pulsa selesai, sampel memuat semua pengukuran untuk dianalisis.
Poin utamanya adalah ketergantungan minimal pada logika di klien, pemrosesan data di server, dan pengukuran permintaan paralel. Dengan demikian, kami dapat mengisolasi dan menguji pengaruh berbagai faktor yang memengaruhi kinerja kueri, memvariasikannya dalam satu resep, dan memperoleh hasil dari klien nyata.
Infrastruktur ini telah terbukti berguna untuk lebih dari sekedar analisis kinerja kueri. Saat ini kami memiliki 14 resep aktif, lebih dari 6000 sampel per detik, menerima data dari seluruh penjuru bumi dan jangkauan perangkat penuh. Jika Netflix membeli layanan serupa dari pihak ketiga, biayanya akan mencapai jutaan dolar per tahun, dengan cakupan yang jauh lebih buruk.
Pengujian teori dalam praktek: prototipe
Dengan sistem seperti itu, kami dapat mengevaluasi efektivitas proxy CDN berdasarkan latensi permintaan. Sekarang Anda membutuhkan:
- membuat prototipe proksi;
- tempatkan prototipe pada CDN;
- menentukan cara mengarahkan klien ke proxy di server CDN tertentu;
- Bandingkan kinerja dengan permintaan di AWS tanpa proksi.
Tugasnya adalah mengevaluasi efektivitas solusi yang diusulkan secepat mungkin. Kami memilih Go untuk mengimplementasikan prototipe karena ketersediaan perpustakaan jaringan yang baik. Di setiap server CDN, kami memasang proksi prototipe sebagai biner statis untuk meminimalkan ketergantungan dan menyederhanakan integrasi. Pada implementasi awal, kami menggunakan komponen standar sebanyak mungkin dan sedikit modifikasi untuk pengumpulan koneksi HTTP/2 dan multiplexing permintaan.
Untuk menyeimbangkan antar wilayah AWS, kami menggunakan database DNS geografis, database yang sama yang digunakan untuk menyeimbangkan klien. Untuk memilih server CDN untuk klien, kami menggunakan TCP Anycast untuk server di Internet Exchange (IX). Pada opsi ini, kami menggunakan satu alamat IP untuk semua server CDN, dan klien akan diarahkan ke server CDN dengan jumlah IP hop paling sedikit. Di server CDN yang diinstal oleh penyedia Internet (ISP), kami tidak memiliki kendali atas router untuk mengkonfigurasi TCP Anycast, jadi kami menggunakan , yang mengarahkan pelanggan ke penyedia Internet untuk streaming video.
Jadi, kami memiliki tiga jenis jalur permintaan: ke cloud melalui Internet terbuka, melalui server CDN di IX, atau melalui server CDN yang terletak di penyedia Internet. Tujuan kami adalah memahami cara mana yang lebih baik, dan apa manfaat proxy, dibandingkan dengan cara permintaan dikirim ke produksi. Untuk melakukan ini, kami menggunakan sistem sampling sebagai berikut:
Masing-masing jalur menjadi target tersendiri, dan kami melihat waktu yang kami dapatkan. Untuk analisis, kami menggabungkan hasil proxy ke dalam satu kelompok (pilih waktu terbaik antara proxy IX dan ISP), dan membandingkannya dengan waktu permintaan ke cloud tanpa proxy:
Seperti yang Anda lihat, hasilnya beragam - dalam sebagian besar kasus, proxy memberikan kecepatan yang baik, namun ada juga sejumlah klien yang situasinya akan memburuk secara signifikan.
Hasilnya, kami melakukan beberapa hal penting:
- Kami menilai kinerja yang diharapkan dari permintaan dari klien ke cloud melalui proksi CDN.
- Kami menerima data dari klien nyata, dari semua jenis perangkat.
- Kami menyadari bahwa teori tersebut tidak 100% terkonfirmasi dan tawaran awal dengan proxy CDN tidak akan berhasil untuk kami.
- Kami tidak mengambil risiko - kami tidak mengubah konfigurasi produksi untuk klien.
- Tidak ada yang rusak.
Prototipe 2.0
Jadi, kembali ke papan gambar dan ulangi prosesnya lagi.
Idenya adalah bahwa alih-alih menggunakan proxy 100%, kami akan menentukan jalur tercepat untuk setiap klien, dan kami akan mengirimkan permintaan ke sana - yaitu, kami akan melakukan apa yang disebut pengarahan klien.
Bagaimana cara menerapkannya? Kita tidak dapat menggunakan logika di sisi server, karena... Tujuannya adalah untuk terhubung ke server ini. Perlu ada beberapa cara untuk melakukan ini pada klien. Dan idealnya, lakukan ini dengan logika kompleks dalam jumlah minimum, agar tidak menyelesaikan masalah integrasi dengan sejumlah besar platform klien.
Jawabannya adalah dengan menggunakan DNS. Dalam kasus kami, kami memiliki infrastruktur DNS kami sendiri, dan kami dapat menyiapkan zona domain yang server kami akan bersifat otoriter. Cara kerjanya seperti ini:
- Klien membuat permintaan ke server DNS menggunakan host, misalnya api.netflix.xom.
- Permintaan tiba di server DNS kami
- Server DNS mengetahui jalur mana yang tercepat untuk klien ini dan mengeluarkan alamat IP yang sesuai.
Solusi ini memiliki kompleksitas tambahan: penyedia DNS otoriter tidak melihat alamat IP klien dan hanya dapat membaca alamat IP dari penyelesai rekursif yang digunakan klien.
Akibatnya, penyelesai otoriter kita harus membuat keputusan bukan untuk klien individu, tetapi untuk sekelompok klien berdasarkan penyelesai rekursif.
Untuk menyelesaikannya, kami menggunakan sampel yang sama, menggabungkan hasil pengukuran dari klien untuk masing-masing penyelesai rekursif dan memutuskan ke mana akan mengirim grup ini - proksi melalui IX menggunakan TCP Anycast, melalui proksi ISP, atau langsung ke cloud.
Kami mendapatkan sistem berikut:
Model pengarah DNS yang dihasilkan memungkinkan Anda mengarahkan klien berdasarkan pengamatan historis terhadap kecepatan koneksi dari klien ke cloud.
Sekali lagi, pertanyaannya adalah seberapa efektifkah pendekatan ini akan berhasil? Untuk menjawabnya, kami kembali menggunakan sistem probe kami. Oleh karena itu, kami mengonfigurasi konfigurasi presenter, di mana salah satu target mengikuti arah dari DNS steering, yang lain langsung menuju cloud (produksi saat ini).
Hasilnya, kami membandingkan hasil dan mendapatkan penilaian efektivitas:
Hasilnya, kami mempelajari beberapa hal penting:
- Kami menilai kinerja permintaan yang diharapkan dari klien ke cloud menggunakan Pengarah DNS.
- Kami menerima data dari klien nyata, dari semua jenis perangkat.
- Efektivitas ide yang diajukan telah terbukti.
- Kami tidak mengambil risiko - kami tidak mengubah konfigurasi produksi untuk klien.
- Tidak ada yang rusak.
Sekarang tentang bagian yang sulit - kami meluncurkannya ke produksi
Bagian yang mudah kini telah berakhir - ada prototipe yang berfungsi. Kini bagian tersulitnya adalah menjalankan solusi untuk semua lalu lintas Netflix, menerapkannya ke 150 juta pengguna, ribuan perangkat, ratusan layanan mikro, serta produk dan infrastruktur yang terus berubah. Server Netflix menerima jutaan permintaan per detik, dan layanan ini mudah dirusak jika dilakukan secara ceroboh. Pada saat yang sama, kami ingin mengarahkan lalu lintas secara dinamis melalui ribuan server CDN di Internet, di mana ada sesuatu yang berubah dan rusak secara terus-menerus dan pada saat yang paling tidak tepat.
Dan dengan semua ini, tim memiliki 3 insinyur yang bertanggung jawab atas pengembangan, penerapan, dan dukungan penuh terhadap sistem.
Oleh karena itu, kami akan terus membahas tentang tidur nyenyak dan sehat.
Bagaimana cara melanjutkan pengembangan dan tidak menghabiskan seluruh waktu Anda untuk dukungan? Pendekatan kami didasarkan pada 3 prinsip:
- Kami mengurangi potensi skala kerusakan (radius ledakan).
- Kami bersiap menghadapi kejutan - kami memperkirakan sesuatu akan rusak, meskipun telah diuji dan pengalaman pribadi.
- Degradasi yang baik - jika ada sesuatu yang tidak berfungsi dengan baik, hal itu harus diperbaiki secara otomatis, meskipun bukan dengan cara yang paling efisien.
Ternyata dalam kasus kami, dengan pendekatan masalah ini, kami dapat menemukan solusi yang sederhana dan efektif serta menyederhanakan dukungan sistem secara signifikan. Kami menyadari bahwa kami dapat menambahkan sepotong kecil kode ke klien dan memantau kesalahan permintaan jaringan yang disebabkan oleh masalah koneksi. Jika terjadi kesalahan jaringan, kami melakukan fallback langsung ke cloud. Solusi ini tidak memerlukan upaya yang signifikan bagi tim klien, namun sangat mengurangi risiko kerusakan dan kejutan yang tidak terduga bagi kami.
Tentu saja, meskipun ada kemunduran, kami tetap mengikuti disiplin yang jelas selama pengembangan:
- Tes sampel.
- Pengujian A/B atau Canaries.
- Peluncuran progresif.
Dengan sampel, pendekatannya telah dijelaskan - perubahan pertama kali diuji menggunakan resep yang disesuaikan.
Untuk pengujian canary, kita perlu mendapatkan pasangan server yang sebanding sehingga kita dapat membandingkan cara kerja sistem sebelum dan sesudah perubahan. Untuk melakukan hal ini, dari banyak situs CDN kami, kami memilih pasangan server yang menerima lalu lintas yang sebanding:
Kemudian kita install build dengan perubahannya di server Canary. Untuk mengevaluasi hasilnya, kami menjalankan sistem yang membandingkan sekitar 100-150 metrik dengan sampel server Kontrol:
Jika pengujian Canary berhasil, maka kami merilisnya secara bertahap, secara bertahap. Kami tidak memperbarui server di setiap situs secara bersamaan - kehilangan seluruh situs karena masalah memiliki dampak yang lebih signifikan terhadap layanan bagi pengguna dibandingkan kehilangan jumlah server yang sama di lokasi berbeda.
Secara umum, efektivitas dan keamanan pendekatan ini bergantung pada kuantitas dan kualitas metrik yang dikumpulkan. Untuk sistem akselerasi kueri, kami mengumpulkan metrik dari semua komponen yang memungkinkan:
- dari klien - jumlah sesi dan permintaan, tarif fallback;
- proxy - statistik jumlah dan waktu permintaan;
- DNS - nomor dan hasil permintaan;
- cloud edge - nomor dan waktu untuk memproses permintaan di cloud.
Semua ini dikumpulkan ke dalam satu saluran, dan, bergantung pada kebutuhan, kami memutuskan metrik mana yang akan dikirim ke analitik real-time, dan mana ke Elasticsearch atau Big Data untuk diagnostik yang lebih mendetail.
Kami memantau
Dalam kasus kami, kami membuat perubahan pada jalur kritis permintaan antara klien dan server. Pada saat yang sama, jumlah komponen berbeda di klien, di server, dan di jalur melalui Internet sangatlah banyak. Perubahan pada klien dan server terjadi terus-menerus - selama kerja puluhan tim dan perubahan alami dalam ekosistem. Kami berada di tengah-tengah - ketika mendiagnosis masalah, ada kemungkinan besar kami akan terlibat. Oleh karena itu, kita perlu memahami dengan jelas cara mendefinisikan, mengumpulkan, dan menganalisis metrik untuk mengisolasi masalah dengan cepat.
Idealnya, akses penuh ke semua jenis metrik dan filter secara real time. Tapi ada banyak metrik, sehingga muncul pertanyaan tentang biaya. Dalam kasus kami, kami memisahkan metrik dan alat pengembangan sebagai berikut:
Untuk mendeteksi dan melakukan triase masalah, kami menggunakan sistem real-time sumber terbuka kami sendiri ΠΈ - untuk visualisasi. Ini menyimpan metrik agregat dalam memori, dapat diandalkan dan terintegrasi dengan sistem peringatan. Untuk pelokalan dan diagnostik, kami memiliki akses ke log dari Elasticsearch dan Kibana. Untuk analisis dan pemodelan statistik, kami menggunakan data besar dan visualisasi di Tableau.
Tampaknya pendekatan ini sangat sulit untuk dilakukan. Namun, dengan mengatur metrik dan alat secara hierarki, kita dapat dengan cepat menganalisis suatu masalah, menentukan jenis masalah, dan kemudian menelusuri metrik secara rinci. Secara umum, kami menghabiskan waktu sekitar 1-2 menit untuk mengidentifikasi sumber kerusakan. Setelah ini, kami bekerja dengan tim khusus untuk diagnostik - mulai dari puluhan menit hingga beberapa jam.
Sekalipun diagnosisnya dilakukan dengan cepat, kita tidak ingin hal ini sering terjadi. Idealnya, kami hanya akan menerima peringatan penting ketika ada dampak signifikan terhadap layanan. Untuk sistem akselerasi kueri kami, kami hanya memiliki 2 peringatan yang akan memberi tahu:
- Persentase Penggantian Klien - penilaian perilaku pelanggan;
- persentase kesalahan Probe - data stabilitas komponen jaringan.
Peringatan penting ini memantau apakah sistem berfungsi untuk sebagian besar pengguna. Kami melihat berapa banyak klien yang menggunakan fallback jika mereka tidak bisa mendapatkan akselerasi permintaan. Rata-rata kami menerima kurang dari 1 peringatan kritis per minggu, meskipun ada banyak sekali perubahan yang terjadi di sistem. Mengapa ini cukup bagi kami?
- Ada fallback klien jika proxy kami tidak berfungsi.
- Ada sistem kemudi otomatis yang merespon masalah.
Rincian lebih lanjut tentang yang terakhir. Sistem uji coba kami, dan sistem untuk secara otomatis menentukan jalur optimal untuk permintaan dari klien ke cloud, memungkinkan kami mengatasi beberapa masalah secara otomatis.
Mari kembali ke konfigurasi sampel dan 3 kategori jalur. Selain waktu pemuatan, kita juga bisa melihat fakta pengiriman itu sendiri. Jika data tidak dapat dimuat, maka dengan melihat hasil di sepanjang jalur yang berbeda, kami dapat menentukan di mana dan apa yang rusak, dan apakah kami dapat memperbaikinya secara otomatis dengan mengubah jalur permintaan.
ΠΡΠΈΠΌΠ΅ΡΡ:
Proses ini dapat diotomatisasi. Sertakan dalam sistem kemudi. Dan ajarkan untuk merespons masalah kinerja dan keandalan. Jika ada sesuatu yang mulai rusak, bereaksilah jika ada pilihan yang lebih baik. Pada saat yang sama, reaksi langsung tidaklah penting, karena adanya fallback pada klien.
Dengan demikian, prinsip-prinsip pendukung sistem dapat dirumuskan sebagai berikut:
- mengurangi skala kerusakan;
- mengumpulkan metrik;
- Kami secara otomatis memperbaiki kerusakan jika kami bisa;
- jika tidak bisa, kami memberitahukan Anda;
- Kami sedang mengerjakan dasbor dan perangkat triase untuk respons cepat.
Pelajaran yang Dipetik
Tidak perlu banyak waktu untuk menulis prototipe. Dalam kasus kami, sudah siap setelah 4 bulan. Dengan itu kami menerima metrik baru, dan 10 bulan setelah dimulainya pengembangan kami menerima lalu lintas produksi pertama. Kemudian pekerjaan yang membosankan dan sangat sulit dimulai: secara bertahap memproduksi dan menskalakan sistem, memigrasikan lalu lintas utama, dan belajar dari kesalahan. Namun, proses yang efektif ini tidak akan berjalan linier β meskipun telah dilakukan segala upaya, semuanya tidak dapat diprediksi. Jauh lebih efektif jika melakukan iterasi dan respons terhadap data baru dengan cepat.
Berdasarkan pengalaman kami, kami dapat merekomendasikan hal berikut:
- Jangan percaya intuisi Anda.
Intuisi kami terus-menerus mengecewakan kami, meskipun anggota tim kami memiliki banyak pengalaman. Misalnya, kami salah memperkirakan kecepatan yang diharapkan dari penggunaan proksi CDN, atau perilaku TCP Anycast.
- Dapatkan data dari produksi.
Penting untuk mendapatkan akses ke setidaknya sejumlah kecil data produksi secepat mungkin. Hampir tidak mungkin mendapatkan jumlah kasus, konfigurasi, dan pengaturan unik dalam kondisi laboratorium. Akses cepat ke hasil akan memungkinkan Anda mempelajari potensi masalah dengan cepat dan mempertimbangkannya dalam arsitektur sistem.
- Jangan ikuti saran dan hasil orang lain - kumpulkan data Anda sendiri.
Ikuti prinsip pengumpulan dan analisis data, namun jangan begitu saja menerima hasil dan pernyataan orang lain. Hanya Anda yang tahu persis apa yang berhasil bagi pengguna Anda. Sistem Anda dan pelanggan Anda mungkin sangat berbeda dari perusahaan lain. Untungnya, alat analisis kini tersedia dan mudah digunakan. Hasil yang Anda peroleh mungkin tidak seperti yang diklaim oleh Netflix, Facebook, Akamai, dan perusahaan lain. Dalam kasus kami, kinerja TLS, HTTP2, atau statistik permintaan DNS berbeda dari hasil Facebook, Uber, Akamai - karena kami memiliki perangkat, klien, dan aliran data yang berbeda.
- Jangan mengikuti tren mode jika tidak perlu dan evaluasi keefektifannya.
Mulailah dengan sederhana. Lebih baik membuat sistem kerja sederhana dalam waktu singkat daripada menghabiskan banyak waktu untuk mengembangkan komponen yang tidak diperlukan. Selesaikan tugas dan masalah yang penting berdasarkan pengukuran dan hasil Anda.
- Bersiaplah untuk aplikasi baru.
Sama seperti sulitnya memprediksi seluruh permasalahan, demikian pula sulitnya memprediksi manfaat dan penerapannya terlebih dahulu. Ambil contoh dari startup β kemampuan mereka untuk beradaptasi dengan kondisi pelanggan. Dalam kasus Anda, Anda mungkin menemukan masalah baru dan solusinya. Dalam proyek kami, kami menetapkan tujuan untuk mengurangi latensi permintaan. Namun, selama analisis dan diskusi, kami menyadari bahwa kami juga dapat menggunakan server proxy:
- untuk menyeimbangkan lalu lintas di seluruh wilayah AWS dan mengurangi biaya;
- untuk memodelkan stabilitas CDN;
- untuk mengkonfigurasi DNS;
- untuk mengkonfigurasi TLS/TCP.
Kesimpulan
Dalam laporan tersebut, saya menjelaskan bagaimana Netflix memecahkan masalah percepatan permintaan Internet antara klien dan cloud. Bagaimana kami mengumpulkan data menggunakan sistem pengambilan sampel pada klien, dan menggunakan data historis yang dikumpulkan untuk mengarahkan permintaan produksi dari klien melalui jalur tercepat di Internet. Bagaimana kami menggunakan prinsip-prinsip protokol jaringan, infrastruktur CDN, jaringan tulang punggung, dan server DNS untuk mencapai tugas ini.
Namun, solusi kami hanyalah contoh bagaimana kami di Netflix menerapkan sistem seperti itu. Apa yang berhasil bagi kami. Bagian penerapan laporan saya untuk Anda adalah prinsip-prinsip pengembangan dan dukungan yang kami ikuti dan mencapai hasil yang baik.
Solusi kami untuk masalah ini mungkin tidak cocok untuk Anda. Namun, teori dan prinsip desainnya tetap ada, meskipun Anda tidak memiliki infrastruktur CDN sendiri, atau jika infrastruktur tersebut berbeda secara signifikan dari infrastruktur kami.
Pentingnya kecepatan permintaan bisnis juga tetap penting. Dan bahkan untuk layanan sederhana Anda perlu membuat pilihan: antara penyedia cloud, lokasi server, CDN, dan penyedia DNS. Pilihan Anda akan mempengaruhi efektivitas pertanyaan Internet untuk pelanggan Anda. Dan penting bagi Anda untuk mengukur dan memahami pengaruh ini.
Mulailah dengan solusi sederhana, perhatikan bagaimana Anda mengubah produk. Belajar sambil jalan dan tingkatkan sistem berdasarkan data dari pelanggan, infrastruktur, dan bisnis Anda. Pikirkan tentang kemungkinan kerusakan yang tidak terduga selama proses desain. Lalu Anda dapat mempercepat proses pengembangan, meningkatkan efisiensi solusi, menghindari beban dukungan yang tidak perlu, dan tidur nyenyak.
Tahun ini dalam format daring. Anda dapat mengajukan pertanyaan kepada salah satu bapak DevOps, John Willis sendiri!
Sumber: www.habr.com