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

sqs que es (10)

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

Añadiré una cosa más que nadie más ha mencionado: SQS es varios órdenes de magnitud más costosa.

En la superficie son vagamente similares, pero su caso de uso determinará qué herramienta es la adecuada. OMI, si puede cumplir con SQS, entonces debería - 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 da ejemplos de casos de uso apropiados para ambas herramientas para ayuda a decidir:

FAQ''s

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 con el mismo procesador de registro (como en la transmisión de MapReduce). Por ejemplo, el conteo y la agregación son más simples cuando todos los registros para una clave dada 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.
Capacidad para que múltiples aplicaciones consuman la misma secuencia al mismo tiempo. Por ejemplo, tiene una aplicación que actualiza un panel de control en tiempo real y otra que archiva datos en Amazon Redshift. Desea que ambas aplicaciones consuman datos de la misma secuencia al mismo tiempo e independientemente.
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 por hasta 7 días, puede ejecutar la aplicación de auditoría hasta 7 días detrás de la aplicación de facturación.
Recomendamos Amazon SQS para casos de uso con requisitos que son similares a los siguientes:
Semántica de mensajes (como confirmación / falla a nivel de mensajes) 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 ack / fail, por lo que la aplicación no tiene que mantener un punto de control / cursor persistente. Amazon SQS eliminará los mensajes incriminados y volverá a enviar mensajes fallidos después de un tiempo límite de visibilidad configurado.
Demora de mensaje individual. 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.
Aumento dinámico de concurrencia / rendimiento en tiempo de lectura. Por ejemplo, tiene una cola de trabajos y desea agregar más lectores hasta que se borre la acumulación. Con Amazon Kinesis Streams, puede escalar hasta una cantidad suficiente de fragmentos (tenga en cuenta, sin embargo, que deberá aprovisionar suficientes fragmentos con anticipación).
Aprovechando la capacidad de Amazon SQS para escalar de forma transparente. Por ejemplo, las solicitudes de almacenamiento intermedio 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 búfer se puede procesar de forma independiente, Amazon SQS puede escalar de forma transparente para manejar la carga sin ninguna instrucción de provisión por su parte.

Kinesis admite múltiples capacidades de los consumidores, lo que significa que los mismos registros de datos se pueden procesar al mismo tiempo o en diferentes momentos dentro de las 24 horas a 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 una cola múltiple agregará segundos de segundos (unos milisegundos) de latencia en el sistema.

En segundo lugar, Kinesis proporciona la capacidad de enrutamiento para los registros de datos de ruta selectiva a diferentes fragmentos usando la clave de partición que puede ser procesada por instancias EC2 particulares y puede habilitar el cálculo de micro lotes {Contaje 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 la cantidad de fragmentos para administrar la carga de los picos y disminuirlos 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.

Kinesis resuelve el problema de la parte del mapa en un escenario típico de reducción de mapas para la transmisión de datos. Mientras que 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, facilitando la agregación en la clave en comparación con SQS

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

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

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

Comprendamos la diferencia por ejemplo.

Supongamos que tenemos un flujo de pedidos, para cada pedido necesitamos reservar algunas existencias y programar una entrega. Una vez que esto esté completo, podemos eliminar de manera segura el elemento de la transmisión y comenzar a procesar el siguiente pedido. Estamos completamente terminados con el orden anterior antes de comenzar el siguiente.
Nuevamente, tenemos el mismo flujo de pedidos, pero ahora nuestro objetivo es agrupar pedidos por destinos. Una vez que tenemos, por ejemplo, 10 pedidos en el mismo lugar, queremos entregarlos juntos (optimización de la entrega). Ahora la historia es diferente: cuando recibimos un nuevo artículo de la transmisión, no podemos terminar de procesarlo; más bien, "esperamos" a que lleguen más artículos para cumplir nuestro objetivo. Además, si el proceso del procesador falla, debemos "restaurar" el estado (por lo que no se perderá ninguna orden).

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

Los modelos de precios son diferentes, por lo que dependiendo de su caso de uso, uno u otro pueden ser más baratos. 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).

Al conectar los precios actuales y sin tener en cuenta el nivel gratuito, si envía 1 GB de mensajes al día con el 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), así que $ 0.00655 por GB. En 1 GB por día, esto está justo por debajo 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), así que $ 0.00059 por GB. En 1 GB por día, esto es menos de $ 0.02 por mes; a 1 TB por día, es alrededor de $ 18 por mes. Sin embargo, Kinesis también cobra $ 0.015 por hora-fragmento. Necesita al menos 1 fragmento por 1 MB por segundo. Con 1 GB por día, 1 fragmento será suficiente, por lo que agregará otros $ 0.36 por día, por un costo total de $ 10.82 por mes. Con 1 TB por día, necesitará al menos 13 fragmentos, que agregan otros $ 4.68 por día, por un costo total de $ 158 por mes.

Otra cosa: Kinesis puede activar un Lambda, mientras que SQS no puede. Entonces, con SQS tiene que proporcionar una instancia de EC2 para procesar los mensajes de SQS (y manejarlos si falla), o tiene que tener un Lambda programado (que no se amplía ni se reduce, sino solo uno por minuto) .

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

Después de aprender el problema por un tiempo, teniendo la misma pregunta en mente, descubrí que SQS (con SNS) es preferible 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 dos ventajas principales para Kinesis (1), puede leer el mismo mensaje desde varias aplicaciones y (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 ventilador a SQS. Eso significa que el productor del mensaje envía solo un mensaje al SNS, luego el SNS despliega el mensaje en varios SQS, uno para cada aplicación de consumidor. De esta manera, puede obtener tanto como los consumidores que desee sin pensar en la capacidad de fragmentación.

Además, agregamos un SQS más que está suscrito al SNS que contendrá los mensajes durante 14 días. En el caso normal, nadie lee de este SQS, pero en el 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. OMI necesita un caso realmente sólido para elegir Kinesis sobre él.