Banco de Dados

11 abr, 2018

SQS ou Kinesis? Comparando laranjas com maçãs

Publicidade

Ao pesquisar sobre desenvolvimento de sistemas de mensageria, é comum acabar achando conteúdos relacionados ao Kinesis. O Kinesis auxilia no armazenamento das mensagens, assim como serve de mecanismo para entrega das mesmas. A primeira vista, o Kinesis tem um conjunto de funcionalidades que, aparentemente, resolve qualquer problema: ele armazena terabytes de dados, pode repetir mensagens antigas, e suporta múltiplos consumidores de mensagem. Porém, se analisarmos um pouco mais a fundo, é possível notar que o Kinesis é adequado para casos de uso bem particulares, e se este não for caso da sua aplicação, o Kinesis pode acabar sendo mais problema que solução, melhor dizendo, pode acabar sendo a solução inadequada.

Neste artigo, iremos comparar dois serviços AWS, o Kinesis e o Simple Queue Service (SQS), mostrando as vantagens e desvantagens de cada um, e destacando a diferença entre streaming de dados (data streams) e filas (queueing).

Data Streams – A aplicabilidade do Kinesis

O principal caso de uso do Kinesis resume-se em: coletar, armazenar e processar um fluxo de dados (data streams) em tempo real. Os data streams são dados gerados continuamente por milhares de fontes de dados, que geralmente enviam registros de dados simultaneamente, e em tamanhos pequenos (Kilobytes).

Quando falamos de data streams, alguns exemplos são: arquivos de log, analíticos de e-commerce, comportamento/atividades dos jogadores no game, informações de redes sociais, serviços geoespaciais, telemetria de dispositivos conectados, instrumentação em data centers.

O Kinesis é projetado para ingestão e processamento de dados em larga escala, com a capacidade de maximizar o throughput de gravação para grandes volumes de dados.

Casos de uso do Kinesis

  • Coleta de dados de log e eventos
  • Análise em tempo real
  • Captura de dados móveis
  • Feed de dados para IoT

Vantagens do Kinesis

Tempo real

Se você precisar do throughput máximo absoluto para ingestão ou processamento de dados, o Kinesis é a escolha certa. O delay entre a escrita de um registro e a leitura a partir do Stream é muitas vezes inferior a um (1) segundo, e isso independente do volume de dados que precisar escrever. Usando o Kinesis, você realmente processará o dado assim que ele for gerado.

“Big Data”

Se você precisa manipular terabytes de dados por dia em um único Stream, o Kinesis pode fazer isso por você. Ele permite o consumo de dados em tempo real de vários produtores (Producers) diferentes, a entrega deste serviço é efetuada de modo confiável e altamente escalável. O tratamento dos dados pode ser efetuado em tempo real ou armazenado para processamento futuro.

Desvantagens do Kinesis

Administração de Shards

Embora seja fácil começar a utilizar o Kinesis, ele apresenta uma dificuldade operacional quando é preciso gerenciar os Shards de dados. Quando é criado um novo Stream, é necessário especificar o número de Shards que o mesmo contém, cada Shard serve como um agrupamento de registros de dados. Uma vez que as leituras e gravações são aplicadas nos Shards, o número de Shards determina o throughput máximo que pode ser alcançado em determinado Stream. No momento atual, o Kinesis não possui suporte ao auto-scaling, logo, é responsabilidade do desenvolvedor da aplicação monitorar o uso do shard e escalar conforme o necessário.

Leitura de throughput limitada

O Kinesis possui um limite de cinco leituras por segundo por Shard, com o máximo de saída de leitura de 2MB/seg. Então, se quiséssemos enviar uma mensagem para cinco consumidores (Consumers) que teriam que ler os mesmos dados e processar do mesmo Shard, já teríamos atingido o limite do Kinesis, sendo necessário efetuar o escalonamento manual dos Shards para permitir mais Consumers.

Bibliotecas para Producers e Consumers complicadas

Tendo em vista o alto desempenho, o Kinesis exige a implantação de bibliotecas de Producers e Consumers ao lado de sua aplicação. Como Producer – utilizando a KPL (Kinesis Producer Library) – você implanta um binário C++ com uma interface Java para ler e gravar registros de dados em fluxo do Kinesis.

Como Consumer – utilizando a KCL (Kinesis Client Library) – você implanta um aplicativo Java que pode se comunicar com outras linguagens de programação através de uma interface criada em cima do padrão chamado MultiLangDaemon. Para ambos os casos, adicionar novos Producers ou Consumers a um fluxo no Kinesis requer investimento em desenvolvimento e manutenção.

Manutenção de estado

O Kinesis permite que cada Consumer leia o fluxo de forma independente. Isto exige que cada um marque sua própria posição e acompanhe o quão longe no fluxo ele está. Para escalar vários Consumers executando a mesma carga de trabalho, é necessário que cada um deles coordene o conjunto de registros que estão sendo lidos a partir do Kinesis. A KCL realiza isso armazenando os metadados dos Consumer em uma tabela DynamoDB. Estes dados auxiliam a dimensionar o número de Consumers para escalar os Shards, porém isto um esforço de desenvolvimento, além de recursos adicionais para implantar.

Queue – O essencial para mensageria

A fila de mensagens (Queue) facilita o desacoplamento e escalonamento de micro serviços, sistemas distribuídos e aplicações serverless. Usando uma queue, é possível enviar, armazenar e receber qualquer quantidade de mensagens entre diferentes componentes de software. Tudo isso, sem perder ou exigir que outros serviços estejam sempre disponíveis.

Construir aplicações com componentes individuais que executam uma função única, melhora a escalabilidade e confiabilidade do serviço, esta é a melhor prática de design para aplicações modernas. Existem muitos padrões de integração entre componentes que podem ser implementados utilizando o conceito de filas.

Se você está procurando um sistema de fila de mensagens, o SQS da Amazon se encaixa neste papel. O SQS oferece filas de mensagens confiáveis e escaláveis, sem a sobrecarga do custo operacional. Ele fornece o encanamento necessário para conectar seus serviços de forma confiável em uma arquitetura orientada a serviços ou de micro serviços.

Casos de uso do SQS

  • Integração entre aplicações
  • Desacoplamento de micro serviços
  • Desacoplar navegação do usuário de processos pesados
  • Alocar tarefas entre vários workers
  • Mensagens em lote para processamento futuro

Vantagens do SQS

Fácil de usar

O SQS é muito simples de utilizar. Crie sua fila e envie as mensagens, simples assim. Ao contrário do Kinesis, você não precisa de nenhuma biblioteca em especial para ler e escrever em uma fila. Outra vantagem é que não é necessário que haja coordenação entre o Consumers. O próprio SQS se responsabiliza por isso. Por fim, o SQS é um serviço confiável, que suporta criptografia, e é extremamente escalável.

Throughput de leitura

O SQS escala facilmente para gerenciar altos volumes de mensagens, tudo isso sem a intervenção do usuário. Ele permite o aumento dinâmico do throughput de leitura, isso é possível escalando o número de tarefa de lidas de uma fila. Isto não requer nenhum pré-provisionamento ou escala de recursos AWS. O próprio SQS faz buffer dos requests para superar os casos de picos de carga.

Desvantagens do SQS

Consumer único

Com SQS, uma vez que o Consumer processou a mensagem da fila, a mensagem é removida e nenhum outro poderá ler ela. Isso significa que o SQS não suporta múltiplos Consumers lendo o mesmo conjunto de mensagens da mesma fila. Para prover tal funcionalidade, é necessário escrever a mesma mensagem em múltiplas filas. Isso é possível utilizando o SNS ou outro serviço de broadcast, que possui como característica a replicação de mensagens.

Incapacidade de reprodução de mensagens

Visto que as mensagens são removidas após processadas, o SQS não oferece suporte para reproduzir mensagens que já foram publicadas. Se você precisar desta funcionalidade, você precisará gravar estas mensagens em uma fonte de dados alternativa e criar um mecanismo para reproduzir as mensagens salvas.

Resumo

Há uma grande quantidade de ferramentas disponíveis a partir de provedores de nuvem com os quais você pode criar sua aplicação, e metade do trabalho na concepção do software para nuvem está na pesquisa das ferramentas disponíveis e entendimento de como elas podem ser implantadas. Este artigo compara o SQS e Kinesis, tecnologias aparentemente semelhantes, porém, com casos de uso muito diferentes.

Se você está pensando em adotar Kinesis para resolver seu problema, considere se você possui ou não um fluxo de dados contínuo de tamanho muito grande. Se você possui, Kinesis é a escolha certa. Caso contrário, considere utilizar o SQS.

Nota: Este artigo é uma adaptação e tradução livre do ótimo artigo do Kevin Sookocheff.