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.
REL05-BP05 Définir les délais d'expiration des clients
Définissez les délais d’expiration de manière appropriée pour les connexions et les demandes, vérifiez-les systématiquement et ne vous fiez pas aux valeurs par défaut, car elles ne tiennent pas compte des spécificités de la charge de travail.
Résultat souhaité : les délais d’expiration du client doivent prendre en compte le coût pour le client, le serveur et la charge de travail associés à l’attente des demandes dont le traitement prend un temps anormal. Dans la mesure où il est impossible de connaître la cause exacte d’un délai d’attente, les clients doivent utiliser leur connaissance des services pour établir des attentes relatives aux causes probables et aux délais d’expiration appropriés.
Le délai d’expiration des connexions client dépend des valeurs configurées. Après avoir dépassé le délai imparti, les clients décident de revenir en arrière et de réessayer ou d’ouvrir un coupe-circuit
Anti-modèles courants :
-
Ne pas connaître les délais d’expiration du système ou les délais d’expiration par défaut.
-
Ne pas connaître le délai normal d’exécution des demandes.
-
Ne pas connaître les raisons pour lesquelles les demandes peuvent prendre un temps anormalement long à traiter, ni les coûts pour le client, le service ou les performances de la charge de travail associés à l’attente de ces traitements.
-
Ne pas connaître la probabilité qu’un réseau défaillant entraîne l’échec d’une requête uniquement lorsque le délai d’expiration est atteint, ainsi que les coûts pour les performances du client et de la charge de travail si l’on n’adopte pas un délai d’expiration plus court.
-
Ne pas tester les scénarios de délai d’expiration à la fois pour les connexions et les demandes.
-
Définir des délais d’expiration trop élevés, ce qui peut entraîner de longs temps d’attente et augmenter l’utilisation des ressources.
-
Définir des délais d’attente trop bas, ce qui entraîne des défaillances artificielles.
-
Oublier les modèles pour gérer les erreurs de temporisation des appels distants, par exemple les disjoncteurs et les nouvelles tentatives.
-
Ne pas envisager de surveiller les taux d’erreur des appels de service, les objectifs de niveau de service en matière de latence et les valeurs aberrantes en matière de latence. Ces métriques peuvent fournir des informations sur les délais d’attente agressifs ou permissifs.
Avantages du respect de cette bonne pratique : les délais d’expiration des appels distants sont configurés et les systèmes sont conçus pour gérer les délais d’expiration de façon appropriée afin de préserver les ressources lorsque les appels distants répondent de manière anormalement lente et que les erreurs de délai d’expiration sont gérées de façon appropriée par les clients du service.
Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé
Directives d’implémentation
Définissez un délai d’expiration de la connexion et un délai d’expiration de la demande pour tout appel de dépendance de service et, plus généralement, pour tout appel entre processus. De nombreux cadres proposent des capacités de délai d’expiration intégrées, mais soyez prudent, car certains ont des valeurs par défaut infinies ou supérieures à ce qui est acceptable pour vos objectifs de service. Une valeur trop élevée réduit l’utilité du délai d’attente, car les ressources continuent d’être consommées pendant que le client attend l’expiration du délai. Une valeur trop faible peut générer un trafic accru sur le back-end et une latence accrue en raison du nombre excessif de demandes réessayées. Dans certains cas, cela peut entraîner des interruptions complètes, car toutes les demandes font l’objet d’une nouvelle tentative.
Tenez compte des points suivants lorsque vous déterminez des stratégies de délai d’expiration :
-
Le traitement des demandes peut prendre plus de temps que d’habitude en raison de leur contenu, de défaillances d’un service cible ou d’une panne de partition réseau.
-
Les demandes dont le contenu est anormalement coûteux peuvent consommer des ressources inutiles du serveur et du client. Dans ce cas, le fait d’avoir un délai d’expiration pour ces demandes et de ne pas réessayer peut préserver les ressources. Les services doivent également se protéger contre les contenus anormalement coûteux avec des limites et des délais d’expiration côté serveur.
-
Les demandes qui prennent anormalement longtemps en raison d’une défaillance du service peuvent être interrompues et réessayées. Il convient de tenir compte des coûts de service liés à la demande et à la nouvelle tentative, mais si la cause est une déficience localisée, une nouvelle tentative ne sera probablement pas coûteuse et réduira la consommation de ressources du client. Le délai d’expiration peut également libérer des ressources du serveur en fonction de la nature de la déficience.
-
Les demandes dont l’exécution prend beaucoup de temps parce que la demande ou la réponse n’a pas été envoyée par le réseau peuvent être interrompues et réessayées. La demande ou la réponse n’ayant pas été envoyée, il en aurait résulté un échec indépendamment de la durée du délai imparti. Dans ce cas, l’expiration du délai ne libérera pas les ressources du serveur, mais des ressources client et cela améliorera les performances de la charge de travail.
Tirez parti de modèles de conception bien établis, tels que les nouvelles tentatives et les disjoncteurs, pour gérer les délais d'attente avec élégance et prendre en charge les approches rapides. AWS SDKset AWS CLI
Étapes d’implémentation
-
Configurez les délais d’expiration pour les appels de service à distance et profitez des fonctionnalités de délai d’expiration spécifique à la langue intégrées ou des bibliothèques de délai d’expiration open source.
-
Lorsque votre charge de travail passe des appels avec un AWS SDK, consultez la documentation pour connaître la configuration du délai d'expiration spécifique à la langue.
-
Lorsque vous utilisez des AWS CLI commandes AWS SDKs or dans votre charge de travail, configurez les valeurs de délai d'expiration par défaut en définissant les AWS valeurs par défaut pour
connectTimeoutInMilliset.tlsNegotiationTimeoutInMillis -
Appliquez des options de ligne de commande
cli-connect-timeoutetcli-read-timeoutcontrôlez des AWS CLI commandes ponctuelles aux AWS services. -
Surveillez les appels de service à distance pour détecter les délais d’expiration et définissez des alarmes en cas d’erreurs persistantes afin de pouvoir gérer de manière proactive les scénarios d’erreur.
-
Mettez en œuvre CloudWatch des mesures et CloudWatch une détection des anomalies sur les taux d'erreur des appels, les objectifs de niveau de service en matière de latence et les valeurs aberrantes de latence afin de mieux comprendre la gestion des délais d'attente trop agressifs ou trop permissifs.
-
Configurez les délais d’expiration des fonctions Lambda.
-
APILes clients Gateway doivent implémenter leurs propres tentatives lors de la gestion des délais d'expiration. APIGateway prend en charge un délai d'intégration de 50 millisecondes à 29 secondes pour les intégrations en aval et ne réessaie pas lorsque les demandes d'intégration expirent.
-
Implémentez le modèle de disjoncteur
pour éviter de passer des appels à distance lorsque le délai d’expiration est écoulé. Ouvrez le circuit pour éviter les échecs d’appels et fermez-le lorsque les appels répondent normalement. -
Pour les charges de travail basées sur des conteneurs, consultez les fonctionnalités d’App Mesh Envoy pour tirer parti des délais d’attente et des disjoncteurs intégrés.
-
AWS Step Functions À utiliser pour créer des disjoncteurs à faible code pour les appels de service à distance, en particulier lorsque vous faites appel à des intégrations Step Functions AWS natives SDKs et compatibles afin de simplifier votre charge de travail.
Ressources
Bonnes pratiques associées :
Documents connexes :
Exemples connexes :
Outils associés :
