El equipo de la plataforma de desarrolladores tiene la misión de potenciar a los desarrolladores externos y brindarles la capacidad de crear nuevos productos sobre Webflow.
Para los miembros de ese equipo, incluyéndome a mí, el objetivo es construir sistemas robustos y fiables en los que los desarrolladores puedan confiar para servir datos con éxito hacia y desde aplicaciones externas que pueden estar en uso en cientos de miles de sitios web.
Un método clave de comunicación entre plataformas y aplicaciones de terceros incluye el uso de webhooks para mantener la sincronización de datos casi en tiempo real entre sistemas. Para los grandes sistemas de gestión de contenidos, los eventos de webhook pueden contener grandes cantidades de datos sin límites que pueden ser difíciles de propagar debido a su tamaño.
A continuación, lee más sobre cómo nuestro equipo superó las limitaciones de carga útil del cliente SQS extendiendo su interfaz para procesar y entregar eventos de gran tamaño para nuestras necesidades de dominio de webhooks.
La limitación de carga útil del cliente SQS
El servicio de colas de mensajes (SQS) de AWS impulsa muchos dominios y servicios que existen dentro del backend de Webflow. Para interactuar con SQS, utilizamos el cliente SDK de Amazon, que tiene una limitación de tamaño máximo de carga útil de 256 kilobytes por mensaje. Dadas estas restricciones, nuestro equipo se vio bloqueado rápidamente para entregar eventos de datos de webhook grandes cuyo contenido estaba empaquetado y encolado en un mensaje SQS destinado a ser procesado posteriormente por un trabajador de cola de webhooks.
Algunos de nuestros equipos de ingeniería habían eludido previamente la limitación del cliente SQS con soluciones personalizadas que incluían el almacenamiento de punteros a recursos en el contenido del mensaje para ser consultados desde un almacén de datos en un momento posterior. Sin embargo, dado que los webhooks son una instantánea de un evento que podría existir solo durante un período de tiempo determinado, era importante para nuestro equipo encontrar una mejor manera de almacenar los detalles del evento para garantizar que la integridad de los datos del webhook permaneciera intacta.
Consideraciones sobre el almacenamiento de datos
Al evaluar almacenes de datos para guardar contenidos de mensajes grandes, analizamos tres opciones que ya estaban en uso en nuestro entorno: S3, Redis y MongoDB. El tamaño de almacenamiento era el principal problema que buscábamos resolver, y S3 fue un claro ganador en comparación con las otras opciones cuando se trataba de tener una gran capacidad de almacenamiento para datos cardinales.
Otros factores decisivos para nuestro equipo incluyeron la durabilidad de los datos, la escalabilidad y las preocupaciones sobre los costos, todas áreas en las que S3 destacó. Estábamos menos preocupados por los almacenes de datos con alto rendimiento o baja latencia, que era el punto fuerte de otra de nuestras opciones, Redis. Además, utilizar un servicio gestionado por Amazon como S3 significaba que no teníamos que preocuparnos por gestionar manualmente los detalles de la infraestructura del almacén de datos para mantener la consistencia, la disponibilidad y la partición de datos.
Enfoque de la solución e implementación
Nuestro enfoque para almacenar grandes cargas útiles de mensajes en S3 no es una idea novedosa, ya que Amazon ofrece clientes extendidos de código abierto tanto en Python como en Java para lograr la misma funcionalidad. Sin embargo, Amazon no tenía una oferta de biblioteca que coincidiera con el lenguaje de nuestra pila tecnológica, por lo que optamos por escribir una solución interna.
Para empezar, extendimos nuestra interfaz de cliente SQS por lotes para almacenar la carga útil de un mensaje en S3 si, y solo si, excedía el tamaño de 256 KiB. También actualizamos los encabezados de los mensajes grandes con un par clave-valor de palabra clave reservada cuyo valor era un puntero a la ubicación de los datos del mensaje en S3. Esto hizo que, cuando se lee cualquier mensaje de la cola, el cliente primero verifique si esta clave existe en el encabezado para determinar si la carga útil del mensaje debe extraerse de S3. Además, toda esta implementación se abstrajo para que ningún productor o consumidor de mensajes SQS en todos nuestros productos tuviera que preocuparse por los detalles del almacenamiento de datos.
Para descargar la eliminación de entradas de S3 para mensajes de carga útil SQS grandes, configuramos una política de ciclo de vida de S3 para gestionar automáticamente las eliminaciones de mensajes cuya vida útil excediera el período de retención de mensajes de SQS. Al hacerlo, simplificamos la implementación del cliente al reducir una llamada de red de ida y vuelta a S3 al leer y procesar un mensaje con éxito. Esto resultó en un mejor rendimiento y eliminó el manejo de reintentos de S3 al desencolar un mensaje en comparación con si el cliente tuviera que realizar eliminaciones en S3.
Algunas métricas de éxito iniciales que recopilamos después de realizar un despliegue gradual del cliente extendido incluyeron la entrega exitosa de más de 13,500 webhooks de carga útil grande con una tasa de entrega exitosa del 100%. Lo que es aún más notable es que entregamos una solución a todas nuestras colas y trabajos de aplicación que evita que se invierta ancho de banda de ingeniería en el futuro para superar las limitaciones de carga útil del cliente SQS.
Nuestro compromiso continuo con la optimización de nuestra infraestructura técnica
Después de lanzar una solución inicial para admitir tamaños de carga útil de mensajes grandes dentro de nuestro sistema de colas, quedan optimizaciones futuras que se han planificado para mejorar la implementación. Por ejemplo, la compresión y descompresión de datos de las cargas útiles de mensajes SQS no se realiza de forma ubicua en el proceso de colas. Ciertos algoritmos de compresión de datos pueden tener una relación de compresión de hasta 5:1, lo que puede mejorar el rendimiento de la latencia de red, reducir los costos de almacenamiento en S3 para los documentos almacenados y disminuir la cantidad de mensajes almacenados en S3, ya que los tamaños de carga útil de datos sin procesar pueden ser superiores a 256 kilobytes.
Mejoras como esta son parte del esfuerzo dedicado que Webflow emprende para proporcionar una infraestructura confiable sobre la cual los desarrolladores externos puedan construir, y estamos emocionados de seguir descubriendo oportunidades adicionales que nos permitan ofrecer los mejores productos y soluciones posibles.
Si te interesa unirte a nuestro equipo de producto e ingeniería en pleno crecimiento, visita nuestra página de empleo para saber más sobre Webflow y descubrir nuestras vacantes.
