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 Transfer Manager Amazon S3 dans le kit AWS Java SDK, et la plupart des autres kits SDK AWS 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 demandes GET et PUT directement plutôt que d’utiliser la gestion des transferts dans le kit AWS SDK. Cette approche permet d'affiner la charge de travail plus directement, tout en tirant profit du support du kit SDK pour les nouvelles tentatives et la gestion 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 dans le goulet d'étranglement (c.-à-d., la ressource avec l'utilisation la plus élevée) et de là le nombre de demandes 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 en savoir plus sur l'utilisation de l'API REST, consultez l'Introduction sur les API REST dans Amazon S3.
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 en savoir plus sur ces instructions, consultez la section Routage des demandes.
