Remarque: Cet article est obsolète. Vous pouvez trouver la version la plus à jour ici.
Ce message est obsolète. Veuillez trouver la version mise à jour ici. Je laisse intentionnellement cet article ici pour ne pas perturber les autres sites qui me renvoient.
Il y a plusieurs années, intégrer les performances dans un système logiciel était simple : vous augmentiez vos ressources matérielles (mise à l’échelle) ou modifiiez votre application pour qu’elle s’exécute plus efficacement (réglage des performances). Aujourd’hui, il existe une troisième option : la mise à l’échelle horizontale (scale out).
La mise à l’échelle horizontale des systèmes logiciels est devenue nécessaire ces dernières années, en raison de la nature globale de l’informatique et des exigences de performance sans cesse croissantes des applications. Dans de nombreux cas, il n’est plus acceptable d’exécuter un seul serveur avec une seule base de données dans un seul centre de données adjacent au siège de votre entreprise. Nous avons besoin d’environnements véritablement distribués pour relever les défis commerciaux d’aujourd’hui.
Malheureusement, les avantages de performance que procure la mise à l’échelle horizontale ont un coût-complexité. Les systèmes distribués introduisent beaucoup plus de facteurs dans l’équation de performance qu’auparavant. Les enregistrements de données varient selon les clients/nœuds situés à différents endroits. Les points de défaillance uniques détruisent le temps de fonctionnement du système et les problèmes de réseau intermittents se propagent au pire moment possible.
Ces préoccupations de cohérence (C), de disponibilité (A) et de tolérance de partition (P) à travers les systèmes distribués constituent ce que ~~Eric Brewer ~~ a inventé comme le théorème de CAP. En termes simples, le théorème CAP démontre que tout système distribué ne peut garantir C, A et P simultanément, mais que des compromis doivent être faits à un moment donné pour atteindre le niveau de performance et de disponibilité requis pour une tâche spécifique.
Cohérence – Tous les nœuds voient les mêmes données en même temps.
En termes simples, l’exécution d’une opération de lecture renverra la valeur de l’opération d’écriture la plus récente, ce qui obligera tous les nœuds à renvoyer les mêmes données. Un système a une cohérence si une transaction commence avec le système dans un état cohérent et se termine avec le système dans un état cohérent. Dans ce modèle, un système peut (et passe) dans un état incohérent lors d’une transaction, mais la transaction entière est annulée en cas d’erreur à une étape du processus.
Les bases de données relationnelles typiques sont cohérentes : SQL Server, MySQL et PostgreSQL.
Disponibilité – Chaque demande reçoit une réponse en cas de succès / d’échec.
La disponibilité dans un système distribué nécessite que le système reste opérationnel 100% du temps. Chaque client reçoit une réponse, quel que soit l’état d’un nœud individuel du système. Cette mesure est triviale à mesurer : soit vous pouvez soumettre des commandes de lecture/écriture, soit vous ne le pouvez pas.
Des bases de données relationnelles typiques sont également disponibles : SQL Server, MySQL et PostgreSQL. Cela signifie que des bases de données relationnelles existent dans l’espace CA – cohérence et disponibilité. Cependant, l’autorité de certification n’est pas seulement réservée aux bases de données relationnelles – certains outils orientés documents comme ElasticSearch relèvent également de l’autorité de certification.
Tolérance de partition – Le système continue de fonctionner malgré la perte de message ou une défaillance partielle.
La plupart des gens considèrent leur magasin de données comme un nœud unique dans le réseau. « Ceci est notre instance SQL Server de production ». Toute personne qui a exécuté une instance de production pendant plus de quatre minutes se rend rapidement compte que cela crée un seul point de défaillance. Un système tolérant aux partitions peut supporter toute défaillance du réseau qui n’entraîne pas une défaillance de l’ensemble du réseau. Les enregistrements de données sont suffisamment répliqués sur des combinaisons de nœuds et de réseaux pour maintenir le système en état de fonctionnement grâce à des pannes intermittentes.
Systèmes de stockage sous Tolérance de partition avec Cohérence (CP) : MongoDB, Redis, Mise en cache AppFabric et MemcacheDB. Les systèmes CP offrent d’excellents caches distribués puisque chaque client reçoit les mêmes données et que le système est partitionné à travers les limites du réseau.
Les systèmes de stockage qui relèvent de la tolérance de partition avec disponibilité (AP) incluent DynamoDB, CouchDB et Cassandra.
Conclusion
Les systèmes distribués nous permettent d’atteindre un niveau de puissance de calcul et de disponibilité qui n’était tout simplement pas disponible autrefois. Nos systèmes ont des performances supérieures, une latence inférieure et un temps de disponibilité proche de 100% dans des centres de données couvrant le monde entier. Mieux encore, les systèmes d’aujourd’hui sont exécutés sur du matériel de base facilement accessible et configurable avec des coûts approchant 0 $.
Toute cette puissance de calcul et ces avantages ont cependant un prix. Les systèmes distribués sont plus complexes que leurs homologues à réseau unique. Il y a beaucoup plus d’outils et de compétences à acquérir pour créer un système vraiment évolutif et performant. Comprendre la complexité des systèmes distribués, faire les compromis appropriés pour la tâche à accomplir (CAP) et choisir le bon outil pour le travail sont autant de compétences essentielles dans un monde où les systèmes informatiques se déplacent, pas vers le haut.
