Abordagens de arquitetura para mensagens em soluções multilocatário

Aplicativos distribuídos que incluem vários serviços internos e externos exigem mensagens assíncronas e comunicação controlada por eventos. Ao projetar sua solução multilocatário, você deve decidir como compartilhar ou particionar mensagens que pertencem a locatários diferentes.

Você pode compartilhar um sistema de mensagens ou um serviço de streaming de eventos em todos os locatários para reduzir o custo operacional e a complexidade do gerenciamento. Como alternativa, você pode usar um sistema de mensagens dedicado para cada locatário para obter um isolamento de dados melhor, reduzir o risco de vazamento de dados, eliminar o problema de vizinho barulhento e cobrar os custos do Azure de volta aos seus locatários com mais facilidade.

Este artigo ajuda os arquitetos de soluções a decidir como usar a infraestrutura de mensagens ou eventos em uma solução multilocatário.

Mensagens, pontos de dados e eventos discretos

Você deve entender a diferença entre os serviços que fornecem um evento e sistemas que enviam uma mensagem. Um evento é uma notificação leve de uma alteração de estado ou condição. Um evento normalmente descreve algo que já aconteceu. Uma mensagem contém dados brutos que um serviço produz para ser consumido ou armazenado em outro lugar. Mensagens são instruções implícitas ou solicitações.

A tabela a seguir descreve os principais tipos de mensagens e exemplos de soluções multilocatários que podem usar esse tipo de entidade.

Para obter mais informações, consulte Escolher o serviço de mensagens do Azure correto para seus dados.

O Azure fornece vários serviços de mensagens que podem dar suporte aos seus requisitos de mensagens. Esses serviços incluem Hubs de Eventos do Azure, Grade de Eventos do Azure e Barramento de Serviço do Azure. Para obter mais informações, consulte Escolher entre os serviços de mensagens do Azure.

Você também pode implantar e gerenciar seu próprio serviço de mensagens em VMs (máquinas virtuais), contêineres ou em serviços como o AKS (Serviço de Kubernetes do Azure). Essa abordagem exige que você implante, gerencie e mantenha sua infraestrutura de mensagens.

Considerações e requisitos

O modelo de implantação e locação escolhido para sua solução afeta a segurança, o desempenho, o isolamento de dados, o gerenciamento e a capacidade de cobrar custos de recursos entre locatários. Ao fazer essa análise, considere também o modelo selecionado para sua infraestrutura de mensagens e eventos. As seções a seguir descrevem as principais decisões que você deve tomar ao planejar um sistema de mensagens em sua solução multilocatário.

Escala

Ao planejar a infraestrutura de mensagens ou eventos, considere o número de locatários, a complexidade dos fluxos de mensagens e fluxos de eventos, o volume de mensagens, o perfil de tráfego esperado e o nível de isolamento.

Primeiro, planeje a capacidade e estabeleça a capacidade máxima de taxa de transferência para o sistema de mensagens. Esse planejamento ajuda você a lidar corretamente com o volume esperado de mensagens durante o tráfego regular e de pico.

Quando sua solução lida com muitos locatários e tem um sistema de mensagens separado para cada locatário, aplique uma estratégia de automação consistente. Essa estratégia deve automatizar a implantação, o monitoramento, o alerta e o dimensionamento de cada infraestrutura.

Por exemplo, você pode implantar um sistema de mensagens para um locatário durante o processo de provisionamento usando uma ferramenta IaC (infraestrutura como código), como modelos do Terraform, Bicep ou arm (modelos do Azure Resource Manager) e um sistema DevOps como o Azure DevOps ou o GitHub Actions. Para obter mais informações, confira Abordagens de arquitetura para implantação e configuração de soluções multilocatário.

Você pode dimensionar o sistema de mensagens com uma taxa de transferência máxima em mensagens por unidade de tempo. Se o sistema der suporte ao dimensionamento automático dinâmico, ele poderá aumentar ou diminuir automaticamente sua capacidade com base em condições de tráfego e métricas para atender ao SLA (contrato de nível de serviço) esperado.

Previsibilidade e confiabilidade do desempenho

Para apenas alguns locatários, um único sistema de mensagens pode atender aos requisitos de taxa de transferência de desempenho e reduzir o custo total de propriedade (TCO). Um aplicativo multilocatário pode compartilhar as mesmas entidades de mensagens, como filas e tópicos, entre vários clientes. Como alternativa, você pode usar um conjunto dedicado de componentes para cada locatário para aumentar o isolamento do locatário. Mas uma infraestrutura de mensagens compartilhadas em vários locatários pode expor toda a solução para o problema do vizinho barulhento. A atividade de um locatário pode interromper o desempenho e a operabilidade de outros locatários.

Nesse caso, você deve dimensionar corretamente o sistema de mensagens para sustentar a carga de tráfego esperada no horário de pico. Idealmente, o sistema deve dar suporte ao dimensionamento automático, que expande dinamicamente conforme o aumento do tráfego e reduz quando o tráfego diminui. Um sistema de mensagens dedicado para cada locatário também pode atenuar o risco de vizinho barulhento, mas o gerenciamento de muitos sistemas de mensagens aumenta a complexidade da solução.

Um aplicativo multilocatário pode usar uma abordagem híbrida. Nessa abordagem, os principais serviços usam o mesmo conjunto de filas e tópicos em um único sistema de mensagens compartilhado para implementar comunicações internas e assíncronas. Por outro lado, outros serviços podem adotar um grupo dedicado de entidades de mensagens ou até mesmo um sistema de mensagens dedicado para cada locatário para atenuar o problema de vizinho barulhento e garantir o isolamento de dados.

Gerenciamento e complexidade operacional

Desde o início, planeje como pretende operar, monitorar e manter sua infraestrutura de mensagens e eventos e como sua abordagem de multilocatário afeta suas operações e processos. Por exemplo, considere os seguintes fatores:

• Ao compartilhar um sistema de mensagens entre vários locatários, defina como sua solução coleta e relata as métricas de uso para cada locatário ou como ela limita o número de mensagens que cada locatário pode enviar ou receber.

• Quando os locatários precisarem migrar para um tipo diferente de serviço de mensagens, uma implantação diferente ou outra região, determine como migrá-los.

• Quando o sistema de mensagens usa uma oferta de PaaS (plataforma como serviço), considere as seguintes considerações:

  • Personalize o tipo de preço para cada locatário com base nos recursos e no nível de isolamento compartilhado ou dedicado que o locatário solicita.

  • Crie identidades gerenciadas específicas do locatário e atribuições de função do Azure para atribuir as permissões adequadas somente às entidades de mensagens que o locatário deve acessar. Por exemplo, consulte Autenticar uma identidade gerenciada com Microsoft Entra ID para acessar os recursos do Service Bus.

• Se você optar por hospedar o sistema de mensagens que seu aplicativo usa em um conjunto dedicado de VMs ou contêineres (um para cada locatário), defina como implantar, atualizar, monitorar e dimensionar esses sistemas.

Custo

Geralmente, quanto maior a densidade de locatários para sua infraestrutura de implantação, menor o custo para provisionar essa infraestrutura. Mas a infraestrutura compartilhada aumenta a probabilidade de problemas como o problema do vizinho barulhento. Considere cuidadosamente as compensações.

Abordagens e padrões a serem considerados

Quando você planeja uma solução multitenant que envolve mensagens, considere o nível de isolamento entre locatários. Examine as seguintes considerações e observações:

• Chaves de criptografia: Se os locatários precisarem de sua própria chave para criptografar e descriptografar mensagens, confirme como o serviço de mensagens dá suporte ao isolamento de chaves. Por exemplo, se você utilizar o Service Bus, talvez seja necessário criar um namespace Premium do Service Bus separado para cada locatário que precise de suas próprias chaves. Essa separação permite que você use chaves gerenciadas pelo cliente (CMKs).

• Continuidade dos negócios: Identificar locatários que precisam de um alto nível de capacidade de recuperação e continuidade dos negócios. Considere a redundância de zona, a redundância geográfica e os recursos de recuperação de desastres geográficos para esses locatários quando disponíveis.

• Processamento de trabalho: Ao usar recursos de fila separados ou um sistema de mensagens dedicado para cada locatário, você pode adotar um pool separado de processos de trabalho para cada locatário. Essa abordagem aumenta o nível de isolamento de dados e reduz a complexidade do gerenciamento de várias entidades de mensagens.

  Cada instância do sistema de processamento pode adotar credenciais diferentes, como uma cadeia de conexão, uma entidade de serviço ou uma identidade gerenciada, para acessar o sistema de mensagens dedicado. Essa abordagem melhora a segurança e o isolamento entre locatários, mas aumenta a complexidade do gerenciamento de identidades.

Sistema de mensagens compartilhado

Você pode implantar um sistema de mensagens compartilhado, como um único namespace do Barramento de Serviço, e compartilhá-lo em todos os seus locatários.

Essa abordagem fornece a maior densidade de locatários para a infraestrutura e reduz o TCO geral. Geralmente, isso reduz a sobrecarga de gerenciamento porque você só precisa gerenciar e proteger um único sistema de mensagens ou recurso.

Mas quando você compartilha um recurso ou uma infraestrutura inteira em vários locatários, considere as seguintes limitações:

• Considere as restrições, os recursos de dimensionamento, as cotas e os limites do recurso. Por exemplo, o número máximo de Hubs de Eventos em um único namespace ou os limites máximos de taxa de transferência pode eventualmente se tornar um bloqueador quando sua arquitetura cresce para dar suporte a mais locatários.

• O problema do vizinho barulhento pode se tornar um fator quando você compartilha um recurso entre vários locatários, especialmente se você tiver locatários ocupados ou que geram tráfego mais alto do que outros. Para atenuar esses efeitos, considere o padrão de controle de velocidade ou o padrão de limitação de taxa. Por exemplo, você pode limitar o número máximo de mensagens que um único locatário pode enviar ou receber dentro de um período de tempo.

• Você pode ter dificuldades para monitorar a atividade e medir o consumo de recursos para um locatário individual. Alguns serviços, como camadas específicas do Barramento de Serviço, cobram por operações de envio e recebimento de mensagens. Quando você compartilha um namespace entre vários locatários, seu aplicativo deve acompanhar o número de operações de mensagens que cada locatário gera e seus custos de chargeback associados. Outros serviços não fornecem o mesmo nível de detalhes.

Os locatários podem ter requisitos diferentes para segurança, resiliência intra-região, recuperação de desastre ou localização. Se esses requisitos não corresponderem à configuração do sistema de mensagens, talvez você não os acomode apenas com um único recurso.

Utilize o padrão de fragmentação

O padrão de fragmentação envolve a implantação de vários sistemas de mensagens, também chamados de fragmentos. Cada fragmento contém uma ou mais entidades de mensagens de locatários, como filas e tópicos. Ao contrário dos selos de implantação, os fragmentos não implicam que você duplica toda a infraestrutura. Você pode fragmentar sistemas de mensagens sem também duplicar ou fragmentar outra infraestrutura em sua solução.

Cada sistema de mensagens ou fragmento pode ter características diferentes em termos de confiabilidade, SKU e localização. Por exemplo, você pode fragmentar seus locatários em vários sistemas de mensagens com base em sua localização ou requisitos para desempenho, confiabilidade, proteção de dados ou continuidade dos negócios.

Ao usar o padrão sharding, é necessário adotar uma estratégia de fragmentação para mapear um locatário específico ao sistema de mensagens que contém suas filas. A estratégia de pesquisa usa um mapa para identificar o sistema de mensagens de destino com base no nome do locatário ou na ID. Vários locatários podem compartilhar o mesmo fragmento, mas as entidades de mensagens que um único locatário usa permanecem dentro de um fragmento.

Você pode implementar o mapa como um dicionário que vincula cada nome de locatário ao nome ou referência de seu sistema de mensagens de destino. Você pode armazenar o mapa em um cache distribuído que todas as instâncias de um aplicativo multilocatário podem acessar ou armazená-lo em um repositório persistente, como uma tabela em um banco de dados relacional ou conta de armazenamento.

O padrão Sharding pode ser dimensionado para dar suporte a vários usuários. Dependendo da carga de trabalho, você pode obter uma alta densidade de locatários para fragmentos, o que pode reduzir o custo. Você também pode usar o padrão sharding para lidar com cotas, limites e restrições de serviço e assinatura do Azure.

Usar um aplicativo multilocatário com um sistema de mensagens dedicado para cada locatário

Você também pode implantar um único aplicativo multilocatário que usa sistemas de mensagens dedicados para cada locatário. Esse modelo de locação inclui alguns componentes compartilhados, como recursos de computação. Você provisiona e gerencia outros serviços por meio de uma abordagem de implantação dedicada para locatário único. Por exemplo, você pode criar uma única camada de aplicativo e, em seguida, implantar sistemas de mensagens individuais para cada locatário, conforme mostrado na ilustração a seguir.

Se componentes específicos gerarem a maior parte da carga do sistema e você puder implantar esses componentes separadamente para cada locatário, use uma implantação particionada horizontalmente para reduzir problemas de vizinhos barulhentos. Por exemplo, use um sistema de mensagens ou eventstream separado para cada locatário se uma única instância não puder acompanhar o tráfego gerado por vários locatários. Quando você usa um sistema de mensagens dedicado para cada locatário, um grande volume de mensagens ou eventos de um único locatário pode afetar os componentes compartilhados, mas não os sistemas de mensagens de outros locatários.

Como você provisiona recursos dedicados para cada locatário, essa abordagem geralmente custa mais do que um modelo de hospedagem compartilhado. No entanto, ele também oferece uma maneira simples de cobrar cada locatário pelos recursos que eles usam. Essa abordagem permite que você obtenha alta densidade para outros serviços, como recursos de computação, e reduz o custo desses componentes.

Com uma implantação particionada horizontalmente, você precisa de um processo automatizado para implantar e gerenciar os serviços de um aplicativo multilocatário, especialmente os serviços usados por um único locatário.

Colaboradores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

• Paolo Salvatori | Engenheiro de Cliente Principal, FastTrack for Azure

Outros colaboradores:

• Daphne Choong | Arquiteto de Soluções de Parceiro Sênior
• John Downs | Principal Engenheiro de Software, Padrões do Azure & Práticas
• Clemens Vasters | Arquiteto Principal, Serviços e Padrões de Mensagens
• Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

Recursos relacionados

Para obter mais informações sobre padrões de design de mensagens, confira os seguintes recursos:

• Padrão de Verificação de Declaração
• Padrão de Consumidores Concorrentes
• Padrão de Fornecimento de Evento
• Padrão de Tubos e Filtros
• Padrão Publicador/Assinante
• Padrão de Comboio Sequencial