Azure Queues vs Service Bus Queues

Azure Queues y Service Bus Queues, diferencias y similitudes

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
(usando las APIs manejadas .NET solamente)

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)

@gjbellmann

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s