Halaman ini memberikan praktik terbaik untuk mengoptimalkan dan mempercepat pengiriman konten dengan Cloud CDN. Bagian ini dibagi menjadi beberapa area utama.
Cloud CDN menggunakan Load Balancer Aplikasi eksternal sebagai origin untuk konten yang dapat di-cache. Load Balancer Aplikasi eksternal dapat mengirimkan campuran konten statis dan yang dibuat secara dinamis kepada pengguna melalui satu alamat IP global dari jenis backend berikut:
- Grup instance
- Grup endpoint jaringan zona (NEG)
- NEG serverless: Satu atau beberapa layanan App Engine, Cloud Run, atau fungsi Cloud Run
- NEG internet untuk backend eksternal
- Bucket di Cloud Storage
Karena integrasi yang lancar dengan Google Cloud, Anda memiliki beberapa opsi untuk men-deploy Cloud CDN dan mengelola konten. Gunakan praktik terbaik yang tercantum di sini untuk merencanakan dan meningkatkan kualitas deployment Anda. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan Cloud CDN.
Mengoptimalkan rasio cache ditemukan
Praktik yang direkomendasikan berikut membantu mengoptimalkan rasio hit cache.
Cache konten statis
Sebagai praktik terbaik untuk meningkatkan performa, saat mengaktifkan Cloud CDN, Anda harus memilih mode cache yang tepat untuk aplikasi Anda.
Metode yang paling fleksibel dan umumnya lebih disukai untuk mengelola aturan cache adalah dengan menggunakan header kontrol cache. Jika Anda tidak terbiasa menggunakan header cache-control origin, rekomendasi praktik terbaiknya adalah mengizinkan Cloud CDN menyimpan konten statis ke dalam cache secara otomatis.
Untuk meng-cache respons statis dari origin secara otomatis, Anda dapat menggunakan setelan --cache-mode=CACHE_ALL_STATIC
(default). Setelan ini memungkinkan Cloud CDN menyimpan jenis konten statis umum dalam cache saat origin tidak menentukan perintah penyimpanan dalam cache di header respons. Pastikan konten Anda cocok dengan
kategori yang diuraikan; jika tidak, konten tidak akan di-cache.
Jangan menyimpan konten khusus pengguna dalam cache
Dalam beberapa kasus, browser dapat meng-cache konten khusus pengguna. Jangan gunakan Cloud CDN untuk menyimpan konten khusus pengguna ke dalam cache.
Menggunakan kunci cache kustom untuk meningkatkan rasio hit cache
Untuk performa dan skalabilitas, penting untuk mengoptimalkan rasio hit cache. Secara default, Cloud CDN menggunakan URL permintaan lengkap untuk membuat kunci cache. Untuk membantu mengoptimalkan rasio hit cache, Anda dapat menggunakan kunci cache kustom sehingga Cloud CDN tidak perlu membuat shard cache.
Kunci cache kustom memungkinkan Anda menyertakan atau menghapus kombinasi protokol, host, dan string kueri apa pun. Berikut adalah beberapa contoh kapan Anda dapat menggunakan kunci cache kustom:
Anda memiliki dua host yang me-resolve ke alamat IP yang sama dan membuka layanan yang sama. Dalam contoh ini, seluruh situs sama di kedua host. Secara default, Cloud CDN meng-cache dua salinan karena header
Host:
yang berbeda dalam permintaan HTTP. Dengan kunci cache kustom, Anda dapat membuat Cloud CDN mengabaikan bagian host permintaan dan membagikan entri cache.Dalam contoh yang lebih spesifik, Anda mungkin memiliki dua situs di domain yang berbeda yang menggunakan logo yang sama. Konten situs berbeda, tetapi Anda menggunakan logo perusahaan yang sama di kedua domain, dan Anda memiliki layanan backend khusus yang menyimpan konten bersama. Saat Anda mengaktifkan Cloud CDN dan menyesuaikan kunci cache untuk layanan backend yang menyimpan logo, hapus centang pada kotak Host sehingga cache mengabaikan domain, tetapi meng-cache logo.
Logo harus di-cache, baik ditampilkan melalui HTTP maupun HTTPS. Saat Anda menyesuaikan kunci cache untuk layanan backend yang menyimpan logo, hapus kotak centang Protokol sehingga permintaan melalui HTTP dan HTTPS dihitung sebagai cocok untuk entri cache logo.
Untuk mempelajari cara menyesuaikan kunci cache, lihat Menggunakan kunci cache.
Mengoptimalkan performa
Praktik yang direkomendasikan berikut membantu mengoptimalkan performa.
Pastikan dukungan protokol HTTP/3 dan QUIC diaktifkan
HTTP/3 adalah protokol internet generasi berikutnya. Protokol ini dibuat berdasarkan QUIC, protokol yang dikembangkan dari protokol Google QUIC ) (gQUIC) asli. HTTP/3 didukung antara load balancer HTTP(S) eksternal, Cloud CDN, dan klien.
Untuk meningkatkan performa dengan Cloud CDN, pastikan HTTP/3 diaktifkan.
Menggunakan caching negatif
Caching negatif memberikan kontrol terperinci terhadap penyimpanan ke cache untuk error atau pengalihan umum. Saat Cloud CDN menemukan kode respons tertentu, Cloud CDN akan menyimpan respons tersebut dalam cache untuk TTL yang ditetapkan. Hal ini dapat mengurangi beban pada origin Anda dan meningkatkan kualitas pengalaman pengguna akhir dengan mengurangi latensi respons.
Mengoptimalkan keamanan
Praktik yang direkomendasikan berikut membantu mengoptimalkan keamanan.
Menggunakan Google Cloud Armor
Google Cloud Armor terintegrasi dengan Cloud CDN untuk konten yang di-cache dan tidak di-cache atau cache tidak ditemukan. Rekomendasi praktik terbaik adalah menggunakan Google Cloud Armor bersama dengan Cloud CDN jika memungkinkan untuk meningkatkan keamanan aplikasi web.
Menggunakan URL yang ditandatangani
Jika Anda menggunakan URL yang ditandatangani, perhatikan hal-hal berikut:
Simpan konten publik dan pribadi di bucket Cloud Storage yang terpisah.
Ikuti praktik terbaik keamanan.
Mengautentikasi origin pribadi
Autentikasi origin menawarkan jaminan kuat bahwa permintaan hanya berasal dari layanan backend yang Anda konfigurasikan sendiri. API ini juga menawarkan perlindungan data dalam pengiriman untuk permintaan dan melindungi dari penggunaan kembali bagian permintaan yang ditandatangani.
Sebaiknya gunakan autentikasi origin pribadi untuk bucket Amazon S3 atau penyimpanan objek yang kompatibel. Autentikasi origin pribadi membantu memastikan bahwa hanya koneksi tepercaya yang mengakses konten di origin pribadi Anda dan pengguna tidak mengaksesnya secara langsung.
Selain itu, jika firewall asal mencegah akses ke asal, gunakan daftar IP yang diizinkan untuk memastikan bahwa permintaan berasal dari Cloud CDN atau Load Balancer Aplikasi eksternal. Namun, hal ini tidak mencegah pelanggan Media CDN lain mencoba mengakses konten Anda dengan menentukan origin Anda dalam konfigurasi mereka.
Mengoptimalkan cache
Praktik yang direkomendasikan berikut membantu mengoptimalkan cache.
Mengoptimalkan TTL cache
Anda dapat menetapkan atau mengganti TTL untuk menyesuaikan durasi penyimpanan cache Cloud CDN terhadap respons Anda dan kapan Cloud CDN memvalidasi ulang respons Anda.
Anda juga dapat menentukan TTL yang ditampilkan klien untuk memaksimalkan cache browser.
Untuk mengetahui informasi selengkapnya, lihat Menggunakan setelan dan penggantian TTL.
Menetapkan masa berlaku untuk konten yang sensitif waktu
Setiap bagian konten dalam cache Cloud CDN memiliki waktu habis masa berlaku terkait, dan Anda harus menetapkan masa berlaku yang sesuai dengan kasus penggunaan Anda. Karena server origin harus mengirim ulang konten yang masa berlakunya habis di server cache, Anda harus memilih masa berlaku dengan cermat.
Salah satu metode untuk memilih masa berlaku adalah dengan mengategorikan konten berdasarkan seberapa sering Anda memperbarui konten; misalnya:
- Informasi hampir real-time seperti feed live untuk acara olahraga atau lalu lintas
- Info terbaru yang sering diperbarui seperti informasi cuaca mingguan, harian, atau per jam, atau gambar berita halaman depan
- Pembaruan yang jarang dilakukan seperti logo situs atau file CSS atau JavaScript
Selanjutnya, pilih masa berlaku berdasarkan kategori konten. Misalnya, masa berlaku
lima detik mungkin sesuai untuk skor olahraga yang mendekati real-time, dan masa berlaku
satu jam dapat digunakan untuk info terbaru tentang cuaca. Untuk konten yang disimpan di
Cloud Storage, tetapkan waktu habis masa berlaku menggunakan
metadata Cache-Control
.
Saat konten ditayangkan oleh Compute Engine, Anda mengontrol waktu habis masa berlaku dengan mengonfigurasi software server web.
Waktu habis masa berlaku ditentukan oleh nilai max-age
dan s-maxage
di header Cache-Control
. Header ini ditentukan oleh
spesifikasi HTTP.
Misalnya, header Cache-Control
berikut membuat konten terkait dapat dibaca secara publik dan dapat di-cache dengan masa berlaku cache 72 jam (259.200 detik):
Cache-Control: public, max-age=259200
Untuk memaksimalkan penyimpanan dalam cache, ikuti panduan di
Ringkasan penyimpanan dalam cache. Ingat bahwa nilai max-age
dan s-maxage
di kolom metadata Cache-Control
bekerja sama dengan cara berikut:
- Nilai
max-age
dans-maxage
diukur dalam detik. - Nilai
s-maxage
hanya berlaku untuk cache bersama, bukan cache browser. - Nilai
max-age
berlaku untuk semua cache kecuali jikas-maxage
menggantinya.
Untuk konten yang jarang berubah atau harus berubah bersama konten terkait, sebaiknya gunakan waktu habis masa berlaku yang lama bersama dengan URL berversi.
Menggunakan URL berversi untuk memperbarui konten
Membuat versi konten akan menayangkan versi konten yang sama, yang secara efektif menghapusnya dengan menampilkan konten baru kepada pengguna sebelum masa berlaku entri cache berakhir. Karena versi gratis, sebaiknya gunakan versi sebagai pendekatan default untuk memperbarui konten yang dapat di-cache.
Untuk membuat versi konten, tambahkan parameter ke URL, seperti nomor versi. Ada berbagai cara untuk menyertakan parameter dalam URL, seperti:
Tambahkan string kueri:
file.ext?v=100
.Untuk bucket backend, string kueri apa pun yang digunakan untuk pembuatan versi harus ditentukan dalam konfigurasi untuk bucket backend. Untuk informasi selengkapnya, lihat Daftar penyertaan string kueri untuk kunci cache Cloud Storage.
Ubah nama file:
file.1.0.0.ext
ataufile_v100.ext
.Ubah jalur:
/v100/file.ext
.
Saat menambahkan parameter, Anda akan mengubah nama file dan URL. Perubahan ini memaksa cache mengabaikan entri cache yang ada.
Gunakan pembatalan validasi seperlunya untuk menghapus konten
Invalidasi menghapus konten dari server cache terdistribusi Cloud CDN sebelum masa berlaku entri cache berakhir. Pembatalan validasi pada akhirnya konsisten.
Sebaiknya gunakan pembatalan validasi seperlunya dan hanya sebagai upaya terakhir. Misalnya, pembatalan validasi berguna saat Anda harus menghapus konten karena alasan hukum atau karena upload yang tidak disengaja. Jika tidak, sebaiknya Anda menggunakan pembuatan versi jika memungkinkan atau menunggu hingga konten berakhir masa berlakunya secara normal. Server cache Cloud CDN secara rutin menghapus konten yang jarang diakses untuk memberi ruang bagi konten baru. Konten yang tidak diakses selama 30 hari akan dihapus tanpa syarat.
Invalidasi cache dibatasi kapasitasnya.
Untuk mempelajari pembatalan validasi lebih lanjut, lihat Ringkasan pembatalan validasi cache.
Mengoptimalkan konsistensi file yang diupload
Praktik yang direkomendasikan berikut membantu mengoptimalkan konsistensi upload file.
Menghindari pembaruan file yang ada
Upload versi baru, bukan memperbarui file yang ada.
Untuk file baru, gunakan nama unik yang dapat menyertakan nomor versi atau tanggal.
Menambahkan nomor versi (misalnya, file_v2.css
) atau tanggal (misalnya,
file_20230806.js
) ke nama file akan membantu memastikan bahwa Cloud CDN
mengambil versi yang benar dan telah diperbarui. Menambahkan parameter ke URL file (misalnya,
file.css?v=2
) untuk memaksa versi baru diambil tidak direkomendasikan karena
pendekatan ini tidak mengatasi risiko meng-cache update file origin nonatomic, yang memungkinkan file sebagian atau tidak lengkap masih dapat di-cache.
Anda harus mengupload dependensi versi baru sebelum mengupload file yang mereferensikannya. Praktik ini membantu memastikan bahwa semua referensi mengarah ke file yang lengkap dan diperbarui, sehingga mengurangi risiko penayangan file yang diperbarui sebagian atau terpotong.
Melakukan update atomik pada file
Jika perlu memperbarui file yang ada, lakukan secara atomik.
Jika file diakses dan di-cache sebelum upload selesai, file tersebut mungkin
di-cache sebagai file yang tidak lengkap atau terpotong. Misalnya, file, seperti
/index.html
, tidak boleh memiliki nama unik, tetapi dapat mengarah ke file lain yang memiliki
nama unik.
Mengupload file dengan nama targetnya dapat menyebabkan file yang tidak lengkap disimpan dalam cache saat diakses selama upload. Sebagai gantinya, upload file dengan nama sementara dan ganti namanya menjadi nama target hanya setelah upload selesai. Praktik ini membantu memastikan bahwa file tersedia sepenuhnya dan langsung saat dirujuk.
Saat file yang ada diperbarui, cache rentang byte
dapat menyebabkan Cloud CDN menyimpan rentang file sebelumnya setelah file
baru diupload. Jika Cloud CDN telah meng-cache rentang file sebelumnya,
permintaan untuk bagian yang tidak ada dapat menyebabkan respons sebagian. Hal ini terjadi
karena Cloud CDN mendeteksi bahwa file asal telah berubah
(karena etag
atau last-modified
berubah), menghapus konten yang tidak relevan,
memutuskan koneksi download yang sedang berlangsung, dan menghasilkan error, yang meminta
klien untuk mencoba lagi. Untuk mengurangi masalah ini, berikan
pembatalan validasi untuk file yang di-cache dalam rentang byte yang sedang diperbarui.
Mengoptimalkan Monitoring dan Logging
Praktik yang direkomendasikan berikut membantu mengoptimalkan Monitoring dan Logging.
Pastikan logging diaktifkan untuk Cloud CDN
Praktik terbaik untuk mengelola Cloud CDN adalah memastikan logging diaktifkan untuk semua backend yang mengaktifkan Cloud CDN.
Menggunakan dasbor pemantauan kustom untuk Cloud CDN
Untuk memastikan keandalan dan performa yang lebih baik, praktik terbaiknya adalah meninjau metrik pemantauan yang terkait dengan Cloud CDN secara rutin. Tempat yang tepat untuk memulai adalah dengan dasbor pemantauan kustom Cloud CDN.
Meninjau pengujian performa pihak ketiga
Tinjau laporan dari penyedia pihak ketiga, seperti laporan ketersediaan, latensi, dan throughput yang disediakan oleh Citrix Radar.