Optimización de Amazon Simple Queue Service (SQS) para lograr velocidad y escalabilidad | Amazon Web Services

Después de varias versiones beta públicas, lanzamos Amazon Simple Queue Service (Amazon SQS) en 2006. Casi dos décadas después, este servicio totalmente administrado sigue siendo un componente fundamental para microservicios, sistemas distribuidos y aplicaciones sin servidor, procesando más de 100 millones de mensajes por segundo en horas pico.

Como siempre hay una forma mejor, seguimos buscando formas de mejorar el rendimiento, la seguridad, la eficiencia interna, etc. Cuando encontramos una forma potencial de hacer algo mejor, tenemos cuidado de preservar el comportamiento existente y, a menudo, ejecutamos sistemas nuevos y antiguos en paralelo para poder comparar los resultados.

Hoy me gustaría contarles cómo recientemente realizamos mejoras en Amazon SQS para reducir la latencia, aumentar la capacidad de la flota, mitigar un abismo de escalabilidad que se aproxima y reducir el consumo de energía.

Mejorando SQS
Al igual que muchos servicios de AWS, Amazon SQS se implementa mediante una colección de microservicios internos. Hoy nos centraremos en dos de ellos:

Interfaz de usuario del cliente – El front-end orientado al cliente acepta, autentica y autoriza llamadas API como CreateQueue y SendMessageLuego, dirige cada solicitud al back-end de almacenamiento.

Back-end de almacenamiento -Este microservicio interno es responsable de la persistencia de los mensajes enviados a colas estándar (no FIFO). Mediante un modelo basado en celdas, cada clúster de la celda contiene varios hosts, cada cola de clientes se asigna a uno o más clústeres y cada clúster es responsable de una multitud de colas:

Conexiones – antiguas y nuevas
La implementación original utilizaba una conexión por solicitud entre estos dos servicios. Cada interfaz tenía que conectarse a muchos hosts, lo que obligaba al uso de un pool de conexiones y también corría el riesgo de alcanzar un límite máximo y fijo en la cantidad de conexiones abiertas. Si bien a menudo es posible simplemente aplicar hardware a problemas como este y escalar horizontalmente, esa no siempre es la mejor manera. Simplemente traslada el momento de la verdad (el «precipicio de escalabilidad») al futuro y no hace un uso eficiente de los recursos.

Después de considerar cuidadosamente varias soluciones a largo plazo, el equipo de Amazon SQS inventó un nuevo protocolo de enmarcado binario patentado entre el front-end del cliente y el back-end de almacenamiento. El protocolo multiplexa múltiples solicitudes y respuestas a través de una única conexión, utilizando identificadores de 128 bits y sumas de comprobación para evitar la diafonía. El cifrado del lado del servidor proporciona una capa adicional de protección contra el acceso no autorizado a los datos de la cola.

¡Funciona!
El nuevo protocolo se puso en funcionamiento a principios de este año y, mientras escribo esto, ha procesado 744,9 billones de solicitudes. Se ha eliminado el problema de la escalabilidad y ya estamos buscando formas de poner en funcionamiento este nuevo protocolo de otras maneras.

En términos de rendimiento, el nuevo protocolo ha reducido la latencia del plano de datos en un 11 % de media y en un 17,4 % en la marca P90. Además de mejorar el rendimiento de SQS, este cambio también beneficia a los servicios que se basan en SQS. Por ejemplo, los mensajes enviados a través de Amazon Simple Notification Service (Amazon SNS) ahora pasan un 10 % menos de tiempo “dentro” antes de ser entregados. Por último, debido al cambio de protocolo, la flota existente de hosts SQS (una combinación de instancias impulsadas por X86 y Graviton) ahora puede manejar un 17,8 % más de solicitudes que antes.

Más por venir
Espero que hayas disfrutado de este pequeño adelanto de la implementación de Amazon SQS. Cuéntamelo en los comentarios y veré si puedo encontrar más historias para compartir.

— Jeff;