Modèles de conception des performances pour Amazon S3

Lors de la conception d’applications pour télécharger et extraire des objets depuis Amazon S3, utilisez nos modèles de conception des bonnes pratiques pour parvenir aux meilleures performances de votre application. Nous vous proposons aussi de prendre en compte des Recommandations de performance pour Amazon S3 lors de la planification de l’architecture de votre application.

Pour optimiser les performances, vous pouvez utiliser les modèles de conception suivants.

Utilisation de la mise en cache pour le contenu consulté fréquemment

La plupart des applications qui stockent des données dans Amazon S3 traitent un « ensemble opérationnel » de données, demandé à maintes reprises par les utilisateurs. Si une charge de travail envoie des demandes GET répétées pour un ensemble commun d’objets, vous pouvez utiliser un cache comme Amazon CloudFront, Amazon ElastiCache ou AWS Elemental MediaStore pour optimiser les performances. L’adoption réussie du cache peut se traduire par une latence faible et des taux élevés de transfert des données. Les applications qui utilisent la mise en cache envoient aussi moins de demandes directes à Amazon S3, ce qui peut aider à réduire les coûts des demandes.

Amazon CloudFront est un réseau de diffusion de contenu (CDN) rapide qui met en cache de façon transparente les données depuis Amazon S3 dans un large ensemble de points de présence (PoP) géographiquement répartis. Lorsqu’il est possible d’accéder aux objets depuis plusieurs régions, ou sur Internet, CloudFront permet que les données soient mises en cache à côté des utilisateurs qui accèdent aux objets. Il peut en résulter une diffusion haute performance des contenus Amazon S3 réputés. Pour plus d’informations sur l’utilisation de CloudFront, consultez le Guide du développeur Amazon CloudFront.

Amazon ElastiCache est un cache en mémoire géré. Avec ElastiCache, vous pouvez provisionner des instances Amazon EC2 qui mettent en cache des objets en mémoire. Cette mise en cache se traduit par des ordres de réduction de magnitude dans la latence GET et de substantielles augmentations dans le débit de téléchargement. Pour utiliser ElastiCache, vous modifiez la logique de l’application pour remplir le cache avec des objets sensibles et vérifier la présence d’objets sensibles dans le cache avant de les demander auprès de Amazon S3. Pour des exemples d’utilisation d’ElastiCache pour améliorer les performances GET d’Amazon S3, consultez le billet de blog Turbocharge Amazon S3 with Amazon ElastiCache for Redis.

AWS Elemental MediaStore est un système de mise en cache et de distribution de contenu spécialement conçu pour les flux de travail vidéo et la diffusion multimédia depuis Amazon S3. MediaStore fournit des API de stockage de bout en bout spécifiquement pour la vidéo et est recommandé pour les charges de travail vidéo sensibles aux performances. Pour en savoir plus sur MediaStore, consultez le Guide de l’utilisateur AWS Elemental MediaStore.

Délais d’expiration et nouvelles tentatives pour les applications sensibles à la latence

Dans certaines situations, une application reçoit une réponse d’Amazon S3 indiquant qu’une nouvelle tentative est nécessaire. Amazon S3 mappe les noms de compartiment et d’objet aux données d’objet qui leur sont associées. Si une application génère des taux de demande élevés (généralement des taux soutenus de plus de 5 000 demandes par seconde pour un petit nombre d’objets), elle peut recevoir des réponses HTTP 503 slowdown. Si ces erreurs se produisent, chaque kit AWS SDK implémente une logique de nouvelle tentative automatique à l’aide d’une interruption exponentielle. Si vous n’utilisez pas de kit AWS SDK, vous devez implémenter une logique de nouvelle tentative lors de la réception de l’erreur HTTP 503. Pour plus d’informations sur les techniques d’interruption, consultez Comportement de nouvelle tentative dans le Guide de référence des outils et des kits AWS SDK.

Amazon S3 se met automatiquement à l’échelle en réponse aux taux soutenus de nouvelles demandes, optimisant dynamiquement les performances. Tandis qu’Amazon S3 optimise en interne le taux de nouvelles demandes, vous recevez temporairement des réponses HTTP 503 jusqu’à ce que l’optimisation soit terminée. Après qu’Amazon S3 optimise en interne les performances pour le nouveau taux de demandes, toutes les demandes sont généralement traitées sans nouvelles tentatives.

Pour les applications sensibles à la latence, Amazon S3 conseille un suivi et des opérations de nouvelles tentatives plus lentes. Lorsque vous retentez une demande, nous recommandons l’utilisation d’une nouvelle connexion à Amazon S3 et l’exécution d’une nouvelle recherche DNS.

Lorsque vous effectuez des demandes volumineuses de taille variable (par exemple, plus de 128 Mo), nous conseillons de suivre le débit obtenu et de procéder à de nouvelles tentatives sur les 5 % les plus lents des demandes. Lorsque vous exécutez des demandes plus petites (par exemple, inférieures à 512 Ko), où les latences médianes sont souvent dans une plage de dix millisecondes, une bonne instruction consiste à retenter une opération GET ou PUT après 2 secondes. Si de nouvelles tentatives sont nécessaires, la bonne pratique consiste à se retirer. Par exemple, nous recommandons de n’émettre une nouvelle tentative qu’après 2 secondes et une deuxième nouvelle tentative au bout de 4 secondes supplémentaires.

Si votre application adresse des demandes de taille fixe à Amazon S3, vous devez escompter des temps de réponse plus cohérents pour chacune de ces demandes. Dans ce cas, une stratégie simple consiste à identifier le 1 % de demandes les plus lentes et de les réessayer. Même une simple nouvelle tentative est fréquemment efficace pour réduire la latence.

Si vous utilisez AWS Key Management Service (AWS KMS) pour le chiffrement côté serveur, consultez Quotas dans le Guide du développeur AWS Key Management Service pour obtenir des informations sur les taux de demandes pris en charge pour votre cas d’utilisation.

Mise à l’échelle horizontale et mise en parallèle des demandes pour le haut débit

Amazon S3 est un système distribué très large. Pour vous aider à tirer parti de son échelle, nous vous encourageons à horizontalement mettre à l’échelle les demandes parallèles adressées aux points de terminaison du service Amazon S3. En plus de la distribution des demandes au sein d’Amazon S3, ce type d’approche de la mise à l’échelle permet de répartir la charge sur plusieurs chemins d’accès du réseau.

Pour les transferts à haut débit, Amazon S3 conseille l’utilisation d’applications employant plusieurs connexions pour exécuter des opérations GET ou PUT sur les données en parallèle. Par exemple, cet aspect est pris en charge par le Gestionnaire de transferts Amazon S3 du kit SDK AWSJava, et la plupart des autres kits AWS SDK fournissent des constructions similaires. Pour certaines applications, vous pouvez obtenir des connexions parallèles en lançant plusieurs demandes simultanément dans différents threads d’application ou dans différentes instances d’application. La meilleure approche à adopter dépend de votre application et de la structure des objets auxquels vous accédez.

Vous pouvez utiliser les kits AWS SDK pour émettre des requêtes GET et PUT directement plutôt que d’utiliser la gestion des transferts dans le kit SDK AWS. Cette approche vous permet d’affiner votre charge de travail plus directement, tout en tirant profit du support du kit SDK pour les nouvelles tentatives et sa gestions des réponses HTTP 503 qui peuvent se produire. En règle générale, lorsque vous téléchargez des objets volumineux au sein d’une région depuis Amazon S3 vers Amazon EC2, nous vous suggérons d’effectuer des demandes simultanées pour les plages d’octets d’un objet avec la granularité de 8 à 16 Mo. Effectuez une seule demande simultanée pour chaque 85-90 Mbits/s du débit réseau souhaité. Pour saturer une carte NIC 10 Gbits/s, vous pouvez utiliser jusqu’à 15 demandes simultanées sur des connexions distinctes. Vous pouvez augmenter les demandes simultanées sur plusieurs connexions pour saturer les NIC les plus rapides, telles que les NIC 25 Gbits/s ou 100 Gbits/s.

La mesure des performances est importante quand vous réglez le nombre de demandes à émettre simultanément. Il est recommandé de commencer avec une seule demande à la fois. Mesurez la bande passante réseau obtenue et l’utilisation des autres ressources que votre application utilise dans le traitement des données. Vous pouvez alors identifier la ressource du goulet d’étranglement (à savoir, la ressource avec l’utilisation la plus élevée), et de là le nombre de requêtes susceptibles d’être utiles. Par exemple, si le traitement d’une demande à la fois conduit à une utilisation de l’UC de 25 %, cela induit que quatre demandes simultanées au plus peuvent être accueillies. Les mesures sont essentielles et il vaut la peine de confirmer l’utilisation des ressources tandis que le taux des demandes augmente.

Si votre application adresse directement des demandes à Amazon S3 à l’aide de l’API REST, nous recommandons l’utilisation d’un groupe de connexions HTTP et la réutilisation de chaque connexion pour un ensemble de demandes. Le fait d’éviter la configuration des connexions par demande supprime la nécessité d’exécuter des liaisons TCP à démarrage lent et SSL (Secure Sockets Layer) sur chaque demande. Pour plus d’informations sur l’utilisation de l’API REST, consultez la Référence des API Amazon Simple Storage Service.

Enfin, il vaut la peine de prêter attention à DNS et de vérifier que les demandes sont réparties sur un vaste groupe d’adresses IP Amazon S3. Les requêtes DNS pour le Amazon S3 parcourent une large liste de points de terminaison IP. Mais la mise en cache des programmes de résolution ou du code d’application qui réutilise une seule adresse IP ne tire pas parti de la diversité des adresses et de l’équilibrage de charge qui en découle. Les outils d’utilitaire réseau comme l’outil de ligne de commande netstat peuvent afficher les adresses IP utilisées pour la communication avec Amazon S3 et nous fournissons des instructions sur les configurations DNS à utiliser. Pour plus d’informations sur ces directives, consultez Envoi de demandes dans la Référence des API Amazon S3.

Utilisation d’Amazon S3 Transfer Acceleration pour accélérer les transferts de données disparates géographiquement

Configuration de transferts de fichiers rapides et sécurisés à l’aide d’Amazon S3 Transfer Acceleration est efficace pour réduire ou supprimer la latence provoquée par la distance géographique entre les clients dispersés géographiquement et une application régionale qui utilise Amazon S3. Transfer Acceleration utilise les emplacements périphériques répartis mondialement dans CloudFront pour le transport de données. Le réseau périphérique AWS dispose de points de présence dans plus de 50 emplacements. Aujourd’hui, il permet de diffuser le contenu via CloudFront et de fournir des réponses rapides aux requêtes DNS adressées à Amazon Route 53.

Le réseau périphérique aide également à accélérer les transferts de données dans et en dehors d’Amazon S3. Il convient parfaitement aux applications qui transfèrent les données entre les continents, ont une connexion Internet rapide, utilise des objets de grande taille ou ont un contenu volumineux à charger. Lorsque les données arrivent dans un emplacement périphérique, elles sont transférées vers Amazon S3 sur un chemin de réseau optimisé. En général, plus vous êtes loin d’une région Amazon S3, plus vous pouvez escompter une amélioration de la vitesse grâce à Transfer Acceleration.

Vous pouvez configurer Transfer Acceleration sur les compartiments nouveaux ou existants. Vous pouvez utiliser un point de terminaison Amazon S3 Transfer Acceleration distinct pour les emplacements périphériques AWS. Le meilleur moyen de tester si Transfer Acceleration améliore les performances des demandes des clients consiste à utiliser l’Outil de comparaison de la vitesse de Amazon S3 Transfer Acceleration. Les configurations et les états du réseau varient de temps à autre et d’emplacement à emplacement. Par conséquent, vous n’êtes facturé que pour les transferts où Amazon S3 Transfer Acceleration peut potentiellement améliorer vos performances de chargement. Pour plus d’informations sur l’utilisation de Transfer Acceleration avec différents kits AWS SDK, consultez Activation et utilisation de S3 Transfer Acceleration.

Optimisation pour les charges de travail à taux de demandes élevés

Les applications qui génèrent des taux de demandes élevés pour Amazon S3 exigent des modèles de conception spécifiques pour obtenir des performances optimales. Lorsque votre application génère systématiquement plus de 3 500 demandes PUT/COPY/POST/DELETE ou 5 500 demandes GET/HEAD par seconde et par préfixe, vous devez mettre en œuvre des stratégies afin de répartir les demandes et gérer le comportement de mise à l’échelle.

Amazon S3 se met automatiquement à l’échelle pour s’adapter à la hausse des taux de demandes, mais cette mise à l’échelle est progressive. Pendant ce processus, vous pouvez recevoir des réponses HTTP 503 (Ralentissement). Ces réponses sont temporaires et indiquent qu’Amazon S3 optimise ses systèmes internes pour s’adapter à votre nouveau modèle de demande. Une fois la mise à l’échelle terminée, vos demandes sont traitées sans limitation.

Pour optimiser les performances face aux charges de travail à taux de demandes élevés, envisagez les stratégies suivantes :

Pour les applications qui ont besoin de performances élevées constantes, pensez à utiliser Amazon S3 Express One Zone, qui a été conçu pour les applications nécessitant des latences à un chiffre en millisecondes et peut prendre en charge des centaines de milliers de demandes par seconde. Pour plus d’informations, consultez S3 Express One Zone.