Editar

Anti-padrão ruidoso vizinho

Azure

Os sistemas multi-inquilino partilham recursos entre inquilinos. Uma vez que os inquilinos utilizam os mesmos recursos partilhados, a atividade de um inquilino pode ter um impacto negativo na utilização do sistema por parte de outro inquilino.

Descrição do problema

Quando cria um serviço para ser partilhado por vários clientes ou inquilinos, pode compilá-lo para ser multi-inquilino. Uma vantagem dos sistemas multi-inquilinos é que os recursos podem ser agrupados e partilhados entre inquilinos. Isto resulta frequentemente em custos mais baixos e numa eficiência melhorada. No entanto, se um único inquilino utilizar uma quantidade desproporcional dos recursos disponíveis no sistema, o desempenho geral do sistema pode sofrer. O problema ruidoso do vizinho ocorre quando o desempenho de um inquilino está degradado devido às atividades de outro inquilino.

Considere um sistema multi-inquilino de exemplo com dois inquilinos. Os padrões de utilização do inquilino A e os padrões de utilização do inquilino B coincidem, o que significa que, em horas de pico, a utilização total de recursos é superior à capacidade do sistema:

Figura que mostra a utilização de recursos de dois inquilinos. O inquilino A consome o conjunto completo de recursos do sistema, o que significa que o inquilino B tem falhas.

É provável que o pedido do inquilino que chegou primeiro tenha precedência. Em seguida, o outro inquilino terá um problema de vizinho ruidoso. Em alternativa, ambos os inquilinos podem descobrir que o desempenho sofre.

O problema ruidoso do vizinho também ocorre mesmo quando cada inquilino individual está a consumir quantidades relativamente pequenas da capacidade do sistema, mas a utilização coletiva de recursos de muitos inquilinos resulta num pico na utilização geral:

Figura com 3 inquilinos, cada um a consumir menos o débito máximo da solução. No total, os três inquilinos consomem os recursos completos do sistema.

Isto pode acontecer quando tem vários inquilinos com padrões de utilização semelhantes ou quando não aprovisionou capacidade suficiente para a carga coletiva no sistema.

Como resolver o problema

Problemas ruidosos de vizinhos são um risco inerente em sistemas multi-inquilino, e não é possível eliminar completamente a possibilidade de ser afetado por um vizinho barulhento. No entanto, existem alguns passos que tanto os clientes como os fornecedores de serviços podem seguir para reduzir a probabilidade de problemas de vizinhos ruidosos ou para mitigar os seus efeitos quando são observados.

Ações que os clientes podem realizar

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

  • Monitorize a utilização de recursos do seu sistema. Monitorize a utilização geral de recursos e os recursos que cada inquilino utiliza. Configure alertas para detetar picos na utilização de recursos e, se possível, configure a automatização para mitigar automaticamente problemas conhecidos ao aumentar ou reduzir verticalmente.
  • Aplicar governação de recursos. Considere aplicar políticas que evitem que um único inquilino sobrecarregue o sistema e reduza a capacidade disponível para outras pessoas. Este passo pode assumir a forma de imposição de quota, através do padrão limitação ou do padrão de Limitação de Taxa.
  • Aprovisionar mais infraestrutura. Este processo pode implicar aumentar verticalmente ao atualizar alguns dos componentes da solução ou pode implicar aumentar horizontalmente ao aprovisionar partições horizontais adicionais, se seguir o padrão de Fragmentação ou carimbos, se seguir o padrão Desativação de Implementação.
  • Permitir que os inquilinos comprem capacidade pré-aprovisionada ou reservada. Esta capacidade proporciona aos inquilinos mais certezas de que a sua solução processa adequadamente a carga de trabalho.
  • Suavizar a utilização de recursos dos inquilinos. Por exemplo, pode experimentar uma das seguintes abordagens:
    • Se alojar várias instâncias da sua solução, considere reequilibrar inquilinos nas instâncias ou carimbos. Por exemplo, considere colocar inquilinos com padrões de utilização previsíveis e semelhantes em vários selos, para aplanar os picos na respetiva utilização.
    • Considere se tem processos em segundo plano ou cargas de trabalho com muitos recursos que não são sensíveis ao tempo. Execute estas cargas de trabalho de forma assíncrona em horas fora do pico, para preservar a capacidade máxima dos recursos para cargas de trabalho sensíveis ao tempo.
  • Verifique se os serviços a jusante fornecem controlos para mitigar problemas de vizinhos ruidosos. Por exemplo, ao utilizar o Kubernetes, considere utilizar limites de pods e, ao utilizar o Service Fabric, considere utilizar as capacidades de governação incorporadas.
  • Restringir as operações que os inquilinos podem realizar. Por exemplo, impeça que os inquilinos executem operações que irão executar consultas de base de dados muito grandes, como especificar uma contagem máxima de registos retornáveis ou um limite de tempo nas consultas. Esta ação mitiga o risco de os inquilinos tomarem ações que podem afetar negativamente outros inquilinos.
  • Fornecer um sistema de Qualidade de Serviço (QoS). Quando aplica QoS, dá prioridade a alguns processos ou cargas de trabalho à frente de outros. Ao considerar a QoS na sua estrutura e arquitetura, pode garantir que as operações de alta prioridade têm precedência quando há pressão sobre os seus recursos.

Considerações

Na maioria dos casos, os inquilinos individuais não pretendem causar problemas de vizinhos ruidosos. Os inquilinos individuais podem nem estar cientes de que as cargas de trabalho causam problemas de vizinhos ruidosos para outras pessoas. No entanto, também é possível que alguns inquilinos possam explorar vulnerabilidades em componentes partilhados para atacar um serviço, individualmente ou ao executar um ataque denial of service distribuído (DDoS).

Independentemente da causa, é importante tratar estes problemas como problemas de governação de recursos e aplicar quotas de utilização, limitação e controlos de governação para mitigar o problema.

Nota

Certifique-se de que indica aos clientes qualquer limitação que aplique ou quaisquer quotas de utilização no seu serviço. É importante que processem de forma fiável os pedidos falhados e que não se surpreendam com quaisquer limitações ou quotas que aplique.

Como detetar o problema

Do ponto de vista de um cliente, o problema de vizinho ruidoso normalmente manifesta-se como pedidos de servidor falhados ou pedidos que demoram muito tempo a concluir. Em particular, se o mesmo pedido for bem-sucedido noutras alturas e parecer falhar aleatoriamente, poderá existir um problema de vizinho ruidoso. As aplicações cliente devem registar telemetria para controlar a taxa de êxito e o desempenho dos pedidos aos serviços e as aplicações também devem registar métricas de desempenho de linha de base para fins de comparação.

Do ponto de vista de um serviço, o problema de vizinho ruidoso pode aparecer de várias formas:

  • Picos na utilização de recursos. É importante ter uma compreensão clara da utilização normal do recurso de linha de base e configurar a monitorização e os alertas para detetar picos na utilização de recursos. Confirme que considera todos os recursos que podem afetar o desempenho ou a disponibilidade do serviço. Estes recursos incluem métricas como a CPU do servidor e a utilização da memória, E/S do disco, utilização da base de dados, tráfego de rede e métricas que são expostas por serviços geridos, como o número de pedidos e as métricas de desempenho sintéticas e abstratas, como as unidades de pedido do Azure Cosmos DB.
  • Falhas ao executar uma operação para um inquilino. Em particular, procure falhas que ocorram quando um inquilino não está a utilizar uma grande parte dos recursos do sistema. Tal padrão pode indicar que o inquilino é vítima do problema de vizinho ruidoso. Considere controlar o consumo de recursos por inquilino. Por exemplo, ao utilizar o Azure Cosmos DB, considere registar as unidades de pedido utilizadas para cada pedido e adicionar o identificador do inquilino como uma dimensão à telemetria, para que possa agregar o consumo de unidade de pedido para cada inquilino.

Contribuidores

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

Autor principal:

  • John Downs | Engenheiro Principal de Clientes, FastTrack para o Azure

Outros contribuidores:

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