Résoudre les problèmes liés à l'autoscaling de Dataflow

Cette page explique comment résoudre les problèmes liés aux fonctionnalités d'autoscaling de Dataflow et fournit des informations concernant la gestion de l'autoscaling.

La tâche n'évolue ni à la hausse ni à la baisse

Cette section fournit des informations sur les scénarios susceptibles d'empêcher les nœuds de calcul d'effectuer un scaling à la hausse ou à la baisse.

La tâche de traitement en flux continu n'effectue pas de scaling à la hausse

Lorsque votre pipeline de traitement en flux continu comprend des éléments en attente, les nœuds de calcul n'effectuent pas de scaling à la hausse.

Ce problème survient lorsque les tâches en attente durent moins de quelques minutes ou lorsque le parallélisme est limité.

Parfois, le nombre de tâches en attente est important, mais le parallélisme est faible. Dans ce cas, Dataflow n'effectue pas de scaling à la hausse, car le travail ne peut pas être réparti entre davantage de nœuds de calcul. L'ajout de nœuds de calcul n'aiderait donc pas au traitement. Pour en savoir plus, consultez la section Autoscaling de flux.

Les tâches par lot et par flux n'effectuent pas de scaling à la hausse

Votre tâche par lot ou par flux s'exécute comme prévu, mais lorsqu'un nombre supplémentaire de nœuds de calcul est nécessaire, elle n'effectue pas de scaling à la hausse.

Ce problème peut survenir pour l'une des raisons suivantes :

  • Les fichiers de préproduction ou temporaires sont inaccessibles. Si votre tâche utilise un bucket Cloud Storage, celui-ci peut comporter une configuration de cycle de vie qui supprime les objets qu'il contient. Les objets supprimés incluent les dossiers et fichiers de préproduction et temporaires. Pour vérifier si des fichiers ont été supprimés, vérifiez la configuration du cycle de vie du bucket. Si les dossiers ou les fichiers temporaires ou de préproduction ont été supprimés après le démarrage du job, il est possible que les packages requis pour créer de nouveaux nœuds de calcul n'existent pas. Pour résoudre ce problème, recréez les dossiers et les fichiers dans le bucket.
  • Les règles de pare-feu empêchent les nœuds de calcul d'envoyer et de recevoir du trafic sur les ports TCP nécessaires. Les règles de pare-feu peuvent empêcher les nœuds de calcul de démarrer. Les nœuds de calcul Dataflow doivent pouvoir envoyer et recevoir du trafic sur les ports TCP 12345 et 12346. Pour en savoir plus, y compris sur la procédure à suivre pour résoudre ce problème, consultez la section Règles de pare-feu pour Dataflow.
  • Une source personnalisée a une méthode getProgress() qui renvoie une valeur NULL. Lorsque vous utilisez une source personnalisée, les métriques de messages en attente s'appuient sur la valeur de renvoi de la méthode getProgress() de votre source personnalisée pour commencer à collecter des données. L'implémentation par défaut pour getProgress() renvoie une valeur NULL. Pour résoudre ce problème, assurez-vous que votre source personnalisée remplace la méthode getProgress() par défaut afin de renvoyer une valeur non nulle.
  • Une mise à jour déclenchée par l'autoscaling vertical désactive temporairement l'autoscaling horizontal. Pour en savoir plus, consultez la page Effet sur l'autoscaling horizontal.
  • Si vous utilisez une opération map dans un pipeline Python et que votre tâche n'effectue pas de scaling à la hausse, vous devrez peut-être ajouter une transformation Reshuffle à votre code de pipeline. Pour en savoir plus, consultez la page Rebrassage de la documentation Apache Beam.

La tâche de traitement en flux continu n'effectue pas de scaling à la baisse

Lorsque votre tâche de traitement en flux continu présente un faible nombre de tâches en attente et une faible utilisation du processeur, aucun scaling à la baisse des nœuds de calcul n'est effectué. Ce problème peut survenir pour plusieurs raisons.

  • Lorsque les jobs n'utilisent pas Streaming Engine, Dataflow équilibre le nombre de disques persistants entre les nœuds de calcul. Par conséquent, chaque nœud de calcul doit disposer d'un nombre égal de disques persistants. Par exemple, s'il y a 100 disques et 100 nœuds de calcul, chaque nœud de calcul dispose d'un disque. Lorsqu'un scaling à la baisse est effectué, le job peut avoir 50 nœuds de calcul avec deux disques persistants par nœud de calcul. Le job ne réduit plus sa capacité jusqu'à ce qu'il puisse avoir 25 nœuds de calcul avec quatre disques persistants par nœud de calcul. De plus, le nombre minimal de nœuds de calcul correspond à la valeur attribuée à maxNumWorkers divisée par 15. Pour plus d'informations, consultez la section Plage de scaling des pipelines d'autoscaling en flux continu.

  • Lorsque les jobs utilisent Streaming Engine, l'objectif de scaling à la baisse est basé sur une utilisation de CPU cible de 75 %. Lorsque cette utilisation de processeur ne peut pas être atteinte, le scaling à la baisse est désactivé.

  • L'estimation du temps d'attente doit être inférieure à dix secondes pendant au moins deux minutes avant qu'un scaling à la baisse des nœuds de calcul ne soit effectué. Les fluctuations du temps d'attente peuvent désactiver le scaling à la baisse. De plus, un débit faible peut fausser l'estimation du temps d'attente.

  • PeriodicImpulse est compatible avec les versions 2.60.0 et ultérieures du SDK Apache Beam. Lorsque votre pipeline utilise PeriodicImpulse avec les versions 2.59.0 et antérieures du SDK Apache Beam, les nœuds de calcul Dataflow n'effectuent pas de scaling à la baisse comme prévu.

Le scaling à la hausse s'est arrêté

Un scaling à la hausse pour votre tâche par lot ou par flux commence à être effectué, mais le nombre de nœuds de calcul arrête d'augmenter, même s'il reste des éléments en attente.

Ce problème se produit lorsque les limites de quota sont atteintes.

  • Quotas Compute Engine : les tâches Dataflow sont soumises au quota Compute Engine du projet. Si plusieurs jobs sont en cours d'exécution, le projet a peut-être atteint la limite de son quota Compute Engine. Dans ce cas, Dataflow ne peut pas augmenter le nombre de nœuds de calcul.
  • Quotas de processeurs : les tâches Dataflow sont également soumises au quota de processeurs du projet. Si le type de nœud de calcul utilise plusieurs processeurs, le projet peut avoir atteint la limite du quota de processeurs.
  • Quotas d'adresses IP externes : lorsque votre tâche utilise des adresses IP externes pour communiquer avec les ressources, vous avez besoin d'autant d'adresses IP externes que de nœuds de calcul. Lorsque le nombre de nœuds de calcul évolue à la hausse, le nombre d'adresses IP externes augmente également. Lorsque vous atteignez la limite d'adresses IP, le nombre de nœuds de calcul cesse d'augmenter.

De plus, si une ressource n'est plus disponible dans la région que vous choisissez, vous ne pouvez pas créer de ressources de ce type, même si vous disposez du quota restant dans votre région ou votre projet. Par exemple, vous pouvez posséder suffisamment de quota pour créer des adresses IP externes dans us-central1, mais cette région peut ne pas posséder d'adresses IP disponibles. Pour en savoir plus, consultez la section Quotas et disponibilité des ressources.

Pour résoudre ce problème, demandez une augmentation de quota ou exécutez le job dans une autre région.

L'indice d'utilisation des nœuds de calcul n'a aucun effet

Vous définissez l'optimisation de l'utilisation des nœuds de calcul, mais le comportement d'autoscaling ne change pas.

Pour comprendre ce problème, accédez au graphique d'utilisation du processeur des nœuds de calcul et vérifiez si la suggestion d'utilisation des nœuds de calcul est utilisée activement. Si l'indice est utilisé, le graphique affiche CPU utilization hint (actively used by autoscaler). Sinon, il affiche CPU utilization hint (not actively used by autoscaler).

L'optimisation de l'utilisation n'est qu'un des facteurs qui affectent l'autoscaling. Le tableau suivant répertorie certaines raisons pour lesquelles l'autoscaler peut ne pas utiliser activement l'optimisation :

Comportement de scaling observé Causes Métriques à vérifier
Aucune modification
  • Vous avez atteint le nombre minimal ou maximal de nœuds de calcul.
  • Le nombre de nœuds de calcul est limité par le nombre de clés traitées en parallèle.
  • Les jobs sont limités par des RPC externes.
  • L'ajustement de scaling à la baisse est trop faible ou Dataflow atténue le scaling à la baisse. Pour en savoir plus, consultez la section Heuristique d'autoscaling de flux.
Effectuer un scaling à la hausse
  • Un objectif de tâches en attente ou de latence élevé ignore les valeurs d'optimisation.
  • Le nombre minimal de nœuds de calcul a été mis à jour avec une valeur supérieure au nombre actuel de nœuds de calcul.
Scaling à la baisse
  • Le nombre maximal de nœuds de calcul a été remplacé par une valeur inférieure au nombre actuel de nœuds de calcul.

Pour en savoir plus, consultez la section Heuristique d'autoscaling de flux.

Résoudre les problèmes liés aux programmations d'autoscaling

Si vous rencontrez des problèmes lors de la création, de la mise à jour ou de l'exécution de planifications d'autoscaling, consultez les scénarios courants et les étapes de dépannage suivants.

Impossible de définir ou de mettre à jour une programmation d'autoscaling

Si une tentative de création ou de mise à jour d'une planification d'autoscaling échoue, vérifiez que la configuration de votre planification respecte les contraintes suivantes :

  • Limite de planifications : un job peut comporter jusqu'à 10 planifications d'autoscaling. Pour ajouter une programmation lorsque le job en compte déjà 10, vous devez d'abord supprimer une programmation existante.
  • Durée minimale : la durée de la programmation doit être d'au moins 5 minutes (300 secondes).
  • Contraintes de paramètres :
    • L'objectif d'utilisation du processeur doit être compris entre 0,1 et 0,9.
    • Le nombre maximal de nœuds de calcul doit être supérieur ou égal au nombre minimal de nœuds de calcul (max_workers ≥ min_workers).
  • Restrictions de format Crontab au démarrage de la tâche : les expressions Crontab spécifiées au lancement de la tâche à l'aide de l'option de pipeline --experiments=autoscaling_schedule=... ne peuvent pas contenir de virgules (telles que 1,15 * * * * ou * * * * MON,WED,FRI). Les virgules sont réservées pour délimiter les options de pipeline. Si votre planification nécessite des virgules, lancez le job sans la planification et configurez-le après le lancement à l'aide d'une mise à jour en cours, ou spécifiez plusieurs planifications distinctes.

La programmation ne prend pas effet ou une autre programmation est appliquée

Si une planification d'autoscaling ne prend pas effet pendant la période prévue, ou si les paramètres d'une autre planification sont appliqués, vérifiez les points suivants :

  • Une seule planification est active à la fois : si deux planifications ou plus ont des périodes qui se chevauchent, Dataflow détermine la planification à appliquer en fonction de la priorité de la planification :
    • La programmation ayant la valeur de priorité la plus élevée (priority) est appliquée.
    • Si plusieurs planifications actives partagent la même valeur de priorité, la planification la plus récemment mise à jour ou modifiée est appliquée.
    • Lorsque la durée de la programmation active se termine, Dataflow applique toute autre programmation encore active ou rétablit le comportement d'autoscaling par défaut du job.
  • Écarts de fuseau horaire : vérifiez que le fuseau horaire spécifié pour votre programmation correspond à la région prévue et aux règles d'heure d'été. Par défaut, les heures de début de la programmation sont interprétées en UTC.
  • Vérifiez les planifications actives dans la console : dans la console Google Cloud , accédez à l'onglet Autoscaling sur la page d'informations du job Dataflow pour voir quelle planification est active. Vous pouvez également inspecter les programmations configurées et leurs paramètres en exécutant la commande gcloud dataflow jobs describe ou en interrogeant l'API REST.

Le pipeline n'effectue pas de scaling à la hausse jusqu'au nombre de nœuds de calcul planifié

Si une planification s'active avec des limites de nœuds de calcul plus élevées ou des indications d'utilisation plus faibles, mais que le pipeline n'effectue pas de scaling à la hausse jusqu'au nombre de nœuds de calcul attendu, vérifiez les facteurs suivants :

  • Limites de ressources et de quotas : le scaling à la hausse nécessite un quota de ressources suffisant dans votre projet et votre région Google Cloud . L'allocation de nœuds de calcul peut être empêchée par :
    • Quotas d'instances Compute Engine : votre projet peut atteindre sa limite d'instances pour la région.
    • Quotas de processeurs : si vos nœuds de calcul utilisent plusieurs processeurs (par exemple, n1-standard-4), assurez-vous que votre projet dispose d'un quota de processeurs suffisant.
    • Quotas d'adresses IP : chaque VM de nœud de calcul nécessite une adresse IP. Si le quota d'adresses IP de votre réseau VPC ou de votre région est épuisé, de nouveaux nœuds de calcul ne peuvent pas être provisionnés.
    • Disponibilité des ressources : si la région ou la zone subit un épuisement temporaire des ressources, Dataflow peut ne pas être en mesure de créer des instances de nœud de calcul, même si un quota est disponible. Pour en savoir plus, consultez Arrêt du scaling à la hausse.

  • Sensibilité du niveau de latence : si la planification active configure un niveau de latence de medium_latency ou high_latency, Dataflow attend intentionnellement que davantage de tâches en attente s'accumulent avant de déclencher des événements de scaling à la hausse :

    • low_latency (par défaut) : effectue un scaling à la hausse lorsque le backlog dépasse 15 secondes.
    • medium_latency : effectue un scaling à la hausse lorsque le backlog dépasse 180 secondes (3 minutes).
    • high_latency : effectue un scaling à la hausse lorsque le backlog dépasse 600 secondes (10 minutes).

    Si votre job semble prendre du retard ou retarder l'augmentation de la capacité pendant une période de planification, vérifiez si la planification active a configuré un niveau de latence plus élevé.

  • Limites de parallélisme basées sur les clés : Dataflow ne peut pas évoluer au-delà du nombre de clés de traitement distinctes disponibles à cette étape. Si votre flux de données contient peu de clés uniques, l'ajout de nœuds de calcul ne peut pas améliorer le débit, et Dataflow limite le nombre de nœuds de calcul pour éviter les ressources inactives.

  • Stabilité du pool de nœuds de calcul : si les instances de nœuds de calcul rencontrent des plantages ou des erreurs de mémoire insuffisante (OOM), Dataflow suspend temporairement les requêtes de redimensionnement de l'autoscaling jusqu'à ce que le pool de nœuds de calcul se stabilise.

Lacunes dans les métriques d'autoscaling

Il existe de courtes lacunes temporaires dans les métriques d'autoscaling.

Ce problème peut se produire si les tâches de backend sont redémarrées. Ces écarts dans les métriques n'indiquent pas un problème d'autoscaling ni d'état de la tâche de traitement en flux continu.

Répartition inégale du processeur

En cas d'autoscaling du job, la répartition de l'utilisation du processeur est inégale entre les nœuds de calcul. Certains nœuds de calcul ont une utilisation du processeur, une latence du système ou une fraîcheur des données plus élevée que d'autres.

Ce problème peut se produire si vos données contiennent une clé chaude. Une clé chaude est une clé contenant suffisamment d'éléments pour avoir un impact négatif sur les performances du pipeline. Chaque clé doit être traitée par un seul nœud de calcul. Le travail ne peut donc pas être réparti entre les nœuds de calcul.

Pour en savoir plus, consultez les conseils sur les erreurs de clé chaude.

L'élément de travail demandant la lecture d'état n'est plus valide sur le backend

Lors de la communication entre des instances de VM de nœud de calcul et des tâches Streaming Engine dans un pipeline de traitement en flux continu, l'erreur suivante se produit :

The work item requesting state read is no longer valid on the backend.
The work has already completed or will be retried.
This is expected during autoscaling events.

Lors de l'autoscaling, les instances de VM de nœud de calcul communiquent avec plusieurs tâches Streaming Engine, et chaque tâche traite plusieurs instances de VM de nœud de calcul. Les clés d'élément sont utilisées pour répartir le travail. Chaque tâche et instance de VM de nœud de calcul ont un ensemble de plages de clés, et la distribution de ces plages peut changer de manière dynamique. Par exemple, lors de l'autoscaling, le redimensionnement d'une tâche peut entraîner une modification de la distribution de la plage de clés. Cette erreur peut se produire lorsqu'une plage de clés est modifiée. Cette erreur est fréquente et, sauf si vous constatez une corrélation entre ces messages et un pipeline peu performant, vous pouvez l'ignorer.

Ressources Streaming Engine insuffisantes

Si Streaming Engine ne peut pas allouer le nombre minimal de nœuds de calcul que vous demandez, l'erreur suivante est renvoyée :

Streaming Engine does not currently have enough resources available to fulfill
the request.

Pour résoudre ce problème, essayez de définir un nombre minimal de nœuds de calcul inférieur. Consultez Définir la plage d'autoscaling.

Plage de scaling des pipelines d'autoscaling en flux continu

Cette section fournit des détails sur la plage de scaling des pipelines d'autoscaling en flux continu.

Java

Pour les jobs d'autoscaling en flux continu qui n'utilisent pas Streaming Engine, le service Dataflow alloue entre 1 et 15 disques persistants à chaque nœud de calcul. Cela signifie que le nombre minimal de nœuds de calcul utilisés pour un pipeline d'autoscaling en flux continu est de N/15, où N est la valeur de --maxNumWorkers.

Pour les tâches d'autoscaling en flux continu qui utilisent Streaming Engine, le nombre minimal de nœuds de calcul est de 1.

Dataflow équilibre le nombre de disques persistants entre les nœuds de calcul. Par exemple, si votre pipeline a besoin de trois ou quatre nœuds de calcul en régime permanent, vous pouvez définir --maxNumWorkers=15. Le pipeline s'adapte automatiquement afin d'utiliser 1 à 15 nœuds de calcul (1, 3, 5 ou 15 nœud(s) de calcul, ce qui correspond à 15, 5, 3 ou 1 disque(s) persistant(s) par nœud de calcul, respectivement).

La valeur --maxNumWorkers ne peut pas dépasser 1 000.

Python

Pour les jobs d'autoscaling en flux continu qui n'utilisent pas Streaming Engine, le service Dataflow alloue entre 1 et 15 disques persistants à chaque nœud de calcul. Cela signifie que le nombre minimal de nœuds de calcul utilisés pour un pipeline d'autoscaling en flux continu est de N/15, où N est la valeur de --max_num_workers.

Pour les tâches d'autoscaling en flux continu qui utilisent Streaming Engine, le nombre minimal de nœuds de calcul est de 1.

Dataflow équilibre le nombre de disques persistants entre les nœuds de calcul. Par exemple, si votre pipeline a besoin de trois ou quatre nœuds de calcul en régime permanent, vous pouvez définir --max_num_workers=15. Le pipeline s'adapte automatiquement afin d'utiliser 1 à 15 nœuds de calcul (1, 2, 3, 4, 5, 8 ou 15 nœud(s) de calcul, ce qui correspond à 15, 8, 5, 4, 3, 2 ou 1 disque(s) persistant(s) par nœud de calcul, respectivement).

La valeur --max_num_workers ne peut pas dépasser 1 000.

Go

Pour les jobs d'autoscaling en flux continu qui n'utilisent pas Streaming Engine, le service Dataflow alloue entre 1 et 15 disques persistants à chaque nœud de calcul. Cela signifie que le nombre minimal de nœuds de calcul utilisés pour un pipeline d'autoscaling en flux continu est de N/15, où N est la valeur de --max_num_workers.

Pour les tâches d'autoscaling en flux continu qui utilisent Streaming Engine, le nombre minimal de nœuds de calcul est de 1.

Dataflow équilibre le nombre de disques persistants entre les nœuds de calcul. Par exemple, si votre pipeline a besoin de trois ou quatre nœuds de calcul en régime permanent, vous pouvez définir --max_num_workers=15. Le pipeline s'adapte automatiquement afin d'utiliser 1 à 15 nœuds de calcul (1, 2, 3, 4, 5, 8 ou 15 nœud(s) de calcul, ce qui correspond à 15, 8, 5, 4, 3, 2 ou 1 disque(s) persistant(s) par nœud de calcul, respectivement).

La valeur --max_num_workers ne peut pas dépasser 1 000.

Nombre maximal de nœuds de calcul utilisables par l'autoscaling en flux continu

Java

Dataflow utilise le quota d'instances Compute Engine ou la valeur maxNumWorkers de votre projet comme limite, selon la valeur la plus basse.

Python

Dataflow utilise le quota d'instances Compute Engine ou la valeur max_num_workers de votre projet comme limite, selon la valeur la plus basse.

Go

Dataflow utilise le quota d'instances Compute Engine ou la valeur max_num_workers de votre projet comme limite, selon la valeur la plus basse.

Limiter l'autoscaling pour réduire l'impact sur la facturation

Si vous ne voulez pas que l'autoscaling augmente votre facture, vous pouvez limiter le nombre maximal de nœuds de calcul que votre job par flux peut utiliser.

Java

Vous pouvez spécifier --maxNumWorkers pour limiter la plage de scaling utilisée pour le traitement de votre tâche.

Python

Vous pouvez spécifier --max_num_workers pour limiter la plage de scaling utilisée pour le traitement de votre tâche.

Go

Vous pouvez spécifier --max_num_workers pour limiter la plage de scaling utilisée pour le traitement de votre tâche.

Modifier la plage de scaling

Pour en savoir plus sur la modification de la plage de scaling d'un pipeline de traitement en flux continu, consultez la page Définir la plage d'autoscaling.

Désactiver l'autoscaling sur les pipelines de traitement en flux continu

Pour désactiver l'autoscaling sur le pipeline de traitement en flux continu, procédez comme suit :

Java

Définissez --autoscalingAlgorithm=NONE. Pour en savoir plus, consultez Désactiver l'autoscaling horizontal.

Python

Définissez --autoscaling_algorithm=NONE. Pour en savoir plus, consultez Désactiver l'autoscaling horizontal.

Go

Définissez --autoscaling_algorithm=NONE. Pour en savoir plus, consultez Désactiver l'autoscaling horizontal.

Utiliser un nombre fixe de nœuds de calcul

Pour les jobs de traitement en flux continu qui n'utilisent pas Streaming Engine, le comportement par défaut consiste à utiliser un nombre fixe de nœuds de calcul. Pour utiliser l'autoscaling de flux avec ces pipelines, vous devez l'activer explicitement, car il n'est pas activé par défaut.