Concepts d'autoscaling simplifiés pour les charges de travail d'IA/de ML dans GKE

Ce document présente les concepts d'autoscaling pour les charges de travail d'IA/de ML dans Google Kubernetes Engine (GKE).

Ce document est destiné aux ingénieurs en machine learning (ML) qui débutent avec GKE. Nous vous recommandons de lire les documents suivants de la série pour vous familiariser avec l'utilisation de GKE pour les charges de travail d'IA/ML :

  1. Pourquoi utiliser GKE pour l'inférence d'IA/ML ?
  2. À propos de l'inférence de modèles d'IA/ML sur GKE
  3. Concepts d'autoscaling simplifiés pour les charges de travail d'IA/de ML dans GKE (ce document)

Avant de commencer

Vous devez avoir des connaissances de base sur les concepts suivants :

Le défi : répondre à la demande de pointe

Cymbal Shops, un marchand en ligne fictif, se prépare pour son événement commercial annuel. Le moteur de recommandations optimisé par l'IA du magasin doit fournir des suggestions personnalisées en temps réel à un afflux massif d'acheteurs en ligne.

Si le moteur de recommandation ralentit, l'expérience utilisateur en pâtit et des ventes sont perdues. Toutefois, il n'est pas rentable de provisionner une capacité de serveur excessive pendant les périodes de trafic normal. L'objectif est de faire évoluer automatiquement les ressources en fonction de la demande, afin de garantir une bonne expérience utilisateur tout en maîtrisant les coûts.

La solution : l'autoscaling à la demande

Les fonctions d'autoscaling de GKE sont semblables à celles d'un responsable de magasin qui se prépare à un afflux de clients. Au lieu de maintenir un grand bâtiment entièrement équipé et alimenté en permanence, le responsable ajuste de manière dynamique la capacité totale du magasin (personnel, surface de vente et équipements) en fonction des besoins des clients à tout moment.

GKE applique le même principe : il ajuste automatiquement les ressources allouées à votre application (charge de travail et infrastructure) en fonction de la demande en temps réel.

Avantages commerciaux de l'autoscaling GKE

En combinant des stratégies de scaling horizontal et vertical, GKE offre une approche robuste qui présente trois avantages principaux :

  • Optimisation des coûts : vous ne payez que pour les ressources de calcul que vous utilisez et évitez les dépenses liées au surprovisionnement. L'autoscaling GKE évite le gaspillage en dimensionnant automatiquement vos applications en fonction de leurs besoins réels en CPU et en mémoire. Il peut également provisionner du matériel spécialisé coûteux (comme des GPU) uniquement lorsqu'ils sont nécessaires, et les supprimer une fois le job terminé.
  • Fiabilité et performances améliorées : votre application peut automatiquement effectuer un scaling horizontal (ajouter des copies) pour gérer les pics de trafic soudains, ce qui garantit la stabilité pour vos utilisateurs. En même temps, l'autoscaling de GKE permet d'éviter les erreurs courantes de mémoire insuffisante (OOM, Out Of Memory) qui peuvent entraîner le plantage des applications. Pour les tâches d'IA/de ML exigeantes, il permet de s'assurer que le matériel hautes performances nécessaire est disponible pour les exécuter efficacement et les terminer à temps.
  • Réduction des coûts opérationnels : la stratégie d'autoscaling multidimensionnel de GKE simplifie considérablement la gestion des ressources. GKE automatise les tâches complexes d'ajustement des demandes de ressources et de gestion des pools de nœuds spécialisés pour différents matériels. Cette automatisation permet à vos équipes d'ingénierie de se concentrer sur le développement d'applications plutôt que sur l'optimisation de l'infrastructure.

Autoscaling des charges de travail

L'autoscaling des charges de travail ajuste automatiquement la puissance de votre application en fonction de la demande. GKE utilise un système d'autoscaling à deux niveaux pour gérer efficacement les ressources de votre application.

Autoscaler horizontal de pods (AHP) : ajout de ressources

L'autoscaler horizontal de pods (AHP) surveille l'utilisation des ressources des pods de votre application. Dans notre analogie, les pods sont les "commerciaux", et le AHP est le "chef d'équipe" qui observe leur charge de travail.

Lorsque la demande sur les pods augmente, l'AHP provisionne automatiquement davantage de pods pour répartir la charge. Lorsque la demande diminue, le AHP met fin aux pods inactifs pour économiser des ressources.

Pour en savoir plus, consultez Autoscaling horizontal des pods.

Autoscaler vertical de pods (VPA) : rendre les ressources plus puissantes

Alors que le scaling horizontal se concentre sur l'augmentation de la quantité de ressources, le scaling vertical est une stratégie complémentaire qui vise à augmenter la puissance des ressources existantes. Dans le contexte de notre analogie avec le magasin physique, il ne s'agit pas d'embaucher plus de personnel, mais d'améliorer les capacités de l'équipe actuelle pour accroître l'efficacité de chacun.

Cette approche de scaling vertical au niveau des pods est gérée par l'autoscaler vertical des pods (VPA). Le VPA analyse la consommation de ressources de votre application et ajuste les demandes de ressources de processeur et de mémoire du pod à la hausse ou à la baisse pour correspondre à son utilisation réelle.

Le VPA peut ajuster les demandes et les limites de ressources d'un pod, par exemple en reconfigurant le pod pour qu'il passe de 1 CPU et 16 Go à 4 CPU et 64 Go. Ce processus consiste à redémarrer le pod avec sa nouvelle configuration plus performante pour mieux gérer sa charge de travail.

Pour en savoir plus, consultez les ressources suivantes :

AHP et VPA sont complémentaires. L'AHP ajuste le nombre de pods en réponse aux variations de trafic, et le VPA permet de s'assurer que chacun de ces pods est correctement dimensionné pour sa tâche. Ces stratégies de scaling permettent d'éviter le gaspillage de ressources et les coûts inutiles, et de s'assurer que votre application reste réactive et disponible en cas de fluctuations du trafic. Toutefois, nous vous déconseillons d'utiliser l'AHP et le VPA sur les mêmes métriques (processeur et mémoire), car ils peuvent entrer en conflit. Pour en savoir plus, consultez Limites de l'autoscaling horizontal de pods.

Autoscaling de l'infrastructure

L'autoscaling de l'infrastructure ajoute ou supprime automatiquement du matériel pour répondre aux exigences de vos charges de travail.

Autoscaler de cluster : le gestionnaire de l'immeuble

L'autoscaler de cluster permet de s'assurer qu'il existe une infrastructure sous-jacente suffisante (VM ou nœuds dans le contexte de GKE) pour accueillir les pods. Les nœuds peuvent être comparés aux "étages" d'un magasin, où l'autoscaler de cluster est le "gestionnaire de l'immeuble".

Si l'AHP doit ajouter des pods, mais que les nœuds existants manquent de capacité disponible, l'autoscaler de cluster provisionne un nouveau nœud. À l'inverse, si un nœud devient sous-utilisé, l'autoscaler de cluster déplace les pods de ce nœud vers d'autres nœuds et arrête le nœud désormais vide.

Pour en savoir plus, consultez la section Autoscaler de cluster.

Création automatique de pools de nœuds : le spécialiste de l'automatisation

Alors que l'autoscaler de cluster ajoute des nœuds aux pools de nœuds existants, la création automatique de pools de nœuds étend les capacités de l'autoscaler de cluster en lui permettant de créer automatiquement des pools de nœuds qui répondent aux besoins spécifiques de vos pods.

Certaines charges de travail d'IA/ML nécessitent du matériel spécialisé et hautes performances, comme des GPU ou des TPU, qui ne sont pas disponibles dans les pools de nœuds à usage général. La création automatique de pools de nœuds automatise entièrement le provisionnement de ce matériel spécialisé lorsque vos charges de travail l'exigent. Cela permet de s'assurer que même les tâches les plus gourmandes en ressources de calcul obtiennent le matériel dont elles ont besoin, au moment où elles en ont besoin.

Pour en savoir plus, consultez À propos de la création automatique de pools de nœuds.

Pour connaître les accélérateurs disponibles dans GKE, consultez les ressources suivantes :

ComputeClasses : le déclencheur de la création automatique de pools de nœuds

Bien que la création automatique de pools de nœuds puisse être déclenchée par la demande d'un pod pour un type de matériel spécifique (comme nvidia-l4-vws), l'utilisation d'une ComputeClass est la méthode la plus résiliente et la plus moderne. Une ComputeClass est une ressource GKE que vous définissez et qui agit sur un ensemble de règles pour contrôler et personnaliser la façon dont votre matériel est autoscalé. Bien qu'il ne s'agisse pas d'un autoscaler en soi, il fonctionne avec l'autoscaler de cluster.

Pour poursuivre l'analogie, considérez les ComputeClasses comme un "formulaire de demande intelligent" pour l'équipement de votre magasin.

Au lieu qu'un vendeur (votre pod) exige un matériel spécifique et rigide (par exemple, "J'ai besoin de la caisse enregistreuse Marque X Modèle 500"), il demande une fonctionnalité à l'aide du formulaire de demande (par exemple, "J'ai besoin d'une caisse rapide"). Le formulaire (ComputeClass) contient un ensemble de règles pour l'équipe des achats (GKE) sur la façon de traiter cette commande.

Les ComputeClasses séparent la demande de matériel de votre pod de l'action de provisionnement de GKE. Au lieu de demander une machine spécifique (comme a3-highgpu-8g), votre pod peut demander une ComputeClass. La ComputeClass elle-même définit la logique "intelligente", c'est-à-dire une liste de règles par ordre de priorité qui indique à GKE comment répondre à cette requête.

Pour en savoir plus, consultez À propos des ComputeClasses GKE.

Pour en savoir plus sur les ComputeClasses avec des exemples concrets et des configurations YAML, consultez le guide technique Optimiser les charges de travail GKE avec des ComputeClasses personnalisées.

Métriques et déclencheurs clés pour l'autoscaling

Pour prendre des décisions de scaling éclairées, les composants d'autoscaling surveillent différents signaux. Le tableau suivant compare les déclencheurs d'autoscaling basés sur des métriques.

Composant Réagit à Source du signal Processus de réflexion Action de GKE
HPA Charge actuelle Consommation en temps réel (par exemple, le processeur est actuellement à 90 %). "Les pods actuels sont surchargés. Nous devons distribuer ce trafic immédiatement." Effectue un scale-out ou un scale-in : modifie le nombre d'instances répliquées de pods pour répondre à la demande.
VPA Efficacité du dimensionnement Consommation historique, par exemple, utilisation moyenne de la RAM au cours des dernières 24 heures. "Les besoins en ressources de ce pod ont changé, ou nos estimations initiales étaient incorrectes. Nous devons ajuster l'allocation de ressources en fonction de son utilisation réelle." Effectue un scaling à la hausse ou à la baisse : modifie la taille (limites de processeur ou de RAM) du pod pour l'adapter.
Création automatique de pools de nœuds Disponibilité du matériel Les requêtes non satisfaites, par exemple, le pod est à l'état "En attente" parce qu'il n'existe aucun nœud GPU. "Ce pod ne peut pas démarrer, car le matériel physique qu'il a demandé est manquant." Provisionne l'infrastructure : crée des pools de nœuds avec le matériel spécifique.

Déclencheurs de l'autoscaler horizontal de pods (AHP) : réaction à la charge

Le HPA adapte le nombre de pods (en l'augmentant ou en le diminuant) en surveillant les métriques de performances en temps réel. Par exemple, l'utilisation du processeur et de la mémoire, les métriques fondamentales qui indiquent la charge de traitement sur vos pods, sont disponibles prêtes à l'emploi pour AHP.

Cependant, certaines métriques nécessitent des configurations explicites, comme les suivantes :

  • Métriques d'équilibreur de charge (requêtes par seconde) : mesure directe du trafic d'application, permettant des réponses de scaling plus rapides. Pour utiliser cette métrique, consultez Activer l'équilibrage de charge basé sur l'utilisation et le profil HPA de performances.
  • Métriques personnalisées : configurez l'autoscaling en fonction de métriques métier personnalisées, telles que le nombre d'utilisateurs actifs, pour gérer de manière proactive les ressources en fonction de la demande prévue. Pour utiliser des métriques personnalisées, vous devez configurer un pipeline de métriques afin de les exposer au AHP. Pour en savoir plus, consultez Google Cloud Managed Service pour Prometheus.

Déclencheurs de l'autoscaler vertical de pods (VPA) : réaction aux besoins en ressources

Le VPA ajuste la taille de votre pod (en l'augmentant ou en la diminuant) en surveillant sa consommation de ressources historique :

  • Utilisation du CPU et de la mémoire : l'autoscaler vertical de pods analyse l'utilisation passée d'un pod pour déterminer si sa demande de ressources est correcte. L'objectif principal du VPA est d'éviter la contention des ressources en augmentant ou en diminuant les demandes de mémoire et de processeur d'un pod pour répondre à ses besoins réels.

Déclencheurs de création automatique de pools de nœuds : réaction aux demandes matérielles

La création automatique de pools de nœuds provisionne de nouveaux pools de nœuds avec du matériel spécialisé. Il n'est pas déclenché par des métriques de performances telles que la charge du processeur. Au lieu de cela, il est déclenché par la demande de ressources d'un pod :

  • Demande de ressource non planifiable : un déclencheur clé. Lorsqu'un pod est créé, il demande du matériel spécifique. Si le cluster ne peut pas répondre à cette demande, car aucun nœud existant ne dispose de ce matériel, la création automatique du pool de nœuds est déclenchée.
  • Demande ComputeClass : un pod demande une ComputeClass, par exemple cloud.google.com/compute-class: premium-gpu. Si aucun nœud du cluster ne peut fournir les fonctionnalités "premium-gpu", la création automatique de pools de nœuds crée automatiquement un pool de nœuds pouvant fournir ces fonctionnalités.

Pour apprendre à utiliser des métriques personnalisées, Prometheus et externes pour l'autoscaling, consultez À propos de l'autoscaling des charges de travail en fonction des métriques.

Conclusion

En appliquant ces stratégies d'autoscaling, vous pouvez gérer efficacement les charges de travail d'IA/ML fluctuantes. Tout comme le responsable du magasin Cymbal Shops a géré son événement commercial le plus important en gérant ses ressources de manière flexible, vous pouvez utiliser l'autoscaling GKE pour étendre et réduire automatiquement vos ressources d'infrastructure et de charge de travail. Cela permet de s'assurer que vos modèles restent performants lors des pics de trafic et rentables pendant les périodes calmes, en maintenant la taille de votre environnement adaptée.

Étapes suivantes