Le Cloud Computing a enrichi le monde numérique de nom­breuses pos­si­bi­li­tés : la mise à dis­po­si­tion des res­sources de Computing via Internet permet notamment des in­no­va­tions rapides, une uti­li­sa­tion flexible des res­sources et des pers­pec­tives d’évolution cor­res­pon­dantes, qui peuvent être adaptées aux besoins par­ti­cu­liers de façon en­tiè­re­ment in­di­vi­duelle. Le théorème CAP montre toutefois que garantir cette flexi­bi­lité implique des compromis à d’autres endroits. Nous vous ex­pli­quons ce que recouvre le théorème CAP (ou théorème de Brewer) et où on peut observer l’ap­pli­ca­tion de ce théorème sur les systèmes dis­tri­bués.

Compute Engine
La solution IaaS idéale pour gérer vos charges de travail
  • vCPU aux coûts avan­ta­geux et cœurs dédiés per­for­mants
  • Sans en­ga­ge­ment pour plus de flexi­bi­lité
  • As­sis­tance par des experts 24h/24 et 7j/7 incluse

Qu’implique le théorème CAP ?

Le théorème CAP précise qu’il est im­pos­sible de sa­tis­faire ou de garantir si­mul­ta­né­ment les trois pro­prié­tés suivantes dans un système distribué :

  • Con­sis­tency (cohérence) : tous les clients voient les mêmes données au même moment.
  • Avai­la­bi­lity (dis­po­ni­bi­lité) : l’ensemble des clients peuvent procéder à tout moment à des accès en lecture et en écriture puisque le système est en mesure d’y répondre en per­ma­nence.
  • Partition Tolerance (tolérance au par­ti­tion­ne­ment) : en cas de panne d’un nœud in­di­vi­duel ou lorsque des nœuds in­di­vi­duels ne sont plus en mesure de com­mu­ni­quer ensemble, le système peut continuer à fonc­tion­ner comme un tout.
Remarque

Le théorème CAP est basé sur une hypothèse publiée en l’an 2000 par l’in­for­ma­ti­cien Eric Brewer lors d’une con­fé­rence dans le cadre du Symposium on Prin­ciples of Dis­tri­bu­ted Computing (PODC). C’est la raison pour laquelle ce principe de li­mi­ta­tion des pro­prié­tés des systèmes dis­tri­bués est également appelé théorème de Brewer. En 2002, Seth Gilbert et Nancy Lynch du MIT ont apporté une preuve axio­ma­tique à cette hypothèse qui est alors devenue un théorème.

Aujourd’hui, les in­for­ma­ti­ciens s’appuient sur ce théorème lors de la création d’un nouveau système distribué et choi­sis­sent un modèle de base axé sur deux des trois pro­prié­tés. Selon le théorème CAP, les groupes d’or­di­na­teurs in­dé­pen­dants au sein d’un même système peuvent par con­sé­quent être classés dans trois ca­té­go­ries :

  • système CP (cohérence et tolérance au par­ti­tion­ne­ment)
  • système AP (dis­po­ni­bi­lité et tolérance au par­ti­tion­ne­ment)
  • système CA (cohérence et dis­po­ni­bi­lité)

Le théorème CAP (ou théorème de Brewer) en pratique

Afin de clarifier quelque peu les im­pli­ca­tions du théorème CAP, nous vous pré­sen­tons ci-dessous des exemples de systèmes dis­tri­bués montrant la validité de ce théorème. Chaque exemple souligne par ailleurs en quoi le théorème de Brewer est ap­pli­cable.

Exemple de système AP : le Domain Name System

Le DNS, ou Domain Name System, est un exemple connu de système AP. Cette com­po­sante réseau centrale est res­pon­sable de la ré­so­lu­tion des noms de domaine pour les adresses IP et met l’accent sur la dis­po­ni­bi­lité et la tolérance au par­ti­tion­ne­ment. Grâce au nombre important de serveurs, ce système est pra­ti­que­ment dis­po­nible sans exception. Si un serveur DNS tombe en panne, le suivant prend le relais. Toutefois, con­for­mé­ment au théorème CAP, le DNS ne permet pas d’obtenir une cohérence : si une entrée du DNS est modifiée, cela peut prendre plusieurs jours avant que cette mo­di­fi­ca­tion ne soit transmise à toute la hié­rar­chie du système et ne puisse être vue par tous les clients.

Exemple de système CA : les systèmes de gestion de base de données re­la­tion­nels

Les systèmes de gestion de base de données basés sur le modèle de base de données re­la­tion­nelle cons­ti­tuent un bon exemple de systèmes CA. Ces systèmes de base de données se dé­mar­quent prin­ci­pa­le­ment par leur forte cohérence et re­cherchent une dis­po­ni­bi­lité aussi élevée que possible. En cas de doute, la dis­po­ni­bi­lité peut toutefois être réduite au profit de la cohérence. Quoi qu’il en soit, la tolérance au par­ti­tion­ne­ment joue ici un rôle mineur.

Exemple de système CP : les ap­pli­ca­tions fi­nan­cières et bancaires

Dans la plupart des systèmes dis­tri­bués, une im­por­tance par­ti­cu­lière est accordée à une dis­po­ni­bi­lité élevée ce qui explique pourquoi on voit assez peu de systèmes CP dans la pratique. Ces systèmes montrent par­ti­cu­liè­re­ment leurs atouts dans le domaine de la finance : afin d’exclure toute erreur comptable, même en cas de per­tur­ba­tion du trafic de données, les ap­pli­ca­tions bancaires devant prélever et trans­fé­rer des montants sur les comptes de façon fiable reposent sur la cohérence et la tolérance au par­ti­tion­ne­ment.

Aller au menu principal