Pada 2016, kami berbicara tentang bagaimana MegaFon.TV mengatasi semua orang yang ingin menonton musim baru Game of Thrones. Pengembangan layanan tidak berhenti di situ, dan pada pertengahan 2017 kami harus berurusan dengan beban beberapa kali lebih banyak. Dalam posting ini kami akan menceritakan bagaimana pertumbuhan yang begitu cepat menginspirasi kami untuk secara radikal mengubah pendekatan untuk mengorganisir CDN dan bagaimana pendekatan baru ini diuji oleh Piala Dunia.
Secara singkat tentang MegaFon.TV
MegaFon.TV adalah layanan OTT untuk melihat berbagai konten video - film, acara TV, saluran TV, dan program yang direkam. Melalui MegaFon.TV, akses ke konten dapat diperoleh di hampir semua perangkat: di ponsel dan tablet dengan iOS dan Android, di TV pintar LG, Samsung, Philips, Panasonic dari tahun rilis yang berbeda, dengan kebun binatang OS lengkap (Apple TV, TV Android), di browser desktop di Windows, MacOS, Linux, di browser seluler di iOS dan Android, dan bahkan pada perangkat eksotis seperti STB dan proyektor Android anak-anak. Praktis tidak ada batasan pada perangkat - hanya ketersediaan Internet dengan bandwidth 700 Kbps yang penting. Tentang bagaimana kami mengatur dukungan untuk banyak perangkat, akan ada artikel terpisah di masa depan.
Sebagian besar pengguna layanan ini adalah pelanggan MegaFon, yang dijelaskan oleh penawaran menguntungkan (dan paling sering bahkan gratis) yang termasuk dalam paket tarif pelanggan. Meskipun kami juga mencatat peningkatan yang signifikan dalam pengguna operator lain. Sesuai dengan distribusi ini, 80% dari lalu lintas MegaFon.TV dikonsumsi dalam jaringan MegaFon.
Secara arsitektur, sejak peluncuran layanan, konten telah didistribusikan melalui CDN. Kami memiliki
pos terpisah yang didedikasikan untuk pekerjaan CDN ini. Di dalamnya, kami berbicara tentang bagaimana hal itu memungkinkan kami untuk menangani lalu lintas puncak yang pergi ke layanan pada akhir 2016, selama rilis musim baru Game of Thrones. Dalam posting ini kita akan berbicara tentang pengembangan lebih lanjut dari MegaFon.TV dan tentang petualangan baru yang telah jatuh pada layanan bersama dengan Piala Dunia 2018
Pertumbuhan layanan. Dan masalah
Dibandingkan dengan peristiwa dari pos terakhir, pada akhir 2017 jumlah pengguna Megafon.TV telah meningkat beberapa kali, film dan serial juga menjadi urutan besarnya lebih besar. Fungsionalitas baru diluncurkan, paket baru muncul, tersedia "dengan berlangganan". Puncak lalu lintas sejak "Game of Thrones" sekarang kita lihat setiap hari, proporsi film dan acara TV dalam aliran total terus meningkat.
Seiring dengan ini, masalah dimulai dengan redistribusi traffic. Pemantauan kami, yang dikonfigurasikan untuk mengunduh potongan untuk berbagai jenis lalu lintas dalam berbagai format, semakin mulai menghasilkan kesalahan saat mengunduh potongan video saat batas waktu habis. Dalam layanan MegaFon.TV, panjang chunk adalah 8 detik. Jika potongan tidak memiliki waktu untuk memuat dalam 8 detik, kesalahan dapat terjadi.
Puncak kesalahan diharapkan terjadi pada jam-jam paling sibuk. Bagaimana hal ini memengaruhi pengguna? Paling tidak, mereka dapat mengamati penurunan kualitas video. Itu tidak selalu terlihat dengan mata telanjang, karena cukup banyak profil multi-bitrate. Dalam kasus terburuk, videonya macet.
Pencarian masalah dimulai. Hampir segera, menjadi jelas bahwa kesalahan kickback terjadi pada server EDGE CDN. Di sini kita perlu melakukan penyimpangan kecil dan memberi tahu bagaimana server bekerja dengan lalu lintas langsung dan VOD. Skemanya sedikit berbeda. Seorang pengguna yang datang ke server EDGE untuk konten (daftar putar atau potongan), jika ada konten dalam cache, mendapatkannya dari sana. Kalau tidak, server EDGE berlaku untuk konten di Origin, memuat saluran utama. Bersama dengan playlist atau chunk, header
Cache-Control: max-age diberikan, yang memberi tahu server EDGE berapa banyak untuk menembolok unit konten tertentu. Perbedaan antara LIVE dan VOD terletak pada waktu yang dibutuhkan untuk cache cache. Untuk potongan langsung, waktu caching pendek diatur, biasanya dari 30 detik hingga beberapa menit - ini disebabkan oleh waktu relevansi konten langsung yang singkat. Cache ini disimpan dalam RAM, karena Anda harus terus-menerus memberikan potongan dan menulis ulang cache. Untuk potongan VOD, lebih banyak waktu yang ditetapkan, dari beberapa jam hingga berminggu-minggu dan bahkan berbulan-bulan - tergantung pada ukuran pustaka konten dan distribusi pandangannya di antara pengguna. Adapun playlist, mereka biasanya di-cache dalam waktu tidak lebih dari dua detik, atau mereka tidak di-cache sama sekali. Perlu diklarifikasi bahwa kita hanya berbicara tentang apa yang disebut PULL-mode CDN, di mana server kami bekerja. Menggunakan mode PUSH dalam kasus kami tidak sepenuhnya dibenarkan.
Tetapi kembali untuk menemukan masalah. Seperti yang telah kita perhatikan, semua server secara bersamaan bekerja untuk mengembalikan kedua jenis konten. Pada saat yang sama, server sendiri memiliki konfigurasi yang berbeda. Akibatnya, beberapa mesin kelebihan beban menggunakan IOPS. Bongkahan tidak punya waktu untuk menulis / membaca karena kinerja kecil, kuantitas, volume disk, pustaka konten yang besar. Di sisi lain, mesin yang lebih kuat yang menerima lebih banyak lalu lintas mulai gagal pada penggunaan CPU. Sumber daya CPU dihabiskan untuk melayani lalu lintas SSL dan potongan yang dikirimkan melalui https, sementara IOPS pada disk hampir tidak mencapai 35%.
Yang dibutuhkan adalah skema yang akan, dengan biaya minimal, memungkinkan untuk menggunakan kapasitas yang tersedia secara optimal. Selain itu, enam bulan kemudian Piala Dunia akan dimulai, dan menurut perhitungan awal, puncak lalu lintas langsung seharusnya meningkat enam kali lipat ...
Pendekatan baru terhadap CDN
Setelah menganalisis masalah, kami memutuskan untuk memisahkan VOD dan lalu lintas langsung menurut PAD yang berbeda yang terdiri dari server dengan konfigurasi yang berbeda. Dan juga membuat fungsi distribusi lalu lintas dan penyeimbangannya di berbagai kelompok server. Total ada tiga kelompok:
- Server dengan sejumlah besar disk berkinerja tinggi yang paling cocok untuk caching konten VOD. Faktanya, disk SSD RI dengan kapasitas maksimum akan paling cocok, tetapi tidak ada, dan akan membutuhkan terlalu banyak anggaran untuk membeli jumlah yang tepat. Pada akhirnya, diputuskan untuk menggunakan yang terbaik yang tersedia. Setiap server berisi delapan disk SAS 1TB 10k di RAID5. Dari server ini VOD_PAD dikompilasi.
- Server dengan sejumlah besar RAM untuk caching semua format yang mungkin untuk pengiriman potongan langsung, dengan prosesor yang mampu menangani lalu lintas ssl, dan antarmuka jaringan "tebal". Kami menggunakan konfigurasi berikut: 2 prosesor 8 core / 192GB RAM / 4 antarmuka 10GB. Dari server ini, EDGE_PAD dikompilasi.
- Grup server yang tersisa tidak dapat menangani lalu lintas VOD, tetapi cocok untuk volume kecil konten langsung. Mereka dapat digunakan sebagai cadangan. Dari server RESERVE_PAD dikompilasi.
Distribusi adalah sebagai berikut:
Modul logika khusus bertanggung jawab untuk memilih PAD dari mana pengguna seharusnya menerima konten. Inilah tugasnya:
- Analisis URL, terapkan skema di atas untuk setiap permintaan streaming dan keluarkan PAD yang diperlukan
- Untuk menghapus beban dari antarmuka EDGE_PAD setiap 5 menit ( dan ini adalah kesalahan kami ), dan ketika batas tercapai, alihkan lalu lintas berlebih ke RESERVE_PAD. Untuk meringankan beban, skrip perl kecil ditulis yang mengembalikan data berikut:
- cap waktu - tanggal dan waktu memperbarui data pemuatan (dalam format RFC 3339);
- total_bandwidth - beban antarmuka saat ini (total), Kbps;
- rx_bandwidth - beban antarmuka saat ini (lalu lintas masuk), Kbps;
- tx_badwidth - beban antarmuka saat ini (lalu lintas keluar), Kbps.
- Lalu lintas langsung dalam mode manual ke server PAD atau Asal jika terjadi situasi yang tidak terduga, atau jika perlu, bekerja di salah satu PAD. Konfigurasi berada di server dalam format yaml dan diizinkan untuk mengambil semua lalu lintas ke PAD yang diinginkan, atau lalu lintas sesuai dengan salah satu parameter:
- Jenis Konten
- enkripsi lalu lintas
- Lalu lintas berbayar
- tipe perangkat
- Jenis daftar putar
- Wilayah
Server asal adalah SSD yang kekurangan staf. Sayangnya, ketika mengalihkan lalu lintas ke Asal, HIT_RATE pada potongan VOD menyisakan banyak yang harus diinginkan (sekitar 30%), tetapi mereka melakukan tugas mereka, jadi kami tidak mengamati masalah dengan pembuat paket di CNN.
Karena ada beberapa server untuk konfigurasi EDGE_PAD, diputuskan untuk mengalokasikannya di wilayah dengan pangsa lalu lintas terbesar - Moskow dan wilayah Volga. Dengan bantuan GeoDNS, lalu lintas dikirim ke wilayah Volga dari wilayah Volga dan distrik federal Ural. Hub Moskow melayani sisanya. Kami tidak benar-benar menyukai gagasan untuk mengirimkan lalu lintas ke Siberia dan Timur Jauh dari Moskow, tetapi secara total wilayah-wilayah ini menyumbang sekitar 1/20 dari semua lalu lintas, dan saluran MegaFon ternyata cukup lebar untuk volume seperti itu.
Setelah pengembangan rencana, pekerjaan berikut dilakukan:
- Dalam dua minggu, dikembangkan fungsi switching CDN
- Butuh waktu satu bulan untuk menginstal dan mengonfigurasi server EDGE_PAD, serta memperluas saluran untuk mereka
- Butuh dua minggu untuk membagi grup server saat ini menjadi dua bagian, ditambah dua minggu lagi untuk menerapkan pengaturan ke semua server di jaringan dan peralatan server
- Dan, akhirnya, minggu dihabiskan untuk pengujian (sayangnya, tidak di bawah beban, yang kemudian terpengaruh)
Ternyata untuk memparalelkan beberapa pekerjaan, dan pada akhirnya semua itu memakan waktu enam minggu.
Hasil Pertama dan Rencana Masa Depan
Setelah penyetelan, kinerja sistem secara keseluruhan adalah 250 Gb / s. Solusi dengan transfer lalu lintas VOD ke server terpisah segera menunjukkan efektivitasnya setelah diluncurkan ke produksi. Sejak awal Piala Dunia, tidak ada masalah dengan lalu lintas VOD. Beberapa kali, karena berbagai alasan, saya harus mengalihkan lalu lintas VOD ke Asal, tetapi pada prinsipnya, mereka juga mengatasinya. Mungkin skema ini tidak terlalu efektif karena penggunaan cache yang sangat kecil, karena kami memaksa SSD untuk terus-menerus menimpa konten. Tetapi rangkaian itu bekerja.
Adapun lalu lintas langsung, volume yang sesuai untuk menguji keputusan kami muncul dengan dimulainya Piala Dunia. Masalah dimulai ketika kedua kalinya kami menghadapi peralihan lalu lintas ketika kami mencapai batas selama pertandingan Rusia-Mesir. Ketika peralihan lalu lintas berfungsi, semuanya mengalir ke PAD cadangan. Dalam lima menit ini, jumlah permintaan (kurva pertumbuhan) begitu besar sehingga cadangan CDN tersumbat sepenuhnya dan mulai menuangkan kesalahan. Pada saat yang sama, PAD utama dirilis selama waktu ini dan mulai sedikit diam:
3 kesimpulan diambil dari ini:
- Lima menit masih terlalu banyak. Diputuskan untuk mengurangi periode bongkar menjadi 30 detik. Akibatnya, lalu lintas pada PAD siaga berhenti tumbuh secara spasmodik:
- Minimal diperlukan untuk mentransfer pengguna antara PAD setiap kali sakelar dipicu. Ini harus memberikan kelancaran tambahan switching. Kami memutuskan untuk memberikan cookie kepada setiap pengguna (atau lebih tepatnya perangkat), yang menurutnya modul yang bertanggung jawab untuk distribusi memahami apakah pengguna harus dibiarkan menggunakan PAD saat ini atau jika pengalihan harus dilakukan. Di sini teknologi mungkin atas kebijaksanaan orang yang mengimplementasikannya. Akibatnya, kami tidak menjatuhkan lalu lintas di PAD utama.
- Ambang untuk beralih ditetapkan terlalu rendah, sebagai akibatnya, lalu lintas pada cadangan PAD tumbuh seperti longsoran salju. Dalam kasus kami, ini adalah reasuransi - kami tidak sepenuhnya yakin bahwa kami membuat penyetelan server yang benar (ide yang diambil dari Habr). Ambang batas telah ditingkatkan ke kinerja fisik antarmuka jaringan.
Perbaikan membutuhkan waktu tiga hari, dan sudah di pertandingan Rusia-Kroasia, kami memeriksa apakah optimasi kami berhasil. Secara umum, hasilnya memuaskan kami. Pada puncaknya, sistem memproses 215 Gbit / s lalu lintas campuran. Ini bukan batas teoritis pada kinerja sistem - kami masih memiliki margin yang substansial. Jika perlu, sekarang kita dapat menghubungkan CDN eksternal apa pun, jika perlu, dan "membuang" lalu lintas berlebih di sana. Model seperti itu bagus ketika Anda tidak ingin membayar uang padat setiap bulan untuk menggunakan CDN orang lain.
Rencana kami meliputi pengembangan lebih lanjut dari CDN. Untuk mulai dengan, saya ingin memperluas skema EDGE_PAD ke semua distrik federal - ini akan menyebabkan lebih sedikit penggunaan saluran. Tes sirkuit redundansi VOD_PAD juga sedang dilakukan, dan beberapa hasil sekarang terlihat cukup mengesankan.
Secara umum, semua yang dilakukan selama setahun terakhir membuat saya berpikir bahwa CDN dari layanan yang mendistribusikan konten video harus dimiliki. Dan bahkan bukan karena itu memungkinkan Anda untuk menghemat banyak uang, tetapi lebih karena CDN menjadi bagian dari layanan itu sendiri, secara langsung mempengaruhi kualitas dan fungsionalitas. Dalam keadaan seperti itu, memberikannya ke tangan yang salah setidaknya tidak masuk akal.