Llegamos a ustedes gracias a:



Reportajes y análisis

Sobrevivir a una estampida de Mastodon

[05/12/2022] Probablemente ya haya oído hablar de Mastodon, la plataforma de microblogging de código abierto que ha ido ganando popularidad desde que Elon Musk se hizo cargo de Twitter.

Una de las principales características de la plataforma es su arquitectura descentralizada y distribuida, que proporciona resiliencia, pero el inconveniente es que puede causar congestión y aumentar la latencia para los desprevenidos.

[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]

Así es como funciona Mastodon. Sus servidores (instancias) funcionan de forma semiindependiente entre sí, y los usuarios se registran en servidores orientados a las comunidades que les interesan. Pero los usuarios pueden seguir e interactuar con otros de todo el Fediverso -usuarios alojados en otras instancias de Mastodon, así como otros servicios que utilizan el protocolo ActivityPub de código abierto del Worldwide Web Consortium.

Los usuarios activos de Mastodon casi se duplicaron entre el 27 de octubre y el 6 de noviembre, según el director general de la empresa, Eugen Rochko, lo que provocó algunos problemas de crecimiento. La naturaleza distribuida de Mastodon y ActivityPub tiene puntos fuertes en cuanto a mantener el servicio impulsado por la comunidad tanto a nivel de instancia como de Fediverse, pero algunos usuarios están empezando a notar algunas verrugas aquí y allá que parecen estar relacionadas con su arquitectura.

Descentralización: Robusta, no necesariamente eficiente

Una constante de los sistemas distribuidos es que cada instancia tiene que compartir algún subconjunto de sus datos. En el caso de Mastodon, gran parte de esto gira en torno a los seguidores. Si el usuario A en una instancia de Mastodon sigue al usuario B en otra instancia, la segunda instancia necesita saber a qué instancia debe notificar cuando el usuario B publique algo. Como la primera instancia recibe una notificación sobre una nueva publicación del usuario B, el usuario A y otros usuarios de esa instancia pueden ver eficazmente esa publicación en su feed federado o incluso recibir una notificación, aunque la publicación se haya producido en otra instancia.

Esta federación significa, en última instancia, que cada nueva publicación puede desencadenar la sincronización entre múltiples instancias de Mastodon, dependiendo de quién siga al usuario. A medida que se crean nuevas instancias de Mastodon y aumenta la complejidad de las redes de usuarios, el tráfico resultante de las publicaciones de los usuarios seguirá aumentando.

Un esfuerzo similar se lleva a cabo cuando un usuario migra su cuenta de una instancia a otra. La instancia que aloja al usuario debe notificar el traslado a las instancias que lo siguen, y debe proporcionar una lista de seguidores a la instancia receptora. Este proceso también implica que las instancias de Mastodon renegocien el vínculo de autenticación entre el usuario y el seguidor. Dado que cada instancia de Mastodon está escalada de forma diferente, tanto en términos de configuración del servidor (hardware y software) como de número de usuarios, el tiempo que conlleva la migración puede llevar días o incluso semanas. Mientras los usuarios están en el limbo, su capacidad de servicio se degrada.

Estos posibles problemas de tráfico de red solo afectan a los que alojan una instancia de Mastodon, que es un pequeño subconjunto de profesionales de TI. Pero eso no significa que los administradores corporativos no tengan un interés en el juego. La leyenda de la industria Jamie Zawinski, uno de los primeros desarrolladores del navegador Netscape, señaló esta semana que su blog ha sido desconectado en repetidas ocasiones inmediatamente después de publicar en su perfil de Mastodon.

Tras algunas investigaciones, Zawinski atribuye este comportamiento a un rápido aumento del tráfico de varias instancias de Mastodon que intentan acceder a la publicación del blog simultáneamente. Otros usuarios han observado problemas similares, concretamente que cada instancia de Mastodon golpea la URL para recuperar una imagen de vista previa y el título de la página para mostrarlo como parte de la publicación.

Proteger el contenido

Los proveedores de contenido son el nicho obvio que debería estar más preocupado por estos hallazgos. Si usted administra un sitio o servicio que impulsa las acciones y la interacción en los medios sociales, existe la posibilidad de que su infraestructura se vea afectada por la arquitectura subyacente de Mastodon. Ser viral es genial, pero si su sistema no puede manejar el impacto del tráfico adicional de usuarios más los impactos generados por el sistema, entonces la atención adicional puede no ser de la variedad generadora de ingresos.

Las mejores prácticas son la respuesta definitiva para asegurarse de que su servicio se mantiene estable, y el uso de herramientas de monitorización para rastrear el rendimiento y la utilización son un primer paso importante. Sin la capacidad de identificar la fuente de tráfico que provoca picos en la utilización del ancho de banda, es difícil reaccionar adecuadamente. Del mismo modo, emplear una red de distribución de contenidos o una capacidad de almacenamiento en caché ayudará a mitigar el impacto de los picos de tráfico en la red. La planificación de la elasticidad automatizada en forma de una plataforma de aplicaciones basada en la nube o una infraestructura de aplicaciones en contenedores que pueda ampliarse o reducirse dinámicamente también puede ser necesaria para manejar plenamente la creciente escala de Mastodon.