🤞🏽 🤛🏾 📹 Banyak sekali Piala Dunia 2018 🕝 👨🏼‍🔧 🐌

Piala Dunia FIFA 2018 yang lalu di Rusia membawa banyak beban tidak hanya ke pusat transportasi negara itu, tetapi juga ke infrastruktur TI penyiar Rusia terbesar, yang membuat pertandingan tersedia dalam format siaran online. Kami menerima dengan penuh minat tantangan baru yang datang ke server yang dilayani bersamaan dengan demam sepak bola.

Kata Pengantar: beban tinggi?

Percakapan tentang beban tinggi sering dimulai dengan refleksi pada topik, muatan apa yang bisa dianggap “tinggi”: ribuan permintaan per detik untuk dinamika? Atau bahkan sejumlah kecil permintaan sehubungan dengan sumber daya yang tersedia? Jutaan pengunjung per hari? Ratusan node beban kerja dalam sebuah cluster? ..

Untuk mendapatkan gambaran tentang "skala bencana", fakta bahwa kita berbicara tentang pengguna yang secara bersamaan melihat siaran, yang jumlahnya mencapai angka 2 juta , sudah cukup. Apa yang terjadi jika Anda melihat siaran pertandingan "dari dalam", dan bagaimana Anda bisa mengatur lalu lintas yang belum pernah terjadi sebelumnya?

Tiga paus

1. Arsitektur situs dan sistem terjemahan

Skema umum interaksi antara pengguna akhir dan sistem terjemahan dikurangi menjadi skema berikut:

Pengguna datang ke situs tempat pemain diluncurkan untuk menonton video. Pemain itu sendiri ditulis dalam JavaScript dan memuatnya mengarah ke banyak permintaan statika, serta berbagai API yang terkait dengan terjemahan.
Antara lain, ada banding ke balancer untuk daftar putar untuk pemutaran.
Daftar putar adalah sekumpulan fragmen video pendek yang terus diperbarui yang di-cache di server CDN.
Saat menonton video pengguna secara waktu nyata, berbagai statistik dikumpulkan, yang, khususnya, diperhitungkan untuk penyeimbangan beban oleh CDN (bersama dengan bandwidth aktual yang tersedia).

Arsitektur untuk distribusi langsung video dirancang dan diimplementasikan oleh kekuatan internal insinyur pelanggan bahkan sebelum dimulainya kerjasama kami. Kemudian, selain layanan itu sendiri, kami terlibat dalam desain dan commissioning infrastruktur untuk beberapa komponennya, serta situs itu sendiri, yang memainkan peran penting dalam skema keseluruhan.

Situs, yang diluncurkan dalam produksi beberapa tahun lalu, difokuskan pada skalabilitas horizontal - termasuk banyak pusat data:

Skema yang disajikan di sini disederhanakan dan dimaksudkan untuk menunjukkan sifat skalabilitas situs, yang komponennya didistribusikan di berbagai pusat data.

2. CDN

Kembali benar-benar menonton video, jelas bahwa beban utama jatuh pada server CDN. Dalam angka untuk Piala Dunia masa lalu, kita berbicara tentang lalu lintas konstan, yang diukur dalam terabit per detik . Dan dalam banyak hal, keberhasilan karya terjemahan dengan beban puncak adalah karena caching pada CDN dari segala sesuatu yang dapat ditransfer ke mereka, dan meminimalkan biaya sumber daya (jaringan, CPU, RAM, ...) dari operasi lain.

Selain itu, poin penting dalam bekerja dengan CDN adalah interaksi dengan API mereka untuk mendapatkan informasi yang relevan tentang total dan bandwidth yang tersedia. Dalam sistem siaran, data ini digunakan untuk mendistribusikan pemirsa baru dan mendistribusikan kembali yang sekarang.

Jadi, jika server CDN dapat menyediakan bandwidth yang cukup untuk jutaan pemirsa Internet, lalu kapan masalah bisa terjadi? Selama kejuaraan, kami mengamati dua skenario utama:

Untuk beberapa alasan, ada jeda dalam siaran.

Sebagai contoh, pengaturan sistem yang "dimainkan" di salah satu pertandingan kejuaraan sehingga layanan perlindungan DDoS, yang tidak mengharapkan muatan yang tiba-tiba, mulai menganggap apa yang terjadi sebagai serangan, memblokir ketersediaan server CDN satu demi satu ... sampai diberitahukan bahwa situasinya adalah dalam arti ekstrim, tetapi masih penuh waktu (kesimpulan yang diperlukan dibuat - dalam siaran berikutnya situasinya tidak terulang).

Pada saat-saat seperti itu, semua pengguna yang dikalahkan oleh masalah besar mulai menyegarkan halaman dengan pemain.
Suatu gol yang dicetak (terutama yang pertama), sebagai suatu peraturan, memprovokasi gelombang besar penonton dalam periode waktu yang terbatas.

Jika kita berbicara tentang angka yang lebih spesifik, maka arus masuk sebesar ratusan ribu pengguna dalam 1-1,5 menit.

Kedua kasus ini menghasilkan lonjakan tajam dalam permintaan untuk konten situs dinamis yang perlu ditangani oleh sumber daya yang tersedia. Bagaimana masalah tersebut dilacak dan diselesaikan?

3. Pemantauan dan statistik waktu nyata

Dimungkinkan untuk bercanda dengan tingkat kebenaran yang signifikan bahwa selama seluruh kejuaraan, kami memiliki jabatan khusus, yang tugasnya termasuk menonton sepak bola dengan penuh perhatian di tempat kerja. Tentu saja, itu bukan tentang sepakbola seperti itu, tetapi tentang reaksi cepat terhadap insiden yang dipicu oleh pertandingan atau keadaan lainnya ...

Apa "keadaan lain"? Pada acara-acara publik seperti itu, bahkan pengaruh cuaca pun terlihat. Berikut adalah dua contoh dari kejuaraan yang kami temui:

Ketika badai mulai selama salah satu pertandingan, penyedia TV satelit memiliki masalah peralatan (mereka tidak bisa mengirim sinyal). Hal ini menyebabkan lonjakan lalu lintas yang nyata (sekitar 10%) dalam waktu singkat, karena dalam mencari solusi alternatif yang mendesak, pemirsa mulai online secara besar-besaran dan melanjutkan penelusuran di sana.
Ketika hujan mulai turun pada pertandingan terakhir, sedikit (sekitar 3%) lompatan pemutusan dan koneksi ulang pengguna (setelah sekitar 5 menit) terlihat. Dalam hal ini, tidak ada masalah yang diamati dalam siaran itu sendiri, yaitu alasan untuk lompatan tidak memiliki dasar teknis. Asumsinya adalah bahwa penonton yang menonton sepak bola di jalan (seperti saya sendiri) pindah ke kamar karena hujan, dan untuk waktu yang singkat ini mereka terputus dari siaran.

Kembali ke topik pemantauan itu sendiri - selama berlangsungnya seluruh kejuaraan, praktik pertemuan reguler (setelah setiap siaran puncak) dianggap normal oleh para pengembang, yang menganalisis semua situasi kritis (atau yang dekat dengan itu) dan konsekuensinya - untuk meminimalkan potensi masalah di lain kali Server / layanan apa yang ada pada batasnya? Pertanyaan apa yang sangat menuntut? Permintaan apa yang dapat dihapus (ditransfer ke CDN ke cache selama beberapa detik)? Permintaan apa yang bisa di-cache lebih lama (setiap 3 menit, bukan per menit)? Apa yang akan terjadi dengan proyeksi peningkatan jumlah penonton, karena Rusia akan bermain? ..

Berbicara tentang Rusia. Seperti yang Anda tebak, rata-rata beberapa kali lebih banyak orang datang ke pertandingan dengan tim nasional Rusia daripada yang lain. Dan semakin jauh tim kami naik braket turnamen, semakin sulit untuk menggabungkan kegembiraan kami dalam hal ini dengan kinerja tugas langsung - karena semuanya rumit oleh pertumbuhan penonton yang tak kenal lelah. Terlepas dari kenyataan bahwa sistem ini dirancang untuk menahan beban yang sangat besar, dalam jadwal kerja normal hal itu tidak sering terjadi (kurang dari 10 kali setahun) ... dan dalam kasus Piala Dunia, kami mengamati puncak beban hampir setiap hari selama sebulan. Keuntungan dari mode ini, bagaimanapun, adalah kemungkinan luas untuk mendeteksi kemacetan aktual yang terdeteksi hanya pada saat-saat beban seperti itu.

Jadi, jika bagian dari masalah teknis murni dihilangkan oleh grafik standar dari sistem pemantauan, maka dalam solusi masalah yang lebih kompleks dan / atau berorientasi logika bisnis, pencapaian proyek dengan nama internal yang berbicara "Statistik waktu nyata" memainkan peran besar.

Statistik waktu nyata

Komponen penting dari infrastruktur penyiaran Internet ini dirancang dan diimplementasikan oleh upaya kami untuk menyediakan alat intelijen bisnis untuk data teknis yang dikumpulkan dari pemain tempat pengguna menonton video. Pada intinya, ini adalah sistem logging yang:

mengumpulkan semua jenis data yang tersedia tentang pengguna (browser, IP, dll. - untuk kesederhanaan, kita dapat mengatakan bahwa ini adalah karakteristik yang biasa kita lihat dalam statistik di audiens situs);
melengkapi mereka dengan data teknis tentang penyiaran (bitrate, dll.) dan peristiwa / masalah yang telah terjadi (pengalihan CDN, kegagalan melihat ...);
menyediakan penyeimbang dengan data untuk penyeimbangan beban optimal pada server CDN (sesuai dengan karakteristik masing-masing pengguna);
mengirimkan peringatan yang diperlukan kepada teknisi yang bertugas dan membuat bagan bisnis yang bermanfaat.

Poin terakhir adalah yang paling menarik, karena:

Peringatan sistem statistik ini adalah komponen kunci dari pemantauan yang memungkinkan Anda untuk "mengikuti perkembangan" indikator praktis selama siaran. Menganalisa mereka (di tempat di mana otomatisasi tidak cukup), petugas membuat keputusan yang tepat untuk meningkatkan kualitas layanan secara real time. Sebagai contoh:
- Apakah banyak pengguna beralih dari server CDN yang sama? Itu harus sementara dinonaktifkan dari rotasi (atau hubungi penyedia untuk respon cepat).
- Sudahkah pengguna mulai mengalami masalah besar menonton video? Saatnya untuk analisis mendesak penyebabnya.
Bagan adalah statistik bisnis real-time yang memungkinkan Anda untuk menjawab pertanyaan-pertanyaan utama, seperti:
- Berapa banyak pengguna yang menonton siaran terakhir?
- Berapa persentase pengguna yang memiliki masalah pada menit terakhir, dan apa sifat mereka?
Karena peristiwa serupa memiliki profil grafik yang sama, grafik itu sendiri memungkinkan Anda untuk memprediksi pertumbuhan jumlah pengguna selama beberapa menit berikutnya dan mengambil tindakan proaktif jika perlu.

Karena statistik ini bekerja secara real time dan sangat penting untuk kualitas seluruh layanan, bahkan menonton video sederhana secara alami oleh jutaan pengguna tidak akan mudah untuk mendistribusikan konten melalui CDN kepada mereka. ClickHouse DBMS membantu mencapai perekaman cepat data baru dari banyak pemain (kita berbicara tentang puluhan ribu permintaan per detik untuk merekam ke setiap server), dan Grafana biasa digunakan untuk grafik.

Ilustrasi rasio pemirsa video online sebelum, selama dan setelah pertandingan

Omong-omong : Solusi yang menarik selama beban puncak adalah menonaktifkan HTTPS (mendukung HTTP) untuk permintaan dari sistem statistik, yang menyebabkan pengurangan dua kali lipat pada beban CPU pada beberapa server.

Ringkasan

Keberhasilan siaran online dari acara berskala besar (bahkan YouTube TV tidak selalu dapat mengatasi beban!) Disediakan oleh tiga faktor utama:

arsitektur yang kompeten (untuk sistem dan situs siaran), yang bahkan tanpa menggunakan sistem modern seperti Kubernetes pada awalnya berorientasi pada muatan tinggi, skalabilitas, dan kesiapan untuk semburan signifikan;
Server CDN dengan bandwidth yang cukup;
pemantauan khusus, yang memungkinkan: a) untuk melacak masalah secara real time, b) untuk memberikan informasi yang diperlukan untuk menghindarinya di masa depan.

Meskipun sebenarnya ada lebih banyak faktor ... dan salah satunya, mungkin, dapat melampaui semua faktor teknis - manusia. Peran paling penting dimainkan oleh para spesialis yang tidak hanya mampu melakukan dan mengikat semua yang diperlukan secara teknis, tetapi juga tanpa lelah mencapai hasil, yang secara khusus ingin saya perhatikan manfaat dari manajemen pelanggan.

NB tentang Kubernet yang disebutkan ... sebuah kisah yang mungkin diharapkan banyak pembaca dari blog kita. Proses migrasi sistem penyiaran ke sana sudah dimulai, tetapi selama Piala Dunia, perkembangan ini belum terlibat.

Banyak sekali Piala Dunia 2018