Mise en cache

Cette page décrit les options vous permettant de contrôler la mise en cache de vos objets Cloud Storage. Cette page se concentre sur le cache intégré à Cloud Storage et sur Cloud CDN, mais Cloud Storage prend aussi bien en charge les CDN tiers.

Présentation

Lorsqu'un objet Cloud Storage est mis en cache, les copies des données de l'objet sont stockées dans un cache Google ou Internet, ce qui permet de livrer votre objet plus rapidement dans les futures requêtes. Bien que la mise en cache puisse améliorer les performances, sachez que si vous mettez à jour votre objet, mais qu'un cache continue à diffuser l'ancienne version de l'objet, vous risquez de livrer du contenu obsolète.

Mise en cache intégrée pour Cloud Storage

Cloud Storage peut se comporter comme un réseau de diffusion de contenu (CDN) sans intervention de votre part. En effet, les données d'un objet sont mises en cache dans le réseau Cloud Storage si ses métadonnées Cache-Control sont configurées pour autoriser la mise en cache et si les critères suivants sont remplis :

L'objet est accessible au public.
L'objet n'est pas stocké dans un bucket pour lequel l'option Paiements par le demandeur est activée et ne se trouve pas dans un périmètre de service VPC.
L'objet n'est pas chiffré à l'aide de clés de chiffrement gérées par le client ni de clés de chiffrement fournies par le client.

Cloud Storage respecte les valeurs standards pour Cache-Control, telles que :

public : l'objet peut être mis en cache.
private : l'objet ne sera pas mis en cache par Cloud Storage, mais il peut l'être dans le cache local d'un demandeur.
no-cache : l'objet peut être mis en cache, mais il ne peut pas être utilisé pour répondre aux requêtes futures, sauf s'il a été préalablement validé par Cloud Storage.
no-store : l'objet ne peut pas être mis en cache.
max-age=TIME_IN_SECONDS : durée pendant laquelle un objet peut être mis en cache avant d'être considéré comme obsolète. Vous pouvez définir max-age sur n'importe quelle durée. Les objets obsolètes ne sont plus livrés à partir d'un cache, sauf dans des cas particuliers.

Pour définir les métadonnées Cache-Control d'un objet, consultez Modifier des métadonnées d'objets.

Comportement de la mise en cache intégrée avec les stratégies de refus IAM

Lorsqu'une stratégie de refus IAM au niveau de l'organisation limite l'accès en lecture à un objet à partir de l'identifiant principal allUsers, la mise en cache intégrée est désactivée pour l'objet, même s'il existe une stratégie IAM au niveau du bucket qui accorde un accès en lecture à l'objet pour allUsers. Toutefois, si la stratégie de refus IAM ne limite que des utilisateurs individuels, la mise en cache intégrée reste activée pour l'objet.

Remarques sur les performances

Les objets pouvant être mis en cache en mode public offrent de bien meilleures performances. Pour désactiver la mise en cache d'un objet qui contrôle de nombreux clients, et fournir ainsi les données les plus récentes, procédez comme suit :

Envisagez plutôt de définir les métadonnées Cache-Control de l'objet sur public avec la valeur max-age comprise entre 15 et 60 secondes. La plupart des applications peuvent tolérer la présence d'un objet obsolète pendant quelques secondes, en échange d'améliorations de performances.
Servez-vous de la valeur Cache-Control: no-store pour indiquer que l'objet ne doit pas être mis en cache pour les requêtes ultérieures, dans n'importe quel cache.

Utiliser Anywhere Cache avec vos buckets

Anywhere Cache est une fonctionnalité Cloud Storage entièrement gérée et toujours cohérente qui vous permet de créer des caches dans la même zone que vos charges de travail. Les caches peuvent ensuite être utilisés à la place de votre bucket multirégional pour répondre aux requêtes de lecture de données. Cela vous aide à contrôler les coûts de stockage lorsque vous exécutez des charges de travail volumineuses et utilisant beaucoup de données qui entraîneraient sinon des frais de transfert de données multirégionaux et affecteraient les performances. Pour en savoir plus sur la fonctionnalité Anywhere Cache, ses avantages et quand l'utiliser, consultez Présentation d'Anywhere Cache.

Cloud Storage avec Cloud CDN

Pour obtenir des performances optimales lors de la diffusion de contenu aux utilisateurs, nous vous recommandons d'utiliser Cloud Storage avec Cloud CDN.

Pour utiliser Cloud CDN, vous devez utiliser un équilibreur de charge d'application externe avec vos buckets Cloud Storage en tant que backend. Pour accéder au tutoriel sur la configuration d'un équilibreur de charge HTTP(S) avec un bucket Cloud Storage, consultez Héberger un site Web statique.

Les modes de cache Cloud CDN vous permettent d'appliquer une configuration de mise en cache unifiée à tous vos objets. Cloud CDN utilise les métadonnées Cache-Control définies sur vos objets pour déterminer comment les mettre en cache, sauf si vous remplacez les métadonnées Cache-Control à l'aide d'un mode de cache ou d'une limite de valeur TTL.

Lorsque vous choisissez entre la mise en cache intégrée à Cloud Storage et Cloud CDN, tenez compte des points suivants :

Fonctionnalité	Cloud Storage	Cloud CDN
Taille maximale de fichier pouvant être mis en cache	10 Mio	100 Gio ¹
Expiration du cache par défaut	1 heure	1 heure (configurable)
Compatibilité avec les domaines personnalisés via HTTPS	Non	Oui
Invalidation de cache	Non	Oui

¹ La taille maximale des fichiers pouvant être mis en cache pour Cloud CDN est de 100 Gio si le serveur d'origine accepte les requêtes de plage d'octets. Si le serveur d'origine n'accepte pas les requêtes de plage d'octets, la taille maximale des fichiers pouvant être mis en cache pour Cloud CDN est de 10 Mio.

Remarques sur les tarifs

En termes de tarification, le choix entre la mise en cache intégrée à Cloud Storage et Cloud CDN dépend de la quantité de données que vous livrez chaque mois, laquelle détermine les coûts de mise en réseau.

Si vous ne livrez que quelques Gio de données pouvant être mises en cache par mois, voire moins, il peut être plus avantageux d'opter pour la mise en cache intégrée à Cloud Storage. Il est possible que la mise en cache Cloud Storage entraîne des coûts de mise en réseau plus élevés que Cloud CDN, car les objets mis en cache et non mis en cache sont facturés selon le même tarif de transfert de données sortantes (vous payez donc le prix fort pour les succès de cache). Toutefois, vous ne payez que les coûts d'utilisation associés à Cloud Storage pour vos opérations et le stockage de vos données, plutôt que les coûts d'utilisation associés à la fois à Cloud Storage, Cloud CDN et Cloud Load Balancing.
Si vous livrez régulièrement 100 Gio ou plus de données pouvant être mises en cache par mois, ou si vous avez besoin d'utiliser la journalisation par requête ainsi que des en-têtes personnalisés, le coût global peut s'avérer moindre avec Cloud CDN. Des frais de transfert de données sortantes Cloud Storage et de remplissage de cache Cloud CDN vous sont facturés pour le remplissage du cache. Les tarifs de mise en réseau Cloud CDN s'appliquent une fois le cache saturé. Les économies réalisées sur les coûts de mise en réseau grâce à Cloud CDN peuvent justifier les coûts d'exploitation élevés liés à la maintenance de l'équilibreur de charge d'application externe et de Cloud CDN en plus de Cloud Storage.

Étapes suivantes

Apprenez-en plus sur les métadonnées Cache-Control.
Apprenez-en davantage sur les directives RFC Cache-Control.
Consultez la présentation de la mise en cache pour Cloud CDN.
Apprenez à créer un équilibreur de charge HTTP(S) externe pour diffuser des requêtes depuis votre bucket Cloud Storage.
Consultez le détail des tarifs des équilibreurs de charge d'application externes et de Cloud CDN.