REL05-BP04 Échouer rapidement et limiter les files d'attente - Reliability Pillar

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-BP04 Échouer rapidement 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 :

  • Implémentation de files de messages, mais pas de configuration de files d'attente de lettres mortes (DLQ) ou d'alarmes sur les DLQ volumes 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 « premier entré, premier sorti » (FIFO) lorsque « dernier entré, premier sorti » (LIFO) répondrait mieux aux besoins des clients, par exemple lorsqu'il n'est pas nécessaire de passer des commandes strictes et que le traitement des arriérés retarde toutes les nouvelles demandes urgentes, ce qui se traduit par un dépassement des niveaux de service pour tous les clients.

  • Exposer les files d'attente internes aux clients au lieu de les exposer à ceux APIs qui gèrent l'admission au 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 fournit des fonctionnalités de surveillance et d'alarme en cas de panne. Une fois que l’on sait qu’un système est défaillant, des stratégies d’atténuation peuvent être invoquées, notamment en cas de défaillance de ressources altérées. Lorsque les systèmes mettent en œuvre des files d'attente avec Amazon SQS et d'autres technologies de file d'attente pour faciliter le chargement, ils doivent réfléchir à la manière de gérer les arriérés de files d'attente, ainsi que les défaillances liées à la consommation de messages.

É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 vous CloudWatch aide à créer des métriques et des alarmes en fonction du modèle de journal des applications et de SDK l'instrumentation.

  • Utilisez CloudWatch les métriques et les alarmes pour éviter les ressources altérées qui ajoutent de la latence au traitement ou qui échouent à traiter les demandes à plusieurs reprises.

  • Utilisez le traitement asynchrone en concevant de manière APIs à accepter les demandes et à les ajouter aux files d'attente internes à l'aide d'SQSAmazon, puis à répondre 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 clients de la file d'attente principale traitent les demandes.

  • Mesurez et surveillez le temps de latence du traitement des files d'attente en produisant une CloudWatch métrique chaque fois que vous retirez un message d'une file d'attente en le comparant à 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 LIFO traitement et permet un traitement normal du système pour tous les nouveaux travaux.

  • 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 :