Il est temps de synchroniser la cohérence dans les systèmes IIoT

Un sujet important (et très débattu) dans la conception de systèmes distribués est le modèle de cohérence à utiliser. Les modèles de cohérence influencent de nombreuses parties de la conception du système, et le choix de l'un par rapport à l'autre a un impact sur la disponibilité du système et sa robustesse contre les pannes de réseau. Ce blog est destiné aux architectes système qui souhaitent mieux comprendre ce que signifie être ou ne pas être cohérent.

Tout d'abord, précisons que ce blog ne concerne pas le "C" dans ACID (https://en.wikipedia.org/wiki/ACID). La cohérence ACID garantit que les mises à jour d'un magasin de données sont valides conformément à un ensemble de contraintes. Ce blog se concentre sur le type de cohérence qui décrit ce qui se passe lorsque les données sont répliquées entre les magasins distribués. Il s'avère que ACID le fait dire quelque chose à ce sujet, mais c'est le "Je" (Isolement), pas le "C". Déroutant? Un peu, mais supportez-moi.

L'isolement est également appelé consistance forte . Lorsqu'un système est fortement cohérent, toutes les écritures et lectures entre les magasins distribués sont exécutées dans le même ordre pour chaque application de ce système. C'est une manière élaborée de dire, lorsqu'une application écrit quelque chose, toutes les applications qui lisent après l'écriture, sont assurés de voir les nouvelles données.

Cela s'avère être une propriété incroyablement utile dans de nombreux systèmes. Cela garantit que deux personnes ne peuvent pas commander le même réfrigérateur sur un site Web d'achat, même lorsqu'elles achètent exactement au même moment. Une cohérence forte applique le même ordre d'opérations globalement , donc deux achats sont toujours traités par tout le monde dans la même commande. En pratique, cela signifie que la deuxième tentative d'achat est garantie de voir que le réfrigérateur est en rupture de stock.

Une cohérence forte semble être une chose assez intéressante à avoir, alors pourquoi tous les systèmes ne l'utilisent-ils pas ? C'est à cause de quelque chose appelé le théorème CAP (https://en.wikipedia.org/wiki/CAP_theorem). Tout d'abord, une note rapide :CAP a été critiqué à juste titre par beaucoup parce qu'il est trop simple de décrire le comportement de systèmes distribués complexes - soyez donc prudent lorsque vous l'utilisez - mais il fournit un cadre utile pour discuter des modèles de cohérence. Je n'entrerai pas dans les détails de CAP car Internet regorge de ressources qui font un bien meilleur travail que je ne pourrais espérer faire ici.

En résumé, CAP nous dit ce qui se passe dans les systèmes distribués lorsque les applications perdent temporairement la capacité de « parler », ou en d'autres termes :lorsque le réseau tombe en panne. Il s'avère qu'il est impossible pour un système d'être fortement cohérent et toujours garantir la disponibilité, indépendamment de la perte de connectivité. Dommage.

Cela semble complexe, mais est en fait assez intuitif. Rappelez-vous à quel point une cohérence forte nécessite un ordre global pour toutes les opérations d'un système ? Cela signifie qu'une lecture doit voir toutes les écritures précédentes, de tout le monde. Si toutes les applications ne sont pas connectées, cela devient impossible à garantir. Une demande peut avoir passé une commande pour un réfrigérateur, mais si toutes les demandes n'ont pas encore reçu cette commande, elles ne peuvent pas passer de nouvelles commandes. Cela entraîne des temps d'arrêt pour le site Web d'achat !

Les temps d'arrêt peuvent être atténués en affectant plus de ressources au problème, comme la réplication de base de données (plus de stockage) ou le déploiement de serveurs Web redondants (plus de calcul). Aujourd'hui, c'est presque trivial à faire dans les infrastructures de cloud public, même si cela devient assez coûteux et complexe lorsqu'un système comporte de nombreuses pièces mobiles, comme avec les architectures de microservices. Lorsqu'un système ne s'exécute pas sur un cloud, l'ajout de ressources est loin d'être anodin, car le stockage, le calcul et la bande passante sont tous beaucoup plus limités dans les environnements non cloud.

Ainsi, bien qu'une cohérence forte soit pratique pour les applications, elle pèse sur une infrastructure (et votre portefeuille !). Pour contourner ces problèmes, des personnes intelligentes ont proposé des solutions qui ne sont pas aussi pédantes en matière de cohérence, mais toujours réalisables du point de vue des applications. Ce dont nous parlons, c'est de « cohérence éventuelle ». Il est temps pour une autre définition.

Un système est finalement cohérent lorsque, s'il n'y a pas eu de mises à jour pour un élément donné, toutes les applications finissent par voir la même valeur. Ou en termes simples :tout le monde finit par voir les mêmes données s'il attend assez longtemps. Cela signifie que les applications sont capables de lire et d'écrire en même temps, et sont capables de le faire même lorsque le réseau est en panne ! Finalement, l'infrastructure du système fournit toutes les mises à jour aux applications.

Étant donné que les applications n'ont pas à s'attendre, la disponibilité d'un système à terme cohérent est théoriquement infinie, à condition que vos applications ne se bloquent pas et qu'une panne de courant ne se produise pas. L'infini n'est cependant pas pratique; après un certain temps, vous vous attendez à ce que vos applications se reconnectent. Par conséquent, les systèmes cohérents à terme limitent généralement le temps nécessaire pour devenir cohérents. Lorsque cette limite expire et que les applications n'ont pas eu la possibilité de se synchroniser, la récupération après échec a lieu.

La disponibilité n'est pas le seul avantage des systèmes cohérents à terme. Étant donné que les lectures et les écritures ne nécessitent aucune synchronisation, comme c'est le cas avec les systèmes fortement cohérents, elles sont beaucoup plus rapides. Le manque de synchronisation permet également une communication directe d'égal à égal, ce qui améliore encore les performances tout en améliorant la robustesse, car il supprime le besoin d'un courtier de messages centralisé, qui introduit des points de défaillance uniques.

Bien que la cohérence à terme ne fonctionne pas pour les sites Web d'achat, si l'on considère ses avantages (disponibilité, performances, robustesse, efficacité des ressources), il n'est pas surprenant qu'il soit beaucoup utilisé dans les systèmes critiques.

La suite de produits RTI Connext est la principale implémentation de la norme OMG DDS, qui est largement déployée en tant que protocole dans les systèmes IoT industriels critiques. Une grande différence entre OMG DDS et d'autres protocoles de connectivité, c'est que DDS se comporte comme une base de données distribuée qui est continuellement synchronisée entre les applications, alors que d'autres protocoles fournissent généralement une interface pour envoyer des messages et laissent la gestion de l'état à l'application.

Si vous pensez qu'une base de données distribuée ressemble à quelque chose qui doit gérer la cohérence, vous avez raison. RTI Connext DDS doit constamment équilibrer la disponibilité et les performances par rapport à la cohérence pour pouvoir travailler dans les environnements critiques les plus exigeants. Par défaut, RTI Connext DDS utilise une cohérence à terme qui garantit que les applications construites avec lui ne s'arrêtent pas de fonctionner lorsque le réseau tombe en panne, tout en garantissant que toutes les applications partagent finalement la même vision du "monde".

Vous voyez maintenant comment quelque chose qui semble aussi abstrait que la « cohérence » a des conséquences de grande envergure et devrait être traité comme un sujet important dans la conception initiale du système. Malheureusement, ce n'est jamais aussi simple que d'être « fortement cohérent » ou « éventuellement cohérent ». Une architecture lambda (https://en.wikipedia.org/wiki/Lambda_architecture) n'est qu'un exemple qui utilise à la fois une cohérence forte et éventuelle pour obtenir le meilleur des deux mondes. Avec autant de nuances de cohérence, les architectes système doivent prendre des décisions complexes sur le degré de cohérence que leur système peut se permettre.

Chez RTI, notre équipe de services professionnels vous aide à prendre ces décisions, à en comprendre les conséquences et à configurer nos produits pour créer une solution cohérente qui fonctionne pour vous.

En savoir plus sur les services RTI ici :https://www.rti.com/services