Lorsque j'envoie des demandes à Amazon Simple Storage Service (Amazon S3), Amazon S3 renvoie une réponse similaire à l'un des messages suivants :

AmazonS3Exception: Internal Error (Service: Amazon S3; Status Code: 500; Error Code: 500 Internal Error; Request ID: A4DBBEXAMPLE2C4D)
AmazonS3Exception: Slow Down (Service: Amazon S3; Status Code: 503; Error Code: 503 Slow Down; Request ID: A4DBBEXAMPLE2C4D)

Comment résoudre ces erreurs ?

Le code d'erreur 500 Internal Error indique qu'Amazon S3 n'est pas à même de gérer la demande actuellement. Le code d'erreur 503 Slow Down indique généralement que les demandes transmises au compartiment S3 sont très élevées et dépassent les débits de demandes décrit dans Directives en matière de débit de demandes et de performances.

Amazon S3 étant un service distribué, un très faible pourcentage d'erreurs 5xx est attendu pendant l'utilisation normale du service. Toutes les demandes qui renvoient des erreurs 5xx en provenance d'Amazon S3 peuvent et doivent faire l'objet d'une nouvelle tentative. C'est pourquoi nous recommandons que les applications qui envoient des demandes à Amazon S3 disposent d'un mécanisme de tolérance aux pannes pour récupérer suite à ces erreurs.

Pour résoudre ou éviter les erreurs 5xx, essayez les solutions suivantes :

  • Activer un mécanisme de nouvelle tentative dans l'application qui émet des demandes
  • Configurer votre application de manière à augmenter graduellement le débit de demandes
  • Distribuer les objets sur plusieurs préfixes

Activer un mécanisme de nouvelle tentative dans l'application qui émet des demandes

En raison de la nature distribuée d'Amazon S3, les demandes qui renvoient des erreurs 500 ou 503 peuvent faire l'objet d'une nouvelle tentative. Créer une logique de nouvelle tentative dans des applications qui envoient des demandes à Amazon S3 constitue une bonne pratique. Il est recommandé de définir le nombre de nouvelles tentatives à 10 pour vos applications.

Tous les kits SDK AWS ont un mécanisme de nouvelle tentative intégré avec un algorithme qui utilise le backoff exponentiel. L'algorithme implémente des temps d'attente de plus en plus longs entre les tentatives en cas de réponses d'erreur consécutives. La plupart des algorithmes d'interruption exponentielle utilisent l'instabilité (retard aléatoire) pour éviter les conflits successifs. Pour plus d'informations, consultez la section Nouvelles tentatives après erreur et interruptions exponentielles dans AWS.

Configurer votre application de manière à augmenter graduellement le débit de demandes

Pour éviter les erreurs 503 Slow Down, essayez de configurer votre application de sorte qu'elle démarre avec un débit de demandes (nombre de transactions par seconde) faible. Ensuite, augmentez de manière exponentielle le débit de demandes de l'application. Amazon S3 se met automatiquement à l'échelle afin de gérer un débit de demandes élevé.

Distribuer les objets sur plusieurs préfixes

Les débits de demande décrits dansDirectives en matière de débit de demandes et de performances s'appliquent par préfixe dans un compartiment S3. Pour configurer votre compartiment de manière à gérer globalement des débits de demande élevés et à éviter les erreurs 503 Slow Down, vous pouvez distribuer les objets sur plusieurs préfixes. Par exemple, si vous utilisez votre compartiment S3 pour stocker des images et des vidéos, vous pouvez distribuer les fichiers dans deux préfixes, comme suit :

  • mybucket/images
  • mybucket/videos

Si le débit de demandes sur les préfixes augmente graduellement, Amazon S3 se met à l'échelle de manière à gérer les demandes pour chacun des deux préfixes (3 500 demandes PUT/POST/DELETE ou 5 500 demandes GET par seconde) ; ainsi, le débit de demandes global géré par le compartiment est multiplié par deux.


Cette page vous a-t-elle été utile ? Oui | Non

Retour au Centre de connaissances AWS Support

Vous avez besoin d'aide ? Consultez le site du Centre AWS Support

Date de publication : 18/09/2018