Salut les copains. Ce fut un mois sauvage. Notre petit serveur de médias sociaux s'est transformé en infrastructure de production et continue de croître.

L'exode massif de la communauté technologique de Twitter est extrêmement réel. À mon avis, ces chiffres valident l'hypothèse selon laquelle la Silicon Valley a perdu confiance dans la capacité de Musk à diriger Twitter. Je sens que nous approchons d'une renaissance des médias sociaux et des entreprises.

Aperçu de la croissance et du nombre d'hachydermes

Du point de vue de l'adoption, notre croissance est déraisonnable "saine" si vous pouvez l'appeler ainsi :

3 novembre : 720 utilisateurs
13 novembre : 6 000 utilisateurs
23 novembre : 25 000 utilisateurs

Nous sommes passés d'un nœud unique à une infrastructure mondialement distribuée et redondante en moins de 30 jours. Notre petit magasin de données Postgres de 400 Mo contient désormais 177 Go de données. Nous prévoyons plus de 30 To de stockage au cours des 6 prochains mois pour notre seule diffusion de contenu.

Le trafic est probablement le résultat le plus fascinant de la croissance de notre service. Oui! Le trafic!

Aujourd'hui, nous avons complètement maximisé notre canal public principal qui est limité à 200 Mbps. Notre FAI principal a dû changer la façon dont il gère notre compte et nous considère désormais comme un grand compte d'entreprise au lieu d'un petit compte d'entreprise. En raison de ce changement, nous avons maintenant accès à de nombreuses nouvelles fonctionnalités et services que nous sommes en train d'explorer pour héberger Hachyderm.

Nous avons traité jusqu'à 1 To de données via le pipeline lors de notre journée la plus chargée (le 21 novembre).

Penser à la Fédération

L'autre jour, notre équipe d'opérateurs et moi-même avons mis le service hors ligne pour des temps d'arrêt programmés. Nous volions un peu à l'aveugle avec notre mise à niveau, et ce n'était certainement pas mon meilleur travail. Nous avons diffusé la mise à jour en direct sur ma chaîne Twitch. La vidéo archivée peut être visionnée .

Mon merveilleux partenaire, Quintessence, m'a regardé après la mise à niveau et m'a demandé si nous avions un environnement de mise en scène en ligne. Ce qui était une question parfaitement valable qui avait une très mauvaise réponse.

Non. Nous n'avions pas d'environnement de mise en scène en ligne. Pour être honnête, je ne sais même pas à quoi ressemblerait un environnement de mise en scène autre que de bifurquer les données et de créer une petite instance d'hachyderme. Le problème est que Mastodon, similaire à wordpress et à d'autres applications, est conscient de son domaine. La création d'une instance de "mise en scène" demanderait un peu de réflexion.

Plus je réfléchissais au problème, plus il révélait que les systèmes décentralisés et les systèmes fédérés ont de nouveaux problèmes pour lesquels notre industrie n'a pas de grands modèles. Mastodon est construit avec la conviction que des personnes du monde entier s'interfaceront avec lui ainsi qu'avec le fait qu'il y aura d'autres instances en ligne avec lesquelles il pourra se fédérer.

Comment construire un environnement intermédiaire tel que nous puissions tester la fédération ou la ségrégation de domaine ? À bien y penser, il. Comment fonctionne la fédération ? Quel impact l'hachyderme a-t-il sur d'autres instances du fédiverse ? Quel impact les autres instances ont-elles sur mes systèmes ?

Création de hachyderm.wtf

Naturellement, mon esprit a commencé à s'emballer en réfléchissant aux implications en matière de sécurité et aux problèmes de goulot d'étranglement liés à la présence en ligne de grands systèmes fédérés et distribués à l'échelle mondiale. J'ai décidé de suivre la dopamine et d'acheter un nouveau domaine.

J'ai acheté hachyderm.wtfet dupliqué l'un de nos hachyderm.ionœuds. Quelques minutes plus tard, le nouveau domaine a été pointé vers une copie de l'ancien nœud. Il était maintenant temps de commencer l'ingénierie inverse des hypothèses formulées par Mastodon et d'apprendre la fédération.

Mastodon cassera si vous essayez de "changer" le domaine.

Un seul nœud Mastodon est conscient de lui-même, ce qui, en général dans les systèmes distribués, est un gros « non non ». Nous avons appris cela dans Kubernetes. Les grandes infrastructures ne doivent généralement pas connaître leur propre nom de domaine, de sorte qu'il peut facilement être répliqué et déplacé.

Cependant, Mastodon est conçu "pour Internet" et non "pour nos réseaux d'entreprise", de sorte que le nom de domaine est en fait la frontière discrète des systèmes dans le modèle. Plus j'en apprenais, plus je commençais à penser qu'Internet se sentait "bien" pour la première fois.

Quoi qu'il en soit, je n'ai pas pu créer un nœud intermédiaire avec des données de production à cause du problème de domaine, alors j'ai juste détruit la base de données et recommencé à zéro.

Les nouvelles instances Mastodon nécessitent un compte administrateur.

Afin de configurer une nouvelle instance, vous devez créer un compte administrateur, sinon il n'y aura aucun moyen d'accéder au système. Il n'y aurait pas de données à fédérer.

J'ai créé un nouveau compte administrateur [email protected]et commencé à mettre le système en ligne.

Étant donné que la plupart de nos configurations de production étaient déjà chargées sur le nouveau serveur, la plupart des fonctionnalités du nouveau Mastodon "fonctionnaient tout simplement". Des e-mails étaient envoyés et nginx répondait au trafic. Sidekiq était équilibré, etc.

Hachyderme de l'extérieur

Je voulais voir ce que c'était que d'être un étranger à l'hachyderme. Quelle part de nos données était « unique » à l'hachyderme ? Quelle part de mon expérience de mastodonte a été isolée dans notre instance ?

Ma conclusion était "pas tout, mais beaucoup". Mastodon a une relation fascinante avec les « suiveurs » et ne me permettait plus de voir qui suivait les hachydermiens. C'est un gros problème, en particulier pour un système qui apprend et crée du contenu basé sur les abonnés.

Par exemple, je ne pouvais plus voir la liste des personnes qu'elle suit de ma partenaire Quintessence depuis hachyderm.wtf.

Mots-clics

Ma prochaine observation était que les hashtags sont gérés au niveau de l'instance. Mes actualités, ma communauté et mes pages pour vous étaient toutes vides. Parce qu'il n'y avait personne d'autre sur mon instance, il n'y avait pas de "contenu communautaire".

Je me suis habitué à avoir une grande quantité de nouvelles techniques, de blogs, de publications et d'articles partagés sur l'hachyderme. Ceux-ci étaient tous partis maintenant.

Accueil Chronologie

Ma chronologie à la maison était une ville fantôme. Je ne suivais personne et il n'y avait personne d'autre sur mon serveur. En gros, c'était comme si le Fedivers n'existait même pas.

Migrer mon compte

L'une des questions qui me restaient à l'esprit était de savoir comment Mastodon gère les followers ? Qu'en est-il de la migration des comptes ?

La gestion du concept d'abonnés à partir de plusieurs systèmes est une question informatique intéressante en général. J'ai utilisé le problème "The Twitter Follower" dans le codage des entretiens comme un moyen de parler de certaines des bases des tables de hachage distribuées et des graphiques directionnels et non directionnels.

Décider de migrer

Par coïncidence, j'ai décidé de prendre quelques jours de congé de la gestion d'Hachyderm et de mon travail quotidien chez GitHub pour profiter d'un concert de Sigur Rós en Islande. Je savais que je serais "hors ligne" pendant environ 5 jours.

L'une des questions que j'avais à l'esprit était de savoir comment les abonnés sont stockés dans la base de données et quel degré de contrôle chaque instance fédérée a-t-elle par rapport à une instance étrangère ? Tout ce que je sais sur les systèmes distribués me dit que les systèmes interdépendants avec une chorégraphie lâche entre eux sont une douleur dans le cul et presque toujours une mauvaise idée. Qu'en est-il lorsque les nœuds du système ont des propriétaires différents ? Cela ressemble à une recette pour un désastre.

J'ai pris la décision d'essayer la fonctionnalité de migration de Mastodon vers hachyderm.wtf dans l'espoir d'en savoir plus sur le contrôle qu'une instance a sur une autre. Mon serveur vient-il de dire à tous les autres serveurs de mettre à jour leurs enregistrements ? Comment cela marche-t-il? J'ai pensé que nous pourrions aussi bien tester avec les données de production, et il se trouve que j'avais un compte qui traînait pour prototyper pendant mes vacances.

Déni de service à distance

J'ai donc suivi la documentation et cliqué sur le bouton pour migrer mon compte. Quel est le pire qui puisse arriver ?

J'ai passé quelques instants à enquêter sur mon nouveau compte et j'ai configuré mon ancien compte pour qu'il pointe vers le nouveau. Le concept de maintenir les deux instances en "accord" l'une avec l'autre va être un thème commun dans la fédération.

Quelques heures après le début du processus, j'ai remarqué que mes abonnés commençaient à "migrer" vers la nouvelle instance. Il est important de comprendre qu'il hachyderm.wtfs'exécutait sur un très petit serveur à 2 cœurs, essentiellement un raspberry pi où hachyderm.ios'exécute sur du matériel de service d'entreprise réparti sur plusieurs nœuds dans un rack avec plus de 132 cœurs au total.

J'ai pu voir hachyderm.iole lancement d'un move_workerprocessus qui est défini dans Ruby ici et qui réécrira les abonnés sur l'instance locale.

J'ai presque immédiatement remarqué un problème sur hachyderm.wtf. Le service ne répondait pas. Après quelques minutes, j'ai pu afficher un tableau de bord fonctionnel et j'ai observé que mon calendrier se limitait lui-même.

Je l'ai redimensionné hachyderm.wtfet lui ai donné plus de calcul et le service a de nouveau été réactif.

Regarder les abonnés suivre

Au fur et à mesure que les choses se sont calmées, j'ai remarqué que je n'avais retenu qu'environ 10% de mes abonnés. Quelque chose n'allait pas ?

J'ai parcouru les journaux hachyderm.wtfet j'ai rapidement découvert que quelque chose se passait clairement par "lots" et que les lots étaient regroupés par serveur.

En d'autres termes, j'ai pu voir hachyderm.wtfplusieurs milliers de requêtes provenant de mastodon.socialet d' mastodon.sdf.orgautres instances en un seul instant. De toute évidence, les serveurs distants devaient effectuer une sorte de négociation avec hachyderm.wtfafin de migrer les abonnés.

Ce fut une découverte intéressante et explique comment j'ai pu me DDoS moi-même lors de la migration.

Le vecteur spécifique qui peut provoquer l'arrêt d'un serveur est un utilisateur dont la chronologie est ouverte dans un navigateur avec la nouvelle fonctionnalité websocket 4.0.2 chargée. Pendant la migration, les suiveurs se remplissent en temps réel, ce qui amène une autre partie du tableau de bord à interroger le /accountspoint de terminaison plus rapidement qu'il ne peut suivre. J'ai contacté l'équipe de sécurité de Mastodon au sujet de l'ouverture potentielle d'un CVE pour cela.

Mais ce qui se passait causait tant de frais généraux entre hachyderm.wtfet les serveurs distants qui essayaient de migrer les abonnés.

Relation suiveur de mastodonte

Ainsi, une fonctionnalité très excitante de la fédération au sein de Mastodon est la façon dont elle gère et authentifie la relation suiveur/suivi.

J'ai trouvé le code FollowRequest qui montre le point de départ du travail qui se hachyderm.wtfdéconnectait. Mastodon utilise des clés de cryptographie publiques pour authentifier diverses requêtes et fonctionnalités du système. Mastodon est basé sur ActivityPub qui utilise des signatures HTTP pour s'authentifier entre les deux instances. C'est ainsi qu'une instance est sûre qu'une autre instance est en fait la personne qu'elle prétend être.

Lorsque vous migrez des comptes, toutes les données clés doivent être reconstruites, car la confiance entre les systèmes est rompue. La fonctionnalité qui était DDoSing hachyderm.wtfétait que mes milliers d'abonnés devaient négocier et se ré-authentifier respectivement avec chacun de leurs serveurs hôtes.

Il y a du bon et du mauvais dans ce modèle. En ce qui concerne la fédération, c'était la bonne décision architecturale à prendre en matière d'authentification. J'ai hâte de voir s'il existe d'autres moyens de migrer les données de manière transparente à l'avenir !

Autres conséquences imprévues

Dans l'ensemble, l'expérience a été un succès et a révélé beaucoup de choses sur le pouvoir que j'ai en tant qu'administrateur Mastodon, ainsi que sur le pouvoir que les autres administrateurs ont sur mes systèmes. Voir la confiance mutuelle entre les systèmes se produire avec les signatures HTTP est très cool !

La migration par intermittence hachyderm.ioa hachyderm.wtfété un succès. Je sais que nous continuerons à tirer parti hachyderm.wtfde notre instance de laboratoire afin de pouvoir travailler sur RustyPub , notre implémentation Rust d'ActivityPub que nous avons l'intention de développer pour comprendre le fonctionnement des relais.

Confiance communautaire

J'ai été réprimandé assez durement par mon partenaire Quintessence pour avoir quitté hachyderm.io de manière inattendue. Je pense qu'elle a soulevé un bon point que d'autres considéreraient le changement comme quelque chose d'inconnu et spéculeraient sur le pire. Il s'est avéré qu'elle – comme toujours – avait raison.

Même si j'espère que le fedivers est moins construit autour de la réputation et de l'image, je crois que tout le monde ne comprend pas les systèmes comme moi et considérerait quelque chose comme un changement de domaine comme un risque et non comme une expérience.

Facteur limitant : le temps

Je pense qu'une autre conséquence inattendue est que mes followers sont maintenant à la disposition de n'importe quel propriétaire d'instance de mastodonte qui avait initialement suivi mon compte dans le sens où leurs travaux pour renégocier les signatures HTTP peuvent être très retardés.

Je ne pense pas que quiconque perdra des abonnés lors d'une migration à moins que le serveur distant qui vous a suivi n'ait depuis été définitivement détruit.

Cependant, je pense que cela peut prendre des jours, des semaines, voire plus pour que d'autres instances renégocient sur le back-end. Un suivi ponctuel est rapide et facile car la plupart des négociations peuvent être effectuées dans le navigateur, mais les travailler par lots sur le back-end met beaucoup de foi sur le fait que d'autres instances ont configuré correctement sidekiq et qu'il n'y a pas de latence dans leurs files d'attente .

Retour à la maison sur Hachyderm.io

Il y a quelques minutes, j'ai lancé une migration hachyderm.wtfvers mon instance d'origine hachyderm.io. Je soupçonne qu'il faudra quelques jours avant que la majeure partie de mes partisans ait renégocié à nouveau.

Revenir en arrière hachyderm.iom'a fait comprendre pourquoi les choses ont été si calmes pour moi récemment.

J'ai remarqué que toutes mes notifications qui avaient fait exploser mon téléphone étaient soudainement devenues silencieuses.

Comprendre vos données

Ainsi, les données qui font de vous "vous" sur Mastodon vivent principalement sur votre instance. La plupart.

Dans le cas des instances en mouvement, j'ai remarqué que toutes mes notifications s'arrêtaient soudainement. J'ai passé un certain temps à comprendre que la migration signifie que mon compte est gelé après une migration, ce qui signifie que les notifications envoyées à l'ancien compte après la migration sont en quelque sorte perdues à jamais.

Alors que je commence à publier davantage sur le nouveau compte, je soupçonne que mon flux de notifications se poursuivra à mesure que de nouvelles notifications seront créées pour mon nouveau contenu. Cependant, les anciennes réponses, likes, etc. ont maintenant disparu.

Dès qu'on efface hachyderm.wtfje suis très curieux de comprendre ce qu'il advient des messages sur les autres serveurs ? Est-il possible que ces publications persistent même après la disparition définitive de leur serveur d'origine ?

Merci d'avoir lu

Je sais que c'était beaucoup ! Il s'agit principalement d'un flux de conscience et de mes notes de terrain alors que je me prépare pour mon concert de ce soir.

Suivez-moi sur Mastodon [email protected] pour en savoir plus !