Comment résoudre une erreur HTTP 500 ou 503 provenant d'Amazon S3 ?

Dernière mise à jour : 17-12-2021

Lorsque j'effectue une demande de copie ou de chargement d'objet à Amazon Simple Storage Service (Amazon S3), celui-ci renvoie une réponse 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 ?

Brève description

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 le nombre de demandes adressées à votre compartiment S3 est très élevé, dépassant le taux de demandes. (Vous pouvez envoyer par exemple 3 500 demandes PUT/COPY/POST/DELETE ou 5 500 demandes GET/HEAD par seconde et par préfixe dans un compartiment S3.) Toutefois, dans certains cas, Amazon S3 peut renvoyer une réponse 503 Slow Down si vos demandes dépassent la quantité de bande passante disponible pour la copie entre régions.

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 provenant d'Amazon S3 peuvent faire l'objet d'une nouvelle tentative. Par conséquent, il est recommandé de disposer d'un mécanisme de tolérance aux pannes ou de mettre en place une logique de nouvelle tentative pour toutes les applications envoyant des demandes à Amazon S3. Ainsi, S3 peut se remettre de ces erreurs.

Pour résoudre ou éviter les erreurs 5xx, envisagez les approches suivantes :

  • Activez un mécanisme de nouvelle tentative dans l'application qui émet des demandes.
  • Configurez votre application de manière à augmenter graduellement le taux de demandes.
  • Distribuez des objets sur plusieurs préfixes.
  • Surveillez le nombre de réponses à l'erreur 500 Internal Error.
  • Copiez vos données en utilisant d'autres méthodes.

Solution

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. Pour mettre à jour la logique de nouvelle tentative de votre application, définissez le nombre de nouvelles tentatives de vos applications sur « 10 ».

Tous les kits AWS SDK 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 de backoff exponentiel utilisent l'instabilité (retard aléatoire) pour éviter des conflits successifs. Pour plus d'informations, consultez Nouvelles tentatives après erreur et backoff exponentiel dans AWS.

Configurer votre application de manière à augmenter graduellement le taux de demandes

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

Distribuer les objets sur plusieurs préfixes

Les taux de demande décrits dans Directives en matière de taux 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 taux 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 taux de demande sur les préfixes augmente progressivement, Amazon S3 se met à l'échelle pour traiter les demandes pour chacun des deux préfixes. (S3 se mettra à l'échelle pour traiter 3 500 requêtes PUT/POST/DELETE ou 5 500 requêtes GET par seconde.) Par conséquent, le taux de demande global traité par le compartiment double.

Surveiller le nombre de réponses à l'erreur 500 Internal Error

Pour surveiller le nombre de réponses à l'erreur 500 Internal Error que vous obtenez, vous pouvez utiliser l'une des options suivantes :

Copier vos données en utilisant d'autres méthodes

Pour les autres façons de copier des données entre des régions, envisagez les options suivantes :

  • Utilisez l'opération S3DistCp sur Amazon EMR. Pour plus d'informations, consultez Seven Tips for Using S3DistCp on Amazon EMR to Move Data Efficiently Between HDFS and Amazon S3 (Sept conseils pour l'utilisation de S3DistCp sur Amazon EMR pour déplacer efficacement des données entre HDFS et Amazon S3).
    Remarque : étant donné que cette approche nécessite l'utilisation d'Amazon EMR, veillez à consulter la tarification Amazon EMR.
  • Essayez une opération GET à partir du compartiment source, puis une opération PUT vers le compartiment de destination.
  • Activez la réplication entre régions (CRR) sur le compartiment source. La réplication entre régions copie automatiquement et de manière asynchrone les objets dans le compartiment de destination.
    Remarque : une fois que vous avez activé la réplication entre régions, les nouveaux objets sont automatiquement copiés dans le compartiment de destination. Les objets qui se trouvaient dans le compartiment source avant d'activer la réplication entre régions ne sont pas automatiquement copiés.

Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?