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 lihat terkait dengan backend eksternal, lihat juga 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, pertama-tama periksa 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 meng-cache 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 miss.

Jika respons untuk URL tidak di-cache, periksa header mana yang ditampilkan untuk URL tersebut, dan cara konfigurasi kemampuan cache 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 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, lihat dokumentasi software server web untuk mengetahui detail tentang cara mengonfigurasi header respons. Untuk Cloud Storage, menandai objek sebagai dibagikan secara publik akan menyebabkan header yang sesuai dikirim.

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 menambahkan header Age ke respons yang disajikannya dari cache. Di sini, header menunjukkan bahwa respons berhasil disalurkan dari cache menggunakan entri cache yang dibuat dua detik yang lalu.

Selain itu, jika ETags diaktifkan pada instance backend, Cloud CDN mengandalkan ETag untuk mengonfirmasi keaktualan objek. Jika instance backend menayangkan ETag yang berbeda pada objek yang sama, Cloud CDN akan menghitung ketidakcocokan sebagai cache yang tidak ditemukan dan memuat ulang objek. Untuk mencegah hal ini, instance backend harus menayangkan 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 Storage

  2. Klik bucket untuk melihat halaman Detail bucket.

  3. Di kolom Akses publik, arahkan kursor ke ikon tanda seru, lalu klik Edit akses.

    Untuk setiap objek dalam bucket, pastikan izin berikut ditetapkan:

    • Entitas: Pengguna
    • Nama: allUsers
    • Akses: Pembaca

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

Untuk mempelajari lebih lanjut URL yang ditandatangani, lihat Menggunakan URL yang ditandatangani.

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

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

Jika Anda mengetahui alasan server asal menayangkan konten pribadi atau 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 salah.
  2. Minta invalidasi cache untuk menginstruksikan Cloud CDN agar berhenti menyajikan konten yang di-cache.

Untuk mengetahui informasi selengkapnya, lihat Ringkasan pembatalan validasi cache.

Cloud CDN hanya meng-cache respons dengan konten yang dapat di-cache dan menyajikan respons dari cache hanya hingga waktu habis masa berlaku yang ditentukan dalam respons. Jika Anda tidak tahu mengapa 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, lihat Ringkasan caching.

Rasio cache ditemukan rendah

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

Gunakan tabel berikut untuk memahami beberapa kemungkinan alasan rasio hit cache 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.
Ada sedikit traffic. 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 setiap 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 membagi traffic menurut URL sehingga semua traffic untuk setiap kumpulan permintaan masuk ke Google. Jangan membagi setiap 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 karena kolom header Vary. Kolom header Vary dalam respons menjelaskan bagian 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 menayangkan 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 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.

Beberapa pengisian cache ada untuk konten yang sama

Secara umum, Anda dapat mengurangi jumlah pengisian cache dengan meningkatkan waktu habis masa berlaku respons yang dapat di-cache. Dengan semua 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, lihat Waktu habis masa berlaku dan permintaan validasi. Untuk mengetahui informasi tentang cara mengonfigurasi header respons yang sesuai, lihat dokumentasi untuk software server web Anda.

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

Kompresi tidak berfungsi

Cloud CDN menawarkan kompresi dinamis untuk origin yang tidak dapat mengompresi responsnya. Jika memungkinkan, sebaiknya gunakan kompresi di origin 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 secara 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 setiap 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 mengaktifkan kompresi bahkan untuk permintaan yang diteruskan oleh proxy seperti Load Balancer Aplikasi eksternal.

  • Baris kedua menambahkan header Vary: Accept-Encoding ke respons. Vary: Accept-Encoding 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 dengan membandingkan header respons ETag dan Last-Modified. Jika Cloud CDN menemukan bahwa nilai salah satu header tidak konsisten dengan rentang yang telah disajikannya kepada 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 mendapatkan nilai ETag dan Last-Modified dari waktu modifikasi file. Dalam hal ini, Anda dapat memastikan bahwa instance VM Anda melaporkan nilai yang konsisten dengan menggunakan image yang sama untuk semua instance. Untuk mengetahui detail tentang cara software server web Anda menentukan nilai ETag dan Last-Modified, lihat 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 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 gagal jika karakter yang dihasilkan tidak aman untuk URL. Pengisihan 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 bahwa blok tanda tangan—URLPrefix, Expires, KeyName, dan Signature itu sendiri—adalah bagian yang dibatasi : terakhir dari cookie.

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

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

Cookie

  • Browser biasanya 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 (:), titik 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 pembatalan validasi 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 /.

Panjang jalur tidak boleh lebih dari 1024 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, tetap dianggap valid.
Rate Limit Exceeded Cloud CDN membatasi kecepatan operasi invalidasi cache yang dapat dilakukan. Anda dapat mengirimkan hingga 500 permintaan pembatalan per menit. Setiap operasi dapat menentukan pola jalur yang cocok dengan sejumlah objek.

Masalah umum

  • Invalidasi cache dibatasi kecepatan hingga satu invalidasi per peta URL per menit.

    Penyelesaian: Tunggu setidaknya satu menit sebelum mencoba membatalkan validasi peta URL lain.

    Untuk mengetahui informasi selengkapnya tentang pembatasan kapasitas pembatalan validasi cache, lihat Batasan.