La prévention est le meilleur remède

La meilleure façon de construire un système distribué est d'éviter de le faire. La raison est simple : vous pouvez contourner les erreurs du calcul distribué (dont la plupart, contrairement à certains optimistes, sont toujours valables) et fonctionnent avec les bits rapides d'un ordinateur.

Mon ordinateur portable personnel a un joli autocollant de SignalFX ; c'est une liste de vitesses de divers mécanismes de transport. Fondamentalement, l'autocollant indique d'éviter les disques et les réseaux, en particulier lorsque vous vous déplacez entre les centres de données. Si vous faites cela et que vous utilisez certains sympathie mécanique , vous pouvez construire des trucs géniaux comme le disrupteur LMAX qui peut prendre en charge une plateforme de trading capable d'exécuter des millions de transactions par seconde sur un seul nœud. Gardez les données en mémoire et sur une seule machine et vous pouvez aller très loin ; si vous acceptez de refaire peut-être 15 secondes de travail en cas de panne, vous pouvez alors effectuer tout le travail en mémoire et n'écrire les points de contrôle sur le disque que quatre fois par minute. Des systèmes comme celui-ci fonctionneront extrêmement rapidement et vous pourrez éviter complètement la question de la mise à l'échelle.

Ne vous laissez pas tromper : les systèmes distribués ajoutent toujours de la complexité et réduisent la productivité. Si les gens vous disent le contraire, ils vous vendent probablement de la poudre de perlimpinpin.

Sachez pourquoi vous le faites et remettez en question toutes les hypothèses

Il existe cette exigence appelée « haute disponibilité » qui rend impossible de placer tout votre code sur un seul nœud. Cette exigence déclenche souvent l’étape très coûteuse consistant à impliquer plusieurs systèmes. Il y a deux choses à faire ici : remettre en question les hypothèses et remettre en question les exigences. Ce système particulier a-t-il vraiment besoin d’avoir 5 neufs de disponibilité ou pouvons-nous le déplacer vers un niveau de disponibilité plus souple ? Surtout si votre logiciel doit encore faire ses preuves, opter pour la haute disponibilité et d’autres gadgets peut très bien être une optimisation prématurée. Au lieu de cela, ignorez-le pour l’instant, mettez-le sur le marché plus rapidement et mettez en place une stratégie pour l’ajouter plus tard. Si les parties prenantes de l’entreprise affirment que oui, il doit s’agir de « haute disponibilité », expliquez-leur les compromis et assurez-vous qu’ils savent qu’ils sont sur le point d’investir du temps et de l’argent dans quelque chose dont ils n’auront peut-être jamais besoin (le résultat attendu devrait être que les clients n’aimeront pas le produit ou la fonctionnalité. Si vous ne créez que des produits ou des fonctionnalités que vous savez que les clients vont aimer, vous ne prenez aucun risque et votre entreprise finira dans un nuage ennuyeux de médiocrité).

Expliquer le théorème CAP , dites à vos parties prenantes qu'elles peuvent bénéficier de la disponibilité ou de la cohérence, mais pas des deux (encore une fois, certains optimistes disent que ce n'est plus le cas, mais je pense que c'est faux). Par exemple, si vous créez un système qui délivre, par exemple, des notifications, elles peuvent obtenir un système qui délivre une notification exactement une fois la plupart du temps (cohérent, mais moins disponible) ou un système qui délivre une notification au moins une fois presque toujours (disponible, mais moins cohérent). En général, les systèmes à cohérence finale (AP) nécessitent moins de coordination, ils sont donc plus simples à créer et plus faciles à faire évoluer et à exploiter. Essayez de voir si vous pouvez vous en sortir, car cela vaut généralement la peine de redéfinir votre problème en une solution AP.

N'oubliez pas : si vous ne pouvez pas l'éviter, négociez au moins vers quelque chose de simple. Ne pas avoir à mettre en œuvre un système distribué complexe est la meilleure façon d'avoir un système distribué.

Simplifiez-vous la vie

La complexité est l'ennemi de notre métier, donc quel que soit le système que vous concevez ou le code que vous écrivez, vous devez jouer à ce jeu du chat et de la souris où la complexité apparaît et vous la réprimandez immédiatement. Cela devient encore plus important dès que vous écrivez un logiciel qui s'étend sur plusieurs systèmes - les systèmes distribués sont intrinsèquement complexes, vous ne devez donc pas avoir de patience avec complexité accidentelle Certaines choses dans les systèmes distribués sont plus simples à mettre en œuvre que d’autres : essayez de vous en tenir aux choses simples.

Distribution pour HA

Il existe plusieurs façons d'augmenter la disponibilité : vous pouvez avoir un cluster de nœuds et tout coordonner (enregistrer l'état de travail en permanence afin que n'importe quel nœud puisse récupérer n'importe quoi), mais cela nécessite beaucoup de coordination. La coordination rend les choses fragiles, alors peut-être ne pouvez-vous pas l'avoir ? Il existe différentes options pour éviter la coordination tout en conservant une bonne disponibilité :

• Exécutez le même travail en parallèle, mais utilisez la sortie d'un seul système. Tout est répliqué sur un nœud secondaire, de sorte que lorsque le nœud principal tombe en panne, la réplication garantit que le nœud de sauvegarde est « actif » et peut prendre le relais en un clin d'œil. La coordination consiste alors simplement à décider quel nœud s'exécute en premier et quel nœud est le nœud de sauvegarde secondaire.
• Ayez un nœud de secours de secours. Le nœud principal continue régulièrement de travailler sur un stockage partagé et s'il cesse de fonctionner, le nœud secondaire le lit et prend le relais. La coordination ici consiste généralement en ce que le nœud secondaire surveille le nœud principal pour voir si une reprise est nécessaire.

Dans les deux cas, la coordination passe de « par transaction » à « par configuration ». Les transactions de travail distribuées sont difficiles, donc si vous pouvez vous en sortir avec une coordination au niveau de la configuration, faites-le. Souvent, cela implique de rejouer une partie du travail : un processus de travail « exactement une fois » devient « presque toujours exactement une fois, sauf si une machine tombe en panne et nous rejouons alors la dernière minute pour être sûrs de ne rien manquer ». La modélisation des opérations pour qu'elles soient idempotentes est utile ; parfois, il n'y a aucun moyen d'éviter que des opérations en double deviennent visibles et vous devez discuter des exigences avec les parties prenantes. Obtenez une évaluation honnête des risques (à quelle fréquence par an les machines tombent-elles en panne ?), une évaluation honnête de l'impact (combien de choses seront effectuées deux fois et comment cela gênera-t-il les utilisateurs) et une évaluation honnête de la difficulté (travail supplémentaire, plus de complexité qui engendre plus de fragilité qui se traduit par moins disponibilité).

Parfois, vous avez besoin de disponibilité même lorsque les centres de données sont défaillants. Soyez particulièrement prudent dans ce cas, car les choses vont devenir très fragiles très rapidement et vous devrez vous assurer de n'avoir besoin que d'un minimum de coordination.

Distribution pour la performance

Parfois, vous ne pouvez pas simplement effectuer tout le travail sur un seul nœud. Tout d’abord, essayez de ne pas vous retrouver dans cette situation. Ouvrez le capot et voyez où vous perdez des cycles – ces embêtants gens de LMAX ont montré que vous pouvez effectuer des transactions à 7 chiffres par seconde sur une seule machine ; il pourrait s’agir d’aller sur Amazon pour l’instance la plus grande. À l’heure actuelle, je m’attends à ce qu’un logiciel décent soit compatible avec plusieurs cœurs, de sorte que vous puissiez effectivement obtenir une solution rapide en vous procurant du matériel plus puissant. De plus, si vous ne pouvez pas organiser votre code pour qu’il s’exécute plus rapidement avec plus de cœurs, vous n’avez probablement aucune chance de le rendre plus rapide en ajoutant plus de nœuds, n’est-ce pas ? Même sans ingénierie de niveau LMAX, je pense qu’il est raisonnable de s’attendre à ce que votre logiciel gère au moins des opérations commerciales à 5 chiffres par seconde. Si vous souhaitez évoluer parce qu’un nœud ne peut pas en gérer quelques centaines par seconde, vous voudrez peut-être d’abord retourner à la planche à dessin. Très probablement, vous avez probablement des problèmes dans votre code qui doivent être résolus.

Lorsque vous devez ajouter des machines supplémentaires pour résoudre le problème (c'est un excellent problème à résoudre !), planifiez-le de manière à ce que la coordination soit minimale.

• Utilisez la coordination de configuration plutôt que la coordination de transaction ; demandez à vos nœuds d'utiliser un schéma de coordination pour répartir le travail, puis faites-leur exécuter le processus par morceaux sans avoir besoin d'une coordination supplémentaire. Vous pouvez ajouter ici un aspect HA tout simplement en demandant aux nœuds de redistribuer le travail lorsque l'un d'eux devient indisponible.
• Essayez de trouver les parties de travail qui sont embarrassantes et parallèles afin de ne pas avoir besoin de coordination du tout. Les serveurs Web sans état viennent à l'esprit ici comme un bon exemple, mais ce n'est pas le seul endroit où vous pouvez simplement lancer un groupe de nœuds non coordonnés sur un problème.

Le stockage est bon marché, utilisez-le

Les modèles architecturaux comme Séparation commande/requête et Recherche d'événements découpler et souvent dupliquer le stockage des données en plusieurs étapes spécialisées. Ces étapes spécialisées fonctionnent bien pour prendre en charge les conceptions distribuées, car vous pouvez choisir ce qui doit être conservé en local et ce qui doit être distribué afin de proposer une solution hybride qui minimise la coordination. Par exemple, vous pouvez écrire des commandes de mise à jour dans une configuration distribuée Kafka cluster, mais que tout ce qui se trouve en aval fonctionne localement et séparément (par exemple, les consommateurs traitent les commandes de mise à jour et mettent à jour indépendamment Recherche élastique Les nœuds utilisés pour les requêtes). Les données « réelles » sont hautement disponibles et coordonnées dans les flux de messages : les systèmes utilisent simplement des vues de ces données pour un traitement spécialisé comme la recherche, l’analyse, etc. Un tel système est beaucoup plus facile à maintenir que la configuration classique où un système de base de données central est le point de jonction de toutes les opérations et devient inévitablement le goulot d’étranglement, que le système de base de données ait été conçu pour l’évolutivité ou non.

N'hésitez pas à stocker les données de manière redondante et à disposer de plusieurs systèmes indépendants, chacun utilisant sa propre forme optimisée des données. Cela nécessite moins de coordination et finit par compenser l'augmentation relativement faible du coût de stockage.

Débarrassez-vous du syndrome du NIH – votre roue a déjà été réinventée ailleurs

À moins que vous n’opériez à l’échelle de Google, le système que vous vous apprêtez à intégrer dans le monde des systèmes distribués n’est pas si spécial que vous deviez le construire de toutes pièces. Il est fort probable que vous soyez payé pour résoudre des problèmes commerciaux, et non pour créer des outils et des infrastructures. Il n’y a donc aucune raison de vous débrouiller tout seul en 2017. Mettre en œuvre correctement un système distribué est difficile, vous risquez donc de vous tromper (le même conseil vaut d’ailleurs pour la persistance et la cryptographie). Si vous pensez avoir un problème unique et que vous devez le créer vous-même, soit vous n’avez pas suffisamment cherché, soit vous n’avez pas suffisamment essayé de le formuler dans un format qui permette d’utiliser l’un des centaines de projets open source existants. Vous avez poussé « l’entreprise » à vous aider à formuler les exigences sous une forme qui rende une solution distribuée beaucoup plus simple (et donc fiable). Maintenant, faites l’effort de trouver le bon logiciel qui résoudra les parties non uniques de votre problème afin de pouvoir vous concentrer sur ce qui rend votre entreprise spéciale.

Oui, la fabrication d’outils est amusante. J’adore ça et je pourrais le faire toute la journée. Et en effet, formuler votre problème sous une forme qui vous fait ressembler à un flocon de neige unique est bon pour votre estime de soi. Laissez tomber et continuez à résoudre de vrais problèmes, ceux qui font le succès de votre entreprise.