Introducción
Microsoft Azure nos ofrece dos alternativas a la horas de armar sistemas basados en colas de mensajes: Azure Queue Storage y Service Bus Queues.
El servicio de Azure Queue Storage es parte de la infraestructura de Azure Storage (que también nos ofrece Blobs y Tables), y están basadas en una interfaz REST.
El servicio de Service Bus Queues, es parte de una infraestructura de mensajes más amplia, que soporta colas, como así también publicador/suscriptor, remoting de Web services y patrones de integración.
Consideraciones tecnológicas
Ambos servicios tienen sus diferencias y similitudes, y podremos usar uno u otro (o ambos) de acuerdo a las necesidades técnicas y/o de negocio del problema que estemos resolviendo.
Deberíamos considerar usar Azure Queues cuando:
- La aplicación necesite almacenar más de 80GB de mensajes en la cola, en donde los mensajes tengan una vida menor a los 7 días.
- La aplicación quiera hacer seguimiento del progreso del procesamiento de un mensaje dentro de la cola. Esto es útil cuando el servidor que está procesando el mensaje se cae, ya que otro servidor puede agarrar ese mensaje y continuar desde donde dejó el anterior.
- Se requiera logs del lado del servidor de todas las transacciones ejecutadas sobre la cola.
Deberíamos considerar usar Service Bus Queues cuando:
- Nuestra aplicación debe ser capaz de recibir mensajes sin estar consultando la cola. En Service Bus esto se puede hacer aplicando una consulta de long-polling, basada en los protocolos TCP que soporta Service Bus.
- La solución necesite que se garantice el orden FIFO (first-in-first-out).
- Necesitamos tener la misma experiencia desde Azure y desde Windows Server (en un private cloud).
- Necesitamos detectar automáticamente mensajes duplicados.
- Nuestra solución requiere un comportamiento transaccional y atomicidad cuando envía y recibe múltiples mensajes de la cola.
- Cuando el tiempo de vida (TTL: time-to-live) del workload específico de la aplicación puede superar los 7 días.
- La aplicación maneja mensajes de más de 64KB, pero que no llegan al límite de 256KB.
- Vemos que a futuro eventualmente vamos a cambiar la comunicación basada en colas punto a punto a un patrón de intercambio de mensajes que permita la integración de más receptores (suscriptores), cada uno de los cuales recibe una copia independiente de alguno o todos los mensajes de la cola. Esto último se trata de la capacidad de publicación/suscripción de Service bus.
- El tamaño de la cola no superará los 80GB.
- Se quiera usar el estándar de mensajería AMQP 1.0.
- Se quiera crear y consumir lotes de mensajes.
- Necesitamos integrar nuestra solución con WCF (Windows Communication Foundation).
Comparación entre Azure Queues y Service Bus Queues
| Criterio | Azure Queues | Service bus queues |
|---|---|---|
| Garantía de orden | No | Si (FIFO: first-in-first-out) |
| Garantía de entrega | Al menos una vez (At-least-once) | Al menos una vez (At-least-once) Como mucho una vez (At-most-once) |
| Soporte de operaciones atómicas | No | Si |
| Comportamiento de recepción | No bloqueante (termina inmediatamente si no encuentra más mensajes) |
Bloqueante con/sin timeout
No bloqueante |
| API estilo PUSH | No | Si |
| Modo de recepción | Peek & lease | Peek & lock
Receive & delete |
| Modo de acceso exclusivo | Basado en lease | Basado en lock |
| Duración del lease/lock | 30 segundos (default) 7 días (máximo) (se puede renovar o revocar un lease usando la función UpdateMessage) |
60 segundos (default) (se puede renovar el lock usando la función RenewLock) |
| Precisión del lease/lock | A nivel de mensaje (cada mensaje tiene un valor diferente de timeout, el cual puede luego actualizarse mientras se procesa el mensaje) |
A nivel de cola (cada cola tiene el lock aplicado a todos sus mensajes, y se puede renovar el lock a través de RenewLock) |
| Recepción en lotes | Si (especificando explícitamente la cantidad de mensajes al solicitarlos, con un máximo de 32) |
Si (implícitamente especificando la propiedad pre-fetch, o explícitamente usando transacciones) |
| Envío en lotes | No | Si (usando transacciones o manejando lotes del lado cliente) |
| Máximo tamaño de cola | 200 TB (limitado al tamaño máximo de una cuenta de Storage) |
1 GB a 80 GB (definido en la creación de la cola, habilitando particiones) |
| Tamaño máximo de mensaje | 64 KB (48 KB cuando se usa encoding Base64) |
256 KB o 1 MB (depende del nivel de servicio) (incluyendo el header y el contenido del mensaje, el header no puede superar los 64 KB) |
| Tiempo de vida (TTL) máximo del mensaje | 7 días | Ilimitado |
| Número máximo de colas | Ilimitado | 10.000 (por namespace del servicio, puede aumentarse) |
| Número máximo de clientes recurrentes | Ilimitado | Ilimitado (el límite de 100 conexiones concurrentes sólo aplica para las comunicaciones basadas en el protocolo TCP) |
| Máxima carga | Hasta 2.000 mensajes por segundo (basado en un benchmark con mensajes de 1 KB) |
Hasta 2.000 mensajes por segundo (basado en un benchmark con mensajes de 1 KB) |
| Latencia promedio | 10 ms (con TCP Nagle deshabilitado) |
20-25 ms |
| Comportamiento de throttling | Rechazo con código HTTP 503 (los requests rechazados no se cobran) |
Rechazo con excepción/código HTTP 503 (los requests rechazados no se cobran) |
Guillermo Bellmann 