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

164

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?

Apoorv
fuente

Respuestas:

59

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

EJ Brennan
fuente
77
FYI docs.aws.amazon.com/AWSSimpleQueueService/latest/… SQS FIFO no funciona con SNS
destruir todo
80

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.

Roee Gavirel
fuente
2
FYI: Puedes hacer que Kinesis retenga hasta por 7 días.
Didier A.
30
Recientemente, AWS ha anunciado SQS FIFO [ docs.aws.amazon.com/AWSSimpleQueueService/latest/… que puede servir para ordenar los mensajes por tiempo.
VijeshJain
44
súper pequeño comentario - probablemente no utilizaría la palabra spliten SNS split the message to multiple SQSsya que no se descompone mensajes en pedazos, pero lo copia en múltiples destinos.
Mobigital
2
Kinesis no es adecuado para casos de uso de abanico (pub-sub) debido a limitaciones en torno al número de lectores por fragmento / segundo. Aunque no es relevante para la investigación original, cualquiera que confíe en la escala de Kinesis para n-lectores debería tener en cuenta este hecho. forums.aws.amazon.com/message.jspa?messageID=760351
codeasone
2
La garantía de pedido de Kinesis es por fragmento, no por secuencia. Una vez que tenga más de un fragmento, todo el flujo no tendrá garantía en el pedido. Para una cola SQS, cuando el rendimiento es relativamente bajo, es casi FIFO. Solo cuando su rendimiento aumenta, el orden se sigue menos. Esto se refiere a las colas SQS clásicas, no a las colas FIFO.
yoroto
54

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.

kartik
fuente
11
En cuanto a su explicación sobre el SQS. Puede lograr una manera fácil de enviar el mismo mensaje a múltiples SQS al tener un SNS antes que ellos.
Roee Gavirel
8
aplicación -> tema sns ---> sqs1, sqs2, sqs3 ...?
kartik
44
Sí, me refería a este enfoque exacto.
Roee Gavirel
@RoeeGavirel, ¿qué pasa con la solicitud / segundas limitaciones para sns api?
Barbaros Alp
@BarbarosAlp: solo conozco la limitación de SMS (mensajes de texto móviles) que está fuera de tema aquí. esta es la documentación oficial: docs.aws.amazon.com/general/latest/gr/…
Roee Gavirel
43

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.

Konstantin Triger
fuente
Con la cola SQS FIFO, tendríamos los mensajes ordenados a medida que se envían. ¿Eso hace que SQS sea similar a Kinesis en este aspecto?
Andy Dufresne
1
@AndyDufresne: esto cubre bien el escenario donde el orden es importante. En el caso (1) anterior, es posible que desee manejar pedidos "en orden". Entonces, si se queda sin existencias, los pedidos posteriores se rechazan o se retrasan. La semántica FIFO no resuelve el problema de la relatividad central (agrupación).
Konstantin Triger
35

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.

técnico en la nube
fuente
34

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.

Matthew Curry
fuente
¿Cómo se confirma el mensaje? ¿Quisiste decir eliminar?
NeverEndingQueue
Si, esencialmente. Diciendo que ya terminaste con este mensaje
Matthew Curry
15

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

DenNukem
fuente
1
-1 No estoy de acuerdo. Si bien Kinesis puede desencadenar lambda, esto no presenta ninguna ventaja sobre una lambda SQS programada. Este último se escalará sin problemas (es decir, si tarda más de un minuto, se activará un segundo lambda). El precio es por tiempo de cálculo, por lo que tampoco hay una diferencia apreciable. Y si necesita más de 5 lambdas simultáneas, simplemente agregue múltiples desencadenantes programados con unos segundos de diferencia (usando cron). Esta no es una razón para usar Kinesis sobre SNS / SQS.
Steven de Salas
55
No estoy seguro de estar de acuerdo con el desacuerdo;] - puedes programar una lambda / minuto, lo que te limitaría a procesar por lotes los mensajes que llegaron ese intervalo. Kinesis le permitiría leer los mensajes de inmediato. ¿O es algo que no entendí?
Moszi
Hay una gran diferencia entre un par de disparadores de vigilancia de la nube y cientos cuando se necesita invocar el lambda de tracción contra SQS.
Coding Pig
14
¡Lambda ahora admite SQS como desencadenante!
sixty4bit
11

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.

John Velonis
fuente
No entiendo completamente por qué el aumento exponencial de tamaño, aquí, importa. ¿Puedes cavar un poco más? Parece que tienes una idea que me gustaría tener. Editar En realidad, mirando la respuesta de Euguene Feingold, parece haber un debate bastante sólido sobre esto (?).
Thomas
Lo siento, cometí algunos errores en mis cálculos (solucionado ahora, espero).
John Velonis
correcto, pero ¿qué pasa si el tamaño promedio de un mensaje SQS es pequeño, digamos 1 kb o menos?
mcmillab
1
@mcmillab SQS cobrará lo mismo si su mensaje es de 1 KB o 64 KB; consulte la página de precios de Amazon SQS . Entonces, si sus mensajes son de solo 1 KB, SQS costará 64 veces más que las cifras que di anteriormente si envía la misma cantidad total de datos. Sin embargo, una sola solicitud puede contener hasta 10 mensajes, por lo que si puede agrupar los mensajes juntos, podría ser solo 6 veces más (dependiendo de cuán llenos estén sus lotes).
John Velonis
1
@JohnVelonis A los cálculos anteriores de precios SQS les falta una pieza clave. Se necesita un cuidado especial para comprender cómo se cobran las solicitudes SQS. 1 solicitud = 1 acción de API. Para procesar un solo "mensaje", es necesario realizar al menos 3 acciones API: 1 enviar + 1 leer + 1 eliminar. Otras características de SQS, como el cambio de visibilidad, generarán más acciones de API. Este multiplicador inesperado es bastante desagradable y generalmente da como resultado que SQS sea entre 2 y 10 veces más costoso que Kinesis Streams para grandes conjuntos de datos (por ejemplo, procesando 100 millones de mensajes por mes).
Vlad Poskatcheev
9

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

Bhanu Tadepalli
fuente
5

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

Eugene Feingold
fuente
3
¿Estás seguro? Según mis cálculos, Kinesis es mucho más costoso, pero nunca he tenido talento usando la Calculadora de precios simple de Amazon.
Didier A.
Mirando los ejemplos de precios actuales en AWS: Kinesis con 267 millones de mensajes cuesta alrededor de $ 60, mientras que poner esa cantidad de mensajes a través de SQS resultaría en $ 107. Obviamente, acabo de hacer una comparación muy rápida, y esto difiere mucho con los diferentes casos de uso, pero esta respuesta definitivamente merece algo de crédito.
Moszi
1
Suponga que está haciendo un fanático para decir 2 consumidores y 100 millones de mensajes al día. El costo del SNS es de $ 50 / día. El costo de SQS es de $ 40 / día / consumidor o $ 80 / día en total. Kinesis es de $ 1.4 / día para PUT y $ 0.36 / fragmento. Incluso con 100 fragmentos (100 MB / s de entrada, 200 MB / s de salida) cuesta solo $ 3.60 / día + $ 1.40 / día. Entonces Kinesis a $ 4 / día vs. SNS / SQS a $ 130 / día.
Carlos Rendon
@Moszi ¿Cómo llegaste a este cálculo? Una cola SQS estándar con 15,000,000 mensajes por mes y 10GB de transferencia y transferencia de datos cuesta solo 5.60USD / mes, mientras que una carga útil de 256KB (SQS max) y ~ 15,000,000 unidades PUT / mes (130 fragmentos) en Kinesis cuesta 1,638.43 USD / mes
simoncpu
3
Me interesaría saber por qué hay tanta disparidad en los costos en este hilo.
Thomas
2

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
Sharhabeel Hamdan
fuente