Estratégias para lidar com o aumento inesperado de demanda e evitar throttling com Kinesis Data Streams On-Demand

Por Hermes Pimentel, Arquiteto de Soluções na AWS

O Amazon Kinesis Data Streams é um serviço de streaming de dados que torna fácil a captura, o processamento e o armazenamento de dados em qualquer escala, com provisionamento e dimensionamento granular.

O Kinesis Data Streams On-Demand é um novo modo do Kinesis Data Streams, que escala automaticamente para suportar até o dobro do pico de demanda observada nos últimos 30 dias. Isso ocorre sem a necessidade de planejamento existente no modo de capacidade provisionada, em que é preciso determinar o número de shards de um Stream para escalar sua capacidade de servir as operações de leitura e escrita.

O modo On-Demand é indicado para clientes que têm uma carga de trabalho desconhecida, variável ou que simplesmente não querem lidar com gerenciamento de capacidade.

Nesse blog post, vamos entender o funcionamento do Kinesis Data Streams On-Demand e algumas estratégias para evitar o throttling nas operações de escrita, que acontece sempre que atingimos os limites de atendimento de um shard. Atualmente, um único shard suporta 1MB/s de escrita ou 1.000 eventos por segundo:

Para mais informações sobre os limites do serviço, consulte a seção  Quotas e Limits na documentação.

Comportamento do Kinesis On Demand:

Quando um novo Stream é criado usando o Kinesis Data Streams On-Demand, ele possui a capacidade padrão de 4 MB/s e 4.000 registros por segundo para gravações. O Kinesis Data Streams On-Demand pode escalar automaticamente até 200 MB/s e 200.000 registros por segundo para operações de escrita.

O Kinesis Data Streams On-Demand acomoda até o dobro da taxa de transferência de gravação de pico anterior observada nos últimos 30 dias. A medida que esta taxa atinge um novo pico, o Kinesis Data Streams dimensiona automaticamente a capacidade do Stream.

Por exemplo, se o Stream tiver uma taxa de transferência de gravação que varia entre 10 MB/s e 40 MB/s, o Kinesis Data Streams garantirá que você atinja facilmente o dobro do pico (80 MB/s). E, se mais tarde, esse mesmo fluxo de dados atingir um novo pico de 50 MB/s, o Kinesis Data Streams garantirá capacidade suficiente para ingerir 100 MB/s. No entanto, o throttling de gravação pode ocorrer se o tráfego crescer mais do que o dobro do pico anterior em menos de 15 minutos.

O Kinesis Data Streams usa a partition key para distribuir dados entre os shards. É por isso que, ao usar o Kinesis Data Streams On-Demand, você ainda deve especificar uma partition key (PK) para cada registro de gravação dos eventos em um Stream, da mesma forma que ocorre no Kinesis Data Streams usando o modo de capacidade provisionado.

No Kinesis Data Streams On-Demand, o Stream se adapta automaticamente para lidar com padrões de distribuição de dados irregulares (partition keys desiguais). Mas você deve ter cuidado para que nenhuma partition key exceda os limites de um shard, ou seja, exceder a taxa de transferência de 1 MB/s de um shard e os limites de 1.000 registros por segundo. Se isso acontecer, você receberá throttling durante as operações de gravação.

O Kinesis Data Streams, com o modo On-Demand ativo, monitora o tráfego de cada shard e o divide em 15 minutos quando o tráfego de gravação excede 500 KB/s. Os valores das hash keys do shard pai são redistribuídos uniformemente entre os shards filhos.

Monitoramento:

Para entendermos o nível de utilização da capacidade dos shards, podemos ativar o enhanced monitoring no Stream para investigar se há algum shard que está passando dos limites e levando algum throttling aos produtores e/ou consumidores. Mais detalhes podem ser verificados nesse artigo de suporte.

Estratégias para lidar com Throttling:

Para contornar situações onde estamos recebendo algum tipo de throttling, algumas estratégias podem ser adotadas:

• Trabalhar com políticas de retry e rate limite para garantir a entrega dos eventos utilizando a Kinesis Producer Library (KPL);
• Aplicar uma lógica de exponential backoff nos produtores;
• Usar partition keys randômicas para uma distribuição equilibrada dos eventos nos shards.

Esse blog post oferece uma excelente explicação sobre como os shards do Kinesis funcionam e a importância da partition key para distribuição dos dados e também para evitar “hot shards”.

Em resumo, para gravar registros em um Stream usamos APIs. Para gravar um único registro, usamos a PutRecord; e para gravar vários registros, usamos a chamada PutRecords. Ao executar qualquer um deles, a solicitação à API do Kinesis deve incluir os três componentes a seguir:

• Nome do Stream;
• Dado que será gravado no Stream;
• Partition key.

O diagrama a seguir mostra vários produtores gravando em um stream de dados do Kinesis. O valor da partition key (PK) é usado em combinação com uma função de hash para estabelecer o shard no qual um determinado registro será gravado.

A partition key é uma string Unicode com um tamanho máximo de 256 bytes. O Kinesis executa o valor da PK que você informou na solicitação por meio de uma função de hash MD5. O valor resultante mapeia seu registro para um shard específico no Stream, e o Kinesis grava o registro nesse shard.

Caso o consumo dos dados não precise de alguma afinidade, a melhor estratégia é usar uma partition key randômica para atingir o maior throughput possível. Chaves de partição randômicas ajudam a distribuir o workload de entrada de forma equilibrada entre todos os shards disponíveis em um Stream do Kinesis. Isto reduz a probabilidade de um ou mais shards serem sobrecarregados e terem um número maior de eventos de escrita.

Você pode usar um identificador único universal (UUID) como uma partition key para obter essa distribuição uniforme de registros entre os shards de um Stream. Entretanto, essa estratégia pode aumentar a latência do processamento de registros se o consumidor precisar agregar dados de vários shards.

Além disso, podemos trabalhar com automação no modo de capacidade provisionada para escalar o número de shards durante os momentos de load. Essa é uma opção caso não se tenha a possibilidade de utilizar Partition Keys que favoreçam a distribuição dos dados.

Algumas opções:

• Utilizar Lambda para realizar o ajuste dos shards em um Stream – Auto scaling Amazon Kinesis Data Streams using Amazon CloudWatch and AWS Lambda;
• Usar uma solução de automação como a Kinesis Scaling Utils.

Observação: Atualmente, é possível alterar um Stream entre o modo de capacidade provisionada ou On-Demand em tempo real, sem impacto aos consumidores e produtores, duas vezes (2x) por dia. Entretanto, é importante lembrar que quando alterado do modo On-Demand para o modo de capacidade provisionada, o Stream mantém o número de shards existente no modo On-Demand naquele momento. É de nossa responsabilidade ajustar o número de shards para o valor adequado.

Conclusão

Neste texto, vimos como o Kinesis Data Streams On-Demand funciona e pode escalar os shards de um Stream automaticamente para atender novas aplicações com comportamento ainda desconhecido e workloads não esperados em eventos ou campanhas. Entendemos as situações em que podemos receber throttling nas operações de escrita, utilizando tanto o modo de capacidade provisionada quanto o modo On-Demand. Além das boas práticas que podemos seguir para preparar nossas aplicações, a fim de evitar a paralisação das operações de escrita em decorrência do limite de cada shard.

Sobre o autor

Hermes Pimentel é arquiteto de soluções na AWS e especialista em arquiteturas orientadas a eventos. Com mais de sete anos de experiência na área de arquitetura e desenvolvimento de soluções que envolvem sistemas distribuídos, auxilia os clientes a utilizarem os serviços da AWS para projetar aplicativos escaláveis, seguros e resilientes.