Comment puis-je résoudre les problèmes de latence des appels ou des requêtes sur les tâches Amazon ECS ?

Lecture de 4 minute(s)
0

Je souhaite résoudre les problèmes liés à mon application Amazon Elastic Container Service (Amazon ECS) qui met du temps à répondre aux requêtes.

Brève description

Les causes courantes de latence élevée sur une tâche ECS sont les suivantes :

  • Utilisation élevée du processeur ou de la mémoire (RAM) pour les tâches.
  • Problèmes liés aux dépendances de l’application qui s'exécutent au sein de l'application.
  • Distance réseau importante entre les clients ou les cibles sur site et ECS Task.
  • Problèmes de connectivité réseau, surcharges.
  • Limitation du volume Amazon Elastic Block Store (Amazon EBS).

Pour examiner et résoudre ces problèmes, essayez d'abord d'isoler l'origine du retard, puis suivez les étapes de résolution.

Résolution

Pour résoudre les problèmes de latence élevée sur votre tâche ECS, procédez comme suit :

  1. Exécutez la commande suivante pour mesurer la réponse du premier octet et vérifier l’existence d’une résolution DNS lente susceptible de provoquer une latence :

    % curl -kso /dev/null -w "\n===============
    | DNS lookup: %{time_namelookup}
    | Connect: %{time_connect}| App connect: %{time_appconnect}
    | Pre-transfer: %{time_pretransfer}
    | Start transfer: %{time_starttransfer}
    | Total: %{time_total}
    | HTTP Code: %{http_code}\n===============\n" https://LOAD_BALANCER_DNS_NAME.com
    
    Example output:
    | DNS lookup: 0.035596
    | Connect: 0.063130
    | App connect: 0.159145
    | Pre-transfer: 0.159264
    | Start transfer: 0.190203
    | Total: 0.190722
    | HTTP Code: 200

    Remarque : L'exemple de sortie précédent est exprimé en millisecondes. Il est recommandé d'exécuter les tests initiaux depuis le VPC afin de réduire les variables impliquées dans les différents parcours de réseau.

  2. Ensuite, ignorez l'équilibreur de charge. Utilisez une adresse IP de tâche pour une tâche en cours d'exécution connue afin de diriger la commande curl précédente. Ce processus permet d'isoler le composant à l'origine de la latence.

  3. S'il existe un Application Load Balancer, vérifiez les statistiques moyennes de la métrique Amazon CloudWatch TargetResponseTime pour détecter des valeurs excessives.

    Si la valeur est élevée, un problème est survenu sur les tâches ou une dépendance de l’application est observée sur des connexions externes. Pour en savoir plus, consultez la section Comment puis-je résoudre le problème d'une augmentation de la métrique TargetResponseTime pour un Application Load Balancer ?

    S'il existe un grand nombre de tâches, activez et consultez les entrées du journal d'accès de votre Application Load Balancer pour identifier les instances de backend.

  4. Pour vérifier les problèmes liés à l'Application Load Balancer, examinez les champs request_processing_time et response_processing_time dans les entrées de journal pour détecter des périodes anormalement longues. Pour en savoir plus, consultez la section Comment puis-je résoudre les problèmes de latence élevée sur mon Application Load Balancer dans Elastic Load Balancing ? Si vous exécutez la commande curl directement sur l'adresse IP de la tâche et que vous recevez une réponse lente, consultez la section CloudWatch Container Insights.

  5. Si le taux d'utilisation du processeur et de la mémoire est inférieur à 90 % en moyenne et ne présente aucun pic, vérifiez l’existence de dépendances sur vos tâches d’application susceptibles de provoquer une latence. Les dépendances incluent les appels vers des ressources externes, telles que des compartiments Amazon Simple Storage Service (Amazon S3), des bases de données Amazon Relational Database Service (Amazon RDS) ou d'autres services Web à distance.

  6. Si les appels externes font partie du flux de travail attendu de l'application, vérifiez auprès des développeurs de l'application si celle-ci effectue des appels synchrones vers des dépendances externes. Vous pouvez également verrouiller l'application jusqu'à ce qu'elle reçoive des réponses à ces appels. Pour plus d'informations, consultez la section Gestion des appels asynchrones.

  7. Si l’hébergement est effectué sur des instances de conteneur EC2, vérifiez tous les volumes et toutes les interfaces réseau Amazon EBS pour détecter tout signe de sur-utilisation. Pour plus d'informations, consultez la section Comment puis-je résoudre les problèmes de performance des volumes EBS sur mon instance EC2 ? Si des signes de limitation EBS sont détectés, vérifiez et augmentez les IOPS provisionnés et le type de débit EBS. Vous pouvez également utiliser une autre option, telle que le stockage d'instances ou Elastic Fabric Adapter (EFA).

    Si vous détectez des signes de limitation de l'interface réseau, utilisez un type d'instance plus volumineux avec une bande passante réseau plus importante. Vous pouvez également utiliser un type d'instance amélioré par le réseau qui fournit une référence optimisée plus importante. Pour plus d'informations, consultez la section Pourquoi mon instance Amazon EC2 dépasse-t-elle ses limites de réseau alors que l'utilisation moyenne est faible ?

  8. Si l’hébergement est effectué sur AWS Fargate, vérifiez les métriques d'interface réseau à l'aide d'un conteneur sidecar de réseau Amazon ECS. Notez que le déploiement doit être effectué avec une nouvelle définition de tâche pour ajouter un conteneur sidecar.

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un mois