Dimensionar com Hubs de Eventos

Existem dois fatores que influenciam a colocação em escala por meio dos Hubs de Eventos.

  • Unidades de produtividade (camada standard) ou unidades de processamento (camada premium)
  • Partições

Unidades de transferência

A capacidade de transferência dos hubs de eventos é controlada pelas unidades de produtividade. As unidades de produtividade são unidades de capacidade pré-adquiridas. Uma unidade de produtividade permite:

  • Entrada: até 1 MB por segundo ou 1.000 eventos por segundo (o que ocorrer primeiro).
  • Saída: até 2 MB por segundo ou 4.096 eventos por segundo.

Além da capacidade das unidades de capacidade adquiridas, a entrada é limitada, e os Hubs de Eventos geram uma ServerBusyException. A saída não gera exceções de limitação, mas ainda é limitada à capacidade das unidades de produtividade adquiridas. Se você receber exceções de taxa de publicação ou estiver esperando ver mais saída, verifique quantas unidades de transferência você comprou para o namespace. Você pode gerenciar as unidades de produtividade na página Escala dos namespaces no portal do Azure. Você também pode gerenciar unidades de produtividade programaticamente usando as APIs de Hubs de Eventos.

As unidades de produtividade são pré-adquiridas e cobradas por hora. Depois de adquiridas, as unidades de taxa de transferência são cobradas por um mínimo de uma hora. Até 40 unidades de produtividade podem ser adquiridas para um namespace de Hubs de Eventos e elas são compartilhadas entre todos os Hubs de Eventos no namespace.

O recurso inflar automaticamente dos Hubs de Eventos escala verticalmente automaticamente aumentando o número de unidades de taxa de transferência para atender às necessidades de uso. O aumento de unidades de taxa de transferência evita cenários de limitação, nos quais:

  • As taxas de entrada de dados excedem as unidades de taxa de transferência definidas.
  • As taxas de solicitação de saída de dados excedem as unidades de taxa de transferência definidas.

O serviço de Hubs de Eventos aumenta a taxa de transferência quando a carga aumentar ultrapassando o limite mínimo, sem quaisquer solicitações com falha com erros de ServerBusy.

Para mais informações sobre o recurso de ampliação automática, confira o tópico Escalar automaticamente unidades de produtividade.

Unidades de processamento

Os Hubs de Eventos Premium fornecem desempenho superior e melhor isolamento em um ambiente de PaaS multilocatário gerenciado. Os recursos em uma camada Premium são isolados no nível de CPU e memória, para que cada carga de trabalho de locatário seja executada isoladamente. Esse contêiner de recursos é chamado de PU (unidade de processamento). Você pode adquirir 1, 2, 4, 6, 8, 10, 12 ou 16 unidades de processamento para cada namespace dos Hubs de Eventos Premium.

O quanto você pode ingerir e transmitir com uma unidade de processamento depende de vários fatores, como os produtores, consumidores, a taxa de ingestão e processamento etc.

Por exemplo, o namespace dos Hubs de Eventos Premium com uma PU e um hub de eventos (100 partições) pode oferecer uma capacidade principal de aproximadamente 5 a 10 MB/s de entrada e 10 a 20 MB/s de saída para cargas de trabalho AMQP ou Kafka.

Para saber como configurar PUs para um namespace de camada premium, consulte Configurar unidades de processamento.

Observação

Para saber mais sobre cotas e limites, consulte Hubs de Eventos do Azure - cotas e limites.

Partições

Os Hubs de Eventos organizam sequências de eventos enviados a um hub de eventos em uma ou mais partições. À medida que novos eventos chegam, eles são adicionados ao final dessa sequência.

Imagem mostrando um hub de eventos com algumas partições.

Uma partição pode ser considerada como um registro de confirmação. As partições contêm dados de evento que contêm as seguintes informações:

  • Corpo do evento
  • Recipiente de propriedades definido pelo usuário que descreve o evento
  • Metadados como o deslocamento na partição, o número na sequência de fluxo
  • Carimbo de data/hora do lado do serviço no qual foi aceito

Diagrama que exibe a sequência de eventos mais antigos para os mais recentes.

Vantagens do uso de partições

Os Hubs de Eventos são projetados para ajudar no processamento de grandes volumes de eventos, e o particionamento ajuda com isso de duas maneiras:

  • Embora os Hubs de Eventos sejam um serviço de PaaS, há uma realidade física oculta. A manutenção de um log que preserva a ordem dos eventos requer que esses eventos estejam sendo mantidos juntos no armazenamento subjacente e em suas réplicas e isso resulta em um teto de taxa de transferência para esse log. O particionamento permite que vários logs paralelos sejam usados para o mesmo hub de eventos, multiplicando, portanto, a capacidade de taxa de transferência de E/S (entrada-saída) bruta disponível.
  • Seus aplicativos precisam conseguir acompanhar o processamento do volume de eventos que estão sendo enviados para um hub de eventos. Ela pode ser complexa e exigir uma capacidade de processamento paralelo, substancial e de expansão. A capacidade de um só processo de lidar com os eventos é limitada. Portanto, é necessário ter vários processos. As partições são como a sua solução alimenta esses processos, garantindo, ainda, que cada evento tenha um proprietário de processamento claro.

Número of partições

O número de partições é especificado no momento da criação de um hub de eventos. Ela deve estar entre um e o número máximo de partições permitido para cada tipo de preço. Para obter o limite de contagem de partições para cada camada, confira este artigo.

Recomendamos que você escolha, pelo menos, o máximo de partições que deverão ser necessárias durante o pico de carga do seu aplicativo para esse hub de eventos específico. Quanto às camadas que não sejam as camadas premium e dedicada, não é possível alterar a contagem das partições de um hub de eventos após sua criação. Quanto a um hub de eventos em uma camada premium ou dedicada, você pode aumentar a contagem das partições após sua criação, mas não pode reduzi-las. A distribuição dos fluxos entre as partições será alterada quando isso for feito, pois o mapeamento das chaves de partição para as partições é alterado, por isso, você deve se esforçar para evitar essas alterações se a ordem relativa dos eventos for importante para o seu aplicativo.

Definir o número de partições com o valor máximo permitido é tentador, mas sempre tenha em mente que os fluxos de eventos precisam ser estruturados de um jeito que você possa tirar proveito de várias partições. Se você precisar de preservação absoluta da ordem em todos os eventos ou apenas em alguns subfluxos, talvez não consiga aproveitar muitas partições. Além disso, muitas partições tornam o lado de processamento mais complexo.

Quando se trata de preço, o número de partições existentes em um hub de eventos não é relevante. Isso depende do número de unidades de preço – TUs (unidades de produtividade) da camada standard, PUs (unidades de processamento) da camada premium e CUs (unidades de capacidade) da camada dedicada – do namespace ou do cluster dedicado. Por exemplo, um hub de eventos da camada standard com 32 partições ou com uma partição incorre exatamente no mesmo custo quando o namespace é definido para uma capacidade de TU. Além disso, é possível escalar as TUs ou as PUs no namespace ou as CUs do cluster dedicado independentemente da contagem de partições.

Como a partição é um mecanismo de organização de dados que permite publicar e consumir dados de maneira paralela. Recomendamos que você equilibre as unidades de dimensionamento (unidades de produtividade para a camada padrão, unidades de processamento para a camada Premium ou unidades de capacidade para a camada dedicada) e as partições para obter o dimensionamento ideal. Em geral, recomendamos uma taxa de transferência máxima de 1 MB/s por partição. Portanto, uma regra geral para calcular o número de partições seria dividir a taxa de transferência máxima esperada por 1 MB/s. Por exemplo, se o seu caso de uso exigir 20 MB/s, recomendamos que você escolha pelo menos 20 partições para obter a taxa de transferência ideal.

Contudo, se você tiver um modelo em que seu aplicativo tenha afinidade com uma partição específica, aumentar o número de partições não será benéfico. Para saber mais, confira disponibilidade e consistência.

Mapeamento de eventos para partições

Você pode usar uma chave de partição para mapear dados de evento de entrada em partições específicas para fins de organização de dados. A chave de partição é um valor fornecido pelo remetente passado para um hub de eventos. Ele é processado por meio de uma função de hash estático, que cria a atribuição de partição. Se você não especificar uma chave de partição ao publicar um evento, uma atribuição de round robin será usada.

O editor de eventos só está ciente da sua chave de partição, não da partição para a qual os eventos são publicados. Essa desassociação de chave e partição isenta o remetente da necessidade de saber muito sobre o processamento de downstream. Uma identidade por dispositivo ou exclusiva do usuário é uma boa chave de partição, mas outros atributos, como geografia, também podem ser usados para agrupar eventos relacionados em uma única partição.

A especificação de uma chave de partição permite manter eventos relacionados juntos na mesma partição e na ordem exata em que eles chegaram. A chave de partição é uma cadeia de caracteres derivada do contexto do aplicativo e identifica a relação entre os eventos. Uma sequência de eventos identificados por uma chave de partição é um fluxo. Uma partição é um repositório de logs multiplexado para muitos desses fluxos.

Observação

Embora você possa enviar eventos diretamente para as partições, não recomendamos isso, especialmente quando a alta disponibilidade é importante para você. Isso faz o downgrade da disponibilidade de um hub de eventos para o nível de partição. Para obter mais informações, confira Disponibilidade e consistência.

Próximas etapas

Você pode saber mais sobre Hubs de Eventos visitando os links abaixo: