Memecahkan masalah Cloud CDN

Pelajari langkah-langkah pemecahan masalah yang mungkin berguna jika Anda mengalami masalah berikut saat menggunakan Cloud CDN.

Jika masalah yang Anda hadapi terkait dengan backend eksternal, baca juga bagian Memecahkan masalah backend eksternal dan NEG internet.

Masalah dan solusi umum

Bagian ini menjelaskan beberapa masalah umum dan solusinya.

Respons tidak di-cache

Jika respons tidak di-cache, periksa terlebih dahulu apakah Cloud CDN diaktifkan untuk layanan backend atau bucket backend Anda. Saat Anda mengaktifkan Cloud CDN, mungkin perlu waktu beberapa menit sebelum respons mulai di-cache.

Cloud CDN hanya akan menyimpan respons dengan konten yang dapat di-cache. Informasi ini disampaikan di header respons HTTP, bersama dengan konfigurasi backend. Saat mengonfigurasi header respons kustom dengan cdn_cache_status, Anda dapat mengamati status cache di log Cloud CDN dan menentukan apakah respons disajikan sebagai akibat dari cache tidak ditemukan atau bukan.

Jika respons untuk suatu URL tidak di-cache, periksa header yang ditampilkan untuk URL tersebut, dan bagaimana kemampuan cache dikonfigurasi untuk backend Anda.

Ada beberapa cara untuk memeriksa header respons:

Contoh berikut menunjukkan penggunaan curl untuk memeriksa header respons HTTP untuk http://example.com/style.css:

curl -s -D - -o /dev/null http://example.com/style.css

Output:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:00 GMT
Content-Type: text/css
Content-Length: 1977
Via: 1.1 google

Membandingkan header ini dengan persyaratan konten yang dapat di-cache akan menunjukkan bahwa respons tidak memiliki header Cache-Control yang diperlukan (dengan asumsi bahwa mode cache disetel ke USE_ORIGIN_HEADERS).

Metode untuk menyetel header bergantung pada jenis server asal. Jika Anda menjalankan server web di Compute Engine, baca dokumentasi software server web untuk mengetahui detail tentang cara mengonfigurasi header respons. Untuk Cloud Storage, menandai objek sebagai dibagikan secara publik akan menyebabkan pengiriman header yang sesuai.

Setelah mengonfigurasi ulang server asal untuk menambahkan header yang diperlukan, Anda dapat menggunakan curl lagi untuk memeriksa hasilnya:

curl -s -D - -o /dev/null http://example.com/style.css

Output:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

Output:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:31 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

Output:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
Age: 2

Respons terakhir dalam contoh ini menyertakan header Age. Cloud CDN akan menambahkan header Age ke respons yang disajikannya dari cache. Di sini, header menunjukkan bahwa respons berhasil disajikan dari cache menggunakan entri cache yang dibuat dua detik yang lalu.

Selain itu, jika ETag diaktifkan pada instance backend, Cloud CDN akan mengandalkan ETag untuk mengonfirmasi keaktualan objek. Jika instance backend menyalurkan ETag yang berbeda pada objek yang sama, Cloud CDN akan menghitung ketidakcocokan sebagai cache tidak ditemukan lalu memuat ulang objek. Untuk mencegah hal ini, instance backend harus menyajikan ETag yang sama atau ETag harus dinonaktifkan.

Untuk memeriksanya, jalankan curl berulang kali dan amati perubahan pada nilai ETag:

curl -s -D - -o /dev/null http://example.com/image.png

Output:

HTTP/2 200
date: Fri, 20 Mar 2020 15:02:30 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:20:59 GMT
etag: "10f-5a0f1256f1402"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:02:30 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

curl -s -D - -o /dev/null http://example.com/image.png

Output:

HTTP/2 200
date: Fri, 20 Mar 2020 15:03:11 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:18:31 GMT
etag: "10f-5a0f11ca09b7a"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:03:11 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

Objek Cloud Storage tidak dapat diakses

Untuk memberikan akses ke objek di Cloud Storage, Anda harus mengonfigurasi URL bertanda tangan atau memberikan akses publik ke bucket dan semua objeknya untuk allUsers.

Jika Anda memutuskan untuk memberikan akses allUsers, Anda dapat memverifikasi akses tingkat objek sebagai berikut.

Konsol

  1. Di konsol Google Cloud , buka browser Cloud Storage.

    Buka browser Penyimpanan

  2. Klik bucket untuk melihat halaman Detail bucket.

  3. Di kolom Public access, tahan kursor di atas ikon tanda seru, lalu klik Edit access.

    Untuk tiap objek dalam bucket, pastikan izin berikut ditetapkan:

    • Entity: User
    • Name: allUsers
    • Access: Reader

Untuk mempelajari lebih lanjut kontrol akses untuk Cloud Storage, baca dokumentasi Identity and Access Management (IAM) untuk Cloud Storage.

Untuk mempelajari lebih lanjut URL bertanda tangan, baca bagian Menggunakan URL bertanda tangan.

Jika objek dapat diakses tetapi tidak di-cache, baca bagian Respons tidak di-cache.

Konten pribadi di-cache, atau konten yang di-cache salah

Jika Anda mengetahui alasan server asal menyajikan konten pribadi atau konten yang salah dan Anda dapat memperbaiki masalah tersebut, Anda dapat membatalkan validasi cache Cloud CDN menggunakan proses berikut:

  1. Pastikan server asal tidak lagi menampilkan konten pribadi atau konten yang salah.
  2. Minta invalidasi cache untuk menginstruksikan Cloud CDN agar berhenti menyajikan konten yang di-cache tersebut.

Untuk mengetahui informasi selengkapnya, baca Ringkasan invalidasi cache.

Cloud CDN hanya akan menyimpan respons dengan konten yang dapat di-cache dan akan menyajikan respons dari cache hanya sampai waktu habis masa berlaku yang ditentukan dalam respons. Jika Anda tidak mengetahui alasan konten di-cache atau tidak dapat memperbaiki masalah dengan cepat, sebaiknya nonaktifkan Cloud CDN hingga Anda dapat memahami dan memperbaiki masalah tersebut, lalu aktifkan kembali. Untuk mengetahui informasi selengkapnya tentang konten yang di-cache dan durasinya, baca Ringkasan caching.

Rasio cache ditemukan rendah

Untuk performa dan skalabilitas, penting untuk mengoptimalkan rasio cache ditemukan. Jika Anda mengalami rasio cache ditemukan yang lebih rendah daripada yang diharapkan, pastikan Anda mengikuti praktik terbaik untuk mengoptimalkan rasio cache ditemukan.

Gunakan tabel berikut untuk memahami beberapa kemungkinan alasan rasio cache ditemukan yang rendah dan potensi perbaikannya.

Alasan Komentar Perbaikan
Konten Anda tidak dapat di-cache. Respons yang dapat di-cache adalah respons HTTP yang dapat disimpan oleh Cloud CDN. Pastikan konten Anda dapat di-cache.
Mode cache tidak optimal untuk aplikasi Anda. Cloud CDN memiliki beberapa mode cache. Jika Anda tidak menggunakan header kontrol cache untuk mengontrol perilaku caching, praktik terbaik yang direkomendasikan adalah membiarkan Cloud CDN menyimpan cache semua konten statis.
Jumlah traffic sedikit. Selama pengujian dan eksperimen, jumlah traffic yang Anda hasilkan cenderung rendah. Google memiliki cache terdistribusi global, dan permintaan dari berbagai lokasi geografis akan menuju ke lokasi frontend Google yang berbeda. Di tiap lokasi frontend, Google mungkin memiliki beberapa instance cache yang terpisah.
  • Pastikan volume traffic yang dikirim ke Google cukup untuk mengisi semua cache yang relevan.
  • Selama pengujian, pastikan untuk men-shard traffic menurut URL sehingga semua traffic untuk tiap kumpulan permintaan akan masuk ke Google. Jangan meng-shard tiap permintaan secara acak ke penyedia CDN yang berbeda.
Respons untuk URL tertentu tidak di-cache. Cloud CDN menggabungkan URI permintaan lengkap ke dalam kunci cachenya, sehingga http://example.com/cat.jpg?color=orange dan http://example.com/cat.jpg?color=gray memiliki entri cache terpisah. Selalu gunakan satu URL untuk resource tertentu.

Jika Anda perlu meneruskan parameter ke JavaScript yang berjalan di halaman yang dapat di-cache, pertimbangkan untuk menggunakan ID fragmen, bukan string kueri.
Cache di-shard secara tidak perlu disebabkan kolom header Vary. Kolom header Vary dalam respons menjelaskan bagian mana dari pesan permintaan (selain metode, kolom header Host, dan target permintaan) yang dapat memengaruhi proses server asal untuk memilih dan merepresentasikan respons. Sebagai contoh, Anda mungkin ingin menggunakan header Vary: Accept-Encoding jika Anda menyajikan konten yang berbeda kepada klien yang dapat menangani respons terkompresi dan yang tidak dapat. Gunakan header respons Vary hanya jika diperlukan.
Anda tidak menggunakan kunci cache kustom. Secara default, Cloud CDN akan menggunakan URL permintaan lengkap untuk membuat kunci cache. Anda dapat menyesuaikan kunci cache untuk menyertakan atau menghapus kombinasi protokol, host, dan string kueri. Misalnya, jika dua domain menggunakan konten statis yang sama, Anda dapat membuat kunci cache kustom yang menghilangkan kolom host. Gunakan kunci cache kustom, jika diperlukan.

Ada beberapa pengisian cache untuk konten yang sama

Secara umum, Anda dapat mengurangi jumlah pengisian cache dengan meningkatkan waktu habis masa berlaku respons yang dapat di-cache. Dengan hal-hal lainnya tetap sama, Anda akan melihat lebih sedikit pengisian cache untuk respons dengan Cache-Control: public, max-age=86400 daripada respons dengan Cache-Control: public, max-age=1.

Untuk mengetahui informasi selengkapnya tentang waktu habis masa berlaku, baca bagian Waktu habis masa berlaku dan permintaan validasi. Untuk mengetahui informasi tentang cara mengonfigurasi header respons yang sesuai, baca dokumentasi untuk software server web Anda.

Cloud CDN mengoperasikan banyak cache di seluruh dunia, dan entri cache lama secara rutin akan dikeluarkan untuk memberi ruang bagi konten baru. Akibatnya, pengisian cache beberapa kali per resource adalah bagian dari operasi normal.

Kompresi tidak berfungsi

Cloud CDN menawarkan kompresi dinamis untuk server asal yang tidak dapat mengompresi responsnya. Jika memungkinkan, sebaiknya gunakan kompresi di server asal karena akan mengurangi biaya pengisian cache.

Jika respons yang disajikan oleh Cloud CDN tidak dikompresi, tetapi seharusnya dikompresi, periksa apakah software server web yang berjalan di instance Anda dikonfigurasi untuk mengompresi respons. Secara default, beberapa software server web akan otomatis menonaktifkan kompresi untuk permintaan yang menyertakan header Via. Kehadiran header Via menunjukkan bahwa permintaan diteruskan oleh proxy. Proxy HTTP seperti Load Balancer Aplikasi eksternal menambahkan header Via ke tiap permintaan seperti yang diwajibkan oleh spesifikasi HTTP. Untuk mengaktifkan kompresi, Anda mungkin harus mengganti konfigurasi default server web untuk memberi tahu server agar mengompresi respons meskipun permintaan memiliki header Via.

Jika Anda menggunakan software server web nginx, ubah file konfigurasi nginx.conf untuk mengaktifkan kompresi. Lokasi file ini bergantung pada tempat nginx diinstal. Di banyak distribusi Linux, file disimpan di /etc/nginx/nginx.conf.

Agar kompresi nginx dapat berfungsi dengan Load Balancer Aplikasi eksternal, tambahkan dua baris berikut ke bagian http nginx.conf:

gzip_proxied any;
gzip_vary on;

  • Baris pertama akan mengaktifkan kompresi bahkan untuk permintaan yang diteruskan oleh proxy seperti Load Balancer Aplikasi eksternal.

  • Baris kedua akan menambahkan header Vary: Accept-Encoding ke respons. Vary: Accept-Encoding akan memberi tahu proxy caching seperti Cloud CDN bahwa mereka harus mempertahankan entri cache terpisah untuk varian terkompresi dan tidak terkompresi dari resource yang dapat dikompresi.

Setelah mengubah nginx.conf, Anda harus memulai ulang nginx sebelum menggunakan konfigurasi baru. Di banyak distribusi Linux, Anda dapat memulai ulang nginx dengan menjalankan sudo service nginx restart atau /etc/init.d/nginx restart.

Respons dihentikan dengan error byte_range_caching_aborted

Saat merakit respons dari beberapa permintaan rentang byte, Cloud CDN akan memeriksa apakah rentang tersebut berasal dari versi resource yang sama atau bukan dengan membandingkan header respons ETag dan Last-Modified. Jika Cloud CDN menemukan bahwa nilai salah satu header tidak konsisten dengan rentang yang telah disajikan ke klien, Cloud CDN akan membatalkan respons.

Jika Anda melihat respons yang dihentikan secara tidak terduga, entri log Cloud Logging dengan statusDetails byte_range_caching_aborted, atau instance Anda menampilkan respons 412 Precondition Failed, pastikan software server web yang berjalan di semua instance virtual machine (VM) Anda menampilkan nilai ETag dan Last-Modified yang sama untuk resource tertentu.

Saat menyajikan file dari disk, software server web biasanya akan mendapatkan nilai ETag dan Last-Modified dari waktu modifikasi file. Dalam hal ini, Anda dapat memastikan bahwa instance VM Anda melaporkan nilai yang konsisten menggunakan image yang sama untuk semua instance. Untuk mengetahui detail tentang cara software server web Anda menentukan nilai ETag dan Last-Modified, baca dokumentasi software server web Anda.

Memecahkan masalah cookie bertanda tangan

Masalah berikut dapat terjadi saat Anda menggunakan cookie bertanda tangan.

Encoding

Saat membuat tanda tangan, permintaan akan ditolak secara tidak terduga karena tanda tangan tidak cocok.

Saat mengenkode nilai URL dan Signature, pastikan Anda menggunakan varian base64 yang aman untuk URL. Base64 standar akan gagal jika karakter yang dihasilkan tidak aman untuk URL. Padding diperbolehkan.

Penandatanganan

Permintaan Anda ditolak oleh Cloud CDN.

  • Pastikan Anda menggunakan HMAC-SHA-1 sebagai algoritma penandatanganan, dan bukan varian HMAC lainnya.

  • Pastikan parameter KeyName (peka huruf besar/kecil) cocok dengan nama kunci yang valid untuk layanan backend atau bucket backend yang digunakan oleh Cloud CDN.

  • Jangan menandatangani parameter kueri saat membuat dan menandatangani URLPrefix. Pastikan URLPrefix hanya berisi komponen skema, host, dan (sebagian) jalur URL.

  • Pastikan blok tanda tangan—URLPrefix, Expires, KeyName, dan Signature itu sendiri—adalah bagian terakhir yang dibatasi : dari cookie.

  • Pastikan URLPrefix, Expires, KeyName, dan Signature terjadi dalam urutan tersebut.

  • Jangan menyertakan karakter tanda bintang (*) di akhir URLPrefix dalam cookie bertanda tangan.

Cookie

  • Browser biasanya akan membatasi cookie hingga 4 KB per domain, dengan batas total 50 cookie per domain. Perhatikan cookie lain yang Anda keluarkan dan wajib dikirim oleh klien Anda karena banyak server web juga memiliki batas header permintaan maksimum.

  • Pastikan Anda menggunakan karakter titik dua (:), poin kode Unicode U+003A, sebagai pembatas untuk parameter bernama dalam cookie bertanda tangan, dan bukan karakter ampersand (&).

  • Pastikan stempel waktu Expires pada cookie yang Anda keluarkan tidak terlalu singkat. Periode validitas kurang dari satu hingga dua menit mungkin rentan terhadap masalah perbedaan waktu antara aplikasi penerbit dan infrastruktur Cloud CDN.

  • Pastikan Anda tidak menyetel beberapa cookie untuk Domain dan Path yang sama dengan nilai yang berbeda. Tetapkan satu cookie per pengguna dengan nilai awalan URL yang mencakup semua konten yang perlu diakses pengguna.

Pesan error

Bagian ini memberikan informasi tentang beberapa pesan error umum dan cara menyelesaikannya.

Error invalidasi cache

Kode error Catatan
Invalid value for field 'resource.path'

Nilai jalur memiliki format yang tidak valid. Jalur harus diawali dengan /, tidak boleh berisi ? atau #, dan hanya boleh memiliki satu *, yang harus berupa karakter akhir setelah /.

Jalur tidak boleh lebih dari 1.024 karakter. Jika Anda menerima error ini, periksa nilai jalur dan perbaiki kesalahan format.

Error ini hanya membahas format jalur. Jalur yang memiliki format valid, tetapi tidak ada, akan tetap dianggap valid.
Rate Limit Exceeded Cloud CDN akan membatasi kecepatan operasi invalidasi cache yang dapat dilakukan. Hanya satu invalidasi per menit yang diizinkan. Namun, tiap operasi dapat menentukan pola jalur yang cocok dengan sejumlah objek.

Masalah umum

  • Invalidasi cache dibatasi kecepatannya hanya satu invalidasi per peta URL per menit.

    Penyelesaian: Tunggu minimal satu menit sebelum mencoba melakukan invalidasi peta URL lain.

    Untuk mengetahui informasi selengkapnya tentang pembatasan kapasitas invalidasi cache, baca bagian Batasan.