Panggilan video adalah cara utama guru dan siswa berkomunikasi di platform Vimbox. Kami telah meninggalkan Skype sejak lama, mencoba beberapa solusi pihak ketiga, dan akhirnya memilih sekelompok WebRTC - Janus-gateway. Untuk sementara, semuanya baik-baik saja dengan kami, tetapi masih ada beberapa poin negatif yang terus merayap. Akibatnya, arah video terpisah dibuat.
Saya meminta Kirill Rogovoy, kepala arah baru, untuk berbicara tentang evolusi komunikasi video di Skyeng, masalah, solusi, dan kruk yang akhirnya kami terapkan. Kami berharap artikel ini bermanfaat bagi perusahaan yang juga membuat video sendiri melalui aplikasi web.
Sedikit sejarah
Pada musim panas 2017, Sergey Safonov, kepala pengembangan Skyeng, berbicara di Backend Conf tentang bagaimana kami "meninggalkan Skype dan mengimplementasikan WebRTC". Mereka yang ingin dapat melihat rekaman kinerja dengan referensi (~ 45 menit), tetapi di sini saya akan secara singkat menguraikan esensinya.
Bagi Skyeng, komunikasi video selalu menjadi metode komunikasi guru-siswa yang diprioritaskan. Pada awalnya, Skype digunakan, tetapi pasti tidak cocok untuk sejumlah alasan, terutama karena kurangnya log dan ketidakmampuan untuk mengintegrasikan langsung ke dalam aplikasi web. Karena itu, kami melakukan semua jenis percobaan.
Sebenarnya, persyaratan untuk komunikasi video kira-kira sebagai berikut:
- stabilitas;
- harga rendah per pelajaran;
- merekam pelajaran;
- melacak siapa yang mengatakan berapa banyak (penting bagi kita agar siswa berbicara lebih banyak di kelas daripada guru);
- penskalaan linear;
- Kemampuan untuk menggunakan UDP dan TCP.
Yang pertama pada tahun 2013 mencoba menerapkan Tokbox. Semuanya baik-baik saja, tetapi ternyata sangat mahal - 113 rubel per pelajaran - dan memakan untung.
Kemudian pada 2015, Voximplant diintegrasikan. Inilah fungsi pelacakan yang kami butuhkan, yang mengatakan berapa banyak, dan pada saat yang sama solusinya jauh lebih murah: asalkan hanya suara yang direkam, 20 rubel per pelajaran keluar. Namun, itu hanya bekerja melalui UDP, beralih ke TCP bukan keahlian. Namun, pada akhirnya, sekitar 40% siswa menggunakannya.
Setahun kemudian, klien korporat mulai muncul dengan persyaratan khusus mereka. Misalnya, semuanya harus bekerja melalui browser, hanya http dan https yang terbuka di perusahaan; yaitu, tidak ada Skype dan UDP. Pelanggan korporat = uang, jadi mereka kembali ke Tokbox, tetapi masalah harga belum hilang.
Solusi - WebRTC dan Janus
Kami memutuskan untuk menggunakan platform browser untuk WebRTC komunikasi video peer-to-peer . Dia bertanggung jawab untuk membangun koneksi, stream encoding dan decoding, sinkronisasi trek dan kontrol kualitas dengan pemrosesan gangguan jaringan. Untuk bagian kami, kami harus memastikan bahwa stream dari kamera dan mikrofon dibaca, video dibuat, koneksi dibuat, koneksi WebRTC dibuat dan stream ditransmisikan ke sana, serta transmisi pesan sinyal antara klien untuk membuat koneksi (WebRTC sendiri hanya menggambarkan format data, tetapi bukan mekanisme mereka. transmisi). Jika klien berada di belakang NAT, WebRTC menghubungkan server STUN, jika ini tidak membantu, server HIDUPKAN.
Koneksi p2p yang biasa tidak cukup bagi kami, karena kami ingin merekam pelajaran untuk analisis lebih lanjut jika ada keluhan. Oleh karena itu, kami mengirim stream WebRTC melalui repeater Gateway Janech Meetecho . Akibatnya, klien tidak tahu alamat masing-masing, hanya melihat alamat server Janus; itu juga melakukan fungsi server sinyal. Janus memiliki banyak fitur yang kami butuhkan: secara otomatis beralih ke TCP jika UDP diblokir pada klien; mampu 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 memiliki dua server Janus, ditambah server tambahan untuk memproses file audio dan video mentah yang direkam, agar tidak menempati prosesor utama. Saat menghubungkan, server Janus dipilih secara genap (nomor koneksi). Pada saat itu, ini sudah cukup, menurut perasaan kami, itu memberi sekitar empat kali margin keselamatan, persentase implementasi sekitar 80. Pada saat yang sama, harga turun menjadi ~ 2 rubel per pelajaran, ditambah pengembangan dan dukungan.
Kembali ke topik panggilan video
Kami terus memantau umpan balik dari siswa dan guru untuk mengidentifikasi dan menghentikan masalah tepat waktu. Pada musim panas 2018, pertama-tama di antara keluhan, kualitas komunikasi dengan penuh percaya diri tertanam. Di satu sisi, ini berarti kami berhasil mengatasi kekurangan lain. Di sisi lain, ada kebutuhan mendesak untuk melakukan sesuatu: jika pelajaran rusak, kita berisiko kehilangan biaya, kadang-kadang seiring dengan biaya pembelian paket berikutnya, dan jika pelajaran pengantar hilang, kita kehilangan klien potensial sama sekali.
Saat itu, komunikasi video masih dalam mode MVP. Sederhananya, mereka meluncurkannya, berhasil, diskalakan sekali, menemukan cara melakukannya - yah, itu bagus. Jika berhasil, jangan memperbaikinya. Tidak ada yang dengan sengaja menangani masalah kualitas komunikasi. Pada bulan Agustus, menjadi jelas bahwa ini tidak dapat berlanjut lebih jauh, dan kami meluncurkan area terpisah untuk mencari tahu apa yang terjadi dengan WebRTC dan Janus.
Di pintu masuk, arah ini diterima: solusi MVP, tidak ada metrik, tidak ada tujuan, tidak ada proses peningkatan, sementara 7% guru mengeluh tentang kualitas komunikasi (tidak ada data tentang siswa juga).
Arah baru diambil untuk bekerja
Perintahnya terlihat seperti ini:
- Kepala arah, dia adalah pengembang utama.
- QA membantu menguji perubahan, mencari cara baru untuk menciptakan kondisi komunikasi yang tidak stabil, melaporkan masalah dari garis depan.
- Analis terus mencari korelasi yang berbeda dalam data teknis, meningkatkan analisis umpan balik pengguna, memeriksa hasil eksperimen.
- Manajer produk membantu dengan arahan umum dan alokasi sumber daya untuk eksperimen.
- Dengan pemrograman itu sendiri dan tugas-tugas terkait, pengembang kedua sering membantu.
Untuk mulai dengan, kami membuat metrik yang relatif andal yang melacak perubahan dalam penilaian kualitas komunikasi (rata-rata berdasarkan hari, minggu, bulan). Pada saat itu, ini adalah nilai dari guru, dan nilai lebih lanjut dari siswa ditambahkan ke mereka. Kemudian mereka mulai membangun hipotesis tentang apa yang tidak berfungsi, untuk memperbaiki dan melihat perubahan dinamika. Kami menggunakan buah-buah yang mudah digantung: misalnya, kami mengganti vp8 codec dengan vp9, kinerjanya membaik. Kami mencoba bermain dengan pengaturan Janus, untuk melakukan percobaan lain - dalam kebanyakan kasus, tidak berhasil.
Pada tahap kedua, sebuah hipotesis muncul: WebRTC adalah solusi peer-to-peer, dan kami menggunakan server di tengah. Mungkin masalahnya ada di sini? Mereka mulai menggali dan menemukan perbaikan paling signifikan sejauh ini di sini.
Pada saat itu, server dari kumpulan dipilih berdasarkan algoritma yang agak bodoh: masing-masing memiliki "bobot" sendiri, bergantung pada saluran dan daya, dan kami mencoba mengirim pengguna ke yang mana "bobot" lebih besar, tidak memperhatikan di mana pengguna berada secara geografis . Akibatnya, seorang guru dari St. Petersburg dapat berkomunikasi dengan seorang siswa dari Siberia melalui Moskow, dan tidak melalui server Janus kami di St. Petersburg.
Algoritma itu diulang: sekarang, ketika pengguna membuka platform kami, kami menggunakan Ajax untuk mengumpulkan ping dari itu ke semua server. Saat membuat koneksi, kami memilih sepasang ping (server guru dan server siswa) dengan jumlah terkecil. Kurang ping - kurang jarak jaringan ke server; lebih sedikit jarak - lebih sedikit kemungkinan kehilangan paket; packet loss adalah faktor negatif terbesar dalam panggilan video. Pangsa negatif turun dua kali dalam tiga bulan (dalam keadilan, percobaan lain juga dilakukan pada saat ini, tetapi yang ini hampir pasti paling terpengaruh).
Baru-baru ini, kami menemukan hal lain yang tidak jelas, tetapi, tampaknya, penting: alih-alih satu server Janus yang kuat di saluran yang tebal, dua lebih sederhana dengan bandwidth yang lebih baik. Ini ternyata setelah kami membeli mesin yang kuat dengan harapan mengisi sebanyak mungkin ruang (sesi komunikasi) di sana pada saat yang bersamaan. Server memiliki batas bandwidth yang dapat kami terjemahkan secara akurat ke dalam jumlah kamar - kami tahu seberapa banyak yang dapat Anda buka, misalnya, pada 300 Mbps. Segera setelah terlalu banyak ruang terbuka di server, kami berhenti memilihnya untuk aktivitas baru hingga beban berkurang. Idenya adalah bahwa, setelah membeli mesin yang kuat, kami akan memuat saluran ke maksimum sehingga pada akhirnya bersandar pada prosesor dan memori, dan bukan pada bandwidth. Tetapi ternyata setelah sejumlah ruang terbuka (420), terlepas dari kenyataan bahwa beban pada prosesor, memori dan disk masih sangat jauh dari batas, negativitas mulai terbang ke dukungan teknis. Rupanya, ada sesuatu yang semakin buruk di dalam Janus, mungkin ada beberapa batasan juga. Mereka mulai bereksperimen, mengurangi batas bandwidth dari 300 menjadi 200 Mbps, masalahnya hilang. Sekarang kami membeli tiga server baru sekaligus dengan batasan dan karakteristik rendah, kami pikir ini akan mengarah pada peningkatan kualitas komunikasi yang stabil. Tentu saja, kami tidak mulai mencari tahu apa masalahnya, kruk adalah milik kami. Dalam pembelaan kami, kami mengatakan bahwa pada saat itu perlu untuk menyelesaikan masalah yang mendesak secepat mungkin, dan tidak melakukannya dengan indah; Selain itu, Janus adalah kotak hitam untuk kita, ditulis dalam C, sangat mahal untuk digali.
Nah, dalam prosesnya kita:
- memperbarui semua dependensi yang dapat diperbarui, baik di server dan di klien (ini juga percobaan, mengikuti hasilnya);
- memperbaiki semua bug yang diidentifikasi terkait dengan kasus tertentu, misalnya, ketika koneksi terputus dan tidak dipulihkan secara otomatis;
- mengadakan banyak pertemuan dengan perusahaan yang bekerja di bidang komunikasi video dan memahami masalah kami: stream game, host webinar; menguji segala sesuatu yang tampaknya bermanfaat bagi kami;
- melakukan tinjauan teknis besi dan kualitas komunikasi dengan guru, dari mana sebagian besar keluhan berasal.
Eksperimen dan perubahan selanjutnya memungkinkan untuk mengurangi ketidakpuasan dengan komunikasi antara guru dari 7,1% pada Januari 2018 menjadi 2,5% pada Januari 2019.
Apa selanjutnya
Stabilisasi platform Vimbox kami adalah salah satu proyek utama perusahaan untuk 2019. Kami memiliki harapan besar bahwa kami akan dapat mempertahankan momentum dan tidak lagi melihat komunikasi video dalam keluhan utama. Kami memahami bahwa sebagian besar keluhan ini terkait dengan keterlambatan komputer dan Internet pengguna, tetapi kami harus menentukan bagian ini dan menyelesaikan yang lainnya. Segala sesuatu yang lain adalah masalah teknis, tampaknya kita harus bisa mengatasinya.
Kesulitan utama adalah bahwa kita tidak tahu pada level apa umumnya realistis untuk meningkatkan kualitas. Klarifikasi pagu ini adalah tugas utama. Oleh karena itu, dua percobaan direncanakan:
- Bandingkan video via Janus dengan p2p reguler dalam pertempuran. Percobaan ini telah dilakukan, tidak ada perbedaan yang signifikan secara statistik antara solusi kami dan p2p yang ditemukan;
- kami akan menyediakan layanan (mahal) dari perusahaan yang menghasilkan secara eksklusif pada solusi komunikasi video, dan membandingkan jumlah negatif dari mereka dengan yang ada.
Dua percobaan ini akan memungkinkan kita untuk menentukan tujuan yang dapat dicapai dan berkonsentrasi padanya.
Selain itu, ada sejumlah tugas yang diselesaikan dalam urutan kerja:
- kami membuat metrik teknis kualitas komunikasi alih-alih ulasan subjektif;
- kami membuat log sesi yang lebih rinci untuk lebih akurat menganalisis kegagalan yang terjadi, untuk memahami kapan dan di mana tepatnya mereka terjadi, peristiwa apa yang tampaknya tidak terkait terjadi pada saat itu;
- kami sedang mempersiapkan tes otomatis kualitas komunikasi sebelum pelajaran, dan kami juga akan memungkinkan klien untuk menguji koneksi secara manual untuk mengurangi jumlah negatif yang disebabkan oleh besi dan salurannya;
- Kami akan mengembangkan dan melakukan lebih banyak stress test komunikasi video dalam kondisi yang buruk, dengan hilangnya paket variabel, dll.;
- Kami mengubah perilaku server jika terjadi masalah untuk meningkatkan toleransi kesalahan;
- kami akan memperingatkan pengguna jika ada sesuatu yang salah dengan koneksi, seperti halnya Skype yang sama, sehingga ia mengerti bahwa masalahnya ada di pihaknya.
Sejak April, arah komunikasi video telah menjadi proyek terpisah penuh dalam Skyeng, yang bergerak dalam produknya sendiri, bukan hanya bagian dari Vimbox. Dan ini berarti kita mulai mencari orang untuk bekerja dengan video dalam mode penuh waktu . Seperti biasa, kami mencari banyak orang baik .
Yah, tentu saja, kami terus berkomunikasi secara aktif dengan orang-orang dan perusahaan yang bekerja dengan komunikasi video. Jika Anda ingin bertukar pengalaman dengan kami, kami akan senang! Komentari, hubungi - kami akan menjawab semua orang.