Conceitos simplificados de escalonamento automático para cargas de trabalho de IA/ML no GKE

Este documento oferece uma visão geral dos conceitos de escalonamento automático para cargas de trabalho de IA/ML no Google Kubernetes Engine (GKE).

Este documento é destinado a engenheiros de machine learning (ML) que não conhecem o GKE. Recomendamos que você leia os seguintes documentos da série para facilitar o uso do GKE em cargas de trabalho de IA/ML:

  1. Por que usar o GKE para inferência de IA/ML
  2. Sobre a inferência de modelos de IA/ML no GKE
  3. Conceitos simplificados de escalonamento automático para cargas de trabalho de IA/ML no GKE (este documento)

Antes de começar

Você precisa ter familiaridade básica com os seguintes conceitos:

O desafio: atender à demanda máxima

A Cymbal Shops, uma varejista on-line fictícia, está se preparando para o evento anual de vendas. O mecanismo de recomendação com tecnologia de IA da loja precisa fornecer sugestões personalizadas em tempo real para um grande número de compradores on-line.

Se o mecanismo de recomendação ficar lento, a experiência do usuário será prejudicada e as vendas serão perdidas. No entanto, o provisionamento de capacidade excessiva do servidor não é econômico durante períodos de tráfego normal. O objetivo é que os recursos sejam escalonados automaticamente em resposta à demanda, o que ajuda a garantir uma boa experiência do usuário e a manter os custos sob controle.

A solução: escalonamento automático sob demanda

As funções de escalonamento automático do GKE são como um gerente de loja se preparando para uma corrida de vendas. Em vez de manter um prédio enorme totalmente equipado e ligado o tempo todo, o gerente ajusta dinamicamente toda a capacidade da loja (equipe, espaço físico e equipamentos) para atender às necessidades dos compradores a qualquer momento.

O GKE aplica o mesmo princípio: ele escalona automaticamente os recursos alocados ao aplicativo (carga de trabalho e infraestrutura) com base na demanda em tempo real.

Benefícios comerciais do escalonamento automático do GKE

Ao combinar estratégias de escalonamento horizontal e vertical, o GKE oferece uma abordagem robusta que proporciona três benefícios principais:

  • Otimização de custos: você paga apenas pelos recursos de computação que usa e evita a despesa de provisionamento excessivo. O escalonamento automático do GKE evita o desperdício, dimensionando automaticamente os aplicativos de acordo com os requisitos reais de CPU e memória. Ele também pode provisionar hardware caro e especializado (como GPUs) apenas para os momentos em que são necessários e os remove quando o trabalho é concluído.
  • Confiabilidade e desempenho aprimorados: seu aplicativo pode ser escalonar horizontalmente horizontalmente automaticamente (adicionar mais cópias) para lidar com picos repentinos de tráfego, garantindo a estabilidade para os usuários. Ao mesmo tempo, o escalonamento automático do GKE ajuda a evitar erros comuns de "falta de memória" (OOM, na sigla em inglês) que podem causar falhas nos aplicativos. Para os jobs exigentes de IA/ML, ele ajuda a garantir que o hardware de alto desempenho necessário esteja disponível para execução eficiente e conclusão dos jobs no prazo.
  • Redução do overhead operacional: a estratégia de escalonamento automático multidimensional do GKE simplifica significativamente o gerenciamento de recursos. O GKE automatiza as tarefas complexas de ajuste de solicitações de recursos e gerenciamento de pools de nós especializados para diferentes hardwares. Essa automação libera suas equipes de engenharia para se concentrarem no desenvolvimento de aplicativos em vez de ajustar a infraestrutura.

Escalonamento automático de cargas de trabalho

O escalonamento automático de cargas de trabalho ajusta automaticamente a capacidade do aplicativo para atender à demanda. O GKE emprega um sistema de escalonamento automático de duas camadas para gerenciar os recursos do aplicativo de maneira eficiente.

Escalonador automático horizontal de pods (HPA): adicionar mais recursos

O Autoescalonador Horizontal de Pods (HPA) monitora a utilização de recursos dos pods do aplicativo. Na nossa analogia, os pods são os "vendedores", e o HPA é o "gerente de equipe" que observa o quão ocupados os vendedores estão.

Quando a demanda nos pods aumenta, o HPA provisiona automaticamente mais pods para distribuir a carga. Quando a demanda diminui, o HPA encerra os pods inativos para conservar recursos.

Para mais informações, consulte Escalonamento automático horizontal de pods.

Autoescalonador de Pods Vertical (VPA): tornar os recursos mais poderosos

Enquanto o escalonamento horizontal se concentra em aumentar a quantidade de recursos, o escalonamento vertical é uma estratégia complementar que se concentra em aumentar a capacidade dos recursos atuais. No contexto da nossa analogia de loja off-line, não se trata de contratar mais funcionários, mas de aprimorar as capacidades da equipe atual para melhorar a eficiência individual.

Essa abordagem de escalonamento vertical no nível do pod é gerenciada pelo Autoescalonador de Pods Vertical (VPA, na sigla em inglês). O VPA analisa o consumo de recursos do aplicativo e ajusta as solicitações de CPU e memória do pod para cima ou para baixo de acordo com o uso real.

O VPA pode ajustar as solicitações e os limites de recursos de um pod, por exemplo, ao provisionar novamente o pod para escalonar de 1 CPU e 16 GB para 4 CPUs e 64 GB. Esse processo envolve a reinicialização do pod com a nova configuração mais capaz para lidar melhor com a carga de trabalho.

Para saber mais, acesse os recursos a seguir:

HPA e VPA são complementares. O HPA ajusta o número de pods em resposta a mudanças no tráfego, e o VPA ajuda a garantir que cada um desses pods seja dimensionado corretamente para a tarefa. Essas estratégias de escalonamento evitam o desperdício de recursos, evitam custos desnecessários e ajudam a garantir que o app permaneça responsivo e disponível durante as flutuações de tráfego. No entanto, não recomendamos o uso de HPA e VPA nas mesmas métricas (CPU e memória), porque elas podem entrar em conflito. Para mais informações, consulte Limitações do escalonamento automático horizontal de pods.

Escalonamento automático de infraestrutura

O escalonamento automático de infraestrutura adiciona ou remove hardware automaticamente para atender às demandas das cargas de trabalho.

Escalonador automático de cluster: o gerente de construção

O escalonador automático de cluster ajuda a garantir que haja infraestrutura subjacente suficiente (VMs ou nós no contexto do GKE) para acomodar os pods. Os nós podem ser comparados aos "andares" de uma loja, em que o escalonador automático de cluster é o "gerente de construção".

Se o HPA precisar adicionar mais pods, mas os nós atuais não tiverem capacidade disponível, o escalonador automático de cluster vai provisionar um novo nó. Por outro lado, se um nó ficar subutilizado, o escalonador automático de cluster vai mover os pods desse nó para outros nós e encerrar o nó agora vazio.

Para mais informações, consulte Escalonador automático de cluster.

Criação automática de pools de nós: o especialista em automação

Embora o escalonador automático de cluster adicione nós aos pools de nós atuais, a criação automática de pool de nós estende a capacidade do escalonador automático de cluster, permitindo que ele crie automaticamente novos pools de nós que atendam às necessidades específicas dos pods.

Algumas cargas de trabalho de IA/ML exigem hardware especializado de alto desempenho, como GPUs ou TPUs, que não estão disponíveis em pools de nós de uso geral. A criação automática de pools de nós automatiza totalmente o provisionamento desse hardware especializado quando as cargas de trabalho exigem. Isso ajuda a garantir que até mesmo as tarefas mais intensivas em computação recebam o hardware necessário, quando necessário.

Para mais informações, consulte Sobre a criação automática de pools de nós.

Para os aceleradores disponíveis no GKE, consulte o seguinte:

ComputeClasses: o gatilho para a criação automática de pool de nós

Embora a criação automática de pool de nós possa ser acionada pela solicitação de um pod para um tipo de hardware específico (como nvidia-l4-vws), o uso de uma ComputeClass é o método mais resiliente e moderno. Uma ComputeClass é um recurso do GKE que você define e que atua em um conjunto de regras para controlar e personalizar como o hardware é escalonado automaticamente. Embora não seja um escalonador automático, ele funciona com o escalonador automático de cluster.

Para estender a analogia, pense nas ComputeClasses como um "formulário de requisição inteligente" para o equipamento do seu repositório.

Em vez de um vendedor (seu pod) exigir uma peça de hardware específica e rígida (por exemplo, "Preciso da caixa registradora do modelo 500 da marca X"), ele solicita uma capacidade usando o formulário de requisição (por exemplo, "Preciso de uma estação de checkout de alta velocidade"). O formulário (a ComputeClass) contém um conjunto de regras para a equipe de compras (GKE) sobre como atender a esse pedido.

As ComputeClasses separam a solicitação de hardware do pod da ação de provisionamento do GKE. Em vez de exigir uma máquina específica (como a3-highgpu-8g), o pod pode solicitar uma ComputeClass. A própria ComputeClass define a lógica "inteligente", uma lista priorizada de regras que informa ao GKE como atender a essa solicitação.

Para mais informações, consulte Sobre as ComputeClasses do GKE.

Para um mergulho profundo nas ComputeClasses com exemplos reais e configurações YAML, consulte o guia técnico: Como otimizar cargas de trabalho do GKE com ComputeClasses personalizadas.

Principais métricas e acionadores para escalonamento automático

Para tomar decisões de escalonamento informadas, os componentes de escalonamento automático monitoram diferentes sinais. A tabela a seguir mostra a comparação dos acionadores de escalonamento automático com base em métricas.

Componente Reage a Fonte do sinal Linha de raciocínio Ação do GKE
HPA Carga atual Consumo em tempo real, por exemplo, a CPU está em 90% no momento. Os pods atuais estão sobrecarregados. Precisamos distribuir esse tráfego imediatamente." Escalonamento horizontal: muda o número de réplicas de pods para atender à demanda.
VPA Eficiência de dimensionamento Consumo histórico, por exemplo, uso médio de RAM nas últimas 24 horas. "As necessidades de recursos desse pod mudaram ou nossas estimativas iniciais estavam incorretas. Precisamos ajustar a alocação de recursos para corresponder ao uso real." Escalonamento vertical: muda o tamanho (limites de CPU ou RAM) do pod para dimensioná-lo corretamente.
Criação automática de pools de nós Disponibilidade de hardware Solicitações não atendidas, por exemplo, o pod está no status "Pendente" porque não há nós de GPU. "Não é possível iniciar esse pod porque o hardware físico solicitado está ausente." Provisiona a infraestrutura: cria novos pools de nós com o hardware específico.

Gatilhos do Escalonador automático horizontal de pods (HPA): reagir à carga

O HPA escalona o número de pods (escalona horizontalmente ou verticalmente) observando as métricas de desempenho em tempo real. Por exemplo, a utilização de CPU e memória, as métricas fundamentais que indicam a carga de processamento nos pods, estão disponíveis imediatamente para o HPA.

No entanto, algumas métricas precisam de configurações explícitas, como as seguintes:

  • Métricas do balanceador de carga (solicitações por segundo, RPS): uma medida direta do tráfego de aplicativos, permitindo respostas de escalonamento mais rápidas. Para usar essa métrica, consulte Ativar o balanceamento de carga baseado na utilização e o perfil de HPA de desempenho.
  • Métricas personalizadas: configure o escalonamento automático com base em métricas de negócios personalizadas, como "número de usuários ativos", para gerenciar proativamente os recursos com base na demanda prevista. Para usar métricas personalizadas, é necessário configurar um pipeline de métricas para expô-las ao HPA. Para mais informações, consulte Google Cloud Managed Service para Prometheus.

Gatilhos do Autoescalonador de Pods Vertical (VPA): reagindo às necessidades de recursos

O VPA escalona o tamanho do pod (escalona horizontalmente ou verticalmente) observando o consumo histórico de recursos:

  • Utilização de CPU e memória: o VPA analisa o uso anterior de um pod para determinar se a solicitação de recursos está correta. O objetivo principal do VPA é evitar a contenção de recursos, aumentando ou diminuindo as solicitações de memória e CPU de um pod para corresponder às necessidades reais.

Acionadores de criação automática de pools de nós: reagir a solicitações de hardware

A criação automática de pools de nós provisiona novos pools de nós com hardware especializado. Ele não é acionado por métricas de desempenho, como carga da CPU. Em vez disso, ele é acionado por uma solicitação de recurso de um pod:

  • Solicitação de recurso não programável: um acionador principal. Quando um pod é criado, ele solicita hardware específico. Se o cluster não puder atender a essa solicitação porque nenhum nó atual tem esse hardware, a criação automática de pool de nós vai agir.
  • Solicitação de ComputeClass: um pod solicita uma ComputeClass, por exemplo, cloud.google.com/compute-class: premium-gpu. Se nenhum nó no cluster puder fornecer os recursos "premium-gpu", a criação automática de pools de nós vai criar automaticamente um novo pool de nós que possa fornecer esses recursos.

Para saber como usar métricas personalizadas, do Prometheus e externas para realizar o escalonamento automático, consulte Sobre o escalonamento automático de cargas de trabalho com base em métricas.

Conclusão

Ao aplicar essas estratégias de escalonamento automático, é possível gerenciar com eficácia cargas de trabalho de IA/ML flutuantes. Assim como o gerente da loja Cymbal Shops navegou pelo evento de vendas de pico gerenciando os recursos de maneira flexível, você pode usar o escalonamento automático do GKE para expandir e contrair automaticamente a infraestrutura e os recursos de carga de trabalho. Isso ajuda a garantir que seus modelos permaneçam com bom desempenho durante picos de tráfego e econômicos durante períodos de inatividade, mantendo o ambiente dimensionado corretamente.

A seguir