As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Tabelas de metadados do DynamoDB e balanceamento de carga na KCL
A KCL gerencia metadados, como concessões e métricas de utilização da CPU dos operadores. A KCL rastreia esses metadados usando as tabelas do DynamoDB. Para cada aplicação do Amazon Kinesis Data Streams, a KCL cria três tabelas do DynamoDB para gerenciar os metadados: tabela de concessão, tabela de métricas do operador e tabela de estado do coordenador.
nota
A KCL 3.x introduziu duas novas tabelas de metadados: métricas do operador e tabelas de estado do coordenador.
Importante
Adicione as permissões adequadas às aplicações da KCL para criar e gerenciar tabelas de metadados no DynamoDB. Para obter detalhes, consulte Permissões do IAM necessárias para aplicativos de consumo da KCL.
O aplicação de consumo da KCL não remove automaticamente essas três tabelas de metadados do DynamoDB. Remova as tabelas de metadados do DynamoDB criadas pela aplicação de consumo da KCL ao descomissionar sua aplicação de consumo para evitar custos desnecessários.
Tabela de concessões
A tabela de concessões é uma tabela exclusiva do Amazon DynamoDB usada para monitorar os fragmentos cedidos e processados pelos agendadores da aplicação de consumo da KCL. Cada aplicação de consumo da KCL cria sua própria tabela de concessões. A KCL usa o nome da aplicação de consumo como nome da tabela de concessões por padrão. Você pode definir um nome de tabela personalizado usando a configuração. A KCL também cria um índice secundário global na tabela de concessões com a chave de partição do leaseOwner para uma descoberta eficiente da concessão. O índice secundário global reflete o atributo leaseKey da tabela básica de concessões. Se a tabela de concessões da aplicação de consumo da KCL não existir quando a aplicação for inicializada, um dos operadores a criará.
É possível visualizar a tabela usando o console do Amazon DynamoDB enquanto a aplicação de consumo está em execução.
Importante
-
Cada nome de aplicação de consumo da KCL deve ser exclusivo para evitar a duplicação do nome da tabela de concessões.
-
Sua conta é cobrada pelos custos associados à tabela do DynamoDB, além dos custos associados ao próprio Kinesis Data Streams.
Cada linha na tabela de concessões representa um fragmento que está sendo processado pelos agendadores da aplicação de consumo. Os campos principais incluem o seguinte:
-
leaseKey: para processamento de fluxo único, essa é a ID do fragmento. Para o processamento de vários fluxos com a KCL, ele é estruturado como
account-id:StreamName:streamCreationTimestamp:ShardId. A leaseKey é a chave de partição da tabela de concessões. Para obter mais informações sobre o processamento de vários fluxos, consulte Processamento de vários fluxos com a KCL . -
checkpoint: número de sequência do ponto de verificação mais recente do fragmento.
-
checkpointSubSequenceNúmero: ao usar o recurso de agregação da Kinesis Producer Library, essa é uma extensão do ponto de verificação que rastreia registros individuais de usuários dentro do registro do Kinesis.
-
leaseCounter: usado para verificar se um operador está processando atualmente a concessão de modo ativo. O leaseCounter aumenta se a propriedade da concessão for transferida para outro operador.
-
leaseOwner: é o operador atual que detém essa concessão.
-
ownerSwitchesSincePonto de controle: Quantas vezes esse contrato mudou de trabalhadores desde o último posto de controle.
-
parentShardId: ID do pai desse fragmento. Assegura que o fragmento principal seja totalmente processado antes do início do processamento dos fragmentos secundários, mantendo a ordem correta de processamento do registro.
-
childShardId: Lista de fragmentos secundários IDs resultantes da divisão ou mesclagem desse fragmento. Usado para rastrear a linhagem de fragmentos e gerenciar a ordem de processamento durante as operações de refragmentação.
-
startingHashKey: o limite inferior do intervalo de chaves de hash desse fragmento.
-
endingHashKey: o limite superior do intervalo de chaves de hash desse fragmento.
Se adotar o processamento de vários fluxos com a KCL, você visualizará os dois campos adicionais a seguir na tabela de concessões. Para obter mais informações, consulte Processamento de vários fluxos com a KCL .
-
shardID: o ID do fragmento.
-
streamName: é o identificador do fluxo de dados no formato:
account-id:StreamName:streamCreationTimestamp.
Tabela de métricas do operador
A tabela de métricas do operador é uma tabela exclusiva do Amazon DynamoDB para cada aplicação da KCL e é usada para registrar as métricas de utilização da CPU de cada operador. Essas métricas serão usadas pela KCL para atribuir concessões de modo eficiente, resultando no uso equilibrado dos recursos entre os operadores. A KCL usa KCLApplicationName-WorkerMetricStats como nome da tabela de métricas do operador por padrão.
Tabela de estados do coordenador
A tabela de estados do coordenador é uma tabela exclusiva do Amazon DynamoDB para cada aplicação da KCL e é usada para armazenar informações de estado internas dos operadores. Por exemplo, a tabela de estados do coordenador armazena dados sobre a eleição do líder ou os metadados associados à migração local da KCL 2.x para a KCL 3.x. A KCL usa KCLApplicationName-CoordinatorState como nome da tabela de estados do coordenador por padrão.
Modo de capacidade do DynamoDB para tabelas de metadados criadas pela KCL
Por padrão, a Kinesis Client Library (KCL) cria tabelas de metadados do DynamoDB, como tabela de concessões, tabela de métricas de operadores e tabela de estados do coordenador usando o modo de capacidade sob demanda. Esse modo dimensiona automaticamente a capacidade de leitura e gravação para acomodar o tráfego sem exigir planejamento de capacidade. É altamente recomendável que você mantenha o modo de capacidade como modo sob demanda para uma operação mais eficiente dessas tabelas de metadados.
Se você decidir mudar a tabela de concessão para o modo de capacidade provisionada, siga estas práticas recomendadas:
-
Analise os padrões de uso:
-
Monitore os padrões e usos de leitura e gravação do seu aplicativo (RCU, WCU) usando métricas da Amazon. CloudWatch
-
Entenda os requisitos de pico e médios de throughput.
-
-
Calcule a capacidade necessária:
-
Estime as unidades de capacidade de leitura (RCUs) e as unidades de capacidade de gravação (WCUs) com base em sua análise.
-
Considere fatores como o número de fragmentos, a frequência dos pontos de verificação e o número de operadores.
-
-
Implemente o ajuste de escala automático:
-
use o ajuste de escala automático do DynamoDB para ajustar automaticamente a capacidade provisionada e definir os limites de capacidade mínima e máxima apropriados.
-
O ajuste de escala automático do DynamoDB ajudará a evitar que a tabela de metadados da KCL atinja o limite de capacidade e a utilização passe a ser controlada.
-
-
Monitoramento e otimização regulares:
-
Monitore continuamente CloudWatch as métricas de
ThrottledRequests. -
Ajuste a capacidade à medida que sua workload for alterada ao longo do tempo.
-
Se você tiver ProvisionedThroughputExceededException nas tabelas de metadados do DynamoDB para sua aplicação de consumo da KCL, você precisará aumentar a capacidade de throughput provisionada da tabela do DynamoDB. Se você definir um determinado nível de unidades de capacidade de leitura (RCU) e de unidades de capacidade de gravação (WCU) na primeira vez que criar sua aplicação de consumo, esse nível pode não ser suficiente à medida que seu uso aumentar. Por exemplo, se uma aplicação de consumo da KCL realiza pontos de verificação com frequência ou opera em um fluxo com vários fragmentos, talvez sejam necessárias unidades com capacidade maior. Para obter informações sobre throughput provisionada no DynamoDB, consulte a capacidade de throughput do DynamoDB e atualização de uma tabela no Guia do desenvolvedor do Amazon DynamoDB.
Como a KCL atribui concessões aos operadores e equilibra a carga
A KCL coleta e monitora continuamente as métricas de utilização da CPU dos hosts de computação que executam os operadores para garantir uma distribuição uniforme de workload. Essas métricas de utilização da CPU são armazenadas na tabela de métricas do operador no DynamoDB. Se a KCL detectar que alguns operadores apresentam taxas de utilização da CPU mais altas em comparação com outros, ela reatribuirá as concessões entre os operadores para reduzir a carga dos operadores mais usados. O objetivo é equilibrar a workload de forma mais uniforme em toda a frota de aplicações de consumo, evitando que algum dos operadores fique sobrecarregado. À medida que a KCL distribui a utilização da CPU em toda a frota de aplicações de consumo, você pode dimensionar corretamente a capacidade da frota da aplicação de consumo escolhendo o número certo de operadores ou usar o ajuste de escala automático para gerenciar com eficiência a capacidade computacional para obter custos mais baixos.
Importante
A KCL somente pode coletar métricas de utilização da CPU dos operadores se determinados pré-requisitos forem atendidos. Para obter detalhes, consulte Pré-requisitos. Se a KCL não conseguir coletar dos operadores as métricas de utilização da CPU, a KCL voltará a usar a throughput por operador para atribuir concessões e equilibrar a carga entre os operadores da frota. A KCL monitorará a throughput que cada operador recebe em um determinado momento e reatribuirá as concessões para garantir que cada operador receba um nível de throughput total semelhante das concessões atribuídas.
