Bonnes pratiques pour la diffusion de contenu

Cette page présente les meilleures pratiques pour optimiser et accélérer la diffusion de contenu avec Cloud CDN. Les sections sont organisées selon plusieurs domaines clés.

Cloud CDN utilise un équilibreur de charge d'application externe comme origine pour le contenu pouvant être mis en cache. Un équilibreur de charge d'application externe peut fournir aux utilisateurs, via une adresse IP globale, un assemblage de contenus statiques et créés dynamiquement provenant des types de backends suivants :

Grâce à l'intégration parfaite avec Google Cloud, vous disposez de plusieurs options pour déployer Cloud CDN et gérer le contenu. Aidez-vous des meilleures pratiques répertoriées ici pour planifier et affiner votre déploiement. Pour en savoir plus, consultez la section Configurer Cloud CDN.

Optimiser le taux d'accès au cache

Les pratiques suivantes sont recommandées pour optimiser le taux d'accès au cache.

Mettre en cache le contenu statique

Lorsque vous activez Cloud CDN, vous devez choisir le mode de cache approprié pour votre application afin d'améliorer les performances.

La méthode la plus flexible, qui est généralement privilégiée pour gérer les règles de cache, consiste à utiliser l'en-tête de contrôle du cache. Si vous ne maîtrisez pas l'utilisation d'en-têtes de contrôle de cache d'origine, la bonne pratique consiste à autoriser Cloud CDN à mettre en cache automatiquement le contenu statique.

Pour mettre automatiquement en cache les réponses statiques de votre origine, vous pouvez utiliser le paramètre --cache-mode=CACHE_ALL_STATIC (valeur par défaut). Ce paramètre permet à Cloud CDN de mettre en cache les types de contenu statique courants lorsque l'origine ne spécifie aucune directive de mise en cache dans les en-têtes de réponse. Assurez-vous que votre contenu correspond aux catégories décrites : sinon, il ne sera pas mis en cache.

Ne pas mettre en cache le contenu spécifique à l'utilisateur

Dans certains cas, les navigateurs peuvent mettre en cache le contenu spécifique à l'utilisateur. N'utilisez pas Cloud CDN pour mettre en cache le contenu spécifique à l'utilisateur.

Améliorer le taux d'accès au cache avec des clés de cache personnalisées

Pour améliorer les performances et l'évolutivité, il est important d'optimiser le taux d'accès au cache. Par défaut, Cloud CDN crée la clé de cache à partir de l'URL complète de la demande. Pour optimiser votre taux d'accès au cache, vous pouvez utiliser des clés de cache personnalisées afin que Cloud CDN ne segmente pas inutilement le cache.

Magasin de clés/valeurs Cloud CDN (cliquez pour agrandir).

Les clés de cache personnalisées vous permettent d'inclure ou d'omettre n'importe quelle combinaison de protocole, d'hôte et de chaîne de requête. Voici quelques exemples d'utilisation des clés de cache personnalisées :

  • Vous avez deux hôtes qui résolvent la même adresse IP et accèdent au même service. Dans cet exemple, l'ensemble du site Web est identique sur les deux hôtes. Par défaut, Cloud CDN met en cache deux copies, en raison de l'en-tête Host: différent dans les requêtes HTTP. Grâce à une clé de cache personnalisée, Cloud CDN peut ignorer la partie hôte de la requête et partager les entrées de cache.

  • Voyons un autre exemple plus spécifique, dans lequel deux sites Web sur des domaines différents utilisent le même logo. Le contenu du site Web est différent, mais vous utilisez le même logo d'entreprise sur les deux domaines et vous disposez d'un service de backend dédié qui contient le contenu partagé. Lorsque vous activez Cloud CDN et personnalisez les clés de cache pour le service de backend contenant le logo, décochez la case Hôte pour que le cache ignore le domaine, mais mette en cache le logo.

  • Un logo doit être mis en cache, qu'il soit affiché via HTTP ou HTTPS. Lorsque vous personnalisez les clés de cache pour le service de backend contenant le logo, décochez la case Protocole pour que les requêtes via HTTP et HTTPS soient considérées comme des correspondances pour l'entrée de cache du logo.

Pour apprendre à personnaliser les clés de cache, consultez la section Utiliser des clés de cache.

Optimiser les performances

Les pratiques suivantes sont recommandées pour optimiser les performances.

Vérifier que la prise en charge des protocoles HTTP/3 et QUIC est activée

HTTP/3 est un protocole Internet de nouvelle génération. Il repose sur QUIC, un protocole développé à partir du protocole Google QUIC (gQUIC) d'origine. Le protocole HTTP/3 est pris en charge entre l'équilibreur de charge HTTP(S) externe, Cloud CDN et les clients.

Pour améliorer les performances avec Cloud CDN, assurez-vous que HTTP/3 est activé.

Utiliser la mise en cache négative

La mise en cache négative permet un contrôle précis de la mise en cache pour les erreurs ou les redirections courantes. Lorsque Cloud CDN rencontre des codes de réponse spécifiques, il conserve cette réponse dans le cache pour une valeur TTL définie. Ce processus peut réduire la charge qui s'exerce sur vos origines et améliorer l'expérience de l'utilisateur final en réduisant la latence des réponses.

Activer les données précoces TLS

L'utilisation des données précoces TLS améliore de 30 à 50 % le taux de connexions rétablies. Pour activer les données précoces TLS, utilisez la commande gcloud compute target-https-proxies update avec l'option tls-early-data. Pour en savoir plus, consultez la section Configurer les données précoces TLS.

Vous pouvez activer les données précoces TLS en mode STRICT ou PERMISSIVE.

  • STRICT : autorise les données précoces pour les méthodes idempotentes (GET, HEAD, OPTIONS et TRACE) qui ne comportent pas d'autres paramètres de requête. Il s'agit de la méthode la plus sûre, applicable dans la plupart des cas.
  • PERMISSIVE : autorise les données précoces pour les méthodes idempotentes pouvant inclure des paramètres de requête. Lorsque vous utilisez ce mode, vous devez surveiller de près le comportement de votre application et votre stratégie de sécurité.

Les demandes de données précoces qui utilisent des méthodes HTTP non idempotentes ou qui comportent des paramètres de requête sont refusées avec un code d'état HTTP 425.

Optimiser la sécurité

Les pratiques suivantes sont recommandées pour optimiser la sécurité.

Utiliser Google Cloud Armor

Cloud Armor s'intègre à Cloud CDN pour les contenus en cache et non mis en cache ou en défaut de cache. Une bonne pratique consiste à utiliser Cloud Armor conjointement avec Cloud CDN dans la mesure du possible pour renforcer la sécurité des applications Web.

Utiliser des URL signées

Si vous utilisez des URL signées, notez les points suivants :

Authentifier les origines privées

L'authentification de l'origine offre une garantie solide que la requête provient uniquement de votre propre service de backend configuré. Cela offre également une protection des données en transit pour la requête et empêche la réutilisation de la partie signée de la requête.

Nous vous recommandons d'utiliser l'authentification de l'origine privée pour les buckets Amazon S3 ou les stores d'objets compatibles. L'authentification de l'origine privée permet de s'assurer que seules les connexions de confiance accèdent aux contenus de vos origines privées et que les utilisateurs n'y accèdent pas directement.

De plus, si des pare-feu de l'origine empêchent l'accès à l'origine, utilisez la liste d'autorisation d'adresses IP pour vous assurer qu'une requête provient bien de Cloud CDN ou de l'équilibreur de charge d'application externe. Toutefois, cela n'empêche pas les autres clients Media CDN de tenter d'accéder à votre contenu en spécifiant votre origine dans leur configuration.

Optimiser le cache

Les pratiques suivantes sont recommandées pour optimiser le cache.

Optimiser les valeurs TTL de cache

Vous pouvez définir ou remplacer les valeurs TTL pour ajuster la durée de mise en cache de vos réponses et le moment où Cloud CDN valide à nouveau les réponses.

Vous pouvez également définir une valeur TTL côté client pour exploiter au mieux les caches des navigateurs.

Pour en savoir plus, consultez la page Utiliser les remplacements et les paramètres TTL.

Définir le délai d'expiration d'un contenu sensible au facteur temps

Chaque élément de contenu d'un cache Cloud CDN est associé à un délai d'expiration. Il est donc important de définir un délai d'expiration approprié au cas d'utilisation. Étant donné que les serveurs d'origine doivent renvoyer le contenu qui expire sur les serveurs de cache, vous devez choisir soigneusement le délai d'expiration.

L'une des méthodes de sélection du délai d'expiration consiste à classer le contenu selon sa fréquence de mise à jour. Par exemple :

  • Mises à jour en temps quasi réel, telles que les flux en direct pour les événements sportifs ou la circulation
  • Mises à jour fréquentes, telles que des informations météorologiques hebdomadaires, quotidiennes ou horaires ou des images d'actualités en première page
  • Mises à jour peu fréquentes, telles qu'un logo de site Web ou des fichiers CSS ou JavaScript

Ensuite, sélectionnez le délai d'expiration par catégorie de contenu. Par exemple, un délai d'expiration de cinq secondes peut être approprié pour les scores sportifs en temps quasi réel, tandis qu'un délai d'une heure peut être adapté aux mises à jour météorologiques. Pour le contenu stocké dans Cloud Storage, définissez les délais d'expiration à l'aide des métadonnées Cache-Control. Lorsque le contenu est diffusé par Compute Engine, vous contrôlez les délais d'expiration par la configuration du logiciel serveur Web.

Les délais d'expiration sont spécifiés par les valeurs max-age et s-maxage dans l'en-tête Cache-Control. Cet en-tête est défini par la spécification HTTP. Par exemple, avec l'en-tête Cache-Control suivant, le contenu associé est lisible publiquement et peut être mis en cache avec un délai d'expiration du cache de 72 heures (259 200 secondes) :

  Cache-Control: public, max-age=259200

Pour optimiser la mise en cache, suivez les instructions de la section Présentation de la mise en cache. Gardez à l'esprit que les valeurs max-age et s-maxage du champ de métadonnées Cache-Control fonctionnent conjointement de la manière suivante :

  • Les valeurs max-age et s-maxage sont mesurées en secondes.
  • La valeur s-maxage s'applique uniquement aux caches partagés, pas aux caches de navigateur.
  • La valeur max-age s'applique à tous les caches, sauf si s-maxage la remplace.

Pour les contenus qui changent peu souvent ou qui doivent changer en même temps qu'un contenu associé, il est souvent approprié d'utiliser un délai d'expiration long et des URL avec versions gérées.

Utiliser des URL avec versions gérées pour mettre à jour des contenus

Le gestion des versions de contenu diffuse une version différente d'un même contenu, en le supprimant efficacement et en présentant le nouveau contenu aux utilisateurs avant l'expiration de l'entrée de cache. La gestion des versions étant gratuite, nous vous recommandons de l'utiliser comme approche par défaut pour la mise à jour des contenus pouvant être mis en cache.

Pour gérer les versions d'un contenu, ajoutez un paramètre à l'URL, tel qu'un numéro de version. Vous pouvez inclure des paramètres dans les URL de différentes manières :

  • Ajouter une chaîne de requête : file.ext?v=100.

    Pour les buckets backend, toutes les chaînes de requête utilisées pour la gestion des versions doivent être spécifiées dans la configuration du bucket backend. Pour en savoir plus, consultez la section Liste d'inclusion de chaîne de requête pour les clés de cache Cloud Storage.

  • Modifier le nom du fichier : file.1.0.0.ext ou file_v100.ext.

  • Modifier le chemin d'accès : /v100/file.ext.

Lorsque vous ajoutez le paramètre, vous modifiez le nom du fichier et l'URL. Cette modification oblige le cache à ignorer toute entrée de cache existante.

Utiliser l'invalidation avec parcimonie pour supprimer du contenu

L'invalidation supprime un contenu des serveurs de cache distribués Cloud CDN avant l'expiration de l'entrée de cache. L'invalidation est finalement cohérente.

Nous vous recommandons d'utiliser l'invalidation avec parcimonie et uniquement en dernier recours. Par exemple, une invalidation est utile lorsque vous devez supprimer du contenu pour des raisons juridiques ou suite à un téléchargement accidentel. Sinon, nous vous recommandons d'utiliser la gestion des versions autant que possible, ou d'attendre que le contenu arrive normalement à expiration. Les serveurs de cache Cloud CDN évincent régulièrement du contenu rarement consulté pour faire de la place au nouveau contenu. Tout contenu qui n'est pas consulté pendant 30 jours est supprimé sans condition.

Les invalidations de cache sont soumises à une limitation du débit.

Pour en savoir plus sur l'invalidation, consultez la présentation de l'invalidation de cache.

Optimiser la cohérence des fichiers importés

Les pratiques suivantes sont recommandées pour optimiser la cohérence des importations de fichiers.

Éviter de mettre à jour les fichiers existants

Au lieu de mettre à jour les fichiers existants, importez de nouvelles versions.

Pour les nouveaux fichiers, utilisez des noms uniques qui peuvent inclure des numéros de version ou des dates. Le fait d'ajouter au nom de fichier un numéro de version (par exemple, file_v2.css) ou une date (par exemple, file_20230806.js) permet de s'assurer que Cloud CDN récupère la version correcte et à jour. Il n'est pas recommandé d'ajouter un paramètre à l'URL du fichier (par exemple, file.css?v=2) pour forcer la récupération d'une nouvelle version, car cette approche ne résout pas le problème du risque de mise en cache d'une mise à jour de fichier d'origine non atomique, situation dans laquelle des fichiers partiels ou incomplets peuvent quand même être mis en cache.

Il est essentiel d'importer les nouvelles versions des dépendances avant d'importer les fichiers qui y font référence. Cette pratique permet de s'assurer que toutes les références pointent vers des fichiers complets et à jour, ce qui réduit le risque de diffuser des fichiers partiellement mis à jour ou tronqués.

Effectuer des mises à jour atomiques des fichiers

S'il devient nécessaire de mettre à jour des fichiers existants, procédez de manière atomique.

Si un fichier est consulté et mis en cache avant la fin de l'importation, il est possible que le contenu mis en cache soit incomplet ou tronqué. Par exemple, un fichier tel que /index.html ne peut pas avoir de nom unique, mais peut pointer vers d'autres fichiers portant des noms uniques.

Si vous importez un fichier sous son nom cible, cela peut entraîner la mise en cache de fichiers incomplets s'ils font l'objet d'un accès durant l'importation. Vous devez plutôt importer le fichier sous un nom temporaire, puis le renommer sous son nom cible une fois l'importation terminée. Cela permet de s'assurer que le fichier est intégralement et immédiatement disponible lorsqu'il est référencé.

Lorsque des fichiers existants sont mis à jour, la mise en cache par plages d'octets peut entraîner la conservation par Cloud CDN de plages de l'ancien fichier après l'importation du nouveau fichier. Si Cloud CDN a mis en cache des plages de l'ancien fichier, les requêtes portant sur des blocs manquants peuvent entraîner des réponses incomplètes. Cette situation se produit parce que Cloud CDN détecte que le fichier d'origine a été modifié (car etag ou last-modified ont changé), supprime tout contenu obsolète, déconnecte les téléchargements en cours et génère une erreur, ce qui invite le client à réessayer. Pour atténuer ce problème, émettez des invalidations pour les fichiers mis en cache par plages d'octets lorsqu'ils sont en cours de mise à jour.

Optimiser la surveillance et la journalisation

Les pratiques suivantes sont recommandées pour optimiser la surveillance et la journalisation.

Vérifier que la journalisation est activée pour Cloud CDN

Une bonne pratique de gestion de Cloud CDN consiste à s'assurer que la journalisation est activée pour tous les backends pour lesquels Cloud CDN est activé.

Utiliser le tableau de bord de surveillance personnalisé de Cloud CDN

Pour améliorer la fiabilité et les performances, il est recommandé d'examiner régulièrement les métriques de surveillance liées à Cloud CDN. Le tableau de bord de surveillance personnalisé de Cloud CDN constitue un excellent point de départ.

Examiner les tests de performance tiers

Découvrez des rapports de fournisseurs tiers, tels que ceux fournis par la communauté Citrix Radar sur la disponibilité, la latence et le débit.