Una mirada a la comunidad: Una Thompson hace que el fediverso sea más manejable con Jortage

En el fediverso, un lugar maravilloso donde comunidades pequeñas e interconectadas pueden automoderarse y elegir con quiénes se relacionan, los usuarios son dueños de sus propios datos y pueden realizar migraciones entre instancias. Sin embargo, la libertad de las redes sociales descentralizadas también tiene sus inconvenientes. 

Debido a la federación, los objetos multimedia y muchos otros contenidos acaban yendo de un servidor para otro. Siempre que alguien publica algo, su instancia envía el estado y los objetos a las instancias de todos sus seguidores, que acto seguido proceden a descargarlo. A continuación, cada instancia lo carga por su cuenta en su proveedor de almacenamiento, así que se acaba multiplicando por el número de seguidores.

El problema se las trae, pero Una ha conseguido resolverlo con gran pericia gracias a Jortage, un proyecto colectivo que, por un lado, almacena y aloja objetos y, por otro, desduplica el almacenamiento de objetos para sus integrantes, lo que se traduce en una reducción de los costes de almacenamiento generales para todo el mundo. Para que los contenidos se envíen a buen ritmo en un proyecto con más de 70 instancias en todo el mundo, Jortage acelera los procesos y almacena en caché las descargas mediante Fastly. Gracias a Fastly, Jortage no necesita invertir en sus propios servidores, lo cual contribuye al ahorro, y permite disfrutar de los gatitos de #CatsOfMastodon mejor y más rápido. :)

Hannah: ¿En qué te inspiraste para crear Jortage? 

Una: Fue una de esas cosas que se te ocurren de manera espontánea. El caso es que me dio por pensar en la federación de contenidos multimedia y tuve una idea que jamás pensé que fuera a cuajar, pero creé un prototipo y al final funcionó muy bien. Decidí escalarlo, me gané el apoyo de otros administradores de instancias y el resto ya es historia.

Un día, Gargron [Eugen Rochko, CEO de Mastodon] me envió un mensaje directo para preguntarme cuál era el secreto de Jortage, ya que tanto FFmpeg como ImageMagick, los programas que utiliza Mastodon para procesar los contenidos multimedia entrantes, son no deterministas. Y, sinceramente, no lo sé. No entiendo de dónde salen estos resultados tan buenos. :P

Hannah: Entonces… ¿cómo funciona? 

Una: Básicamente, a todos los archivos que se cargan en la reserva de almacenamiento se les añade un hash. A continuación, una base de datos de MariaDB guarda una asociación de hashes con rutas y los nuevos archivos se cargan a Wasabi, nuestro proveedor de almacenamiento de backend, con los hashes en los nombres. Al enviar una petición a pool.jortage.com, se busca la ruta en la base de datos y, si hay una coincidencia, se devuelve ​un redireccionamiento a blob.jortage.com​ con el hash correspondiente. La reserva indica la ruta hacia un servidor que ejecuto con poolmgr y blob hace lo mismo con Wasabi.

La conexión de la CDN para la reserva de almacenamiento no tuvo mucho misterio. Lo más complicado de hacer en mi configuración de Fastly fue el redireccionamiento desde la ruta raíz, que tuvo su miga, pero ese es un problema muy concreto de la reserva de almacenamiento. También tuve que habilitar Segmented Caching para que Jortage funcionara con vídeos, ya que Mastodon solo admite archivos de 40 MB como máximo.   

El software que está detrás de Jortage es una versión personalizada de poolmgr. Para este proyecto hemos tenido que utilizar todos los recursos a nuestro alcance. Sin S3Proxy y Apache JClouds, sacarlo adelante habría sido muchísimo más difícil. poolmgr da acceso a una API compatible con S3 con la que se comunica Mastodon, al igual que ocurre con Pleroma, Akkoma, Misskey y demás. Sin embargo, como la inmensa mayoría del almacenamiento en una instancia de Mastodon va a su proveedor de S3, unas 70 instancias siguen aprovechando las ventajas de Fastly. Según unas pruebas que hice por encima mientras se propagaba el DNS, las descargas son entre dos y cinco veces más rápidas con Fastly que con nuestro anterior proveedor, incluidas las peticiones no almacenadas en caché.

Una CDN no sirve para lo más voluminoso que pasa por Mastodon. De hecho, el gestor de tareas (Sidekiq) y las peticiones de federación empeoran con una CDN: no hay más que ver los misteriosos problemas con la federación que suelen producirse en las instancias ejecutadas mediante Cloudflare. Y los contenidos multimedia son archivos tirando a grandes.

Según unas pruebas que hice por encima mientras se propagaba el DNS, las descargas son entre dos y cinco veces más rápidas con Fastly que con nuestro anterior proveedor, incluidas las peticiones no almacenadas en caché.

Hannah: Hablando de las complejidades de la federación, ¿crees que hay alguna forma de hacer que las peticiones de federación y Sidekiq sean más eficientes?

Una: Creo que ahora mismo no existe ningún servicio web que se pueda definir como «eficiente» sin ponerle unas cuantas notas al pie. Se mire por donde se mire, los servicios RESTful que envían archivos JSON de ida y vuelta no son eficientes. No soy ni mucho menos una experta en ActivityPub, pero no diría que es un protocolo eficiente en líneas generales. 

Cada vez que haces una publicación, tu instancia se la envía a las instancias de todos tus seguidores. Esto, a su vez, provoca que esas instancias envíen una petición a la tuya para acceder al contexto del hilo, lo cual puede traducirse en más peticiones de publicaciones. Como también comprueban la información actual de tu perfil, cargan los enlaces del mismo en busca de enlaces rel=me que permitan realizar la verificación. Y, por supuesto, si hay documentos adjuntos, todos se descargan. El resultado de todo esto es un mayor número de tareas en la cola de Sidekiq, que en la configuración predeterminada de Mastodon tiene muy pocos hilos y se ejecuta en un único proceso. Ni siquiera está bien documentada la posibilidad de ejecutar varios procesos en Sidekiq: muchas personas saben de su existencia por este artículo en el blog de Nora Tindall. 

A todo esto, hay que añadir más gastos generales porque Sidekiq utiliza una cantidad absurda de memoria, así que me he fijado en la solución que propone TruffleRuby para englobarlo todo en un único proceso y mejorar la recolección de elementos no utilizados.

Si esa vorágine de peticiones de ida y vuelta dejara paso al envío de datos durante la federación inicial, podría ser de gran ayuda. Jortage tiene otro proyecto relacionado con el problema de la resolución de enlaces que se llama jort.link.

Saco este tema porque se ejecuta en el intérprete de Ruby, y uno de los proyectos que me gustaría emprender cuando se me presente la oportunidad es intentar que Mastodon funcione con GraalVM mediante TruffleRuby. Creo que sería un gran punto a favor para Sidekiq, ya que añadiría la compilación JIT y tareas multihilo de las de verdad. Con un bloqueo global del intérprete, el procesamiento paralelo no va muy fino en las versiones convencionales de Ruby y Python, aunque es una de las principales ventajas de PyPy. 

La centralización inherente a Jortage no favorece la sostenibilidad, pero ejecutar servicios cien por cien independientes y escalables cuesta una fortuna.

Hannah: ¿Qué consejo le darías a los desarrolladores que quieran configurar una instancia? 

Una: Que se lo piensen muy bien. Para ejecutar una instancia hace falta crear una comunidad, y ese es un proceso muy largo, incluso diría que interminable. Además, llevar bien la moderación no es nada fácil. Yo utilizo una instancia cerrada, pero no hay que irse muy lejos para conocer los casos de personas que han intentado ejecutar una pública sin estar preparadas para lo que conlleva.

Si quieres obtener más información acerca de Jortage o ponerte en contacto con Una, visita esta página y dile hola en Fedi.