Théorème CAP
IBM® Cloudant® for IBM Cloud® utilise un modèle "finalement cohérent" . Lorsque vous effectuez une mise à jour d'une partie de IBM Cloudant,
la mise à jour est finalement vue par d'autres parties du système.
Pour comprendre comment fonctionne ce modèle, et pourquoi il représente un aspect essentiel de l'utilisation d'IBM Cloudant, considérons tout d'abord ce que l'on entend par cohérence.
La cohérence est l'une des quatre propriétés "ACID" qui sont nécessaires pour que les transactions d'une base de données soient traitées et signalées de manière fiable.
De plus, la cohérence est l'un des trois attributs du théorème "CAP" . Ces attributs sont les suivants : Consistency (Cohérence), Availability (Disponibilité) et Partition tolerance (Tolérance au partitionnement). Le théorème indique qu'il n'est pas possible pour un système informatique distribué tel que IBM Cloudant pour garantir trois attributs simultanément:
- Consistency (Cohérence) : tous les noeuds du système voient exactement les mêmes données au même moment ;
- Availability (Disponibilité) : garantie que toutes les requêtes reçoivent une réponse ;
- Partition tolerance (Tolérance au partitionnement) : le système continue à fonctionner même si une partie du système est perdue ou tombe en panne.
L'incapacité à assurer les trois attributs en même temps signifie qu'IBM Cloudant ne garantit pas l'attribut Consistency (Cohérence). Lorsque la mise à jour est propagée, le système "converge" lorsque la cohérence est atteinte.
La cohérence finale permet d'obtenir de bonnes performances. Avec un modèle de cohérence fort, le système doit attendre que les mises à jour soient complètement propagées avant d'exécuter une demande d'écriture ou de mise à jour. Avec un modèle de cohérence finale, la demande d'écriture ou de mise à jour peut être renvoyée presque immédiatement, tandis que la propagation sur le système se poursuit en arrière-plan.
Une base de données peut utiliser uniquement deux de ces trois attributs pour des raisons à la fois théoriques et pratiques. Une base de données hiérarchisant la cohérence et la disponibilité est simple : Un nœud unique stocke une seule copie de vos données. Mais ce modèle s'avère difficile à faire évoluer sachant que vous devez mettre à niveau le noeud pour optimiser les performances, au lieu d'utiliser des noeuds supplémentaires. En outre, le moindre incident système peut arrêter un système à noeud unique, tandis que la perte de messages peut induire une importante perte de données. Pour durer, le système doit devenir plus pointu.
Compromis en matière de tolérance au partitionnement
Une base de données qui privilégie la cohérence et la tolérance au partitionnement emploie généralement une configuration de type primaire-secondaire, dans laquelle l'un des noeuds du système est élu comme noeud principal. Seul le noeud principal approuve les opérations d'écriture de données, tandis que tous les noeuds secondaires assurent la réplication des données du noeud principal pour traiter les opérations de lecture. Si le noeud principal perd sa connexion au réseau, ou s'il ne parvient pas à communiquer avec un grand nombre de noeuds du système, un nouveau noeud principal est choisi. Ce processus d'élection diffère d'un système à l'autre et peut être à l'origine de problèmes importants.
IBM Cloudant met l'accent sur la disponibilité et la tolérance au partitionnement en s'appuyant sur une configuration de type primaire-primaire, de sorte que chaque noeud puisse accepter des opérations d'écriture et de lecture sur sa partie de vos données. Plusieurs noeuds détiennent des copies de chaque partie de vos données. Chaque noeud copie les données avec d'autres noeuds. Si un noeud n'est plus accessible, d'autres peuvent prendre sa place le temps que le réseau soit rétabli. Ainsi, le système renvoie vos données dans les délais malgré une défaillance de noeud arbitraire et conserve la cohérence finale. Le compromis visant à faire passer la cohérence absolue au second plan découle du délai nécessaire pour que tous les noeuds voient les mêmes données. Par conséquent, certaines réponses peuvent inclure d'anciennes données, alors que les nouvelles données sont propagées sur le système.
Changement d'approche
La conservation d'une vue cohérente des données est logique et facile à comprendre, car une base de données relationnelle se charge de le faire pour vous. On s'attend donc que les services Web qui interagissent avec les systèmes de base de données en fassent de même. Mais cela ne veut pas dire qu'ils fonctionnent de la même manière. La cohérence n'est pas acquise et changer d'approche nécessite quelques efforts.
En fait, la cohérence n'est pas forcément essentielle pour un grand nombre de services cloud d'entreprise. Avec un système très utilisé, il existe une forte probabilité qu'une partie de ce système tombe en panne. Une base de données conçue autour de la nécessité d'accorder la priorité à la disponibilité et à la cohérence finale est mieux adaptée pour maintenir l'application en ligne. La cohérence des données d'application peut être abordée après coup.
Disponibilité d'application et cohérence dans l'entreprise
Si l'on examine les services Web les plus populaires, il ressort que les utilisateurs s'attendent déjà à une haute disponibilité et échangent bien volontiers cette disponibilité contre des données cohérentes à terme sans même s'en rendre compte.
Un grand nombre d'applications induisent les utilisateurs en erreur pour le bien de la disponibilité. Envisagez les guichets automatiques : Des données bancaires incohérentes est la raison pour laquelle il est encore possible d'avoir un découvert d'argent sans s'en rendre compte. Il n'est pas réaliste de présenter une vue cohérente du solde de votre compte dans l'ensemble du système bancaire si chaque noeud du réseau doit s'arrêter et enregistrer cette valeur avant de poursuivre les opérations. Il est préférable d'assurer la haute disponibilité du système.
Le secteur bancaire l'a compris dans les années 1980, mais de nombreuses sociétés informatiques s'inquiètent toujours de privilégier la disponibilité au détriment de la cohérence. Pensez au nombre d'appels passés au support technique lorsque vos équipes commerciales ne parviennent pas à accéder à leur CRM. Maintenant, dites-vous qu'elles ne remarqueraient même pas que la mise à jour de base de données prendrait quelques secondes pour se propager sur l'ensemble de l'application.
La disponibilité est bien plus importante que la cohérence. Pensez aux systèmes de panier en ligne, aux caches HTTP et autres serveurs de noms de domaine pour ne citer que quelques exemples. Les organisations doivent prendre en compte le coût du temps d'indisponibilité lié à la frustration des utilisateurs, à la perte de productivité et aux opportunités manquées.
De la théorie à la pratique
Il est essentiel de relever le défi de la haute disponibilité pour les applications en cloud. Sinon, une cohérence de base de données globale reste un goulot d'étranglement lorsque vous procédez aux mises à niveau. Les applications à haute disponibilité ont un besoin permanent de rester en contact avec leurs données, même si ces dernières ne sont pas à jour. C'est le concept même de la cohérence finale, et il n'y a aucune raison d'en avoir peur. Parfois, à grande échelle, il est préférable de fournir des réponses qui ne sont pas tout à fait correctes plutôt que pas du tout de réponse.
Les systèmes de base de données masquent les difficultés de la disponibilité par rapport à la cohérence de différentes façons, mais elles existent quand même. Les équipes d'IBM Cloudant, de CouchDB et d'autres bases de données NoSQL pensent que la meilleure façon de procéder consiste à demander aux développeurs de traiter ces difficultés au plus tôt dans le processus de conception. En travaillant suffisamment en amont, vous réduisez le risque de mauvaises surprises, car les applications sont prêtes à être déployées dès le premier jour.