Editar

Compartilhar via


SaaS multilocatário no Azure

Microsoft Entra ID
Serviço de aplicativo do Azure
DNS do Azure
Porta da frente do Azure
AKS (Serviço de Kubernetes do Azure)

Quando você identifica uma parte da solução de software da sua empresa da qual você pode remover a marca e comercializar para outras, isso traz um novo fluxo de receita para uma empresa. No entanto, a configuração da solução para suprir a carga que uma grande quantidade de locatários traz geralmente é um obstáculo desafiador a ser resolvido. Esta solução visita um pacote de tecnologias do Azure que protegem e equilibram o tráfego.

Arquitetura

Diagrama mostrando uma arquitetura SaaS multilocatário configurada no Azure em duas regiões diferentes.

Baixe um Arquivo Visio dessa arquitetura.

Workflow

Um conjunto de tecnologias do Azure protege e balanceia a carga do tráfego.

  1. O Microsoft Azure Front Door lida com algumas tarefas iniciais:

    • Processamento da solicitação inicial

    • Balanceamento de carga entre as regiões

    • Encerramento e descarregamento de SSL (HTTPS)

    • Failover em caso de falha regional

  2. O DNS do Azure gerencia registros DNS e assegura o roteamento para o ponto de extremidade correto do Azure Front Door.

  3. A arquitetura usa o Microsoft Entra ID como provedor de identidade para autenticação.

  4. Uma vez encaminhados para a região apropriada, o Gateway de Aplicativo encaminha e balanceia a carga, direcionando as solicitações para o Serviço de Aplicativo apropriado do Azure.

  5. Para essa arquitetura, usar o Serviço de Aplicativo é o serviço preferencial para:

    • Qualquer aplicativo baseado em HTTP.

    • Serviço de conteúdo da Web.

    • Exposição de APIs RESTful.

    • Implementação da lógica de negócios por trás do aplicativo de front-end.

    Você pode configurar o Serviço de Aplicativo para escalar vertical e horizontalmente de forma automática. Isso torna o Serviço de Aplicativo um bom ajuste para escalar um host de solicitações do locatário controladas por HTTP sob demanda.

  6. Os serviços de camada de acesso a dados também são dimensionados de modo independente com base na carga. Os serviços de dados gerenciam modelos de dados, clientes de conexão e drivers. Os serviços também fornecem uma interface de dados consistente para todos os serviços de nível superior que desejam consumir dados no aplicativo. Você pode implantar e escalar esses serviços de dados usando o AKS (Serviço de Kubernetes do Azure). Cada cluster do AKS é responsável por um conjunto de recursos relacionados na camada. O AKS pode implementar uma arquitetura de microsserviço, que apresenta uma série de contêineres que encapsulam cada funcionalidade específica dentro do cluster. Isso permite um alto grau de abstração e desacoplamento no código. Ele também permite que os clusters escalem horizontalmente de forma individual a fim de suprir o aumento da carga de vários locatários. Cada cluster pode escalar verticalmente seus recursos se a carga aumentar no cluster. A escala vertical não afeta os outros clusters no grupo de recursos, desde que eles não estejam experimentando o mesmo aumento.

  7. Armazene e gerencie dados relacionais fora da estrutura do aplicativo. Isso fornece um único ponto de entrada de dados para qualquer região. Você pode obter replicação, disponibilidade, escalabilidade e segurança aproveitando os pontos fortes dos Pools Elásticos do SQL do Azure. Provisione um banco de dados em um pool para cada locatário. Aloque os recursos disponíveis no pool para bancos de dados sob demanda conforme a carga e as solicitações chegam. Isso otimiza os recursos de banco de dados disponíveis para locatários em seu orçamento.

Componentes

Os componentes primários são os componentes sugeridos para a arquitetura nesta solução. Se qualquer um dos componentes primários não se ajustar à sua arquitetura, consulte a lista de componentes alternativos.

Componentes primários

  • Azure Front Door: um balanceador de carga regional que encaminha o tráfego do cliente para a região correta. Ele poderá fazer failover para a segunda região se ocorrer uma falha regional e proteger o ponto de entrada voltado para a Internet por meio do Firewall de Aplicativo Web do Azure.

  • Microsoft Entra ID: atua como provedor de identidade para todo o aplicativo, aplicando autenticação e autorização de ponta a ponta da solicitação no aplicativo.

  • DNS do Azure: um serviço de hospedagem no Azure para resolução de nomes de domínio. Em uma solução multilocatário, vários clientes acessam a solução por meio de seus próprios domínios individuais. Use o DNS do Azure para configurar e resolver solicitações de cliente para sua pilha de aplicativos correta.

  • Gateway de Aplicativo: roteia e balanceia a carga do tráfego internamente no aplicativo para os vários serviços que atendem às necessidades de negócios do cliente. Embora o Azure Front Door balanceie a carga entre regiões de alto nível, é o Gateway de Aplicativo que tem reconhecimento da carga em serviços individuais dentro de um grupo. O Azure Front Door e o Gateway de Aplicativo são combinados a fim de fornecer balanceamento de carga complexo em todos os níveis em uma solução multilocatário. Para obter mais informações sobre opções de balanceamento de carga no Azure, visite esta visão geral sobre o balanceamento de carga do Azure.

  • Serviço de Aplicativo: serviço premier do Azure para aplicativos Web e APIs baseadas na Web. A segurança se integra a serviços como o Microsoft Entra ID e o Azure Key Vault. Você pode configurar o dimensionamento automático. Além disso, a quantidade de recursos disponíveis para os quais dimensionar é flexível entre os vários planos do Serviço de Aplicativo em que o aplicativo pode ser executado. O Serviço de Aplicativo também pode aproveitar as funcionalidades DevOps integração contínua e implantação em vários ambientes. Esses e outros recursos de suporte da plataforma Azure permitem que os desenvolvedores se concentrem no desenvolvimento de seus aplicativos.

  • Serviço Azure Kubernetes: orquestra instâncias de imagens de contêiner implantadas em um cluster. O gerenciamento de dados de vários clientes geralmente envolve a implementação de um conjunto de componentes para gerenciar:

    • Modelagem de dados

    • Conectividade da fonte de dados

    • ETL (extração, transformação, carregamento)

    • Atividades de importação/exportação

    Desenvolver esses muitos componentes menores como microsserviços baseados em contêiner cria um cenário ideal para a implantação em um cluster do AKS. Ferramentas para dimensionamento automático, balanceamento de carga e a capacidade de atualização são integradas à estrutura. O AKS se integra bem a uma estratégia de CI/CD (integração contínua/entrega contínua) usando os recursos do DevOps e o Registro de Contêiner do Azure.

  • Pools Elásticos do SQL do Azure: fornece uma solução para gerenciar um conjunto de bancos de dados de forma flexível com um pool de recursos. O serviço aloca recursos sob demanda para os bancos de dados. Ele fornece ao desenvolvedor de uma arquitetura de SaaS multilocatário o poder de fornecer recursos de banco de dados aos clientes conforme necessário. O serviço também reduz o orçamento e a sobrecarga de manter vários servidores SQL com grandes partes de recursos de computação não utilizados.

  • Azure Cognitive Search (anteriormente conhecido como Azure Search): um serviço que adiciona um mecanismo eficiente de indexação e consulta ao seu aplicativo. Ele fornece aos clientes acesso a uma funcionalidade de consulta forte. Eles também podem usar os recursos de IA do Azure para enriquecer e aprimorar a funcionalidade de consulta. O Azure Cognitive Search pode suprir a multilocação usando uma estratégia de índice por locatário ou serviço por locatário.

  • Cache do Azure para Redis: aplica uma camada de cache como serviço à solução, fornecendo um cache gerenciado na memória para reduzir a latência e aumentar o desempenho dos clientes. A alta taxa de transferência permite que um alto volume de solicitações manipule vários locatários que acessam o sistema. Você pode escalar verticalmente o serviço de forma flexível à medida que as cargas de aplicativo aumentam. Ele também dá suporte à criptografia inativa para proteger e isolar dados de locatário armazenados em cache.

Componentes alternativos

  • Conjuntos de Dimensionamento de Máquinas Virtuais do Azure: permitem a implantação de serviços em um ambiente de máquina virtual (VM) que é dimensionado e aumentam automaticamente conforme a necessidade. Os Conjuntos de Dimensionamento de Máquinas Virtuais se integram bem a um Balanceador de Carga ou Gateway de Aplicativo para reequilibrar automaticamente a carga conforme o conjunto de dimensionamento aumenta. Os Conjuntos de Dimensionamento de Máquinas Virtuais proporcionam a escalabilidade que essa solução exige. No entanto, em muitos casos, é desnecessário gerenciar todo o ambiente de VMs e podemos adiar esse nível da pilha para o Serviço de Aplicativo ou o AKS.

  • Banco de Dados SQL do Azure: implemente como instâncias dedicadas individuais como uma substituição para Pools Elásticos. Usar o Banco de Dados SQL do Azure aumenta a sobrecarga no gerenciamento da instância diretamente e incorre em mais custos para recursos alocados. Dito isso, é uma alternativa aceitável quando o locatário requer um servidor dedicado. Particularmente, o cliente pode exigir mais controle sobre a instância e os recursos disponíveis dedicados. Locatários que exigem um SQL Server dedicado podem existir lado a lado com locatários em uma configuração de Pool Elástico. Você pode tornar uma camada de bancos de dados SQL uma das opções de preço disponíveis para locatários ao comprar licenças para o SaaS.

  • SQL Server em Máquinas Virtuais: outra opção para a implantação de bancos de dados SQL. O locatário pode ter uma infraestrutura de TI pré-existente e servidores SQL existentes no local. Nesse caso, o locatário deve usar suas licenças atuais, seja como migração completa ou em um cenário híbrido. A natureza desacoplada do SaaS permite que a camada de dados do aplicativo seja destinada a qualquer Banco de Dados SQL por meio de configuração.

Detalhes do cenário

Quando você identifica uma parte da solução de software da sua empresa da qual você pode remover a marca e comercializar para outras, isso traz um novo fluxo de receita para uma empresa. No entanto, a configuração da solução para suprir a carga que uma grande quantidade de locatários traz geralmente é um obstáculo desafiador a ser resolvido.

O Azure oferece uma variedade de serviços para gerenciar uma solução de software que:

  • A flexibilidade mantém bancos de dados para todos os clientes.

  • Dimensiona a camada de negócios e lógica da solução para evitar gargalos na camada de computação.

  • Integra disponibilidade e failover regional.

  • Fornece segurança de ponta a ponta em todos os níveis da solução.

Possíveis casos de uso

Esses casos de uso têm padrões de design que podem se beneficiar de uma solução de SaaS multilocatário hospedada no Azure:

  • Desenvolva uma solução de CRM (gerenciamento de relacionamentos com o cliente) que os clientes possam comercializar e vender aos clientes.

  • Implemente um sistema CMS (sistema de gerenciamento de conteúdo) e entregue-o a vários usuários usando essa arquitetura.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Multilocação

Uma solução multilocatário é a principal consideração nesta solução. A solução lida com vários clientes simultaneamente. Ela também aloca recursos suficientes para processar todas as solicitações de cliente com eficiência. Durante o processamento de solicitações, a solução protege o tráfego de pontos de extremidade globais e isola os dados do cliente para evitar violações e contaminação cruzada. Implante clientes em um par de grupos de recursos regionais com base em seu local primário. Isso otimiza a disponibilidade regional.

Você pode implantar muitos clientes em um único grupo de computação porque o sistema isola as solicitações com base nas chaves de autenticação e de cliente, que diferenciam as solicitações com base nesses identificadores exclusivos. O sistema pode criptografar todas as solicitações de cliente separadamente pelas chaves, de modo que nenhum cliente possa descriptografar os dados de nenhum outro cliente. O gerenciamento de vários clientes em uma única pilha de computação oferece a capacidade de otimizar a alocação de recursos para fornecer aos clientes a capacidade de resposta de que precisam ao custo.

Você gerencia os bancos de dados cliente de maneira semelhante fora da pilha de computação porque uma solicitação de cliente pode chegar de qualquer uma das pilhas regionais. Muitos bancos de dados de clientes podem existir no mesmo Pool Elástico, isolados e protegidos pela TDE (criptografia de dados transparente). Você pode configurar cada banco de dados para criptografar os dados usando uma chave gerenciada pelo cliente e descriptografar os dados just-in-time (JIT). Descriptografar JIT protege os dados do cliente tanto do desenvolvedor e como de outros clientes. O sistema aproveita o Pool Elástico para fornecer recursos sob demanda aos clientes atribuídos a ele e manter os custos baixos para você. Você pode atribuir políticas de replicação a cada Pool Elástico para fornecer backup e failover para dados do cliente. Coloque mais Pools Elásticos online conforme integra mais clientes ao sistema.

Para obter mais informações sobre soluções multilocatário, consulte Projetar soluções multilocatário no Azure.

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.

Escalabilidade e disponibilidade

Esta solução foi projetada para suprir um grande número de locatários usando o SaaS. Ele aproveita o grande número de componentes e serviços escalonáveis para crescer com base na carga. Essa arquitetura não foi projetada para soluções atendem a alguns locatários ou uma pequena carga de solicitações e dados. Isso pode sobrecarregar o orçamento de uma solução cujo alvo é um único cliente ou uma carga menor. Também é desnecessário ter a sobrecarga de várias regiões em que a alta disponibilidade global não é um requisito, porque isso traz complexidade e custos desnecessários.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para mais informações, consulte Visão geral do pilar de segurança.

O sistema aborda a segurança de ponta a ponta em cada nível do aplicativo:

  • O Azure Front Door fornece suporte a HTTPS integrado para seus domínios. Isso significa que o sistema pode criptografar todo o tráfego para o aplicativo SaaS. O Azure Front Door também implementa o Firewall de Aplicativo Web do Azure, protegendo a pilha de SaaS contra ataques na borda, antes que o sistema encaminhe solicitações para o aplicativo.

  • Cada pilha de aplicativos em cada região está dentro de uma Rede Virtual do Azure. O sistema restringe o tráfego para a rede virtual aceitando solicitações do Azure Front Door, protegendo todos os serviços de aplicativo contra tráfego externo. Uma vez dentro do firewall seguro, o Gateway de Aplicativo pode encerrar o SSL e fornecer balanceamento de carga e roteamento de desempenho dentro do aplicativo.

  • Você pode gerenciar com segurança todas as credenciais, segredos e cadeias de conexão usando o Azure Key Vault. Ao gerenciar esses dados confidenciais como segredos, os desenvolvedores podem injetar credenciais no aplicativo no momento da implantação. Isso garante que o código não seja poluído com informações confidenciais. O uso de segredos protege os dados do cliente, garantindo que uma violação no código ou ataque man-in-the-middle não obtenha acesso aos bancos de dados de locatário.

  • Nesse cenário, os dados de vários locatários podem existir lado a lado no mesmo servidor de banco de dados, se não no mesmo banco de dados. Usar a descriptografia TDE e JIT protege os dados no banco de dados. O sistema criptografa todos os dados no banco de dados inativos e apenas os descriptografa quando solicitado pelo locatário. Os clientes podem fornecer suas próprias chaves e você pode armazenar todas as chaves de cliente Azure Key Vault para gerenciar a criptografia para vários locatários. Isso protege os dados do cliente de ponta a ponta, impede que o desenvolvedor tenha acesso aos dados de cliente, isola os dados entre locatários e ajuda a atender aos requisitos de conformidade para segurança e dados.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

O Serviço de Aplicativo do Azure fornece muitas camadas de preço com base nos recursos de computação esperados necessários. Para um SaaS multilocatário, os recursos de alta disponibilidade e expansão são os principais componentes na escolha do plano de serviço. Se você espera hospedar muitos locatários, a escolha de uma camada premium ou isolada pode ser necessária para fornecer os recursos de computação necessários para dar conta do alto volume de tráfego. As camadas padrão, premium e isolada são todas instâncias de VM dedicadas. Você pode calcular o custo por unidade de tempo com base na quantidade de VMs dessa camada que você especificou. Para obter mais informações, visite a visão geral dos planos de preços do Serviço de Aplicativo.

O AKS fornece um serviço de contêiner econômico. Os encargos para nós do AKS ocorrem somente no uso e, portanto, você só é cobrado por:

  • VMs

  • Armazenamento consumido e recursos de rede

  • Custo de escala diretamente relacionado ao uso

Usar o AKS como serviço de camada de dados é o ideal se você deseja reduzir custos. Para uma estimativa sobre como calcular o preço de uma camada de instâncias do AKS, visite a calculadora de serviço do Kubernetes.

Por design, o preço do Pool Elástico do SQL do Azure é altamente econômico em um cenário multilocatário. Os bancos de dados de locatário no Pool Elástico compartilharão os recursos disponíveis. À medida que a demanda muda entre locatários ao longo do tempo, os recursos também mudarão. O Pool Elástico do SQL do Azure fornece o máximo de recursos disponíveis para bancos de dados exigidos sem a necessidade de sobrecarga de recursos em todos os bancos de dados. O serviço mantém o custo baixo para o desenvolvedor do SaaS e os locatários. Use a calculadora de preços do Banco de Dados SQL do Azure para calcular o preço e determinar a camada e a quantidade de recursos necessários para atender os locatários e seus dados.

  • O uso de um modelo de preços de núcleo virtual (vCore) oferece maior flexibilidade no escala para atender aos recursos necessários. Além disso, você pode aproveitar o Benefício Híbrido do Azure. As licenças do SQL Server existentes dão um desconto para recursos do SQL do vCore na nuvem. Portanto, em uma instância em que os servidores locais já fazem parte da infraestrutura do desenvolvedor, é possível gerenciar ainda mais o custo usando esses descontos. Você pode estimar as possíveis economias usando a calculadora de economia do Benefício Híbrido do Azure.

  • Você também pode economizar em custo nos recursos do SQL Server comprando capacidade reservada do Banco de Dados SQL do Azure. Comprar capacidade reservada marca um compromisso de uso de longo prazo do Banco de Dados SQL. O prazo geralmente é de um e três anos. Em troca, você obterá descontos nos custos de computação dos recursos na reserva. Por exemplo, você pode reservar 32 vCores de uso geral por um ano, o que reduz o custo desses 32 vCores para esse ano. Quando diversos locatários compram licenças para um SaaS isso é um forte indicador de que o uso da capacidade reservada se ajusta à solução e uma economia de custo ideal nessa carga de trabalho.

Você pode encontrar a estrutura de preços do Cache do Azure para Redis na página Preços do Cache do Azure para Redis. Ajuste a camada de cache a qualquer momento entre uma camada Básica, Standard e Premium com base na necessidade. Você verá preços mais altos nos maiores limites de cache e recursos adicionais, como replicação e recuperação de desastre. O Cache do Azure para Redis também oferece preços de capacidade reservada para compromissos de uso de longo prazo.

O preço do Azure Front Door depende da quantidade de transferência de dados de entrada e de saída do serviço. Para dados de saída, o preço é diferente dependendo das zonas. Regiões diferentes incorrerão em custos diferentes. Se você encontrar um diferencial de preço, estime o custo separadamente. O preço inclui roteamento e capacidade de domínio, mas o sistema incorre em custos além dos limites iniciais. O Firewall de Aplicativo Web do Azure incorre em uma pequena taxa adicional por política ou regra aplicada. Você pode encontrar os detalhes de preços do Azure Front Door na página preços do Azure Front Door.

O preço do Azure Cognitive Search é um sistema totalmente em camadas. Uma camada gratuita está disponível para desenvolvimento e teste. Depois disso, cada camada incorre em um custo por hora para cada instância alocada do Cognitive Search. À medida que as camadas aumentam, o armazenamento total, o número de índices e os limites de expansão também aumentam. O Azure Cognitive Search oferece extração de imagem como um serviço na mesma taxa para todas as camadas pagas.

Próximas etapas