Comment corriger les erreurs 504 renvoyées lors de l'utilisation d'un Classic Load Balancer ?

Lecture de 4 minute(s)

Des erreurs HTTP 504 apparaissent dans les journaux d'accès à Classic Load Balancer, dans les métriques Amazon CloudWatch ou lors de la connexion à mon service via un Classic Load Balancer.

Résolution

Une erreur HTTP 504 est un code d'état HTTP qui indique qu'une passerelle ou un proxy a expiré. Passez en revue les éléments suivants pour résoudre ce problème :

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

La source la plus courante de l'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é de Classic Load Balancer est de 60 secondes.

Si les métriques CloudWatch sont activées, vérifiez les métriques CloudWatch pour votre équilibreur de charge. Lorsque les points de données de latence sont égaux à la valeur configurée pour le délai d'expiration de votre équilibreur de charge et que HTTPCode_ELB_5XX comprend des points de données, cela signifie qu’au moins une demande a expiré.

Pour résoudre ce problème, vous pouvez au choix :

Modifier le délai d'inactivité de votre équilibreur de charge afin que la requête HTTP se termine dans ce délai d'inactivité.
Régler votre application pour qu’elle réponde plus rapidement.

Vérifiez que vos instances dorsales maintiennent les connexions ouvertes

Lorsque l'instance dorsale ferme une connexion TCP vers l'équilibreur de charge avant qu’il n'atteigne sa valeur de délai d'inactivité, une erreur HTTP 504 peut survenir.

Pour résoudre ce problème, activez les paramètres Keep-Alive sur vos instances dorsales, puis définissez le délai d'expiration 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 dorsales Apache, l'équilibreur de charge initie une connexion en envoyant un SYN à l'instance dorsale. L'instance dorsale répond ensuite par un SYN-ACK, puis l'équilibreur de charge envoie un ACK vide à l'instance dorsale.

Comme le dernier ACK est vide, l'instance dorsale n'accepte pas ce **ACK ** et renvoie à la place un SYN-ACK à l'équilibreur de charge. Cela peut entraîner un délai d'expiration lié à d’une nouvelle tentative d’envoi de SYN. Si l’envoi de FIN ou de RST n’est pas effectué avant la fermeture de la connexion par l'instance dorsale, l'équilibreur de charge considère que la connexion est établie, bien que cela ne soit pas le cas. Lorsque l'équilibreur de charge envoie ensuite des requêtes via cette connexion TCP, l’instance dorsale répond par un RST, générant ainsi une erreur 504.

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

(Apache uniquement) Désactivez le MPM des événements et configurez de manière optimale les MPM prefork et worker

Il est recommandé de désactiver le MPM des événements sur les instances dorsales enregistrées auprès d'un équilibreur de charge. En effet, l’instance dorsale Apache ferme les connexions de manière dynamique, et ces connexions fermées peuvent entraîner des erreurs HTTP 504. Pour en savoir plus, consultez la page Apache MPM event sur le site Web d'Apache.

Pour obtenir des performances optimales lorsque vous utilisez les MPM prefork et worker, et en supposant que l'équilibreur de charge est configuré avec un délai d'inactivité de 60 secondes, utilisez les valeurs suivantes :


	mod_prefork MPM	mod_worker MPM
Timeout	65	65
KeepAliveTimeout	65	65
KeepAlive	On	On
MaxKeepAliveRequests	10000	0
AcceptFilter http	none	none
AcceptFilter https	none	none