Editar

Compartilhar via

Antipadrão de vizinho barulhento

Azure

Sistemas multilocatários compartilham recursos entre dois ou mais 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 a ser compartilhado entre vários clientes ou locatários, você pode defini-lo como multilocatário. Um benefício dos sistemas multilocatários é que os recursos podem ser agrupados e compartilhados entre locatários. Isso geralmente resulta em redução de custos e melhor eficiência. No entanto, se um locatário usar uma quantidade desproporcional dos recursos disponíveis no sistema, o desempenho geral do sistema poderá ser afetado. O problema de vizinho barulhento ocorre quando o desempenho de um locatário é degradado devido às atividades de outro.

Como exemplo, considere um 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. Nos horários de pico, o locatário A usa todos os recursos do sistema, o que significa que todas as solicitações feitas pelo locatário B falham. Em outras palavras, o uso total de recursos é maior do que a capacidade do sistema:

Figura que mostra 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 apresenta falhas.

É provável que a solicitação de qualquer locatário que chegue primeiro tenha precedência. Em seguida, o outro locatário enfrentará um problema de vizinho barulhento. Como alternativa, os dois locatários podem ter o desempenho prejudicado.

O problema de 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 três locatários, cada um consumindo menos a taxa de transferência máxima da solução. No total, os três locatários consomem os recursos completos do sistema.

Essa situação pode acontecer quando você tem vários locatários com padrões de uso semelhantes ou quando você não provisionou capacidade suficiente para a carga coletiva no sistema.

Como corrigir o problema

Problemas com vizinhos barulhentos são um risco inerente quando você compartilha um único recurso e não é possível eliminar completamente a possibilidade de ser afetado por um vizinho barulhento. No entanto, há algumas etapas que os clientes e provedores de serviço podem executar para reduzir a probabilidade de problemas de vizinho barulhento ou atenuar os efeitos, quando forem observados.

Ações que os clientes podem executar

Ações que os provedores de serviços podem executar

  • Monitore o uso de recursos para seu sistema. Monitore o uso geral de recursos e os recursos que cada locatário usa. Configure alertas para detectar picos de uso de recursos e, se possível, configurar a automação para atenuar automaticamente os problemas conhecidos ao escalar vertical ou horizontalmente.
  • Aplique a governança de recursos. Aplique políticas para evitar que um só locatário sobrecarregue o sistema e reduza a capacidade disponível para outras pessoas. Isso pode assumir a forma de imposição de cota, por meio do Padrão de limitação ou do Padrão de limitação de taxa.
  • Provisione mais infraestrutura. Esse processo poderá envolver a escala vertical, com a atualização de alguns dos componentes da solução, ou a escala horizontal, com o provisionamento de fragmentos adicionais, se você seguir o Padrão de fragmentação, ou os selos, se seguir o Padrão de selos de implantação.
  • Permita que os locatários adquiram capacidade reservada ou pré-provisionada. Com essa capacidade, os locatários terão mais certeza de que a sua solução processa adequadamente a carga de trabalho deles.
  • Suavize o uso de recursos dos locatários. Por exemplo, você pode tentar uma das seguintes abordagens:
    • Se você hospedar várias instâncias da sua solução, considere a possibilidade de refazer o balanceamento de locatários em instâncias ou selos. Por exemplo, considere colocar locatários com padrões de uso previsíveis e semelhantes em vários selos, para nivelar os picos em seu uso.
    • Verifique 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 maneira assíncrona em horários fora de pico, a fim de preservar sua capacidade de recursos de pico para cargas de trabalho sensíveis ao tempo.
  • Analise se os serviços downstream fornecem controles para atenuar problemas de vizinho barulhento. Por exemplo, ao usar o Kubernetes, considere o uso de limites de pod e, ao usar o Service Fabric, considere o uso das funcionalidades internas de governança.
  • Restrinja as operações que os locatários podem executar. Por exemplo, restrinja os locatários a executar operações com consultas de banco de dados muito grandes, por exemplo, especificando uma contagem máxima de registros retornáveis ou um limite de tempo em consultas. Essa ação reduz o risco de locatários realizarem ações que possam afetar negativamente outros locatários.
  • Forneça um sistema de Qualidade de Serviço (QoS). Ao aplicar a QoS, você prioriza alguns processos ou cargas de trabalho em vez de outros. Ao considerar a QoS em seu design 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 locatários individuais não têm a intenção de causar problemas de vizinho barulhento. Locatários individuais podem nem mesmo estar cientes de que as cargas de trabalho causam problemas de vizinho barulhento para outros. No entanto, também é possível que alguns locatários usem vulnerabilidades em componentes compartilhados para atacar um serviço individualmente ou executando um ataque de DDoS (negação de serviço distribuído).

Independentemente da causa, é importante tratar esses problemas como problemas de governança de recursos e aplicar cotas de uso, limitação e controles de governança para atenuá-los.

Observação

Informe seus clientes sobre qualquer limitação que você aplicar ou qualquer cota de uso no seu serviço. É importante que eles lidem bem com as solicitações com falha e que não fiquem surpresos com as limitações ou cotas que você aplicar.

Como detectar o problema

Da perspectiva do cliente, o problema de vizinho barulhento normalmente se manifesta como solicitações ao serviço com falha ou solicitações que levam muito tempo para serem concluídas. Especificamente, se a mesma solicitação for bem-sucedida em outras ocasiões e parecer falhar aleatoriamente, poderá 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 para serviços, e os aplicativos também devem registrar métricas de desempenho de linha de base para fins de comparação.

Da perspectiva de um serviço, o problema de vizinho barulhento pode aparecer de várias maneiras:

  • Picos de uso de recursos. É importante ter uma compreensão clara de seu uso normal de recursos de linha de base e configurar o monitoramento e os alertas para detectar picos de uso de recursos. Considere todos os recursos que podem afetar o desempenho ou a disponibilidade do serviço. Esses recursos incluem métricas como uso de memória e da CPU 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, por exemplo, 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. Esse padrão pode indicar que o locatário é uma vítima do problema de vizinho barulhento. Considere acompanhar 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 adicionar o identificador do locatário como uma dimensão à telemetria, para que você possa agregar o consumo de unidade de solicitação para cada locatário.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Outros colaboradores:

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