Solucionar problemas de autoescalado de Dataflow

En esta página se explica cómo solucionar problemas con las funciones de autoescalado de Dataflow y se proporciona información sobre cómo gestionar el autoescalado.

El trabajo no se escala verticalmente

En esta sección se proporciona información sobre los casos en los que los trabajadores no pueden aumentar o reducir su actividad.

El trabajo de streaming no se escala verticalmente

Cuando tu canalización de streaming tiene un trabajo pendiente, los trabajadores no se escalan.

Este problema se produce cuando el trabajo pendiente dura menos de unos minutos o cuando el paralelismo es limitado.

A veces, la acumulación es elevada, pero el paralelismo es bajo. En ese caso, Dataflow no se amplía, ya que el trabajo no se puede distribuir entre más trabajadores, por lo que añadir más trabajadores no ayudará con el procesamiento. Para obtener más información, consulta Autoescalado de streaming.

Los trabajos por lotes y en streaming no se escalan

Tu trabajo por lotes o de streaming se ejecuta correctamente, pero cuando se necesitan más trabajadores, el trabajo no se escala.

Este problema puede deberse a uno de los siguientes motivos:

• No se puede acceder a los archivos de almacenamiento provisional o temporales. Si tu trabajo usa un segmento de Cloud Storage, es posible que el segmento tenga una configuración de ciclo de vida que elimine objetos del segmento. Los objetos eliminados incluyen carpetas y archivos de almacenamiento provisional y temporales. Para comprobar si se han eliminado los archivos, consulta la configuración del ciclo de vida del bucket. Si las carpetas o los archivos de staging o temporales se han eliminado después de que se haya iniciado el trabajo, es posible que no existan los paquetes necesarios para crear nuevos trabajadores. Para solucionar este problema, vuelve a crear las carpetas y los archivos en el contenedor.
• Las reglas de cortafuegos impiden que los trabajadores envíen y reciban tráfico en los puertos TCP necesarios. Las reglas de cortafuegos pueden impedir que se inicien los trabajadores. Los trabajadores de Dataflow deben poder enviar y recibir tráfico en los puertos TCP 12345 y 12346. Para obtener más información, incluidos los pasos para solucionar este problema, consulta Reglas de cortafuegos de Dataflow.
• Una fuente personalizada tiene un método getProgress() que devuelve un valor NULL. Cuando usa una fuente personalizada, las métricas de la cartera de pedidos dependen del valor devuelto del método getProgress() de su fuente personalizada para empezar a recoger datos. La implementación predeterminada de getProgress() devuelve un valor NULL. Para solucionar este problema, asegúrese de que su fuente personalizada anule el método getProgress() predeterminado para devolver un valor distinto de NULL.
• Una actualización activada por el autoescalado vertical desactiva temporalmente el autoescalado horizontal. Para obtener más información, consulta Efecto en el autoescalado horizontal.
• Si usas una operación map en una canalización de Python y tu trabajo no se escala, puede que tengas que añadir una transformación Reshuffle al código de tu canalización. Para obtener más información, consulta Reshuffle en la documentación de Apache Beam.

El trabajo de streaming no se reduce verticalmente

Cuando un trabajo de streaming tiene un backlog y un uso de CPU bajos, los trabajadores no se reducen. Este problema puede producirse por varios motivos.

• Cuando las tareas no usan Streaming Engine, Dataflow equilibra el número de discos persistentes entre los trabajadores. Por lo tanto, cada trabajador debe tener el mismo número de discos persistentes. Por ejemplo, si hay 100 discos y 100 trabajadores, cada trabajador tiene un disco. Cuando la tarea se reduce, puede tener 50 trabajadores con dos discos persistentes por trabajador. El trabajo no se vuelve a reducir hasta que pueda tener 25 trabajadores con cuatro discos persistentes por trabajador. Además, el número mínimo de trabajadores es el valor asignado a maxNumWorkers dividido entre 15. Para obtener más información, consulta Intervalo de escalado de las canalizaciones de escalado automático de streaming.

• Cuando los trabajos usan Streaming Engine, el objetivo de reducción se basa en un uso de CPU objetivo del 75%. Si no se puede alcanzar esta utilización de la CPU, se inhabilita la reducción de recursos.

• La estimación del tiempo de trabajo pendiente debe mantenerse por debajo de los diez segundos durante al menos dos minutos antes de que se reduzca el número de trabajadores. Las fluctuaciones en el tiempo de trabajo pendiente pueden inhabilitar la reducción de la escala. Además, un rendimiento bajo puede sesgar la estimación del tiempo.

• PeriodicImpulse es compatible con las versiones 2.60.0 y posteriores del SDK de Apache Beam. Cuando tu flujo de procesamiento usa PeriodicImpulse con las versiones 2.59.0 y anteriores del SDK de Apache Beam, los trabajadores de Dataflow no se reducen como se espera.

Escalar verticalmente las paradas

Tu trabajo por lotes o en streaming empieza a aumentar la escala, pero los trabajadores dejan de hacerlo aunque siga habiendo un trabajo pendiente.

Este problema se produce cuando se alcanzan los límites de cuota.

• Cuotas de Compute Engine: las tareas de Dataflow están sujetas a la cuota de Compute Engine del proyecto. Si se están ejecutando varios trabajos, es posible que el proyecto haya alcanzado el límite de su cuota de Compute Engine. En ese caso, Dataflow no puede aumentar el número de trabajadores.
• Cuotas de CPU: las tareas de Dataflow también están sujetas a la cuota de CPU del proyecto. Si el tipo de trabajador usa más de una CPU, es posible que el proyecto haya alcanzado el límite de la cuota de CPU.
• Cuotas de direcciones IP externas: cuando un trabajo usa direcciones IP externas para comunicarse con los recursos, necesita tantas direcciones IP externas como trabajadores. Cuando aumenta el número de trabajadores, también lo hace el número de direcciones IP externas. Cuando alcances el límite de direcciones IP, los trabajadores dejarán de aumentar.

Además, si se agota un recurso en la región que elijas, no podrás crear más recursos de ese tipo, aunque quede cuota en tu proyecto o tu región. Por ejemplo, quizá aún tengas cuota para crear direcciones IP externas en us-central1, pero es posible que no haya direcciones IP disponibles en esa región. Para obtener más información, consulta Cuotas y disponibilidad de recursos.

Para solucionar este problema, solicita un aumento de cuota o ejecuta el trabajo en otra región.

La sugerencia de utilización de los trabajadores no tiene ningún efecto

Has definido la sugerencia de utilización de trabajadores pero el comportamiento del ajuste automático de escala no cambia.

Para entender este problema, ve al gráfico de utilización de la CPU de los procesos de trabajo y comprueba si se usa activamente la sugerencia de utilización de los procesos de trabajo. Si se usa la pista, el gráfico muestra CPU utilization hint (actively used by autoscaler). De lo contrario, se muestra CPU utilization hint (not actively used by autoscaler).

La sugerencia de uso es solo uno de los factores que afectan al autoescalado. En la siguiente tabla se indican algunos motivos por los que el escalador automático podría no usar activamente la sugerencia:

Comportamiento de escalado observado	Causas	Métricas que debes comprobar
Sin cambios	Has alcanzado el número mínimo o máximo de trabajadores. El número de trabajadores está limitado por el número de claves procesadas en paralelo. Los trabajos se limitan mediante RPCs externas. El ajuste de reducción de escala es demasiado pequeño o Dataflow está amortiguando la reducción de escala. Para obtener más información, consulta Heurísticas de escalado automático de streaming.	job/aggregated_worker_utilization job/max_worker_instances_limit job/min_worker_instances_limit job/processing_parallelism_keys Errores de RPC registrados en los registros de errores del trabajador Fallos registrados en los registros de trabajadores
Escalar verticalmente	El objetivo de latencia o de acumulación es alto y anula la sugerencia. El número mínimo de trabajadores se ha actualizado a un valor superior al número de trabajadores actual.	job/aggregated_worker_utilization job/backlog_bytes job/backlog_elements job/estimated_timer_backlog_processing_time job/min_worker_instances_limit
Escalado horizontal	El número máximo de trabajadores se ha actualizado a un valor inferior al número actual de trabajadores.	job/aggregated_worker_utilization job/max_worker_instances_limit

Para obtener más información, consulta Heurísticas de escalado automático de streaming.

Faltan datos en las métricas de autoescalado

Hay breves interrupciones temporales en las métricas de autoescalado.

Este problema puede producirse si se reinician las tareas de backend. Estas lagunas en las métricas no indican que haya ningún problema con el autoescalado ni con el estado de tu tarea de streaming.

La CPU se distribuye de forma desigual

Cuando la tarea se autoescala, la utilización de la CPU se distribuye de forma desigual entre los trabajadores. Algunos trabajadores tienen un mayor uso de la CPU, latencia del sistema o actualización de datos que otros.

Este problema puede producirse si tus datos contienen una tecla de acceso rápido. Una tecla activa es una tecla con suficientes elementos como para afectar negativamente al rendimiento de la canalización. Cada clave debe procesarla un solo trabajador, por lo que el trabajo no se puede dividir entre varios trabajadores.

Para obtener más información, consulta las directrices sobre errores de teclas de acceso rápido.

El elemento de trabajo que solicita la lectura del estado ya no es válido en el backend

Durante la comunicación entre las instancias de VM de trabajador y las tareas de Streaming Engine en una canalización de streaming, se produce el siguiente error:

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.

Durante el autoescalado, las instancias de VM de trabajador se comunican con varias tareas de Streaming Engine, y cada tarea sirve a varias instancias de VM de trabajador. Las claves de elemento se usan para distribuir el trabajo. Cada tarea y cada instancia de VM de trabajador tienen una colección de intervalos de claves, y la distribución de estos intervalos puede cambiar dinámicamente. Por ejemplo, durante el escalado automático, el cambio de tamaño de los trabajos puede provocar que cambie la distribución del intervalo de claves. Este error puede producirse cuando cambia un intervalo de claves. Este error es normal y, a menos que veas una correlación entre estos mensajes y un rendimiento inferior al esperado en la canalización, puedes ignorarlo.

Recursos de Streaming Engine insuficientes

Si Streaming Engine no puede asignar el número mínimo de trabajadores que has solicitado, se devuelve el siguiente error:

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

Para solucionar este problema, prueba a definir un número mínimo de trabajadores más bajo. Consulta Definir el intervalo de escalado automático.

Intervalo de escalado de flujos de procesamiento con autoescalado

En esta sección se proporcionan detalles sobre el intervalo de escalado de las canalizaciones de escalado automático de streaming.

Java

En las tareas de autoescalado de streaming que no usan Streaming Engine, el servicio Dataflow asigna entre 1 y 15 discos persistentes a cada trabajador. Esta asignación significa que el número mínimo de trabajadores que se usan en una canalización de autoescalado de streaming es N/15, donde N es el valor de --maxNumWorkers.

En las tareas de autoescalado de streaming que usan Streaming Engine, el número mínimo de trabajadores es 1.

Dataflow equilibra el número de Persistent Disks entre los trabajadores. Por ejemplo, si tu canalización necesita tres o cuatro trabajadores en estado estable, puedes definir --maxNumWorkers=15. La canalización se escala automáticamente entre 1 y 15 trabajadores, con 1, 2, 3, 4, 5, 8 o 15 trabajadores, que corresponden a 15, 8, 5, 4, 3, 2 o 1 discos persistentes por trabajador, respectivamente.

--maxNumWorkers puede ser 1000 como máximo.

Python

En las tareas de autoescalado de streaming que no usan Streaming Engine, el servicio Dataflow asigna entre 1 y 15 discos persistentes a cada trabajador. Esta asignación significa que el número mínimo de trabajadores que se usan en una canalización de autoescalado de streaming es N/15, donde N es el valor de --max_num_workers.

En las tareas de autoescalado de streaming que usan Streaming Engine, el número mínimo de trabajadores es 1.

Dataflow equilibra el número de Persistent Disks entre los trabajadores. Por ejemplo, si tu canalización necesita tres o cuatro trabajadores en estado estable, puedes definir --max_num_workers=15. La canalización se escala automáticamente entre 1 y 15 trabajadores, con 1, 2, 3, 4, 5, 8 o 15 trabajadores, que corresponden a 15, 8, 5, 4, 3, 2 o 1 discos persistentes por trabajador, respectivamente.

--max_num_workers puede ser 1000 como máximo.

Go

En las tareas de autoescalado de streaming que no usan Streaming Engine, el servicio Dataflow asigna entre 1 y 15 discos persistentes a cada trabajador. Esta asignación significa que el número mínimo de trabajadores que se usan en una canalización de autoescalado de streaming es N/15, donde N es el valor de --max_num_workers.

En las tareas de autoescalado de streaming que usan Streaming Engine, el número mínimo de trabajadores es 1.

Dataflow equilibra el número de Persistent Disks entre los trabajadores. Por ejemplo, si tu canalización necesita tres o cuatro trabajadores en estado estable, puedes definir --max_num_workers=15. La canalización se escala automáticamente entre 1 y 15 trabajadores, con 1, 2, 3, 4, 5, 8 o 15 trabajadores, que corresponden a 15, 8, 5, 4, 3, 2 o 1 discos persistentes por trabajador, respectivamente.

--max_num_workers puede ser 1000 como máximo.

Número máximo de trabajadores que puede usar el autoescalado de streaming

Java

Dataflow opera dentro de los límites de la cuota de número de instancias de Compute Engine de tu proyecto o de maxNumWorkers, el que sea inferior.

Python

Dataflow opera dentro de los límites de la cuota de número de instancias de Compute Engine de tu proyecto o de max_num_workers, el que sea inferior.

Go

Dataflow opera dentro de los límites de la cuota de número de instancias de Compute Engine de tu proyecto o de max_num_workers, el que sea inferior.

Limitar el autoescalado para reducir el impacto en la facturación

Si no quieres que el autoescalado aumente tu factura, puedes limitar el número máximo de trabajadores que puede usar tu tarea de streaming.

Java

Si especificas --maxNumWorkers, limitas el intervalo de escalado que se usa para procesar tu trabajo.

Python

Si especificas --max_num_workers, limitas el intervalo de escalado que se usa para procesar tu trabajo.

Go

Si especificas --max_num_workers, limitas el intervalo de escalado que se usa para procesar tu trabajo.

Cambiar el intervalo de escalado

Para obtener información sobre cómo cambiar el intervalo de escalado de una canalización de streaming, consulta Definir el intervalo de autoescalado.

Desactivar el autoescalado en las canalizaciones de streaming

Para desactivar el escalado automático en una canalización de streaming, sigue estos pasos.

Java

Define --autoscalingAlgorithm=NONE. Para obtener más información, consulta Inhabilitar el escalado automático horizontal.

Python

Define --autoscaling_algorithm=NONE. Para obtener más información, consulta Inhabilitar el escalado automático horizontal.

Go

Define --autoscaling_algorithm=NONE. Para obtener más información, consulta Inhabilitar el escalado automático horizontal.

Usar un número fijo de trabajadores

En las tareas de streaming que no usan Streaming Engine, el comportamiento predeterminado es usar un número fijo de trabajadores. Para usar el autoescalado de streaming con estas pipelines, debes habilitarlo explícitamente, ya que no está activado de forma predeterminada.