- Saya akan mulai dari mana bioskop online berasal.
Dalam perjalanan perkembangan internet, muncul layanan media OTT yang mulai digunakan untuk mentransfer konten media melalui internet, berbeda dengan layanan media tradisional yang menggunakan kabel, satelit dan saluran komunikasi lainnya.
Layanan media semacam itu didasarkan pada OVP - platform video online, yang mencakup sistem manajemen konten, pemutar web, dan CDN. Kelas terpisah dari sistem tersebut adalah OTT-TV, bioskop online, yang, selain OVP, menerapkan sistem kontrol dan manajemen untuk akses ke konten, sistem perlindungan hak konten digital, pengelolaan langganan, pembelian, dan berbagai metrik produk dan teknis. Dan itu memberlakukan pada sistem ini peningkatan persyaratan untuk waktu kerja dan latensi.
Saya akan berbicara tentang backend, yang bertanggung jawab atas sistem manajemen konten, untuk fungsionalitas pengguna bioskop online dan untuk bagian dari manajemen konten dan sistem kontrol.
Mari kita lihat dari apa bioskop online itu dibuat. Dalam KinoPoisk HD parallelepiped, segala macam hal keren dan mode tampilan diimplementasikan. Ribuan pengguna RPS memilih konten yang tersedia di etalase, berlangganan dan membeli. Simpan kemajuan penjelajahan, pengaturan pengguna. Ribuan RPS menghasilkan berbagai metrik. Ini adalah satu set komponen yang agak besar dan menarik, detailnya tidak akan kita bahas hari ini. Namun perlu disebutkan bahwa, secara umum, ini adalah layanan yang baik dan dapat dipahami skalanya - karena fakta bahwa mereka dipisahkan oleh pengguna.
Hari ini kita akan fokus pada cloud di bawah kotak. Ini adalah platform yang bertanggung jawab untuk menyimpan film, serial, berbagai batasan dari pemegang hak cipta. Didukung oleh upaya beberapa departemen. Bagian dari platform ini adalah transformator aksesibilitas yang menjawab pertanyaan yang dapat saya tonton sekarang di lokasi ini. Tanpa transformator aksesibilitas, tidak ada konten yang benar-benar akan muncul di KinoPoisk HD.
Tantangan bagi transformator adalah menerjemahkan model aksesibilitas yang fleksibel dan berlapis menjadi model yang efisien yang dapat diskalakan dengan baik ke sebanyak mungkin konsumen konten.
Mengapa fleksibel dan skalabel? Terutama karena ini mencakup berbagai entitas yang mendeskripsikan konten, monetisasi, ketersediaan relasional, dan ketersediaan di situs. Semua ini dalam hubungan revolusioner, memiliki hierarki yang kompleks. Dan fleksibilitas ini diperlukan untuk memenuhi persyaratan puluhan pemegang hak cipta dan berbagai opsi harga yang fleksibel.
Yang kami maksud dengan situs, misalnya, bioskop online di web, bioskop online di perangkat, dan layanan OTT mitra lain yang juga memutar konten kami.
Jelas bahwa untuk menghitung ketersediaan model multi-level secara efektif, Anda perlu membangun gabungan yang kompleks, dan kueri semacam itu tidak menskalakan untuk beban apa pun, kueri tersebut cukup sulit untuk ditafsirkan untuk membangun beberapa fungsionalitas dengan cepat dan jelas pada mereka. Untuk mengatasi masalah ini, transformator aksesibilitas muncul, menormalkan kembali model yang disajikan pada slide sebagai kunci komposit, yang mencakup ID konten, negara, situs, langganan, dan beberapa residu non-kunci tak terlihat yang mengisi sebagian besar memori. Hari ini kita akan berbicara tentang kesulitan penskalaan transformator aksesibilitas.
Mari selami lebih dalam komponen ini dan lihat terdiri dari apa. Di sini kita melihat keadaan sistem sebelum dimulainya masalah. Selama ini, trafo aksesibilitas telah bergerak di sepanjang jalur perkembangan bioskop online yang secepat kilat. Penting untuk segera meluncurkan fungsionalitas baru, pertama-tama, untuk memastikan ketersediaan puluhan ribu film dan serial TV.
Jika Anda pergi dari kiri ke kanan, maka ada CMS, database relasional di mana dalam bentuk normal ketiga dan di EAVentitas utama kami disimpan. Berikutnya adalah snapshot loader. Selanjutnya, generator snapshot, yang secara teratur menerima data yang relevan, memfilternya, menambahkannya ke penyimpanan snapshot. Ini sebenarnya adalah dump SQL. Lebih jauh di dalam contoh prosesor permintaan, Snapshot Loader secara teratur menerima data baru dan mengimpornya ke H2. H2 adalah database dalam memori yang ditulis dalam Java yang mengimplementasikan kapabilitas dasar dari DBMS, yaitu ada interpreter kueri, pengoptimal kueri, dan indeks.
Faktanya, ini adalah komponen yang memberikan fleksibilitas untuk membuat fungsionalitas baru untuk bioskop online karena Anda cukup menulis kueri SQL dan menggabungkan entitas yang dinormalisasi dengan cepat dan mudah.
H2 diperbarui pada model salin-saat-tulis. Snapshot Loader mengambil instance database baru dan mengisinya. Dan kemudian, setelah diisi, ia membuang yang lama menggunakan pengumpul sampah.
Bersamaan dengan H2, cache entitas dimunculkan, yang mencakup entitas komposit dan indeks di atasnya. Entitas komposit pada dasarnya adalah kelanjutan dari denormalisasi dari apa yang ada di H2 untuk mengakomodasi permintaan latensi yang lebih menuntut dari klien. Entitas cache diperbarui dengan cara yang sama sesuai dengan model salin-saat-tulis, bersamaan dengan peningkatan instans H2 baru.
Keuntungan utama sistem: Anda dapat dengan mudah dan fleksibel menambahkan fungsionalitas baru menggunakan gabungan. Skema yang relatif sederhana untuk memperbarui data dengan copy-on-write. Kelemahannya, tentu saja, dibutuhkan x2 memori untuk menyimpan dan memperbarui entitas ini. Ini secara tidak langsung memengaruhi permintaan pengguna karena dibuang oleh pengumpul sampah.
Selain itu, saat membuat cache entitas, sumber daya CPU diperlukan untuk pengindeksan. Dan ini juga secara tidak langsung memengaruhi permintaan pengguna, tetapi dengan mengorbankan persaingan untuk sumber daya CPU. Kedua poin ini bersama-sama mengarah pada fakta bahwa dengan pertumbuhan volume data entitas utama kami, prosesor kueri perlu menskalakan secara vertikal, baik dalam hal CPU dan memori.
Tetapi sistem tersebut mengandalkan puluhan ribu film dan serial TV yang tersedia secara online. Oleh karena itu, untuk waktu yang lama, kelemahan ini dapat diterima, mereka memungkinkan untuk memanfaatkan keunggulan utama dalam hal fleksibilitas dan kemudahan memperkenalkan fungsi baru bioskop online.
Jelas bahwa semua ini berhasil sampai titik tertentu. Bayangkan bus kuning ini adalah trafo aksesibilitas kita.
Ia menjadi tuan rumah film dan serial yang direproduksi dengan denormalisasi, yaitu, jumlahnya puluhan ribu. Dan di salah satu pemberhentian, ratusan ribu video musik dan trailer perlu diangkat ke atas dan ditempatkan entah bagaimana. Begitu masuk, mereka juga berkembang biak karena denormalisasi. Mereka yang di dalam perlu menyusut, dan mereka yang di luar perlu masuk, masuk. Bisa dibayangkan bagaimana ini terjadi. Secara teknis, saat ini, kapasitas memori kami pada instans bertambah menjadi puluhan gigabyte. Membangun cache dan membuang instance lama menggunakan pengumpul sampah membutuhkan beberapa inti virtual. Dan karena jumlah data telah bertambah secara dramatis, seluruh prosedur ini menghasilkan fakta bahwa perlu waktu puluhan menit untuk mempublikasikan konten baru.
Secara teknis, kami melihat penggunaan CPU di sini pada cluster prosesor kueri. Di parit - pemrosesan permintaan klien dari urutan beberapa ribu RPS, dan di bukit - beberapa ribu RPS yang sama, ditambah pemuatan foto yang sama dan pembuangannya menggunakan pengumpul sampah. Dua grafik terbawah adalah CPU wait di container. Kami melihat bahwa mereka juga mulai menampakkan diri pada saat mengunduh snapshot dan membuangnya.
Untuk mengakomodasi video musik dan cuplikan ini dan terus menskalakan, kami memperkenalkan instance prosesor permintaan aktif dan pasif. Sebenarnya, ini adalah transfer copy-on-write satu tingkat. Sekarang kita memiliki instance aktif dan pasif di dalam container. Pasif menyiapkan H2 baru dan cache entitas, sedangkan yang aktif hanya memproses permintaan pengguna. Dengan demikian, kami telah mengurangi dampak pengumpulan sampah dan jeda pada pemrosesan permintaan pengguna. Namun pada saat yang sama, karena mereka masih berada di penampung yang sama, memuat snapshot dan membuat cache masih bersaing untuk mendapatkan sumber daya CPU, dan dampaknya pada permintaan pengguna masih ada.
Kami juga telah memperkenalkan partisi berdasarkan situs. Ini memberi kami pengurangan memori di situs-situs yang tidak membutuhkan semua jenis konten baru ini. Misalnya, ini memungkinkan bioskop online untuk tidak mendownload video musik dan trailer, dan untuk mengurangi dampaknya. Tetapi pada saat yang sama, untuk situs yang perlu menyediakan semua konten dengan aksesibilitas, tentu saja, tidak ada yang berubah.
Oleh karena itu, pro dan kontra dari skema tersebut tetap sama seperti sebelumnya. Namun karena partisi, penskalaan vertikal dalam hal CPU dan memori dipindahkan ke situs, dan ini memungkinkan beberapa situs untuk terus menskalakan. Dibandingkan dengan skema penerbitan konten sebelumnya, ini tidak berubah sama sekali. Biasanya membutuhkan waktu puluhan menit yang sama, jadi kami terus mencari cara untuk mengoptimalkannya.
Apa yang kami pahami saat itu? Kueri bioskop online tersebut menggunakan sebagian kecil dari kemampuan DBMS. Penafsir dan pengoptimal kueri telah merosot dari waktu ke waktu menjadi cache entitas. Kami menyadari bahwa definisi aksesibilitas bersifat universal secara luas. Kueri berbeda dalam hal Anda perlu memahami ketersediaan unit konten atau daftar dan menambahkan atribut tambahan ke ketersediaan ini. Secara umum, ini dapat dilakukan tanpa DBMS yang lengkap.
Dan kedua, bagian dari kunci komposit adalah parameter kardinal rendah. Ada lusinan negara, dalam batas beberapa ratus, lusinan situs, dan hanya beberapa langganan. Kemungkinan besar, denormalisasi penuh tidak diperlukan. Kedua temuan ini telah mengarahkan kami untuk beralih ke representasi dalam memori yang lebih ringkas dan tidak terlalu dinormalisasi, tetapi masih merespons permintaan pengguna dengan cepat.
Pada slide, kita melihat transisi dari transformator ketersediaan v1 ke v2. Berikut adalah skema skema aksesibilitas baru, di mana kunci komposit sebenarnya hanya berupa kunci ID konten. Dan aksesibilitas, secara fisik atau logis, turun untuk menentukan ketersediaan berdasarkan daftar negara, situs, dan langganan.
Dengan demikian, kami mengurangi jumlah sisa non-kunci yang tidak terlihat, yang menempati sebagian besar memori, dan mengurangi jumlah memori pada saat yang bersamaan.
Di sini kita melihat proses perpindahan ke rangkaian trafo aksesibilitas baru. Netflix Hollow berperan sebagai penyedia dan pengindeks entitas dasar, di mana layanan domain mengumpulkan dengan cepat kumpulan entitas komposit dengan berbagai ukuran. Ini berfungsi karena entitas yang mendasarinya masih dinormalisasi dan jumlah gabungan minimal saat membangun. Di sisi lain, menentukan ketersediaan bermuara pada siklus yang sederhana dan murah dan seharusnya tidak sulit.
Pada saat yang sama, Netflix Hollow menyimpan dan dengan hati-hati menangani beban pada CPU dan pengumpulan sampah, selama pembaruan data dan selama mengaksesnya. Hal ini memungkinkan kami untuk mengurangi perbukitan yang kami lihat di grafik pemanfaatan CPU dan menjaganya ke tingkat minimum yang dapat diterima. Selain itu, karena menerapkan skema pengiriman hibrid dalam bentuk snapshot dan perbedaannya, hal ini dapat meningkatkan kecepatan penerbitan konten baru hingga beberapa menit.
Jelas bahwa sebagian besar keuntungan dari skema sebelumnya telah dipertahankan. Mekanisme untuk memperbarui data dalam memori menjadi lebih sederhana dan lebih murah dalam hal pemanfaatan sumber daya. Penskalaan vertikal menurut partisi, menurut situs juga telah dilengkapi dengan penskalaan untuk entitas tertentu, sekarang lebih murah. Dan karena kami mengurangi biaya tambahan untuk memperbarui salinan Snapshot, benar-benar terjadi penskalaan horizontal di seluruh CPU.
Sisi negatif dari skema ini adalah komposisi entitas memerlukan panggilan antar-layanan atau layanan terpisah. Dan masih ada duplikasi data di tingkat entitas dasar, karena sekarang disimpan di setiap layanan domain tempat data digunakan. Tapi Netflix Hollow menyimpan data lebih padat daripada H2, dan H2 menyimpannya jauh lebih padat daripada HashMap dengan objek. Jadi minus ini pasti juga dianggap dapat diterima dan memungkinkan Anda melihat ke masa depan dengan optimisme.
Perosotan ini mampu mengisi bahkan air keran dengan optimisme. Karena penskalaan ke negara baru tidak lagi menjadi faktor pengali dari memori - juga bukan penskalaan ke situs baru. Karena partisi, ini diubah menjadi penskalaan horizontal.
Nah, menskalakan pengguna baru dan memperluas fungsionalitas bioskop online turun ke peningkatan beban. Untuk menyediakannya, kami siap menghadirkan layanan ringan terikat CPU sebanyak yang diperlukan. Di sisi lain, kami telah mengumpulkan cukup pengetahuan di bidang aksesibilitas untuk menantikan tantangan baru dengan percaya diri. Saya harap saya dapat membagikan sebagian dari pengetahuan ini kepada Anda. Terima kasih atas perhatian Anda.