Editar

Partilhar via

Antipadrão de vizinho barulhento

Azure

Os sistemas multilocatários compartilham recursos entre locatários. Como os locatários usam os mesmos recursos compartilhados, a atividade de um locatário pode ter um impacto negativo no uso do sistema por outro locatário.

Descrição do problema

Ao criar um serviço para ser compartilhado por vários clientes ou locatários, você pode criá-lo para ser multilocatário. Um benefício dos sistemas multilocatários é que os recursos podem ser agrupados e compartilhados entre os locatários. Isso geralmente resulta em custos mais baixos e maior eficiência. No entanto, se um único locatário usar uma quantidade desproporcional dos recursos disponíveis no sistema, o desempenho geral do sistema pode ser prejudicado. O problema do vizinho barulhento ocorre quando o desempenho de um inquilino é degradado devido às atividades de outro inquilino.

Considere um exemplo de sistema multilocatário com dois locatários. Os padrões de uso do locatário A e os padrões de uso do locatário B coincidem, o que significa que, nos horários de pico, o uso total de recursos é maior do que a capacidade do sistema:

Figura mostrando o uso de recursos de dois locatários. O locatário A consome o conjunto completo de recursos do sistema, o que significa que o locatário B enfrenta falhas.

É provável que qualquer pedido do inquilino que chegue primeiro tenha precedência. Em seguida, o outro inquilino experimentará um problema de vizinho barulhento. Alternativamente, ambos os inquilinos podem ver o seu desempenho prejudicado.

O problema do vizinho barulhento também ocorre mesmo quando cada locatário individual está consumindo quantidades relativamente pequenas da capacidade do sistema, mas o uso coletivo de recursos de muitos locatários resulta em um pico no uso geral:

Figura com 3 locatários, cada um consumindo menos a taxa de transferência máxima da solução. No total, os três locatários consomem todos os recursos do sistema.

Isso pode acontecer quando você tem vários locatários que têm padrões de uso semelhantes ou quando você não provisionou capacidade suficiente para a carga coletiva no sistema.

Como resolver o problema

Problemas de vizinhos barulhentos são um risco inerente em sistemas multilocatário, e não é possível eliminar completamente a possibilidade de ser afetado por um vizinho barulhento. No entanto, existem algumas medidas que tanto os clientes quanto os provedores de serviços podem tomar para reduzir a probabilidade de problemas de vizinhos barulhentos ou para mitigar seus efeitos quando observados.

Ações que os clientes podem tomar

Ações que os prestadores de serviços podem tomar

  • Monitore o uso de recursos para o seu sistema. Monitore o uso geral de recursos e os recursos que cada locatário usa. Configure alertas para detetar picos no uso de recursos e, se possível, configure a automação para mitigar automaticamente problemas conhecidos, aumentando ou diminuindo a escala.
  • Aplique a governança de recursos. Considere a aplicação de políticas que evitem que um único locatário sobrecarregue o sistema e reduza a capacidade disponível para outros. Esta etapa pode assumir a forma de imposição de cotas, por meio do padrão de Limitação ou do padrão de Limitação de Taxa.
  • Disponibilizar mais infraestruturas. Esse processo pode envolver a expansão atualizando alguns dos componentes da solução, ou pode envolver o dimensionamento por meio do provisionamento de fragmentos adicionais, se você seguir o padrão Sharding, ou carimbos, se seguir o padrão Deployment Stamps.
  • Permitir que os locatários comprem capacidade pré-provisionada ou reservada. Essa capacidade fornece aos locatários mais certeza de que sua solução lida adequadamente com sua carga de trabalho.
  • Suavize o uso de recursos dos locatários. Por exemplo, você pode tentar uma das seguintes abordagens:
    • Se você hospedar várias instâncias de sua solução, considere reequilibrar os locatários entre as instâncias ou selos. Por exemplo, considere colocar locatários com padrões de uso previsíveis e semelhantes em vários selos, para achatar os picos de uso.
    • Considere se você tem processos em segundo plano ou cargas de trabalho com uso intensivo de recursos que não são sensíveis ao tempo. Execute essas cargas de trabalho de forma assíncrona fora dos horários de pico, para preservar sua capacidade de recursos de pico para cargas de trabalho sensíveis ao tempo.
  • Verifique se seus serviços downstream fornecem controles para mitigar problemas de vizinhos barulhentos. Por exemplo, ao usar o Kubernetes, considere usar limites de pod e, ao usar o Service Fabric, considere usar os recursos internos de governança.
  • Restrinja as operações que os locatários podem executar. Por exemplo, impeça que os locatários executem operações que executarão consultas de banco de dados muito grandes, como especificar uma contagem máxima de registros retornáveis ou um limite de tempo em consultas. Esta ação reduz o risco de os inquilinos tomarem medidas que podem afetar negativamente outros inquilinos.
  • Fornecer um sistema de Qualidade de Serviço (QoS). Ao aplicar a QoS, você prioriza alguns processos ou cargas de trabalho à frente de outros. Ao considerar a QoS em seu projeto e arquitetura, você pode garantir que as operações de alta prioridade tenham precedência quando houver pressão sobre seus recursos.

Considerações

Na maioria dos casos, os inquilinos individuais não pretendem causar problemas de vizinhos barulhentos. Locatários individuais podem nem estar cientes de que suas cargas de trabalho causam problemas de vizinhos barulhentos para os outros. No entanto, também é possível que alguns locatários explorem vulnerabilidades em componentes compartilhados para atacar um serviço, individualmente ou executando um ataque distribuído de negação de serviço (DDoS).

Independentemente da causa, é importante tratar esses problemas como questões de governança de recursos e aplicar cotas de uso, limitação e controles de governança para mitigar o problema.

Nota

Certifique-se de informar seus clientes sobre qualquer limitação que você aplicar ou quaisquer cotas de uso em seu serviço. É importante que eles lidem de forma confiável com solicitações com falha e que não sejam surpreendidos por quaisquer limitações ou cotas que você aplicar.

Como detetar o problema

Da perspetiva de um cliente, o problema do vizinho barulhento normalmente se manifesta como solicitações de servidor com falha ou solicitações que levam muito tempo para serem concluídas. Em particular, se a mesma solicitação for bem-sucedida em outros momentos e parecer falhar aleatoriamente, pode haver um problema de vizinho barulhento. Os aplicativos cliente devem registrar a telemetria para acompanhar a taxa de sucesso e o desempenho das solicitações de serviços, e os aplicativos também devem registrar métricas de desempenho da linha de base para fins de comparação.

Do ponto de vista de um serviço, o problema do vizinho barulhento pode aparecer de várias maneiras:

  • Picos no uso de recursos. É importante ter uma compreensão clara do uso normal de recursos da linha de base e configurar o monitoramento e os alertas para detetar picos no uso de recursos. Certifique-se de considerar todos os recursos que podem afetar o desempenho ou a disponibilidade do serviço. Esses recursos incluem métricas como uso de CPU e memória do servidor, E/S de disco, uso de banco de dados, tráfego de rede e métricas expostas por serviços gerenciados, como o número de solicitações e as métricas de desempenho sintéticas e abstratas, como as unidades de solicitação do Azure Cosmos DB.
  • Falhas ao executar uma operação para um locatário. Em particular, procure falhas que ocorrem quando um locatário não está usando uma grande parte dos recursos do sistema. Tal padrão pode indicar que o inquilino é vítima do problema do vizinho barulhento. Considere controlar o consumo de recursos por locatário. Por exemplo, ao usar o Azure Cosmos DB, considere registrar as unidades de solicitação usadas para cada solicitação e adicione o identificador do locatário como uma dimensão à telemetria, para que você possa agregar o consumo da unidade de solicitação para cada locatário.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

  • John Downs - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Outros contribuidores:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.