Platform For AI:Atualizações contínuas e desligamento graceful

Atualização contínua

Durante uma atualização, o sistema cria novas réplicas e substitui gradualmente as antigas com base na sua configuração. Se uma nova réplica falhar ao iniciar, a atualização é pausada. A réplica com falha não recebe tráfego, e as réplicas antigas restantes continuam a atender às solicitações, de modo que seu service não é afetado. Você pode escolher reverter a atualização ou iniciar uma nova. Uma nova atualização prioriza a remoção das réplicas com falha da tentativa anterior incompleta.

Dois parâmetros principais controlam o processo de atualização contínua:

• Exceeds the expected number of replicas (parâmetro JSON: **rolling_strategy.max_surge**)

  • Descrição: Número máximo de réplicas extras que o sistema pode criar durante uma atualização. Pode ser um número inteiro positivo ou uma porcentagem. Um valor mais alto acelera o processo de atualização.

  • Exemplo: Para um service com 100 réplicas, se você definir esse valor como 20, o sistema criará 20 novas réplicas quando a atualização começar.

  • Padrão: 2% do total de réplicas, com um mínimo de 1.

  Importante

  Se Exceeds the expected number of replicas estiver definido com um valor muito alto, o sistema colocará um grande número de novas réplicas online e substituirá imediatamente uma quantidade igual de réplicas antigas. Caso as novas réplicas ainda não tenham passado pelo warm-up, o aumento repentino de tráfego poderá impactar a estabilidade do service.

• Maximum Unavailable Replicas (parâmetro JSON: **rolling_strategy.max_unavailable**)

  • Descrição: Quantidade máxima de réplicas que podem ficar indisponíveis durante uma atualização. Essa configuração libera recursos e evita que a escassez deles bloqueie a atualização.

  • Exemplo: Se você definir esse valor como N, o sistema interromperá imediatamente N réplicas antigas quando a atualização começar.

  • Padrão:

    • Para um grupo de recursos dedicado: O padrão é 1 para services criados antes de 1º de setembro de 2025. Para services criados em ou após 1º de setembro de 2025, o padrão é 0 se um pool elástico estiver ativado e 1 caso contrário.

    • Para um grupo de recursos público: 0.

    • Para uma cota de recursos: O padrão é 0 para services criados antes de 1º de setembro de 2025. Para services criados em ou após 1º de setembro de 2025, o padrão é 2% da contagem de réplicas, com um mínimo de 1.

  Importante

  • Em um service de réplica única, se você definir Maximum Unavailable Replicas como 1, a réplica antiga será interrompida antes que a nova inicie, tornando o service temporariamente indisponível.

  • Definir Maximum Unavailable Replicas com um valor muito alto pode causar a saída simultânea de muitas réplicas. As réplicas restantes podem não ser suficientes para lidar com o tráfego, o que degrada a disponibilidade do service.

Desligamento graceful

Os parâmetros de desligamento graceful afetam a estabilidade do encerramento das réplicas durante uma atualização contínua.

• Graceful Shutdown Time (parâmetro JSON: **eas.termination_grace_period**)

  • Descrição: Tempo, em segundos, que o sistema aguarda para que uma réplica seja desligada de forma graceful. Após uma réplica entrar no estado Terminating, o sistema para de rotear tráfego para ela. Em seguida, o sistema aguarda esse período para permitir que a réplica termine de processar quaisquer solicitações em andamento antes de encerrá-la. Se suas solicitações geralmente têm tempos de processamento longos, recomendamos aumentar esse valor.

  • Padrão: 30.

  Importante

  Reduzir esse valor pode afetar a estabilidade do service, enquanto defini-lo com um valor muito alto pode desacelerar as atualizações. A menos que você tenha requisitos específicos, não altere este parâmetro.

• Send SIGTERM (parâmetro JSON: **rpc.enable_sigterm**)

  • Descrição: SIGTERM é um sinal que encerra um processo. O parâmetro JSON aceita true ou false.

    • false: O sistema não envia um sinal SIGTERM quando uma réplica sai.

    • true: O sistema envia imediatamente um sinal SIGTERM quando uma réplica sai. O processo principal do service deve implementar uma lógica personalizada de desligamento graceful em um manipulador de sinais. Caso contrário, o sistema poderá encerrar o processo diretamente, fazendo com que o desligamento graceful falhe.

  • Padrão: Desativado (false).

Por padrão, o sistema não envia um sinal SIGTERM. Isso ocorre porque a maioria dos contêineres de aplicação não lida com o sinal SIGTERM por padrão. Se um contêiner receber um sinal SIGTERM sem um manipulador correspondente, seu processo será encerrado imediatamente. Isso ignora o processo de desligamento graceful, interrompendo seu service.

Para services com tempos de processamento de solicitações altamente variáveis, recomendamos ativar o SIGTERM. Por exemplo, se os tempos de processamento variarem de alguns segundos a 30 minutos, definir um tempo fixo de desligamento graceful de 30 minutos desacelerará as atualizações do service. Nesse cenário, configure seu contêiner de aplicação para lidar com o sinal SIGTERM, terminar de processar quaisquer solicitações em andamento e então sair. Isso permite um controle mais flexível sobre o processo de desligamento.

Não é necessário ativar o SIGTERM para um service de inferência assíncrona. Quando uma réplica sai, o plano de controle do EAS lida automaticamente com o sinal SIGTERM. Ele para de assinar novas solicitações e aguarda a conclusão das solicitações existentes antes de encerrar a réplica.