Les systèmes distribués, sont au cœur de la plupart des applications modernes. Peu importe où vous allez sur internet, vous utilisez probablement un système distribué sans même le savoir. Mais c’est ça la beauté de ces systèmes, ils sont transparents pour l’utilisateur final.

Mais au juste, c’est quoi un système distribué ?

alt text

Qu’est-ce qu’un système distribué ?

Avant de répondre à cette question, il faut comprendre d’où vient ce concept. Au début, les ordinateurs étaient conçus pour être autonomes. Même les premiers serveurs web et bases de données, c’était des machines qui tournaient toutes seules.

Mais les besoins ont évolué. Une seule machine, ça ne suffit plus. Ces serveurs doivent répondre à une demande de plus en plus grande chaque jour, et ils ont des limites, par définition. Ils ne peuvent pas gérer tout le stockage, tous les calculs, ou garantir une disponibilité parfaite tout seuls.

Les données deviennent de plus en plus volumineuses, la demande de rapidité, et l’exigence des utilisateurs quant à la disponibilité des services, ont poussé les entreprises à revoir leur architecture et d’innover dans la matière. C’est là que les systèmes distribués sont nés.

Un système distribué est un ensemble de composants informatiques autonomes (ordinateurs, serveurs, etc.) situés sur différents nœuds d’un réseau, qui communiquent et coordonnent leurs actions en s’échangeant des messages, afin d’apparaître comme un système unique et cohérent pour l’utilisateur final.

La création de ce genre de système a permis d’accélérer les traitements, de réduire les coûts, et d’améliorer la disponibilité des services. Mais néanmoins, cela a aussi apporté son lot de problèmes.

Quels sont les avantages des systèmes distribués ?

L’une des raisons principales pour lesquelles on adore les systèmes distribués dans le monde de l’IT, c’est la redondance. Tout bon sysadmin le sait : une machine, ça peut lâcher n’importe quand. Si nous avons qu’un seul serveur et qu’il tombe, c’est fini, plus de service. Avec un système distribué, si une machine tombe, les autres peuvent prendre le relais. L’idée, c’est d’avoir un système tolérant aux pannes. Idéalement, chaque machine devrait être indépendante et pouvoir tourner sans les autres. Mais en réalité, c’est plus compliqué que ça, et ça dépend beaucoup de comment le système est architecturé. Il y a souvent des dépendances, même si on essaie de les minimiser.

La scalabilité, c’est aussi un énorme concept dans les systèmes distribués. Comme on l’a dit, on ne peut pas booster une seule machine à l’infini – rajouter des disques durs, de la RAM, ça a des limites. C’est ce qu’on appelle scaler verticalement. Mais avec les systèmes distribués, on peut scaler horizontalement, et ajouter un très, très grand nombre de serveurs. Surtout dans notre ère où le cloud comme AWS, a rendu ça très simple. En quelques clics, on peut avoir une nouvelle instance de serveur qui tourne. C’est ça qui permet à des entreprises comme Netflix et Facebook de gérer des milliards d’utilisateurs en même temps.

Par exemple lorsque Netflix sort une nouvelle série, ils savent que des millions de personnes vont la regarder en même temps. Et pour éviter que le service tombe en panne, donc des clients malheureux, ils ajoutent des serveurs, c’est ce qu’on appelle des nœuds, pour pouvoir répondre à la demande. Une fois la demande passée, ils peuvent retirer ces serveurs, et ainsi économiser de l’argent. C’est ce qu’on appelle le scaling horizontal, et de l’infrastructure on demand.

Mais cela ne veut pas dire que les systèmes distribués sont la solution à tout. Ils ont aussi des inconvénients. Beaucoup d’inconvénients.

Quels sont les inconvénients des systèmes distribués ?

Le premier inconvénient majeur, c’est la complexité. Plus on a de machines, plus c’est un cauchemar à gérer. Il ne suffit pas qu’elles communiquent : il faut gérer la latence du réseau, détecter les pannes partielles (quand certaines machines répondent et d’autres non), et s’assurer que tout le monde est d’accord. Déployer des mises à jour sur des centaines ou des milliers de serveurs sans tout casser, c’est un défi en soi. Et la sécurité ? Avec autant de nœuds, la surface d’attaque est énorme. Si un nœud tombe en panne, il faut le remplacer immédiatement, et de manière transparente pour l’utilisateur. Heureusement, on a des outils de monitoring, de déploiement automatisé, bref, tout l’arsenal DevOps, pour nous aider.

Et puis, il y a la consistance des données. Imaginez que nous avons des copies de données sur plusieurs nœuds (c’est la réplication). Le défi, c’est de garantir que toutes ces copies restent synchronisées, surtout quand plusieurs utilisateurs modifient les mêmes données en même temps. Par exemple, si deux personnes mettent à jour le solde d’un compte bancaire en même temps sur deux nœuds différents, comment peut-on s’assurer que le résultat final est correct ? C’est là qu’on parle de consistance forte (tout le monde voit la même chose au même moment) ou de consistance éventuelle (les données finiront par être cohérentes, mais il peut y avoir un délai). C’est un problème fondamental des systèmes distribués, et il n’y a pas de solution miracle.

Théorème de CAP

Avant de conclure, j’aimerais vous donner un avant-goût de la théorie des systèmes distribués. Il y a un théorème très connu, appelé le théorème de CAP (ou théorème de Brewer), qui dit que dans un système distribué, on ne peut garantir que deux des trois propriétés suivantes :

  • Cohérence (Consistency) : C’est le “C” de CAP. Ça veut dire que tous les nœuds voient les mêmes données au même moment. Si vous faites une lecture, vous êtes sûr d’obtenir la dernière version écrite. C’est comme si vous aviez une seule copie des données, même si en réalité, il y en a plusieurs.

  • Disponibilité (Availability) : C’est le “A”. Ça signifie que chaque requête reçoit une réponse, sans garantie que cette réponse contienne la dernière version écrite. En gros, le système répond toujours, même s’il n’est pas sûr d’avoir les données les plus récentes.

  • Tolérance au partitionnement (Partition tolerance) : C’est le “P”. C’est un peu plus technique, mais imaginez que le réseau entre vos nœuds tombe en panne (une “partition”). La tolérance au partitionnement signifie que le système continue de fonctionner malgré cette coupure. Les nœuds de chaque côté de la partition peuvent continuer à travailler indépendamment.

Alors, quel est le piège ? Le piège, c’est qu’on ne peut pas avoir les trois en même temps. Il faut choisir. Si vous voulez la cohérence et la disponibilité, vous sacrifiez la tolérance au partitionnement (ce qui est impossible dans un système réellement distribué, où les pannes réseau sont inévitables). Si vous voulez la cohérence et la tolérance au partitionnement, vous sacrifiez la disponibilité (le système peut refuser de répondre pour éviter de donner des données obsolètes). Et si vous voulez la disponibilité et la tolérance au partitionnement, vous sacrifiez la cohérence (vous acceptez que les données puissent être temporairement incohérentes).

C’est un compromis fondamental. Il n’y a pas de “bonne” réponse. Le choix dépend de votre application. Pour une banque, la cohérence est souvent primordiale (on ne veut pas perdre d’argent !). Pour un réseau social, la disponibilité peut être plus importante (on préfère que le site réponde, même si les données ne sont pas parfaitement à jour).

Le théorème CAP, c’est un peu la “loi de la gravité” des systèmes distribués. On ne peut pas l’ignorer. Il faut comprendre les compromis qu’il implique pour concevoir des systèmes robustes et adaptés à nos besoins. C’est un sujet fascinant, et on pourrait en parler pendant des heures… mais ce sera pour un prochain post !

Conclusion

Jusqu’à là, je vous remercie d’avoir lu cet article. J’espère que vous avez appris quelque chose sur les systèmes distribués. C’est un sujet vaste et complexe, mais aussi passionnant. Si vous avez des questions, n’hésitez pas à me les poser directement sur LinkedIn. Je serais ravi de vous répondre.

À bientôt !