Comment résoudre les erreurs HTTP 504 qui s'affichent lorsque j'utilise un Classic Load Balancer ?

Lecture de 4 minute(s)
0

Je vois des erreurs HTTP 504 dans les journaux d'accès du Classic Load Balancer, dans les métriques Amazon CloudWatch ou lorsque je me connecte à mon service par le biais d'un Classic Load Balancer.

Résolution

Une erreur HTTP 504 est un code d'état HTTP indiquant qu'une passerelle ou un proxy a expiré. Lors de la résolution du problème, vérifiez les éléments suivants :

Vérifiez le délai d'inactivité de l'équilibreur de charge et modifiez-le si nécessaire

La raison la plus courante d'une erreur HTTP 504 est qu'une instance correspondante n'a pas répondu à la demande dans le délai d'inactivité configuré. Par défaut, le délai d'inactivité d'un Classic Load Balancer est de 60 secondes.

Si les métriques CloudWatch sont activées, consultez les métriques CloudWatch de votre équilibreur de charge. Lorsque les points de données de latence sont égaux à la valeur de délai d'expiration de votre équilibreur de charge configurée et que le HttpCode_ELB_5XX contient des points de données, au moins une demande a expiré.

Pour résoudre ce problème, vous pouvez faire l'une des deux choses suivantes :

  • Modifiez le délai d'inactivité de votre équilibreur de charge afin que la demande HTTP se termine au cours de celui-ci.
  • Réglez votre application pour répondre plus rapidement.

Assurez-vous que les instances backend gardent les connexions ouvertes

Lorsque l'instance d'arrière-plan ferme une connexion TCP à l'équilibreur de charge avant que celle-ci n'atteigne sa valeur de délai d'inactivité, une erreur HTTP 504 peut s'afficher.

Pour résoudre ce problème, activez les paramètres « maintenir en vie » sur vos instances d'arrière-plan et définissez le délai d'attente de la « maintenance en vie » sur une valeur supérieure au délai d'inactivité de l'équilibreur de charge.

(Apache uniquement) Désactiver TCP_DEFER_ACCEPT

Lorsque TCP_DEFER_ACCEPT est activé pour les instances d'arrière-plan Apache, l'équilibreur de charge lance une connexion en envoyant un SYN à l'instance d'arrière-plan. L'instance d'arrière-plan répond ensuite par un SYN-ACK, et l'équilibreur de charge envoie un ACK vide à l'instance d'arrière-plan.

Étant donné que le dernierACK est vide,l'instance d'arrière-plan n'accepte pas le ACK, et renvoie à la place unSYN-ACK à l'équilibreur de charge à la place. Cela peut entraîner un dépassement du délai de nouvelle tentative SYN. Lorsque FIN ou RST ne sont pas envoyés avant que l'instance d'arrière-plan ne ferme la connexion, l'équilibreur de charge considère que la connexion est établie, mais ce n'est pas le cas. Ensuite, lorsque l'équilibreur de charge envoie des demandes via cette connexion TCP, l'instance d'arrière-plan répond par un RST, ce qui génère une erreur 504.

Pour résoudre ce problème, définissez la valeur de Filtre d'acceptation http et Filtre d'acceptation httpsur aucun.

(Apache uniquement) Désactivez l'évènement MPM et configurez de manière optimale les MPM du préfigurateur et du travailleur

Il est recommandé de désactiver le MPM des événements sur les instances d'arrière-plan enregistrées à un équilibreur de charge. Comme l'Apache d'arrière-plan ferme les connexions de manière dynamique, ces connexions fermées peuvent entraîner des erreurs HTTP 504.

Pour des performances optimales lors de l'utilisation des modules multi-processus Prefork et Worker, et en partant du principe que le délai d'inactivité de l'équilibreur de charge est de 60 secondes, utilisez les valeurs suivantes :

mod_prefork MPMmod_worker MPM
Expiration6565
KeepAliveTimeout6565
KeepAliveOnOn
MaxKeepAliveRequests100000
AcceptFilter httpnonenone
AcceptFilter httpsnonenone

Informations connexes

Surveiller votre Classic Load Balancer

Résolution des problèmes d'un Classic Load Balancer : erreurs HTTP

Quels sont les paramètres optimaux pour utiliser Apache ou NGINX comme serveur backend pour ELB ?

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 2 ans