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 menggunakan GPU untuk komputasi berperforma tinggi. Biasanya, 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 tunggu GPU yang lebih rendah. Mereka juga memerlukan latensi baca dan tulis yang rendah karena hal ini penting dalam mengurangi latensi ekor.
  • Pengelolaan aset media: Mencakup penataan 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 pengiriman konten (CDN), konten tersebut diambil dari bucket Cloud Storage. Untuk permintaan live streaming, 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 file media mentah berukuran lebih dari 1 TiB dari sumber lokal, seperti kamera video atau penyimpanan lokal ke Cloud Storage. Storage Transfer Service memungkinkan pergerakan 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 beban kerja yang memerlukan resource komputasi seperti produksi media, Anda harus membuat bucket di region yang sama atau region ganda dengan resource komputasi. Metode ini membantu mengoptimalkan performa dengan menurunkan latensi baca dan tulis untuk workload pemrosesan, biaya, dan bandwidth. Untuk panduan selengkapnya tentang cara memilih lokasi bucket, lihat Pertimbangan lokasi bucket.

Kelas penyimpanan

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

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

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 men-downgrade kelas penyimpanan objek guna 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 penayangan dan distribusi konten

Untuk workload VoD dan live streaming, tujuannya adalah menghindari kesalahan pemutaran, penundaan mulai pemutaran, atau buffering saat memutar video di pemutar video pengguna akhir. Workload ini juga memerlukan penskalaan pembacaan untuk memperhitungkan sejumlah besar 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 meningkatkan pengalaman pengguna akhir karena CDN menyimpan konten dalam cache 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 tetap mendapatkan pengurangan TCO saat menayangkan konten dari cache Media CDN ini, bukan dari origin.

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 opsi yang dapat dikonfigurasi saat menyiapkan CDN:

Pilih lokasi perisai asal

Lokasi perisai asal adalah cache antara CDN dan Cloud Storage. Jika CDN memungkinkan Anda memilih lokasi perisai asal, ikuti panduan CDN tentang apakah sebaiknya memilih perisai asal agar lebih dekat dengan region bucket Cloud Storage atau lokasi konsentrasi traffic pengguna akhir Anda. Perisai origin adalah tindakan perlindungan yang melindungi server origin Anda dari kelebihan beban. CDN dengan perlindungan origin membantu meningkatkan pengurangan beban origin dengan menambahkan cache ekstra 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 menggabungkan 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 satu permintaan origin per node tepi, 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 asal, yang memungkinkan percobaan ulang permintaan yang tidak berhasil ke asal. 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 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 tersebut mereplikasi objek Anda di dua region untuk ketersediaan yang lebih baik.
    • Untuk kasus penggunaan yang memerlukan penayangan 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 live streaming, bucket menerima permintaan tulis dari transcoder dan permintaan baca dari CDN yang menyimpan dalam cache dan mendistribusikan konten kepada pengguna akhir. Untuk performa streaming yang lebih baik, pilih bucket regional yang dikolokasikan 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 penulisan long-tail. Latensi penulisan long-tail 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 jauh dari lokasi bucket, sebaiknya gunakan ukuran segmen video yang lebih panjang.

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

Tingkatkan QPS secara bertahap

Bucket Cloud Storage memiliki kapasitas IO awal sebanyak 1.000 operasi tulis objek per detik dan 5.000 operasi baca objek per detik. Untuk workload live stream, 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 live stream dengan QPS yang lebih tinggi, Anda harus menerapkan penskalaan pada bucket dengan memanaskan bucket terlebih dahulu atau dengan mengaktifkan namespace hierarkis di bucket Anda. Sebelum menerapkan penskalaan pada bucket, Anda harus melakukan tugas berikut:

Perkirakan QPS Anda ke origin

Misalnya, untuk live stream dengan satu juta penonton, CDN akan menerima satu juta QPS. Dengan asumsi CDN Anda memiliki rasio hit cache 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.

Pantau QPS dan pecahkan 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 konsol Google Cloud . Jika Anda menskalakan QPS pada bucket lebih cepat daripada pedoman peningkatan yang ditentukan yang disebutkan di bagian sebelumnya, Anda mungkin mengalami error 429 Terlalu banyak permintaan. Pelajari cara mengatasi error 429 Too many requests.

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

Terapkan penskalaan QPS di bucket Anda dengan melakukan pemanasan awal bucket

Anda dapat mempercepat proses penskalaan sebelum acara live streaming dengan memanaskan bucket terlebih dahulu. Sebelum acara live streaming, 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 dengan memperhitungkan perkiraan rasio hit cache CDN Anda. Misalnya, jika Anda memperkirakan QPS ke origin Anda adalah 10.000, maka traffic simulasi Anda harus menargetkan 15.000 permintaan per detik untuk mempersiapkan origin Anda menghadapi acara tersebut.

Untuk traffic simulasi ini, Anda dapat menggunakan file feed langsung 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, untuk 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 berkurang 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 memudahkan penskalaan beban kerja yang memproses banyak 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 ke beberapa server. Namun, Anda mungkin mengalami hambatan performa saat semua objek menggunakan awalan yang tidak diacak atau berurutan. Menggunakan nama yang benar-benar acak daripada nama berurutan akan memberi Anda 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 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 ruang nama 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. Penggunaan bucket yang berbeda untuk setiap livestream mengurangi latensi pencilan besar karena penundaan penskalaan.

Langkah berikutnya