Multilocação e Hubs de Eventos do Azure

  • Artigo

O Hubs de Eventos é uma plataforma de streaming de Big Data e um serviço de ingestão de eventos que pode receber e processar milhões de eventos por segundo. Você pode transformar e armazenar dados de hub de eventos usando provedores de análise em tempo real e adaptadores de envio em lote/armazenamento. Para ver uma comparação dos Hubs de Eventos e de outros serviços de mensagens do Azure, consulte Escolher entre os serviços de mensagens do Azure – Grade de Eventos, Hubs de Eventos e Barramento de Serviço.

Este artigo descreve os recursos e modelos de isolamento dos Hubs de Eventos que você pode usar em soluções multilocatário.

Modelos de isolamento

Ao usar Hubs de Eventos em seu sistema multilocatário, você precisará decidir o nível de isolamento desejado. Os Hubs de Eventos têm suporte a diferentes modelos de multilocação.

  • Multilocação confiável: todos os locatários compartilham um namespace dos Hubs de Eventos. Essa opção poderá ser adequada quando todos os locatários estiverem em sua organização.
  • Multilocação hostil: cada locatário tem seu próprio namespace que não é compartilhado. Essa opção poderá ser adequada quando você quiser garantir que seus locatários não tenham problemas de vizinhos barulhentos.

Um sistema pode implementar os dois modelos: alguns locatários compartilham namespaces, outros têm um dedicado. Além disso, um locatário pode compartilhar um namespace com outros locatários, mas tem hubs de eventos dedicados.

A tabela a seguir resume as diferenças entre os principais modelos de isolamento de locação para Hubs de Eventos. Os modelos serão descritos em mais detalhes nas seções a seguir.

Consideração Namespace dedicado Namespace compartilhado, hubs de eventos dedicados Namespace compartilhado e hubs de eventos
Isolamento de dados Alto Médio Nenhum
Isolamento de desempenho O mais alto. Gerencie as necessidades de desempenho com base nos requisitos de cada locatário. Média. Pode ter problemas de vizinho barulhento. Baixo. Pode ter problemas de vizinho barulhento.
Complexidade da implantação Média. Esteja ciente de cotas e limites dos Hubs de Eventos no nível de assinatura. Média. Entidades de mensagem separadas devem ser implantadas para cada locatário. Esteja ciente de cotas e limites dos Hubs de Eventos. Alguns casos requerem vários namespaces, dependendo do número de locatários. Baixo
Complexidade operacional Alto. Necessidade de gerenciar namespaces por locatário. Média. Alguns locatários requerem gerenciamento granular de entidades de mensagem. Baixo
Cenário de exemplo Separe instâncias de aplicativo por locatário. Hubs de eventos dedicados para cada locatário. Solução multilocatário grande com uma camada de aplicativo compartilhada e um ou mais hubs de eventos compartilhados.

Observação

O Hubs de Eventos para Apache Kafka é um recurso que fornece um cabeçalho de protocolo sobre os Hubs de Eventos, de forma que eles possam ser usados por aplicativos Apache Kafka. Os aplicativos transmitem eventos em hubs de eventos, que são equivalentes aos tópicos do Kafka. Para obter mais informações, consulte O que é Hubs de Eventos para Apache Kafka.

Namespace dedicado

Nesse modelo, você provisiona um namespace de Hubs de Eventos para cada locatário. Essa abordagem fornece o nível máximo de isolamento e a capacidade de fornecer desempenho aceitável para todos os locatários.

Você pode usar as técnicas a seguir para ajustar os recursos de eventos para atender aos requisitos do locatário:

Se você atingir o número máximo de namespaces de Hubs de Eventos em sua assinatura do Azure, poderá implantar namespaces em diferentes assinaturas usando o padrão de Selos de Implantação.

A desvantagem desse modelo de isolamento é que, à medida que o número de locatários aumenta com o passar do tempo, o gerenciamento dos namespaces fica mais complexo. Outra desvantagem é que o modelo aumenta os custos, porque você paga cada namespace.

Namespace compartilhado, hubs de eventos dedicados

Mesmo que um namespace seja compartilhado por múltiplos locatários, você poderá isolar locatários em um hub de eventos dedicado. Você poderá usar assinaturas de acesso compartilhado ou identidades do Microsoft Entra para controlar o acesso.

À medida que o número de locatários cresce em seu sistema, o número de hubs de eventos também aumenta para acomodar cada locatário. Esse crescimento pode levar a custos operacionais mais altos e menor agilidade organizacional. Há um limite no número de hubs de eventos por namespace. Dessa forma, o número de namespaces que seu sistema requer depende do número de hubs de eventos que seus locatários exigem.

Quando um namespace é compartilhado, os problemas de vizinhos barulhentos são mais prováveis. Por exemplo, será possível que as entidades de evento de um locatário consumam uma quantidade desproporcional dos recursos de namespace e prejudiquem outros locatários. Os namespaces de hubs de eventos têm limites em suas unidades de processamento (camada premium) ou unidades de capacidade (camada dedicada), bem como no número de conexões agenciadas com um namespace. Considere se um único locatário pode consumir muitos recursos.

Namespace compartilhado e hubs de eventos

Você pode ter um namespace e entidades de evento que são compartilhadas por todos os seus locatários. Esse modelo diminui a complexidade operacional e reduz os custos de recursos.

No entanto, ter um namespace compartilhado poderá levar ao problema do vizinho barulhento e resultar em maior latência para alguns locatários. Você também precisa implementar seus aplicativos para atender a múltiplos locatários. Os hubs de eventos compartilhados e os tópicos do Kafka não fornecem isolamento de dados entre locatários, portanto, você precisa atender aos requisitos de isolamento de dados na lógica do aplicativo.

Observação

Não use partições de Hubs de Eventos para tentar isolar seus locatários. O particionamento nos Hubs de Eventos permite o processamento de eventos e a escalabilidade, mas não é um modelo de isolamento. Você pode enviar eventos diretamente para partições, mas isso não é recomendado porque isso faz o downgrade da disponibilidade de um hub de eventos para o nível de partição. Para obter mais informações, consulte Disponibilidade e consistência nos Hubs de Eventos.

Recursos dos Hubs de Eventos que dão suporte à multilocação

Os seguintes recursos dos Hubs de Eventos dão suporte à multilocação:

Esses recursos serão discutidos nas seções a seguir.

Grupos de aplicativos

Um grupo de aplicativos é uma coleção de um ou mais aplicativos cliente que interagem com o plano de dados dos Hubs de Eventos. Você pode aplicar políticas de gerenciamento de cotas e de acesso a todos os aplicativos do grupo aplicando-as ao próprio grupo.

Cada grupo de aplicativos pode ter como escopo um namespace único de Hubs de Eventos ou um hub de eventos único. Ele deve usar um identificador de condição de identificação exclusiva dos aplicativos cliente, como o contexto de segurança, que é uma assinatura de acesso compartilhado (SAS) ou uma ID de aplicativo do Microsoft Entra.

Para obter mais informações, confira Governança de recursos com grupos de aplicativos.

autenticação do Microsoft Entra

Os Hubs de Eventos são integrados ao Microsoft Entra ID. Os clientes podem se autenticar nos recursos dos Hubs de Eventos usando uma identidade gerenciada com o Microsoft Entra ID. Os Hubs de Eventos definem um conjunto de funções internas que você pode conceder a seus locatários para acessar entidades dos Hubs de Eventos. Por exemplo, usando a autenticação do Microsoft Entra, você pode conceder acesso a um locatário a um hub de eventos que tenha as mensagens para esse locatário. Você pode usar essa técnica para isolar um locatário de outros locatários.

Os aplicativos Kafka podem usar o OAuth de identidade gerenciada para acessar recursos dos Hubs de Eventos.

Para obter mais informações, consulte os seguintes artigos:

Assinatura de acesso compartilhado

As assinaturas de acesso compartilhado (SAS) permitem conceder a um locatário acesso aos recursos dos Hubs de Eventos com direitos específicos. Se você isolar seus locatários em um nível de entidade de evento, poderá conceder chaves SAS em um hub de eventos ou tópico do Kafka que se aplique somente a um locatário específico.

Para obter mais informações, consulte Autenticar o acesso aos recursos dos Hubs de Eventos usando SAS (assinaturas de acesso compartilhado).

Chaves gerenciadas pelo cliente

Se seus locatários precisarem de suas próprias chaves para criptografar e descriptografar eventos, você poderá configurar as chaves gerenciadas pelo cliente em algumas versões de Hubs de Eventos.

Esse recurso requer que você use o modelo de isolamento de namespace dedicado. A criptografia só pode ser habilitada para namespaces novos ou vazios.

Para obter mais informações, confira Configurar chaves gerenciadas pelo cliente para criptografar dados inativos dos Hubs de Eventos do Azure.

Capturar Hubs de Eventos

Você pode usar o recurso Captura de Hubs de Eventos para capturar automaticamente os dados de streaming dos Hubs de Eventos e armazená-los em uma conta do Armazenamento de Blobs do Azure ou do Data Lake Storage.

Esse recurso é útil para arquivamento de eventos. Por exemplo, caso seja necessário arquivar eventos de um locatário por motivos de conformidade, você poderá implantar namespaces específicos do locatário e habilitar a Captura de Hubs de Eventos para arquivar eventos em Contas de Armazenamento do Azure específicas do locatário. Você também poderá habilitar a Captura de Hubs de Eventos em hubs de eventos específicos do locatário em um namespace compartilhado.

Para obter mais informações, consulte Capturar eventos por meio dos Hubs de Eventos do Azure no Armazenamento de Blobs do Azure ou no Azure Data Lake Storage.

Recuperação de desastre geográfico

A recuperação de desastre geográfico replica continuamente toda a configuração de um namespace de Hubs de Eventos de um namespace primário para um namespace secundário emparelhado com o primário. Esse recurso pode ajudar na recuperação de desastres, como falhas regionais.

Por exemplo, se você isolar seus locatários no nível do namespace, poderá replicar a configuração de um namespace de locatário para uma região secundária, a fim de fornecer proteção contra paralisações e falhas da região primária.

Para saber mais, consulte Hubs de Eventos do Azure - Recuperação de desastre geográfico.

Observação

Para ajudar a proteger a continuidade das operações, a recuperação de desastre geográfico replica a configuração do namespace primário para o namespace secundário. Ela não replica os dados do evento, nem quaisquer atribuições do Microsoft Entra RBAC que você usa para seu namespace primário. Para obter mais informações, consulte Federação de vários sites e várias regiões.

Regras de firewall de IP

Você pode usar regras de firewall de IP para controlar o acesso a namespaces. Ao isolar locatários no nível do namespace, você poderá configurar os namespaces para aceitar conexões somente de clientes originados de endereços IP ou intervalos de endereços permitidos.

Para saber mais, veja:

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

  • Will Velida | Engenheiro do Cliente 2, FastTrack for Azure

Outros colaboradores:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas