REL05-BP04 Procéder à une interruption immédiate et limiter les files d’attente
Lorsqu’un service n’est pas en mesure de répondre correctement à une demande, procédez à son interruption immédiate. Cela permet la libération des ressources associées à une demande et donne la possibilité au service de récupérer s’il lui manque des ressources. L’interruption immédiate est un modèle de conception logicielle bien établi qui peut être exploité pour créer des charges de travail hautement fiables dans le cloud. La mise en file d’attente est également un modèle d’intégration d’entreprise bien établi qui permet de faciliter le chargement et de permettre aux clients de libérer des ressources lorsque le traitement asynchrone peut être toléré. Lorsqu’un service est capable de répondre correctement dans des conditions normales, mais échoue lorsque le taux de demandes est trop élevé, utilisez une file d’attente pour mettre les demandes en mémoire tampon. Toutefois, ne permettez pas l’accumulation de longs backlogs de files d’attente susceptibles d’entraîner le traitement de demandes obsolètes auxquelles un client a déjà renoncé.
Résultat souhaité : lorsque les systèmes sont confrontés à des problèmes de ressources, à des dépassements de délai, à des exceptions ou à des pannes grises qui rendent les objectifs de niveau de service irréalisables, les stratégies d’interruption immédiate permettent d’accélérer la récupération du système. Les systèmes qui doivent absorber les pics de trafic et peuvent prendre en charge le traitement asynchrone peuvent améliorer la fiabilité en permettant aux clients de lancer rapidement des demandes grâce à l’utilisation des files d’attente pour mettre en mémoire tampon les demandes envoyées aux services back-end. Lors de la mise en mémoire tampon des demandes dans des files d’attente, des stratégies de gestion des files d’attente sont mises en œuvre pour éviter des backlogs insurmontables.
Anti-modèles courants :
-
Mise en œuvre de files de messages sans configurer de files d’attente de lettres mortes (DLQ) ni d’alarmes sur les volumes DLQ pour détecter les défaillances d’un système.
-
Il ne s’agit pas de mesurer l’ancienneté des messages dans une file d’attente, mais de mesurer la latence pour comprendre quand les utilisateurs prennent du retard ou si des erreurs entraînent de nouvelles tentatives.
-
Conservation des messages en attente dans une file d’attente, alors qu’il n’est plus utile de traiter ces messages si l’entreprise n’en a plus besoin.
-
La configuration de files d’attente du premier entré, premier sorti (FIFO) au moment du dernier entré, premier sorti (LIFO) permettrait de mieux répondre aux besoins des clients, par exemple lorsqu’un ordre strict n’est pas requis et que le traitement du backlog retarde toutes les nouvelles demandes urgentes, ce qui entraîne une violation des niveaux de service pour tous les clients.
-
Exposition des files d’attente internes aux clients au lieu d’exposer les API qui gèrent la prise de travail et placent les demandes dans les files d’attente internes.
-
La combinaison d’un trop grand nombre de types de demandes de travail dans une seule file d’attente peut aggraver les problèmes de backlog en répartissant la demande de ressources entre les types de demandes.
-
Traitement de demandes complexes et simples dans la même file d’attente, malgré la nécessité d’une surveillance, de délais d’expiration et d’allocations de ressources différents.
-
Absence de validation des entrées ou utilisation des assertions pour implémenter des mécanismes d’interruption immédiate dans les logiciels qui génèrent des exceptions vers des composants de niveau supérieur capables de gérer les erreurs de façon appropriée.
-
Absence de suppression des ressources défectueuses du routage des requêtes, en particulier lorsque les défaillances sont grises, ce qui indique à la fois des réussites et des échecs en raison d’un plantage et d’un redémarrage, d’une panne de dépendance intermittente, d’une capacité réduite ou d’une perte de paquets réseau.
Avantages du respect de cette bonne pratique : les systèmes avec interruption immédiate sont plus faciles à déboguer et à corriger, et présentent souvent des problèmes de codage et de configuration avant la publication des versions en production. Les systèmes qui intègrent des stratégies de mise en file d’attente efficaces offrent une résilience et une fiabilité accrues face aux pics de trafic et aux pannes intermittentes du système.
Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé
Directives d’implémentation
Les stratégies d’interruption immédiate peuvent être codées dans des solutions logicielles ou configurées dans l’infrastructure. En plus de leur capacité d’interruption immédiate, les files d’attente constituent une technique architecturale simple mais puissante qui permet de découpler les composants du système en douceur. Amazon CloudWatch
Étapes d’implémentation
-
Implémentez des assertions programmatiques ou des métriques spécifiques dans votre logiciel et utilisez-les pour signaler explicitement les problèmes du système. Amazon CloudWatch vous aide à créer des métriques et des alarmes reposant sur le modèle de journal des applications et l’instrumentation du SDK.
-
Utilisez les métriques et les alarmes CloudWatch pour éviter les problèmes liés à l’altération des ressources qui ajoutent de la latence au traitement ou qui échouent à plusieurs reprises à traiter les demandes.
-
Utilisez le traitement asynchrone en concevant des API pour accepter les demandes et les ajouter aux files d’attente internes en utilisant Amazon SQS, puis en répondant au client émetteur du message par un message de réussite afin que le client puisse libérer des ressources et passer à autre chose pendant que les utilisateurs de la file d’attente back-end traitent les demandes.
-
Mesurez et surveillez la latence de traitement des files d’attente en produisant une métrique CloudWatch chaque fois que vous retirez un message d’une file d’attente en comparant l’heure actuelle à l’horodatage du message.
-
Lorsque des défaillances empêchent le bon traitement des messages ou que des pics de trafic concernent des volumes qui ne peuvent pas être traités conformément aux contrats de niveau de service, mettez de côté le trafic ancien ou excédentaire vers une file d’attente de débordement. Cela permet de traiter en priorité les nouvelles tâches et les tâches plus anciennes lorsque la capacité est disponible. Cette technique est une approximation du traitement LIFO et permet un traitement normal du système pour toutes les nouvelles tâches.
-
Utilisez des lettres mortes ou réadaptez des files d’attente afin de déplacer les messages qui ne peuvent pas être traités hors du backlog vers un emplacement pouvant faire l’objet de recherches et de résolutions ultérieures.
-
Réessayez ou, si cela est acceptable, supprimez les anciens messages en comparant l’heure actuelle à l’horodatage du message et en supprimant les messages qui ne sont plus pertinents pour le client demandeur.
Ressources
Bonnes pratiques associées :
Documents connexes :
Exemples associés :
Vidéos connexes :
Outils associés :
