21 articles tagués avec « Architecture »

L'essentiel de ce blog est allé en profondeur sur une chose à la fois — comparaison-et-échange, transactions multi-clés, structures de données natives, streams, watch, le journal d'opérations en dessous. Chaque article répond à « comment ceci fonctionne ». Celui-ci répond à une question différente, plus pratique : quand vous avez un problème devant vous, lequel choisissez-vous ?

Cette question compte parce que le mauvais choix est rarement un plantage. C'est un système qui marche dans la démo puis perd une mise à jour sous charge, ou qui canalise un millier d'écrivains à travers une seule clé, ou qui utilise une notification tire-et-oublie là où il lui fallait un journal durable. Les primitives ne vous empêchent pas de les mal utiliser. Alors voici un guide de terrain : le modèle mental qui les relie, une table de décision, une descente de chaque branche avec son adéquation honnête et sa limite honnête, et un organigramme à la fin.

La plupart des stores de données distribués vous obligent à choisir, tôt et définitivement, entre deux mondes. Il y a le « vrai » store — un cluster que vous déployez, vers lequel vous pointez un client sur le réseau, et auquel vous parlez via un protocole de communication. Et il y a le « faux » store auquel vous recourez dans les tests unitaires : un dictionnaire en mémoire, un mock, un bouchon fait main qui implémente juste assez de l'interface pour que le test compile. Les deux ne partagent rien. Votre test exerce le comportement du bouchon, pas celui du store, et l'écart entre eux est exactement là où se cachent les bugs.

Zaris supprime ce choix. Le même client .NET typé qui parle à un cluster distribué sur TLS exécute aussi le store embarqué à l'intérieur de votre processus, sans socket, sans carte de partitions et sans déploiement — et c'est le même moteur de store, pas un substitut. Vous sélectionnez lequel vous obtenez avec une seule chaîne de connexion. Cet article traite de la façon dont cela fonctionne, des cas pour lesquels il est véritablement bon, et de la ligne dure où le mode embarqué s'arrête et où un cluster commence.

Il y a une question que chaque développeur finit par poser à un store distribué, généralement juste après un rapport de bug déroutant : si j'écris une valeur puis la relis immédiatement, suis-je garanti de voir ce que j'ai écrit ? On dirait que cela devrait avoir une réponse en un mot. Ce n'est pas le cas — ni pour aucun store partitionné et répliqué, ni pour Zaris. La réponse honnête est « oui, au sein d'une partition, parce que les lectures vont au même propriétaire unique que votre écriture » — et la partie intéressante est tout ce qui est contenu dans ce qualificatif.

Cet article est le modèle de cohérence de Zaris, assemblé en un seul endroit. Nous avons écrit sur les pièces séparément — comparaison-et-échange optimiste, nouvelle tentative transparente lors du changement de propriété, le journal d'opérations rejouable qui alimente les réplicas, transactions multi-clés. Ici nous les relions du côté du lecteur et répondons à la seule question qui compte derrière un clavier : quand je lis, qu'est-ce qui m'est réellement promis ? Y compris, surtout, là où la promesse s'arrête.

Les licences sont la partie d'un produit à laquelle la plupart des ingénieurs ne veulent jamais penser, et cela se voit. Le schéma habituel est une bombe à retardement : une date est vérifiée, et quand elle passe, le logiciel vous punit — il lève une exception au démarrage, il corrompt ou efface l'état local pour vous empêcher de le « voler », ou il plante simplement et emporte vos données avec lui. Cette conception traite vos propres opérateurs en adversaires, et elle échoue exactement au moment où vous pouvez le moins vous le permettre : en production, après que l'horloge a silencieusement basculé.

Zaris adopte la posture inverse. La vérification de licence est l'interrupteur le plus critique pour la sûreté d'un store de données distribué, alors elle est construite comme tel : une unique fonction de politique pure et déterministe, un chemin d'application gracieux et entièrement réversible qui ne détruit jamais un octet, et une horloge par machine qui reprend à l'instant où vous activez une clé. Cet article parcourt le fonctionnement réel de ce cycle de vie dans le code livré — car l'ingénierie intéressante ici réside dans ce qu'il refuse de vous faire subir.

Deux événements d'apparence très différente dans un store distribué s'avèrent être le même problème en dessous. Le premier : un réplica prend du retard sur son primaire — une pause de ramasse-miettes, un disque lent, une brève partition réseau — et détient désormais une copie périmée d'une partition qu'il doit finir par faire correspondre. Le second : une partition est réassignée à un nœud qui ne l'a jamais détenue, et ce nœud doit acquérir l'ensemble complet des données auprès du propriétaire actuel. L'un est un retard de réplication ; l'autre est une migration. Ils ont des déclencheurs différents, des opérateurs différents, des histoires d'échec différentes.

Mais la question à laquelle chacun doit répondre est identique : comment converger vers la vérité courante de cette partition sans geler les écritures pendant que je le fais ? Zaris répond aux deux avec un seul mécanisme — un journal d'opérations ordonné par révision, tenu par segment, rejoué depuis un point connu. Cet article porte sur ce journal : comment il est construit sur le chemin d'écriture, comment il est borné pour ne pas pouvoir grossir sans limite, comment il est rejoué, et pourquoi exactement le même substrat conduit à la convergence tant un réplica en retard qu'un propriétaire flambant neuf.

Il y a un nombre que tout ingénieur performance .NET finit par mémoriser : 85 000 octets. Toute allocation unique au-delà d'environ cette taille ne va pas sur le tas normal des petits objets — elle va sur le Large Object Heap (LOH). Le LOH est une autre bête. Il n'est collecté que lors d'un ramasse-miettes gen-2 (complet), et par défaut il n'est pas compacté. Cette combinaison convient à un gros tampon que vous allouez une fois et conservez. Elle ne convient pas à un store en mémoire à faible latence qui écrit et réécrit à répétition de grandes valeurs.

Imaginez la charge de travail : gros blobs sérialisés, grands documents JSON, images, charges utiles de protocole — stockés, mis à jour, remplacés, encore et encore. Chacune de ces grandes écritures dépose un objet neuf sur le LOH. Comme le LOH n'est pas compacté, les emplacements libérés ne fusionnent pas en espace contigu ; ils se fragmentent. Et comme en récupérer la moindre partie implique un ramasse-miettes gen-2 complet, les pauses s'allongent et surviennent plus souvent précisément à mesure que l'ensemble de travail grossit. Pour un store dont tout l'argumentaire est la faible latence, c'est le mauvais type de surprise.

Zaris propose une fonctionnalité optionnelle pour contourner entièrement le LOH pour ces valeurs. Elle est désactivée par défaut, et cet article porte sur ce qu'elle fait, comment elle fonctionne, et — tout aussi important — quand vous devriez et ne devriez pas l'activer.

La capacité n'est jamais juste longtemps. Le trafic augmente, un lancement a lieu, une saison se termine — et le store que vous avez dimensionné le trimestre dernier est soit saturé, soit à moitié inactif. La question qui décide si c'est une corvée ou une crise est simple : pouvez-vous changer la taille d'un store en cours d'exécution sans l'arrêter ?

Pour Zaris la réponse est oui, avec une asymétrie importante qu'il vaut la peine d'avouer d'emblée. La mise à l'échelle horizontale — ajouter des serveurs — est la direction facile, sûre et sans perte, et elle se produit en direct pendant que le store continue de servir. La réduction d'échelle — retirer des serveurs — est également prise en charge, mais c'est une opération délibérée et surveillée, car les données du serveur qui part doivent d'abord aller quelque part.

Cet article parcourt les deux directions : agrandir un store avec Add-ZrServer, le réduire avec Remove-ZrServer, pourquoi la réduction nécessite un drain, et où s'insère la console web.

Le moyen le plus sûr de garantir que TLS sera contourné est d'imposer un unique modèle de confiance à tout le monde. Un développeur qui exécute un store sur un ordinateur portable ne veut pas monter une CA. Une banque dont la racine hors ligne est dans un HSM ne veut pas du tout que votre outil frappe des certificats. Livrez un store qui ne connaît qu'un seul de ces cas, et la moitié de vos utilisateurs désactiveront la sécurité pour faire leur travail.

Zaris ne choisit donc pas à votre place. Sa confiance TLS est enfichable selon quatre modes d'autorité de certification, du self-signed zéro-configuration jusqu'aux certificats que vous provisionnez entièrement hors bande. Vous choisissez le mode qui correspond à la PKI que vous exploitez déjà, et Zaris s'y insère au lieu de vous demander de tout reconstruire autour de lui. TLS n'est pas une solution universelle, et le traiter ainsi est précisément la raison pour laquelle la sécurité est repoussée.

Zaris est un store clé-valeur distribué conçu nativement pour .NET. Ses clients de premier ordre parlent un protocole binaire efficace, et si votre pile est en .NET, c'est le chemin que vous voulez — de véritables API asynchrones, des types .NET, des primitives de coordination, des remplacements directs IDistributedCache et HybridCache.

Mais la plupart des systèmes ne sont pas uniquement en .NET. Il y a un service Python qui fait du traitement de données, un sidecar Go, un exécuteur de tâches Ruby, une passerelle Node. Les réécrire tous vers un nouveau client pour essayer un nouveau store est inenvisageable. Aussi, dans la 2.0.0, chaque nœud Zaris peut également exposer un listener protocole-Redis (RESP2) : pointez un client Redis existant vers lui et utilisez Zaris comme store clé-valeur en remplacement direct, dans n'importe quel langage, sans changer une ligne de code client.

Cet article explique comment ce front-end fonctionne réellement — le modèle de routage, le modèle de données, les modèles de basculement, et exactement quelles commandes sont prises en charge ou non.

Aujourd'hui, nous publions Zaris 0.9.0, et avec lui, Zaris atteint la disponibilité générale. Il est prêt pour la production, multiplateforme, et désormais soutenu par un support commercial.

Si vous ne le connaissez pas encore : Zaris est un store clé-valeur distribué et en mémoire pour .NET. Il est rapide, répliqué, et vous pouvez le piloter depuis un navigateur, PowerShell, ou directement depuis votre application. Cette version est l'aboutissement de ce travail — le moment où un « projet prometteur » devient une « solution que vous pouvez mettre en production ».