Praktik terbaik untuk workload media

Halaman ini menjelaskan praktik terbaik saat menggunakan Cloud Storage untuk workload media. Workload ini sering kali mencakup berbagai Google Cloud produk seperti Media CDN, Live Stream API, Transcoder API, dan Video Stitcher API.

Ringkasan

Google Cloud menawarkan solusi untuk mengoptimalkan jenis workload media berikut:

  • Produksi media: Mencakup workload seperti pascaproduksi film termasuk pengeditan video yang memerlukan banyak komputasi dan sering menggunakan GPU untuk komputasi berperforma tinggi. Sering kali, data terkait media yang berada di Cloud Storage diproses oleh aplikasi yang berjalan di Compute Engine atau Google Kubernetes Engine, dan output dari proses ini ditulis kembali ke Cloud Storage. Workload ini memerlukan penskalaan throughput baca dan tulis gabungan dari Cloud Storage ke cluster komputasi dengan waktu idle GPU yang lebih rendah. Workload ini juga memerlukan latensi baca dan tulis yang rendah karena hal ini penting dalam mengurangi latensi ekor.
  • Pengelolaan aset media: Mencakup pengorganisasian aset media Anda untuk penyimpanan, pengambilan, dan penggunaan yang efisien.
  • Penayangan dan distribusi konten: Mencakup streaming media kepada pengguna, termasuk layanan video on demand (VoD) dan livestreaming. Selama VoD, saat pengguna meminta konten yang tidak di-cache di jaringan penayangan konten (CDN), konten akan diambil dari bucket Cloud Storage. Untuk permintaan livestreaming, konten ditulis ke bucket Storage dan dibaca dari CDN secara bersamaan.

Praktik terbaik untuk workload media

Untuk mengetahui praktik terbaik yang berlaku untuk workload media, lihat bagian berikut.

Transfer data

Gunakan Storage Transfer Service untuk mengupload lebih dari 1 TiB file media mentah dari sumber lokal, seperti kamera video atau penyimpanan lokal ke Cloud Storage. Storage Transfer Service memungkinkan perpindahan data yang lancar di seluruh sistem penyimpanan objek dan file. Untuk transfer yang lebih kecil, pilih layanan untuk mentransfer data ke dan dari Cloud Storage atau antar-sistem file berdasarkan skenario transfer Anda.

Lokasi bucket

Untuk workload yang memerlukan resource komputasi seperti produksi media, Anda harus membuat bucket di region atau dual-region yang sama dengan resource komputasi. Metode ini membantu mengoptimalkan performa dengan menurunkan latensi baca dan tulis untuk workload pemrosesan, biaya, dan bandwidth Anda. Untuk panduan selengkapnya tentang memilih lokasi bucket, lihat Pertimbangan lokasi bucket.

Kelas penyimpanan

Bergantung pada jenis workload media, kelas penyimpanan yang harus Anda pilih akan berbeda. Jenis kelas penyimpanan yang direkomendasikan untuk berbagai workload media adalah sebagai berikut:

  • Untuk mengelola aset media, seperti video arsip, kelas penyimpanan default bucket harus berupa penyimpanan Arsip. Anda dapat menentukan kelas penyimpanan yang berbeda untuk objek yang memiliki kebutuhan akses atau ketersediaan yang berbeda.
  • Untuk workload produksi media dan penayangan konten, karena data sering dibaca dari bucket Cloud Storage, Anda harus menyimpan data di Standard Storage.

Untuk panduan selengkapnya tentang memilih kelas penyimpanan untuk bucket Anda, lihat Kelas penyimpanan.

Pengelolaan siklus proses data

Untuk mengelola aset media, Anda harus mengelola siklus proses objek untuk bucket dengan menentukan konfigurasi siklus proses. Dengan fitur Object Lifecycle Management, Anda dapat mengelola siklus proses data termasuk menetapkan Time to Live (TTL) untuk objek, mempertahankan versi lama objek, dan menurunkan kelas penyimpanan objek untuk membantu mengelola biaya.

Jika pola akses data dapat diprediksi, Anda dapat menetapkan konfigurasi siklus proses untuk bucket. Untuk pola akses data yang tidak diketahui atau tidak dapat diprediksi, Anda dapat menetapkan fitur Autoclass untuk bucket. Dengan Autoclass, Cloud Storage secara otomatis memindahkan data yang tidak sering diakses ke kelas penyimpanan yang jarang diakses.

Praktik terbaik untuk workload penayangan dan distribusi konten

Untuk workload VoD dan livestreaming, tujuannya adalah menghindari error pemutaran, penundaan awal pemutaran, atau buffering saat memutar video di pemutar video pengguna akhir. Workload ini juga memerlukan penskalaan pembacaan untuk memperhitungkan banyaknya penonton serentak. Dalam semua kasus, pembacaan traffic pelanggan harus melalui CDN.

Untuk mengetahui praktik terbaik yang berlaku untuk workload penayangan dan distribusi konten, lihat bagian berikut.

Menggunakan CDN secara efektif

Menggunakan jaringan penayangan konten (CDN) di depan bucket Cloud Storage akan meningkatkan pengalaman pengguna akhir karena CDN meng-cache konten dengan mengurangi latensi dan meningkatkan efisiensi bandwidth. CDN memungkinkan Anda mengurangi total biaya kepemilikan (TCO) dengan mengurangi biaya bandwidth, mengoptimalkan penggunaan resource, dan meningkatkan performa. Menggunakan Media CDN membantu mengurangi TCO untuk menayangkan konten kepada pengguna akhir karena biaya pengisian cache untuk Media CDN adalah nol. Anda dapat menggunakan Media CDN sebagai sumber CDN pihak ketiga lainnya. Dengan CDN lain, Anda tetap mendapatkan pengurangan TCO saat menayangkan konten dari cache Media CDN ini, bukan dari server asal.

Jika Anda menggunakan CDN pihak ketiga, CDN Interconnect memungkinkan penyedia tertentu membuat link peering langsung dengan jaringan edge Google di berbagai lokasi. Traffic jaringan Anda yang keluar dari Google Cloud melalui salah satu link ini akan mendapatkan manfaat dari konektivitas langsung ke penyedia CDN yang didukung dan akan ditagih secara otomatis dengan harga yang lebih rendah. Untuk mengetahui daftar penyedia yang disetujui, lihat Penyedia layanan yang disetujui Google.

Berikut adalah daftar opsi yang dapat dikonfigurasi saat menyiapkan CDN:

Memilih lokasi origin shield

Lokasi origin shield adalah cache antara CDN dan Cloud Storage. Jika CDN memungkinkan Anda memilih lokasi origin shield, ikuti panduan CDN tentang apakah sebaiknya memilih origin shield agar lebih dekat ke region bucket Cloud Storage Anda atau lokasi konsentrasi traffic pengguna akhir Anda. Origin shield adalah tindakan perlindungan yang melindungi server asal Anda dari kelebihan beban. CDN dengan origin shielding membantu meningkatkan pengurangan beban origin dengan menambahkan cache tambahan antara origin dan CDN. Misalnya, Media CDN menyediakan infrastruktur edge bertingkat yang dirancang untuk secara aktif meminimalkan pengisian cache jika memungkinkan.

Mengaktifkan penggabungan permintaan

Pastikan penggabungan permintaan diaktifkan untuk CDN Anda. Menggabungkan beberapa permintaan menjadi satu permintaan akan mengurangi biaya operasi kelas B Cloud Storage. CDN memiliki cache terdistribusi yang di-deploy di seluruh dunia, tetapi menyediakan cara untuk menggabungkan beberapa permintaan pengguna akhir menjadi satu permintaan ke server asal. Misalnya, Media CDN secara aktif menggabungkan beberapa permintaan pengisian cache yang didorong pengguna untuk kunci cache yang sama menjadi permintaan satu server asal per node edge, sehingga mengurangi jumlah permintaan yang dibuat ke bucket.

Mengonfigurasi perilaku percobaan ulang di CDN

Pastikan Anda mengonfigurasi percobaan ulang untuk masalah server dengan kode respons HTTP 5xx–502, 503, 504 di CDN Anda. CDN mendukung percobaan ulang server asal, sehingga memungkinkan percobaan ulang permintaan yang gagal ke server asal. Sebagian besar CDN memungkinkan Anda menentukan jumlah percobaan ulang untuk server asal saat ini. Untuk mengetahui informasi tentang mencoba ulang permintaan server asal di Media CDN, lihat Mencoba ulang permintaan server asal.

Opsi lokasi untuk distribusi konten

Untuk workload yang membaca data dari Cloud Storage yang tidak di-cache di CDN, seperti penayangan dan distribusi konten jenis VoD, pertimbangkan faktor-faktor berikut saat memilih lokasi untuk bucket Anda:

  • Untuk mengoptimalkan biaya, bucket yang dibuat dalam satu region memiliki biaya penyimpanan terendah.
  • Untuk mengoptimalkan ketersediaan, pertimbangkan hal berikut:
    • Untuk sebagian besar workload media, sebaiknya gunakan bucket dual-region karena bucket ini mereplikasi objek Anda di dua region untuk ketersediaan yang lebih baik.
    • Untuk kasus penggunaan yang memerlukan penayangan konten dan analisis dengan redundansi geografis, gunakan bucket di multi-region untuk ketersediaan tertinggi.
  • Untuk mengoptimalkan latensi dan mengurangi biaya jaringan, pertimbangkan hal berikut:
    • Untuk VoD, pilih region yang paling dekat dengan lokasi sebagian besar pengguna akhir Anda atau region dengan konsentrasi traffic tertinggi.
    • Selama livestreaming, bucket menerima permintaan tulis dari transcoder dan permintaan baca dari CDN yang meng-cache dan mendistribusikan konten ke pengguna akhir. Untuk performa streaming yang ditingkatkan, pilih bucket regional yang berada di lokasi yang sama dengan resource komputasi yang digunakan untuk transcoding.

Mengoptimalkan panjang segmen video untuk livestream

Untuk livestream, ukuran segmen terendah yang direkomendasikan adalah dua detik karena segmen video pendek lebih sensitif terhadap latensi tulis ekor panjang. Latensi tulis longtail mengacu pada operasi tulis yang lambat atau tertunda untuk konten yang jarang diakses atau memiliki volume permintaan yang rendah.

Jarak fisik antara lokasi bucket dan lokasi pemutaran pengguna akhir memengaruhi waktu transmisi. Jika pengguna akhir Anda jauh dari lokasi bucket, sebaiknya gunakan ukuran segmen video yang lebih panjang.

Untuk memberikan pengalaman terbaik kepada penonton, sebaiknya gunakan strategi percobaan ulang dan hedging permintaan untuk penulisan di transcoder guna mengurangi latensi ekor panjang yang lebih dari dua detik untuk penulisan ke Cloud Storage dan bereksperimen dengan waktu buffer yang lebih lama, yaitu sekitar sepuluh detik.

Meningkatkan QPS secara bertahap

Bucket Cloud Storage memiliki kapasitas IO awal sebesar 1.000 operasi tulis objek per detik dan 5.000 operasi baca objek per detik. Untuk workload livestream, panduannya adalah menskalakan permintaan Anda secara bertahap dengan memulai dari 1.000 operasi tulis per detik dan 5.000 operasi baca per detik, serta meningkatkan dua kali lipat rasio permintaan secara bertahap setiap 20 menit. Metode ini memungkinkan Cloud Storage mendistribusikan ulang beban di beberapa server, serta meningkatkan ketersediaan dan latensi bucket Anda dengan mengurangi kemungkinan masalah pemutaran.

Untuk acara livestream dengan QPS yang lebih tinggi, Anda harus menerapkan penskalaan pada bucket dengan melakukan pemanasan awal pada bucket atau dengan mengaktifkan namespace hierarkis di bucket. Sebelum menerapkan penskalaan pada bucket, Anda harus melakukan tugas berikut:

Memperkirakan QPS ke server asal

Misalnya, untuk livestream dengan satu juta penonton, CDN akan menerima satu juta QPS. Dengan asumsi CDN Anda memiliki rasio cache ditemukan sebesar 99,0%, traffic yang dihasilkan ke Cloud Storage akan menjadi 1%. QPS akan menjadi 1% dari total penonton (satu juta), yang sama dengan 10.000 QPS. Nilai ini lebih besar dari kapasitas IO awal.

Memantau QPS dan memecahkan masalah error penskalaan

Anda harus memantau QPS dan memecahkan masalah error penskalaan. Untuk mengetahui informasi selengkapnya, lihat Ringkasan pemantauan di Cloud Storage . Untuk memantau permintaan baca dan tulis, amati diagram Total read/list/get request count dan diagram Total write request count di Google Cloud konsol. Jika Anda menskalakan QPS pada bucket lebih cepat daripada panduan peningkatan yang ditentukan yang disebutkan di bagian sebelumnya, Anda mungkin akan mengalami error 429 Terlalu banyak permintaan. Pelajari cara mengatasi error 429 Terlalu banyak permintaan.

Bagian berikut menjelaskan cara menskalakan bucket untuk QPS yang lebih tinggi setelah Anda memperkirakan QPS ke server asal.

Menerapkan penskalaan QPS pada bucket dengan melakukan pemanasan awal pada bucket

Anda dapat mempercepat proses penskalaan sebelum acara livestreaming dengan melakukan pemanasan awal pada bucket. Sebelum acara livestreaming, buat traffic sintetis ke bucket Anda yang cocok dengan QPS maks yang diharapkan yang akan diterima server asal CDN untuk acara tersebut ditambah buffer 50% tambahan yang memperhitungkan rasio cache ditemukan yang diharapkan dari CDN Anda. Misalnya, jika Anda memperkirakan QPS ke server asal Anda adalah 10.000, traffic simulasi Anda harus menargetkan 15.000 permintaan per detik untuk menyiapkan server asal Anda untuk acara tersebut.

Untuk traffic simulasi ini, Anda dapat menggunakan file feed live acara sebelumnya seperti segmen dan manifes atau file pengujian. Pastikan Anda memiliki file yang berbeda selama proses pemanasan awal.

Saat membuat traffic simulasi ini, ikuti pendekatan penskalaan bertahap, mulai dari 5.000 permintaan per detik dan terus meningkat hingga Anda mencapai target. Alokasikan waktu yang cukup sebelum acara untuk mencapai perkiraan beban. Misalnya, mencapai 15.000 permintaan per detik, menggandakan beban setiap 20 menit dari 5.000 permintaan per detik awal, akan memerlukan waktu sekitar 30 menit.

Server asal mempertahankan kapasitas hingga traffic konsisten. Kapasitas server asal secara bertahap menurun ke tingkat dasar pengukuran selama 24 jam. Jika server asal Anda mengalami jeda beberapa jam antara acara livestream, sebaiknya simulasikan traffic sebelum setiap acara.

Menggunakan bucket dengan namespace hierarkis yang diaktifkan untuk QPS awal yang tinggi

Bucket Cloud Storage dengan namespace hierarkis yang diaktifkan memberikan QPS awal hingga delapan kali lipat dibandingkan bucket tanpa HNS. QPS awal yang lebih tinggi memudahkan penskalaan workload yang memerlukan banyak data dan memberikan peningkatan throughput. Untuk mengetahui informasi tentang batasan di bucket dengan namespace hierarkis yang diaktifkan, lihat Batasan.

Menghindari nama berurutan untuk segmen video untuk penskalaan QPS

Dengan penskalaan QPS, permintaan didistribusikan ulang di beberapa server. Namun, Anda mungkin mengalami bottleneck performa saat semua objek menggunakan awalan yang tidak diacak atau berurutan. Menggunakan nama yang benar-benar acak dibandingkan nama berurutan akan memberikan distribusi beban terbaik. Namun, jika Anda ingin menggunakan nomor urut atau stempel waktu sebagai bagian dari nama objek, terapkan pengacakan pada nama objek dengan menambahkan nilai hash sebelum nomor urut atau stempel waktu. Misalnya, jika nama objek asli yang ingin Anda gunakan adalah my-bucket/2016-05-10-12-00-00/file1, Anda dapat menghitung hash MD5 nama objek asli dan menambahkan enam karakter pertama hash sebagai awalan pada nama objek. Objek baru akan menjadi my-bucket/2fa764-2016-05-10-12-00-00/file1. Untuk mengetahui informasi selengkapnya, lihat Menggunakan konvensi penamaan yang mendistribusikan beban secara merata di seluruh rentang kunci. Jika Anda tidak dapat menghindari penamaan berurutan untuk segmen video, gunakan bucket dengan namespace hierarkis yang diaktifkan untuk mendapatkan QPS yang lebih tinggi.

Menggunakan bucket yang berbeda untuk setiap livestream

Untuk livestream serentak, menggunakan bucket yang berbeda untuk setiap livestream akan membantu Anda menskalakan beban baca dan tulis secara efektif tanpa mencapai batas IO untuk bucket. Menggunakan bucket yang berbeda untuk setiap livestream akan mengurangi latensi outlier besar karena penundaan penskalaan.

Langkah berikutnya