Consignes applicables aux taux de demandes et à la distribution des accès

Cloud Storage est un service ultra évolutif qui exploite la technologie d'autoscaling pour atteindre des taux de demandes très élevés. Cette page explique comment optimiser le scaling et les performances fournis par Cloud Storage.

Autoscaling

Cloud Storage est un service mutualisé, ce qui signifie que les utilisateurs partagent le même ensemble de ressources sous-jacentes. Afin d'optimiser l'utilisation de ces ressources partagées, les buckets ont une capacité d'E/S initiale suivante :

  • Environ 1 000 requêtes d'écriture d'objets par seconde. Ces opérations incluent l'importation, la mise à jour et la suppression d'objets. Notez que Cloud Storage présente également une limite plus faible pour les écritures répétées sur le même nom d'objet.
  • Environ 5 000 requêtes de lecture d'objets par seconde. Ces opérations incluent la création de listes d'objets, la lecture de données d'objets et la lecture de métadonnées d'objets.

Ces taux initiaux de lecture et d'écriture permettent en moyenne d'écrire 2,5 Po de données et d'en lire 13 Po par mois pour des objets de 1 Mo. À mesure que le taux de demandes s'accroît sur un bucket donné, Cloud Storage en augmente automatiquement la capacité d'E/S et procède à un autoscaling en répartissant la charge de requêtes sur plusieurs serveurs.

Délai de répartition de la charge

Lorsqu'un bucket approche de sa limite de capacité d'E/S, Cloud Storage met généralement quelques minutes à détecter la charge et à la répartir en conséquence sur davantage de serveurs. Donc, si le taux de demandes sur votre bucket augmente plus rapidement que Cloud Storage ne peut répartir la charge, vous risquez d'être confronté à des restrictions temporaires, et notamment de subir une latence et des taux d'erreur plus élevés. Pour éviter ce genre de situation, vous pouvez augmenter progressivement le taux de demandes sur vos buckets, comme décrit ci-dessous.

Indexation des clés d'objet

Cloud Storage permet de répertorier les objets de manière cohérente pour que les utilisateurs puissent facilement exécuter des workflows de traitement des données sur le service. Afin de fournir des listes d'objets cohérentes, Cloud Storage gère un index de clés d'objet pour chaque bucket. Cet index est stocké dans l'ordre lexicographique et est mis à jour chaque fois qu'un objet est créé dans un bucket ou supprimé d'un bucket. L'ajout ou la suppression d'objets dont toutes les clés se trouvent dans une petite plage de l'index augmente naturellement les chances de conflit.

Cloud Storage détecte ces conflits, également appelés hotspotting, et répartit automatiquement la charge sur la plage d'index affectée entre plusieurs serveurs. À l'instar du scaling de la capacité d'E/S d'un bucket, il est conseillé d'augmenter progressivement le taux de demandes lorsque vous accédez à une nouvelle plage de l'index ou que vous écrivez des objets sous un nouveau préfixe, comme décrit ci-dessous. Sinon, votre latence et vos taux d'erreur pourraient temporairement s'accroître.

Bonnes pratiques

Les sections suivantes décrivent les bonnes pratiques à adopter lors de l'augmentation progressive du taux de demandes, du choix des clés d'objet et de la distribution des requêtes afin d'éviter d'être soumis à des restrictions temporaires sur votre bucket. Notez qu'en plus de ces considérations par bucket, des limites de bande passante combinées s'appliquent également aux buckets situés dans le même emplacement et le même projet.

Augmenter progressivement le taux de demandes

Pour garantir un autoscaling optimal dans Cloud Storage, vous devez augmenter progressivement votre taux de demandes sur les buckets qui n'ont pas rencontré un taux élevé au cours des derniers jours ou qui disposent d'une nouvelle plage de clés d'objet. Si votre taux de demandes est inférieur à 1 000 requêtes d'écriture ou à 5 000 requêtes de lecture par seconde, aucune augmentation n'est nécessaire. S'il devait dépasser ces seuils, vous devriez commencer par choisir un taux de demandes inférieur ou proche de ces derniers, puis l'augmenter progressivement, sans excéder une cadence d'un doublement par période de 20 minutes.

Si vous rencontrez des problèmes tels qu'une latence ou des taux d'erreur élevés, cessez d'augmenter progressivement le taux de demandes ou réduisez-le temporairement pour laisser à Cloud Storage le temps d'adapter le bucket. Vous devez relancer vos requêtes avec un intervalle exponentiel entre les tentatives dans les cas suivants :

  • Erreurs générées avec des codes de réponse 408 et 429
  • Erreurs générées avec des codes de réponse 5xx.

Utiliser une convention de dénomination qui répartit la charge uniformément entre les plages de clés

L'autoscaling d'une plage d'index peut être ralenti lorsque vous utilisez des noms séquentiels, tels que des clés d'objet basées sur une séquence de chiffres ou sur un horodatage. Ce phénomène est dû au fait que les requêtes passent constamment à d'autres plages d'index, ce qui complique la répartition de la charge et la rend moins efficace.

Afin de maintenir un taux de demandes élevé, évitez d'utiliser des noms séquentiels. Employez plutôt des noms d'objet aléatoires, qui optimiseront la répartition de la charge. Si vous souhaitez utiliser des numéros séquentiels ou des horodatages dans vos noms d'objet, intégrez une dimension aléatoire en ajoutant une valeur de hachage avant le numéro de séquence ou l'horodatage.

Supposons par exemple que vous souhaitiez utiliser les noms d'objet d'origine suivants :

my-bucket/2016-05-10-12-00-00/file1
my-bucket/2016-05-10-12-00-00/file2
my-bucket/2016-05-10-12-00-01/file3
...

Vous pouvez calculer le hachage MD5 du nom d'objet d'origine et ajouter les six premiers caractères du hachage en tant que préfixe de ce nom. Les objets prennent alors les noms suivants :

my-bucket/2fa764-2016-05-10-12-00-00/file1
my-bucket/5ca42c-2016-05-10-12-00-00/file2
my-bucket/6e9b84-2016-05-10-12-00-01/file3
...

Un préfixe aléatoire plus long fournit un autoscaling plus efficace lorsqu'il est soumis à des taux de lecture et d'écriture très élevés. Par exemple, un préfixe à 1 caractère utilisant une valeur hexadécimale aléatoire fournit un autoscaling efficace de 5 000/1 000 lectures/écritures par seconde jusqu'à environ 80 000/16 000 lectures/écritures par seconde, car le préfixe comporte 16 valeurs potentielles. Si votre cas d'utilisation ne nécessite pas des taux plus élevés que ces valeurs, un préfixe aléatoire à 1 caractère est tout aussi efficace qu'un préfixe aléatoire à 2 caractères ou plus pour accroître le débit des requêtes.

L'ajout d'une chaîne aléatoire après un préfixe commun s'avère efficace pour les éléments comportant le préfixe

Notez que la chaîne aléatoire ne doit pas nécessairement se situer au début du nom d'objet. L'ajout d'une chaîne aléatoire après un préfixe commun n'entravera pas l'autoscaling, mais l'effet se limitera au préfixe, sans tenir compte du reste du bucket.

Exemple :

my-bucket/images/animals/4ce4c6af-6d27-4fa3-8a91-5701a8552705/1.jpg
my-bucket/images/animals/9a495e72-1d85-4637-a243-cbf3e4a90ae7/2.jpg
...
my-bucket/images/landscape/585356ac-ce89-47a8-bdd2-78a86b58fee6/1.jpg
my-bucket/images/landscape/2550ae5b-395e-4243-a29b-bbf5aece60ef/2.jpg
...
my-bucket/images/clouds/1.jpg
my-bucket/images/clouds/2.jpg
...

Les noms ci-dessus permettent d'obtenir un autoscaling efficace des objets dans images/animals et images/landscape,, mais pas dans images/clouds.

L'ajout d'une chaîne aléatoire après des préfixes séquentiels n'est pas aussi efficace

Comme mentionné ci-dessus, l'utilisation d'une chaîne aléatoire après un préfixe commun ne rend l'autoscaling efficace que pour les éléments comportant ce préfixe. Lorsque les requêtes passent à un autre préfixe, vous ne pouvez plus bénéficier des effets d'autoscaling précédents. Ce problème est particulièrement apparent lorsque les préfixes suivent un schéma séquentiel.

Par exemple, si vous écrivez des fichiers toutes les heures sous un nouveau préfixe basé sur un horodatage, vous pouvez obtenir les noms suivants :

my-bucket/2016-05-10-00/cf9a7b95-0d2e-4466-9596-840ff388ddbd
my-bucket/2016-05-10-00/f1e16a88-16b8-4c66-ba66-a225c87be80c
my-bucket/2016-05-10-00/646d8272-4a88-4dc2-b2d4-d537c778df41
...
my-bucket/2016-05-10-01/bdcba6de-ac25-4c27-8550-0d08f249e69d
my-bucket/2016-05-10-01/a32c867c-09a9-4d65-9668-ddd4ebe4138b
my-bucket/2016-05-10-01/d619485c-5243-4a4e-8ef3-0f7e1d26ce1d
...

Bien que l'autoscaling aide à augmenter au fil du temps le taux d'écriture avec un certain préfixe, ce taux est réinitialisé au début de chaque heure. Vous obtenez alors un taux d'écriture non optimal, ainsi qu'une latence et des taux d'erreur périodiquement accrus. Si, au fil du temps, vous avez besoin d'écrire des données avec différents préfixes, assurez-vous que les nouveaux préfixes sont uniformément répartis sur l'ensemble de la plage de clés pour contourner ce problème.

Réorganiser les opérations groupées pour répartir la charge uniformément sur les plages de clés

Vous voudrez peut-être parfois effectuer une importation ou une suppression groupée de données Cloud Storage. Dans les deux cas, il est possible que vous n'exerciez aucun contrôle sur les noms d'objet. Toutefois, vous pouvez choisir l'ordre d'importation ou de suppression des objets pour obtenir le meilleur taux d'écriture ou de suppression possible.

Pour ce faire, répartissez les importations ou les suppressions sur plusieurs préfixes. Si vous souhaitez par exemple importer un grand nombre de dossiers contenant beaucoup de fichiers, une bonne stratégie consiste à importer plusieurs dossiers en parallèle et à choisir aléatoirement les dossiers et les fichiers à importer. Ainsi, le système est en mesure de répartir la charge sur l'ensemble de la plage de clés de manière plus uniforme, ce qui permet d'atteindre un taux de demandes élevé après l'augmentation progressive initiale.

Étape suivante