Platform For AI:Mises à jour progressives et arrêt gracieux

Mise à jour progressive

Lors d'une mise à jour, le système crée de nouveaux réplicas et remplace progressivement les anciens selon votre configuration. Si un nouveau réplica ne parvient pas à démarrer, la mise à jour est suspendue. Le réplica défaillant ne reçoit aucun trafic et les anciens réplicas restants continuent de traiter les requêtes, ce qui préserve la continuité de votre service. Vous pouvez alors choisir de revenir à la version précédente ou de lancer une nouvelle mise à jour. Lors d'une nouvelle tentative, le système priorise la suppression des réplicas ayant échoué lors de la tentative incomplète précédente.

Deux paramètres clés contrôlent le processus de mise à jour progressive :

• Exceeds the expected number of replicas (paramètre JSON : **rolling_strategy.max_surge**)

  • Description : nombre maximal de réplicas supplémentaires que le système peut créer pendant une mise à jour. Cette valeur peut être un entier positif ou un pourcentage. Une valeur plus élevée accélère le processus de mise à jour.

  • Exemple : pour un service comptant 100 réplicas, si vous définissez cette valeur sur 20, le système crée 20 nouveaux réplicas au début de la mise à jour.

  • Valeur par défaut : 2 % du nombre total de réplicas, avec un minimum de 1.

  Important

  Si Exceeds the expected number of replicas est défini sur une valeur trop élevée, le système met en ligne un grand nombre de nouveaux réplicas et remplace immédiatement un nombre équivalent d'anciens réplicas. Si les nouveaux réplicas n'ont pas terminé leur phase d'échauffement, l'augmentation soudaine du trafic peut affecter la stabilité du service.

• Maximum Unavailable Replicas (paramètre JSON : **rolling_strategy.max_unavailable**)

  • Description : nombre maximal de réplicas autorisés à être indisponibles pendant une mise à jour. Ce paramètre libère des ressources et évite qu'un manque de ressources ne bloque la mise à jour.

  • Exemple : si vous définissez cette valeur sur N, le système arrête immédiatement N anciens réplicas au démarrage de la mise à jour.

  • Valeur par défaut :

    • Pour un groupe de ressources dédié : la valeur par défaut est 1 pour les services créés avant le 1er septembre 2025. Pour les services créés le 1er septembre 2025 ou après, la valeur par défaut est 0 si un pool élastique est activé, et 1 s'il ne l'est pas.

    • Pour un groupe de ressources public : 0.

    • Pour un quota de ressources : la valeur par défaut est 0 pour les services créés avant le 1er septembre 2025. Pour les services créés le 1er septembre 2025 ou après, la valeur par défaut est de 2 % du nombre de réplicas, avec un minimum de 1.

  Important

  • Pour un service à réplica unique, si vous définissez Maximum Unavailable Replicas sur 1, l'ancien réplica s'arrête avant que le nouveau ne démarre, rendant le service temporairement indisponible.

  • Une valeur trop élevée pour Maximum Unavailable Replicas peut entraîner la mise hors ligne simultanée d'un trop grand nombre de réplicas. Les réplicas restants risquent de ne pas suffire à gérer le trafic, ce qui dégrade la disponibilité du service.

Arrêt gracieux

Les paramètres d'arrêt gracieux influent sur la stabilité de la terminaison des réplicas lors d'une mise à jour progressive.

• Graceful Shutdown Time (paramètre JSON : **eas.termination_grace_period**)

  • Description : durée, en secondes, pendant laquelle le système attend qu'un réplica s'arrête gracieusement. Lorsqu'un réplica passe à l'état Terminating, le système cesse de lui acheminer du trafic. Il attend ensuite cette période pour permettre au réplica de terminer le traitement des requêtes en cours avant de le supprimer. Si vos requêtes ont généralement des temps de traitement longs, nous vous recommandons d'augmenter cette valeur.

  • Valeur par défaut : 30.

  Important

  Une réduction de cette valeur peut affecter la stabilité du service, tandis qu'une valeur trop élevée ralentit les mises à jour. Sauf besoin spécifique, ne modifiez pas ce paramètre.

• Send SIGTERM (paramètre JSON : **rpc.enable_sigterm**)

  • Description : SIGTERM est un signal qui termine un processus. Le paramètre JSON accepte les valeurs true ou false.

    • false : le système n'envoie pas de signal SIGTERM lorsqu'un réplica s'arrête.

    • true : le système envoie immédiatement un signal SIGTERM lorsqu'un réplica s'arrête. Le processus principal du service doit implémenter une logique d'arrêt gracieux personnalisée dans un gestionnaire de signaux. Dans le cas contraire, le système peut terminer directement le processus, ce qui empêche l'arrêt gracieux.

  • Valeur par défaut : Désactivé (false).

Par défaut, le système n'envoie pas de signal SIGTERM. En effet, la plupart des conteneurs d'applications ne gèrent pas le signal SIGTERM par défaut. Si un conteneur reçoit un signal SIGTERM sans gestionnaire correspondant, son processus se termine immédiatement. Cela contourne le processus d'arrêt gracieux et perturbe votre service.

Pour les services dont les temps de traitement des requêtes varient considérablement, nous vous recommandons d'activer SIGTERM. Par exemple, si les temps de traitement des requêtes vont de quelques secondes à 30 minutes, définir une durée d'arrêt gracieux fixe de 30 minutes ralentira les mises à jour du service. Dans ce scénario, vous devez configurer votre conteneur d'application pour qu'il gère le signal SIGTERM, termine le traitement des requêtes en cours, puis s'arrête. Cela permet un contrôle plus flexible du processus d'arrêt.

Il n'est pas nécessaire d'activer SIGTERM pour un service d'inférence asynchrone. Lorsqu'un réplica s'arrête, le plan de contrôle EAS gère automatiquement le signal SIGTERM. Il cesse de souscrire à de nouvelles requêtes et attend que les requêtes existantes soient traitées avant de terminer le réplica.