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.
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 Directives relatives aux performances 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.
Rubriques
- Utilisation de la mise en cache pour le contenu fréquemment consulté
- Délais et nouvelles tentatives pour les applications sensibles à la latence
- Mise à l'échelle horizontale et parallélisation des demandes pour un débit élevé
- Utilisation d'Amazon S3 Transfer Acceleration pour accélérer les transferts de données géographiquement disparates
Utilisation de la mise en cache pour le contenu fréquemment consulté
La plupart des applications qui stockent les 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 GET demandes répétées pour un ensemble commun d'objets, vous pouvez utiliser un cache tel qu'Amazon CloudFront ElastiCache, Amazon ou AWS Elemental MediaStorepour 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 rapide (CDN) qui met en cache de manière transparente les données d'Amazon S3 dans un grand nombre de points de présence répartis géographiquement ()PoPs. Lorsque des objets sont accessibles depuis plusieurs régions ou via Internet, cela CloudFront permet aux données d'être mises en cache à proximité 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 à ce sujet CloudFront, consultez le manuel Amazon CloudFront Developer Guide.
Amazon ElastiCache est un cache en mémoire géré. Avec ElastiCache, vous pouvez provisionner des EC2 instances Amazon qui mettent en cache des objets en mémoire. Cette mise en cache entraîne une réduction de plusieurs ordres de grandeur de la GET latence et une augmentation substantielle du débit de téléchargement. Pour l'utiliser ElastiCache, vous modifiez la logique de l'application pour remplir le cache avec des objets chauds et vérifier la présence d'objets chauds dans le cache avant de les demander à Amazon S3. Pour des exemples d'utilisation visant ElastiCache à améliorer les GET performances d'Amazon S3, consultez le billet de blog Turbocharger Amazon S3 avec Amazon ElastiCache pour 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 de contenu multimédia à partir d'Amazon S3. MediaStore fournit un end-to-end stockage APIs spécifique pour les vidéos et est recommandé pour les charges de travail vidéo sensibles aux performances. Pour plus d'informations MediaStore, consultez le guide de AWS Elemental MediaStore l'utilisateur.
Délais 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 requêtes é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 HTTP 503 réponses de ralentissement. Si ces erreurs se produisent, chacune AWS SDK implémente une logique de nouvelle tentative automatique utilisant un retard exponentiel. Si vous n'utilisez pas un AWS SDK, vous devez implémenter une logique de nouvelle tentative lorsque vous recevez l'erreur HTTP 503. Pour plus d'informations sur les techniques de réduction, consultez la section Comportement des nouvelles tentatives dans le guide de référence des outils AWS SDKs et.
Amazon S3 se met automatiquement à l'échelle en réponse aux taux soutenus de nouvelles demandes, optimisant dynamiquement les performances. Pendant qu'Amazon S3 optimise en interne un nouveau taux de demandes, vous recevrez HTTP 503 réponses aux demandes temporairement 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 réessayez une demande, nous vous recommandons d'utiliser une nouvelle connexion à Amazon S3 et d'effectuer une nouvelle DNS recherche.
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 faites des demandes plus petites (par exemple, moins de 512 Ko), où les latences médianes sont souvent de l'ordre de plusieurs dizaines de millisecondes, il est conseillé de réessayer une opération GET OR 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 delandes 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 la section Quotas du guide du AWS Key Management Service développeur pour obtenir des informations sur les taux de demandes pris en charge pour votre cas d'utilisation.
Mise à l'échelle horizontale et parallélisation des demandes pour un débit élevé
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 d'utiliser des applications qui utilisent plusieurs connexions GET ou des PUT données en parallèle. Par exemple, cela est pris en charge par Amazon S3 Transfer Manager en AWS JavaSDK, et la plupart des autres AWS SDKs proposent 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 le AWS SDKs pour émettre GET et PUT demander directement plutôt que d'utiliser la gestion des transferts dans le AWS SDK. Cette approche vous permet d'ajuster votre charge de travail plus directement, tout en bénéficiant SDK de la prise en charge des nouvelles tentatives et de sa gestion des HTTP 503 réponses qui pourraient survenir. 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 de demander simultanément des plages d'octets d'un objet d'une granularité de 8 à 16 Mo. Effectuez une demande simultanée pour chaque tranche de 85 à 90. MB/s of desired network throughput. To saturate a 10 Gb/s network interface card (NIC), you might use about 15 concurrent requests over separate connections. You can scale up the concurrent requests over more connections to saturate faster NICs, such as 25 Gb/s or 100 Gb/s NICs
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 suscpetibles d’être utiles. Par exemple, si le traitement d'une demande à la fois entraîne une CPU utilisation de 25 %, cela suggère qu'il est possible de traiter jusqu'à quatre demandes simultanées. 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 envoie des demandes directement à Amazon S3 à l'aide du RESTAPI, nous vous recommandons d'utiliser un pool de HTTP connexions et de réutiliser chaque connexion pour une série de demandes. En évitant de configurer une connexion par demande, il n'est plus nécessaire d'effectuer des poignées de main au TCP démarrage lent et au protocole Secure Sockets Layer (SSL) pour chaque demande. Pour plus d'informations sur l'utilisation du RESTAPI, consultez le Amazon Simple Storage Service API Reference.
Enfin, il convient de prêter attention DNS et de vérifier que les demandes sont réparties sur un large pool d'adresses IP Amazon S3. DNSles requêtes pour Amazon S3 passent par une longue 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 utilitaires réseau tels que l'outil de ligne de netstat commande peuvent afficher les adresses IP utilisées pour communiquer avec Amazon S3, et nous fournissons des directives relatives aux DNS configurations à utiliser. Pour plus d'informations sur ces directives, consultez la section Faire des demandes dans le manuel Amazon S3 API Reference.
Utilisation d'Amazon S3 Transfer Acceleration pour accélérer les transferts de données géographiquement disparates
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 dans le monde entier CloudFront pour le transport des données. Le réseau AWS périphérique possède des points de présence dans plus de 50 sites. Aujourd'hui, il est utilisé pour diffuser du contenu via Amazon Route 53 CloudFront et pour fournir des réponses rapides aux DNS requêtes 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 utiliser les emplacements AWS périphériques. 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
