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?
Respostas:
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:
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:
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.
split, SNS split the message to multiple SQSspois ela não divide as mensagens em pedaços, mas a copia para vários destinos.
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:
Vamos entender a diferença pelo exemplo.
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
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):
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
Casos de Uso SQS