Qu’est-ce que le théorème CAP ?

Le théorème CAP indique qu’un système distribué ne peut fournir que deux des trois caractéristiques souhaitées :
cohérence, disponibilité et tolérance au partitionnement (« C », « A » et « P » dans CAP signifiant « consistency », « availability » et « partition tolerance »).

Avez-vous déjà vu une publicité pour un paysagiste, un peintre en bâtiment ou tout autre artisan commençant par le titre suivant :« Bon marché, rapide et excellente qualité : sélectionnez deux critères au choix » ? Le théorème CAP applique un type de logique similaire aux systèmes distribués.

Un système distribué est un réseau qui stocke les données sur plusieurs nœuds (machines virtuelles ou physiques) en même temps. Comme toutes les applications cloud sont des systèmes distribués, il est essentiel de comprendre le théorème CAP lors de la conception d’une application cloud afin de pouvoir choisir un système de gestion des données fournissant les caractéristiques dont votre application a le plus besoin.

Le théorème CAP est également appelé théorème de Brewer, car il a été énoncé pour la première fois par le professeur Eric A. Brewer lors d’une conférence sur l’informatique en réseau en 2000. Deux ans plus tard, les professeurs Seth Gilbert et Nancy Lynch du MIT ont publié une preuve de la « conjecture de Brewer ».

Examinons en détail les trois caractéristiques d’un système distribué auxquelles se réfère le théorème CAP.

Cohérence

La cohérence signifie que tous les clients voient les mêmes données en même temps, quel que soit le nœud auquel ils se connectent. Pour que cela soit possible, à chaque fois que des données sont écrites sur un nœud, elles doivent être transférées ou répliquées instantanément vers tous les autres nœuds du système avant que l’écriture ne soit considérée comme « réussie ».

Disponibilité

La disponibilité signifie qu’un client qui effectue une requête de données obtient une réponse, même si un ou plusieurs nœuds sont en panne. Autrement dit : tous les nœuds actifs du système distribué renvoient une réponse valide à toutes les requêtes, sans exception.

Tolérance au partitionnement

Un partitionnement est une interruption de communication au sein d’un système distribué, c’est-à-dire une connexion perdue ou temporairement retardée entre deux nœuds. La tolérance au partitionnement signifie que la grappe (cluster) doit continuer à fonctionner quel que soit le nombre d’interruptions de communication entre les nœuds du système.

Les bases de données NoSQL sont idéales pour les applications en réseau distribué. Contrairement à leurs homologues SQL (relationnelles) qui sont évolutives verticalement, les bases de données NoSQL sont distribuées et évolutives horizontalement par nature : elles peuvent être rapidement mises à l’échelle dans un réseau en expansion et composé de nœuds multiples et interconnectés (pour en savoir plus, voir « Bases de données SQL et NoSQL : quelle est la différence ?»).

Actuellement, les bases de données NoSQL sont classifiées selon les deux caractéristiques CAP qu’elles prennent en charge :

• Base de données CP : une base de données CP fournit cohérence et tolérance au partitionnement au détriment de la disponibilité. Lorsque survient un partitionnement entre deux nœuds, le système doit arrêter le nœud non cohérent (c’est-à-dire le rendre indisponible) jusqu’à la résolution du partitionnement.
  
  
• Base de données AP : une base de données AP fournit disponibilité et tolérance au partitionnement au détriment de la cohérence. Lorsque survient un partitionnement, tous les nœuds restent disponibles, mais ceux situés du mauvais côté du partitionnement risquent de renvoyer une version des données plus ancienne que les autres (lorsque le partitionnement est résolu, les bases de données AP lancent une nouvelle synchronisation des nœuds pour réparer toutes les incohérences dans le système).
  
  
• Base de données CA : une base de données CA fournit cohérence et disponibilité sur tous les nœuds. Cependant, cela n’est plus possible si un partitionnement se produit entre deux nœuds du système : elle ne fournit donc pas de tolérance aux pannes.

Les bases de données de type CA sont mentionnées en dernier pour une raison précise : dans un système distribué, les partitionnements sont inévitables. Ainsi, bien que l’on puisse discuter théoriquement des bases de données distribuées CA, elles ne peuvent pas exister dans la pratique. Toutefois, cela ne signifie pas que vous ne pouvez pas disposer d’une base de données CA pour votre application distribuée si vous en avez besoin. De nombreuses bases de données relationnelles, telles que PostgreSQL, fournissent cohérence et disponibilité, et peuvent être déployées sur plusieurs nœuds grâce à la réplication.

MongoDB est un système de gestion de base de données NoSQL répandu qui stocke les données sous forme de documents BSON (JSON binaire). Il est fréquemment utilisé pour les applications de big data et en temps réel qui s’exécutent dans plusieurs emplacements différents. Par rapport au théorème CAP, MongoDB est un magasin de données CP : il résout les partitionnements de réseau en maintenant la cohérence, au détriment de la disponibilité.

MongoDB est un système maître unique : chaque jeu de répliques ne peut avoir qu’un seul nœud principal qui reçoit toutes les opérations d’écriture. Tous les autres nœuds de ce jeu sont des nœuds secondaires qui répliquent le journal des opérations du nœud principal et l’appliquent à leur propre jeu de données. Par défaut, les clients aussi lisent les données à partir du nœud principal, mais ils peuvent également spécifier une préférence de lecture leur permettant de lire les données à partir des nœuds secondaires.

Lorsque le nœud principal est rendu indisponible, le nœud secondaire dont le journal des opérations est le plus récent devient le nouveau nœud principal. Une fois que tous les autres nœuds secondaires sont alignés sur le nouveau maître, la grappe redevient disponible. Comme les clients ne peuvent effectuer aucune requête d’écriture pendant cet intervalle, les données restent cohérentes sur l’ensemble du réseau.

Apache Cassandra est une base de données NoSQL à code source ouvert gérée par l’Apache Software Foundation. Il s’agit d’une base de données en colonnes larges permettant de stocker des données sur un réseau réparti. Cependant, contrairement à MongoDB, Cassandra dispose d’une architecture sans maître et comporte donc plusieurs points de défaillance au lieu d’un seul.

Par rapport au théorème CAP, Cassandra est une base de données AP : elle fournit disponibilité et tolérance au partitionnement, mais ne peut pas garantir la cohérence en permanence. Cassandra ne possédant pas de nœud principal, tous les nœuds doivent être disponibles en continu. Elle fournit cependant une cohérence finale en permettant aux clients d’écrire sur n’importe quel nœud à tout moment et en remédiant aux incohérences aussi rapidement que possible.

Comme les données deviennent incohérentes seulement en cas de partitionnement du réseau et que les incohérences sont rapidement résolues, Cassandra offre une fonctionnalité de « réparation » pour aider les nœuds à s’aligner sur leurs homologues. Toutefois, la disponibilité constante permet de rendre un système hautement performant, ce qui peut justifier le compromis dans de nombreux cas de figure.

Les microservices sont des composants d’application faiblement couplés et pouvant être déployés de manière indépendante. Ils intègrent leur propre pile, y compris leur propre base de données et leur propre modèle de base de données, et communiquent entre eux sur un réseau. Comme ils peuvent s’exécuter aussi bien sur des serveurs cloud que dans des centres de données sur site, ils connaissent un grand succès avec les applications hybrides et multicloud.

Comprendre le théorème CAP peut vous aider à choisir la meilleure base de données lors de la conception d’une application basée sur des microservices et exécutée à partir de plusieurs emplacements. Si, par exemple, la capacité à itérer rapidement le modèle de données et à mettre à l’échelle horizontalement est essentielle pour votre application et que vous pouvez tolérer la cohérence finale (par opposition à la cohérence stricte), une base de données AP comme Cassandra ou Apache CouchDB peut répondre à vos besoins et vous simplifier le déploiement. Par contre, si votre application dépend fortement de la cohérence des données, comme c’est le cas pour une application de commerce électronique ou un service de paiement, vous pourriez préférer une base de données relationnelle comme PostgreSQL.