Balanceamento de carga de partição para processamento de eventos

O balanceamento de carga de partição é uma técnica em Hubs de Eventos do Azure que distribui cargas de trabalho de processamento de eventos em várias instâncias do aplicativo. O cliente do processador de eventos gerencia automaticamente a propriedade das partições e coordena a distribuição de tarefas entre todas as instâncias de consumidor ativas.

Nas versões mais recentes do SDK (5.0 em diante), EventProcessorClient (.NET e Java) ou EventHubConsumerClient (Python e JavaScript) manipula o balanceamento de carga automaticamente. Você se inscreve nos eventos em que está interessado registrando um manipulador de eventos.

Este artigo descreve um cenário de exemplo para usar várias instâncias de aplicativos cliente para ler eventos de um hub de eventos. Explica também conceitos-chave como propriedade de partições, checkpoints e balanceamento de carga.

Cenário de exemplo

Como um exemplo de cenário, considere uma empresa de segurança residencial que monitora 100.000 residências. A cada minuto, ele obtém dados de vários sensores, como um detector de movimento, sensor de porta/janela aberta, detector de quebra de vidro etc., instalado em cada residência. A empresa oferece um site da web para residentes monitorarem a atividade da sua casa quase em tempo real.

Cada sensor envia dados para um hub de eventos. O hub de eventos é configurado com 16 partições. No lado do consumidor, você precisa de um mecanismo que possa ler esses eventos, consolidá-los (filtrar, agregar, etc.) e despejar o agregado em um blob de armazenamento, que é então projetado para uma página da web amigável.

Aplicativo do consumidor

Ao projetar o consumidor em um ambiente distribuído, o cenário deve lidar com os seguintes requisitos:

• Escalar: crie vários consumidores, com cada consumidor assumindo a responsabilidade pela leitura de algumas partições do Hubs de Eventos.
• Balanceamento de carga: aumente ou reduza os consumidores dinamicamente. Por exemplo, quando um novo tipo de sensor (por exemplo, um detector de monóxido de carbono) é adicionado a cada residência, o número de eventos aumenta. Nesse caso, o operador (um ser humano) aumenta o número de instâncias de consumidor. Em seguida, o pool de consumidores pode redistribuir o número de partições que são proprietárias, para compartilhar a carga com os consumidores recém-adicionados.
• Retomada sem interrupções em falhas: se um consumidor (consumidor A) falhar (por exemplo, a máquina virtual que hospeda o consumidor falhar repentinamente), outros consumidores podem assumir as partições de propriedade do consumidor A e continuar. Além disso, o ponto de continuação, chamado de checkpoint ou offset, deve estar no ponto exato em que consumidor A falhou, ou um pouco antes disso.
• Consumir eventos: embora os três pontos anteriores tratem do gerenciamento do consumidor, deve haver código para consumir eventos e fazer algo útil com eles. Por exemplo, agregá-lo e carregá-lo no armazenamento de BLOBs.

Processador de eventos ou cliente consumidor

Você não precisa criar sua própria solução para atender a esses requisitos. Os SDKs dos hubs de eventos do Azure fornecem essa funcionalidade. Em SDKs .NET ou Java, use um cliente de processador de eventos (EventProcessorClient). Em SDKs Python e JavaScript, use EventHubConsumerClient. Na versão antiga do SDK, o host do processador de eventos (EventProcessorHost) tinha suporte para esses recursos.

Para a maioria dos cenários de produção, use o cliente do processador de eventos para ler e processar eventos. O cliente do processador fornece uma experiência robusta para processar eventos em todas as partições de um hub de eventos de maneira tolerante a falhas e, ao mesmo tempo, fornecer um meio de verificar seu progresso. Os clientes do processador de eventos podem trabalhar de forma cooperativa no contexto de um grupo de consumidores para um determinado Hub de eventos. Os clientes gerenciam automaticamente a distribuição e o balanceamento de trabalho conforme as instâncias tornam-se disponíveis ou indisponíveis para o grupo.

Propriedade da partição

Uma instância do processador de eventos normalmente possui e processa eventos de uma ou mais partições. O sistema distribui uniformemente a propriedade de partições entre todas as instâncias de processador de eventos ativas associadas a uma combinação de hub de eventos e grupo de consumidores.

Cada processador de eventos tem um identificador exclusivo e reivindica a propriedade de partições adicionando ou atualizando uma entrada em um repositório de checkpoints. Todas as instâncias do processador de eventos se comunicam com esse repositório periodicamente para atualizar seu próprio estado de processamento e saber mais sobre outras instâncias ativas. O sistema usa esses dados para equilibrar a carga entre os processadores ativos. Novas instâncias podem ingressar no pool de processamento para expandir. Quando as instâncias ficam indisponíveis, seja por falhas ou para escalar para baixo, o sistema transfere de forma suave a propriedade da partição para outros processadores ativos.

Os registros de propriedade de partição no repositório de ponto de verificação controlam o namespace dos hubs de eventos, o nome do hub de eventos, o grupo de consumidores, o identificador do processador de eventos (também conhecido como proprietário), a ID da partição e a hora da última modificação.

Cada instância do processador de eventos adquire a propriedade de uma partição e começa a processar a partição do último ponto de verificaçãoconhecido. Se um processador falhar (a VM será desligada), outras instâncias detectarão a falha examinando a hora da última modificação. Outras instâncias tentam obter a propriedade das partições anteriormente pertencentes à instância inativa. O repositório de ponto de verificação garante que apenas uma das instâncias tenha êxito ao declarar a propriedade de uma partição. Portanto, em qualquer momento específico, há no máximo um processador que recebe eventos de uma partição.

Receber mensagens

Ao criar um processador de eventos, especifique funções que processam eventos e erros. Cada chamada para a função que processa eventos fornece um único evento de uma partição específica. Você deve lidar com esse evento. Se você quiser garantir que o consumidor processe cada mensagem pelo menos uma vez, escreva seu próprio código com lógica de repetição. Mas tenha cuidado com mensagens suspeitas.

Processar eventos com relativa rapidez. Ou seja, faça o menor processamento possível. Caso você precise gravar no armazenamento e fazer algum roteamento, é melhor usar dois grupos de consumidores e ter dois processadores de evento.

Ponto de verificação

Checkpointing é um processo pelo qual um processador de eventos marca ou confirma a posição do último evento com êxito processado em uma partição. A marcação de um ponto de verificação normalmente ocorre dentro da função que processa os eventos e ocorre por partição dentro de um grupo de consumidores.

Se um processador de eventos se desconectar de uma partição, outra instância poderá retomar o processamento da partição no checkpoint que o último processador dessa partição naquele grupo de consumidores havia confirmado anteriormente. Quando o processador se conecta, ele passa esse deslocamento para o hub de eventos para especificar o ponto de início da leitura. Assim, você pode usar o ponto de verificação para marcar eventos como "concluídos" por aplicativos de downstream e oferecer resiliência quando um processador de eventos ficar inativo. Você pode retornar a dados anteriores especificando um deslocamento inferior a partir desse processo de checkpoint.

Quando o checkpoint marca um evento como processado, ele adiciona ou atualiza uma entrada no armazenamento de checkpoints com o deslocamento e o número de sequência do evento. Decida a frequência de atualização do ponto de verificação. A atualização após cada evento processado com êxito pode ter implicações de desempenho e custo, pois dispara uma operação de gravação para o repositório de ponto de verificação subjacente. Além disso, a definição de ponto de verificação para cada evento é indicativo de um padrão de mensagens enfileiradas para o qual uma fila do barramento de serviço pode ser uma opção melhor do que um hub de eventos. A ideia por trás dos Hubs de eventos é que você obtenha entregas "pelo menos uma vez" em grande escala. Ao tornar seus sistemas downstream idempotentes, é fácil se recuperar de falhas ou reinicializações que resultam nos mesmos eventos sendo recebidos várias vezes.

Siga estas recomendações ao usar o Armazenamento de Blobs do Azure como um repositório de ponto de verificação:

• Use um contêiner separado para cada grupo de consumidores. Você pode usar a mesma conta de armazenamento, mas usar um contêiner por cada grupo.
• Não use a conta de armazenamento para mais nada.
• Não use o contêiner para mais nada.
• Crie a conta de armazenamento na mesma região que o aplicativo implantado. Se o aplicativo estiver no local, tente escolher a região mais próxima possível.

Na página Conta de armazenamento do portal do Azure, na seção serviço Blob, verifique se as seguintes configurações estão desabilitadas.

• Namespace hierárquico
• Exclusão temporária de blobs
• Controle de versão

Segurança de thread e instâncias de processador

Por padrão, a função que processa eventos é chamada sequencialmente para uma determinada partição. Os eventos e chamadas subsequentes para essa função a partir da mesma participação são enfileirados em segundo plano enquanto a bomba de eventos continua a ser executada em segundo plano em outros threads. Eventos de partições diferentes podem ser processados simultaneamente. Você deve sincronizar qualquer estado compartilhado acessado entre partições.

Conteúdo relacionado

Confira os seguintes guias de início rápido:

• .NET Core
• Java
• Python
• JavaScript