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

Dernière mise à jour : 21/03/2018

Problème

Des messages d'erreur HTTP 504 s'affichent dans les journaux d'accès d'un Classic Load Balancer, dans les métriques Amazon CloudWatch ou lorsque je me connecte au service par le biais d'un Classic Load Balancer. Comment résoudre le problème ?

Résolution

Une erreur HTTP 504 est un code d'état HTTP indiquant l'expiration du délai d'inactivité d'une passerelle ou d'un proxy. 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 principale raison pour laquelle un équilibreur de charge renvoie des erreurs HTTP 504 est le fait qu'une instance backend correspondante n'a pas répondu à la demande durant 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. Si les points de données de latence sont égaux à la valeur de délai d'inactivité actuellement configurée pour l'équilibreur de charge et s'il existe des points de données dans la métrique HTTPCode_ELB_5XX, alors au moins une demande a expiré.

Pour résoudre ce problème, modifiez le délai d'inactivité de l'équilibreur de charge afin de permettre l'achèvement d'une demande HTTP durant le délai d'inactivité spécifié ou configurez votre application afin qu'elle réponde plus rapidement.

Assurez-vous que les instances backend gardent les connexions ouvertes

Si une instance backend ferme une connexion TCP à l'équilibreur de charge avant que ce dernier n'ait atteint le délai d'inactivité configuré, l'équilibreur de charge risque de ne pas pouvoir répondre à la demande, ce qui entraînera une erreur HTTP 504.

Pour résoudre ce problème, activez les paramètres keep-alive sur vos instances backend et définissez le délai d'attente keep-alive sur une valeur supérieure au délai d'inactivité de l'équilibreur de charge.

(Apache uniquement) Désactivez TCP_DEFER_ACCEPT

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

L'instance backend n'accepte pas l'ACK, car il est vide et renvoie un SYN-ACK à l'équilibreur de charge à la place. Cela peut entraîner un dépassement du délai de nouvelle tentative SYN. Lorsque l'instance backend ferme la connexion sans envoyer de FIN ou de RST à l'équilibreur de charge, ce dernier considère que la connexion est établie, ce qui n'est pas le cas. Ensuite, lorsque l'équilibreur de charge envoie des demandes via cette connexion TCP, l'instance backend répond par un RST, ce qui génère une erreur HTTP 504.

Pour résoudre ce problème, définissez la valeur de AcceptFilter http et AcceptFilter https sur none.

(Apache uniquement) Désactivez le module multi-processus Event et configurez de manière optimale les modules multi-processus Prefork et Worker

Le module multi-processus Event ne doit pas être utilisé sur les instances backend enregistrées sur un équilibreur de charge, car l'instance backend Apache ferme les connexions de manière dynamique, ce qui entraîne l'envoi d'erreurs HTTP 504 aux clients.

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 MPM mod_worker MPM
Expiration 65 65
KeepAliveTimeout 65 65
KeepAlive On On
MaxKeepAliveRequests 10000 0
AcceptFilter http none none
AcceptFilter https none none