Por que devo usar o Amazon Kinesis e não o SNS-SQS?

Eu tenho um caso de uso em que haverá fluxo de dados e não posso consumi-lo no mesmo ritmo e preciso de um buffer. Isso pode ser resolvido usando uma fila SNS-SQS. Eu vim a saber que o Kinesis resolve o mesmo propósito, então qual é a diferença? Por que devo preferir (ou não) o Kinesis?

Na superfície, eles são vagamente semelhantes, mas seu caso de uso determinará qual ferramenta é apropriada. Na IMO, se você pode se dar bem com o SQS, faça o que quiser - se ele fizer o que deseja, será mais simples e barato, mas aqui está uma explicação melhor das Perguntas frequentes da AWS, que fornece exemplos de casos de uso apropriados para ambas as ferramentas. ajudá-lo a decidir:

Perguntas frequentes

Lembre-se de que esta resposta estava correta em junho de 2015

Depois de estudar o problema por um tempo, tendo a mesma pergunta em mente, descobri que o SQS (com SNS) é preferido para a maioria dos casos de uso, a menos que a ordem das mensagens seja importante para você (o SQS não garante FIFO nas mensagens).

Existem 2 vantagens principais para o Kinesis:

1. você pode ler a mesma mensagem de vários aplicativos
2. você pode reler as mensagens caso precise.

Ambas as vantagens podem ser alcançadas usando o SNS como um ventilador para o SQS. Isso significa que o produtor da mensagem envia apenas uma mensagem para o SNS. Em seguida, o SNS distribui a mensagem para vários SQSs, um para cada aplicativo de consumidor. Dessa forma, você pode ter quantos consumidores quiser, sem pensar na capacidade de sharding.

Além disso, adicionamos mais um SQS inscrito no SNS que manterá as mensagens por 14 dias. Em casos normais, ninguém lê este SQS, mas no caso de um bug que nos faça retroceder os dados, podemos ler facilmente todas as mensagens desse SQS e enviá-las novamente ao SNS. Enquanto o Kinesis fornece apenas 7 dias de retenção.

Em conclusão, SNS + SQSs é muito mais fácil e fornece a maioria dos recursos. Na IMO, você precisa de um argumento realmente forte para escolher o Kinesis.

O Kinesis oferece suporte a vários recursos de consumidores, o que significa que os mesmos registros de dados podem ser processados ​​ao mesmo tempo ou em horas diferentes dentro de 24 horas em consumidores diferentes, um comportamento semelhante no SQS pode ser alcançado gravando em várias filas e os consumidores podem ler em várias filas. No entanto, a gravação novamente em várias filas adicionará latência de segundos (alguns milissegundos) no sistema.

Segundo, o Kinesis fornece capacidade de roteamento para registros seletivos de dados de rota para diferentes fragmentos usando a chave de partição que pode ser processada por instâncias específicas do EC2 e pode permitir o cálculo de micro lotes (Contagem e agregação).

Trabalhar em qualquer software da AWS é fácil, mas com o SQS é mais fácil. Com o Kinesis, é necessário provisionar shards suficientes antes do tempo, aumentando dinamicamente o número de shards para gerenciar a carga de pico e diminuir para economizar custos também necessários para gerenciar. é uma dor no Kinesis. Não é necessário o SQS. SQS é infinitamente escalável.

A semântica dessas tecnologias é diferente porque elas foram projetadas para suportar diferentes cenários:

• SNS / SQS: os itens no fluxo não estão relacionados entre si
• Kinesis: os itens no fluxo estão relacionados entre si

Vamos entender a diferença pelo exemplo.

1. Suponha que tenhamos um fluxo de pedidos; para cada pedido, precisamos reservar algum estoque e agendar uma entrega. Quando isso estiver concluído, podemos remover o item com segurança do fluxo e começar a processar o próximo pedido. Estamos totalmente feito com a ordem anterior, antes de começar a próxima.
2. Novamente, temos o mesmo fluxo de pedidos, mas agora nosso objetivo é agrupar pedidos por destinos. Assim que tivermos, digamos, 10 pedidos no mesmo local, queremos entregá-los juntos (otimização da entrega). Agora a história é diferente: quando obtemos um novo item do fluxo, não podemos terminar de processá-lo; em vez disso, "aguardamos" a chegada de mais itens para atingir nossa meta. Além disso, se o processo do processador travar, devemos "restaurar" o estado (para que nenhum pedido seja perdido).

Uma vez que o processamento de um item não pode ser separado do processamento de outro, é necessário ter a semântica do Kinesis para lidar com todos os casos com segurança.

Trecho da documentação da AWS :

Recomendamos o Amazon Kinesis Streams para casos de uso com requisitos semelhantes aos seguintes:

• Encaminhamento de registros relacionados para o mesmo processador de registros (como no MapReduce de streaming). Por exemplo, contagem e agregação são mais simples quando todos os registros de uma determinada chave são roteados para o mesmo processador de registros.

• Ordenação de registros. Por exemplo, você deseja transferir dados de log do host do aplicativo para o host de processamento / arquivamento, mantendo a ordem das instruções de log.

• Capacidade para vários aplicativos consumirem o mesmo fluxo simultaneamente. Por exemplo, você tem um aplicativo que atualiza um painel em tempo real e outro que arquiva dados no Amazon Redshift. Você deseja que os dois aplicativos consumam dados do mesmo fluxo simultaneamente e independentemente.

• Capacidade de consumir registros na mesma ordem algumas horas depois. Por exemplo, você tem um aplicativo de cobrança e um aplicativo de auditoria que são executados algumas horas atrás do aplicativo de cobrança. Como o Amazon Kinesis Streams armazena dados por até 7 dias, você pode executar o aplicativo de auditoria até 7 dias atrás do aplicativo de cobrança.

Recomendamos o Amazon SQS para casos de uso com requisitos semelhantes aos seguintes:

• Semântica de mensagens (como confirmação / falha no nível da mensagem) e tempo limite de visibilidade. Por exemplo, você tem uma fila de itens de trabalho e deseja acompanhar a conclusão bem-sucedida de cada item independentemente. O Amazon SQS rastreia a confirmação / falha, para que o aplicativo não precise manter um ponto de verificação / cursor persistente. O Amazon SQS excluirá as mensagens confirmadas e reenviará as mensagens com falha após um tempo limite de visibilidade configurado.

• Atraso de mensagem individual. Por exemplo, você tem uma fila de trabalhos e precisa agendar trabalhos individuais com um atraso. Com o Amazon SQS, você pode configurar mensagens individuais com um atraso de até 15 minutos.

• Aumentar dinamicamente a simultaneidade / taxa de transferência no tempo de leitura. Por exemplo, você tem uma fila de trabalho e deseja adicionar mais leitores até que a lista de pendências seja limpa. Com o Amazon Kinesis Streams, você pode escalar até um número suficiente de shards (observe, no entanto, que você precisará provisionar shards suficientes antes do tempo).

• Aproveitando a capacidade do Amazon SQS de escalar de forma transparente. Por exemplo, você armazena em buffer as solicitações e a carga muda como resultado de picos de carga ocasionais ou do crescimento natural de seus negócios. Como cada solicitação em buffer pode ser processada de forma independente, o Amazon SQS pode ser dimensionado de forma transparente para lidar com a carga sem nenhuma instrução de fornecimento fornecida por você.

A maior vantagem para mim é o fato de o Kinesis ser uma fila reproduzível e o SQS não. Assim, você pode ter vários consumidores das mesmas mensagens do Kinesis (ou o mesmo consumidor em momentos diferentes) onde, com o SQS, depois que uma mensagem é aceita, ela sai dessa fila. O SQS é melhor para filas de trabalhadores por causa disso.

Outra coisa: o Kinesis pode acionar um Lambda, enquanto o SQS não. Portanto, com o SQS, você precisa fornecer uma instância do EC2 para processar as mensagens do SQS (e lidar com elas se falhar) ou precisa ter um Lambda agendado (que não aumenta ou diminui - você recebe apenas uma por minuto) .

Editar: esta resposta não está mais correta. O SQS pode acionar diretamente o Lambda a partir de junho de 2018

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

Os modelos de preços são diferentes, portanto, dependendo do seu caso de uso, um ou outro pode ser mais barato. Usando o caso mais simples (não incluindo o SNS):

• Cobranças de SQS por mensagem (cada 64 KB conta como uma solicitação).
• O Kinesis cobra por shard por hora (um shard pode lidar com até 1000 mensagens ou 1 MB / segundo) e também pela quantidade de dados inseridos (a cada 25 KB).

Conectando os preços atuais e sem levar em consideração o nível gratuito, se você enviar 1 GB de mensagens por dia no tamanho máximo, o Kinesis custará muito mais do que SQS (US $ 10,82 / mês para Kinesis vs. US $ 0,20 / mês para SQS) . Mas se você enviar 1 TB por dia, o Kinesis é um pouco mais barato (US $ 158 / mês vs. US $ 201 / mês para SQS).

Detalhes: o SQS cobra US $ 0,40 por milhão de solicitações (64 KB cada), portanto, US $ 0,00655 por GB. Com 1 GB por dia, isso é um pouco menos de US $ 0,20 por mês; com 1 TB por dia, chega a pouco mais de US $ 201 por mês.

A Kinesis cobra US $ 0,014 por milhão de solicitações (25 KB cada), portanto, US $ 0,00059 por GB. Com 1 GB por dia, isso é menos de US $ 0,02 por mês; com 1 TB por dia, custa cerca de US $ 18 por mês. No entanto, a Kinesis também cobra US $ 0,015 por hora de fragmento. Você precisa de pelo menos 1 shard por 1 MB por segundo. Com 1 GB por dia, um fragmento será suficiente, o que adicionará outros US $ 0,36 por dia, a um custo total de US $ 10,82 por mês. Com 1 TB por dia, você precisará de pelo menos 13 fragmentos, o que adiciona outros US $ 4,68 por dia, a um custo total de US $ 158 por mês.

O Kinesis resolve o problema da parte do mapa em um cenário típico de redução de mapa para transmissão de dados. Enquanto o SQS não garante isso. Se você possui dados de streaming que precisam ser agregados em uma chave, o kinesis garante que todos os dados dessa chave sejam direcionados a um shard específico e que o shard possa ser consumido em um único host, facilitando a agregação da chave em comparação com o SQS

Vou acrescentar mais uma coisa que ninguém mais mencionou - o SQS é várias ordens de magnitude mais caras.

Casos de uso de Kinesis

• Coleta de dados de log e evento
• Análise em tempo real
• Captura de dados móveis
• Feed de dados “Internet das Coisas”

Casos de Uso SQS

• Integração de aplicativos
• Desacoplando microsserviços
• Alocar tarefas para vários nós do trabalhador
• Separar solicitações de usuários ao vivo de trabalhos intensivos em segundo plano
• Mensagens em lote para processamento futuro