Komunikasi video adalah cara komunikasi utama antara guru dan siswa di platform Vimbox. Kami sudah lama meninggalkan Skype, mencoba beberapa solusi pihak ketiga dan akhirnya memilih kombinasi WebRTC - Janus-gateway. Untuk beberapa waktu kami senang dengan semuanya, namun tetap saja beberapa aspek negatif terus bermunculan. Hasilnya, arahan video terpisah dibuat.
Saya meminta Kirill Rogovoy, kepala arah baru, untuk berbicara tentang evolusi komunikasi video di Skyeng, masalah yang ditemukan, solusi dan penopang yang akhirnya kami gunakan. Kami berharap artikel ini bermanfaat bagi perusahaan yang juga membuat video sendiri melalui aplikasi web.
Sedikit sejarah
Pada musim panas 2017, kepala pengembangan Skyeng, Sergey Safonov, berbicara di Backend Conf dengan cerita tentang bagaimana kami βmeninggalkan Skype dan mengimplementasikan WebRTC.β Bagi yang berminat dapat menyaksikan rekaman pidatonya di (~45 menit), dan di sini saya akan menguraikan secara singkat esensinya.
Bagi Skyeng School, komunikasi video selalu menjadi cara prioritas komunikasi guru-siswa. Pada awalnya, Skype digunakan, tetapi secara kategoris tidak memuaskan karena sejumlah alasan, terutama karena kurangnya log dan ketidakmungkinan integrasi langsung ke aplikasi web. Oleh karena itu, kami melakukan segala macam eksperimen.
Sebenarnya, persyaratan kami untuk komunikasi video kira-kira sebagai berikut:
β stabilitas;
β harga rendah per pelajaran;
β merekam pelajaran;
β melacak siapa yang berbicara seberapa banyak (penting bagi kami bahwa siswa berbicara lebih banyak daripada guru selama pelajaran);
β penskalaan linier;
- kemampuan untuk menggunakan UDP dan TCP.
Yang pertama dicoba adalah mengimplementasikan Tokbox pada tahun 2013. Semuanya baik-baik saja, tetapi ternyata sangat mahal - 113 rubel per pelajaran - dan menghabiskan keuntungannya.
Kemudian pada tahun 2015, Voximplant diintegrasikan. Inilah fungsi yang kami perlukan untuk melacak siapa yang berbicara berapa banyak, dan pada saat yang sama solusinya jauh lebih murah: jika hanya audio yang direkam, biayanya 20 rubel per pelajaran. Namun, ini hanya berfungsi melalui UDP dan tidak dapat beralih ke TCP. Namun, sekitar 40% siswa akhirnya menggunakannya.
Setahun kemudian, kami mulai memiliki klien korporat dengan kebutuhan khusus mereka sendiri. Misalnya, semuanya harus bekerja melalui browser, perusahaan hanya membuka http dan https; yaitu tidak ada Skype atau UDP. Klien korporat = uang, jadi kembali ke Tokbox, tapi masalah harga tidak kunjung selesai.
Solusi - WebRTC dan Janus
Memutuskan untuk menggunakan . Ia bertanggung jawab untuk membuat koneksi, menyandikan dan mendekode aliran, menyinkronkan trek, dan mengontrol kualitas dengan menangani gangguan jaringan. Bagi kami, kami harus memastikan pembacaan aliran dari kamera dan mikrofon, menggambar video, mengelola koneksi, membuat koneksi WebRTC dan mentransmisikan aliran ke sana, serta mengirimkan pesan sinyal antar klien untuk membuat koneksi (WebRTC sendiri hanya menjelaskan format datanya, namun bukan mekanisme transfernya). Jika klien berada di belakang NAT, WebRTC menghubungkan server STUN; jika ini tidak membantu, TURN server.
Koneksi p2p biasa tidak cukup bagi kami, karena kami ingin mencatat pelajaran untuk dianalisis lebih lanjut jika ada keluhan. Oleh karena itu kami mengirimkan aliran WebRTC melalui relay . Akibatnya, klien tidak mengetahui alamat satu sama lain, hanya melihat alamat server Janus; itu juga melakukan fungsi server sinyal. Janus memiliki banyak fitur yang kita butuhkan: secara otomatis beralih ke TCP jika UDP klien diblokir; dapat merekam aliran UDP dan TCP; terukur; Bahkan ada plugin bawaan untuk tes gema. Jika perlu, server STUN dan TURN dari Twilio terhubung secara otomatis.
Pada musim panas 2017, kami menjalankan dua server Janus, ditambah server tambahan untuk memproses rekaman file audio dan video mentah, agar tidak menempati prosesor yang utama. Saat terhubung, server Janus dipilih berdasarkan ganjil genap (nomor koneksi). Pada saat itu, ini sudah cukup, menurut perasaan kami, ini memberikan sekitar empat kali lipat margin keamanan, persentase implementasi sekitar 80. Pada saat yang sama, harga diturunkan menjadi ~2 rubel per pelajaran, ditambah pengembangan dan dukungan.
Kembali ke topik komunikasi video
Kami terus memantau masukan dari siswa dan guru untuk mengidentifikasi dan memperbaiki masalah secara tepat waktu. Pada musim panas 2018, kualitas panggilan menduduki peringkat pertama di antara keluhan. Di satu sisi, ini berarti kami telah berhasil mengatasi kekurangan-kekurangan lainnya. Di sisi lain, sesuatu harus segera dilakukan: jika pelajaran terganggu, kita berisiko kehilangan nilainya, terkadang bersamaan dengan biaya pembelian paket berikutnya, dan jika pelajaran pengantar terganggu, kita berisiko kehilangan calon klien. sama sekali.
Saat itu komunikasi video kami masih dalam mode MVP. Sederhananya, mereka meluncurkannya, berhasil, mereka menskalakannya sekali, mereka memahami cara melakukannya - ya, bagus. Jika berhasil, jangan diperbaiki. Tidak ada seorang pun yang dengan sengaja membahas masalah kualitas komunikasi. Pada bulan Agustus, menjadi jelas bahwa hal ini tidak dapat dilanjutkan, dan kami meluncurkan arahan terpisah untuk mencari tahu apa yang salah dengan WebRTC dan Janus.
Sebagai masukan, arahan ini menerima: solusi MVP, tidak ada metrik, tidak ada tujuan, tidak ada proses perbaikan, sementara 7% guru mengeluh tentang kualitas komunikasi (tidak ada data tentang siswa juga).
Arah baru sedang berlangsung
Perintahnya terlihat seperti ini:
- Kepala departemen yang juga merupakan pengembang utama.
- QA membantu menguji perubahan, mencari cara baru untuk menciptakan kondisi komunikasi yang tidak stabil, dan melaporkan masalah dari garis depan.
- Analis terus-menerus mencari berbagai korelasi dalam data teknis, meningkatkan analisis umpan balik pengguna, dan memeriksa hasil eksperimen.
- Manajer produk membantu mengarahkan keseluruhan dan alokasi sumber daya untuk eksperimen.
- Pengembang kedua sering kali membantu pemrograman dan tugas-tugas terkait.
Untuk memulainya, kami menyiapkan metrik yang relatif andal yang melacak perubahan dalam penilaian kualitas komunikasi (rata-rata selama berhari-hari, berminggu-minggu, berbulan-bulan). Pada saat itu, ini adalah nilai dari guru, kemudian nilai dari siswa ditambahkan ke dalamnya. Kemudian mereka mulai membangun hipotesis tentang apa yang salah, memperbaikinya, dan melihat perubahan dalam dinamika. Kami memilih hasil yang mudah: misalnya, kami mengganti codec vp8 dengan vp9, kinerjanya meningkat. Kami mencoba bermain-main dengan pengaturan Janus dan melakukan eksperimen lain - dalam banyak kasus, eksperimen tersebut tidak menghasilkan apa-apa.
Pada tahap kedua, muncul hipotesis: WebRTC adalah solusi peer-to-peer, dan kami menggunakan server di tengahnya. Mungkin masalahnya terletak di sini? Kami mulai menggali dan menemukan peningkatan paling signifikan sejauh ini.
Pada saat itu, server dari kumpulan dipilih menggunakan algoritme yang agak bodoh: masing-masing memiliki "bobot" sendiri, bergantung pada saluran dan daya, dan kami mencoba mengirim pengguna ke server dengan "bobot" terbesar, tanpa memperhatikan di mana pengguna berada secara geografis. Hasilnya, seorang guru dari St. Petersburg dapat berkomunikasi dengan siswa dari Siberia melalui Moskow, dan bukan melalui server Janus kami di St. Petersburg.
Algoritmenya telah diubah: sekarang, saat pengguna membuka platform kami, kami mengumpulkan ping darinya ke semua server menggunakan Ajax. Saat membuat koneksi, kita memilih pasangan ping (server-guru dan server-siswa) dengan jumlah terkecil. Lebih sedikit ping berarti lebih sedikit jarak jaringan ke server; jarak yang lebih pendek berarti kemungkinan kehilangan paket yang lebih rendah; Kehilangan paket adalah faktor negatif terbesar dalam komunikasi video. Jumlah negatifnya turun setengahnya dalam waktu tiga bulan (agar adil, eksperimen lain dilakukan pada saat ini, namun eksperimen ini hampir pasti memiliki dampak paling besar).
Kami baru-baru ini menemukan hal lain yang tidak jelas, namun tampaknya penting: daripada satu server Janus yang kuat pada saluran yang tebal, lebih baik memiliki dua server yang lebih sederhana dengan bandwidth yang lebih tipis. Hal ini menjadi jelas setelah kami membeli mesin yang kuat dengan harapan dapat menjejalkan sebanyak mungkin ruangan (sesi komunikasi) ke dalamnya pada saat yang bersamaan. Server memiliki batasan bandwidth, yang dapat kami terjemahkan secara akurat ke dalam jumlah ruangan - kami mengetahui berapa banyak yang dapat dibuka, misalnya, pada 300 Mbit/s. Segera setelah ada terlalu banyak ruangan yang terbuka di server, kami berhenti memilihnya untuk aktivitas baru hingga bebannya berkurang. Idenya adalah, setelah membeli mesin yang kuat, kami akan memuat saluran tersebut secara maksimal, sehingga pada akhirnya akan dibatasi oleh prosesor dan memori, dan bukan oleh bandwidth. Namun ternyata setelah sejumlah ruang terbuka (420), meskipun beban pada prosesor, memori, dan disk masih sangat jauh dari batas, hal negatif mulai berdatangan ke dukungan teknis. Rupanya ada sesuatu yang menjadi lebih buruk di dalam Janus, mungkin ada beberapa batasan di sana juga. Kami mulai bereksperimen, menurunkan batas bandwidth dari 300 menjadi 200 Mbit/s, dan masalahnya hilang. Sekarang kami membeli tiga server baru sekaligus dengan batas dan karakteristik rendah, menurut kami hal ini akan menghasilkan peningkatan kualitas komunikasi yang stabil. Tentu saja, kami tidak mencoba mencari tahu apa yang terjadi di sana; tongkat kami adalah segalanya. Dalam pembelaan kami, katakanlah bahwa pada saat itu masalah yang mendesak perlu diselesaikan secepat mungkin, dan tidak dilakukan dengan indah; selain itu, Janus bagi kami adalah kotak hitam yang ditulis dalam bahasa C, sangat mahal untuk mengotak-atiknya.
Nah, dalam prosesnya kami:
- memperbarui semua dependensi yang dapat diperbarui, baik di server maupun di klien (ini juga eksperimen, kami memantau hasilnya);
- memperbaiki semua bug yang teridentifikasi terkait dengan kasus tertentu, misalnya, ketika koneksi terputus dan tidak dipulihkan secara otomatis;
- Kami mengadakan banyak pertemuan dengan perusahaan yang bergerak di bidang komunikasi video dan mengetahui masalah kami: streaming game, pengorganisasian webinar; kami mencoba segala sesuatu yang tampaknya berguna bagi kami;
- Melakukan tinjauan teknis terhadap perangkat keras dan kualitas komunikasi para guru, yang paling banyak menerima keluhan.
Eksperimen dan perubahan selanjutnya memungkinkan penurunan ketidakpuasan komunikasi antar guru dari 7,1% pada Januari 2018 menjadi 2,5% pada Januari 2019.
Apa Selanjutnya
Menstabilkan platform Vimbox kami adalah salah satu proyek utama perusahaan untuk tahun 2019. Kami mempunyai harapan besar untuk dapat menjaga momentum dan tidak lagi melihat komunikasi video sebagai keluhan utama. Kami memahami bahwa sebagian besar keluhan ini terkait dengan lambatnya komputer dan Internet pengguna, namun kami harus menentukan bagian ini dan menyelesaikan sisanya. Selebihnya adalah masalah teknis, sepertinya kita harus bisa mengatasinya.
Kesulitan utamanya adalah kita tidak mengetahui sejauh mana peningkatan kualitas sebenarnya dapat dilakukan. Mencari tahu plafon ini adalah tugas utama. Oleh karena itu, dua percobaan direncanakan:
- bandingkan video melalui Janus dengan p2p biasa dalam kondisi pertempuran. Eksperimen ini telah dilakukan, tidak ditemukan perbedaan signifikan secara statistik antara solusi kami dan p2p;
- Mari kita sediakan layanan (mahal) dari perusahaan yang menghasilkan uang secara eksklusif dari solusi komunikasi video, dan bandingkan jumlah negatifnya dengan yang sudah ada.
Kedua eksperimen ini akan memungkinkan kita mengidentifikasi tujuan yang dapat dicapai dan fokus pada tujuan tersebut.
Selain itu, ada beberapa tugas yang dapat diselesaikan secara rutin:
- Kami membuat metrik teknis kualitas komunikasi, bukan ulasan subjektif;
- Kami membuat log sesi yang lebih rinci untuk menganalisis kegagalan yang terjadi dengan lebih akurat, memahami kapan dan di mana tepatnya kegagalan tersebut terjadi, dan peristiwa apa yang tampaknya tidak terkait yang terjadi pada saat itu;
- Kami mempersiapkan tes kualitas koneksi otomatis sebelum pelajaran, dan juga memberikan kesempatan kepada klien untuk menguji koneksi secara manual untuk mengurangi jumlah negatif yang disebabkan oleh perangkat keras dan salurannya;
- kami akan mengembangkan dan melakukan lebih banyak uji beban komunikasi video dalam kondisi buruk, dengan kehilangan paket yang bervariasi, dll.;
- kami mengubah perilaku server jika terjadi masalah untuk meningkatkan toleransi kesalahan;
- Kami akan memperingatkan pengguna jika ada yang salah dengan koneksinya, seperti yang dilakukan Skype, sehingga dia memahami bahwa masalahnya ada di pihaknya.
Sejak April, arahan komunikasi video telah menjadi proyek terpisah yang lengkap di dalam Skyeng, menangani produknya sendiri, dan bukan hanya bagian dari Vimbox. Ini berarti kami mulai mencari orang . Ya, seperti biasa .
Dan, tentu saja, kami terus berkomunikasi secara aktif dengan orang-orang dan perusahaan yang bergerak di bidang komunikasi video. Jika Anda ingin bertukar pengalaman dengan kami, kami akan senang! Beri komentar, hubungi kami - kami akan menjawab semua orang.
Sumber: www.habr.com