Balanceamento de carga de partições para processamento de eventos

O balanceamento de carga de partições é uma técnica no Hubs de Eventos do Azure que distribui cargas de processamento de eventos entre múltiplas instâncias da sua aplicação. O cliente processador de eventos gere automaticamente a propriedade das partições e coordena a distribuição do trabalho entre todas as instâncias de consumo ativas.

Nas versões mais recentes do SDK (5.0 em diante), EventProcessorClient (.NET e Java) ou EventHubConsumerClient (Python e JavaScript) trata automaticamente do balanceamento de carga. Subscreve os eventos que lhe interessam ao registar um gestor 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. Também explica conceitos-chave como ponto de verificação, responsabilidade da partição e o balanceamento de carga.

Cenário de exemplo

Como cenário de exemplo, considere uma empresa de segurança doméstica que monitora 100.000 casas. A cada minuto, ele obtém dados de vários sensores, como um detetor de movimento, sensor de abertura de porta / janela, detetor de quebra de vidro, e assim por diante, instalado em cada casa. A empresa fornece um site para os moradores monitorarem a atividade de sua casa quase em tempo real.

Cada sensor envia dados para um hub de eventos. O hub de eventos é configurado com 16 partições. Na extremidade consumidora, você precisa de um mecanismo que possa ler esses eventos, consolidá-los (filtrar, agregar e assim por diante) e despejar a agregação em um blob de armazenamento, que é então projetado para uma página da Web amigável.

Aplicação ao consumidor

Quando você projeta um consumidor em um ambiente distribuído, o cenário deve lidar com os seguintes requisitos:

• Escala: Crie múltiplos consumidores, com cada consumidor assumindo a responsabilidade de ler de algumas partições de Hubs de Eventos.
• Balanceamento de carga: Aumente ou reduza os consumidores dinamicamente. Por exemplo, quando um novo tipo de sensor (por exemplo, um detetor de monóxido de carbono) é adicionado a cada casa, o número de eventos aumenta. Nesse caso, o operador (um ser humano) aumenta o número de instâncias de consumo. Em seguida, o pool de consumidores pode reequilibrar o número de partições que possuem, para compartilhar a carga com os consumidores recém-adicionados.
• Retomada contínua em falhas: Se um consumidor (consumidor A) falhar (por exemplo, a máquina virtual que hospeda o consumidor falha repentinamente), outros consumidores podem pegar as partições de propriedade do consumidor A e continuar. Além disso, o ponto de continuação, chamado de ponto de verificação ou compensação, deve estar no ponto exato em que o consumidor A falhou, ou um pouco antes disso.
• Consumir eventos: Enquanto os três pontos anteriores tratam da gestão do consumidor, deve haver código para consumir eventos e fazer algo útil com ele. Por exemplo, agregue-o e carregue-o para o 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, utiliza-se um cliente processador de eventos (EventProcessorClient). Em SDKs Python e JavaScript, use EventHubConsumerClient. Na versão antiga do SDK, o host do processador de eventos (EventProcessorHost) suportava estas funcionalidades.

Para a maioria dos cenários de produção, use o cliente processador de eventos para ler e processar eventos. O cliente processador proporciona uma experiência robusta para processar eventos em todas as partições de um hub de eventos de forma eficiente e tolerante a falhas, proporcionando ao mesmo tempo um meio de verificar o seu progresso. Os clientes do processador de eventos podem trabalhar cooperativamente dentro do contexto de um grupo de consumidores para um determinado hub de eventos. Os clientes gerem automaticamente a distribuição e o equilíbrio do trabalho à medida que as instâncias ficam 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 das partições entre todas as instâncias ativas do processador de eventos associadas a uma combinação de hub de eventos e grupo de consumidores.

Cada processador de eventos tem um identificador único e reivindica a propriedade das partições ao adicionar ou atualizar uma entrada num repositório de checkpoints. Todas as instâncias do processador de eventos comunicam periodicamente com este armazenamento para atualizar o seu próprio estado de processamento e para aprender sobre outras instâncias ativas. O sistema utiliza estes dados para equilibrar a carga entre os processadores ativos. Novas instâncias podem se juntar ao pool de processamento para aumentar a escala. Quando as instâncias ficam indisponíveis, seja devido a falhas ou para escalar para baixo, o sistema repassa graciosamente a propriedade das partições para outros processadores ativos.

Os registros de propriedade de partição no repositório de pontos de verificação mantêm registo do namespace dos Hubs de Eventos, do nome do hub de eventos, do grupo de consumidores, do identificador do processador de eventos (também conhecido como proprietário), da ID da partição e da data e 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 a partir do último ponto de verificação conhecido. Se um processador falhar (a VM for desligada), outras instâncias detetam a falha ao verificar o registo temporal da última modificação. Outras instâncias tentam obter a propriedade das partições anteriormente pertencentes à instância inativa. O armazenamento de pontos de verificação garante que apenas uma das instâncias consiga reivindicar a propriedade de uma partição. Portanto, em qualquer momento, 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 entrega um único evento de uma partição específica. Tens de lidar com este evento. Se quiser garantir que o consumidor processa cada mensagem pelo menos uma vez, escreva o seu próprio código com lógica de reintento. Mas tenha cuidado com mensagens envenenadas.

Processa os eventos relativamente rápido. Ou seja, fazer o mínimo de processamento possível. Se você precisar gravar no armazenamento e fazer algum roteamento, é melhor usar dois grupos de consumidores e ter dois processadores de eventos.

Ponto de Verificação

Checkpointing é um processo no qual um processador de eventos marca ou confirma a posição do último evento processado com sucesso dentro de uma partição. A marcação de um ponto de controlo ocorre tipicamente dentro da função que processa os eventos e ocorre numa base por partição dentro de um grupo de consumidores.

Se um processador de eventos se desconectar de uma partição, outra instância pode retomar o processamento da partição no ponto de verificação que o último processador dessa partição nesse grupo de consumidores confirmou anteriormente. Quando o processador se conecta, ele passa o deslocamento para o hub de eventos para especificar o local no qual iniciar a leitura. Dessa forma, você pode usar o ponto de verificação para marcar eventos como "completos" por aplicativos downstream e para fornecer resiliência quando um processador de eventos fica inativo. Pode regressar a dados mais antigos especificando um deslocamento inferior a partir deste processo de verificação de ponto.

Quando o checkpoint marca um evento como processado, adiciona ou atualiza uma entrada no armazenamento do checkpoint com o deslocamento e o número de sequência do evento. Decide a frequência de atualização do ponto de controlo. 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 no armazenamento de ponto de verificação subjacente. Além disso, o ponto de verificação de cada evento é indicativo de um padrão de mensagens em fila para o qual uma fila do Service Bus pode ser uma opção melhor do que um hub de eventos. A ideia por trás dos Hubs de Eventos é que você obtenha "pelo menos uma vez" entrega em grande escala. Ao tornar seus sistemas downstream idempotentes, é fácil se recuperar de falhas ou reinicializações que resultam no recebimento dos mesmos eventos várias vezes.

Siga estas recomendações ao usar o Armazenamento de Blobs do Azure como um armazenamento 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 recipiente para mais nada.
• Crie a conta de armazenamento na mesma região do aplicativo implantado. Caso a aplicação seja local, tente escolher a região mais próxima possível.

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

• Espaço de nomes hierárquico
• Eliminação suave de blobs
• Controlo 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. Eventos subsequentes e chamadas para esta função da mesma fila de partição são enfileirados nos bastidores, à medida que o sistema de processamento de eventos continua a ser executado em segundo plano em outros threads. Eventos de diferentes partições podem ser processados em simultâneo. Tens de sincronizar qualquer estado partilhado que seja acedido entre partições.

Conteúdos relacionados

Veja os seguintes quickstarts:

• .NET Core
• Java
• Píton
• Javascript