Gokul vous montre comment
dépanner les erreurs HTTP 504
avec les Classic Load Balancer

504-error-classic-gokul

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 puis-je résoudre le problème ?

Une erreur HTTP 504 est un code de statut HTTP qui indique 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 points suivants :

Vérifier le délai d'inactivité de l'équilibreur de charge et le modifier, si nécessaire

Le motif le plus commun de renvoi d'une erreur HTTP 504 par un équilibreur de charge est lié au fait que l'instance principale n'a pas répondu à la requête dans le délai d'inactivité actuellement configuré. Par défaut, le délai d'inactivité pour un Classic Load Balancer est de 60 secondes.

Si les métriques CloudWatch sont activées, vérifiez les métriques pour votre équilibreur de charge. Si les points de données de latence correspondent à la valeur du délai d'inactivité actuellement configuré pour l'équilibreur de charge et que la métrique HTTPCode_ELB_5XX contient des points de données de latence, cela signifie qu'au moins une demande a dépassé le délai d'inactivité.

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 pendant la période spécifiée pour le délai d'inactivité, ou configurez votre application afin qu'elle traite plus rapidement les demandes.

Vérifier 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ésactiver TCP_DEFER_ACCEPT

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

L'instance principale n'accepte pas le dernier ACK, car il est vide et elle renvoie un SYN-ACK à l'équilibreur de charge à la place. Cela peut entraîner un délai de dépassement de la nouvelle tentative SYN ultérieurement. Lorsque l'instance backend ferme la connexion sans envoyer de FIN ou 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 principale répond à l'aide d'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ésactiver le module multi-processus Event et configurer de manière optimale les modules multi-processus Prefork et Worker

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

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

 

mod_prefork MPM

mod_worker MPM

 

Expiration

65

65

 

KeepAliveTimeout

65

65

 

KeepAlive

Activé

Activé

 

MaxKeepAliveRequests

10 000

0

 

AcceptFilter http

aucun

aucun

 

AcceptFilter https

aucun

aucun

 

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 : 15/09/2016

Date de mise à jour : 21/03/2018