¿Por qué debería usar Amazon Kinesis y no SNS-SQS?

Tengo un caso de uso en el que habrá flujo de datos y no puedo consumirlo al mismo ritmo y necesito un búfer. Esto se puede resolver utilizando una cola SNS-SQS. Llegué a saber que Kinesis resuelve el mismo propósito, entonces, ¿cuál es la diferencia? ¿Por qué debería preferir (o no preferir) Kinesis?

En la superficie son vagamente similares, pero su caso de uso determinará qué herramienta es la adecuada. En mi opinión, si puede seguir adelante con SQS, entonces debería hacerlo: si hace lo que quiere, será más simple y más barato, pero aquí hay una mejor explicación de las preguntas frecuentes de AWS que ofrece ejemplos de casos de uso apropiados para ambas herramientas. ayudarlo a decidir:

Preguntas frecuentes

Tenga en cuenta que esta respuesta fue correcta para junio de 2015

Después de estudiar el problema por un tiempo, teniendo en cuenta la misma pregunta, descubrí que SQS (con SNS) es el preferido para la mayoría de los casos de uso, a menos que el orden de los mensajes sea importante para usted (SQS no garantiza FIFO en los mensajes).

Hay 2 ventajas principales para Kinesis:

1. puedes leer el mismo mensaje desde varias aplicaciones
2. puede volver a leer los mensajes en caso de que lo necesite.

Ambas ventajas se pueden lograr mediante el uso de SNS como un abanico de SQS. Eso significa que el productor del mensaje envía solo un mensaje a SNS, luego el SNS despliega el mensaje en múltiples SQS, uno para cada aplicación de consumidor. De esta manera, puede tener tantos consumidores como desee sin pensar en la capacidad de fragmentación.

Además, agregamos un SQS más que está suscrito al SNS que retendrá mensajes durante 14 días. En el caso normal, nadie lee de este SQS, pero en caso de un error que nos hace querer rebobinar los datos, podemos leer fácilmente todos los mensajes de este SQS y volver a enviarlos al SNS. Mientras que Kinesis solo proporciona una retención de 7 días.

En conclusión, SNS + SQSs es mucho más fácil y proporciona la mayoría de las capacidades. En mi opinión, necesitas un caso realmente fuerte para elegir Kinesis sobre él.

Kinesis admite capacidades de múltiples consumidores, lo que significa que se pueden procesar los mismos registros de datos al mismo tiempo o en un plazo diferente dentro de las 24 horas en diferentes consumidores, se puede lograr un comportamiento similar en SQS escribiendo en múltiples colas y los consumidores pueden leer desde múltiples colas. Sin embargo, volver a escribir en varias colas agregará una latencia de sub segundos {pocos milisegundos} en el sistema.

En segundo lugar, Kinesis proporciona la capacidad de enrutamiento para seleccionar registros de datos de ruta a diferentes fragmentos utilizando la clave de partición que puede ser procesada por instancias particulares de EC2 y puede permitir el cálculo de micro lotes {Conteo y agregación}.

Trabajar en cualquier software de AWS es fácil, pero con SQS es más fácil. Con Kinesis, existe la necesidad de aprovisionar suficientes fragmentos con anticipación, aumentando dinámicamente el número de fragmentos para administrar la carga de picos y disminuir para ahorrar costos que también se requieren para administrar. es dolor en Kinesis, no se requieren tales cosas con SQS. SQS es infinitamente escalable.

La semántica de estas tecnologías es diferente porque fueron diseñadas para admitir diferentes escenarios:

• SNS / SQS: los elementos en la secuencia no son relacionados entre sí
• Kinesis: los elementos en la secuencia están relacionados entre sí

Comprendamos la diferencia con el ejemplo.

1. Supongamos que tenemos una secuencia de pedidos, para cada pedido necesitamos reservar algunas existencias y programar una entrega. Una vez que esto se haya completado, podemos eliminar de forma segura el artículo de la secuencia y comenzar a procesar el siguiente pedido. Estamos completamente hecho con el pedido anterior antes de comenzar el siguiente.
2. Nuevamente, tenemos el mismo flujo de pedidos, pero ahora nuestro objetivo es agrupar los pedidos por destinos. Una vez que tengamos, digamos, 10 pedidos en el mismo lugar, queremos entregarlos juntos (optimización de entrega). Ahora la historia es diferente: cuando obtenemos un nuevo elemento de la transmisión, no podemos terminar de procesarlo; más bien "esperamos" que lleguen más artículos para cumplir con nuestro objetivo. Además, si el proceso del procesador falla, debemos "restaurar" el estado (para que no se pierda ningún orden).

Una vez que el procesamiento de un elemento no puede separarse del procesamiento de otro, debemos tener la semántica de Kinesis para manejar todos los casos de forma segura.

Extracto de la documentación de AWS :

Recomendamos Amazon Kinesis Streams para casos de uso con requisitos similares a los siguientes:

• Enrutamiento de registros relacionados al mismo procesador de registros (como en la transmisión de MapReduce). Por ejemplo, el recuento y la agregación son más simples cuando todos los registros de una clave determinada se enrutan al mismo procesador de registros.

• Ordenamiento de registros. Por ejemplo, desea transferir datos de registro desde el host de la aplicación al host de procesamiento / archivo mientras mantiene el orden de las declaraciones de registro.

• Posibilidad de que varias aplicaciones consuman la misma secuencia al mismo tiempo. Por ejemplo, tiene una aplicación que actualiza un tablero en tiempo real y otra que archiva datos en Amazon Redshift. Desea que ambas aplicaciones consuman datos del mismo flujo de forma simultánea e independiente.

• Posibilidad de consumir registros en el mismo orden unas horas más tarde. Por ejemplo, tiene una aplicación de facturación y una aplicación de auditoría que se ejecuta unas horas detrás de la aplicación de facturación. Debido a que Amazon Kinesis Streams almacena datos durante un máximo de 7 días, puede ejecutar la aplicación de auditoría hasta 7 días después de la aplicación de facturación.

Recomendamos Amazon SQS para casos de uso con requisitos similares a los siguientes:

• Semántica de mensajería (como reconocimiento / falla de nivel de mensaje) y tiempo de espera de visibilidad. Por ejemplo, tiene una cola de elementos de trabajo y desea realizar un seguimiento de la finalización exitosa de cada elemento de forma independiente. Amazon SQS rastrea el reconocimiento / falla, por lo que la aplicación no tiene que mantener un punto de control / cursor persistente. Amazon SQS eliminará los mensajes atacados y volverá a entregar los mensajes fallidos después de un tiempo de espera de visibilidad configurado.

• Mensaje individual de retraso. Por ejemplo, tiene una cola de trabajos y necesita programar trabajos individuales con un retraso. Con Amazon SQS, puede configurar mensajes individuales para que tengan un retraso de hasta 15 minutos.

• Incrementar dinámicamente la concurrencia / rendimiento en el tiempo de lectura. Por ejemplo, tiene una cola de trabajo y desea agregar más lectores hasta que se borre la acumulación. Con Amazon Kinesis Streams, puede escalar hasta un número suficiente de fragmentos (tenga en cuenta, sin embargo, que deberá aprovisionar suficientes fragmentos antes de tiempo).

• Aprovechando la capacidad de Amazon SQS para escalar de forma transparente. Por ejemplo, amortigua las solicitudes y los cambios de carga como resultado de picos de carga ocasionales o el crecimiento natural de su negocio. Debido a que cada solicitud almacenada en el búfer se puede procesar de forma independiente, Amazon SQS puede escalar de manera transparente para manejar la carga sin ninguna instrucción de aprovisionamiento suya.

La mayor ventaja para mí es el hecho de que Kinesis es una cola rejugable, y SQS no lo es. Por lo tanto, puede tener múltiples consumidores de los mismos mensajes de Kinesis (o el mismo consumidor en diferentes momentos) donde con SQS, una vez que se ha recibido un mensaje, se ha ido de esa cola. SQS es mejor para las colas de los trabajadores debido a eso.

Otra cosa: Kinesis puede desencadenar un Lambda, mientras que SQS no. Entonces, con SQS, debe proporcionar una instancia de EC2 para procesar los mensajes de SQS (y tratarla si falla), o debe tener un Lambda programado (que no aumenta o disminuye, solo obtiene uno por minuto) .

Editar: esta respuesta ya no es correcta. SQS puede activar directamente Lambda a partir de junio de 2018

https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html

Los modelos de precios son diferentes, por lo que dependiendo de su caso de uso, uno u otro puede ser más barato. Usando el caso más simple (sin incluir SNS):

• Cargos de SQS por mensaje (cada 64 KB cuenta como una solicitud).
• Kinesis cobra por fragmento por hora (1 fragmento puede manejar hasta 1000 mensajes o 1 MB / segundo) y también por la cantidad de datos que ingresa (cada 25 KB).

Conectando los precios actuales y sin tener en cuenta el nivel gratuito, si envía 1 GB de mensajes por día al tamaño máximo de mensaje, Kinesis costará mucho más que SQS ($ 10.82 / mes para Kinesis frente a $ 0.20 / mes para SQS) . Pero si envía 1 TB por día, Kinesis es algo más barato ($ 158 / mes frente a $ 201 / mes para SQS).

Detalles: SQS cobra $ 0.40 por millón de solicitudes (64 KB cada una), por lo que $ 0.00655 por GB. A 1 GB por día, esto es un poco menos de $ 0.20 por mes; a 1 TB por día, se trata de un poco más de $ 201 por mes.

Kinesis cobra $ 0.014 por millón de solicitudes (25 KB cada una), por lo que $ 0.00059 por GB. A 1 GB por día, esto es menos de $ 0.02 por mes; a 1 TB por día, es de aproximadamente $ 18 por mes. Sin embargo, Kinesis también cobra $ 0.015 por hora de fragmentación. Necesita al menos 1 fragmento por 1 MB por segundo. Con 1 GB por día, 1 fragmento será suficiente, por lo que se agregarán otros $ 0.36 por día, con un costo total de $ 10.82 por mes. Con 1 TB por día, necesitará al menos 13 fragmentos, lo que agrega otros $ 4.68 por día, por un costo total de $ 158 por mes.

Kinesis resuelve el problema de la parte del mapa en un escenario típico de reducción de mapa para la transmisión de datos. Si bien SQS no se asegura de eso. Si tiene datos de transmisión que deben agregarse en una clave, kinesis se asegura de que todos los datos de esa clave vayan a un fragmento específico y el fragmento se pueda consumir en un solo host, lo que facilita la agregación en clave en comparación con SQS

Agregaré una cosa más que nadie más ha mencionado: SQS es varias órdenes de magnitud más caro.

Casos de uso de Kinesis

• Registro y recopilación de datos de eventos
• Analítica en tiempo real
• Captura de datos móviles
• Fuente de datos de "Internet de las cosas"

Casos de uso de SQS

• Integración de aplicaciones
• Desacoplamiento de microservicios
• Asignar tareas a múltiples nodos de trabajo
• Desacople las solicitudes de usuarios en vivo del trabajo intensivo en segundo plano
• Mensajes por lotes para procesamiento futuro