AI Deploy - Stratégies de mise à l'échelle
Comprendre les stratégies de scaling (scaling statique vs autoscaling) d'AI Deploy et apprendre à les utiliser
AI Deploy est couvert par les Conditions particulières OVHcloud Public Cloud.
Objectif
Ce guide propose une compréhension complète des différentes stratégies de scaling pour AI Deploy. L’objectif est d’expliquer les différences entre le scaling statique et l’autoscaling, d’aider les utilisateurs à choisir entre les deux, à les définir lors de la création de l’app, et d’expliquer comment modifier les stratégies de scaling une fois les apps créées.
Prérequis
- Un projet Public Cloud actif.
- L’AI CLI OVHcloud (
ovhai) installée. Pour les instructions d’installation, consultez comment installer ovhai.
Accès à la console OVHcloud
- Lien direct :
- Pour accéder à vos services :
Public Cloud> Sélectionnez votre projet
Principes du scaling
Lors de la création d’une application via la console OVHcloud (interface) ou la CLI ovhai, vous pouvez choisir l’une des deux stratégies de scaling suivantes :
- Scaling statique : nombre fixe de réplicas en cours d’exécution.
- Autoscaling : réplicas dynamiques basés sur des métriques d’usage (CPU/RAM ou métriques personnalisées).
Scaling statique
Qu’est-ce que le scaling statique ?
Le scaling statique vous permet de configurer un nombre fixe de réplicas (instances identiques de votre application) en cours d’exécution en permanence. C’est la stratégie par défaut si aucune n’est spécifiée.
Le nombre minimum de réplicas est 1 et le maximum est 10.
Pour la haute disponibilité, il est fortement recommandé de déployer un minimum de 2 réplicas.
Quand choisir le scaling statique ?
- Vous avez des charges de travail prévisibles et constantes.
- Vous préférez des coûts fixes et prévisibles, sans pic imprévu d’utilisation des ressources.
- Votre cas d’usage nécessite une latence minimale, les réplicas étant toujours actifs.
Configurer le scaling statique (interface et CLI)
Lors de la création de votre application, vous choisissez votre stratégie de scaling dans la section Scalabilité. Par défaut, la stratégie est définie sur le scaling statique (Autoscaling désactivé). Pour utiliser cette stratégie, assurez-vous que l'autoscaling n’est pas activé. Renseignez ensuite le Nombre de réplicas sur lesquels sera déployée votre app.
Autoscaling
Qu’est-ce que l’autoscaling ?
L’autoscaling ajuste dynamiquement le nombre de réplicas de l’application en fonction de métriques en temps réel, telles que l’utilisation du CPU ou de la RAM. Cette stratégie est optimisée pour les charges de travail à la demande variable.
L’autoscaling s’ajuste en calculant l’utilisation moyenne des ressources sur l’ensemble des réplicas. Si la moyenne dépasse le seuil, de nouveaux réplicas sont ajoutés après le délai de montée en charge ; si elle passe en dessous, des réplicas sont supprimés après le délai de réduction.
Paramètres de configuration clés de l’autoscaling
Avec cette stratégie, il est possible de choisir :
Pour la haute disponibilité, il est fortement recommandé de déployer un minimum de 2 réplicas.
Si vous définissez le nombre minimum de réplicas sur 0, veuillez tenir compte des points suivants :
-
Comportement du scaling : en l’absence de trafic, votre app sera réduite à zéro réplica.
-
Latence de cold start : si une requête arrive alors qu’aucun réplica ne dessert votre app, un délai de cold start s’appliquera avant que l’app ne recommence à traiter les requêtes, allant de 30 secondes à plusieurs minutes selon votre image et le poids de vos volumes.
-
Risque de disponibilité des ressources : si vous utilisez un flavor très demandé, il existe un risque que votre app ne puisse PAS remonter en charge si ce flavor n’est plus disponible, empêchant votre app de traiter les requêtes entrantes.
-
Interaction entre paramètres : le délai avant de passer à 0 s’applique en plus du délai avant réduction. Cela signifie que le délai total avant qu’une app ne soit réduite à 0 correspond à la somme des deux paramètres.
Quand choisir l’autoscaling ?
- Votre app présente des schémas d’inférence/charge irréguliers ou fluctuants.
- Vous souhaitez un scaling économique, aligné sur l’usage réel.
- Vous gérez une application à fort débit sujette à des pics de demande soudains.
Configurer l’autoscaling (interface et CLI)
Lors de la création de votre application, vous choisissez votre stratégie de scaling dans la section Scalabilité. Par défaut, la stratégie est définie sur le scaling statique. Activez l'interrupteur pour passer à Autoscaling activé, puis configurez le Minimum de réplicas et le Maximum de réplicas, la Métrique surveillée et le Seuil de déclenchement (%), ainsi que la fenêtre de mise à l'échelle (Temps avant mise à l'échelle vers le bas (s), Temps avant mise à l'échelle vers le haut (s)).
Avancé : métriques personnalisées pour l’autoscaling
Pour des scénarios avancés, vous pouvez définir des métriques personnalisées pour piloter les décisions d’autoscaling. Cela est recommandé pour des charges de travail telles que l’inférence sur GPU, où l’utilisation du CPU et de la RAM ne donne qu’une vision incomplète de la performance du système ou de la charge de requêtes.
Cette fonctionnalité peut être utilisée depuis l’interface et la CLI, et nécessite un endpoint API pour récupérer les métriques.
Pour activer l’autoscaling personnalisé, sélectionnez CUSTOM comme Métrique surveillée dans la section Scalabilité. Vous devrez ensuite renseigner plusieurs champs :
- URL de la métrique : URL de l’opération API à appeler pour récupérer la valeur de la métrique. Un placeholder spécifique
<SELF>peut être utilisé lorsque l’API de métriques est servie par l’app déployée elle-même. - Format des données : format de la métrique sur laquelle scaler (
JSON,XML,YAML,PROMETHEUS). La valeur par défaut estJSON. - Emplacement des données : emplacement de la valeur de la métrique dans le payload de la réponse. Cette valeur dépend du format. Consultez le paramètre valueLocation dans la liste des paramètres de la documentation Trigger Specification pour plus de détails.
- Valeur cible de la métrique : valeur cible de la métrique sur laquelle scaler. Lorsque la métrique fournie par l’API est égale ou supérieure à cette valeur, la montée en charge est déclenchée. Si la métrique est inférieure ou égale à 0, le scaling revient à 0. Cette valeur peut être un nombre décimal.
- Type d'agrégation : type d’agrégation à effectuer avant de comparer la valeur de métrique agrégée à la valeur cible. Par exemple, si vous choisissez AVERAGE, la valeur comparée à la valeur cible pour le scaling sera la moyenne des valeurs de métrique de chaque réplica de votre app AI Deploy. Les options sont (
AVERAGE,MIN,MAX,SUM). La valeur par défaut estAVERAGE.
Modifier les stratégies de scaling après le déploiement
Vous pouvez également modifier la stratégie de scaling une fois l’app créée, via l’interface ou la commande CLI ovhai app scale.
Pour modifier les stratégies de scaling depuis l’interface, accédez à la page de détails de votre application en cliquant sur son nom dans la liste AI Deploy. Dans l'onglet Vue d’ensemble, vous trouverez des informations générales sur votre application, dont une carte Dimensionnement.
Dans cette carte, cliquez sur le bouton Modifier l'autoscaling pour accéder aux options de configuration du scaling. Cela ouvrira une fenêtre Modifier la stratégie de mise à l’échelle dans laquelle vous pouvez :
- Basculer entre l’autoscaling et le scaling statique
- Modifier les valeurs de réplicas
- Modifier la métrique surveillée et les valeurs associées
- Mettre à jour votre fenêtre de scaling (délai de montée en charge, de réduction ou de passage à 0)
Cliquez ensuite sur Enregistrer.
Exemples de scaling
Nous utiliserons l’exemple suivant :
Si une app repose sur le flavor AI1-1-CPU avec une taille de ressource de 2 (soit 2 CPU), chaque réplica de l’application disposera de 2 vCores et 8 Go de RAM.
Exemple 1
Nous choisissons d’abord l’autoscaling.
Nous définissons ensuite le seuil de déclenchement à 75 % de CPU.
Dans ce cas, l’app montera en charge lorsque l’utilisation moyenne du CPU sur l’ensemble de ses réplicas dépassera > 1,5 CPU (2*0,75), et redescendra lorsque l’utilisation moyenne du CPU passera sous < 1,5.
Exemple 2
Dans ce second exemple, nous choisissons l’autoscaling.
Nous définissons ensuite le seuil de déclenchement à 60 % de RAM.
Dans cet exemple, l’app montera en charge lorsque l’utilisation moyenne de la RAM sur l’ensemble de ses réplicas dépassera > 4,8 Go (8*0,60), et redescendra lorsque l’utilisation moyenne de la RAM repassera sous < 4,8 Go.
Le prix total du déploiement pour les apps en autoscaling est calculé sur la base du nombre minimum de réplicas, mais les coûts peuvent augmenter pendant le scaling.
Conclusion
Choisir la bonne stratégie de scaling est essentiel pour équilibrer coût, performance et fiabilité de vos applications AI Deploy. Le scaling statique offre stabilité et prévisibilité, tandis que l’autoscaling apporte de la flexibilité pour les charges de travail dynamiques.
Votre avis nous intéresse !
N’hésitez pas à nous faire part de vos questions, retours et suggestions pour améliorer le service :
- Sur le serveur Discord OVHcloud
Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.