Comment puis-je résoudre une erreur HTTP 500 ou 503 depuis Amazon S3 ?

Brève description

Amazon S3 renvoie une erreur d'état 5xx similaire aux exemples suivants :

• « Exception Amazon S3 : Erreur interne (Service : Amazon S3 ; code d'état : 500 ; Code d’erreur : Erreur interne 500 ; ID de demande : A4DBBEXAMPLE2C4D) »
• « Exception Amazon S3 : Ralentissez (Service : Amazon S3 ; code d'état : 503 ; Code d’erreur : 503 Ralentir ; ID de la demande : A4DBBEXAMPLE2C4D) »

Le code d'erreur 500 Erreur interne indique qu'Amazon S3 ne peut pas traiter la demande à ce moment-là. Le code d'erreur 503 Slow Down indique généralement que le nombre de demandes adressées à votre compartiment S3 est élevé. Par exemple, vous pouvez envoyer 3 500 requêtes PUT/COPI/POST/DELETE ou 5 500 requêtes GET/HEAD par seconde et par préfixe dans un compartiment S3. Toutefois, 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.
Pour résoudre ou éviter les erreurs d'état 5xx, essayez les approches suivantes :

• Pour l'application qui émet les demandes, utilisez un mécanisme de nouvelle tentative
• Configurez votre application pour augmenter progressivement les taux de demandes.
• Répartissez les objets sur plusieurs préfixes.
• Surveillez le nombre de réponses d'erreur 5xx.

Remarque : lorsqu'un préfixe est créé, Amazon S3 n'attribue pas automatiquement de ressources supplémentaires pour le taux de demandes pris en charge. Amazon S3 évolue en fonction des modèles de demandes. À mesure que le taux de demandes augmente, Amazon S3 optimise dynamiquement le nouveau taux de demandes.

Résolution

Utiliser un mécanisme de nouvelle tentative

En raison de la nature distribuée d'Amazon S3, vous pouvez réessayer les demandes qui renvoient des erreurs 500 ou 503. Il est recommandé d'intégrer une logique de nouvelle tentative dans les applications qui adressent des requêtes à Amazon S3.

Tous les kits SDK AWS sont dotés d'un mécanisme de nouvelle tentative intégré avec un algorithme qui utilise un retard exponentiel. Cet algorithme met en œuvre des temps d'attente de plus en plus longs entre les tentatives pour des réponses d'erreur consécutives. De nombreux algorithmes de backoff exponentiel utilisent le gigue (délai aléatoire) pour empêcher les collisions successives. Pour plus d'informations, consultez la section Comportement des nouvelles tentatives.

Remarque : Amazon S3 prend en charge des taux de requêtes allant jusqu'à 3 500 requêtes Put par seconde vers un seul préfixe. Dans certains scénarios, des requêtes Put simultanées et rapides adressées à la même clé peuvent entraîner une réponse 503. Dans ces cas, il est recommandé de réessayer les demandes qui ont échoué.

Configurez votre application pour augmenter progressivement les taux de demandes

Lorsque vous envoyez des demandes à un taux de requêtes élevé proche de la limite de débit, Amazon S3 renvoie 503 erreurs Slow Down. En cas d'augmentation soudaine du taux de requêtes pour les objets contenus dans un préfixe, vous recevez 503 erreurs de ralentissement. Configurez votre application pour maintenir le taux de demandes et implémentez une nouvelle tentative avec un backoff exponentiel. Cette solution donne à Amazon S3 le temps de surveiller les modèles de demandes et de mettre à l’échelle horizontale le backend pour gérer le taux de demandes.

Configurez votre application pour qu'elle démarre avec un taux de demandes inférieur (transactions par seconde) afin d'éviter l'erreur 503 Slow Down. Augmentez ensuite le taux de demandes de l'application de façon exponentielle. Amazon S3 est mis automatiquement à l’échelle pour gérer un taux de demandes plus élevé.

Répartissez les objets sur plusieurs préfixes

Les tarifs de demande s'appliquent par préfixe dans un compartiment Amazon S3. Pour configurer votre compartiment de manière à gérer des taux de demandes globalement plus élevés et pour éviter les ** erreurs ** 503 Slow Down, répartissez les objets entre plusieurs préfixes. Par exemple, si vous utilisez un compartiment Amazon S3 pour stocker des images et des vidéos, répartissez les fichiers sous deux préfixes :

• mybucket/images
• mybucket/vidéos

Si le taux de demandes sur les préfixes augmente progressivement, Amazon S3 augmente pour traiter les demandes pour chacun des deux préfixes séparément. Amazon S3 augmente pour gérer 3 500 requêtes PUT/POST/DELETE ou 5 500 requêtes GET par seconde et par préfixe. Par conséquent, le taux de demandes global traité par le compartiment double.

Surveillez le nombre de réponses d'erreur d'état 5xx

Pour contrôler le nombre de réponses d'erreur d'état 5xx que vous recevez, utilisez l'une des options suivantes :

• Activez les métriques Amazon CloudWatch. Les métriques de demande Amazon S3 CloudWatch incluent une métrique pour les réponses d'état 5xx.
• Activez la journalisation des accès au serveur Amazon S3. Étant donné que la journalisation des accès au serveur capture toutes les demandes, filtrez et examinez toutes les demandes qui reçoivent une réponse d'erreur 500/503. Utilisez Amazon Athena pour analyser les journaux.

Autres raisons des erreurs 5xx

Lorsque vous utilisez le niveau de restauration accélérée pour récupérer des objets archivés, vous pouvez recevoir une erreur similaire aux exemples suivants :

• « GlacierExpeditedRetrievalNotAvailable »
• « Les extractions accélérées de Glacier ne sont actuellement pas disponibles, veuillez réessayer ultérieurement »

Ces erreurs se produisent si la capacité est insuffisante pour traiter la demande accélérée.

Pendant une période de forte demande soutenue, Amazon S3 peut refuser les demandes de récupération accélérée et renvoyer une erreur 503. Utilisez les unités de capacité provisionnées (PCU) pour vous assurer que la capacité d'extraction pour les extractions accélérées est disponible à la demande. Chaque unité permet d'effectuer au moins trois extractions accélérées toutes les 5 minutes. Chaque unité fournit jusqu'à 150 mégaoctets par seconde (Mbit/s) de débit de récupération. Vous pouvez également utiliser les options de récupération « Standard » ou « Bulk ».

Vous pouvez réessayer la récupération, mais cela ne garantit pas le succès. Sauf en cas de demande extrême, les extractions accélérées sont possibles sans capacité provisionnée. En raison de l'évolution constante et de la forte demande de disponibilité de la récupération accélérée à partir de capacités non provisionnées, AWS Support ne fournit pas de contrat de niveau de service garanti.

Si vous continuez à recevoir un taux d'erreur de 5xx élevé, contactez AWS Support. Incluez plusieurs paires d’ID de demande Amazon S3 pour les demandes qui échouent avec un code d'erreur d'état 5xx.

Informations connexes

Résolution des problèmes liés à Amazon S3

Surveillance des métriques avec Amazon CloudWatch