Ringkasan origin

Media CDN memungkinkan Anda mengambil konten dari infrastruktur asal, baik konten dihosting dalam Google Cloud, di cloud lain, atau di lokal.

Setiap konfigurasi dapat memiliki satu atau beberapa asal yang terkait. Konfigurasi origin memberi tahu Media CDN cara terhubung ke infrastruktur Anda, kapan dan bagaimana melakukan failover, mencoba lagi, dan waktu tunggu, serta protokol apa yang akan digunakan saat terhubung.

Origin memiliki fitur berikut:

• Asal dapat ditentukan per host dan per rute, yang memungkinkan satu resource EdgeCacheService dipetakan ke beberapa asal yang berisi, misalnya, manifes, segmen video, dan konten statis lainnya.
• Origin dapat dijangkau melalui HTTP/2, HTTPS, dan HTTP/1.1 yang tidak terenkripsi.
• Anda dapat mengonfigurasi aturan firewall untuk mengizinkan hanya alamat IP Google tertentu sehingga hanya Media CDN yang dapat mengakses origin Anda.
• Perilaku percobaan ulang dan failover dikonfigurasi per asal, dan dapat memungkinkan layanan melakukan failover pada error berat (seperti kegagalan konektivitas) atau mencoba lagi berdasarkan respons HTTP 404 Not Found atau HTTP 429 Too Many Requests.
• Resource pribadi di dalam Google Cloud atau lokal dapat dijangkau dengan mengonfigurasi Load Balancer Aplikasi eksternal sebagai origin di belakang Media CDN.
• Perilaku mengikuti pengalihan dikonfigurasi per origin. Anda dapat mengaktifkan Media CDN untuk mengikuti pengalihan ke server asal lain.

Persyaratan asal

Untuk mengizinkan Media CDN menyimpan respons origin yang lebih besar dari 1 MiB, origin harus menyertakan hal berikut dalam header respons untuk permintaan HEAD dan GET, kecuali jika ditentukan lain:

• Header respons HTTP Last-Modified atau ETag (validator).
• Header HTTP Date yang valid.
• Header Content-Length yang valid.
• Header respons Content-Range, sebagai respons terhadap permintaan Range GET. Header Content-Range harus memiliki nilai yang valid dalam bentuk bytes x-y/z (dengan z adalah ukuran objek).

Protokol asal default adalah HTTP/2. Jika origin Anda hanya mendukung HTTP/1.1, Anda dapat menetapkan kolom protokol secara eksplisit untuk setiap origin.

Perlindungan asal

Media CDN menyediakan infrastruktur edge bertingkat yang komprehensif yang dirancang untuk secara aktif meminimalkan pengisian cache jika memungkinkan.

Ada tiga lapisan utama infrastruktur caching:

1. Cache edge dalam, yang melayani sebagian besar traffic dan off-load dalam jaringan penyedia layanan.
2. Edge peering Google, yang terhubung ke ribuan ISP dan berfungsi sebagai cache tingkat menengah untuk cache edge, dan untuk kasus ketika cache tersebut tidak ada dalam ISP tertentu, cache yang terlihat oleh pengguna.
3. Cache long-tail dalam jaringan Google yang diisi oleh cache hilir lainnya dari sebelum origin. Cache ini mendukung fan-in yang signifikan, memiliki kapasitas penyimpanan cache yang besar, dan bertindak sebagai perisai asal.

Ringkasan topologi ini ditampilkan di sini:

Media CDN menyediakan perlindungan origin secara default menggunakan serangkaian lokasi global utama yang terbatas. Perlindungan asal default beroperasi berdasarkan lokasi pengguna akhir, bukan asal. Cara ini berfungsi dengan baik dan memberikan manfaat offload yang kuat saat pengguna akhir dan server asal berada di region yang sama dan saat server asal global berada di beberapa region.

Perisai fleksibel

Dalam skenario saat asal Anda terpusat di satu wilayah, tetapi pengguna Anda tersebar secara global, perilaku perisai asal default, yang didasarkan pada lokasi pengguna, mungkin tidak optimal dengan cara berikut:

• Meningkatkan latensi untuk cache tidak ditemukan saat lokasi perisai default berada jauh secara geografis dari asal terpusat Anda
• Mengurangi pelepasan asal dengan menyebarkan permintaan pengisian cache di beberapa lokasi perisai default global, bukan memusatkannya

Perlindungan fleksibel membantu Anda mengatasi batasan ini dengan mengonfigurasi satu region geografis tertentu untuk perlindungan asal, yang biasanya dipilih agar dekat dengan asal terpusat Anda. Perlindungan fleksibel kemudian merutekan semua permintaan pengisian cache melalui cache perisai yang berada di atau dekat dengan region yang dikonfigurasi. Hal ini menggabungkan beban ke asal Anda melalui cache yang berfokus pada regional tersebut.

Dengan mengonfigurasi region perlindungan fleksibel di region geografis yang sama dengan origin terpusat, Anda dapat mengoptimalkan hal berikut:

• Rasio cache ditemukan di lapisan perisai
• Offload asal
• Latensi untuk cache tidak ditemukan dan konten yang tidak dapat di-cache
• Stabilitas performa

Perlindungan fleksibel kompatibel dengan jenis origin apa pun yang dikonfigurasi di Media CDN.

Meminta penyusutan

Penciutan permintaan secara aktif menciutkan beberapa permintaan pengisian cache yang didorong pengguna untuk kunci cache yang sama menjadi satu permintaan asal, per node tepi.

Semua lapisan caching mendukung penyusutan permintaan (atau penggabungan) untuk lebih mengurangi beban origin. Berdasarkan beban kerja dunia nyata yang diamati dalam skala besar:

• > 95% pengisian cache menggunakan node cache long-tail khusus dalam region, untuk mengurangi biaya dan latensi pengisian cache.
• Pengisian cache antara origin dan infrastruktur edge Google sendiri sepenuhnya dilakukan melalui jaringan backbone pribadi global Google, yang mengurangi latensi pengisian cache dan meningkatkan keandalan—keduanya merupakan manfaat aktif untuk beban kerja live streaming.
• Cache saling mengisi jika menguntungkan, sehingga semakin menurunkan rasio pengisian cache.
• Media CDN memiliki kapasitas penyimpanan yang signifikan di seluruh cache, yang meminimalkan rasio penghapusan bahkan untuk konten long-tail yang kurang populer.

Pelanggan mungkin melihat rasio pelepasan yang berbeda, bergantung pada konfigurasi cache, beban pengguna, beban kerja (seperti live versus on-demand), distribusi pengguna, dan seberapa banyak konten long-tail (ukuran korpus total) yang mereka sajikan kepada pengguna di seluruh wilayah.

Jika digabungkan dengan perlindungan origin, penggabungan permintaan akan semakin mengurangi beban origin dan kebutuhan bandwidth keluar, serta merupakan perilaku default untuk Media CDN.

Permintaan yang diciutkan mencatat permintaan yang ditampilkan kepada klien dan permintaan pengisian cache (yang diciutkan). Pemimpin sesi yang diciutkan digunakan untuk membuat permintaan pengisian asal, yang berarti bahwa asal melihat header (termasuk User-Agent) hanya dari klien tersebut.

Permintaan yang tidak memiliki kunci cache yang sama tidak dapat diciutkan.

Konektivitas origin

Bagian berikut menjelaskan cara Media CDN terhubung ke origin, cara permintaan HTTP dibuat, dan cara Anda dapat mengautentikasi permintaan.

Asal dan protokol yang didukung

Media CDN secara langsung mendukung endpoint HTTP yang dapat dijangkau secara publik sebagai origin, termasuk:

• Bucket Cloud Storage, termasuk bucket pribadi melalui akun layanan Identity and Access Management
• Load Balancer Aplikasi Eksternal
• Bucket yang kompatibel dengan Amazon S3, termasuk bucket pribadi yang menggunakan AWS Signature Version 4
• Penyimpanan objek yang tersedia secara publik lainnya, seperti Azure Blob Storage
• Server web yang tersedia secara publik, seperti VM publik atau host lokal

Konektivitas ke origin dilakukan melalui tunnel yang aman dan jaringan backbone global Google.

Tabel berikut menjelaskan protokol asal yang didukung.

Media CDN menggunakan HTTP/2 (h2) untuk terhubung ke origin secara default. HTTP/2 dan HTTPS memerlukan sertifikat TLS (SSL) yang valid dan dipercaya secara publik. Sertifikat yang valid adalah sertifikat yang belum habis masa berlakunya, ditandatangani oleh Otoritas Sertifikat publik, dan memiliki Nama Alternatif Subjek yang cocok dengan hostname yang dikirim ke origin.

Catatan:

• Jika origin Anda tidak mendukung HTTP/2, Anda dapat secara eksplisit menyetel protokol (berdasarkan per-origin) ke HTTP (HTTP/1.1) atau HTTPS (HTTP/1.1 melalui TLS).
• Saat mengonfigurasi HTTPS atau HTTP/1.1 sebagai protokol origin, Media CDN tidak menegosiasikan protokol alternatif (seperti HTTP/2). Demikian pula, saat mengonfigurasi HTTP/2, koneksi tidak akan kembali ke HTTP/1.1, agar perilaku konektivitas asal menjadi jelas.
• CDN Media otomatis menggunakan port yang benar berdasarkan protokol: port 80 untuk HTTP atau port 443 untuk HTTPS dan HTTP/2.

Header permintaan asal

Saat terhubung ke origin, Media CDN menggunakan header Host dari permintaan klien secara default.

Tabel berikut mendokumentasikan apa yang dilihat origin dalam permintaan masuk di berbagai skenario konfigurasi:

Asal utama dan asal failover melihat header host yang sama jika keduanya berbagi konfigurasi routeRule atau hostRewrite yang sama.

Setelan hostRewrite diabaikan saat menggunakan bucket Cloud Storage sebagai asal karena nilai header host alternatif tidak didukung oleh bucket Cloud Storage. Header host otomatis ditetapkan berdasarkan nama bucket.

Nilai TLS SNI (Server Name Indication) dalam permintaan (untuk permintaan HTTP/3, HTTP/2, dan HTTPS) ditetapkan ke nilai yang sama dengan header host yang dikirim ke origin.

Untuk mengetahui informasi tentang cara menulis ulang header host untuk konfigurasi per rute, lihat Mengonfigurasi rute layanan. Untuk mengetahui informasi tentang cara menyetel tindakan penggantian per-origin, lihat Pengalihan jika terjadi kegagalan origin tanpa mengikuti pengalihan.

Mengizinkan origin menerima traffic dari Media CDN

Untuk mengurangi risiko akses tidak sah ke konten Anda, gunakan daftar yang diizinkan IP di origin untuk memblokir akses ke semua alamat IP kecuali rentang alamat IP tertentu yang digunakan Google untuk mengirim permintaan ke origin eksternal. Dengan begitu, hanya Media CDN yang dapat terhubung ke server asal Anda.

Tabel berikut merangkum rentang alamat IP sumber yang diperlukan untuk aturan firewall:

Gunakan URL berikut untuk mengakses file JSON yang berisi rentang alamat IP yang ditetapkan Google yang telah diupdate.

https://www.gstatic.com/ipranges/mediacdn.json

Failover dan waktu tunggu

Bagian berikut menjelaskan opsi konfigurasi ini:

• Waktu tunggu: Tentukan berapa lama Media CDN menunggu untuk terhubung ke origin Anda atau untuk merespons permintaan.
• Coba lagi: Tentukan apakah Media CDN mencoba lagi permintaan HTTP origin ke origin Anda, dan dalam kondisi apa.
• Failover: Tentukan apakah Media CDN mencoba terhubung ke origin failover jika origin pertama tidak tersedia atau menampilkan kode status tertentu.

Waktu tunggu asal

Dengan waktu tunggu, Anda dapat mengonfigurasi kapan perilaku percobaan ulang dan failover asal dipicu, serta kapan failover klien berikutnya dapat dipicu.

Berikut ini menjelaskan waktu tunggu yang dapat dikonfigurasi yang didukung Media CDN:

• connectTimeout dan maxAttemptsTimeout membatasi waktu yang dibutuhkan Media CDN untuk menemukan respons yang dapat digunakan.

  Kedua waktu tunggu mencakup waktu yang diperlukan asal untuk menampilkan header dan untuk menentukan apakah akan menggunakan failover atau pengalihan. connectTimeout berlaku secara independen untuk setiap upaya asal, sedangkan maxAttemptsTimeout mencakup waktu yang diperlukan untuk terhubung di semua upaya asal, termasuk failover dan pengalihan. Mengikuti pengalihan dihitung sebagai upaya tambahan untuk terhubung ke asal, dan dihitung dalam maxAttempts yang ditetapkan untuk asal yang dikonfigurasi.

  Saat Media CDN menemukan respons non-pengalihan, seperti dari origin pengalihan atau failover, nilai readTimeout dan responseTimeout akan berlaku. Origin yang dialihkan menggunakan nilai connectTimeout, readTimeout, dan responseTimeout yang dikonfigurasi untuk EdgeCacheOrigin yang mengalami pengalihan.

• responseTimeout dan readTimeout mengontrol durasi respons streaming dapat diperlukan. Setelah Media CDN menentukan bahwa Media CDN akan menggunakan respons upstream, connectTimeout maupun maxAttemptsTimeout tidak akan berpengaruh. Pada tahap ini, readTimeout dan responseTimeout akan berlaku.

Media CDN melakukan maksimal empat upaya origin di semua origin, terlepas dari maxAttempts yang ditetapkan oleh setiap EdgeCacheOrigin. Media CDN menggunakan nilai maxAttemptsTimeout dari EdgeCacheOrigin utama. Nilai waktu tunggu per percobaan (connectTimeout, readTimeout, dan responseTimeout) dikonfigurasi untuk EdgeCacheOrigin setiap percobaan.

Tabel berikut menjelaskan kolom waktu tunggu:

Perhatikan contoh berikut:

• Origin A mencocokkan permintaan ke "/segments/" dan memiliki nilai maxAttemptsTimeout 5s, nilai maxAttempts 1, dan nilai failover_origin Origin B. Nilai connectTimeout berada pada defaultnya, yaitu 5s. Jika Anda mencoba terhubung ke Origin A, dan gagal dalam waktu 1 detik karena sertifikat TLS tidak valid, Anda memiliki waktu ~4 detik untuk membuat koneksi yang berhasil ke Origin B.

• Origin C cocok dengan permintaan ke "/manifests/*, memiliki nilai maxAttemptsTimeout 10s, nilai maxAttempts 3, dan failover_origin tidak dikonfigurasi. Nilai connectTimeout berada pada nilai defaultnya, yaitu 5s. CDN Media berupaya terhubung ke Origin C hingga tiga kali, dengan waktu hingga 10 detik (batas maxAttemptsTimeout) untuk membuat koneksi yang berhasil.

Mencoba lagi permintaan origin

Media CDN mendukung percobaan ulang origin, sehingga permintaan yang tidak berhasil ke origin dapat dicoba ulang. Anda dapat menentukan berapa kali asal saat ini dapat dicoba ulang sebelum asal failover (jika dikonfigurasi) dicoba.

• Media CDN mencoba menjangkau origin utama hingga nilai maxAttempts yang dikonfigurasi, yang secara default adalah 1.
• Media CDN mencoba ulang koneksi origin hingga maksimum tiga kali sebelum gagal dan menampilkan error HTTP 502 Bad Gateway kepada pengguna. Hal ini mencakup koneksi asal failover, yang dihitung dalam batas tiga.
• Saat mengonfigurasi resource origin, Anda dapat mengonfigurasi origin utama menggunakan kolom originAddress, lalu failoverOrigin opsional. failoverOrigin mengarah ke resource asal lain.

retryConditions untuk setiap origin menentukan jenis kegagalan yang memicu percobaan ulang:

Jika Anda memerlukan pemeriksaan kondisi aktif, round-robin, atau pengarahan yang sadar beban di seluruh asal, Anda dapat mengonfigurasi Load Balancer Aplikasi eksternal sebagai asal utama.

Perilaku failover

Tabel berikut menjelaskan cara kerja failover, dan respons apa yang akan diamati klien:

Jika Media CDN menerima kode status yang cocok dengan retryConditions yang dikonfigurasi, seperti error HTTP 404 Not Found atau HTTP 429 Too Many Requests, dan permintaan origin coba lagi dan failover berikutnya terus gagal, error HTTP 502 Bad Gateway akan ditampilkan ke klien setelah upaya origin habis.

Praktik terbaik untuk failover asal

Saat mengonfigurasi beberapa asal untuk failover atau load balancing, pastikan konten media dan perilaku header Vary, ETag, dan Last-Modified Anda konsisten di antara asal Anda.

Sebagai praktik terbaik, konfigurasi pengalihan origin hanya untuk origin yang Anda percayai dan kontrol. Pastikan Anda memercayai setiap asal dalam rantai pengalihan karena setiap asal menghasilkan konten yang ditayangkan oleh EdgeCacheService Anda.

Langkah berikutnya

• Mengonfigurasi origin
• Menggunakan bucket pribadi yang kompatibel dengan Amazon S3 sebagai origin
• Mengonfigurasi rute layanan