Dr. Martin Kleppmann est chercheur en systèmes distribués à l'Université de Cambridge et auteur du très apprécié
"Designing Data-Intensive Applications" (O'Reilly Media, 2017).
Kevin Scott, CTO chez Microsoft,
a déclaré un jour : «Ce livre devrait être une lecture obligatoire pour les ingénieurs logiciels. "La conception d'applications à forte intensité de données est une ressource rare qui relie la théorie et la pratique pour aider les développeurs à prendre des décisions intelligentes lors de la conception et de la mise en œuvre de l'infrastructure et des systèmes de données."
Les principaux intérêts de recherche de Martin incluent les logiciels de collaboration, les CRDT et la vérification formelle des algorithmes distribués. Auparavant, il était ingénieur logiciel et entrepreneur dans plusieurs sociétés Internet, dont LinkedIn et Rapportive, où il a travaillé sur une infrastructure de données à grande échelle.
Vadim Tsesko (
@incubos ) est un ingénieur logiciel principal chez
Odnoklassniki qui travaille dans l'équipe Core Platform. Les intérêts scientifiques et techniques de Vadim incluent les systèmes distribués, les entrepôts de données et la vérification des systèmes logiciels.
Contenu:
- Passer de la recherche commerciale à la recherche universitaire;
- Discussion sur "Conception d'applications à forte intensité de données";
- Bon sens contre le battage médiatique artificiel et le marketing agressif;
- Pièges du théorème de la PAC et d'autres erreurs de l'industrie;
- Avantages de la décentralisation;
- Blockchains, Dat, IPFS, Filecoin, WebRTC;
- Nouveaux CRDT. Vérification formelle avec Isabelle;
- Sourcing d'événements. Approche de bas niveau. Transactions XA
- Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
- Comment appliquer tous ces outils à la vie réelle;
- Public cible attendu des pourparlers de Martin et de la conférence Hydra.
Passer de la recherche commerciale à la recherche universitaire
Vadim : La première question que je voudrais vous poser est vraiment importante pour moi. Vous avez fondé Go Test It et Rapportive, et vous conceviez et développiez des systèmes à grande échelle chez LinkedIn depuis un certain temps. Vous avez ensuite décidé de passer de l'ingénierie industrielle au milieu universitaire. Pourriez-vous expliquer la motivation de cette décision? Qu'avez-vous gagné et qu'avez-vous dû sacrifier?
Martin : Ce fut un processus très intéressant. Comme vous semblez le laisser entendre, peu de gens font le changement dans cette direction. Beaucoup de gens passent du monde universitaire à l'industrie, mais pas beaucoup en retour. Ce qui est compréhensible, car j'ai dû subir une réduction de salaire assez importante pour retourner au monde universitaire. Mais ce que j'aime vraiment dans la recherche, c'est la liberté de travailler sur des sujets que je trouve intéressants et que je pense importants, même si ces sujets ne conduisent pas immédiatement à un produit commercialement viable dans les 6 prochains mois environ. Bien sûr, dans une entreprise, ce que vous construisez doit se transformer en un produit qui peut être vendu sous une forme ou une autre. D'un autre côté, les choses sur lesquelles je travaille actuellement sont des sujets qui sont vraiment importants pour l'avenir de la façon dont nous créons des logiciels et comment Internet fonctionne. Mais nous ne comprenons pas encore assez bien ces sujets pour commencer à construire des produits commerciaux: nous sommes toujours au niveau d'essayer de comprendre, fondamentalement, à quoi ces technologies doivent ressembler. Et comme il s'agit d'une recherche fondamentale, j'ai réalisé qu'il vaut mieux le faire dans une université que d'essayer de le faire dans une entreprise, car dans une université, je suis libre de travailler sur des choses qui pourraient ne pas devenir commercialement viables avant dix ans, et c'est OK. C'est OK de travailler avec un horizon temporel beaucoup plus long lorsque vous êtes en recherche.
«Conception d'applications à forte intensité de données»
Vadim : Nous reviendrons certainement sur vos intérêts de recherche actuels. En attendant, parlons de votre dernier livre
Designing Data-Intensive Applications . Je suis un grand fan de votre livre et je pense que c'est l'un des meilleurs guides pour construire des systèmes distribués modernes. Vous avez couvert presque toutes les réalisations notables à jour.
Martin : Merci, je suis content que vous le trouviez utile.
Vadim : Juste pour les lecteurs malchanceux qui n'ont pas encore lu votre livre, pourriez-vous citer plusieurs réalisations majeures dans le domaine des systèmes distribués de nos jours?
Martin : Eh bien, le but du livre n'est pas tant d'expliquer une technologie particulière; l'objectif est plutôt de vous donner un guide sur l'ensemble du paysage des différents systèmes utilisés pour le stockage et le traitement des données. Il y a tellement de bases de données différentes, de processeurs de flux, d'outils de traitement par lots, de toutes sortes d'outils de réplication et ainsi de suite, et il est vraiment difficile d'avoir un aperçu. Si vous essayez de créer une application particulière, il est vraiment difficile de savoir quelle base de données vous devez utiliser et quels outils sont les plus appropriés pour le problème que vous essayez de résoudre. Beaucoup de livres informatiques existants n'ont tout simplement pas répondu à ce problème de manière satisfaisante. J'ai trouvé que si vous lisez un livre sur Cassandra par exemple, cela vous dirait pourquoi Cassandra est merveilleux, mais il ne vous dirait généralement pas des choses pour lesquelles ce n'est pas un bon choix. Donc, ce que je voulais vraiment faire dans ce livre était d'identifier les principales questions que vous devez vous poser si vous essayez de construire une sorte de système à grande échelle. Et en répondant à ces questions, vous pouvez ensuite aider à déterminer quelles technologies sont appropriées et lesquelles sont moins appropriées au problème particulier que vous essayez de résoudre - car, en général, il n'y a pas une technologie qui soit parfaite pour tout. Et donc, le livre essaie de vous aider à comprendre les avantages et les inconvénients des différentes technologies dans différents contextes.
Bon sens contre le battage médiatique artificiel et le marketing agressif
Vadim : En effet, souvent - sinon toujours - il existe de nombreuses technologies avec des fonctions, des fonctionnalités et des modèles de données qui se chevauchent. Et vous ne pouvez pas croire tous ces mots à la mode marketing. Vous devez lire les livres blancs pour apprendre les composants internes et même essayer de lire le code source pour comprendre comment cela fonctionne exactement.
Martin : Et j'ai trouvé que vous devez souvent lire entre les lignes parce que souvent la documentation ne vous dit pas vraiment pour quelles choses une base de données particulière aspire. La vérité est que chaque base de données aspire à une sorte de charge de travail, la question est simplement de savoir lesquelles elles sont. Alors oui, il faut parfois lire les directives de déploiement pour les opérateurs et essayer de procéder à une rétro-ingénierie à partir de ce qui se passe réellement sur le système.
Vadim : Ne pensez-vous pas que l’industrie n’a pas le vocabulaire commun ou un ensemble de critères pour comparer différentes solutions pour le même problème? Des choses similaires sont appelées par des noms différents, certaines choses sont omises et doivent toujours être claires et explicites, comme les garanties de transaction. Qu'en penses-tu?
Martin : Oui, je pense que l'un des problèmes de notre industrie est que souvent, lorsque les gens parlent d'un outil particulier, il y a beaucoup de battage médiatique autour de tout. Ce qui est compréhensible, car les outils sont fabriqués par diverses entreprises, et évidemment, ces entreprises veulent promouvoir leurs produits, et donc ces entreprises enverront des gens à des conférences pour parler de la beauté de leur produit, essentiellement. Il sera déguisé en discours technique, mais il s'agit essentiellement d'une activité commerciale. En tant qu'industrie, nous pourrions vraiment faire avec plus d'honnêteté les avantages et les inconvénients de certains produits. Et une partie de cela nécessite une terminologie commune, car sinon vous ne pouvez tout simplement pas comparer les choses sur un pied d'égalité. Mais au-delà d'une terminologie partagée, nous avons besoin de moyens de raisonner sur des choses que certaines technologies sont bonnes ou mauvaises.
Pièges du théorème de la PAC et autres erreurs de l'industrie
Vadim : Ma prochaine question est assez controversée. Pourriez-vous s'il vous plaît nommer les erreurs majeures dans l'industrie que vous avez rencontrées au cours de votre carrière? Peut-être des technologies surévaluées ou des solutions largement utilisées dont nous aurions dû nous débarrasser il y a longtemps? Ce pourrait être un mauvais exemple, mais comparez JSON sur HTTP / 1.1 avec le gRPC beaucoup plus efficace sur HTTP / 2. Ou existe-t-il un autre point de vue?
Martin : Je pense que dans de nombreux cas, il y a de très bonnes raisons pour lesquelles une technologie fait une chose et pas une autre. J'hésite donc beaucoup à appeler les choses des erreurs, car dans la plupart des cas, c'est une question de compromis. Dans votre exemple de JSON sur HTTP / 1.1 contre les tampons de protocole sur HTTP / 2, je pense qu'il y a en fait des arguments tout à fait raisonnables pour les deux côtés. Par exemple, si vous souhaitez utiliser des tampons de protocole, vous devez définir votre schéma, et un schéma peut être une chose merveilleuse car il aide à documenter exactement la communication en cours. Mais certaines personnes trouvent les schémas ennuyeux, surtout s'ils en sont aux premiers stades de développement et qu'ils changent très fréquemment de format de données. Donc voilà, il y a une question de compromis; dans certaines situations, l'un est meilleur, dans d'autres, l'autre est meilleur.
En termes d'erreurs réelles qui me paraissent tout simplement mauvaises, il n'y a qu'un assez petit nombre de choses. Une opinion que j'ai est que le théorème de la PAC est fondamentalement mauvais et simplement inutile. Chaque fois que les gens utilisent le théorème de la PAC pour justifier des décisions de conception, je pense souvent qu'ils interprètent mal ce que la PAC dit réellement ou énoncent l'évidence d'une manière. Le CAP en tant que théorème a un problème qu'il énonce simplement l'évidence. De plus, il parle d'un seul modèle de cohérence très étroitement défini, à savoir la linéarisation, et d'un modèle de disponibilité très étroitement défini, à savoir: vous voulez que chaque réplique soit entièrement disponible pour les lectures et les écritures, même si elle ne peut pas communiquer avec d'autres répliques. Ce sont des définitions raisonnables, mais elles sont très étroites, et de nombreuses applications ne tombent tout simplement pas dans le cas d'avoir besoin précisément de cette définition de cohérence ou précisément de cette définition de disponibilité. Et pour toutes les applications qui utilisent une définition différente de ces mots, le théorème CAP ne vous dit rien du tout. C'est simplement une déclaration vide. Donc, je pense que c'est une erreur.
Et pendant que nous nous déchaînons, si vous me demandez de nommer des erreurs, une autre grosse erreur que je vois dans l'industrie technologique est l'extraction de crypto-monnaies, qui je pense est un gaspillage d'électricité si flagrant. Je n'arrive pas à comprendre pourquoi les gens pensent que c'est une bonne idée.
Vadim : En parlant du théorème du CAP, de nombreuses technologies de stockage sont en fait réglables, en termes de choses comme AP ou CP. Vous pouvez choisir le mode dans lequel ils opèrent.
Martin : Oui. De plus, il existe de nombreuses technologies qui ne sont ni cohérentes ni disponibles selon la définition stricte du théorème de la PAC. Ils sont littéralement juste P! Pas CP, pas CA, pas AP, juste P. Personne ne dit cela, car cela aurait l'air mauvais, mais honnêtement, cela pourrait être une décision de conception parfaitement raisonnable à prendre. Il existe de nombreux systèmes pour lesquels cela est en fait tout à fait correct. C'est en fait l'une des raisons pour lesquelles je pense que CAP est une façon si inutile de parler des choses: parce qu'il y a une grande partie de l'espace de conception qu'il ne capture tout simplement pas, où il existe de bonnes conceptions parfaitement raisonnables pour les logiciels qu'il ne vous permet tout simplement pas d'en parler.
Avantages de la décentralisation
Vadim : En ce qui concerne les applications gourmandes en données aujourd'hui, quels autres défis majeurs, problèmes non résolus ou sujets de recherche chauds pouvez-vous citer? Pour autant que je sache, vous êtes un grand partisan du calcul et du stockage décentralisés.
Martin : Oui. L'une des thèses à l'origine de mes recherches est qu'en ce moment nous comptons trop sur les serveurs et la centralisation. Si vous pensez à la façon dont Internet a été conçu à l'origine à l'époque où il a évolué à partir d'ARPANET, il était conçu comme un réseau très résilient où les paquets pouvaient être envoyés via plusieurs itinéraires différents, et ils atteindraient toujours la destination. Et si une bombe nucléaire frappait une ville américaine particulière, le reste du réseau continuerait de fonctionner car il ne ferait que contourner les parties défaillantes du système. C'était une conception de la guerre froide.
Et puis nous avons décidé de tout mettre dans le cloud, et maintenant, fondamentalement, tout doit passer par l'un des centres de données d'AWS, comme us-east-1 quelque part en Virginie. Nous avons supprimé cet idéal de pouvoir utiliser de manière décentralisée différentes parties du réseau, et nous avons installé ces serveurs sur lesquels tout repose, et maintenant il est extrêmement centralisé. Je suis donc intéressé par la décentralisation, dans le sens de déplacer une partie de la puissance et du contrôle des données loin de ces serveurs et de revenir aux utilisateurs finaux.
Une chose que je veux ajouter dans ce contexte est que beaucoup de gens qui parlent de décentralisation parlent de choses comme les crypto-monnaies, car ils tentent également une forme de décentralisation par laquelle le contrôle est éloigné d'une autorité centrale comme une banque et dans un réseau de nœuds coopérants. Mais ce n'est pas vraiment le genre de décentralisation qui m'intéresse: je trouve que ces crypto-monnaies sont en fait toujours extrêmement centralisées, dans le sens où si vous voulez faire une transaction Bitcoin, vous devez la faire sur le réseau Bitcoin - vous doivent utiliser le réseau de Bitcoin, donc tout est centralisé sur ce réseau particulier. La façon dont il est construit est décentralisée dans le sens où il n'a pas de nœud de contrôle unique, mais le réseau dans son ensemble est extrêmement centralisé dans la mesure où toute transaction que vous devez effectuer doit être effectuée via ce réseau. Vous ne pouvez pas le faire d'une autre manière. Je pense que c'est toujours une forme de centralisation.
Dans le cas d'une crypto-monnaie, cette centralisation peut être inévitable, car vous devez faire des choses comme éviter de doubler les dépenses, et cela est difficile sans un réseau qui parvient à un consensus sur les transactions qui ont eu lieu et celles qui ne l'ont pas été. Et c'est exactement ce que fait le réseau Bitcoin. Mais il existe de nombreuses applications qui ne nécessitent pas quelque chose comme une blockchain, qui peut en fait faire face à un modèle beaucoup plus flexible de données circulant dans le système. Et c'est le type de système décentralisé qui m'intéresse le plus.
Vadim : Pouvez-vous nommer des technologies prometteuses ou sous-évaluées dans le domaine des systèmes décentralisés en dehors de la blockchain? J'utilise IPFS depuis un certain temps.
Martin : Pour IPFS, je l'ai étudié un peu mais je ne l'ai pas utilisé moi-même. Nous avons effectué quelques travaux avec le projet
Dat , qui est quelque peu similaire à
IPFS dans le sens où il s'agit également d'une technologie de stockage décentralisé. La différence est que IPFS a
Filecoin , une crypto-monnaie, qui lui est attachée comme moyen de payer pour les ressources de stockage, tandis que Dat n'a pas de blockchain attachée - c'est purement un moyen de répliquer des données sur plusieurs machines de manière P2P.
Pour le projet sur lequel je travaille, Dat a été assez bien adapté, car nous voulions créer un logiciel de collaboration dans lequel plusieurs utilisateurs différents pourraient chacun modifier un document ou une base de données, et toute modification de ces données serait envoyée à n'importe qui sinon qui a besoin d'une copie de ces données. Nous pouvons utiliser Dat pour effectuer cette réplication de manière P2P, et Dat s'occupe de toutes les choses au niveau du réseau, telles que la traversée NAT et le passage à travers les pare-feu - c'est un problème assez délicat juste pour obtenir les paquets d'un bout à l'autre . Et puis nous avons construit une couche en plus de cela, en utilisant des CRDT, ce qui est un moyen de permettre à plusieurs personnes de modifier un document ou un ensemble de données et d'échanger ces modifications de manière efficace. Je pense que vous pouvez probablement créer ce genre de chose sur IPFS également: vous pouvez probablement ignorer l'aspect Filecoin et simplement utiliser l'aspect de réplication P2P, et il fera probablement le travail tout aussi bien.
Vadim : Bien sûr, bien que l'utilisation d'IPFS puisse entraîner une baisse de la réactivité, car le Dat sous-jacent WebRTC connecte directement les nœuds P2P, et IPFS fonctionne comme une table de hachage distribuée.
Martin : Eh bien, WebRTC est à un niveau différent de la pile, car il est principalement destiné à connecter deux personnes qui pourraient avoir un appel vidéo; en fait, le logiciel que nous utilisons pour cette interview en ce moment pourrait bien utiliser WebRTC. Et WebRTC vous donne un canal de données que vous pouvez utiliser pour envoyer des données binaires arbitraires dessus, mais la construction d'un système de réplication complet en plus de cela est encore un peu de travail. Et c'est quelque chose que Dat ou IPFS font déjà.
Vous avez mentionné la réactivité - c'est certainement une chose à laquelle penser. Imaginons que vous souhaitiez créer les prochains documents Google de manière décentralisée. Avec Google Docs, l'unité de modifications que vous apportez est une seule touche. Chaque lettre que vous tapez sur votre clavier peut être envoyée en temps réel à vos collaborateurs, ce qui est excellent du point de vue d'une collaboration rapide en temps réel. Mais cela signifie également qu'au cours de l'écriture d'un document volumineux, vous pourriez avoir des centaines de milliers de ces modifications à caractère unique qui s'accumulent, et beaucoup de ces technologies ne sont pas très efficaces actuellement pour compresser ce type de données d'édition. Vous pouvez conserver toutes les modifications que vous avez déjà apportées à votre document, mais même si vous n'envoyez qu'une centaine d'octets pour chaque frappe que vous effectuez et que vous écrivez un document légèrement plus grand avec, disons, 100 000 frappes, vous soudainement maintenant avoir 10 Mo de données pour un document qui ne représenterait normalement que quelques dizaines de kilo-octets. Nous avons donc cette énorme surcharge pour la quantité de données qui doit être envoyée, à moins que nous ne devenions plus intelligents pour compresser et empaqueter les modifications.
Plutôt que d'envoyer à quelqu'un la liste complète de tous les caractères qui ont été saisis, nous pourrions simplement envoyer l'état actuel du document, puis nous enverrons les mises à jour qui se sont produites depuis. Mais beaucoup de ces systèmes peer-to-peer n'ont pas encore un moyen de faire ces instantanés d'état d'une manière qui serait suffisamment efficace pour les utiliser pour quelque chose comme Google Docs. C'est en fait un domaine sur lequel je travaille activement, en essayant de trouver de meilleurs algorithmes pour synchroniser différents utilisateurs pour quelque chose comme un document texte, où nous ne voulons pas conserver chaque touche car cela serait trop cher, et nous voulons pour utiliser plus efficacement la bande passante du réseau.
Nouveaux CRDT. Vérification formelle avec isabelle
Vadim : Avez-vous réussi à compresser considérablement ces données de frappe? Avez-vous inventé de nouveaux CRDT ou quelque chose de similaire?
Martin : Oui. Jusqu'à présent, nous n'avons que des prototypes pour cela, il n'est pas encore entièrement mis en œuvre, et nous devons encore faire d'autres expériences pour mesurer son efficacité réelle dans la pratique. Mais nous avons développé des schémas de compression qui semblent très prometteurs. Dans mon prototype, je l'ai réduit d'environ 100 octets par édition à quelque chose comme 1,7 octet de surcharge par édition. Et c'est beaucoup plus raisonnable bien sûr. Mais comme je l'ai dit, ces expériences sont toujours en cours, et le nombre pourrait encore légèrement changer. Mais je pense que l'essentiel est qu'il y a encore beaucoup de place pour l'optimisation, donc nous pouvons encore l'améliorer beaucoup.
Vadim : C'est donc de cela que vous parlerez lors de la
conférence Hydra , ai-je raison?
Martin : Oui, exactement. Je donnerai une brève introduction au domaine des CRDT, des logiciels collaboratifs et de certains des problèmes qui se posent dans ce contexte. Je décrirai ensuite certaines des recherches que nous avons effectuées dans ce domaine. Cela a été assez amusant, car les recherches que nous avons menées ont porté sur toute une gamme de préoccupations différentes. Du côté très appliqué, nous avons une implémentation JavaScript de ces algorithmes, et nous l'utilisons pour créer de vrais logiciels, essayant d'utiliser ce logiciel nous-mêmes pour voir comment il se comporte. À l'autre extrémité du spectre, nous avons travaillé avec des méthodes formelles pour prouver la validité de ces algorithmes, car certains de ces algorithmes sont assez subtils et nous voulons être très sûrs que les systèmes que nous créons sont réellement corrects, c'est-à-dire que ils atteignent toujours un état cohérent. Il y a eu beaucoup d'algorithmes dans le passé qui n'ont pas réussi à le faire, qui étaient tout simplement faux, c'est-à-dire que, dans certains cas extrêmes, ils resteraient incohérents de façon permanente. Et donc, afin d'éviter ces problèmes que les algorithmes ont eu dans le passé, nous avons utilisé des méthodes formelles pour prouver que nos algorithmes sont corrects.
Vadim : Wow. Utilisez-vous vraiment des démonstrateurs de théorèmes, comme Coq ou Isabelle ou autre chose?
Martin : Exactement, nous utilisons Isabelle pour ça.
Vous pouvez assister à la conférence de Martin "Preuve d'exactitude des systèmes distribués avec Isabelle" à la conférence The Strange Loop en septembre.
Vadim : Ça a l'air génial! Ces preuves vont-elles être publiées?
Martin : Oui, notre premier jeu d'épreuves est déjà public. Nous l'avons
publié il y a un an et demi: c'était un cadre de vérification des CRDT, et nous avons vérifié trois CRDT particuliers dans ce cadre, dont le principal était RGA (
Replicated Growable Array ), qui est un CRDT pour l'édition de texte collaborative. Bien que ce ne soit pas très compliqué, c'est un algorithme assez subtil, et c'est donc un bon cas où une preuve est nécessaire, car il n'est pas évident simplement en le regardant qu'il est vraiment correct. Et donc la preuve nous donne la certitude supplémentaire qu'elle est vraiment correcte. Notre travail précédent portait sur la vérification de quelques CRDT existants, et notre travail le plus récent dans ce domaine concerne nos propres CRDT pour les nouveaux modèles de données que nous avons développés et la vérification de nos propres CRDT corrects également.
Vadim : Quelle est la taille de la preuve par rapport à la description de l'algorithme? Parce que cela peut parfois être un problème.
Martin : Oui, c'est un problème - les preuves demandent souvent beaucoup de travail. Je pense que dans notre dernier exemple ... En fait, laissez-moi jeter un coup d'œil au code. La description de l'algorithme et des structures de données est d'environ 60 lignes de code. C'est donc un petit algorithme. La preuve est de plus de 800 lignes. Nous avons donc un rapport d'environ 12: 1 entre la preuve et le code. Et c'est malheureusement assez typique. La preuve est un gros travail supplémentaire. D'un autre côté, une fois que nous en avons la preuve, nous avons acquis une très grande certitude quant à l'exactitude de l'algorithme. De plus, nous avons nous-mêmes, en tant qu'humains, compris bien mieux l'algorithme. Souvent, je trouve qu'en essayant de le formaliser, nous finissons par comprendre ce que nous essayons de formaliser beaucoup mieux qu'avant. Et cela en soi est en fait un résultat utile de ce travail: en plus de la preuve elle-même, nous acquérons une compréhension plus profonde, et cela est souvent très utile pour créer de meilleures implémentations.
Vadim : Pourriez-vous s'il vous plaît décrire le public cible de votre discours, quel sera le niveau de hardcore? Quelles sont les connaissances préliminaires que vous attendez du public?
Martin : J'aime rendre mes discussions accessibles avec le moins de connaissances préalables possible, et j'essaie d'élever tout le monde au même niveau. Je couvre beaucoup de matière, mais je commence sur une base basse. Je m'attendrais à ce que les gens aient une expérience générale des systèmes distribués: comment envoyer des données sur un réseau en utilisant TCP, ou peut-être une idée approximative du fonctionnement de Git, qui est un assez bon modèle pour ces choses. Mais c'est à peu près tout ce dont vous avez besoin, vraiment. Ensuite, comprendre le travail que nous avons accompli en plus de cela n'est en fait pas trop difficile. J'explique tout par l'exemple, en utilisant des images pour tout illustrer. Espérons que tout le monde pourra suivre.
Sourcing d'événements. Approche de bas niveau. Transactions XA
Vadim : Sonne vraiment super. En fait, nous avons un peu de temps et je voudrais discuter de l'un de vos
articles récents sur le traitement des événements en ligne. Vous êtes un grand partisan de l'idée de sourcing d'événements, n'est-ce pas?
Martin : Oui, bien sûr.
Vadim : Aujourd'hui, cette approche prend de l'ampleur, et dans la poursuite de tous les avantages d'un journal des opérations ordonné mondialement, de nombreux ingénieurs tentent de le déployer partout. Pourriez-vous s'il vous plaît décrire certains cas où la recherche d'événements n'est pas la meilleure option? Juste pour éviter son utilisation abusive et sa déception éventuelle avec l'approche elle-même.
Martin : Il y a deux couches différentes de la pile dont nous devons d'abord parler. Le sourcing d'événements, tel que proposé par Greg Young et quelques autres, est conçu comme un mécanisme de modélisation des données, c'est-à-dire: si vous avez un schéma de base de données et que vous commencez à en perdre le contrôle car il y a tellement de tables différentes et elles '' Tout le monde est modifié par différentes transactions - alors le sourcing d'événements est un moyen d'apporter une meilleure clarté à ce modèle de données, car les événements peuvent exprimer très directement ce qui se passe au niveau de l'entreprise. Quelle est l'action entreprise par l'utilisateur? Et puis, les conséquences de cette action peuvent être la mise à jour de diverses tables et ainsi de suite.Effectivement, ce que vous faites avec le sourcing d'événements, c'est que vous séparez l'action (l'événement) de ses effets, qui se produisent quelque part en aval.
Je suis venu dans ce domaine sous un angle légèrement différent, ce qui est un point de vue de niveau inférieur d'utiliser des systèmes comme Kafka pour construire des systèmes hautement évolutifs. Cette vue est similaire en ce sens que si vous utilisez quelque chose comme Kafka, vous utilisez des événements, mais cela ne signifie pas que vous utilisez nécessairement la recherche d'événements. Et inversement, vous n'avez pas besoin d'utiliser Kafka pour faire du sourcing d'événements; vous pouvez faire du sourcing d'événements dans une base de données régulière, ou vous pouvez utiliser une base de données spéciale conçue spécifiquement pour le sourcing d'événements. Ces deux idées sont donc similaires, mais aucune ne nécessite l'autre, elles ont juste un certain chevauchement.
L'argument pour vouloir utiliser un système comme Kafka est principalement l'argument de l'évolutivité: dans ce cas, vous avez simplement tellement de données qui arrivent que vous ne pouvez pas les traiter de manière réaliste sur une base de données à nœud unique, vous devez donc les partitionner dans certains manière, et en utilisant un journal des événements comme Kafka vous donne un bon moyen de répartir ce travail sur plusieurs machines. Il fournit une bonne méthode de mise à l'échelle des systèmes. C'est particulièrement utile si vous souhaitez intégrer plusieurs systèmes de stockage différents. Donc, si, par exemple, vous souhaitez mettre à jour non seulement votre base de données relationnelle, mais aussi, disons, un index de recherche en texte intégral comme Elasticsearch, ou un système de mise en cache comme Memcached ou Redis ou quelque chose comme ça, et vous voulez qu'un événement ait un effet de mise à jour sur tous ces différents systèmes, alors quelque chose comme Kafka est très utile.
En ce qui concerne la question que vous avez posée (quelles sont les situations dans lesquelles je n'utiliserais pas cette approche de sourcing d'événements ou de journal des événements) - je pense qu'il est difficile de le dire avec précision, mais en règle générale, je dirais: utilisez ce qui est le plus simple . Autrement dit, tout ce qui est le plus proche du domaine que vous essayez de mettre en œuvre. Et donc, si la chose que vous essayez d'implémenter est très bien mappée vers une base de données relationnelle, dans laquelle vous insérez et mettez à jour et supprimez simplement certaines lignes, utilisez simplement une base de données relationnelle et insérez, mettez à jour et supprimez certaines lignes. Il n'y a rien de mal à utiliser des bases de données relationnelles et à les utiliser telles quelles. Ils ont bien fonctionné pour nous pendant assez longtemps et ils continuent de le faire. Mais si vous vous trouvez dans une situation où vous avez vraiment du mal à utiliser ce type de base de données, par exemple parce que la complexité du modèle de données devient incontrôlable, alors il est logique de passer à quelque chose comme un sourcing d'événements approche.
Et de même, au niveau inférieur (évolutivité), si la taille de vos données est telle que vous pouvez simplement les placer dans PostgreSQL sur une seule machine - c'est probablement bien, utilisez simplement PostgreSQL sur une seule machine. Mais si vous êtes au point où il n'y a aucun moyen pour qu'une seule machine puisse gérer votre charge, vous devez évoluer sur un grand système, alors il devient logique d'examiner des systèmes plus distribués comme Kafka. Je pense que le principe général ici est: utilisez ce qui est le plus simple pour la tâche particulière que vous essayez de résoudre.
Vadim : C'est vraiment un bon conseil. À mesure que votre système évolue, vous ne pouvez pas prédire avec précision la direction du développement, toutes les requêtes, les modèles et les flux de données.
Martin : Exactement, et pour ce genre de situations, les bases de données relationnelles sont incroyables, car elles sont très flexibles, surtout si vous incluez le support JSON dont elles disposent maintenant. PostgreSQL a maintenant un assez bon support pour JSON. Vous pouvez simplement ajouter un nouvel index si vous souhaitez interroger d'une manière différente. Vous pouvez simplement modifier le schéma et continuer à exécuter les données dans une structure différente. Et donc si la taille de l'ensemble de données n'est pas trop grande et la complexité n'est pas trop grande, les bases de données relationnelles fonctionnent bien et offrent une grande flexibilité.
Vadim : Parlons un peu plus du sourcing d'événements. Vous avez mentionné un exemple intéressant avec plusieurs consommateurs consommant des événements d'une file d'attente basée sur Kafka ou quelque chose de similaire. Imaginez que de nouveaux documents soient publiés et que plusieurs systèmes consomment des événements: un système de recherche basé sur Elasticsearch, qui rend les documents consultables, un système de mise en cache qui les place dans un cache de valeurs-clés basé sur Memcached, et un système de base de données relationnelle qui met à jour certains tableaux en conséquence. Un document peut être une offre de vente de voiture ou une annonce immobilière. Tous ces systèmes consommateurs fonctionnent simultanément et simultanément.
Martin : Votre question est donc de savoir comment gérer le fait que si vous avez ces plusieurs consommateurs, certains d'entre eux pourraient avoir été mis à jour, mais les autres n'ont pas encore vu de mise à jour et sont toujours légèrement en retard?
Vadim : Oui, exactement. Un utilisateur accède à votre site Web, saisit une requête de recherche, obtient des résultats de recherche et clique sur un lien. Mais elle obtient le code d'état HTTP 404 car il n'y a pas une telle entité dans la base de données, qui n'a pas encore pu consommer et conserver le document.
Martin : Oui, c'est un peu un défi en fait. Idéalement, ce que vous voulez, c'est ce que nous appellerions la «cohérence causale» entre ces différents systèmes de stockage. Si un système contient des données dont vous dépendez, les autres systèmes que vous regardez contiendront également ces dépendances. Malheureusement, la mise en place de ce type de cohérence causale entre différentes technologies de stockage est en fait très difficile, et ce n'est pas vraiment la faute de la recherche d'événements, car quelle que soit l'approche ou le système que vous utilisez pour envoyer les mises à jour aux différents systèmes, vous peut toujours se retrouver avec des problèmes de concurrence.
Dans votre exemple d'écriture de données sur Memcached et Elasticsearch, même si vous essayez d'effectuer les écritures sur les deux systèmes simultanément, vous pourriez avoir un peu de retard sur le réseau, ce qui signifie qu'ils arrivent à des heures légèrement différentes sur ces différents systèmes, et être traité avec un timing légèrement différent. Et donc quelqu'un qui lit à travers ces deux systèmes peut voir un état incohérent. Maintenant, il y a des projets de recherche qui travaillent au moins à atteindre ce type de cohérence causale, mais c'est toujours difficile si vous voulez simplement utiliser quelque chose comme Elasticsearch ou Memcached ou ainsi sur étagère.
Une bonne solution ici serait que vous soyez présenté, conceptuellement, avec un instantané cohérent à la fois dans l'index de recherche et le cache et la base de données. Si vous travaillez uniquement dans une base de données relationnelle, vous obtenez quelque chose appelé isolement de l'instantané, et le point de l'isolement de l'instantané est que si vous lisez à partir de la base de données, il semble que vous ayez votre propre copie privée de l'ensemble base de données. Tout ce que vous regardez dans la base de données, toutes les données que vous interrogez seront l'état à ce moment-là, selon l'instantané. Ainsi, même si les données ont été modifiées par la suite par une autre transaction, vous verrez en fait les anciennes données, car ces anciennes données font partie d'un instantané cohérent.
Et maintenant, dans le cas où vous avez Elasticsearch et Memcached, vraiment ce que vous voudriez idéalement est un instantané cohérent sur ces deux systèmes. Mais malheureusement, ni Memcached, ni Redis, ni Elasticsearch ne disposent d'un mécanisme efficace pour réaliser ces types d'instantanés qui peuvent être coordonnés avec différents systèmes de stockage. Chaque système de stockage pense juste pour lui-même et vous présente généralement la dernière valeur de chaque clé, et il n'a pas cette possibilité pour regarder en arrière et présenter une version légèrement plus ancienne des données, car la version la plus récente des données n'est pas encore cohérente.
Je n'ai pas vraiment de bonne réponse à quoi ressemblerait la solution. Je crains que la solution ne nécessite des modifications de code sur tous les systèmes de stockage qui participent à ce genre de chose. Il faudra donc modifier Elasticsearch, Redis, Memcached et tout autre système. Et ils devraient ajouter une sorte de mécanisme pour les instantanés ponctuels qui est suffisamment bon marché pour que vous puissiez l'utiliser tout le temps, parce que vous voudrez peut-être l'instantané plusieurs fois par seconde - ce n'est pas seulement une fois une instantané du jour, c'est très fin. Et pour le moment, les systèmes sous-jacents ne sont pas là pour pouvoir faire ce genre d'instantanés sur différents systèmes de stockage. C'est un sujet de recherche vraiment intéressant. J'espère que quelqu'un y travaillera, mais je n'ai pas encore trouvé de réponses vraiment convaincantes à ce problème.
Vadim : Oui, nous avons besoin d'une sorte de
contrôle de concurrence multiversion partagé.
Martin : Exactement, comme les systèmes de transaction distribués. Les transactions distribuées XA vous y aideront, mais malheureusement, XA, en l'état, n'est pas vraiment bien adapté car il ne fonctionne que si vous utilisez un contrôle de concurrence basé sur le verrouillage. Cela signifie que si vous lisez certaines données, vous devez les verrouiller afin que personne ne puisse modifier ces données pendant que vous disposez de ce verrou. Et ce type de contrôle de concurrence basé sur le verrouillage a des performances terribles, donc aucun système n'utilise réellement cela dans la pratique de nos jours. Mais si vous ne disposez pas de ce verrouillage, vous n'obtiendrez pas le comportement d'isolation nécessaire dans un système comme les transactions distribuées XA. Alors peut-être que nous avons besoin d'un nouveau protocole pour les transactions distribuées qui permet l'isolement de l'instantané comme mécanisme d'isolement sur différents systèmes. Mais je ne pense pas avoir encore vu quoi que ce soit qui implémente cela.
Vadim : Oui, j'espère que quelqu'un y travaille.
Martin : Oui, ce serait vraiment important. Toujours dans le contexte des microservices, par exemple: la façon dont les gens font la promotion de la création de microservices est que chaque microservice a son propre stockage, sa propre base de données, et vous n'avez pas un service accédant directement à la base de données d'un autre service, car cela romprait l'encapsulation du service. Par conséquent, chaque service gère uniquement ses propres données.
Par exemple, vous disposez d'un service de gestion des utilisateurs, et il a une base de données pour les utilisateurs, et tous les autres qui veulent en savoir plus sur les utilisateurs doivent passer par le service utilisateur. Du point de vue de l'encapsulation, c'est bien: vous cachez des détails du schéma de la base de données aux autres services par exemple.
But from the point of view of consistency across different services — well, you've got a huge problem now, because of exactly the thing we were discussing: we might have data in two different services that depends upon each other in some way, and you could easily end up with one service being slightly ahead of or slightly behind the other in terms of timing, and then you could end up with someone who reads across different services, getting inconsistent results. And I don't think anybody building microservices currently has an answer to that problem.
Vadim : It is somewhat similar to workflows in our society and government, which are inherently asynchronous and there are no guarantees of delivery. You can get your passport number, then you can change it, and you need to prove that you changed it, and that you are the same person.
Martin : Yes, absolutely. As humans we have ways of dealing with this, for example, we might know that oh, sometimes that database is a bit outdated, I'll just check back tomorrow. And then tomorrow it's fine. But if it's software that we're building, we have to program all that kind of handling into the software. The software can't think for itself.
Vadim : Definitely, at least not yet. I have another question about the advantages of event sourcing. Event sourcing gives you the ability to stop processing events in case of a bug, and resume consuming events having deployed the fix, so that the system is always consistent. It's a really strong and useful property, but it might not be acceptable in some cases like banking where you can imagine a system that continues to accept financial transactions, but the balances are stale due to suspended consumers waiting for a bugfix from developers. What might be a workaround in such cases?
Martin : I think it's a bit unlikely to stop the consumer, deploying the fix and then restart it, because, as you say, the system has got to continue running, you can't just stop it. I think what is more likely to happen is: if you discover a bug, you let the system continue running, but while it continues running with the buggy code, you produce another version of the code that is fixed, you deploy that fixed version separately and run the two in parallel for a while. In the fixed version of the code you might go back in history and reprocess all of the input events that have happened since the buggy code was deployed, and maybe write the results to a different database. Once you've caught up again you've got two versions of the database, which are both based on the same event inputs, but one of the two processed events with the buggy code and the other processed the events with the correct code. At that point you can do the switchover, and now everyone who reads the data is going to read the correct version instead of the buggy version, and you can shut down the buggy version. That way you never need to stop the system from running, everything keeps working all the time. And you can take the time to fix the bug, and you can recover from the bug because you can reprocess those input events again.
Vadim : Indeed, it's a really good option if the storage systems are under your control, and we are not talking about side effects applied to external systems.
Martin : Yes, you're right, once we send the data to external systems it gets more difficult because you might not be able to easily correct it. But this is again something you find in financial accounting, for example. In a company, you might have quarterly accounts. At the end of the quarter, everything gets frozen, and all of the revenue and profit calculations are based on the numbers for that quarter. But then it can happen that actually, some delayed transaction came in, because somebody forgot to file a receipt in time. The transaction comes in after the calculations for the quarter have been finalized, but it still belongs in that earlier quarter.
What accountants do in this case is that in the next quarter, they produce corrections to the previous quarter's accounts. And typically those corrections will be a small number, and that's no problem because it doesn't change the big picture. But at the same time, everything is still accounted for correctly. At the human level of these accounting systems that has been the case ever since accounting systems were invented, centuries ago. It's always been the case that some late transactions would come in and change the result for some number that you thought was final, but actually, it wasn't because the correction could still come in. And so we just build the system with the mechanism to perform such corrections. I think we can learn from accounting systems and apply similar ideas to many other types of data storage systems, and just accept the fact that sometimes they are mostly correct but not 100% correct and the correction might come in later.
Vadim : It's a different point of view to building systems.
Martin : It is a bit of a new way of thinking, yes. It can be disorienting when you come across it at first. But I don't think there's really a way round it, because this impreciseness is inherent in the fact that we do not know the entire state of the world — it is fundamental to the way distributed systems work. We can't just hide it, we can't pretend that it doesn't happen, because that imprecision is necessarily exposed in the way we process the data.
Professional growth and development
Vadim : Do you think that conferences like
Hydra are anticipated? Most distributed systems are quite different, and it is hard to imagine that many attendees will get to work and will start applying what they have learned in day-to-day activities.
Martin : It is broad, but I think that a lot of the interesting ideas in distributed systems are conceptual. So the insights are not necessarily like «use this database» or «use this particular technology». They are more like ways of thinking about systems and about software. And those kinds of ideas can be applied quite widely. My hope is that when attendees go away from this conference, the lessons they take away are not so much what piece of software they should be using or which programming language they should be using – really, I don't mind about that – but more like how to
think about the systems they are building.
Vadim : Why do you think it's important to give conference talks on such complex topics as your talk, compared to publishing papers, covering all their details and intricacies? Or should anyone do both?
Martin : I think they serve different purposes. When we write papers, the purpose is to have a very definitive, very precise analysis of a particular problem, and to go really deep in that. On the other hand, the purpose of a talk is more to get people interested in a topic and to start a conversation around it. I love going to conferences partly because of the discussions I then have around the talk, where people come to me and say: «oh, we tried something like this, but we ran into this problem and that problem, what do you think about that?» Then I get to think about other people's problems, and that's really interesting because I get to learn a lot from that.
So, from my point of view, the selfish reason for going to conferences is really to learn from other people, what their experiences have been, and to help share the experiences that we've made in the hope that other people will find them useful as well. But fundamentally, a conference talk is often an introduction to a subject, whereas a paper is a deep analysis of a very narrow question. I think those are different genres and I think we need both of them.
Vadim : And the last question. How do you personally grow as a professional engineer and a researcher? Could you please recommend any conferences, blogs, books, communities for those who wish to develop themselves in the field of distributed systems?
Martin : That's a good question. Certainly, there are things to listen to and to read. There's no shortage of conference talks that have been recorded and put online. There are books like my own book for example, which provides a bit of an introduction to the topic, but also lots of references to further reading. So if there are any particular detailed questions that you're interested in, you can follow those references and find the original papers where these ideas were discussed. They can be a very valuable way of learning about something in greater depth.
A really important part is also trying to implement things and seeing how they work out in practice, and talking to other people and sharing your experiences. Part of the value of a conference is that you get to talk to other people as well, live. But you can have that through other mechanisms as well; for example, there's a Slack channel that people have set up for people
interested in distributed systems . If that's your thing you can join that. You can, of course, talk to your colleagues in your company and try to learn from them. I don't think there's one right way of doing this — there are many different ways through which you can learn and get a deeper experience, and different paths will work for different people.
Vadim : Thank you very much for your advice and interesting discussion! It has been a pleasure talking to you.
Martin : No problem, yeah, it's been nice talking to you.
Vadim : Let's meet
at the conference .