Rapid Cache

Important : Anywhere Cache s'appelle désormais Rapid Cache. Lorsque vous utilisez Rapid Cache avec certains outils, il est possible que le nom Anywhere Cache soit toujours mentionné dans l'interface ou la surface de l'outil.

Cette page décrit Rapid Cache, une fonctionnalité qui fournit un cache de lecture zonal basé sur SSD pour les buckets Cloud Storage. Elle vous permet d'obtenir un débit plus élevé et une latence plus faible pour vos données stockées. Rapid Cache fournit une capacité de stockage et une bande passante qui évoluent automatiquement en fonction de vos besoins.

Grâce à ses avantages, le cache rapide est utile pour améliorer les performances et réduire les coûts réseau associés aux charges de travail à forte intensité de lecture.

Consultez Créer et gérer des caches pour savoir comment procéder dans Rapid Cache.

Fonctionnement

Rapid Cache vous permet de créer des caches dans la même zone que vos charges de travail. Lorsque vous créez un cache dans une zone, les requêtes de lecture de données provenant de la zone sont traitées par le cache au lieu du bucket. Chaque cache dessert les clients situés dans la même zone que le cache. Les données ne seront ingérées dans le cache à partir de votre bucket que lorsqu'elles seront lues par une VM résidant dans la même zone que le cache. De plus, les données peuvent être ingérées lorsqu'elles sont écrites dans votre bucket si vous configurez l'ingestion à l'écriture. Les métadonnées ne sont pas mises en cache et les requêtes de métadonnées d'objet sont traitées par le bucket au lieu du cache.

Rapid Cache est un service entièrement géré qui renvoie toujours des données cohérentes.

Autoscaling de la taille du cache et de la limite de bande passante

Rapid Cache fournit une capacité de stockage et une bande passante temporaires qui évoluent automatiquement en fonction de la quantité de données stockées dans un cache.

La limite de bande passante du cache commence à 100 Gbit/s et évolue à raison de 20 Gbit/s par 1 Tio de données stockées. Vous pouvez augmenter la bande passante de départ ou la limite de bande passante totale en augmentant la quantité de données stockées dans le cache, en créant davantage de caches dans une zone ou en contactant votre responsable de compte technique ou votre représentant Google.

Pour en savoir plus sur les limites de taille et de bande passante pour Rapid Cache, consultez Quotas et limites pour Cloud Storage.

Mettre en cache des données dans des zones

Lorsque vous créez un cache pour un bucket, il doit être créé dans une zone située dans l'emplacement de votre bucket. Par exemple, si votre bucket se trouve dans la région us-east1, vous pouvez créer un cache dans us-east1-b, mais pas dans us-central1-c. Si votre bucket se trouve dans l'emplacement birégional ASIA, vous pouvez créer un cache dans n'importe quelle zone des régions asia-east1 et asia-southeast1.

Pour chaque bucket, vous pouvez créer au maximum un cache par zone. Par exemple, si un bucket est situé dans la région us-east1, vous pouvez créer un cache dans us-east1-b et un autre dans us-east1-c. Si un bucket se trouve dans un emplacement multirégional qui englobe us-central1 et us-east1, vous pouvez créer un cache dans us-central1-a et un autre dans us-east1-b.

Vous pouvez créer des caches dans des zones tant que la capacité est disponible pour la zone. Si la capacité de création d'un cache n'est pas disponible, Rapid Cache continue d'essayer de créer un cache jusqu'à ce que la capacité devienne disponible ou que le processus de création soit annulé par l'utilisateur. Il est possible que la capacité reste indisponible pendant une longue période.

Vous pouvez utiliser Rapid Cache dans les zones suivantes. Ces zones peuvent être utilisées en fonction du type d'emplacement de votre bucket.

Zone géographique		Emplacement
	Nom de la zone	Régional	Birégional	Multirégional	Birégional personnalisé
Asie
	asia-east1-a	check		check	check
	asia-east1-b	check		check	check
	asia-east1-c	check		check	check
	asia-northeast1-a	check	check
	asia-northeast1-b	check	check
	asia-northeast1-c	check	check
	asia-south1-a	check
	asia-south1-b	check
	asia-south1-c	check
	asia-southeast1-a	check		check	check
	asia-southeast1-b	check		check	check
	asia-southeast1-c	check		check	check
Europe
	europe-north1-a	check	check
	europe-north1-b	check	check
	europe-north1-c	check	check
	europe-west1-b	check	check	check	check
	europe-west1-c	check	check	check	check
	europe-west1-d	check	check	check	check
	europe-west4-a	check	check	check	check
	europe-west4-b	check	check	check	check
	europe-west4-c	check	check	check	check
	europe-west6-a	check	check
	europe-west6-b	check	check
États-Unis
	us-central1-a	check	check	check	check
	us-central1-b	check	check	check	check
	us-central1-c	check	check	check	check
	us-central1-f	check	check	check	check
	us-central1-ai1a (zone d'IA)	check
	us-east1-b	check	check	check	check
	us-east1-c	check	check	check	check
	us-east1-d	check	check	check	check
	us-east4-a	check		check	check
	us-east4-b	check		check	check
	us-east4-c	check		check	check
	us-east5-a	check		check	check
	us-east5-b	check		check	check
	us-east5-c	check		check	check
	us-south1-a	check		check	check
	us-south1-b	check		check	check
	us-south1-c	check		check	check
	us-south1-ai1b (zone d'IA)	check
	us-west1-a	check		check	check
	us-west1-b	check		check	check
	us-west1-c	check		check	check
	us-west3-a	check
	us-west3-b	check
	us-west3-c	check
	us-west4-a	check		check	check
	us-west4-b	check		check	check
	us-west4-c	check		check	check

Ingestion de données

Les données sont toujours ingérées dans le cache lors de leur premier accès à partir d'un bucket. La première lecture est traitée comme un défaut de cache (miss), et les lectures suivantes comme des accès au cache, ce qui accélère la lecture des données. Vous pouvez éventuellement configurer un cache pour ingérer des données lors de l'écriture afin d'éviter le premier défaut de cache (miss). Cela est utile pour des cas d'utilisation tels que la restauration de points de contrôle ou la préparation de pipelines de données pour l'entraînement de modèles.

Lors de l'ingestion de données dans un cache, Rapid Cache divise les objets en blocs plus petits de taille fixe. La fragmentation des objets permet une mise en cache plus précise, en particulier pour les fichiers volumineux dont seules certaines parties sont consultées.

Un bloc est un bloc de données de 2 Mo. Lorsqu'une requête est effectuée pour un objet, le cache rapide identifie les blocs de 2 Mo qui couvrent la plage d'octets demandée et gère ces blocs de manière indépendante.

Le comportement d'ingestion des données diffère selon la taille de l'objet ingéré dans le cache :

• Pour les requêtes de lecture d'objets de plus de 2 Mo, seuls les blocs contenant la plage d'octets demandée sont ingérés. Par exemple, si vous lisez le premier Mo d'un fichier de 100 Mo, seul le premier bloc de 2 Mo est ingéré.

• Pour les requêtes de lecture d'objets de moins de 2 Mo (par exemple, une image de 500 Ko), l'intégralité de l'objet est ingérée dans le cache.

Configuration du cache

Vous pouvez définir les propriétés suivantes lorsque vous configurez un cache :

Valeur TTL (Time To Live)

La valeur TTL correspond à la durée maximale pendant laquelle un fragment de données reste dans le cache après la dernière lecture. Par exemple, si la valeur TTL est définie sur 24 heures, un fragment de données qui a été lu pour la dernière fois le lundi à 11h et qui n'a pas été lu depuis sera supprimé du cache le mardi à 11h. Vous pouvez définir une valeur TTL comprise entre 24 heures et 7 jours. Si aucune valeur n'est spécifiée, la valeur TTL est de 24 heures par défaut.

Ingérer lors de l'écriture

L'ingestion de données dans le cache lors de l'écriture d'objets accélère les charges de travail de lecture après écriture, telles que la création de points de contrôle et la préparation des données de sortie pour un job d'entraînement. Lorsque vous configurez un cache pour ingérer des données lors de l'écriture, les données sont écrites dans le cache à mesure qu'elles sont importées dans le bucket. Cette approche proactive élimine les échecs de cache initiaux et permet à vos charges de travail de bénéficier d'un succès de cache (hit) immédiat dès la première lecture.

L'ingestion lors de l'écriture peut être activée en option lorsque vous mettez à jour les critères d'ingestion d'un cache existant. Vous ne pouvez pas le configurer lors de la création initiale du cache.

Considérations sur les performances

• Échecs de récupération de blocs : si une requête couvre plusieurs blocs et que certains sont dans le cache tandis que d'autres ne le sont pas, le cache rapide récupère de manière transparente les blocs manquants à partir du bucket source.

• TTL et expulsion : les règles d'expulsion TTL (Time to Live) et LRU (Least Recently Used) fonctionnent également sur les blocs. Les parties fréquemment utilisées d'un fichier volumineux peuvent rester dans le cache, tandis que les parties peu utilisées sont supprimées.

Tarifs

Pour en savoir plus, consultez les tarifs de Rapid Cache.

Contrôle des coûts

Développez les conseils suivants pour découvrir comment minimiser les coûts d'exécution des caches :

Sélection du bucket

Vous ne devez créer des caches que pour les buckets contenant les données que vous souhaitez mettre en cache.

Sélectionner la zone

Vous ne devez créer des caches que dans les zones où votre charge de travail bénéficiera de la mise en cache.

Paramètre TTL

Vous devez spécifier la valeur TTL minimale dont vous avez besoin pour stocker les données dans le cache. Vous pouvez modifier la valeur TTL sans interruption. La valeur par défaut est de 1 jour.

Désactiver le cache

Vous pouvez désactiver un cache pour le supprimer définitivement du service et arrêter l'accumulation de tous les frais de cache associés.

Avantages

Lorsque vous mettez vos données en cache avec Rapid Cache, vous bénéficiez des avantages suivants :

• Accès plus rapide aux données : Rapid Cache colocalise vos données dans la même zone que vos ressources de calcul et repose entièrement sur des disques SSD. Cela permet à vos charges de travail d'obtenir un débit allant jusqu'à 2,5 To/s et de réduire la latence pour des lectures plus rapides.

• Réduction des frais de transfert de données multirégionaux : les données lues à partir du cache sont facturées avec des frais de transfert de données réduits par rapport aux données lues directement depuis un bucket multirégional.

• Réduction des frais de récupération : les frais de récupération pour les buckets de stockage Nearline, Coldline et Archive ne s'appliquent pas aux lectures de données à partir du cache.

• Réduction des coûts des opérations de lecture : les opérations de lecture exécutées depuis Rapid Cache sont facturées à moindre coût par rapport aux opérations de classe B exécutées à partir d'un bucket dans le stockage standard.

• Mise à l'échelle automatique de la taille de votre cache : la mise en cache des disques SSD dynamiques de Rapid Cache s'adapte automatiquement en fonction de l'utilisation, sans que vous ayez besoin de spécifier une taille.

• Utilisation efficace des caches : vous pouvez activer Rapid Cache sur les buckets existants sans avoir à modifier vos applications ni vos API. Les données stockées dans le cache rapide sont fortement cohérentes.

Pour en savoir plus, consultez les tarifs de Rapid Cache. Pour en savoir plus sur les quotas, consultez Quotas Rapid Cache.

Quand utiliser Rapid Cache ?

Utilisez Rapid Cache pour les données qui sont rarement modifiées et fréquemment lues afin d'accélérer la lecture des données pour les charges de travail d'analyse, ainsi que l'entraînement et le chargement des modèles d'IA/ML.

Imaginons que vous entraîniez un modèle d'IA sur plusieurs nœuds Google Kubernetes Engine, qui lisent tous à plusieurs reprises les données stockées dans vos buckets Cloud Storage et s'exécutent dans la même zone. Lorsque vous créez un cache dans la zone où s'exécute votre charge de travail, le cache fournit une bande passante supplémentaire et vous aide à réduire les frais de transfert de données liés à la lecture de données dans des buckets multirégionaux. Vous pouvez ainsi exécuter des charges de travail plus importantes et à plus grande échelle de manière plus efficace.

Utiliser le cache rapide pour accélérer les lectures pour BigQuery

Rapid Cache peut être utilisé pour diffuser des données pour les demandes de lecture d'objets émises par BigQuery. En utilisant le cache Rapid, vous pouvez accélérer la lecture des données pour vos applications tout en optimisant l'efficacité des coûts.

Bien que BigQuery soit un service régional, ses ressources de calcul sous-jacentes peuvent parfois passer d'une zone à une autre pour l'équilibrage de charge. En tant que bonne pratique, activez le cache Rapid pour une charge de travail BigQuery dans toutes les zones d'une région afin de vous assurer qu'un cache est disponible en cas de changement de zone des ressources de calcul sous-jacentes. Si un cache dans une zone n'est pas utilisé, il n'entraîne aucun coût supplémentaire, car Rapid Cache est un service à la demande. Notez que si les ressources d'une charge de travail changent de zone, le cache de la nouvelle zone devra réingérer les données, ce qui peut entraîner une augmentation ponctuelle des coûts d'ingestion de données.

Outil de recommandation Rapid Cache

L'outil de recommandation Rapid Cache fournit des recommandations et des insights pour créer des caches dans des paires zone/bucket en analysant votre utilisation des données et votre stockage. Pour obtenir des informations générales et des instructions sur l'utilisation de l'outil de recommandation Rapid Cache, consultez Outil de recommandation Rapid Cache.

Opérations de cache

Cette section décrit les opérations que vous pouvez effectuer sur les caches Rapid Cache. Certaines opérations sont asynchrones et renvoient une opération de longue durée, tandis que d'autres sont synchrones, où les opérations sont effectuées immédiatement et renvoient une ressource AnywhereCache.

Créer un cache

Lorsque vous créez un cache, il passe à l'état EN COURS DE CRÉATION pendant sa création, puis à l'état EN COURS D'EXÉCUTION lorsqu'il devient actif. La création du cache peut prendre jusqu'à 48 heures, après quoi l'opération expire.

L'API AnywhereCaches Create est asynchrone. Une opération de création entraîne le renvoi d'une opération de longue durée. L'opération de longue durée fournit l'état de l'opération de création et vous permet de l'annuler avant qu'elle ne soit terminée.

Remarque : Si vous tentez d'annuler l'opération de création, le serveur fera de son mieux pour l'annuler, mais la réussite de l'opération n'est pas garantie.

Mettre à jour un cache

Vous pouvez mettre à jour la valeur TTL ou le comportement d'ingestion d'un cache à l'état EN COURS D'EXÉCUTION. Lorsqu'un cache est en cours de mise à jour, le champ pending_update est défini sur la valeur true. Tant que le champ pending_update affiche la valeur true, le cache ne peut plus être mis à jour.

Il est impossible de mettre à jour un cache dont l'état est EN COURS DE CRÉATION ou DÉSACTIVÉ. L'API AnywhereCaches Update est asynchrone et renvoie une opération de longue durée.

Lorsque la valeur TTL d'un cache a fini d'être mise à jour, la nouvelle valeur TTL s'applique immédiatement aux données existantes et nouvelles du cache.

Obtenir un cache

Lorsque vous obtenez un cache, Rapid Cache renvoie l'état et la configuration de l'instance de cache. L'API AnywhereCaches Get est synchrone et renvoie une ressource AnywhereCache.

Lister les caches

Vous pouvez renvoyer une liste des caches associés pour un bucket donné. L'API AnywhereCaches List est synchrone et compatible avec la pagination.

Désactiver un cache

Vous pouvez désactiver un cache pour le supprimer définitivement de la configuration de votre bucket. Lorsque vous désactivez un cache, il passe à l'état DÉSACTIVÉ. Dans cet état, vous pouvez toujours lire les données existantes du cache, mais vous ne pouvez pas en ingérer de nouvelles.

Après avoir désactivé un cache, vous disposez d'un délai de grâce d'une heure pendant lequel vous pouvez annuler la désactivation en réactivant le cache. Passé ce délai de grâce d'une heure, le cache est supprimé. Lorsque le cache est supprimé, toutes les données qu'il contient sont supprimées et le cache est retiré du bucket.

Pendant l'heure précédant la suppression du cache, vous pouvez rétablir l'état DÉSACTIVÉ en réactivant le cache, qui reprend alors l'état EN COURS D'EXÉCUTION.

L'API AnywhereCaches Disable est synchrone et renvoie une ressource AnywhereCache.

Réactiver un cache

Vous pouvez reprendre les caches qui affiche l'état DÉSACTIVÉ, à condition que le cache désactivé soit compris dans le délai de grâce d'une heure. Après le délai de grâce d'une heure, l'opération de reprise est effectuée au mieux de ses capacités, car le cache peut être supprimé à tout moment après le délai de grâce. Une fois qu'un cache a été repris, il passe à l'état EN COURS D'EXÉCUTION.

L'API AnywhereCaches Resume est synchrone et renvoie une ressource AnywhereCache.

Limites et restrictions

• Pour supprimer un bucket, vous devez d'abord supprimer tous les caches associés. La seule exception concerne la suppression d'un bucket à l'aide de la console Google Cloud , qui supprime tous les caches associés en même temps que le bucket.

• Lorsque vous créez, désactivez, reprenez ou mettez à jour des caches, limitez le nombre d'opérations à une par seconde. Si vous effectuez plusieurs opérations par seconde, des échecs peuvent se produire.

• Rapid Cache n'est pas un stockage durable. Les données peuvent être supprimées du cache dans différents scénarios. Par exemple, le cache peut être redimensionné automatiquement pour garantir que des ressources suffisantes sont disponibles pour vos charges de travail. Dans ce scénario, certaines données peuvent être évincées selon un algorithme dit du "moins récemment utilisé" (LRU, least recently used) jusqu'à ce que le service Rapid Cache ait fini d'augmenter la taille du cache.

  Dans tous les cas, vos données restent stockées de manière sécurisée dans votre bucket source. Lorsque des données sont supprimées du cache pour des raisons autres que l'expiration de la valeur TTL, le service Rapid Cache tente de les réingérer dans le cache de manière transparente et sans frais. Si les données ne peuvent pas être réingérées de manière transparente ou ont été supprimées en raison de l'expiration de la valeur TTL, le service Rapid Cache les réingère lors de la première lecture.

• Les recommandations et les insights générés par l'outil de recommandation Rapid Cache ne peuvent pas être lus à l'aide de BigQuery.

Résoudre les problèmes liés au manque temporaire de ressources

Les sections suivantes décrivent comment résoudre les problèmes liés au manque temporaire de ressources, lorsque la capacité de disque SSD ou de diffusion dans une zone spécifiée est insuffisante pour créer un cache, augmenter sa taille ou augmenter sa limite de bande passante.

Échec de la création d'un cache

Rapid Cache peut ne pas réussir à créer un cache dans une zone spécifique en raison d'un manque de capacité de disque SSD ou de ressources de diffusion du débit, ce qui entraîne un manque temporaire de ressources. Pendant cette période, Rapid Cache tente de créer le nouveau cache pendant 48 heures maximum. Si des ressources deviennent disponibles dans un délai de 48 heures, Rapid Cache traite la demande de création du cache. Si les ressources ne deviennent pas disponibles dans le délai de 48 heures, la requête de création du cache échoue.

Dépannage : pour éviter toute interruption de la mise en cache, vous pouvez annuler manuellement l'opération de création du cache et en créer un dans une autre zone où de la capacité est peut-être disponible. Pour surveiller ou annuler une opération de création de cache, consultez Utiliser des opérations de longue durée.

Échec de l'augmentation de la taille du cache

Rapid Cache peut ne pas parvenir à augmenter la taille d'un cache lorsque la quantité requise de capacité de disque SSD n'est pas disponible dans la zone du cache.

Bien que Rapid Cache propose des augmentations automatiques de la taille du cache à la demande, celles-ci dépendent de la disponibilité de la capacité de disque SSD. Si la capacité de disque SSD n'est pas disponible lors de la demande d'augmentation automatique de la taille du cache, Rapid Cache continue d'envoyer la demande jusqu'à ce que le manque temporaire de ressources prenne fin ou qu'une augmentation de la taille du cache ne soit plus nécessaire.

En cas de manque temporaire de ressources, de nouvelles données sont ingérées et les données existantes dans le cache sont supprimées en fonction de leur date d'utilisation la plus récente. Les caches suffisamment volumineux pour stocker la plupart des données "chaudes" n'ont que peu ou pas d'impact sur les métriques de cache. Les caches dont la capacité est inférieure à la quantité de données "chaudes" peuvent évincer des données et les réingérer plus souvent que les caches non affectés par les manques de ressources. Lorsque la taille réelle de votre cache est beaucoup plus petite que la capacité requise, vous pouvez rencontrer les problèmes suivants liés au manque de ressources :

• Une limite de bande passante du cache et un débit du cache inférieurs, une consommation du quota de bande passante du transfert de données plus élevée et un impact possible sur d'autres métriques
• La facturation peut être affectée de différentes manières :
  • Augmentation des coûts liés aux frais d'ingestion du cache
  • Réduction des coûts liés aux frais de stockage du cache
  • Réduction des coûts liés aux frais de transfert de données sortantes du cache
  • Réduction des coûts liés aux frais d'opération de transfert de données sortantes du cache
  • Augmentation des coûts liés aux frais de transfert de données multirégionaux
  • Augmentation des coûts liés à l'utilisation des opérations de classe B

Pour en savoir plus sur ces frais, consultez les tarifs de Rapid Cache.

Comment résoudre les problèmes : pour obtenir les meilleurs résultats en cas de manque temporaire de ressources, nous vous recommandons de surveiller vos caches et de désactiver les caches ou les charges de travail inutiles en fonction de vos besoins.

Échec du scaling à la hausse de la limite de bande passante d'un cache

Une insuffisance temporaire de la limite de bande passante du cache peut se produire lors d'une augmentation de la taille du cache lorsque les ressources de diffusion du débit dans une zone spécifique sont insuffisantes pour effectuer le scaling de la limite de bande passante des caches existants à 20 Gbit/s par Tio. En cas d'insuffisance de bande passante du cache, Rapid Cache ne permet pas à la limite de bande passante du cache d'évoluer à 20 Gbit/s par Tio de données, mais le cache continue de répondre aux requêtes de lecture. Vous pouvez demander plus de bande passante de cache en contactant votre responsable de compte technique ou votre représentant Google. En cas d'insuffisance de bande passante de cache disponible, vous pouvez constater peut-être une augmentation de la consommation de bande passante de sortie des données de votre bucket.

Comment résoudre les problèmes : pour obtenir les meilleurs résultats en cas de manque temporaire de ressources, nous vous recommandons de surveiller vos caches et de désactiver les caches ou les charges de travail inutiles en fonction de vos besoins.

Étapes suivantes

• Créez et gérez des caches.