Partilhar via

Abordagens arquitetônicas para computação em soluções multilocatárias

A maioria das soluções baseadas na nuvem é composta por recursos de computação. Esses recursos podem incluir camadas da Web e de aplicativos, processadores em lote, trabalhos agendados ou recursos especializados, como GPUs e computação de alto desempenho. As soluções multilocatárias geralmente se beneficiam de recursos de computação compartilhados porque uma maior densidade 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 oferece orientação sobre os principais requisitos e considerações que os arquitetos de soluções devem ter em mente ao planear uma camada de computação multilocação. Esta orientação inclui padrões comuns para aplicar multilocação a serviços de computação e antipadrões a evitar.

Principais considerações e requisitos

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

Escala

Os sistemas devem funcionar adequadamente à medida que a procura muda. À medida que o número de locatários e o tráfego aumentam, talvez seja necessário dimensionar seus recursos para atender à crescente demanda e manter um 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 inquilinos sofrem quando a escala é insuficiente para lidar com a sua carga total. Para obter mais informações, consulte Antipadrão de vizinho barulhento.

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

Problemas de desempenho muitas vezes permanecem indetectados até que uma aplicação 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 usada para dimensionar, normalmente é necessário planejar os gatilhos que fazem com que os componentes sejam dimensionados. 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 os locatários enfrentarem o problema do 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 que usa para atender 100 locatários, conforme for integrando mais locatários, pode planear o dimensionamento para que seus recursos dupliquem para cada 100 locatários extras.

Estado

Os recursos de computação podem ser sem estado ou com estado. Os componentes sem estado não mantêm dados entre solicitações. Do ponto de vista da escalabilidade, os componentes sem estado geralmente são fáceis de escalar porque se pode adicionar rapidamente novos trabalhadores, instâncias ou nós. Os componentes sem estado também podem começar imediatamente a processar solicitações. Caso a sua arquitetura ofereça suporte à reutilização de instâncias, também poderá reatribuir instâncias de um inquilino para outro inquilino.

Os recursos estatais podem ser subdivididos com base no 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 em memória só de leitura e o armazenamento de ficheiros temporários em discos locais.

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

Em aplicativos sensíveis à latência, o custo da hidratação do cache pode se tornar significativo. Uma solução multilocatária pode piorar esse problema se cada locatário exigir que dados diferentes sejam armazenados em cache. Para mitigar 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 para 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 de forma eficaz. No entanto, a afinidade de sessão também complica o dimensionamento e o balanceamento de carga de tráfego entre os trabalhadores. Considere esta compensação cuidadosamente. Para muitas aplicações, a afinidade de sessão não é indispensável.

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, enquanto 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 da aplicação, enquanto você mantém a camada de computação sem estado.

Importante

Evite vazar dados entre locatários ao usar caches na memória ou outros componentes que mantenham o estado. Por exemplo, considere antecipar 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 uma camada de processamento multilocatário, tem várias opções para o isolamento dos 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 enquadre 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 ou políticas de gerenciamento 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 máquina virtual (VM) específica para se adequar à carga de trabalho de um locatário.

Dependendo do modelo de isolamento escolhido, certifique-se de que os dados do locatário permaneçam adequadamente isolados, mesmo se ocorrerem 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. Esse teste ajuda a verificar se sua solução mantém o isolamento adequado do locatário e continua a funcionar sob pressão.

Abordagens e padrões a considerar

Escala automática

Os serviços de computação do Azure fornecem vários recursos que dimensionam cargas de trabalho. Muitos serviços de computação oferecem suporte ao dimensionamento automático, 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. Consulte os seguintes exemplos de serviços ou componentes:

Padrão de selos 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 arquitetônicas 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 locatários para computar a infraestrutura compartilhando os recursos de computação subjacentes. Ao compartilhar recursos de computação, você pode reduzir o custo direto desses recursos. Além disso, seus custos de gerenciamento geralmente são mais baixos porque há menos componentes para gerenciar.

No entanto, a consolidação de recursos de computação aumenta a probabilidade do problema do vizinho barulhento. A carga de trabalho de qualquer locatário pode consumir uma quantidade desproporcional da capacidade de computação disponível. Muitas vezes, você pode reduzir esse risco garantindo que dimensiona 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. Consulte os seguintes exemplos de serviços ou componentes:

  • 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: Implante ambientes compartilhados.

  • AKS: Implante pods partilhados com um aplicativo compatível com multilocação.

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

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 do vizinho barulhento , garantindo que os recursos de computação de 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 um custo mais elevado porque tem-se uma densidade menor de locatários por recurso.

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 físico no nível do host 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 geralmente é mais cara do que usar hosts compartilhados.

Recursos de computação semi-isolados

As abordagens semi-isoladas exigem que você implante aspetos 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 da sua camada de computação porque os planos de App Service representam a unidade de faturamento. Ele também permite que você aplique configurações e políticas distintas para cada aplicativo. No entanto, esta abordagem introduz 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.

AKS, e Kubernetes mais amplamente, fornecem várias opções para multilocação:

  • Namespaces específicos do locatário que podem fornecer isolamento lógico de recursos específicos do locatário, que são implantados em clusters compartilhados e pools de nós

  • Nodos específicos do cliente ou pools de nodos em um cluster compartilhado

  • Pods específicos do arrendatário que podem usar o mesmo grupo de nós

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

Também é importante estar ciente dos componentes compartilhados em um cluster do Kubernetes e 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á enfrentar contenção de um grande número de solicitações entre os locatários.

Antipadrões a evitar

Evite os seguintes antipadrões.

Antipadrão do Vizinho Barulhento

Quando você implanta componentes que os locatários compartilham, o problema do vizinho barulhento é um risco potencial. Certifique-se de incluir a governança e o monitoramento de recursos para reduzir o risco de a atividade de outros locatários afetar a carga de trabalho de computação de um locatário.

Fuga de dados entre inquilinos

As camadas de computação podem estar sujeitas a vazamento de dados entre locatários se não forem tratadas 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 Front-end ocupado

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

Em vez disso, considere o uso de processamento assíncrono usando filas ou outros serviços de mensagens. Essa abordagem também permite que você aplique controles de qualidade de serviço (QOS) para diferentes locatários com base em suas necessidades. 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 maior de recursos dedicados para processar o trabalho a partir de suas mensagens de fila.

Dimensionamento inelástico ou insuficiente

As soluções multilocatárias geralmente estão sujeitas a padrões de escala bursty. Os componentes partilhados são especialmente vulneráveis a este problema porque a potencial para aumento repentino de uso é maior, e o impacto é mais significativo quando há mais locatários com padrões de utilização distintos.

Certifique-se de tirar proveito da elasticidade e da escala da nuvem. Considere se você deve usar o dimensionamento horizontal ou vertical e o dimensionamento automático para lidar automaticamente com picos de carga. Teste sua solução para entender como ela opera sob diferentes níveis de carga. Certifique-se de incluir 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.

Anti-padrão Sem Cache

O antipadrão Sem Cache é quando o desempenho da sua solução é prejudicado porque a camada de aplicativo solicita ou recalcula repetidamente informações que podem ser reutilizadas entre solicitações. Se você tiver dados que podem ser compartilhados, seja entre locatários ou entre usuários dentro de um único locatário, provavelmente vale a pena armazená-los em cache para reduzir a carga em sua camada de back-end ou banco de dados.

Estado desnecessário

A implicação do antipadrão Sem Cache é que você também deve evitar armazenar estado desnecessário em sua camada de computação. Seja explícito sobre onde você mantém o estado e por quê. As camadas de front-end ou aplicativo com monitoração de estado podem reduzir sua capacidade de escala. 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 dos locatários mudam. Você também pode armazenar o estado em um cache externo, como o Azure Managed Redis.

Contribuidores

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

Principais autores:

  • Dixit Arora | Engenheiro Cliente Senior, FastTrack for Azure
  • John Downs | Engenheiro de Software Principal, Azure Patterns & Practices

Outros contribuidores:

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Revise as orientações específicas para os seus serviços de computação.

  • Last updated on