Compartilhar via

Abordagens de arquitetura para computação em soluções de multilocatário

A maioria das soluções baseadas em nuvem é composta por recursos de computação. Esses recursos podem incluir camadas web e de aplicativo, processadores em lotes, trabalhos agendados ou recursos especializados, como GPUs e computação de alto desempenho. As soluções multilocatários geralmente se beneficiam de recursos de computação compartilhados porque uma densidade maior de locatários para cada infraestrutura reduz os custos operacionais e simplifica o gerenciamento. Você deve considerar os requisitos de isolamento e as implicações da infraestrutura compartilhada.

Este artigo fornece diretrizes sobre considerações e requisitos cruciais a serem considerados pelos arquitetos de soluções ao planejarem uma camada de computação multitenant. Essas diretrizes incluem padrões comuns para aplicar multitenancy a serviços de computação e antipadrões que devem ser evitados.

Considerações e requisitos

Tanto a multilocação quanto o modelo de isolamento que você escolher afetam o dimensionamento, o desempenho, o gerenciamento de estado e a segurança dos seus recursos de computação. As seções a seguir revisam as principais decisões que você deve tomar ao planejar uma solução de computação multilocatário.

Escala

Os sistemas devem ser executados adequadamente conforme a demanda muda. À medida que o número de locatários e tráfego aumenta, talvez seja necessário dimensionar seus recursos para corresponder à demanda crescente e manter o desempenho aceitável. Da mesma forma, quando o número de usuários ativos ou a quantidade de tráfego diminui, você deve reduzir automaticamente a capacidade de computação para reduzir os custos. No entanto, você deve minimizar qualquer interrupção para os usuários ao ajustar a capacidade.

Se você implantar recursos dedicados para cada locatário, terá a flexibilidade de dimensionar os recursos de cada locatário de forma independente. Em uma solução em que os recursos de computação são compartilhados entre vários locatários, o dimensionamento desses recursos permite que todos os locatários se beneficiem do aumento da capacidade. No entanto, todos os locatários sofrerão quando a balança for insuficiente para lidar com sua carga geral. Para obter mais informações, consulte o Antipadrão Vizinho Barulhento.

Ao criar soluções de nuvem, você pode escolher se deseja dimensionar horizontal ou verticalmente. Em uma solução multilocatário que tem um número crescente de locatários, dimensionar horizontalmente geralmente proporciona maior flexibilidade e um teto de escala geral maior.

Os problemas de desempenho geralmente permanecem não detectados até que um aplicativo esteja sob carga. Você pode usar um serviço totalmente gerenciado, como o Teste de Carga do Azure, para saber como seu aplicativo opera sob estresse.

Gatilhos de escala

Independentemente da abordagem que você usa para dimensionar, normalmente você precisa planejar os gatilhos que fazem seus componentes dimensionar. Quando você tiver componentes compartilhados, considere os padrões de carga de trabalho de cada locatário para garantir que sua capacidade provisionada atenda à demanda total necessária. Essa abordagem ajuda a evitar a contenção de recursos e reduz a probabilidade de locatários apresentarem o problema de vizinho barulhento. Você também pode planejar sua capacidade de dimensionamento considerando o número de locatários. Por exemplo, se você medir os recursos usados para atender a 100 locatários, à medida que adicionar mais locatários, poderá planejar a escala de forma que os recursos disponíveis dobrem para cada 100 locatários extras.

Estado

Os recursos de computação podem ser sem estado ou com estado. Componentes sem estado não mantêm dados entre solicitações. Do ponto de vista da escalabilidade, componentes sem estado geralmente são fáceis de escalar, pois é possível adicionar rapidamente novos trabalhadores, instâncias ou nós. Componentes sem estado também podem começar imediatamente a processar solicitações. Se sua arquitetura der suporte à reutilização de instâncias, você também poderá reatribuir instâncias de um cliente para outro.

Os recursos com estado podem ser subdivididos ainda mais, de acordo com o tipo de estado que mantêm. Estado persistente são dados que precisam ser armazenados permanentemente. Em soluções de nuvem, evite armazenar um estado persistente em sua camada de computação. Em vez disso, use serviços de armazenamento, como bancos de dados ou contas de armazenamento. Estado transitório são dados armazenados temporariamente. Inclui caches só de leitura na memória e o armazenamento de arquivos temporários em discos locais.

O estado transitório geralmente é útil para melhorar o desempenho da camada de aplicativo, reduzindo o número de solicitações para serviços de armazenamento de back-end. Por exemplo, quando você usa um cache na memória, pode ser capaz de atender solicitações de leitura sem se conectar a um banco de dados e sem executar uma consulta intensiva executada recentemente quando tiver atendido outra solicitação.

Em aplicativos sensíveis à latência, o custo da hidratação do cache pode se tornar significativo. Uma solução multilocatário pode piorar esse problema se cada locatário exigir que dados diferentes sejam armazenados em cache. Para atenuar esse problema, algumas soluções aplicam afinidade de sessão. Essa abordagem garante que o mesmo nó de trabalho de computação processe todas as solicitações de um usuário ou locatário específico. A afinidade de sessão pode melhorar a capacidade da camada de aplicativo de usar seu cache efetivamente. No entanto, a afinidade de sessão também complica o dimensionamento e o balanceamento de carga de tráfego entre os trabalhadores. Considere essa troca com cuidado. Para muitos aplicativos, a afinidade de sessão não é necessária.

Também é possível armazenar dados em caches externos, como o Azure Managed Redis. Os caches externos são otimizados para recuperação de dados de baixa latência, ao mesmo tempo em que isolam o estado dos recursos de computação para que possam ser dimensionados e gerenciados separadamente. Em muitas soluções, os caches externos permitem melhorar o desempenho do aplicativo, enquanto você mantém a camada de computação sem estado.

Importante

Evite o vazamento de dados entre locatários quando você usa caches na memória ou outros componentes que mantêm o estado. Por exemplo, considere anexar um identificador de locatário a todas as chaves de cache para garantir que os dados sejam separados para cada locatário.

Isolamento

Ao projetar um nível de computação multilocatário, você tem várias opções para isolamento de inquilinos. Você pode implantar recursos de computação compartilhados para todos os locatários, recursos de computação dedicados para locatários individuais ou uma abordagem semi-isolada que se enquadra entre esses extremos. Cada opção tem compensações. Para ajudá-lo a decidir qual opção melhor se adapta à sua solução, considere seus requisitos de isolamento.

Você pode estar preocupado com o isolamento lógico dos locatários e como separar as responsabilidades de gerenciamento ou as políticas que são aplicadas a cada locatário. Como alternativa, talvez seja necessário implantar configurações de recursos distintas para locatários específicos, como implantar uma SKU de VM (máquina virtual) específica para atender à carga de trabalho de um locatário.

Dependendo do modelo de isolamento escolhido, verifique se os dados do locatário permanecem isolados corretamente, mesmo que ocorram falhas ou interrupções de componentes. Considere usar o Azure Chaos Studio em seu processo de teste automatizado regular para introduzir falhas que simulam interrupções do mundo real. Este teste ajuda a verificar se sua solução mantém o isolamento entre locatários adequado e continua funcionando sob pressão.

Abordagens e padrões a serem considerados

Dimensionamento automático

Os serviços de computação do Azure fornecem vários recursos que dimensionam cargas de trabalho. Muitos serviços de computação dão suporte ao dimensionamento automático, o que exige que você determine quando dimensionar e definir níveis mínimos e máximos de escala. As opções de dimensionamento específicas dependem dos serviços de computação que você usa. Confira os seguintes componentes ou serviços de exemplo:

Padrão de Carimbos de Implantação

Para obter mais informações sobre como você pode usar o padrão Selos de Implantação para dar suporte a uma solução multilocatário, consulte Abordagens de arquitetura para uma solução multilocatário.

Padrão de consolidação de recursos de computação

O padrão de Consolidação de Recursos de Computação ajuda você a obter uma maior densidade de inquilinos na infraestrutura de computação ao compartilhar os recursos de computação subjacentes. Ao compartilhar recursos de computação, você pode reduzir o custo direto desses recursos. Além disso, os custos de gerenciamento geralmente são menores porque há menos componentes a serem gerenciados.

No entanto, a consolidação de recursos de computação aumenta a probabilidade do problema de vizinho barulhento. A carga de trabalho de qualquer locatário pode consumir uma quantidade desproporcional da capacidade de computação disponível. Geralmente, você pode reduzir esse risco garantindo que dimensione sua solução adequadamente e aplicando controles como cotas e limites de API para evitar locatários que consomem mais do que sua parte justa da capacidade.

Esse padrão é alcançado de maneiras diferentes, dependendo do serviço de computação que você usa. Confira os seguintes componentes ou serviços de exemplo:

  • Serviço de Aplicativo e Azure Functions: Implante planos compartilhados do Serviço de Aplicativo, que representam a infraestrutura do servidor de hospedagem.

  • Aplicativos de contêiner: Implantar ambientes compartilhados.

  • AKS: implante pods compartilhados com um aplicativo com reconhecimento multilocatário.

  • VMs: Implante um único conjunto de VMs para uso de todos os locatários.

Recursos de computação dedicados para cada locatário

Você também pode implantar recursos de computação dedicados para cada locatário. Os recursos dedicados reduzem o risco do problema de vizinho barulhento , garantindo que os recursos de computação para cada locatário sejam isolados dos outros. Ele também permite que você implante uma configuração distinta para os recursos de cada locatário com base em seus requisitos. No entanto, os recursos dedicados normalmente têm custos mais altos, pois você tem uma densidade menor de locatários para recursos.

Dependendo dos serviços de computação do Azure que você usa, talvez seja necessário implantar diferentes recursos dedicados:

  • Serviço de Aplicativo e Azure Functions: Implante planos separados do Serviço de Aplicativo para cada locatário.

  • Aplicativos de contêiner: Implante ambientes separados para cada locatário.

  • AKS: Implante clusters dedicados para cada locatário.

  • Vms: Implante VMs dedicadas para cada locatário.

O isolamento no nível do host físico também pode ser fornecido executando VMs de locatário em hosts dedicados do Azure, que reservam um servidor físico inteiro para um único cliente. No entanto, essa abordagem normalmente é mais cara do que usar hosts compartilhados.

Recursos de computação semi-isolados

Abordagens semi-isoladas exigem que você implante aspectos da solução em uma configuração isolada enquanto compartilha os outros componentes.

Ao usar o Serviço de Aplicativo e o Azure Functions, você pode implantar aplicativos distintos para cada locatário e hospedar os aplicativos em planos compartilhados do Serviço de Aplicativo. Essa abordagem reduz o custo de sua camada de computação, pois os planos do Serviço de Aplicativo representam a unidade de cobrança. Ele também permite que você aplique configurações e políticas distintas a cada aplicativo. No entanto, essa abordagem apresenta o risco do problema do vizinho barulhento.

Você pode usar Aplicativos de Contêiner para implantar vários aplicativos em um ambiente compartilhado e, em seguida, usar o Dapr e outras ferramentas para configurar cada aplicativo separadamente.

O AKS e o Kubernetes de forma mais ampla fornecem várias opções para multilocatário:

  • Namespaces específicos do inquilino que podem fornecer isolamento lógico de recursos específicos do inquilino, implantados em clusters compartilhados e pools de nós.

  • Nós ou pools de nós específicos para o locatário em um cluster compartilhado

  • Pods específicos por locatário que podem usar o mesmo conjunto de nós

Você também pode usar o AKS para aplicar a governança no nível do pod para atenuar o problema de vizinho barulhento. Para obter mais informações, consulte As práticas recomendadas para os desenvolvedores de aplicativos gerenciarem recursos no AKS.

Também é importante estar ciente dos componentes compartilhados em um cluster do Kubernetes e de como a multilocação pode afetar esses componentes. Por exemplo, o servidor de API do Kubernetes é um serviço compartilhado usado em todo o cluster. Mesmo que você forneça pools de nós específicos do locatário para isolar as cargas de trabalho do aplicativo dos locatários, o servidor de API poderá sofrer contenção de um grande número de solicitações entre os locatários.

Antipadrões a serem evitados

Evite os antipadrões a seguir.

Antipadrão de Vizinho Barulhento

Quando você implanta componentes que os locatários compartilham, o problema de vizinho barulhento é um risco potencial. Inclua a governança de recursos e o monitoramento para reduzir o risco de atividades de outros locatários que afetam a carga de trabalho de computação de um locatário.

Vazamento de dados entre locatários

As camadas de computação podem estar sujeitas a vazamento de dados entre inquilinos se não forem gerenciadas corretamente. Esse risco geralmente não é algo que você precisa considerar ao usar um serviço multilocatário no Azure porque a Microsoft fornece proteções na camada de plataforma. No entanto, ao desenvolver seu próprio aplicativo multilocatário, considere se quaisquer recursos compartilhados, como caches de disco local, RAM e caches externos, podem conter dados que outro locatário pode exibir ou modificar acidentalmente.

Antipadrão do front-end ocupado

Para evitar o padrão indesejado de sobrecarga no front-end, certifique-se de que a camada de front-end não realiza a maior parte do trabalho que outros componentes ou camadas de sua arquitetura podem manejar. Esse antipadrão é especialmente importante quando você cria front-ends compartilhados para uma solução multilocatário porque um front-end ocupado degrada a experiência de todos os locatários.

Em vez disso, considere usar o processamento assíncrono usando filas ou outros serviços de mensagens. Essa abordagem também permite que você aplique controles de QOS (qualidade de serviço) para locatários diferentes com base em seus requisitos. Por exemplo, todos os locatários podem compartilhar uma camada de front-end comum, mas os locatários que pagam por um nível de serviço mais alto podem ter um conjunto mais alto de recursos dedicados para processar o trabalho de suas mensagens de fila.

Dimensionamento inelástico ou insuficiente

As soluções multilocatárias geralmente estão sujeitas a padrões de escala intermitentes. Os componentes compartilhados são especialmente vulneráveis a esse problema porque o escopo para intermitência é maior e o efeito é maior quando você tem mais locatários que têm padrões de uso distintos.

Certifique-se de aproveitar a elasticidade e a escala da nuvem. Considere se você deve usar o dimensionamento horizontal ou vertical e usar o dimensionamento automático para lidar automaticamente com picos de carga. Teste sua solução para entender como ela opera em diferentes níveis de carga. Inclua os volumes de carga esperados na produção e o crescimento esperado. Você pode usar um serviço totalmente gerenciado, como o Teste de Carga, para saber como seu aplicativo opera sob estresse.

Nenhum antipadrão de cache

O antipadrão sem cache ocorre quando o desempenho da sua solução sofre porque a camada de aplicação solicita ou recomputa repetidamente informações que podem ser reutilizadas entre solicitações. Se você tiver dados que podem ser compartilhados, entre locatários ou entre usuários em um único locatário, provavelmente vale a pena armaixá-los em cache para reduzir a carga em sua camada de back-end ou de banco de dados.

Estado desnecessário

A implicação do antipadrão Sem Cache é que você também deve evitar armazenar o estado desnecessário em sua camada de computação. Explicite onde você manterá o estado e por quê. As camadas de aplicativos ou front-end com estado podem reduzir sua capacidade de dimensionamento. As camadas de computação com estado normalmente também exigem afinidade de sessão, o que pode reduzir sua capacidade de balancear efetivamente a carga do tráfego entre trabalhadores ou nós.

Considere as compensações para cada parte do estado que você mantém em sua camada de computação e se isso afeta sua capacidade de dimensionar ou crescer à medida que os padrões de carga de trabalho de seus locatários mudam. Você também pode armazenar o estado em um cache externo, como o Redis Gerenciado do Azure.

Contribuidores

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

Autores principais:

  • Dixit Arora | Engenheiro sênior de clientes, FastTrack para Azure
  • John Downs | Principal Engenheiro de Software, Padrões do Azure & Práticas

Outros colaboradores:

  • Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

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

Examine as diretrizes específicas do serviço para seus serviços de computação:

  • Last updated on