L'architecture de Mastodon est loin d'être efficace
Alors qu'Elon Musk fait fuir les utilisateurs de Twitter vers Mastodon, l'architecture sous-jacente de la plateforme alternative peut surcharger les réseaux de fournisseurs de contenu.
Désormais, tout le monde ou presque a probablement entendu parler de Mastodon. Depuis qu'Elon Musk a pris le contrôle de Twitter, cette plateforme de microblogging open-source est devenue très populaire. L'une des principales caractéristiques de la plateforme concerne son architecture décentralisée et distribuée, qui lui confère une certaine résilience. Avec un inconvénient : elle peut provoquer des encombrements et augmenter la latence si l'on n'y est pas préparé. Mastodon fonctionne de la façon suivante : Ses serveurs (instances) sont partiellement indépendants les uns des autres, et les utilisateurs s'inscrivent sur des serveurs orientés vers les communautés qui les intéressent. Mais les utilisateurs peuvent suivre et interagir avec d'autres personnes à travers le Fediverse, terme qui désigne un ensemble de médias sociaux administrés de façon autonome et connectés entre eux, en l'occurrence avec des utilisateurs hébergés sur d'autres instances de Mastodon et d'autres services utilisant le protocole libre ActivityPub du Worldwide Web Consortium. Selon le CEO du média social, Eugen Rochko, entre le 27 octobre et le 6 novembre, les utilisateurs actifs de Mastodon ont presque doublé, provoquant ainsi quelques difficultés de croissance. La nature distribuée de Mastodon et d'ActivityPub présente des avantages en ce sens qu'elle permet au service de rester axé sur la communauté, tant au niveau de l'instance que du Fediverse. Mais certains utilisateurs commencent à remarquer ici et là des inconvénients liés, semble-t-il, à leur architecture.
Une décentralisation robuste, mais pas nécessairement efficace
Généralement, dans les systèmes distribués, chaque instance doit partager un sous-ensemble de ses données. Dans le cas de Mastodon, une grande partie de ces données concerne les followers. Si l'utilisateur A d'une instance de Mastodon suit l'utilisateur B d'une autre instance, la seconde instance doit savoir quelle instance notifier quand l'utilisateur B publie un message. Comme la première instance est notifiée d'un nouveau message de l'utilisateur B, l'utilisateur A et les autres utilisateurs de cette instance peuvent voir ce message dans leur flux fédéré ou recevoir une notification, même si le message a été publié sur une autre instance. En fin de compte, cette fédération signifie que chaque nouveau message peut déclencher une synchronisation entre plusieurs instances Mastodon en fonction du follower qui suit l'utilisateur. À mesure que de nouvelles instances Mastodon sont créées et que la complexité des réseaux d'utilisateurs augmente, le trafic résultant des messages des utilisateurs continue à augmenter.
C'est exactement la même chose quand un utilisateur migre son compte d'une instance à une autre. L'instance qui héberge l'utilisateur doit informer les instances qui suivent l'utilisateur de son transfert et doit fournir une liste de followers à l'instance qui le reçoit. Ce processus implique également que les instances Mastodon renégocient le lien d'authentification entre l'utilisateur et le follower. Chaque instance Mastodon étant dimensionnée différemment en termes de configuration de serveur (matériel et logiciel) et de nombre d'utilisateurs, la migration peut prendre plusieurs jours, voire plusieurs semaines. Pendant que les utilisateurs sont en transition, leur capacité de service est dégradée. Ces problèmes potentiels de trafic réseau n'affectent réellement que ceux qui hébergent une instance de Mastodon, ce qui est le cas, il est vrai, d'un petit sous-ensemble de professionnels de l'IT. Mais cela ne signifie pas que les administrateurs d'entreprise n'ont rien à défendre. Cette semaine, la légende de l'industrie Jamie Zawinski, l'un des premiers développeurs du navigateur Netscape, a remarqué que son blog avait été mis hors ligne à plusieurs reprises immédiatement après avoir publié sur son profil Mastodon. Après quelques recherches, M. Zawinski a attribué ce comportement à une augmentation rapide du trafic provenant de plusieurs instances de Mastodon qui essayent toutes d'accéder simultanément au message du blog. D'autres utilisateurs ont constaté des problèmes similaires, notamment le fait que chaque instance de Mastodon consulte l'URL afin de récupérer une image de prévisualisation et le titre de la page à afficher avec le message.
Protéger son contenu
Les fournisseurs de contenu sont évidemment le secteur qui devrait être le plus concerné par ces résultats. Ceux qui gèrent un site ou un service favorisant les partages et l'interaction avec les médias sociaux, verront peut-être leur infrastructure affectée par l'architecture sous-jacente de Mastodon. Devenir viral, c'est bien, mais si le système ne peut pas gérer l'impact du trafic supplémentaire des utilisateurs et des hits générés par le système, cette attention supplémentaire risque de ne pas être génératrice de revenus. Les meilleures pratiques sont la réponse ultime pour s'assurer que le service reste stable, et l'usage d'outils de surveillance pour suivre les performances et l'utilisation est un premier pas important en ce sens. Si l'on ne peut pas identifier la source du trafic à l'origine des pics d'utilisation de la bande passante, il est difficile de réagir de manière appropriée. De même, l'utilisation d'un réseau de distribution de contenu ou d'une capacité de mise en cache contribuera à atténuer l'impact des pics de trafic sur le réseau. La planification d'une élasticité automatisée sous forme de plateforme d'applications cloud ou d'infrastructure d'applications conteneurisées capable d'augmenter ou de diminuer dynamiquement peut s'avérer nécessaire pour gérer pleinement l'échelle croissante de Mastodon.
