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

Info

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 à l'espace client OVHcloud

Lien direct :
Chemin de navigation : Public Cloud > Sélectionnez votre projet

Principes du scaling

Lors de la création d’une application via l’espace client 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.

Warning

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)

Depuis l'espace client (UI)

Depuis la CLI ovhai

Lors de la création de votre application, vous aurez l’occasion de choisir votre stratégie de scaling. Par défaut, la stratégie est définie sur le scaling statique. Pour utiliser cette stratégie, assurez-vous que le scaling automatique n’est pas activé. Vous devrez ensuite choisir le nombre de réplicas sur lesquels votre application sera exécutée.

Configurer le scaling statique sur AI Deploy depuis l'interface

Utilisez la commande ovhai app run avec le paramètre --replicas pour définir le nombre de réplicas au déploiement :

ovhai app run <registry-address>/<image-identifier>:<tag-name> \
    --replicas 2 \
    -- <optional-command>

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.

Info

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 :

Paramètre	Description
Minimum Replicas	Nombre minimum de réplicas en cours d’exécution. Lorsqu’il est défini sur 0, le nombre de réplicas sera réduit à 0 lorsque votre application ne reçoit plus d’appels pendant la période définie, limitant ainsi les coûts de votre app.
Maximum Replicas	Limite supérieure du nombre de réplicas (à définir en fonction des attentes d’usage).
Time before scaling down (s)	Nombre de secondes avant de passer de N à N-1 réplicas. La valeur par défaut est 300 s. Doit être supérieur ou égal à 0 et inférieur ou égal à 3600 (une heure).
Time before scaling to 0 (s)	Nombre de secondes avant de passer de 1 à 0 réplica. S’applique uniquement lorsque le nombre minimum de réplicas est défini sur 0. Une fois activé, ce délai doit être considéré en plus du paramètre `Time before scaling down`.
Time before scaling up (s)	Nombre de secondes avant de passer de N à N+1 réplicas. La valeur par défaut est 0 s. Doit être supérieur ou égal à 0 et inférieur ou égal à 3600 (une heure).
Monitored Metric	La métrique à surveiller. Choisissez entre `CPU`, `RAM` ou une métrique personnalisée pour déclencher les actions d’autoscaling.
Trigger Threshold (%)	Pourcentage d’utilisation moyenne utilisé pour déclencher la montée ou la descente en charge. Plage : 1 à 100 %.

Warning

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)

Depuis l'espace client (UI)

Depuis la CLI ovhai

Lors de la création de votre application, vous aurez l’occasion de choisir votre stratégie de scaling. Par défaut, la stratégie est définie sur le scaling statique. Basculez le bouton pour passer à l’autoscaling, puis configurez le nombre minimum/maximum de réplicas, la métrique et le seuil.

Configurer l'autoscaling sur AI Deploy depuis l'interface

Utilisez la commande ovhai app run avec les paramètres d’autoscaling suivants :

ovhai app run <registry-address>/<image-identifier>:<tag-name> \
    --auto-min-replicas 1 \
    --auto-max-replicas 5 \
    --auto-scale-down-stabilization-window-seconds <seconds> \
    --auto-scale-up-stabilization-window-seconds <seconds> \
    --auto-resource-type <CPU/RAM> \
    --auto-resource-usage-threshold <percent>

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.

Depuis l'espace client (UI)

Depuis la CLI ovhai

Pour activer l’autoscaling personnalisé, sélectionnez CUSTOM comme métrique surveillée dans l’interface, lors de l’étape Scaling. Vous devrez ensuite renseigner plusieurs champs :

Metric URL : 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.
Data format : format de la métrique sur laquelle scaler (JSON, XML, YAML, PROMETHEUS). La valeur par défaut est JSON.
Data location : 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.
Target value of the metric : 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.
Aggregation type : 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 est AVERAGE.

Activer l'autoscaling personnalisé sur AI Deploy depuis l'interface

Utilisez la commande ovhai app run avec les paramètres suivants :

Paramètre	Description
`--auto-custom-api-url`	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.
`--auto-custom-metric-format`	Format de la métrique sur laquelle scaler (`JSON`, `XML`, `YAML`, `PROMETHEUS`). La valeur par défaut est `JSON`.
`--auto-custom-value-location`	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.
`--auto-custom-target-value`	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.
`--auto-custom-metric-aggregation-type`	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 est `AVERAGE`.

Exemple :

Scaling basé sur une métrique personnalisée provenant d’un endpoint interne :

ovhai app run <registry-address>/<image-identifier>:<tag-name> \
    --auto-custom-api-url http://<SELF>:6000/metrics \
    --auto-custom-metric-format JSON \
    --auto-custom-value-location foo.bar \
    --auto-custom-target-value 42 \
    --auto-custom-metric-aggregation-type AVERAGE

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.

Depuis l'espace client (UI)

Depuis la CLI ovhai

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 section AI Deploy. Sur cette page, vous trouverez des informations générales sur votre application, dont une section Resources.

Tableau de bord de l'application AI Deploy my-app avec le panneau Resources mis en évidence affichant Automatic scaling avec minimum replicas 1 maximum replicas 5 metric monitored CPU et trigger threshold 75%

Dans cette fenêtre, cliquez sur le bouton Modifier pour accéder aux options de configuration du scaling. Cela ouvrira une fenêtre Update application scaling 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)

Mise à jour du scaling de l'application, étape 2

Pour modifier les stratégies de scaling depuis la CLI, utilisez la commande ovhai app scale avec les paramètres appropriés :

ovhai app scale [OPTIONS] <ID>

Mettre à jour le scaling statique

Pour modifier le nombre de réplicas d’une stratégie de scaling statique, utilisez la commande ovhai app scale avec le paramètre --replicas :

ovhai app scale --replicas <new-replicas-number> <app-id>

Mettre à jour l’autoscaling

Pour modifier les paramètres d’autoscaling, utilisez la commande ovhai app scale avec les paramètres suivants :

ovhai app scale \
    --auto-min-replicas <min> \
    --auto-max-replicas <max> \
    --auto-scale-down-stabilization-window-seconds <seconds> \
    --auto-scale-up-stabilization-window-seconds <seconds> \
    --auto-cooldown-period-seconds <seconds> \
    --auto-resource-type <CPU/RAM> \
    --auto-resource-usage-threshold <percent> \
    <app-id>

Mettre à jour l’autoscaling avec une métrique personnalisée

Options disponibles pour la Fixed Scaling Strategy :

ovhai app scale \
    --auto-min-replicas <min> \
    --auto-max-replicas <max> \
    --auto-scale-down-stabilization-window-seconds <seconds> \
    --auto-scale-up-stabilization-window-seconds <seconds> \
    --auto-cooldown-period-seconds <seconds> \
    --auto-custom-api-url <API URL> \
    --auto-custom-value-location <METRIC VALUE LOCATION> \
    --auto-custom-target-value <METRIC TARGET VALUE> \
    --auto-custom-metric-format <METRIC FORMAT> \
    --auto-custom-metric-aggregation-type <METRIC AGGREGATION TYPE> \
    <app-id>

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.

Info

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.

Nous voulons vos retours !

N’hésitez pas à nous faire part de vos questions, retours et suggestions pour améliorer le service :

Sur le serveur Discord OVHcloud

Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur ce lien pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.

Cette page vous a-t-elle aidé ?