Sobrevive a la fiebre del mastodonte

hace 1 año

000000089272.png

Mientras Elon Musk lleva a los usuarios de Twitter a Mastodon, la arquitectura subyacente de la plataforma alternativa puede sobrecargar las redes de proveedores de contenido.

A estas alturas, casi todo el mundo probablemente ha oído hablar de Mastodon. Desde que Elon Musk tomó el control de Twitter, esta plataforma de microblogging de código abierto se ha vuelto muy popular. Una de las principales características de la plataforma se refiere a su arquitectura descentralizada y distribuida, lo que le otorga cierta resiliencia. Con una desventaja: puede causar congestión y aumentar la latencia si no está preparado para ello. Mastodon funciona de la siguiente manera: Sus servidores (instancias) son parcialmente independientes entre sí, y los usuarios se registran en servidores orientados a las comunidades que les interesan. Pero los usuarios pueden seguir e interactuar con otras personas a través de Fediverse, un término que se refiere a un conjunto de redes sociales administradas de forma autónoma conectadas entre sí, en este caso con usuarios alojados en otras instancias de Mastodon y otros servicios que utilizan la red gratuita del Worldwide Web Consortium. Protocolo ActivityPub. Según el director ejecutivo de redes sociales, Eugen Rochko, entre el 27 de octubre y el 6 de noviembre, los usuarios activos de Mastodon casi se duplicaron, lo que provocó algunos dolores de crecimiento. La naturaleza distribuida de Mastodon y ActivityPub tiene la ventaja de que permite que el servicio permanezca centrado en la comunidad, tanto a nivel de instancia como de Fediverse. Pero algunos usuarios están comenzando a notar inconvenientes aquí y allá, aparentemente relacionados con su arquitectura.

Descentralización robusta pero no necesariamente eficiente

Normalmente, en los sistemas distribuidos, cada instancia debe compartir un subconjunto de sus datos. En el caso de Mastodon, muchos de esos datos son sobre seguidores. Si el Usuario A de una instancia de Mastodon sigue al Usuario B de otra instancia, la segunda instancia necesita saber a qué instancia notificar cuando el Usuario B publica un mensaje. Debido a que la primera instancia recibe una notificación de un nuevo mensaje del usuario B, el usuario A y otros usuarios de esta instancia pueden ver este mensaje en su feed federado o recibir una notificación, incluso si el mensaje se publicó en otra instancia. En última instancia, esta federación significa que cada nueva publicación puede desencadenar una sincronización entre varias instancias de Mastodon según el seguidor que sigue 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 los mensajes de los usuarios sigue aumentando.

Es exactamente lo mismo cuando un usuario migra su cuenta de una instancia a otra. La instancia que aloja al usuario debe informar a las instancias que siguen al usuario de su transferencia y debe proporcionar una lista de seguidores a la instancia que lo recibe. Este proceso también implica que las instancias de Mastodon renegocian el enlace de autenticación entre el usuario y el seguidor. Dado que cada instancia de Mastodon tiene un tamaño diferente en términos de configuración del servidor (hardware y software) y número de usuarios, la migración puede demorar varios días o incluso semanas. A medida que los usuarios hacen la transición, su capacidad de servicio se degrada. Estos posibles problemas de tráfico de red solo afectan realmente a aquellos que alojan una instancia de Mastodon, lo que sin duda afecta a un pequeño subconjunto de profesionales de TI. Pero eso no significa que los directores corporativos no tengan nada que defender. Esta semana, la leyenda de la industria Jamie Zawinski, uno de los primeros desarrolladores del navegador Netscape, notó que su blog se había desconectado varias veces inmediatamente después de publicarlo en su perfil de Mastodon. Después de algunas investigaciones, Zawinski atribuyó este comportamiento a un rápido aumento en el tráfico de múltiples instancias de Mastodon que intentaban acceder a la publicación del blog simultáneamente. Otros usuarios han visto problemas similares, incluida cada instancia de Mastodon que mira la URL para recuperar una imagen de vista previa y el título de la página para mostrar con la publicación.

Proteja su contenido

Los proveedores de contenidos son obviamente el sector que debería verse más afectado por estos resultados. Aquellos que administran un sitio o servicio que promueve el intercambio y la interacción en las redes sociales pueden encontrar su infraestructura afectada por la arquitectura subyacente de Mastodon. Volverse viral es excelente, pero si el sistema no puede manejar el impacto del tráfico adicional de usuarios y las visitas generadas por el sistema, es posible que esa atención adicional no genere ingresos. Las mejores prácticas son la respuesta definitiva para garantizar que el servicio se mantenga estable, y el uso de herramientas de monitoreo para rastrear el rendimiento y el uso es un primer paso importante en esa dirección. Si no se puede identificar la fuente de tráfico que causa los picos en el uso del ancho de banda, es difícil responder adecuadamente. De manera similar, el uso de una red de entrega de contenido o capacidad de almacenamiento en caché ayudará a mitigar el impacto de los picos de tráfico en la red. Puede ser necesario planificar la elasticidad automatizada en forma de una plataforma de aplicaciones en la nube o una infraestructura de aplicaciones en contenedores que pueda aumentar o reducir dinámicamente para manejar completamente la escala creciente de Mastodon.

Si quieres conocer otros artículos parecidos a Sobrevive a la fiebre del mastodonte puedes visitar la categoría Otros.

Otras noticias que te pueden interesar

Subir