Meilleures pratiques pour optimiser les performances de S3 Express One Zone - Amazon Simple Storage Service

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Meilleures pratiques pour optimiser les performances de S3 Express One Zone

Lors du développement d’applications qui chargent et récupèrent les objets depuis Amazon S3 Express One Zone, suivez nos bonnes pratiques pour optimiser les performances. Pour utiliser la classe de stockage S3 Express One Zone, vous devez créer un compartiment de répertoires S3. La classe de stockage S3 Express One Zone n’est pas prise en charge pour une utilisation avec les compartiments S3 à usage général.

Pour accéder aux directives d’optimisation des performances relatives à toutes les autres classes de stockage Amazon S3 et aux compartiments à usage général S3, consultez Modèles de conception des bonnes pratiques : optimisation des performances d’Amazon S3.

Pour optimiser les performances et l'évolutivité de la classe de stockage S3 Express One Zone et des compartiments de répertoire pour les charges de travail à grande échelle, il est important de comprendre en quoi les compartiments de répertoire fonctionnent différemment des compartiments à usage général. Ensuite, nous proposons les meilleures pratiques pour aligner vos applications sur le fonctionnement des buckets d'annuaires.

Comment fonctionnent les compartiments de répertoires

La classe de stockage Amazon S3 Express One Zone peut prendre en charge des charges de travail comportant jusqu'à 2 000 000 de transactions GET et jusqu'à 200 000 transactions PUT par seconde (TPS) par compartiment de répertoire. Avec S3 Express One Zone, les données sont stockées dans des compartiments de répertoire S3 situés dans des zones de disponibilité. Les objets des compartiments de répertoire sont accessibles dans un espace de noms hiérarchique, comme dans un système de fichiers, contrairement aux compartiments à usage général S3 dotés d'un espace de noms plat. Contrairement aux compartiments à usage général, les compartiments de répertoires organisent les clés de manière hiérarchique dans des répertoires plutôt qu’avec des préfixes. Un préfixe est une chaîne de caractères au début du nom de la clé d’objet. Vous pouvez utiliser des préfixes pour organiser vos données et gérer une architecture de stockage d'objets plats dans des compartiments à usage général. Pour de plus amples informations, veuillez consulter Organisation des objets à l’aide de préfixes.

Dans les compartiments de répertoire, les objets sont organisés dans un espace de noms hiérarchique en utilisant forward slash (/) comme seul séparateur pris en charge. Lorsque vous chargez un objet avec une clé telle quedir1/dir2/file1.txt, les répertoires dir1/ dir2/ sont automatiquement créés et gérés par Amazon S3. Les répertoires sont créés pendant PutObject CreateMultiPartUpload les opérations et automatiquement supprimés lorsqu'ils deviennent vides après DeleteObject AbortMultiPartUpload les opérations. Il n'y a pas de limite supérieure au nombre d'objets et de sous-répertoires dans un répertoire.

Les répertoires créés lorsque les objets sont chargés dans des compartiments de répertoires peuvent être redimensionnés instantanément afin de réduire le risque d'erreurs HTTP. 503 (Slow Down) Cette mise à l’échelle automatique permet à vos applications de mettre en parallèle les demandes de lecture et d’écriture dans et entre les répertoires, selon les besoins. Pour S3 Express One Zone, les annuaires individuels sont conçus pour prendre en charge le taux de requêtes maximal d'un bucket de répertoires. Il n'est pas nécessaire de randomiser les préfixes de clé pour obtenir des performances optimales, car le système distribue automatiquement les objets pour une répartition uniforme de la charge. Par conséquent, les clés ne sont pas stockées lexicographiquement dans des compartiments de répertoire. Cela contraste avec les compartiments à usage général S3 où les clés les plus proches du point de vue lexicographique sont plus susceptibles d'être colocalisées sur le même serveur.

Pour plus d'informations sur des exemples d'opérations de bucket d'annuaire et d'interactions d'annuaires, consultezExemples d'opérations de bucket et d'interactions entre annuaires.

Bonnes pratiques

Suivez les meilleures pratiques pour optimiser les performances de votre bucket d'annuaires et faire évoluer vos charges de travail au fil du temps.

Utilisez des répertoires contenant de nombreuses entrées (objets ou sous-répertoires)

Les compartiments d'annuaire offrent des performances élevées par défaut pour toutes les charges de travail. Pour optimiser encore les performances de certaines opérations, la consolidation d'un plus grand nombre d'entrées (objets ou sous-répertoires) dans des répertoires réduira le temps de latence et augmentera le taux de requêtes :

  • Les opérations d'API mutantes, telles quePutObject, CreateMultiPartUpload et DeleteObjectAbortMultiPartUpload, permettent d'obtenir des performances optimales lorsqu'elles sont mises en œuvre avec des répertoires moins nombreux et plus denses contenant des milliers d'entrées, plutôt qu'avec un grand nombre de répertoires plus petits.

  • ListObjectsV2les opérations sont plus performantes lorsque moins de répertoires doivent être parcourus pour remplir une page de résultats.

N'utilisez pas l'entropie dans les préfixes

Dans les opérations Amazon S3, l'entropie fait référence au caractère aléatoire de la dénomination des préfixes qui permet de répartir les charges de travail de manière uniforme sur les partitions de stockage. Cependant, étant donné que les compartiments de répertoire gèrent en interne la distribution de la charge, il n'est pas recommandé d'utiliser l'entropie dans les préfixes pour de meilleures performances. En effet, pour les compartiments de répertoires, l'entropie peut ralentir les demandes en ne réutilisant pas les répertoires déjà créés.

Un modèle clé tel que celui-ci $HASH/directory/object pourrait finir par créer de nombreux répertoires intermédiaires. Dans l'exemple suivant, tous les job-1 s sont des répertoires différents puisque leurs parents sont différents. Les répertoires seront rares et les demandes de mutation et de liste seront plus lentes. Dans cet exemple, il existe 12 répertoires intermédiaires qui ont tous une seule entrée.

s3://my-bucket/0cc175b9c0f1b6a831c399e269772661/job-1/file1 s3://my-bucket/92eb5ffee6ae2fec3ad71c777531578f/job-1/file2 s3://my-bucket/4a8a08f09d37b73795649038408b5f33/job-1/file3 s3://my-bucket/8277e0910d750195b448797616e091ad/job-1/file4 s3://my-bucket/e1671797c52e15f763380b45e841ec32/job-1/file5 s3://my-bucket/8fa14cdd754f91cc6554c9e71929cce7/job-1/file6

Au lieu de cela, pour de meilleures performances, nous pouvons supprimer le $HASH composant et l'autoriser job-1 à devenir un répertoire unique, améliorant ainsi la densité d'un répertoire. Dans l'exemple suivant, le répertoire intermédiaire unique comportant 6 entrées peut améliorer les performances par rapport à l'exemple précédent.

s3://my-bucket/job-1/file1 s3://my-bucket/job-1/file2 s3://my-bucket/job-1/file3 s3://my-bucket/job-1/file4 s3://my-bucket/job-1/file5 s3://my-bucket/job-1/file6

Cet avantage en termes de performances est dû au fait que lorsqu'une clé d'objet est initialement créée et que son nom de clé inclut un répertoire, celui-ci est automatiquement créé pour l'objet. Les chargements d’objets ultérieurs vers ce même répertoire ne nécessitent pas la création du répertoire, ce qui réduit la latence lors des chargements d’objets vers les répertoires existants.

Utilisez un séparateur autre que le délimiteur/pour séparer les parties de votre clé si vous n'avez pas besoin de pouvoir regrouper des objets de manière logique pendant les appels ListObjectsV2

Étant donné que le / délimiteur est traité spécialement pour les compartiments de répertoires, il doit être utilisé avec intention. Bien que les compartiments de répertoire n'ordonnent pas les objets de manière lexicographique, les objets d'un répertoire sont toujours regroupés dans les sorties. ListObjectsV2 Si vous n'avez pas besoin de cette fonctionnalité, vous pouvez le / remplacer par un autre caractère comme séparateur afin de ne pas provoquer la création de répertoires intermédiaires.

Supposons, par exemple, que les clés suivantes suivent un modèle de YYYY/MM/DD/HH/ préfixe

s3://my-bucket/2024/04/00/01/file1 s3://my-bucket/2024/04/00/02/file2 s3://my-bucket/2024/04/00/03/file3 s3://my-bucket/2024/04/01/01/file4 s3://my-bucket/2024/04/01/02/file5 s3://my-bucket/2024/04/01/03/file6

Si vous n'avez pas besoin de regrouper les objets par heure ou par jour dans les ListObjectsV2 résultats, mais que vous devez regrouper les objets par mois, le schéma clé suivant YYYY/MM/DD-HH- permettra de réduire considérablement le nombre de répertoires et d'améliorer les performances de l'ListObjectsV2opération.

s3://my-bucket/2024/04/00-01-file1 s3://my-bucket/2024/04/00-01-file2 s3://my-bucket/2024/04/00-01-file3 s3://my-bucket/2024/04/01-02-file4 s3://my-bucket/2024/04/01-02-file5 s3://my-bucket/2024/04/01-02-file6

Utilisez des opérations de liste délimitées dans la mesure du possible

Une ListObjectsV2 requête dépourvue de delimiter effectue une traversée récursive de tous les répertoires en fonction de la profondeur d'abord. Une ListObjectsV2 requête contenant un delimiter extrait uniquement les entrées du répertoire spécifié par le prefix paramètre, ce qui réduit le temps de latence des demandes et augmente le nombre de clés agrégées par seconde. Pour les compartiments de répertoire, utilisez des opérations de liste délimitées dans la mesure du possible. Les listes délimitées réduisent le nombre de visites dans les annuaires, ce qui se traduit par un plus grand nombre de clés par seconde et une latence des demandes plus faible.

Par exemple, pour les répertoires et objets suivants de votre bucket de répertoire :

s3://my-bucket/2024/04/12-01-file1 s3://my-bucket/2024/04/12-01-file2 ... s3://my-bucket/2024/05/12-01-file1 s3://my-bucket/2024/05/12-01-file2 ... s3://my-bucket/2024/06/12-01-file1 s3://my-bucket/2024/06/12-01-file2 ... s3://my-bucket/2024/07/12-01-file1 s3://my-bucket/2024/07/12-01-file2 ...

Pour de meilleures ListObjectsV2 performances, utilisez une liste délimitée pour répertorier vos sous-répertoires et vos objets, si la logique de votre application le permet. Par exemple, vous pouvez exécuter la commande suivante pour l'opération de liste délimitée :

aws s3api list-objects-v2 --bucket my-bucket --prefix '2024/' --delimiter '/'

Le résultat est la liste des sous-répertoires.

{ "CommonPrefixes": [ { "Prefix": "2024/04/" }, { "Prefix": "2024/05/" }, { "Prefix": "2024/06/" }, { "Prefix": "2024/07/" } ] }

Pour répertorier chaque sous-répertoire avec de meilleures performances, vous pouvez exécuter une commande comme dans l'exemple suivant :

Commande :

aws s3api list-objects-v2 --bucket my-bucket --prefix '2024/04' --delimiter '/'

Sortie :

{ "Contents": [ { "Key": "2024/04/12-01-file1" }, { "Key": "2024/04/12-01-file2" } ] }

Regroupement du stockage S3 Express One Zone et de vos ressources de calcul

Avec S3 Express One Zone, chaque compartiment de répertoire est situé dans une seule zone de disponibilité que vous sélectionnez lorsque vous créez le compartiment. Vous pouvez commencer par créer un nouveau compartiment de répertoires dans une zone de disponibilité locale pour vos charges de travail ou vos ressources de calcul. Vous pouvez alors commencer immédiatement des opérations de lecture et d’écriture à très faible latence. Les compartiments de répertoire sont un type de compartiments S3 dans lesquels vous pouvez choisir la zone de disponibilité dans un Région AWS afin de réduire le temps de latence entre le calcul et le stockage.

Si vous accédez à des compartiments d'annuaire à travers des zones de disponibilité, il est possible que vous rencontriez une légère augmentation de la latence. Pour optimiser les performances, nous vous recommandons d’accéder à un compartiment de répertoires depuis des instances Amazon Elastic Container Service, Amazon Elastic Kubernetes Service et Amazon Elastic Compute Cloud situées dans la même zone de disponibilité, quand cela est possible.

Utilisez des connexions simultanées pour atteindre un débit élevé avec des objets de plus de 1 Mo

Vous pouvez optimiser les performances en adressant plusieurs demandes simultanées aux compartiments de répertoires pour répartir vos demandes sur des connexions distinctes et augmenter au maximum la bande passante accessible. À l'instar des compartiments à usage général, S3 Express One Zone n'impose aucune limite quant au nombre de connexions établies avec votre compartiment d'annuaire. Les répertoires individuels peuvent mettre à l’échelle horizontalement et automatiquement les performances quand un grand nombre d’écritures simultanées sont effectuées dans le même répertoire.

Les connexions TCP individuelles aux compartiments de répertoire ont une limite supérieure fixe pour le nombre d'octets pouvant être chargés ou téléchargés par seconde. Lorsque les objets grossissent, les temps de requête sont dominés par le streaming d'octets plutôt que par le traitement des transactions. Pour utiliser plusieurs connexions afin de paralléliser le chargement ou le téléchargement d'objets plus volumineux, vous pouvez réduire end-to-end le temps de latence. Si vous utilisez le Java 2.x SDK, vous devriez envisager d'utiliser le S3 Transfer Manager, qui bénéficiera des améliorations de performances, telles que les opérations d'API de téléchargement partitionné et les extractions par plage d'octets pour accéder aux données en parallèle.

Utiliser les points de terminaison VPC Gateway

Les points de terminaison de passerelle fournissent une connexion directe entre votre VPC et les compartiments de répertoire, sans nécessiter de passerelle Internet ou de périphérique NAT pour votre VPC. Pour réduire le temps que vos paquets passent sur le réseau, vous devez configurer votre VPC avec un point de terminaison VPC passerelle pour les compartiments de répertoire. Pour de plus amples informations, veuillez consulter Mise en réseau des compartiments de répertoires.

Utilisez l'authentification de session et réutilisez les jetons de session lorsqu'ils sont valides

Les compartiments d'annuaire fournissent un mécanisme d'authentification par jeton de session pour réduire la latence lors des opérations d'API sensibles aux performances. Vous pouvez passer un seul appel pour CreateSession obtenir un jeton de session qui sera ensuite valide pour toutes les demandes dans les 5 minutes suivantes. Pour réduire au maximum la latence de vos appels d'API, assurez-vous d'acquérir un jeton de session et de le réutiliser pendant toute la durée de vie de ce jeton avant de l'actualiser.

Si vous l'utilisez AWS SDKs, SDKs gérez automatiquement les actualisations des jetons de session afin d'éviter les interruptions de service à l'expiration d'une session. Nous vous recommandons d'utiliser le AWS SDKs pour lancer et gérer les demandes relatives à l'opération CreateSession API.

Pour plus d’informations sur CreateSession, consultez Autorisation des opérations d’API de point de terminaison zonal avec CreateSession.

Utiliser un client CRT

Le AWS Common Runtime (CRT) est un ensemble de bibliothèques modulaires, performantes et efficaces écrites en C et destinées à servir de base au AWS SDKs. Le CRT fournit un débit amélioré, une meilleure gestion des connexions et des temps de démarrage plus rapides. Le CRT est disponible sur tous les réseaux AWS SDKs sauf Go.

Pour plus d'informations sur la configuration du CRT pour le SDK que vous utilisez, consultez les bibliothèques AWS Common Runtime (CRT), Accélérez le débit d'Amazon S3 avec le AWS Common Runtime, Présentation duclient S3 basé sur CRT et du gestionnaire de transfert S3 dans le SDK pour Java AWS 2.x, Utilisation de S3 pour les opérations CrtClient Amazon S3 et Configuration des clients HTTP basés sur le CRT. AWS

Utilisez la dernière version du AWS SDKs

Ils AWS SDKs fournissent un support intégré pour de nombreuses directives recommandées pour optimiser les performances d'Amazon S3. Ils SDKs proposent une API plus simple pour tirer parti d'Amazon S3 depuis une application et sont régulièrement mis à jour pour suivre les meilleures pratiques les plus récentes. Par exemple, ils réessayent SDKs automatiquement les demandes après des 503 erreurs HTTP et gèrent les réponses lentes aux connexions.

Si vous utilisez le Java 2.x SDK, vous devriez envisager d'utiliser le gestionnaire de transfert S3, qui redimensionne automatiquement les connexions horizontalement pour traiter des milliers de demandes par seconde en utilisant des requêtes par plage d'octets, le cas échéant. Les requêtes par plage d'octets peuvent améliorer les performances car vous pouvez utiliser des connexions simultanées à S3 pour récupérer différentes plages d'octets au sein d'un même objet. Vous pouvez ainsi parvenir au regroupement de débits le plus élevé, par opposition à une seule demande d’objet entier. Il est donc important d'utiliser la dernière version du AWS SDKs pour obtenir les dernières fonctionnalités d'optimisation des performances.

Dépannage des performances

Configurez-vous des demandes de nouvelle tentative pour les applications sensibles à la latence ?

La classe S3 Express One Zone est spécialement conçue pour fournir des niveaux élevés constants de performances sans réglages supplémentaires. Toutefois, la définition de valeurs de délai d’attente et de nouvelles tentatives agressives contribue également à garantir une latence et des performances constantes. Ils AWS SDKs ont des valeurs de délai d'expiration et de nouvelle tentative configurables que vous pouvez ajuster en fonction des tolérances de votre application spécifique.

Utilisez-vous des bibliothèques CRT ( AWS Common Runtime) et des types d' EC2 instances Amazon optimaux ?

Les applications qui effectuent un grand nombre d’opérations de lecture et d’écriture ont probablement besoin de plus de mémoire et de capacité de calcul que les autres. Lorsque vous lancez vos instances Amazon Elastic Compute Cloud (Amazon EC2) pour votre charge de travail exigeante en performances, choisissez des types d'instances dotés de la quantité de ressources dont votre application a besoin. Le stockage hautes performances S3 Express One Zone est idéalement associé à des types d'instances plus grands et plus récents, dotés d'une plus grande quantité de mémoire système et plus puissants, CPUs et GPUs qui peuvent tirer parti d'un stockage plus performant. Nous recommandons également d'utiliser les dernières versions de la technologie compatible CRT AWS SDKs, qui permettent de mieux accélérer les requêtes de lecture et d'écriture en parallèle.

Utilisez-vous une authentification basée sur AWS SDKs les sessions ?

Avec Amazon S3, vous pouvez également optimiser les performances lorsque vous utilisez des requêtes d'API HTTP REST en suivant les mêmes bonnes pratiques que celles décrites dans le AWS SDKs. Toutefois, compte tenu du mécanisme d'autorisation et d'authentification basé sur les sessions utilisé par S3 Express One Zone, nous vous recommandons vivement d'utiliser le AWS SDKs to manage CreateSession et son jeton de session géré. Créez et actualisez AWS SDKs automatiquement les jetons en votre nom à l'aide de l'opération CreateSession API. Utilisation d'CreateSessionéconomies sur le temps de latence aller-retour par demande vers AWS Identity and Access Management (IAM) pour autoriser chaque demande.

Exemples d'opérations de bucket et d'interactions entre annuaires

Voici trois exemples illustrant le fonctionnement des compartiments de répertoire.

Exemple 1 : Comment les PutObject requêtes S3 adressées à un compartiment de répertoire interagissent avec les annuaires

  1. Lorsque l'opération PUT(<bucket>, "documents/reports/quarterly.txt") est exécutée dans un compartiment vide, le répertoire documents/ situé à la racine du compartiment est créé, le répertoire situé à l'reports/intérieur documents/ est créé et l'objet qu'reports/il quarterly.txt contient est créé. Pour cette opération, deux répertoires ont été créés en plus de l'objet.

    Schéma montrant la structure du répertoire après l'opération PUT pour documents/reports/quarterly.txt
  2. Ensuite, lorsqu'une autre opération PUT(<bucket>, "documents/logs/application.txt") est exécutée, le répertoire existe documents/ déjà, le logs/ répertoire qu'il contient documents/ n'existe pas et est créé, et l'objet qu'logs/il application.txt contient est créé. Pour cette opération, un seul répertoire a été créé en plus de l'objet.

    Schéma montrant la structure du répertoire après l'opération PUT pour documents/logs/application.txt
  3. Enfin, lorsqu'une PUT(<bucket>, "documents/readme.txt") opération est exécutée, le répertoire situé documents/ dans la racine existe déjà et l'objet readme.txt est créé. Pour cette opération, aucun répertoire n'est créé.

    Schéma montrant la structure du répertoire après l'opération PUT pour documents/readme.txt

Exemple 2 : Comment les ListObjectsV2 requêtes S3 adressées à un compartiment de répertoire interagissent avec les annuaires

Pour les ListObjectsV2 demandes S3 sans spécifier de délimiteur, un compartiment est parcouru en fonction de la profondeur d'abord. Les sorties sont renvoyées dans un ordre cohérent. Cependant, bien que cet ordre reste le même entre les demandes, il n'est pas lexicographique. Pour le bucket et les répertoires créés dans l'exemple précédent :

  1. Lorsque a LIST(<bucket>) est exécuté, le répertoire documents/ est saisi et la traversée commence.

  2. Le sous-répertoire logs/ est saisi et la traversée commence.

  3. L'objet application.txt se trouve à l'intérieurlogs/.

  4. Aucune autre entrée n'existe danslogs/. L'opération List sort de logs/ puis entre à documents/ nouveau.

  5. Le documents/ répertoire continue d'être parcouru et l'objet readme.txt est trouvé.

  6. Le documents/ répertoire continue d'être parcouru, le sous-répertoire reports/ est entré et le parcours commence.

  7. L'objet quarterly.txt se trouve à l'intérieurreports/.

  8. Aucune autre entrée n'existe dansreports/. La liste sort de la liste reports/ et y entre documents/ à nouveau.

  9. Aucune autre entrée n'existe documents/ et la liste revient.

Dans cet exemple, logs/ est commandé avant readme.txt et readme.txt est commandé avantreports/.

Exemple 3 : Comment les DeleteObject requêtes S3 adressées à un compartiment de répertoire interagissent avec les annuaires

Schéma illustrant la structure initiale du répertoire avant les opérations DELETE
  1. Dans ce même compartiment, lorsque l'opération DELETE(<bucket>, "documents/reports/quarterly.txt") est exécutée, l'objet quarterly.txt est supprimé, laissant le répertoire reports/ vide et provoquant sa suppression immédiate. Le documents/ répertoire n'est pas vide car il contient à la fois le répertoire logs/ et l'objetreadme.txt. Il n'est donc pas supprimé. Pour cette opération, un seul objet et un seul répertoire ont été supprimés.

    Schéma illustrant la structure du répertoire après l'opération DELETE pour documents/reports/quarterly.txt
  2. Lorsque l'opération DELETE(<bucket>, "documents/readme.txt") est exécutée, l'objet readme.txt est supprimé. documents/n'est toujours pas vide car il contient le répertoirelogs/, il n'est donc pas supprimé. Pour cette opération, aucun répertoire n'est supprimé et seul l'objet est supprimé.

    Schéma illustrant la structure du répertoire après l'opération DELETE pour documents/readme.txt
  3. Enfin, lorsque l'opération DELETE(<bucket>, "documents/logs/application.txt") est exécutée, elle application.txt est supprimée, la laissant logs/ vide et entraînant sa suppression immédiate. Cela reste alors documents/ vide et le supprime également immédiatement. Pour cette opération, deux répertoires et un objet sont supprimés. Le compartiment est maintenant vide.

    Schéma illustrant la structure du répertoire après l'opération DELETE pour documents/logs/application.txt