Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Code d'état HTTP 504 (délai d'expiration de la passerelle)
Un code d'état HTTP 504 (délai d'expiration de la passerelle) indique que lors du CloudFront transfert d'une demande à l'origine (parce que l'objet demandé ne se trouvait pas dans le cache périphérique), l'un des événements suivants s'est produit :
-
L'origine a renvoyé un code d'état HTTP 504 à CloudFront.
-
L'origine n'a pas répondu avant l'expiration de la demande.
CloudFront renverra un code d'état HTTP 504 si le trafic est bloqué vers l'origine par un pare-feu ou un groupe de sécurité, ou si l'origine n'est pas accessible sur Internet. Commencez par vérifier ces problèmes. Ensuite, si l'accès n'est pas le problème, explorez les retards de l'application et les délais d'attente du serveur pour mieux identifier et résoudre les problèmes.
Rubriques
- Configurez le pare-feu sur votre serveur d'origine pour autoriser CloudFront le trafic
- Configurez les groupes de sécurité sur votre serveur d'origine pour autoriser CloudFront le trafic
- Rendez accessible votre serveur d’origine personnalisée sur Internet
- Recherchez et corrigez des réponses retardées à partir des applications sur votre serveur d’origine
Configurez le pare-feu sur votre serveur d'origine pour autoriser CloudFront le trafic
Si le pare-feu de votre serveur d'origine bloque le CloudFront trafic et CloudFront renvoie un code d'état HTTP 504, il est donc conseillé de vous assurer que ce n'est pas le problème avant de vérifier s'il existe d'autres problèmes.
La méthode que vous utilisez pour déterminer s’il s’agit d’un problème avec votre pare-feu dépend du système que votre serveur d’origine utilise :
-
Si vous utilisez un pare-feu IPTables sur un serveur Linux, vous pouvez rechercher des outils et des informations qui vous aideront à travailler avec IPTables.
-
Si vous utilisez le pare-feu de Windows sur un serveur Windows, consultez Ajouter ou modifier la règle de pare-feu
dans la documentation Microsoft.
Lorsque vous évaluez la configuration du pare-feu sur votre serveur d'origine, recherchez les pare-feux ou les règles de sécurité qui bloquent le trafic en provenance des emplacements CloudFront périphériques, en fonction de la plage d'adresses IP publiée. Pour plus d’informations, consultez Emplacements et plages d'adresses IP des serveurs CloudFront périphériques.
Si la plage d'adresses CloudFront IP est autorisée à se connecter à votre serveur d'origine, veillez à mettre à jour les règles de sécurité de votre serveur afin d'intégrer les modifications. Vous pouvez vous abonner à une rubrique Amazon SNS et recevoir des notifications lorsque le fichier de plage d’adresses IP est mis à jour. Après avoir reçu la notification, vous pouvez utiliser le code pour extraire le fichier, l’analyser et effectuer des ajustements pour votre environnement local. Pour plus d'informations, consultez la section S'abonner aux modifications d'adresse IP AWS publique via Amazon SNS
Configurez les groupes de sécurité sur votre serveur d'origine pour autoriser CloudFront le trafic
Si votre origine utilise Elastic Load Balancing, passez en revue les groupes de sécurité ELB et assurez-vous qu'ils autorisent le trafic entrant en provenance de. CloudFront
Vous pouvez également l'utiliser AWS Lambda pour mettre à jour automatiquement vos groupes de sécurité afin d'autoriser le trafic entrant en provenance de CloudFront.
Rendez accessible votre serveur d’origine personnalisée sur Internet
Si CloudFront vous ne parvenez pas à accéder à votre serveur d'origine personnalisé parce qu'il n'est pas accessible au public sur Internet, CloudFront renvoie une erreur HTTP 504.
CloudFront les emplacements périphériques se connectent aux serveurs d'origine via Internet. Si votre origine personnalisée se trouve sur un réseau privé, CloudFront vous ne pouvez pas y accéder. Pour cette raison, vous ne pouvez pas utiliser de serveurs privés, y compris les équilibreurs de charge classiques internes, comme serveurs d'origine avec CloudFront.
Pour vérifier que le trafic Internet peut se connecter à votre serveur d'origine, exécutez les commandes suivantes (où se OriginDomainNametrouve le nom de domaine de votre serveur) :
Pour le trafic HTTPS :
-
NC-ZV 443
OriginDomainName -
telnet 443
OriginDomainName
Pour le trafic HTTP :
-
NC-ZV 80
OriginDomainName -
telnet 80
OriginDomainName
Recherchez et corrigez des réponses retardées à partir des applications sur votre serveur d’origine
Les délais d’attente du serveur sont souvent le résultat d’une application qui met beaucoup de temps à répondre ou de la définition d’une valeur de délai d’attente trop faible.
Une solution rapide pour éviter les erreurs HTTP 504 consiste simplement à définir une valeur de CloudFront délai d'expiration plus élevée pour votre distribution. Cependant, nous vous recommandons de commencer par vous assurer que vous traitez tous les problèmes de performances et de latence liés à l’application et au serveur d’origine. Ensuite, vous pouvez définir une valeur de délai d’attente raisonnable qui vise à empêcher les erreurs HTTP 504 et qui offre une bonne réactivité aux utilisateurs.
Voici une vue d'ensemble des étapes que vous pouvez suivre pour rechercher des problèmes de performances et les corriger :
-
Mesurez la latence standard et à charge élevée (réactivité) de votre application web.
-
Ajoutez d’autres ressources, telles que l’UC ou la mémoire, si nécessaire. Prenez d’autres mesures pour résoudre les problèmes, telles que le réglage des requêtes de base de données pour prendre en charge les scénarios à charge élevée.
-
Si nécessaire, ajustez la valeur du délai d'expiration pour votre CloudFront distribution.
Vous trouverez ci-après des détails relatifs à chaque étape.
Mesure de la latence standard et à charge élevée
Pour déterminer si un ou plusieurs serveurs d’application web backend présentent une latence élevée, exécutez la commande curl Linux suivante sur chaque serveur :
curl -w "Connect time: %{time_connect} Time to first byte: %{time_starttransfer} Total time: %{time_total} \n" -o /dev/null https://www.example.com/yourobject
Note
Si vous exécutez Windows sur vos serveurs, vous pouvez rechercher et télécharger curl pour Windows afin d’exécuter une commande similaire.
Lorsque vous mesurez et évaluez la latence d’une application qui s’exécute sur votre serveur, gardez à l’esprit les points suivants :
-
Les valeurs de latence sont relatives à chaque application. Toutefois, un délai jusqu’au premier octet en millisecondes plutôt qu’en secondes ou plus est raisonnable.
-
Si vous mesurez la latence de l'application sous une charge normale et qu'elle est satisfaisante, sachez que les utilisateurs peuvent tout de même connaître des dépassements de délais d'attente sous une charge élevée. Lorsqu’il y a une forte demande, les serveurs peuvent avoir des réponses différées ou aucune réponse du tout. Pour essayer d'éviter les problèmes de latence en cas de charge élevée, vérifiez les ressources de vos serveurs telles que l'UC, la mémoire et les lectures et écritures sur disque pour vous assurer que vos serveurs ont la capacité d'évoluer suffisamment pour traiter une charge élevée.
Vous pouvez exécuter la commande Linux suivante pour vérifier la mémoire utilisée par les processus Apache :
watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m" -
Une utilisation intensive de l'UC sur le serveur peut réduire considérablement les performances d'une application. Si vous utilisez une instance Amazon EC2 pour votre serveur principal, passez en revue les CloudWatch métriques du serveur afin de vérifier l'utilisation du processeur. Pour plus d'informations, consultez le guide de CloudWatch l'utilisateur Amazon. Ou, si vous utilisez votre propre serveur, reportez-vous à la documentation d'aide du serveur pour obtenir des instructions sur la manière de vérifier l'utilisation de l'UC.
-
Recherchez d'autres problèmes potentiels sous des charges élevées, telles que les requêtes de base de données qui s'exécutent lentement dans le cas d'un grand volume de demandes.
Ajout de ressources et réglage des serveurs et des bases de données
Une fois que vous avez évalué la réactivité de vos applications et serveurs, assurez-vous d’avoir les ressources suffisantes en place pour gérer des situations à trafic standard et à charge élevée :
-
Si vous possédez votre propre serveur, assurez-vous qu’il a suffisamment d’UC, de mémoire et d’espace disque pour gérer les demandes des utilisateurs, en fonction de votre évaluation.
-
Si vous utilisez une instance Amazon EC2 comme serveur backend, assurez-vous que le type d’instance dispose des ressources appropriées pour traiter les demandes entrantes. Pour plus d'informations, consultez Types d'instances dans le Guide de l'utilisateur Amazon EC2.
En outre, prenez en compte les étapes de réglage suivantes pour essayer d’éviter le dépassement des délais d’attente :
-
Si la valeur du délai jusqu’au premier octet qui est renvoyée par la commande curl semble élevée, prenez des mesures pour améliorer les performances de votre application. L’amélioration de la réactivité de l’application aidera à son tour à réduire les erreurs de dépassement de délai.
-
Réglez les requêtes de base de données pour vous assurer que de grands volumes de requêtes peuvent être gérés sans ralentir les performances.
-
Configurez des connexions keep-alive (persistantes)
sur votre serveur backend. Cette option permet d’éviter les latences qui se produisent lorsque les connexions doivent être rétablies pour des demandes ou des utilisateurs suivants. -
Si vous utilisez ELB comme origine, découvrez comment vous pouvez réduire la latence en passant en revue les suggestions présentées dans l’article suivant du Centre de connaissances : Comment résoudre les problèmes de latence élevée liés à ELB Classic Load Balancer ?
Si nécessaire, ajustez la valeur du CloudFront délai d'attente
Si vous avez évalué et traité le problème de la lenteur de la performance de l’application, de la capacité du serveur d’origine et d’autres problèmes, mais que les utilisateurs connaissent encore des erreurs HTTP 504, vous devez envisager de modifier le temps spécifié dans votre distribution comme délai d’attente de réponse de l’origine. Pour plus d’informations, consultez Délai de réponse (origines personnalisées uniquement).
