Abordagens arquitetônicas para mensagens em soluções multilocatárias

Aplicações distribuídas que incluem múltiplos serviços internos e externos requerem mensagens assíncronas e comunicação orientada a eventos. Ao desenhar a sua solução multiinquilino, deve decidir como partilhar ou particionar mensagens que pertencem a diferentes inquilinos.

Pode partilhar um sistema de mensagens ou um serviço de streaming de eventos entre todos os inquilinos para reduzir os custos operacionais e a complexidade da gestão. Em alternativa, pode usar um sistema de mensagens dedicado para cada inquilino para obter melhor isolamento de dados, reduzir o risco de fuga de dados, eliminar o problema barulhento dos vizinhos e cobrar os custos do Azure aos seus inquilinos com mais facilidade.

Este artigo ajuda os arquitetos de soluções a decidir como usar infraestrutura de mensagens ou eventos numa solução multiinquilino.

Mensagens, pontos de dados e eventos discretos

Deve compreender a diferença entre serviços que entregam um evento e sistemas que transmitem uma mensagem. Um evento é uma notificação leve de uma condição ou alteração de estado. Um evento normalmente descreve algo que já aconteceu. Uma mensagem contém dados brutos que um serviço produz para serem consumidos ou armazenados noutro local. As mensagens são instruções ou pedidos implícitos.

A tabela seguinte descreve os principais tipos de mensagens e exemplos de soluções multiinquilino que possam usar esse tipo de entidade.

Para mais informações, consulte Escolha o serviço de mensagens Azure adequado para os seus dados.

O Azure oferece vários serviços de mensagens que podem suportar as suas necessidades de mensagens. Estes serviços incluem Azure Event Hubs, Azure Event Grid e Azure Service Bus. Para mais informações, consulte Escolher entre serviços de mensagens Azure.

Também pode implementar e gerir o seu próprio serviço de mensagens em máquinas virtuais (VMs), containers ou em serviços como o Azure Kubernetes Service (AKS). Esta abordagem exige que implemente, gere e mantenha a sua infraestrutura de mensagens.

Principais considerações e requisitos

O modelo de implementação e arrendamento que escolher para a sua solução afeta a segurança, desempenho, isolamento de dados, gestão e a capacidade de cobrar custos de recursos aos inquilinos. Ao fazer esta análise, considere também o modelo que escolhe para a sua infraestrutura de mensagens e eventos. As secções seguintes descrevem as decisões-chave que deve tomar ao planear um sistema de mensagens na sua solução multiinquilino.

Escala

Ao planear infraestrutura de mensagens ou eventos, considere o número de inquilinos, 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, planeie a capacidade e estabeleça a capacidade máxima de processamento do sistema de mensagens. Este planeamento ajuda-o a gerir corretamente o volume esperado de mensagens durante o tráfego regular e de pico.

Quando a sua solução gere muitos inquilinos e tem um sistema de mensagens separado para cada inquilino, aplique uma estratégia de automação consistente. Esta estratégia deve automatizar a implementação, monitorização, alerta e escalabilidade de cada infraestrutura.

Por exemplo, pode implementar um sistema de mensagens para um inquilino durante o processo de provisionamento usando uma ferramenta de infraestrutura como código (IaC) como Terraform, Bicep ou modelos Azure Resource Manager (templates ARM) e um sistema DevOps como Azure DevOps ou GitHub Actions. Para obter mais informações, consulte Abordagens arquitetônicas para a implantação e configuração de soluções multilocatário.

Pode dimensionar o sistema de mensagens com uma capacidade de processamento máxima de mensagens por unidade de tempo. Se o sistema suportar autoscaling dinâmico, pode aumentar ou diminuir automaticamente a sua capacidade com base nas condições de tráfego e métricas para cumprir o acordo de nível de serviço (SLA) esperado.

Previsibilidade e fiabilidade do desempenho

Para apenas alguns locatários, um único sistema de mensagens pode satisfazer os requisitos funcionais de taxa de transferência e reduzir o custo total de propriedade (TCO). Uma aplicação multitenant pode partilhar entidades de mensagens iguais, como filas e tópicos, entre vários clientes. Alternativamente, pode usar um conjunto dedicado de componentes para cada inquilino para aumentar o isolamento dos inquilinos. Mas uma infraestrutura de mensagens partilhada entre vários inquilinos pode expor toda a solução ao problema ruidoso dos vizinhos. A atividade de um inquilino pode perturbar o desempenho e a operacionalidade de outros inquilinos.

Neste caso, deve dimensionar corretamente o sistema de mensagens para suportar a carga de tráfego esperada na hora de pico. Idealmente, o sistema deve suportar o auto-escalonamento, que aumenta dinamicamente para fora quando o tráfego aumenta e reduz para dentro quando o tráfego diminui. Um sistema de mensagens dedicado para cada inquilino também pode mitigar o risco de vizinhos ruidosos, mas gerir muitos sistemas de mensagens aumenta a complexidade da solução.

Uma aplicação multitenant pode usar uma abordagem híbrida. Nesta abordagem, os serviços centrais utilizam o mesmo conjunto de filas e tópicos num único sistema de mensagens partilhado para implementar comunicações internas e assíncronas. Em contraste, outros serviços podem adotar um grupo dedicado de entidades de mensagens ou até um sistema de mensagens dedicado para cada inquilino, para mitigar o problema ruidoso dos vizinhos e garantir o isolamento dos dados.

Complexidade de gestão e operacional

Desde o início, planeie como pretende operar, monitorizar e manter a sua infraestrutura de mensagens e eventos, e como a sua abordagem multitenancy afeta as suas operações e processos. Por exemplo, considere os seguintes fatores:

• Quando partilha um sistema de mensagens entre vários inquilinos, defina como a sua solução recolhe e reporta as métricas de utilização de cada inquilino ou como limita o número de mensagens que cada inquilino pode enviar ou receber.

• Quando os utilizadores precisarem de mudar para outro tipo de serviço de mensagens, uma implementação diferente ou outra região, determine o método para a sua migração.

• Quando o seu sistema de mensagens utiliza uma oferta de plataforma como serviço (PaaS), tenha em conta as seguintes considerações:

  • Personalize o escalão de preços para cada inquilino com base nas características e no nível de isolamento partilhado ou dedicado que o inquilino solicita.

  • Crie identidades geridas específicas para o inquilino e atribuições de funções Azure para atribuir as permissões adequadas apenas às entidades de mensagens que o inquilino deve aceder. Por exemplo, veja Autenticar uma identidade gerida com o Microsoft Entra ID para aceder a recursos do Service Bus.

• Se optar por hospedar o sistema de mensagens que a sua aplicação utiliza num conjunto dedicado de VMs ou contentores (um para cada inquilino), defina como implementar, atualizar, monitorizar e escalar estes 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 partilhada aumenta a probabilidade de problemas como o problema do vizinho ruidoso. Considere cuidadosamente as compensações.

Abordagens e padrões a considerar

Quando planeia uma solução multiinquilino que envolva mensagens, considere o nível de isolamento entre os inquilinos. Reveja as seguintes considerações e observações:

• Chaves de encriptação: Se os inquilinos precisarem da sua própria chave para encriptar e desencriptar mensagens, confirme como o serviço de mensagens suporta o isolamento de chaves. Por exemplo, se usar Service Bus, pode ser necessário criar um namespace Service Bus Premium separado para cada inquilino que precise das suas próprias chaves. Esta separação permite-lhe usar chaves geridas pelo cliente (CMKs).

• Continuidade do negócio: Identifique inquilinos que necessitam de um elevado nível de recuperação e continuidade do negócio. Considere as capacidades de redundância de zonas, geo-redundância e recuperação de desastres geográficos para estes inquilinos, sempre que disponíveis.

• Processamento de trabalhadores: Quando utiliza recursos de fila separados ou um sistema de mensagens dedicado para cada inquilino, pode adotar um conjunto separado de processos de trabalhadores para cada inquilino. Esta abordagem aumenta o nível de isolamento dos dados e reduz a complexidade de gerir múltiplas entidades de mensagens.

  Cada instância do sistema de processamento pode adotar diferentes credenciais, como uma cadeia de ligação, principal de serviço ou identidade gerida, para aceder ao sistema de mensagens dedicado. Esta abordagem melhora a segurança e o isolamento entre os inquilinos, mas aumenta a complexidade da gestão de identidades.

Sistema de mensagens compartilhadas

Pode implementar um sistema de mensagens partilhadas, como um único namespace de Service Bus, e partilhá-lo entre todos os seus inquilinos.

Esta abordagem proporciona a maior densidade de inquilinos à infraestrutura e reduz o TCO global. Muitas vezes reduz a sobrecarga de gestão porque só precisa de gerir e proteger um único sistema ou recurso de mensagens.

Mas quando partilha um recurso ou uma infraestrutura inteira entre vários inquilinos, considere as seguintes limitações:

• Considere as limitações, capacidades de escalabilidade, quotas e limites do recurso. Por exemplo, o número máximo de Event Hubs num único namespace, ou os limites máximos de throughput, poderão eventualmente tornar-se um obstáculo à medida que a sua arquitetura cresce para suportar mais entidades.

• O problema dos vizinhos barulhentos pode tornar-se um fator quando partilhas um recurso entre vários inquilinos, especialmente se tiveres inquilinos ocupados ou inquilinos que geram mais tráfego do que outros. Para mitigar estes efeitos, considere o Padrão de Atraso ou o Padrão de Limitação de Taxa. Por exemplo, pode limitar o número máximo de mensagens que um único inquilino pode enviar ou receber num determinado período de tempo.

• Pode ter dificuldade em monitorizar a atividade e medir o consumo de recursos de um inquilino individual. Alguns serviços, como níveis específicos de Service Bus, cobram pelas operações de mensagens. Quando partilha um namespace entre vários inquilinos, a sua aplicação deve registar o número de operações de mensagens geradas por cada inquilino e os custos de chargeback associados. Outros serviços não fornecem o mesmo nível de detalhe.

Os locatários podem ter requisitos diferentes de segurança, resiliência dentro da região, recuperação de desastres ou localização. Se estes requisitos não corresponderem à configuração do seu sistema de mensagens, pode não os satisfazer apenas com um único recurso.

Utilize o padrão de fragmentação

O padrão de Sharding envolve a implementação de múltiplos sistemas de mensagens, também chamados shards. Cada fragmento contém as entidades de mensagens de um ou mais locatários, como filas e tópicos. Ao contrário dos selos de implantação, os shards não exigem que se duplique 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, pode fragmentar os seus inquilinos em vários sistemas de mensagens com base na sua localização ou requisitos de desempenho, fiabilidade, proteção de dados ou continuidade do negócio.

Quando usas o padrão de Sharding, precisas de usar uma estratégia de sharding para mapear um dado inquilino ao sistema de mensagens que contém as suas filas. A estratégia de pesquisa utiliza um mapa para identificar o sistema de mensagens alvo com base no nome ou ID do inquilino. Vários locatários podem partilhar o mesmo shard, mas as entidades de mensagens utilizadas por um único locatário permanecem dentro de um único shard.

Pode implementar o mapa como um dicionário que liga o nome de cada inquilino ao nome ou referência do seu sistema de mensagens de destino. Pode armazenar o mapa numa cache distribuída a que todas as instâncias de uma aplicação multitenant possam aceder, ou armazená-lo num armazenamento persistente como uma tabela numa base de dados relacional ou conta de armazenamento.

O padrão de Sharding pode escalar para suportar vários inquilinos. Dependendo da tua carga de trabalho, podes atingir uma alta densidade de inquilinos em fragmentos, o que pode reduzir custos. Também pode usar o padrão de Sharding para abordar quotas, limites e restrições de subscrição e serviços do Azure.

Use uma aplicação multiinquilino com um sistema de mensagens dedicado para cada inquilino

Também pode implementar uma única aplicação multitenant que utilize sistemas de mensagens dedicados para cada inquilino. Este modelo de arrendamento inclui alguns componentes partilhados, como recursos computacionais. Provisiona e gere outros serviços utilizando uma abordagem de implementação dedicada e de inquilino único. Por exemplo, pode construir um único nível de aplicação e depois implementar sistemas de mensagens individuais para cada inquilino, como mostrado na ilustração seguinte.

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

Como fornece recursos dedicados para cada inquilino, esta abordagem muitas vezes custa mais do que um modelo de alojamento partilhado. No entanto, também lhe dá uma forma simples de cobrar a cada inquilino pelos recursos que utiliza. Esta abordagem permite alcançar alta densidade para outros serviços, como recursos computacionais, e reduz o custo destes componentes.

Com uma implementação particionada horizontalmente, é necessário um processo automatizado para implementar e gerir os serviços de uma aplicação multiinquilino, especialmente os serviços que um único inquilino utiliza.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

• Paolo Salvatori - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Outros contribuidores:

• Daphne Choong | Arquiteto Sénior de Soluções para Parceiros
• John Downs | Engenheiro de Software Principal, Azure Patterns & Practices
• Clemens Vasters | Arquiteto Principal, Serviços de Mensagens e Padrões
• Arsen Vladimirskiy | Engenheiro Principal de Clientes, FastTrack for Azure

Recursos relacionados

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

• Padrão de verificação de sinistro
• Padrão de consumidores concorrentes
• Padrão de fornecimento de eventos
• Padrão de tubos e filtros
• Padrão Editor-Subscritor
• Padrão de comboio sequencial