Présentation de l'outil d'autoscaling

Cette page présente l'outil d'autoscaling pour Spanner, un outil Open Source que comme outil associé à Spanner. Cet outil vous permet d'augmenter ou de réduire automatiquement la capacité de calcul Instances Spanner en fonction de la capacité utilisée.

Pour en savoir plus sur le scaling dans Spanner, consultez la page Autoscaling Spanner. Pour sur le déploiement de l'outil Autoscaler, consultez les pages suivantes:

Cette page présente les fonctionnalités, l'architecture, la configuration et le déploiement de l'autoscaler. Les sujets abordés dans cette série via le déploiement de l'autoscaler dans chacune des topologies.

Autoscaler

L'autoscaler est utile pour gérer l'utilisation et les performances Déploiements Spanner. Pour vous aider à équilibrer le contrôle des coûts avec en termes de performances, l'outil d'autoscaler surveille vos instances ajoute ou supprime des nœuds ou des unités de traitement pour s'assurer qu'ils restent les paramètres suivants:

L'autoscaling des déploiements Spanner permet à votre infrastructure s'adaptent et évoluent automatiquement pour répondre aux exigences de charge avec peu ou pas et l'intervention. L'autoscaling redimensionne également l'infrastructure provisionnée, ce qui peut vous aider à réduire les coûts.

Architecture

Cette section décrit plus en détail les composants d'Autoscaler et leurs fonctions respectives.

L'architecture de l'outil Autoscaler se compose des éléments suivants : Cloud Scheduler , deux Pub/Sub sujets, deux Cloud Functions et Firestore pour en savoir plus. La API Cloud Monitoring permet d'obtenir des métriques sur l'utilisation du processeur et le stockage pour Spanner. Compute Engine.

Cloud Scheduler

En utilisant Cloud Scheduler , vous définissez la fréquence à laquelle l'outil d'autoscaling vérifie votre Spanner et le scaling des seuils de métriques. Une tâche Cloud Scheduler peut vérifier une ou plusieurs instances en même temps. Vous pouvez définir autant de planifications de tâches que nécessaire.

Fonction Cloud d'interrogation

Fonction Cloud Poller est responsable de la collecte et du traitement des métriques de séries temporelles plus d'instances Spanner. Poller prétraite les données de métriques pour chaque instance Spanner, de sorte que seuls les points de données les plus pertinents évaluée et envoyée à la fonction Cloud Scaler. Le prétraitement effectué par la fonction Cloud Poller simplifie également le processus Évaluer des seuils pour les emplacements régionaux, birégionaux et multirégionaux aux instances Spanner.

Fonction Cloud de scaling

Le scaler Cloud Functions évalue les points de données reçus de la fonction Cloud Poller détermine si vous devez ajuster le nombre de nœuds ou d'unités de traitement et, si oui, dans quelle mesure. La fonction Cloud compare les valeurs de la métrique au seuil, plus ou moins une valeur marge , et ajuste le nombre de nœuds ou d'unités de traitement en fonction de la configuration de mise à l'échelle. Pour en savoir plus sur les méthodes de scaling, consultez la page Fonctionnalités de l'autoscaler. pour en savoir plus.

Flux opérationnel

Cette section détaille le modèle opérationnel de l'outil Autoscaler, dans le schéma d'architecture suivant.

Modèle opérationnel d'Autoscaler.

  1. Vous définissez la planification, l'heure et la fréquence de vos jobs d'autoscaling dans Cloud Scheduler.
  2. Sur la planification que vous définissez, Cloud Scheduler transmet un message contenant une charge utile JSON avec les paramètres de configuration de l'outil Autoscaler pour une ou plusieurs instances Spanner sujet Pub/Sub.
  3. Lorsque le message est publié dans le sujet d'interrogation, une instance de la fonction Cloud d'interrogation est créée pour gérer le message.
  4. Fonction Cloud Poller lit la charge utile du message et interroge l'API Cloud Monitoring pour récupérer pour chaque instance Spanner.
  5. Pour chaque instance Spanner énumérée dans le message, le La fonction d'interrogation transmet un message au scaling Pub/Sub contenant les métriques et les paramètres de configuration à évaluer pour une instance Spanner spécifique.

  6. Pour chaque message envoyé dans le sujet "Scaler", le scaler Cloud Functions effectue les opérations suivantes:

    1. Il compare les métriques de l'instance Spanner avec des seuils configurés, plus ou moins une valeur marge.

    Vous pouvez la configurer vous-même ou utiliser la valeur par défaut. 1. Elle détermine si l'instance doit subir un scaling ou non. 1. Calcule le nombre de nœuds ou d'unités de traitement que l'instance doit être ajusté en fonction de la méthode de scaling choisie.

  7. La fonction Cloud "Scaler" récupère l'heure à laquelle l'instance a effectué un scaling à partir de Firestore et le compare pour déterminer si un scaling à la hausse ou à la baisse est autorisé en fonction de la période de stabilisation périodes.

  8. Si la période d'attente configurée est passée, le Scaler La fonction Cloud envoie une requête au service Scaling à la hausse ou à la baisse de l'instance.

Tout au long du flux, l'autoscaler rédige un résumé de ses recommandations. et des actions pour Cloud Logging pour le suivi et l'audit.

Quelle que soit la topologie de déploiement, que vous choisissez, le fonctionnement global de l'outil d'autoscaler reste le même.

Fonctionnalités d'Autoscaler

Cette section décrit les principales fonctionnalités de l'autoscaler.

Gérer plusieurs instances

L'autoscaler est capable de gérer plusieurs instances Spanner plusieurs projets. Les instances multirégionales, birégionales et régionales disposent toutes différents seuils d'utilisation utilisés lors du scaling. Par exemple, les déploiements multirégionaux et birégionaux font l'objet d'un scaling à 45% du processeur à priorité élevée l'utilisation, tandis que les déploiements régionaux sont ajustés avec 65% de ressources d'utilisation, plus ou moins une valeur marge. Pour en savoir plus sur les différents seuils de scaling, consultez Alertes en cas d'utilisation intensive du processeur

Paramètres de configuration indépendants

Chaque instance Spanner avec autoscaling peut comporter une ou plusieurs interrogations programmations. Chaque planification d'interrogation possède son propre ensemble de paramètres de configuration.

Ces paramètres déterminent les facteurs suivants :

  • Nombre minimal et maximal de nœuds ou d'unités de traitement qui contrôlent la manière dont qu'elles soient petites ou grandes, ce qui vous aide à maîtriser les coûts.
  • Méthode de scaling pour adapter votre instance Spanner à votre charge de travail.
  • Les périodes d'attente pour permettre à Spanner de gérer les divisions de données.

Différentes méthodes de scaling pour différentes charges de travail

L'outil Autoscaler propose trois méthodes différentes pour le scaling à la hausse et à la baisse. le scaling des instances Spanner: par étapes, linéaires et directs ; Chaque est conçue pour gérer différents types de charges de travail. Vous pouvez appliquer un ou de méthodes supplémentaires pour chaque instance Spanner faisant l'objet d'un autoscaling lorsque vous créez des calendriers de sondage indépendants.

Par étapes

Le scaling par étapes est utile pour les charges de travail présentant des pics petits ou multiples. Il de la capacité pour les lisser avec un seul événement d'autoscaling.

Le graphique suivant présente un modèle de charge avec des plateaux ou étapes de charge multiples, où chaque étape comporte plusieurs petits pics. Ce modèle est particulièrement adapté à la méthode par étapes.

Schéma de charge avec des étapes multiples.

Lorsque le seuil de charge est franchi, cette méthode provisionne et supprime des nœuds ou d'unités de traitement à l'aide d'un nombre fixe, mais configurable. Par exemple, trois nœuds sont ajoutées ou supprimées pour chaque action de scaling. En modifiant la configuration, vous permet d'ajouter ou de supprimer des augmentations de capacité à tout moment.

Linéaire

Le scaling linéaire est préférable avec des modèles de charge qui changent plus progressivement ou présentent quelques pics importants. La méthode calcule le nombre minimal de nœuds ou d'unités de traitement requis pour maintenir l'utilisation en dessous du seuil de scaling. La le nombre de nœuds ou d'unités de traitement ajoutés ou supprimés dans chaque événement de scaling est égal à pas seulement à un nombre de pas fixe.

L'exemple de modèle de charge dans le graphique suivant montre des augmentations et des diminutions soudaines plus importantes de la charge. Ces fluctuations ne sont pas regroupées dans des étapes perceptibles, comme elles l'étaient dans le graphique précédent. Ce modèle est plus facile à gérer à l'aide du scaling linéaire.

Schéma de charge avec fluctuations.

L'outil Autoscaler utilise le ratio d'utilisation observée sur le le seuil d'utilisation pour calculer s'il faut ajouter ou soustraire des nœuds, d'unités de traitement à partir du nombre total actuel.

La formule permettant de calculer le nouveau nombre de nœuds ou d'unités de traitement se présente comme suit :

newSize = currentSize * currentUtilization / utilizationThreshold

Direct

Le scaling direct offre une augmentation immédiate de la capacité. Cette méthode est destinée à gérer les charges de travail par lots dans lesquelles un nombre de nœuds prédéterminé plus élevé est périodiquement exigé dans une planification avec une heure de début connue. Cette méthode effectue un scaling l'instance jusqu'au nombre maximal de nœuds ou d'unités de traitement spécifié du calendrier. Il est destiné à être utilisé en complément d'un suivi linéaire ou par étapes .

Le graphique suivant décrit l'augmentation planifiée importante de la charge, pour laquelle Autoscaler a préprovisionné la capacité à l'aide de la méthode directe.

Modèle de charge avec scaling direct préprovisionné.

Une fois la charge de travail par lot terminée et l'utilisation repassée à un niveau normal, selon votre configuration, le scaling linéaire ou par étapes est appliqué pour effectuer un scaling à la baisse de l'instance automatiquement.

Méthodes de déploiement

L'outil Autoscaler peut être déployé dans un projet individuel ou en même temps des instances Spanner qu'il gère. L'autoscaler est conçu permet une plus grande flexibilité et s'adapte à la séparation entre vos équipes chargées des opérations et des applications. La la responsabilité de configurer l'autoscaling des instances Spanner peut être centralisée avec une seule équipe chargée des opérations ou distribuée les équipes les plus proches des applications qu'ils gèrent Compute Engine.

Les différents modèles de déploiement sont abordés plus en détail dans Topologies de déploiement

Sans serveur pour une simplicité du déploiement et de la gestion

L'outil Autoscaler est conçu uniquement à l'aide de Google Cloud sans serveur et à faible gestion tels que Cloud Functions, Pub/Sub, Cloud Scheduler et Firestore. Cette approche minimise le coût et les coûts opérationnels liés à l'exécution de l'autoscaler.

Grâce aux outils Google Cloud intégrés, l'autoscaler peut exploiter les avantages offerts par IAM (IAM) pour l'authentification et l'autorisation.

Configuration

L'outil Autoscaler propose différentes options de configuration que vous pouvez utiliser pour gérer le scaling de vos déploiements Spanner. Les sections suivantes décrire les options de configuration de base et les options de configuration plus avancées.

Configuration de base

L'outil Autoscaler gère les instances Spanner via la configuration définies dans Cloud Scheduler. Si plusieurs instances Spanner ont besoin doivent être interrogées avec le même intervalle, nous vous recommandons de les configurer même job Cloud Scheduler. La configuration de chaque instance représentée sous forme d'objet JSON. Voici un exemple de configuration où deux instances Spanner sont gérées Job Cloud Scheduler:

   [
    {
        "projectId": "my-spanner-project", "instanceId": "spanner1",
        "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
        "units": "NODES", "minSize": 1, "maxSize": 3
     },
     {
        "projectId":
        "different-project", "instanceId": "another-spanner1", "scalerPubSubTopic":
        "projects/my-spanner-project/topics/spanner-scaling", "units":
        "PROCESSING_UNITS", "minSize": 500, "maxSize": 3000, "scalingMethod": "DIRECT"
    }
   ]

Les instances Spanner peuvent avoir plusieurs configurations sur différents Jobs Cloud Scheduler. Par exemple, une instance peut disposer d'une configuration Autoscaler avec la méthode linéaire pour les opérations normales, mais aussi d'une autre configuration Autoscaler avec la méthode directe pour les charges de travail par lot planifiées.

Lorsque la tâche Cloud Scheduler s'exécute, elle envoie un message Pub/Sub au sujet Pub/Sub d'interrogation. La charge utile de ce message correspond au tableau JSON des objets de configuration pour toutes les instances configurées dans la même tâche. Consultez la liste complète des options de configuration dans le fichier README d'interrogation.

Configuration avancée

L'autoscaler dispose d'options de configuration avancées qui vous permettent contrôler quand et comment vos instances Spanner sont gérées. Les éléments suivants : présentent une sélection de ces commandes.

Seuils personnalisés

L'autoscaler détermine le nombre de nœuds ou d'unités de traitement ajouté ou soustrait à une instance à l'aide de la méthode seuils Spanner recommandés pour les métriques de charge suivantes:

  • Processeur à priorité élevée
  • Utilisation du processeur, moyenne glissante de 24 heures
  • Utilisation du stockage

Nous vous recommandons d'utiliser les seuils par défaut, comme décrit dans Créer des alertes pour les métriques Spanner pour en savoir plus. Toutefois, dans certains cas, vous souhaiterez peut-être modifier les seuils utilisés par l'outil Autoscaler. Par exemple, vous pouvez définir des seuils plus bas L'outil d'autoscaler réagit plus rapidement que pour les seuils plus élevés. Cette modification permet d'éviter le déclenchement d'alertes à des seuils plus élevés.

Métriques personnalisées

Bien que les métriques par défaut de l'outil autoscaler répondent à la plupart des besoins de scaling, vous devrez peut-être parfois spécifier propres métriques utilisées pour déterminer quand effectuer un scaling vertical et horizontal. Pour ces scénarios, vous définissez des métriques personnalisées dans la configuration metrics .

Marges

Une marge définit une limite supérieure et inférieure au seuil. L'autoscaler ne déclenche un événement d'autoscaling que si la valeur de la métrique est supérieure à la limite supérieure ou inférieure à la limite inférieure.

L'objectif de ce paramètre est d'éviter les déclenchements d'événements d'autoscaling pour les fluctuations de charge de travail mineures autour du seuil, réduisant ainsi la fluctuation des actions d'Autoscaler. Ensemble, le seuil et la marge définissent plage suivante, en fonction de la valeur de métrique souhaitée: 

[threshold - margin, threshold + margin]
Plus la marge est faible, plus la plage est étroite, ce qui donne un la probabilité qu'un événement d'autoscaling soit déclenché.

La spécification d'un paramètre de marge pour une métrique est facultative et sa valeur par défaut est de cinq points de pourcentage, avant et sous le paramètre.

Topologies de déploiement

Pour déployer l'outil d'autoscaler, déterminez la meilleure topologie parmi les suivantes. pour répondre à vos besoins techniques et opérationnels:

  • Topologie par projet: l'infrastructure de l'autoscaler est déployée dans le qui doit faire l'objet d'un autoscaling.
  • Topologie centralisée: l'outil d'autoscaling est déployé dans un projet et gère une ou plusieurs instances Spanner dans différents projets.
  • Topologie distribuée : la majeure partie de l'infrastructure de l'autoscaler est déployée dans un projet, mais certains composants d'infrastructure sont déployés Instances Spanner en cours d'autoscaling dans différents projets.

Topologie par projet

Dans un déploiement de topologie par projet, chaque projet avec une instance Spanner devant être soumis à un autoscaling a également son propre déploiement indépendant des composants d'Autoscaler. Nous recommandons cette topologie aux équipes indépendantes qui souhaitent gérer leurs propres configuration et infrastructure d'Autoscaler. C'est aussi un est un bon point de départ pour tester les fonctionnalités de l'autoscaler.

Le schéma suivant présente une vue conceptuelle générale d'un déploiement par projet.

Vue conceptuelle d'un déploiement par projet.

Les déploiements par projet illustrés dans le schéma précédent comportent ces caractéristiques:

  • Deux applications, Application 1 et Application 2, utilisent chacune leur propre aux instances Spanner.
  • Les instances Spanner (A) se trouvent dans l'application 1 et Projets Application 2
  • Un autoscaler indépendant (B) est déployé dans chaque projet pour contrôler l'autoscaling des instances d'un projet.

Pour obtenir un schéma plus détaillé d'un déploiement par projet, consultez la Architecture .

Un déploiement par projet présente les avantages et les inconvénients suivants.

Avantages :

  • Conception la plus simple: la topologie par projet est la conception la plus simple du trois topologies, car tous les composants de l'autoscaler sont déployés les instances Spanner concernées par l'autoscaling.
  • Configuration: le contrôle des paramètres du planificateur appartient à l'équipe propriétaire de l'instance Spanner, ce qui offre à l'équipe la liberté d'adapter l'outil Autoscaler à ses besoins par rapport à une solution centralisée ou une topologie distribuée.
  • Limite claire de la responsabilité de l'infrastructure : la conception d'une topologie par projet établit une limite claire de responsabilité et de sécurité sur l'infrastructure d'Autoscaler, car le propriétaire d'équipe des instances Spanner est également propriétaire de l'infrastructure d'Autoscaler.

Inconvénients :

  • Une maintenance globale plus importante: chaque équipe est responsable de l'autoscaler. la configuration et l'infrastructure. Il peut donc devenir difficile de s'assurer que tous les outils d'autoscaler de l'entreprise suivent la même mise à jour consignes.
  • Audit plus complexe : chaque équipe ayant un haut niveau de contrôle, un audit centralisé peut devenir plus complexe.

Pour savoir comment configurer l'autoscaler à l'aide d'une topologie par projet, consultez Déployez un outil d'autoscaler centralisé ou par projet pour Spanner.

Topologie centralisée

Comme dans la topologie par projet, dans un déploiement de topologie centralisé, de l'outil Autoscaler se trouvent dans le même projet. Cependant, les instances Spanner se trouvent dans des projets différents. Ce de déploiement est adapté à une équipe qui gère la configuration et l'infrastructure plusieurs instances Spanner à partir d'un seul déploiement de l'autoscaler en un seul endroit.

Le schéma suivant présente une vue conceptuelle générale d'un déploiement de projet centralisé :

Vue conceptuelle d'un déploiement de projet centralisé.

Le déploiement centralisé illustré dans le schéma précédent présente les caractéristiques suivantes :

  • Deux applications, Application 1 et Application 2, utilisent chacune leur propre aux instances Spanner.
  • Les instances Spanner (A) se trouvent dans l'application 1 et Projets Application 2
  • L'autoscaler (B) est déployé dans un projet distinct pour contrôler des instances Spanner des instances d'application 1 Projets Application 2

Pour obtenir un schéma plus détaillé d'un déploiement de projet centralisé, consultez Déployez un outil d'autoscaler centralisé ou par projet pour Spanner.

Un déploiement centralisé présente les avantages et les inconvénients suivants :

Avantages :

  • Configuration et infrastructure centralisées: une seule équipe contrôle les paramètres du programmeur et l'infrastructure de l'autoscaler. Cette approche peut être utiles dans les secteurs hautement réglementés.
  • Maintenance globale réduite: les opérations de maintenance et de configuration sont généralement inférieures. à maintenir par rapport à un déploiement par projet.
  • Règles et audits centralisés : les bonnes pratiques des différentes équipes peuvent être plus simples à spécifier et à exécuter. Les audits peuvent être plus faciles à exécuter.

Inconvénients :

  • Configuration centralisée: toute modification des paramètres de l'autoscaler nécessite de passer par l'équipe centralisée, même si l'équipe qui demande modifié est propriétaire de l'instance Spanner.
  • Potentiel de risque supplémentaire: l'équipe centralisée elle-même peut devenir un point de défaillance unique, même si l'infrastructure de l'autoscaler est conçue tout en gardant à l'esprit la haute disponibilité.

Pour consulter un tutoriel par étapes sur la configuration de l'outil d'autoscaling à l'aide de cette option, consultez consultez l'article Déployer un outil d'autoscaler centralisé ou par projet pour Spanner.

Topologie distribuée

Dans un déploiement de topologie distribuée, Cloud Scheduler et Les instances Spanner nécessitant un autoscaling se trouvent dans le même projet. Les autres composants de l'autoscaler sont centralisés géré par Google. Il s'agit d'un déploiement hybride. Les équipes qui possèdent Les instances Spanner ne gèrent que la configuration de l'autoscaler pour leurs instances, et une équipe centrale gère le reste Infrastructure d'autoscaler

Le schéma suivant présente une vue conceptuelle globale d'un dans un déploiement de projet distribué.

Vue conceptuelle d'un déploiement de projet distribué.

Le déploiement hybride illustré dans le schéma précédent présente les caractéristiques suivantes :

  • Deux applications, Application 1 et Application 2, utilisent leurs propres aux instances Spanner.
  • Les instances Spanner (A) se trouvent dans les projets de l'Application 1 et de l'Application 2.
  • Un composant Cloud Scheduler indépendant (C) est déployé dans chaque projet: Application 1 et Application 2.
  • Les composants restants d'Autoscaler (B) sont déployés dans un projet distinct.
  • L'outil Autoscaler assure l'autoscaling des instances Spanner dans les Les projets Application 1 et Application 2 utilisant les configurations envoyées par les composants Cloud Scheduler indépendants de chaque projet.

Pour obtenir un schéma plus détaillé du déploiement de projet centralisé, consultez Déployez un outil d'autoscaler distribué pour Spanner.

Un déploiement distribué présente les avantages et les inconvénients suivants :

Avantages :

  • Les équipes chargées des applications contrôlent la configuration et les plannings: Cloud Scheduler est déployé en même temps que Spanner d'instances faisant l'objet d'un autoscaling, ce qui donne plus de contrôle aux équipes de développement sur la configuration et la planification.
  • L'équipe chargée des opérations contrôle l'infrastructure: les composants fondamentaux Les autoscalers sont déployés de manière centralisée, ce qui permet aux équipes chargées des opérations de contrôler l'infrastructure de l'autoscaler.
  • Maintenance centralisée: l'infrastructure du Scaler est centralisée, ce qui réduit ou d'autres frais généraux.

Inconvénients :

  • Configuration plus complexe: les équipes en charge des applications doivent fournir un service pour écrire dans le sujet de sondage.
  • Risque supplémentaire de risque: l'infrastructure partagée peut devenir point de défaillance unique, même si l'infrastructure est conçue avec des la disponibilité.

Pour savoir comment configurer l'autoscaler dans un déploiement distribué, consultez Déployez un outil d'autoscaler distribué pour Spanner.

Divisions des données

Spanner attribue des plages de données appelées divisions aux nœuds ou aux subdivisions. d'un nœud appelées unités de traitement. Le nœud ou les unités de traitement indépendamment gérer et diffuser les données dans les répartitions réparties. Les divisions de données sont créées en fonction de plusieurs facteurs, dont le volume de données et les modes d'accès. Pour plus détails, consultez Spanner – Schéma et modèle de données pour en savoir plus.

Les données sont divisées en divisions, et Spanner gère automatiquement les écrans fractionnés. Ainsi, lorsque l'outil d'autoscaling ajoute ou supprime des nœuds ou des unités de traitement, il doit laisser suffisamment de temps au backend Spanner pour réattribuer réorganiser les divisions à mesure que de nouvelles capacités sont ajoutées ou supprimées des instances.

L'outil Autoscaler utilise des périodes d'attente pour les événements de scaling à la hausse et à la baisse. pour contrôler la vitesse à laquelle il peut ajouter ou supprimer des nœuds ou des unités de traitement Compute Engine. Avec cette méthode, l'instance dispose du temps nécessaire pour réorganiser les relations entre les notes de calcul ou les unités de traitement et les divisions de données. Par par défaut, les périodes d'attente pour le scaling à la hausse et à la baisse sont définies comme suit : valeurs minimales:

  • Valeur de scaling à la hausse : 5 minutes
  • Valeur de scaling à la baisse : 30 minutes

Pour en savoir plus sur les recommandations de scaling et les périodes de stabilisation, consultez Effectuer le scaling d'instances Spanner

Coûts

L'outil autoscaler consomme peu de ressources. Dans la plupart des cas, sont négligeables. Autoscaler est gratuit lorsqu'il est utilisé sur Google Cloud. Exemple , qui exécute un autoscaler pour gérer trois instances Spanner avec une un intervalle d'interrogation de 5 minutes pour chaque instance est disponible sans frais. Ce estimation comprend les éléments suivants:

  • 3 tâches Cloud Scheduler
  • 0,15 Go de messages Pub/Sub
  • 51 840 appels de 500 ms de la fonction Cloud
  • Moins de 10 Mo de données dans Firestore

L'estimation n'inclut pas les coûts des opérations de la base de données Spanner. Utilisez la Simulateur de coût pour générer une estimation des coûts en fonction de votre utilisation prévue.

Étape suivante