🕐 😈 🏦 HighLoad ++, Mikhail Raichenko (ManyChat): hampir tanpa sulap, atau betapa mudahnya mendistribusikan aliran video terabit 🙋🏽 🗽 🗞️

Konferensi HighLoad ++ berikutnya akan diadakan pada 6 dan 7 April 2020 di St. Petersburg. Detail dan tiket di sini . HighLoad ++ Moscow 2018. Hall "Delhi + Calcutta". 8 November, 2 malam Abstrak dan presentasi .

Saya bekerja di tim VKontakte dan saya mengembangkan sistem penyiaran video.
Dalam laporan tersebut, saya akan membagikan fitur-fitur pengembangan backend, bagaimana sistem kami telah berkembang, dan solusi teknis yang kami miliki: 

bagaimana kami melakukan backend siaran video, dan proses evolusi seperti itu;
dampak persyaratan bisnis dan operasional pada arsitektur;
"Tunggu" dan "coba lagi" akan gagal;
bagaimana tugas yang paling sederhana menjadi rumit oleh jumlah pengguna;
cara mengurangi latensi tanpa UDP;
Kami melakukan tes stres 2 kali sehari, atau apa yang Clover bantu.

Mikhail Raichenko (selanjutnya - MR): - Sebuah perjalanan kecil. Saya akan memberi tahu Anda tentang orang-orang yang mengalirkan kami, tentang siaran langsung (live), tentang platform mana kami menerima aliran video dan yang kami distribusikan. Pada akhirnya, saya akan berbicara tentang arsitektur live saat ini, tentang keterbatasan dan kemampuannya, serta bagaimana arsitektur saat ini bertahan dari efek seperti "Clover".

Tentang siaran langsung. Garis besar laporan

Pertama, saya akan berbicara sedikit tentang siaran langsung dan streaming sendiri, mengirimkan kepada kami konten video yang kami tampilkan kepada pemirsa lain.
. ? , , , , - - , - , . , : , – .
. , . . , , .
, , . , . , , , , , 2014-2015 . , .
. , .
, . , . , .
, . .
, , «», .

Semua layanan siaran terlihat seperti ini:

Kami memiliki beberapa streamer, ia mengirimkan aliran RTMP kepada kami, dan kami menunjukkan kepada audiens - tidak ada yang mengejutkan, tidak ada yang supernatural.

Dari mana asal aliran video? Sumber lalu lintas yang signifikan bagi kami adalah aplikasi mobile kami VKlife. Apa bagusnya dia? Di dalamnya, kita dapat sepenuhnya mengontrol bagaimana kita menyandikan video. Kami dapat membuat banyak optimasi di sisi klien, sehingga nanti, dengan penundaan minimal, menunjukkannya kepada pemirsa kami.

Kekurangannya: aplikasi seluler bekerja di atas jaringan. Itu bisa 3G ... Dalam hal apa pun, hampir selalu jaringan seluler, yang menyebabkan beberapa kelambatan - Anda juga perlu menyangga data di sisi aplikasi, sehingga aliran berjalan semulus mungkin.

Sumber kedua adalah streamer dengan OBS, Wirecast atau mereka yang streaming dari aplikasi desktop lain. Ini adalah audiens yang cukup besar. Kadang-kadang ini adalah seminar, kadang-kadang - aliran permainan (ada banyak dari mereka dari aplikasi seperti itu). Dari yang positif: ada beberapa aplikasi seperti itu, kami dapat memberikan rekomendasi tuning yang bagus untuk streamer kami. Tetapi pada saat yang sama ada banyak pengaturan dan mengirim tidak cukup aliran yang kita inginkan.

Kategori ketiga adalah aliran RTMP dari server media. Ini bisa berupa server media yang sangat kecil, yaitu, format rumah: seseorang mengalirkan pandangan ke jalan atau sesuatu yang lain. Atau siaran yang cukup serius dari mitra kami: bisa ada apa saja, tidak ada banyak aliran seperti itu, tetapi pada dasarnya mereka sangat penting bagi kami.

Siapa yang memperhatikan?

Sekali lagi, ini adalah aplikasi seluler - semuanya jelas di sini. Masalah terbesar adalah latensi jaringan. Dari pro: kami dapat menyesuaikan pemain - nyaman bagi kami, bagus, tapi tidak di mana-mana ternyata 100%.

Pemain web di vk.com. Di sini juga, semuanya sederhana - ini adalah pemutar web biasa yang dapat Anda buka untuk ditonton. Pemirsa yang cukup besar di vk.com, banyak pemirsa di siaran. Beberapa siaran menggantung di bagian "Video" kami - mungkin ada puluhan ribu (kadang-kadang tanpa PR), terutama jika ini adalah konten yang menarik.

Dengan demikian, salurannya cukup besar untuk pemirsa yang duduk di pemutar web. Karena itu, ada banyak lalu lintas, termasuk untuk satu siaran.

Yang ketiga adalah pemutar web VKontakte di beberapa situs pihak ketiga. Anda dapat mulai mengalirkan semua yang Anda inginkan, dan menggantung pemutar web VKontakte di situs web Anda. Anda dapat menjadi mitra kami jika Anda memiliki konten yang menarik: Anda dapat menggantungnya sendiri, Anda dapat bergaul dengan kami - sesuai keinginan. Anda dapat mengatur siaran Anda dengan cara ini, dan semuanya akan berfungsi.

Perbandingan dengan panggilan video

Dalam panggilan video, beberapa distorsi gambar akan dimaafkan. Panggilan video lebih sederhana: kita dapat secara signifikan menurunkan gambar, tetapi pada saat yang sama kita harus menjaga latensi yang sangat baik. Dengan penundaan yang lama, layanan ini sama sekali tidak mungkin digunakan.

Dalam siaran dalam pengertian ini, ini agak sebaliknya: kita harus mempertahankan kualitas gambar yang tinggi, tetapi pada saat yang sama kita dapat meningkatkan latensi karena banyak faktor. Sebagai contoh, pemain buffer aliran dalam satu atau lain cara (itu bisa menjadi yang kedua, dua untuk bertahan dari degradasi jaringan, misalnya), oleh karena itu, tidak perlu kedua, penundaan milidetik dalam banyak kasus. Anda dapat berjuang untuk ini, tetapi makanan bukanlah prasyarat.

Dengan video biasa, situasinya justru sebaliknya. Kami membutuhkan kualitas yang sangat baik. Pada saat yang sama, diinginkan untuk meminimalkan ukuran video, rasio bitrate dan kualitas, sehingga dengan aliran minimum, memberikan solusi terbaik. Dari pro: kami tidak terbatas dalam waktu: pada saat mengunduh video, kami memiliki cukup waktu untuk mengoptimalkan video, melihat bagaimana mengompresnya dengan cara terbaik, melakukan sesuatu, menyeretnya ke cache, jika perlu - secara umum, semuanya sudah cukup BAIK.

Dalam siaran langsung, situasinya, sekali lagi, kebalikannya: kami memiliki sedikit waktu untuk transcoding. Pada saat yang sama, ada beberapa peluang, tetapi tidak ada harapan untuk siaran. Penonton akan memaafkan kami jika kami memiliki dukungan atau kualitasnya tidak terlalu bagus.

Versi pertama

Sangat diharapkan:

Sebenarnya, ini sedikit berbeda:

"Streamer - server media - level cache - pemirsa". Pada prinsipnya, versi ini memungkinkan Anda untuk skala cukup kuat. Saya akan mengatakan bahwa itu seharusnya sudah menahan puluhan ribu penonton. Ini memiliki kelemahan lain ...

Misalnya, jika Anda melihat sirkuit ini (slide sebelumnya), Anda dapat melihat bahwa itu tidak toleran terhadap kesalahan. Kita harus menebak dengan server media untuk menyeimbangkan audiens dengan baik. Kami tidak dapat menggantung banyak cache di setiap server - ini cukup mahal. Oleh karena itu, kami melihat, menyadari bahwa itu sederhana dan jelas, ada beberapa kemungkinan penskalaan, tetapi jelas ada sesuatu yang hilang ... Dan kami mulai merumuskan persyaratan.

Persyaratan infrastruktur

Apa yang penting

. , , . ( ). (, ).
. : -, (, ) ; -, – , , .
Pengiriman ke daerah. Juga poin penting! Sangat bodoh untuk menyeret semua konten video dari Petersburg atau Moskow ke semacam Novosibirsk, Yekaterinburg, atau bahkan dari St. Petersburg ke Moskow. Ini tidak terlalu baik, karena penundaan jaringan akan lama - akan ada kelambatan, semuanya akan ketinggalan, dan ini tidak baik. Oleh karena itu, infrastruktur kami harus mempertimbangkan bahwa kami mengirimkan konten ke wilayah.
Kemudahan operasi dan pemantauan. Properti penting. Karena sistemnya besar, ada banyak pemirsa, penting untuk mengirimkan peringatan kepada administrator jika ada masalah, termasuk memantau metrik produk dan teknis.

Seperti apa infrastruktur penyiarannya sekarang?

Akibatnya, kami sampai pada infrastruktur yang cukup sederhana namun efektif ...

– , ( , ). RTMP-, . , .
, , , , . . , , , – : , -, (. . ); -, .
. – , . , , . , ( , ).
, (edge-). , . !
– edge-, , . : , – .

Menarik? Seimbang! Dalam skema ini, kami memilih menyeimbangkan, mencoba mengirim pemirsa yang menonton streaming yang sama ke setiap server tepi. Cache locality sangat penting di sini, karena mungkin ada banyak server tepi; dan jika kita tidak mengamati temporer dan lokalitas cache dari sudut pandang aliran, maka kita akan membebani lapisan dalam. Kami juga tidak akan menyukainya.

Oleh karena itu, kami menyeimbangkan dengan cara berikut: kami memilih server tepi tertentu untuk wilayah tempat kami mengirim pemirsa, dan mengirim hingga kami mulai memahami bahwa beberapa pengisian telah terjadi dan harus dikirim ke server lain. Rangkaiannya sederhana dan bekerja sangat andal. Secara alami, untuk aliran berbeda Anda memilih urutan berbeda dari server tepi (urutan di mana kami mengirimkan penonton). Karenanya, menyeimbangkan bekerja cukup sederhana.

Kami juga memberikan klien tautan ke server tepi yang tersedia. Hal ini dilakukan agar dalam kasus kegagalan edge-server, kita dapat mengarahkan penampil ke yang lain. Yaitu, ketika pemirsa menonton siaran, ia menerima tautan ke server yang diinginkan setiap beberapa detik sekali. Jika dia mengerti bahwa tautannya harus berbeda, dia beralih (pemutar beralih) dan terus menonton siaran dari server lain.

Peran penting lain dari server tepi adalah perlindungan konten. Semua perlindungan konten pada dasarnya terjadi di sana. Kami memiliki modul nginx kami sendiri untuk ini. Ini agak mirip dengan Tautan Keamanan.

Penskalaan dan penyeimbangan

. , : , . edge-, . . . … , – , -- – , – , , , – ! – .
. , , , , : . ( ) , – , . , , , edge-.
, , , .

?

Salah satu protokol utama yang kami miliki adalah RTMP (tidak hanya untuk input, tetapi juga untuk distribusi konten). Keuntungan utama adalah latensi rendah. Itu bisa setengah detik, kedua, dua detik. Bahkan, manfaatnya berakhir di sana ...

Protokol streaming ini sulit dipantau - ditutup dalam arti tertentu, meskipun ada spesifikasi. Pemutar Flash tidak lagi berfungsi (sebenarnya, "sudah semuanya"). Butuh dukungan di tingkat CDN - Anda memerlukan modul nginx khusus atau perangkat lunak Anda sendiri untuk mentransfer aliran secara normal. Ada juga beberapa kesulitan dengan klien seluler. Di luar kotak di klien seluler didukung sangat buruk - perbaikan khusus diperlukan, dan semua ini sangat sulit.
Protokol kedua yang kami gunakan adalah HLS. Itu terlihat cukup sederhana: itu adalah file teks, yang disebut file indeks. Ini berisi tautan untuk mengindeks file dengan izin berbeda, dan file itu sendiri berisi tautan ke segmen media.

Bagaimana dia baik? Ini sangat sederhana, meski sudah agak tua. Ini memungkinkan Anda untuk menggunakan CDN, yaitu, Anda hanya perlu nginx untuk mendistribusikan protokol HLS. Dapat dipahami dalam hal pemantauan.

Inilah kelebihannya:

kemudahan operasi - nginx sebagai server proxy;
mudah untuk memantau dan mengambil metrik (cukup bagi Anda untuk memantau hampir sama dengan apa yang Anda pantau di situs web Anda);
Sekarang protokol ini adalah yang utama untuk pengiriman konten.

Minus signifikan:

latensi tinggi.

Latensi HLS sebenarnya bersarang dalam protokol itu sendiri; karena waktu penyangga yang lama diperlukan, pemain dipaksa untuk menunggu setidaknya ketika satu bongkahan dimuat, tetapi dengan cara yang baik ia harus menunggu sampai dua bongkahan (dua segmen media) dimuat, jika tidak dalam kasus kelambatan klien akan memiliki beban pemain, dan ini tidak terlalu mempengaruhi pengalaman pengguna.

Poin kedua yang memberi penundaan pada HLS adalah caching. Daftar main di-cache pada lapisan dalam dan di server tepi. Bahkan jika kita melakukan cache, secara relatif, selama satu detik atau setengah detik, maka ini kira-kira ditambah 2-3 detik keterlambatan. Secara total, ternyata dari 12 hingga 18 detik - ini tidak terlalu menyenangkan, jelas itu lebih baik.

Meningkatkan HLS

Dengan pemikiran ini, kami mulai meningkatkan HLS. Kami memperbaikinya dengan cara yang agak sederhana: mari kita beri segmen media terakhir dari daftar putar sedikit lebih awal. Artinya, segera setelah kami mulai menulis segmen media terakhir, kami segera mengumumkannya di daftar putar. Apa yang terjadi pada saat ini? .. Waktu

buffering di pemain berkurang. Pemain percaya bahwa dia telah mengunduh semuanya, dan dengan tenang mulai mengunduh segmen yang diinginkan. Dengan cara ini kami "menipu" pemain dengan cara ini, tetapi jika kami memantau "baja" (memuat pemain) dengan baik, itu tidak membuat kami takut - kami dapat berhenti memberikan segmen sebelumnya dan semuanya akan kembali normal.

Poin kedua: kami memenangkan total sekitar 5-8 detik. Mereka berasal dari mana? Waktu segmen ini adalah 2 hingga 4 detik per segmen, ditambah waktu untuk menyimpan daftar putar (ini adalah 2-3 detik lainnya). Penundaan kami menurun, apalagi, secara signifikan. Penundaan dikurangi dari 12-15 detik menjadi 5-7.

Apa lagi yang baik dalam pendekatan ini? Ini sebenarnya gratis! Kami hanya perlu memeriksa apakah para pemain kompatibel dengan pendekatan ini. Yang tidak kompatibel, kami kirim ke URL lama, dan kami mengirim pemain yang kompatibel ke URL baru. Kami tidak perlu memutakhirkan klien lama yang mendukung ini, yang juga penting. Kami sebenarnya tidak perlu memodifikasi, melepaskan pemain di klien seluler. Kami tidak perlu mengembangkan pemain web. Terlihat cukup bagus!

Dari minus - kebutuhan untuk mengontrol aliran video yang masuk. Dalam kasus klien seluler, kita dapat melakukan ini dengan cukup mudah (ketika streaming berasal dari klien seluler), atau transcode tanpa gagal, karena pemain harus tahu berapa lama waktu yang dibutuhkan untuk satu segmen media. Dan karena kita mengumumkannya sebelum benar-benar direkam, kita perlu tahu berapa banyak waktu yang diperlukan ketika kita merekamnya.

Metrik kualitas

Dengan demikian, kami telah meningkatkan HLS. Sekarang saya ingin memberi tahu bagaimana kami memantau dan metrik kualitas apa yang kami ambil:

Salah satu metrik kualitas utama adalah waktu mulai. Idealnya, ini adalah saat Anda menelusuri klien seluler sebelum siaran, tekan tombol, dan segera dimulai. Ini akan ideal jika dimulai sebelum Anda menekan tombol, tetapi, sayangnya, hanya ketika Anda menekan.
Poin kedua adalah penundaan sinyal. Kami percaya bahwa beberapa detik sangat baik, 10 detik dapat ditoleransi, 20-30 detik sangat buruk. Mengapa ini penting? Misalnya, untuk konser dan beberapa acara publik ini adalah metrik yang sama sekali tidak penting, tidak ada umpan balik; kami hanya menunjukkan aliran - lebih baik tidak ketinggalan daripada sedikit keterlambatan. Dan untuk aliran di mana semacam konferensi sedang berlangsung atau seseorang mengatakan sesuatu dan mereka mengajukan pertanyaan kepadanya, ini mulai menjadi penting, karena mereka mengajukan banyak pertanyaan di komentar dan saya ingin audiens mendapatkan umpan balik sesegera mungkin.

Metrik penting lainnya adalah buffering dan lag. Faktanya, metrik ini penting tidak hanya dari sudut pandang klien dan kualitas, tetapi dari sudut pandang seberapa banyak kita dapat "memperluas" pengiriman HLS, seberapa banyak kita dapat memeras data dari server kami. Oleh karena itu, kami memantau waktu penyangga rata-rata di pemain dan "baja".

Pilihan kualitas di pemain bisa dimengerti: perubahan tak terduga selalu mengganggu.

Karenanya, ini juga merupakan metrik penting.

Pemantauan

Kami memiliki banyak metrik pemantauan, tetapi di sini saya memilih metrik yang selalu berfungsi jika terjadi kesalahan:

-, . - , . , – , ( , – ).
/ . , , , , , . .
edge-. , , edge- .

«», ?

Sekarang saya akan memberi tahu Anda bagaimana kami menangani aplikasi seperti "Player" ketika kami menggunakan infrastruktur kami untuk menyiarkan aliran video dengan pertanyaan dan jawaban.

Clover adalah kuis online. Tuan rumah mengatakan sesuatu, bertanya: pertanyaan rontok - Anda menjawab. 12 pertanyaan, 10 menit pertandingan, pada akhirnya - semacam hadiah. Apa yang rumit? Ini pertumbuhan!

Di sebelah kanan adalah grafik ini:

Puncak [pada grafik] adalah beban pada server dalam hal API pada saat dimulainya "Semanggi". Sisa waktu adalah aliran siaran yang biasa. Ini tidak bisa disamakan dengan jumlah pemirsa. Mungkin ini jumlah permintaan dan bebannya.

Sulit: dalam 5 menit satu juta penonton mendatangi kami di puncak. Mereka mulai menonton siaran, mendaftar, melakukan semacam aksi, meminta video ... Tampaknya ini adalah permainan yang sangat sederhana, tetapi ini terjadi dalam periode waktu yang sangat singkat (semua aksi, termasuk permainan terakhir) - ini memberikan beban yang cukup tinggi.

Pertanyaan dan tantangan apa yang kita hadapi?

Pertumbuhan yang cepat. Terkadang +50% per minggu. Jika, misalnya, Anda memiliki 200 ribu orang pada hari Rabu, maka pada hari Sabtu atau Minggu mungkin sudah ada 300. Itu banyak! Masalah mulai muncul ke permukaan yang sebelumnya tidak terlihat.
2 . . , . , , , , , .
12 . , , , , , - , , …
, . , , 200-300 , 400-500.
- , , , 3-5 . ? «», , , , .

( 3 , ), , 3-5 . ? – , – exponential backoff, .

exponential on backoff: – , 2 , 4, 8. backend-.

«»?

-, . , – .
« ». , , , , «». , , -, , -, .
, – , «» . «». , , , … – . 10% «» – , 10% «» 100 – .
«» , , «» . – - . 100 – , 1 15 – .
. «» , , , . , , .
. , . , latency, .
. – , .
«» 1 . , , . . , , . .

?

Arsitektur sepenuhnya cocok untuk kita, dan saya dapat merekomendasikannya dengan aman. HLS akan tetap bersama kami protokol utama untuk setidaknya situs web dan setidaknya protokol cadangan untuk yang lainnya. Mungkin kita akan beralih ke MPEG-DASH.

RTMP yang ditinggalkan. Terlepas dari kenyataan bahwa itu memberikan penundaan yang lebih rendah, kami memutuskan bahwa kami akan menyetel HLS. Mungkin mempertimbangkan kendaraan pengiriman lain, termasuk DASH sebagai alternatif.

Kami akan meningkatkan saldo yang masuk. Kami juga ingin membuat failover mulus untuk penyeimbangan masuk, sehingga jika terjadi masalah pada salah satu server media untuk klien, peralihan akan benar-benar tidak terlihat.

Mungkin kami akan mengembangkan sistem pengiriman dari server tepi ke klien. Kemungkinan besar, itu akan menjadi semacam UDP. Yang mana - yang sekarang kita pikirkan dan sedang dalam tahap penelitian.

Sebenarnya itu saja. Terimakasih untuk semua!

Pertanyaan

Pertanyaan dari hadirin (selanjutnya - A): - Terima kasih banyak atas laporannya! Hanya pembicara dari Odnoklassniki yang berbicara, dan dia berkata bahwa mereka harus menulis ulang streamer, encoder, encoder ... Apakah Anda menggunakan solusi seperti itu atau menggunakan stock yang ada di pasaran (seperti Harmonic, dll.)?

MR: - Sekarang kami telah memutar solusi pihak ketiga. Dari solusi open source yang kami gunakan, kami memiliki nginx, modul RTMP (untuk waktu yang lama). Di satu sisi, dia senang kita karena dia bekerja, cukup sederhana. Kami bertarung untuk waktu yang sangat lama sehingga ia akan bekerja dengan stabil. Sekarang dia pindah dari Nginx-RTMP ke solusinya sendiri. Kami berpikir dengan transcoder sekarang. Penerima, yaitu bagian penerima, juga telah ditulis ulang dari Nginx-RTMP menjadi solusinya.

DAN:- Saya ingin mengajukan pertanyaan tentang mengiris RTMP pada HLS, tetapi seperti yang saya mengerti, Anda sudah menjawab ... Katakan padaku, apakah solusi Anda open-source?

MR: - Kami sedang mempertimbangkan untuk merilisnya di opensource. Kami lebih suka ingin merilisnya, tetapi pertanyaannya adalah waktu rilis di open source. Masukkan saja sumbernya di Internet - ini tidak cukup. Anda perlu berpikir, membuat beberapa contoh penyebaran. Dan untuk tujuan apa Anda bertanya? Ingin menggunakan?

A: - Karena saya juga menemukan Nginx-RTMP! Singkatnya, tidak didukung untuk waktu yang sangat lama. Penulis bahkan tidak menjawab terutama pertanyaan ...

MR: - Jika Anda mau, Anda bisa menulis surat. Berikan untuk penggunaan sendiri? Kita bisa setuju. Kami benar-benar berencana untuk membukanya.

DAN:- Anda juga mengatakan bahwa Anda dapat pindah dari HLS ke DASH. HLS tidak cocok?

MR: - Ini adalah pertanyaan tentang apa yang kita bisa, atau mungkin tidak. Ini sangat tergantung pada apa yang akan kita bahas dalam hal meneliti metode pengiriman alternatif (mis. UDP). Jika kami menemukan sesuatu yang "sepenuhnya" bagus, maka kami mungkin tidak akan menyentuh HLS. Jika tampaknya MPEG-DASH lebih nyaman - mungkin kita akan memindahkannya. Tampaknya tidak terlalu sulit, tetapi kami tidak yakin apakah itu perlu atau tidak. Sinkronisasi antara aliran, antara kualitas dan hal-hal lain jelas lebih baik di sana. Ada plusnya.

A: - Mengenai peringatan. Anda berbicara tentang fakta bahwa jika streaming berhenti mengalir, maka ini segera peringatan. Dan Anda tidak menangkap sesuatu yang independen dari Anda: penyedia jatuh, Megafon jatuh, dan orang-orang berhenti mengalir? ..

MR:- Anggap saja sesuatu yang independen dari kita pada dasarnya adalah semua jenis liburan dan seterusnya. Ya mereka melakukannya. Ya, benar. Administrator melihat - hari ini adalah hari libur, karakteristik lainnya baik-baik saja - mereka tenang.

A: - Dan tentang penskalaan. Pada tingkat apa skala itu? Misalnya, saya meminta aliran dari telepon - akankah saya segera menerima tautan tertentu dengan server-abu yang benar?

MR: - Tautan akan segera datang dan, jika perlu, akan mengalihkan Anda (jika ada masalah pada server tertentu).

A: - Siapa yang akan beralih?

MR: - Pemutar seluler atau pemutar web.

A: - Dia akan memulai kembali aliran atau apa?

MR: - Tautan baru akan datang kepadanya di mana ia harus pergi siaran langsung. Dia akan pergi ke sana dan bertanya kembali sungai.

DAN:- Di level apa Anda menyimpan cache? Dan daftar putar, dan potongan, atau hanya itu?

MR: - Dan daftar putar, potongan! Tembolok sedikit berbeda, baik dari segi waktu maupun dari pengembalian waktu, tetapi kami menyimpan keduanya.

A: - Mengenai penciptaan ash-server? Apakah Anda memiliki situasi seperti itu sehingga Anda menonton 2 juta pemirsa di satu siaran, tidak punya waktu untuk sesuatu dan dengan cepat mengambil beberapa server ash? Atau apakah Anda menaikkan semuanya terlebih dahulu dengan margin?

Pak:- Mungkin ini bukan. Pertama, stok selalu kecil atau besar - tidak masalah. Kedua, tidak terjadi siaran yang tiba-tiba menjadi sangat populer. Kami dapat memprediksi jumlah pemirsa dengan baik. Pada dasarnya, untuk memiliki banyak orang, kita harus berusaha. Dengan demikian, kita dapat menyesuaikan jumlah pemirsa siaran, tergantung pada upaya apa yang dilakukan.

A: - Anda mengatakan bahwa Anda mengukur keterlambatan instrumental di pihak pemain. Bagaimana?

MR: - Sangat sederhana. Dalam potongan (di segmen media) kami memiliki stempel waktu, atas nama segmen media - di pemain kami hanya mengembalikannya. Jika dia tidak secara eksplisit sama sekali, dia kembali.

A: - Saya ingat mencoba menjalankan peering di WebRTC. Kenapa ditolak?

Pak:"Aku tidak bisa menjawab pertanyaan ini untukmu - itu terjadi tanpaku." Saya tidak bisa mengatakan mengapa saya mencobanya dan saya tidak bisa mengatakan mengapa saya menolak.

A: - Mengenai receiver dan server media. Seperti yang saya pahami, dulu Anda punya Nginx-RTMP, sekarang baik di sana maupun di sana Anda memiliki solusi buatan sendiri. Bahkan, ini adalah salah satu server media yang proksi server media lain, dan mereka sudah ada di cache dan di tepi.

MR: - Jadi, tidak juga. Ini adalah solusi buatan sendiri, tetapi berbeda dalam hal server media dan dalam hal penerima. Nginx-RTMP - itu semacam pemanen yang bisa melakukan keduanya. Interior penerima dan server media kami sangat berbeda - baik berdasarkan kode maupun keseluruhan. Satu-satunya hal yang menyatukan mereka adalah pemrosesan RTMP.

A: - Mengenai keseimbangan di antara ujung-ujungnya. Bagaimana ini bisa terjadi?

MR: - Kami mengukur lalu lintas, mengirimkannya ke server yang diinginkan. Saya tidak mengerti sedikit pertanyaan ...

A: - Saya akan menjelaskan: pengguna meminta daftar putar melalui pemain - ia mengembalikan jalur relatif ke manifes dan potongan atau jalur absolut, misalnya, dengan IP atau domain? ..

MR: - Jalur relatif.

A: - Artinya, tidak ada penyeimbangan saat melihat aliran oleh satu pengguna?

MR: - Itu terjadi. Cukup rumit. Kita dapat menggunakan pengalihan 301 saat membebani server. Jika kami melihat semuanya benar-benar buruk di sana, untuk segmen kami dapat mengirimkannya ke server lain.

A: - Tapi itu harus ditransfer ke logika pemain?

Pak:- Tidak, hanya bagian ini yang seharusnya tidak dijahit. Redirect 301! Sederhananya, pemain harus dapat keluar dari tautan 301. Kami dapat mengirimkannya ke server lain dari sisi server pada saat kelebihan beban.

A: - Artinya, dia bertanya pada server, dan server memberikannya kepadanya?

MR: - Ya. Ini tidak terlalu bagus, oleh karena itu, logika pemain digunakan untuk me-retweet tautan ke kasus kegagalan salah satu server - ini sudah ada dalam logika pemain.

A: - Dan Anda tidak mencoba untuk bekerja bukan secara relatif, tetapi secara absolut: ketika Anda meminta pemain untuk melakukan beberapa keajaiban, mencari tahu di mana ada sumber daya dan di mana tidak, dan sudah memberikan daftar putar yang menunjukkan server tertentu?

Pak:- Sebenarnya, ini terlihat seperti solusi yang berfungsi. Jika Anda datang saat itu, kami akan menimbang keduanya! Tetapi solusi saat ini juga berfungsi, jadi saya tidak benar-benar ingin beralih dari satu ke yang lain, meskipun, mungkin, ini juga terlihat seperti solusi yang berfungsi.

A: - Katakan, apakah ini bersahabat dengan multicast? HLS, seperti yang saya pahami, sama sekali tidak ada ...

MR: - Dalam implementasi saat ini, kami mungkin tidak memiliki apa pun dalam sistem dengan multicast yang aktif. Kami tidak memasukkan konsep multicast di sana. Mungkin di suatu tempat di kedalaman admin magic, ada sesuatu di dalam jaringan, tetapi tersembunyi dari semua orang dan tidak ada yang tahu ...

Sedikit iklan :)

Terima kasih untuk tetap bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman Anda, cloud VPS untuk pengembang dari $ 4,99 , analog unik dari server entry-level yang diciptakan oleh kami untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps mulai dari $ 19 atau cara membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya kami yang memiliki 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV dari $ 199 di Belanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai dari $ 99! Baca tentang Cara Membangun Infrastruktur Bldg. kelas c menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?

HighLoad ++, Mikhail Raichenko (ManyChat): hampir tanpa sulap, atau betapa mudahnya mendistribusikan aliran video terabit