Lorsque vous utilisez une opération cohérente qui se compose d’une série d’étapes, le modèle de transaction de compensation peut être utile. Plus précisément, si une ou plusieurs des étapes échouent, vous pouvez utiliser le modèle de transaction de compensation pour annuler le travail effectué par les étapes. Les opérations qui suivent le modèle de cohérence éventuelle sont couramment rencontrées dans les applications hébergées dans le cloud qui implémentent des flux de travail et des processus professionnels complexes.
Contexte et problème
Les applications qui s’exécutent dans le cloud modifient fréquemment des données. Ces données proviennent parfois de diverses sources de données réparties dans différents emplacements géographiques. Pour éviter la contention et améliorer les performances dans un environnement distribué, une application ne devrait pas tenter de garantir une cohérence transactionnelle élevée. Au lieu de cela, l’application devrait implémenter une cohérence éventuelle. Dans le modèle de cohérence éventuelle, une opération métier type se compose d’une série d’étapes distinctes. Pendant que l’opération effectue ces étapes, l’affichage global de l’état du système peut être incohérent. Mais une fois l’opération terminée et toutes les étapes exécutées, le système devrait redevenir cohérent.
Le Manuel d’introduction à la cohérence des données explique pourquoi les transactions distribuées n’offrent que peu d’évolutivité. Cette ressource répertorie également les principes du modèle de cohérence éventuelle.
L’une des difficultés du modèle de cohérence éventuelle est la gestion d’une étape qui échoue. Après un échec, vous devrez peut-être annuler tout le travail effectué par les étapes précédentes de l’opération. Toutefois, les données ne peuvent pas simplement être restaurées, car elles peuvent avoir été modifiées par d’autres instances simultanées de l’application. Même dans les cas où les instances simultanées n’ont pas modifié les données, l’annulation d’une étape peut être plus complexe que la restauration de l’état d’origine. Il peut être nécessaire d’appliquer différentes règles spécifiques à l’entreprise. Pour obtenir un exemple, consultez le site web de voyage que la section Exemple décrit plus loin dans cet article.
Si une opération qui implémente la cohérence éventuelle s’étend sur plusieurs banques de données hétérogènes, l’annulation des différentes étapes de l’opération nécessitera d’accéder à chacune des banques de données. Pour empêcher le système de rester incohérent, vous devez annuler de manière fiable le travail que vous avez effectué dans chaque magasin de données.
Il arrive qu’une base de données ne contienne pas les données affectées par une opération qui implémente la cohérence éventuelle. Par exemple, considérez un environnement d’architecture orientée service (SOA). Une opération SOA peut invoquer une action dans un service et provoquer un changement dans l’état détenu par ce service. Pour annuler l’opération, vous devez également annuler ce changement d’état. Ce processus peut nécessiter d’appeler à nouveau le service et d’effectuer une autre action qui annule les effets de la première action.
Solution
La solution consiste à implémenter une transaction de compensation. Les étapes d’une transaction de compensation annulent les effets des étapes de l’opération d’origine. Une approche intuitive consiste à remplacer l’état actuel par l’état dans lequel se trouvait le système au début de l’opération. Toutefois, une transaction de compensation ne peut pas toujours adopter cette approche, car elle pourrait remplacer les modifications apportées par d’autres instances simultanées d’une application. Au lieu de cela, une transaction de compensation doit être un processus intelligent qui prend en compte tout travail que les instances simultanées effectuent. Ce processus varie généralement en fonction de l’application et de la nature du travail effectué par l’opération d’origine.
Une approche courante consiste à utiliser un flux de travail pour implémenter une opération cohérente qui nécessite une compensation. Au cours de l’exécution de l’opération d’origine, le système enregistre des informations sur chaque étape, notamment la manière dont le travail effectué par l’étape en cours peut être annulé. Si l’opération échoue à un moment donné, le flux de travail effectue un retour en arrière sur les étapes effectuées. À chaque étape, le workflow effectue le travail qui inverse cette étape.
Deux points importants sont à considérer :
- Une transaction de compensation peut ne pas avoir à annuler le travail dans l’ordre inverse exact de l’opération d’origine.
- Il peut être possible d’effectuer certaines des étapes d’annulation en parallèle.
Cette approche est similaire à la stratégie Sagas présentée sur le blog de Clemens Vasters.
Une transaction de compensation est une opération de cohérence éventuelle elle-même, et peut donc échouer. Le système doit être en mesure de relancer la transaction de compensation à partir du point de défaillance et de poursuivre son exécution. Il peut être nécessaire de répéter une étape qui a échoué. Les étapes d’une transaction de compensation doivent donc être définies en tant que commandes idempotentes. Pour en savoir plus, consultez l’article Idempotency Patterns sur le blog de Jonathan Oliver.
Dans certains cas, l’intervention manuelle peut être le seul moyen de récupérer à partir d’une étape qui a échoué. Dans ces situations, le système doit générer une alerte et fournir autant d’informations que possible sur la raison de l’échec.
Problèmes et considérations
Prenez en compte les points suivants lorsque vous choisissez comment implémenter ce modèle :
Il n’est pas toujours facile de déterminer quand une étape d’une opération qui implémente la cohérence éventuelle a échoué. Une étape peut ne pas échouer immédiatement. Au lieu de cela, elle peut être bloquée. Vous devrez peut-être implémenter un mécanisme de délai d’attente.
Il n’est pas facile de généraliser la logique de compensation. La transaction de compensation varie en fonction de chaque application. Elle s’appuie sur les informations dont dispose l’application pour pouvoir annuler les effets de chaque étape d’une opération ayant échoué.
Les transactions de compensation ne fonctionnent pas toujours. Vous devez définir les étapes d’une transaction de compensation en tant que commandes idempotentes. Si vous le faites, les étapes pourront être répétées si la transaction de compensation échoue.
L’infrastructure qui gère les étapes doit répondre aux critères suivants :
- Être résiliente dans l’opération d’origine et dans la transaction de compensation.
- Ne pas perdre les informations nécessaires pour compenser une étape défaillante.
- Surveiller de manière fiable la progression de la logique de compensation.
Une transaction de compensation ne rétablit pas forcément l’état des données dans le système tel qu’il l’était au début de l’opération d’origine. Au lieu de cela, la transaction compense le travail effectué avec succès avant l’échec de l’opération.
Il n’est pas nécessaire que les étapes de la transaction de compensation soient effectuées dans l’ordre inverse des étapes de l’opération d’origine. Par exemple, un magasin de données peut être plus sensible aux incohérences qu’un autre. Les étapes de la transaction de compensation qui annulent les changements apportés à ce magasin doivent avoir lieu en premier.
Certaines mesures peuvent vous aider à augmenter la probabilité que l’activité globale réussisse. Plus précisément, vous pouvez placer un verrou à court terme basé sur un délai d’attente sur chaque ressource requise pour terminer une opération. Vous pouvez également obtenir ces ressources à l’avance. Ensuite, effectuez le travail uniquement après avoir acquis toutes les ressources. Finalisez toutes les actions avant l’expiration des verrous.
Une logique de nouvelle tentative qui est généralement plus indulgente pour limiter les erreurs qui déclenchent une transaction de compensation. Lorsqu’une étape d’une opération qui implémente la cohérence éventuelle échoue, essayez de traiter l’erreur comme une exception temporaire et répétez l’étape. Arrêtez l’opération et démarrez une transaction de compensation uniquement si une étape échoue à plusieurs reprises ou n’est pas récupérable.
Lorsque vous implémentez une transaction de compensation, vous faites face à la plupart des mêmes défis que lorsque vous implémentez une cohérence éventuelle. Pour plus d’informations, reportez-vous à la section Considerations for Implementing Eventual Consistency (Considérations relatives à l’implémentation de la cohérence éventuelle) du Manuel d’introduction à la cohérence des données.
Quand utiliser ce modèle
Utilisez ce modèle uniquement pour les opérations qui doivent être annulées si elles échouent. Si possible, concevez vos solutions de manière à ne pas avoir à gérer la complexité liée aux transactions de compensation.
Conception de la charge de travail
Un architecte doit évaluer la façon dont le modèle de transaction de compensation peut être utilisé dans la conception de leurs charges de travail pour se conformer aux objectifs et principes abordés dans les piliers d’Azure Well-Architected Framework. Par exemple :
| Pilier | Comment ce modèle soutient les objectifs des piliers. |
|---|---|
| Les décisions relatives à la fiabilité contribuent à rendre votre charge de travail résiliente aux dysfonctionnements et à s’assurer qu’elle retrouve un état de fonctionnement optimal après une défaillance. | Les actions de compensation corrigent les dysfonctionnements dans les chemins de charge de travail critiques à l’aide de processus tels que l’annulation directe des modifications de données, la rupture des verrous de transaction ou encore l’exécution d’un comportement natif du système pour en inverser l’effet. - RE :02 Flux critiques - RE :09 reprise d’activité après sinistre |
Comme pour toute autre décision de conception, il convient de prendre en compte les compromis par rapport aux objectifs des autres piliers qui pourraient être introduits avec ce modèle.
Exemple
Les clients utilisent un site web de voyage pour réserver des itinéraires. Un seul itinéraire peut comprendre plusieurs vols et hôtels. Un client qui part de Seattle en direction de Londres, puis de Paris, pourrait suivre les étapes suivantes pour créer son itinéraire :
- Réservation d’un siège sur le vol F1 reliant Seattle à Londres.
- Réservation d’un siège sur le vol F2 reliant Londres à Paris.
- Réservation d’un siège sur le vol F3 reliant Paris à Seattle.
- Réservation d’une chambre à l’hôtel H1 à Londres.
- Réservation d’une chambre à l’hôtel H2 à Paris.
Ces étapes constituent une opération de cohérence éventuelle, même si chaque étape correspond à une action distincte. En plus d’effectuer ces étapes, le système doit également enregistrer les opérations de compteur pour annuler chaque étape. Ces informations sont nécessaires dans le cas où le client annule l’itinéraire. Les étapes nécessaires pour effectuer les opérations de réversion peuvent ensuite être exécutées dans le cadre d’une transaction de compensation.
Les étapes de la transaction de compensation peuvent ne pas être exactement à l’opposé des étapes d’origine. En outre, la logique de chaque étape de la transaction de compensation doit prendre en compte des règles spécifiques à l’entreprise. Par exemple, l’annulation d’une réservation de vol peut ne pas donner droit au client à un remboursement complet.
La figure suivante montre les étapes d’une transaction de longue durée pour la réservation d’un itinéraire de voyage. Vous pouvez également voir les étapes de compensation de transaction qui annulent la transaction.
Notes
Il est parfois possible d’exécuter en parallèle les étapes de la transaction de compensation. Cela dépend de la façon dont vous avez conçu la logique de compensation pour chaque étape.
Dans de nombreuses solutions d’entreprise, l’échec d’une seule étape ne nécessite pas toujours une réinitialisation de l’état d’origine du système via une transaction de compensation. Par exemple, considérez le scénario du site web de voyage. Supposons que le client réserve des vols F1, F2 et F3, mais qu’il ne peut pas réserver une chambre à l’hôtel H1. Il est préférable d’offrir au client une chambre dans un autre hôtel dans la même ville plutôt que d’annuler les vols. Le client peut toujours décider d’annuler. Dans ce cas, la transaction de compensation s’exécute et annule les réservations pour les vols F1, F2 et F3. Mais c’est au client de prendre cette décision, pas au système.
Étapes suivantes
- Data Consistency Primer (Manuel d’introduction à la cohérence des données). Le modèle de transaction de compensation est souvent utilisé pour annuler les opérations qui implémentent le modèle de cohérence éventuelle. Ce manuel présente les avantages et les inconvénients de la cohérence éventuelle.
- Modèles d’idempotence. Dans une transaction de compensation, il est préférable d’utiliser des commandes idempotentes. Ce billet de blog décrit les facteurs à prendre en compte lorsque vous implémentez l’idempotence.
Ressources associées
- Modèle de superviseur de l’agent du planificateur. Cet article décrit comment implémenter des systèmes résilients qui exécutent des opérations métiers utilisant des ressources et des services distribués. Dans ces systèmes, vous devez parfois utiliser une transaction de compensation pour annuler le travail effectué par une opération.
- Modèle Nouvelle tentative. Les transactions de compensation peuvent être exigeantes en calcul. Vous pouvez essayer de réduire leur utilisation à l’aide du modèle de nouvelle tentative pour implémenter une stratégie efficace de nouvelle tentative pour les opérations ayant échoué.
- Modèle de transactions distribuées de saga. Cet article explique comment utiliser le modèle Saga pour gérer la cohérence des données entre les microservices dans les scénarios de transaction distribuée. Le modèle Saga gère la récupération d’échec avec des transactions de compensation.
- Modèle de canaux et de filtres. Cet article décrit le modèle Canaux et filtres, que vous pouvez utiliser pour décomposer une tâche de traitement complexe en une série d’éléments réutilisables. L’utilisation du modèle de canaux et de filtres avec le Modèle de transaction de compensation est une alternative à l’implémentation des transactions distribuées.
- Conception de la réparation spontanée. Ce guide explique comment concevoir des applications avec réparation automatique. Vous pouvez utiliser des transactions de compensation dans le cadre d’une approche de réparation automatique.