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 par flux n'effectue pas de scaling à la hausse

Lorsque votre pipeline de traitement par flux 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 les nœuds de calcul utilisent moins de 20 % de leurs processeurs.

Parfois, le nombre de tâches en attente est important, mais l'utilisation du processeur est faible. Certaines tâches ne nécessitant pas une utilisation élevée du processeur, l'ajout de nœuds de calcul n'améliore pas les performances. Dans ce cas, Dataflow n'effectue pas de scaling à la hausse. Pour en savoir plus, consultez la section Autoscaling de flux. Ce scénario peut se produire pour les raisons suivantes :

• Le pipeline est intense en E/S.
• Le pipeline attend des appels RPC externes.
• Des clés chaudes entraînent une utilisation inégale de processeur par nœud de calcul.
• Le pipeline ne dispose pas de suffisamment de clés.

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 les fichiers temporaires et de préproduction. 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 par flux n'effectue pas de scaling à la baisse

Lorsque votre tâche de traitement par flux 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 tâches 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 existe 100 disques et 100 nœuds de calcul, chaque nœud de calcul dispose d'un disque. Lorsqu'un scaling à la baisse est effectué, la tâche 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.

• Lorsque votre pipeline utilise PeriodicImpulse, les nœuds de calcul Dataflow n'évoluent pas à la baisse comme prévu. L'utilisation de PeriodicImpulse n'est pas compatible avec l'autoscaling de flux.

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 survient lorsque les limites de quota sont atteintes.

• Quotas Compute Engine : les tâches Dataflow sont soumises au quota Compute Engine du projet. Si plusieurs tâches sont en cours d'exécution, le projet peut atteindre 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 atteindre la limite de 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'optimisation de l'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'optimisation est utilisée, 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 facteur qui affecte 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
Aucun changement	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 tâches sont limitées par les appels RPC externes. L'ajustement de scaling à la baisse est trop faible, ou Dataflow bloque la réduction de la capacité. Pour en savoir plus, consultez la section Heuristique d'autoscaling de flux.	job/aggregated_worker_utilization job/max_worker_instances_limit job/min_worker_instances_limit job/processing_parallelism_keys Erreurs RPC signalées dans les journaux d'erreurs des nœuds de calcul Plantages signalés dans les journaux des nœuds de calcul
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 vers une valeur supérieure au nombre actuel de nœuds de calcul.	job/aggregated_worker_utilization job/backlog_bytes job/backlog_elements job/estimated_timer_backlog_processing_time job/min_worker_instances_limit
Scaling à la baisse	Le nombre maximal de nœuds de calcul a été mis à jour à une valeur inférieure au nombre actuel de nœuds de calcul.	job/aggregated_worker_utilization job/max_worker_instances_limit

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

Écarts dans les métriques d'autoscaling

Les métriques d'autoscaling présentent des écarts courts et temporaires.

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 par flux.

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é d'hôte. Une clé d'hôte 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, de sorte que le travail ne peut pas être réparti entre plusieurs nœuds de calcul.

Pour en savoir plus, consultez la documentation sur les erreurs liées aux clés d'hôte.

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 par flux, 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 instance de tâche et 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 la section Définir la plage d'autoscaling.

Plage de scaling pour les 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 tâches 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 prêts à l'emploi, vous pouvez définir --maxNumWorkers=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 --maxNumWorkers ne peut pas dépasser 1 000.

Python

Pour les tâches 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 prêts à l'emploi, 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 tâches 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 prêts à l'emploi, 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 de votre projet ou de maxNumWorkers comme limite, selon la valeur la plus basse.

Python

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

Go

Dataflow utilise le quota d'instances Compute Engine de votre projet ou de max_num_workers 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 par flux, consultez la page Définir la plage d'autoscaling.

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

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

Java

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

Python

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

Go

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

Utiliser un nombre fixe de nœuds de calcul

Pour les tâches de traitement par flux 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.