Praktik terbaik untuk workload media

Halaman ini menjelaskan praktik terbaik saat menggunakan Cloud Storage untuk beban kerja media. Beban kerja 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 beban kerja media berikut:

  • Produksi media: Mencakup beban kerja seperti pascaproduksi film, termasuk pengeditan video yang membutuhkan banyak komputasi dan sering kali 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 tidak ada aktivitas GPU yang lebih rendah. Mereka juga memerlukan latensi baca dan tulis yang rendah karena hal ini sangat penting dalam mengurangi latensi tail.
  • Pengelolaan aset media: Mencakup pengaturan 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 live streaming. 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 pada workload media, lihat bagian berikut.

Transfer data

Gunakan Storage Transfer Service untuk mengupload file media mentah berukuran lebih dari 1 TiB 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 di antara 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 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 Archive Storage. Anda dapat menentukan kelas penyimpanan yang berbeda untuk objek yang memiliki kebutuhan ketersediaan atau akses yang berbeda.
  • Untuk beban kerja produksi media dan penyajian 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 mendowngrade kelas penyimpanan objek untuk membantu mengelola biaya.

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

Praktik terbaik untuk workload penyaluran dan distribusi konten

Untuk workload VoD dan livestreaming, tujuannya adalah untuk menghindari error pemutaran, penundaan mulai pemutaran, atau buffering saat memutar video di pemutar video pengguna akhir. Workload ini juga memerlukan penskalaan pembacaan untuk memperhitungkan jumlah besar pelihat 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 pemanfaatan resource, dan meningkatkan performa. Penggunaan 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 masih mendapatkan pengurangan TCO saat menyajikan 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 daftar penyedia yang disetujui, lihat Penyedia layanan yang disetujui Google.

Berikut adalah opsi yang dapat dikonfigurasi saat menyiapkan CDN:

Pilih lokasi origin shield

Lokasi origin shield adalah cache antara CDN dan Cloud Storage. Jika CDN Anda memungkinkan Anda memilih lokasi origin shield, ikuti panduan CDN tentang apakah direkomendasikan untuk memilih origin shield agar lebih dekat ke region bucket Cloud Storage atau lokasi konsentrasi traffic pengguna akhir Anda. Origin shield adalah tindakan perlindungan yang melindungi server asal Anda dari kelebihan beban. CDN dengan perlindungan origin membantu meningkatkan pengurangan beban origin dengan menambahkan cache tambahan antara origin dan CDN. Misalnya, Media CDN menyediakan infrastruktur edge bertingkat yang komprehensif 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 Cloud Storage kelas B. CDN memiliki cache terdistribusi yang di-deploy di seluruh dunia, tetapi menyediakan cara untuk menciutkan beberapa permintaan pengguna akhir menjadi satu permintaan ke origin. 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 apa pun dengan kode respons HTTP 5xx–502, 503, 504 di CDN Anda. CDN mendukung percobaan ulang origin, sehingga memungkinkan percobaan ulang permintaan yang gagal ke origin. Sebagian besar CDN memungkinkan Anda menentukan jumlah percobaan ulang untuk origin saat ini. Untuk informasi tentang mencoba ulang permintaan asal di Media CDN, lihat Mencoba ulang permintaan asal.

Opsi lokasi untuk distribusi konten

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

  • Untuk mengoptimalkan biaya, bucket yang dibuat di 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 penyajian konten dan analisis dengan geo-redundansi, 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 kepada pengguna akhir. Untuk performa streaming yang lebih baik, pilih bucket regional yang ditempatkan bersama dengan resource komputasi yang digunakan untuk transcoding.

Mengoptimalkan durasi segmen video untuk live stream

Untuk livestream, ukuran segmen terendah yang direkomendasikan adalah dua detik karena segmen video pendek lebih sensitif terhadap latensi tulis longtail. Latensi penulisan ekor panjang mengacu pada operasi penulisan 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 berada 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 pada transcoder guna mengurangi latensi longtail lebih dari dua detik untuk penulisan ke Cloud Storage dan bereksperimen dengan waktu buffering yang lebih lama sekitar sepuluh detik.

Tingkatkan 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, pedomannya adalah menskalakan permintaan Anda secara bertahap dengan memulai dari 1.000 operasi tulis per detik dan 5.000 operasi baca per detik, lalu menaikkan rasio permintaan secara bertahap dua kali lipat setiap 20 menit. Metode ini memungkinkan Cloud Storage mendistribusikan ulang beban di beberapa server, dan meningkatkan ketersediaan serta latensi bucket Anda dengan mengurangi kemungkinan masalah pemutaran.

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

Perkirakan QPS Anda ke origin

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 adalah 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 jumlah permintaan baca/daftar/dapatkan dan diagram Total jumlah permintaan tulis masing-masing di konsolGoogle Cloud . Jika Anda menskalakan QPS pada bucket lebih cepat daripada panduan peningkatan yang ditentukan yang disebutkan di bagian sebelumnya, Anda mungkin akan mengalami error 429 Too many requests. Pelajari cara mengatasi error 429 Too many requests.

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

Menerapkan penskalaan QPS di bucket dengan melakukan pra-pemanasan bucket

Anda dapat mempercepat proses penskalaan sebelum acara livestreaming dengan melakukan prewarming pada bucket. Sebelum acara livestreaming, buat traffic sintetis ke bucket Anda yang sesuai dengan QPS maksimum yang diharapkan yang akan diterima oleh 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 origin Anda sebesar 10.000, traffic simulasi Anda harus menargetkan 15.000 permintaan per detik untuk mempersiapkan origin Anda menghadapi peristiwa tersebut.

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

Saat membuat traffic simulasi ini, ikuti pendekatan penskalaan bertahap, mulai dari 5.000 permintaan per detik dan meningkat secara progresif hingga Anda mencapai target. Alokasikan waktu yang cukup sebelum acara untuk mencapai perkiraan beban. Misalnya, mencapai 15.000 permintaan per detik, dengan 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 akan menurun secara bertahap ke tingkat dasar selama 24 jam. Jika server asal Anda mengalami jeda beberapa jam di antara acara livestream, sebaiknya simulasikan traffic sebelum setiap acara.

Menggunakan bucket yang mengaktifkan namespace hierarkis untuk QPS awal yang tinggi

Bucket Cloud Storage dengan namespace hierarkis diaktifkan memberikan QPS awal hingga delapan kali lipat dibandingkan dengan bucket tanpa HNS. QPS awal yang lebih tinggi mempermudah penskalaan beban kerja yang intensif data dan memberikan throughput yang lebih baik. Untuk mengetahui informasi tentang batasan dalam bucket dengan namespace hierarkis yang diaktifkan, lihat Batasan.

Hindari nama berurutan untuk segmen video guna menskalakan QPS

Dengan penskalaan QPS, permintaan didistribusikan ulang di beberapa server. Namun, Anda mungkin mengalami bottleneck performa jika semua objek menggunakan awalan yang tidak diacak atau berurutan. Menggunakan nama yang benar-benar acak daripada nama berurutan akan memberi Anda distribusi pemuatan 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 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, penggunaan bucket yang berbeda untuk setiap livestream akan membantu Anda menskalakan beban baca dan tulis secara efektif tanpa mencapai batas I/O untuk bucket. Menggunakan bucket yang berbeda untuk setiap livestream akan mengurangi latensi outlier yang besar karena penundaan penskalaan.

Langkah berikutnya