El desarrollo de la canalización implica diferentes fases y tareas, como el desarrollo de código, las pruebas y la entrega en producción. En este documento se explica lo siguiente:
- Consideraciones sobre la integración continua y la entrega continua (CI/CD) para admitir la compilación, las pruebas y el despliegue de flujos de procesamiento automatizados en diferentes entornos.
- Funciones de Dataflow para optimizar el rendimiento y el uso de recursos en producción.
- Estrategias y puntos de control para actualizar flujos de procesamiento de streaming en producción.
- Prácticas recomendadas para mejorar la fiabilidad de las canalizaciones en producción.
Integración continua
La integración continua (CI) requiere que los desarrolladores combinen el código en un repositorio compartido con frecuencia, lo que resulta útil para las aplicaciones que cambian mucho, como los sitios web que se actualizan con frecuencia. Aunque las canalizaciones de datos no suelen cambiar tanto como otros tipos de aplicaciones, las prácticas de integración continua ofrecen muchas ventajas para el desarrollo de canalizaciones. Por ejemplo, la automatización de pruebas proporciona comentarios rápidos cuando se detectan defectos y reduce la probabilidad de que se produzcan regresiones en la base de código.
La automatización de pruebas es una parte importante de la integración continua. Si se combina con una cobertura de pruebas adecuada, la automatización de pruebas ejecutará tu conjunto de pruebas en cada confirmación de código. Tu servidor de CI puede funcionar junto con una herramienta de automatización de compilaciones como Maven para ejecutar tu conjunto de pruebas como uno o varios pasos del flujo de CI. Puedes empaquetar el código que supera las pruebas unitarias y de integración en artefactos de implementación desde los que se inician las canalizaciones. Esta compilación se denomina compilación correcta.
El número y los tipos de artefactos de implementación creados a partir de una compilación correcta varían en función de cómo se lancen las canalizaciones. Con el SDK de Apache Beam para Java, puedes empaquetar el código de tu flujo de procesamiento en un archivo JAR autoejecutable. Después, puedes almacenar el archivo JAR en un contenedor alojado en el proyecto de un entorno de implementación, como el proyecto de preproducción o de producción. Google Cloud Si usas plantillas clásicas (un tipo de ejecución con plantillas), los artefactos de implementación incluyen un archivo de plantilla JSON, el archivo JAR de tu canalización y una plantilla de metadatos opcional. A continuación, puede desplegar los artefactos en diferentes entornos de implementación mediante la entrega continua, tal como se explica en la siguiente sección.
Entrega y despliegue continuos
La entrega continua (CD) copia los artefactos de implementación en uno o varios entornos de implementación que están listos para lanzarse manualmente. Normalmente, los artefactos creados por el servidor de integración continua se despliegan en uno o varios entornos de preproducción para ejecutar pruebas integrales. El entorno de producción se actualiza si todas las pruebas integrales se superan correctamente.
En el caso de los flujos de procesamiento por lotes, la implementación continua puede iniciar directamente el flujo de procesamiento como una nueva tarea de Dataflow. También pueden usar los artefactos para iniciar trabajos por lotes cuando sea necesario. Por ejemplo, puedes usar Cloud Composer para ejecutar trabajos por lotes en un flujo de trabajo o Cloud Scheduler para programar trabajos por lotes.
Los flujos de procesamiento de streaming pueden ser más complejos de implementar que los flujos de procesamiento por lotes y, por lo tanto, pueden ser más difíciles de automatizar mediante la implementación continua. Por ejemplo, puede que tengas que determinar cómo sustituir o actualizar una canalización de streaming. Si no puedes actualizar una canalización o decides no hacerlo, puedes usar otros métodos, como coordinar varios trabajos de Dataflow, para minimizar o evitar interrupciones en tu negocio.
Identidades y roles necesarios para CI/CD
Tu flujo de procesamiento de CI/CD interactúa con diferentes sistemas para compilar, probar y desplegar flujos de procesamiento. Por ejemplo, tu canalización necesita acceder a tu repositorio de código fuente. Para habilitar estas interacciones, asegúrate de que tu canalización tenga las identidades y los roles adecuados. Es posible que las siguientes actividades de la canalización también requieran que la canalización tenga identidades y roles específicos.
Pruebas de integración con servicios externos, incluido Google Cloud Platform
Cuando usas Direct Runner para ejecutar pruebas ad hoc o pruebas de integración del sistema, tu canalización usa credenciales predeterminadas de la aplicación (ADC) para obtener las credenciales. La forma de configurar ADC depende de dónde se ejecute tu canalización. Para obtener más información, consulta Configurar credenciales predeterminadas de la aplicación.
Asegúrate de que la cuenta de servicio que se usa para obtener las credenciales de los recursos de Google Cloud Platform a los que accede la canalización tenga los roles y permisos suficientes.
Desplegar artefactos en distintos entornos de despliegue
Cuando sea posible, utilice credenciales únicas para cada entorno (es decir, para cada proyecto) y limite el acceso a los recursos en consecuencia.
Usa cuentas de servicio únicas para cada proyecto con el fin de leer y escribir artefactos de implementación en los contenedores de almacenamiento. En función de si tu canalización usa una plantilla, es posible que tengas que organizar varios artefactos en tu proceso de implementación. Por ejemplo, crear y organizar una plantilla de Dataflow requiere permisos para escribir artefactos de implementación que se necesitan para iniciar tu flujo de trabajo, como el archivo de plantilla del flujo de trabajo, en un segmento de Cloud Storage.
Desplegar las canalizaciones en distintos entornos de despliegue
Si es posible, utiliza cuentas de servicio únicas para cada proyecto con el fin de acceder a los recursos del proyecto y gestionarlos, incluido el acceso a Dataflow. Google Cloud
La cuenta de servicio que uses para crear y gestionar trabajos de Dataflow debe tener permisos de gestión de identidades y accesos suficientes. Para obtener más información, consulta la sección Cuenta de servicio de Dataflow de la página Seguridad y permisos de Dataflow.
La cuenta de servicio de trabajador que uses para ejecutar tareas de Dataflow necesita permiso para gestionar recursos de Compute Engine mientras se ejecuta la tarea y para gestionar la interacción entre la canalización de Apache Beam y el servicio Dataflow. Para obtener más información, consulta la sección Cuenta de servicio de trabajador de la página Seguridad y permisos de Dataflow.
Para especificar una cuenta de servicio de trabajador gestionada por el usuario para un trabajo, usa la opción de canalización --serviceAccount.
Si no especificas una cuenta de servicio de trabajador al crear una tarea, Dataflow intentará usar la cuenta de servicio predeterminada de Compute Engine.
En su lugar, le recomendamos que especifique una cuenta de servicio de trabajador gestionada por el usuario para los entornos de producción, ya que la cuenta de servicio predeterminada de Compute Engine suele tener un conjunto de permisos más amplio que los permisos necesarios para sus trabajos de Dataflow.
En los casos prácticos, te recomendamos que uses cuentas de servicio independientes para gestionar los trabajos de Dataflow y para la cuenta de servicio de los trabajadores, lo que proporciona una mayor seguridad en comparación con el uso de una sola cuenta de servicio. Por ejemplo, la cuenta de servicio que se usa para crear tareas de Dataflow puede que no necesite acceder a fuentes y receptores de datos ni usar otros recursos que utilice la canalización. En este caso, la cuenta de servicio de trabajador que se usa para ejecutar tareas de Dataflow tiene permisos para usar recursos de la canalización. Se concede a otra cuenta de servicio para la creación de tareas permisos para gestionar (incluida la creación) tareas de Dataflow.
Ejemplo de flujo de procesamiento de CI/CD
En el siguiente diagrama se muestra una vista general e independiente de las herramientas de CI/CD para flujos de datos. Además, el diagrama muestra la relación entre las tareas de desarrollo, los entornos de implementación y los ejecutores de la canalización.
En el diagrama se muestran las siguientes fases:
Desarrollo de código: durante el desarrollo de código, un desarrollador ejecuta código de la canalización de forma local mediante Direct Runner. Además, los desarrolladores usan un entorno de pruebas para ejecutar flujos de procesamiento ad hoc con Dataflow Runner.
En los flujos de procesamiento de CI/CD habituales, el proceso de integración continua se activa cuando un desarrollador hace un cambio en el sistema de control de versiones, como enviar código nuevo a un repositorio.
Compilación y pruebas: el proceso de integración continua compila el código de la canalización y, a continuación, ejecuta pruebas unitarias y pruebas de integración de transformaciones con Direct Runner. También se pueden realizar pruebas de integración de sistemas opcionales, que incluyen pruebas de integración con fuentes y receptores externos mediante conjuntos de datos de prueba pequeños.
Si las pruebas se superan, el proceso de integración continua almacena los artefactos de implementación, que pueden incluir archivos JAR, imágenes de Docker y metadatos de plantillas, necesarios para iniciar la canalización en ubicaciones a las que pueda acceder el proceso de entrega continua. En función de los tipos de artefactos de implementación que se generen, puede usar Cloud Storage y Artifact Registry para almacenar los diferentes tipos de artefactos.
Entrega e implementación: el proceso de entrega continua copia los artefactos de implementación en un entorno de preproducción o hace que estos artefactos estén disponibles para su uso en ese entorno. Los desarrolladores pueden ejecutar manualmente pruebas de extremo a extremo con Dataflow Runner o usar la implementación continua para iniciar la prueba automáticamente. Por lo general, es más fácil habilitar un enfoque de despliegue continuo para las canalizaciones por lotes que para las canalizaciones de streaming. Como las canalizaciones por lotes no se ejecutan de forma continua, es más fácil sustituirlas por una nueva versión.
El proceso de actualización de las canalizaciones de streaming puede ser sencillo o complejo y debes probar las actualizaciones en el entorno de preproducción. Es posible que los procedimientos de actualización no siempre sean coherentes entre las versiones. Por ejemplo, una canalización puede cambiar de tal forma que sea imposible realizar actualizaciones in situ. Por este motivo, a veces es difícil automatizar las actualizaciones de la canalización mediante la implementación continua.
Si se superan todas las pruebas completas, puedes copiar los artefactos de implementación o ponerlos a disposición del entorno de producción como parte del proceso de entrega continua. Si la nueva canalización actualiza o sustituye una canalización de streaming, sigue los procedimientos probados en el entorno de preproducción para implementar la nueva canalización.
Ejecución de tareas sin plantilla y con plantilla
Puedes crear una tarea de Dataflow usando el SDK de Apache Beam directamente desde un entorno de desarrollo. Este tipo de tarea se denomina tarea sin plantilla. Aunque este enfoque es práctico para los desarrolladores, puede que prefieras separar las tareas de desarrollo y ejecución de las canalizaciones. Para hacer esta separación, puedes usar plantillas de Dataflow, que te permiten organizar y ejecutar tus flujos de procesamiento como tareas independientes. Una vez que se ha almacenado un archivo de plantilla, otros usuarios, incluidos los que no son desarrolladores, pueden ejecutar los trabajos a partir de la plantilla mediante la interfaz de línea de comandos de Google Cloud, la consolaGoogle Cloud o la API REST de Dataflow.
Dataflow ofrece los siguientes tipos de plantillas de trabajos:
- Plantillas clásicas: los desarrolladores usan el SDK de Apache Beam para ejecutar el código de la canalización y guardar el gráfico de ejecución serializado en JSON como plantilla. El SDK de Apache Beam pone en el área de stage el archivo de plantilla en una ubicación de Cloud Storage, junto con las dependencias que requiere el código del flujo de procesamiento.
- Plantillas flexibles: los desarrolladores usan la CLI de Google Cloud para empaquetar la canalización como una imagen Docker, que se almacena en Artifact Registry. También se genera automáticamente un archivo de especificación de plantilla de Flex, que se almacena en una ubicación de Cloud Storage especificada por el usuario. El archivo de especificación de la plantilla flexible contiene metadatos que describen cómo ejecutar la plantilla, como los parámetros de la canalización.
Además de las funciones de las plantillas Flex que se explican en la documentación vinculada, las plantillas Flex ofrecen ventajas con respecto a las plantillas clásicas para gestionar plantillas.
- Con las plantillas clásicas, es posible que se almacenen varios artefactos, como archivos JAR, en una ubicación de staging de Cloud Storage, pero sin ninguna función para gestionar estos artefactos. En cambio, una plantilla Flex se encapsula en una imagen de Docker. La imagen empaqueta todas las dependencias, excepto la especificación de FlexTemplate, que necesita tu canalización en un artefacto de implementación que gestiona Artifact Registry.
- Puedes usar las funciones de gestión de imágenes de Docker para tus plantillas Flex. Por ejemplo, puedes compartir de forma segura FlexTemplates concediendo permisos de extracción (y, opcionalmente, de envío) a Artifact Registry y usar etiquetas de imágenes de Docker para diferentes versiones de tus FlexTemplates.
Los desarrolladores pueden usar plantillas clásicas y flexibles para iniciar trabajos en un proyecto distinto del proyecto propietario del registro y del contenedor de almacenamiento que aloja los recursos de la plantilla, o solo del contenedor de almacenamiento si usan plantillas clásicas. Esta función es útil si necesitas aislar el tratamiento de datos de varios clientes en diferentes proyectos y trabajos de canalización. Con las plantillas Flex, puedes especificar diferentes versiones de una imagen de Docker para usarlas al iniciar una canalización. Esta función simplifica la sustitución gradual de flujos de procesamiento por lotes o de flujos de procesamiento en tiempo real en varios proyectos cuando actualizas las plantillas más adelante.
Funciones de Dataflow para optimizar el uso de recursos
Dataflow proporciona las siguientes funciones específicas del runner para optimizar el uso de recursos, lo que puede mejorar el rendimiento y reducir los costes:
- Streaming Engine: Streaming Engine traslada la ejecución de las canalizaciones de streaming fuera de los trabajadores de las máquinas virtuales y a un servicio específico. Entre las ventajas, se incluyen una mayor capacidad de respuesta del escalado automático, una reducción de los recursos de las VMs de los trabajadores consumidos y actualizaciones automáticas de los servicios sin necesidad de volver a implementarlos. En algunos casos, también puedes reducir el uso de recursos mediante el procesamiento al menos una vez para los casos prácticos que toleren duplicados. Se recomienda habilitar Streaming Engine en los flujos de procesamiento de streaming. La función está habilitada de forma predeterminada cuando se usan las versiones más recientes del SDK de Apache Beam para Java o Python.
- Dataflow Shuffle: esta función traslada las operaciones de orden sistemático de datos de los flujos de procesamiento por lotes fuera de los trabajadores de las máquinas virtuales y las ubica en un servicio específico. Entre las ventajas se incluyen una ejecución más rápida de la mayoría de las canalizaciones por lotes, un menor consumo de recursos por parte de las VMs de trabajador, una mayor capacidad de respuesta del autoescalado y una mayor tolerancia a fallos. Se recomienda habilitar Shuffle de Dataflow en los flujos de procesamiento por lotes. La función está habilitada de forma predeterminada mediante el SDK de Apache Beam para Java y el SDK de Python más reciente.
- Programación flexible de recursos (FlexRS): FlexRS reduce los costes del procesamiento por lotes mediante técnicas de programación avanzadas, el servicio Dataflow Shuffle y una combinación de instancias de máquina virtual estándar e interrumpibles.
Actualizar las canalizaciones de streaming en producción
Consulta Actualizar una canalización de streaming.
Ciclo de vida de una tarea de Dataflow
Una tarea de Dataflow pasa por un ciclo de vida representado por varios estados de la tarea.
Para ejecutar una tarea de Dataflow, envíala a una región.
A continuación, la tarea se dirige a un backend de Dataflow disponible en una de las zonas de la región. Antes de asignar un backend, Dataflow verifica que tengas suficiente cuota y permisos para ejecutar el trabajo. Cuando se completan estas comprobaciones previas y se asigna un backend, la tarea pasa al estado JOB_STATE_PENDING. En el caso de las tareas de FlexRS, es posible que la asignación del backend se retrase y que estas tareas pasen al estado JOB_STATE_QUEUED.
El backend asignado recoge la tarea para ejecutarla e intenta iniciar los trabajadores de Dataflow en tu proyecto de Google Cloud Platform. La zona que se elija para las VMs de trabajador depende de varios factores. En el caso de las tareas por lotes que usan Dataflow Shuffle, el servicio también intenta asegurarse de que el backend de Dataflow y las VMs de trabajador se encuentren en la misma zona para evitar el tráfico entre zonas.
Una vez que se inician los trabajadores de Dataflow, solicitan trabajo al backend de Dataflow. El backend se encarga de dividir el trabajo en fragmentos paralelizados, llamados paquetes, que se distribuyen entre los trabajadores. Si los trabajadores no pueden gestionar el trabajo actual y el autoescalado está habilitado, el backend inicia más trabajadores para gestionar el trabajo. Del mismo modo, si se inician más procesos de trabajo de los necesarios, algunos de ellos se cierran.
Una vez que se inician los trabajadores de Dataflow, el backend de Dataflow actúa como plano de control para coordinar la ejecución del trabajo. Durante el procesamiento, el plano de datos del trabajo realiza operaciones de aleatorización, como GroupByKey, CoGroupByKey y Combine.
Los trabajos usan una de las siguientes implementaciones del plano de datos para las operaciones de aleatorización:
- El plano de datos se ejecuta en los trabajadores de Dataflow y los datos de la operación de barajado se almacenan en discos persistentes.
- El plano de datos se ejecuta como un servicio externalizado de las VMs de trabajador. Esta implementación tiene dos variantes, que se especifican al crear el trabajo: Dataflow Shuffle para flujos de procesamiento por lotes y Streaming Engine para flujos de procesamiento de streaming. El shuffle basado en servicios mejora significativamente el rendimiento y la escalabilidad de las operaciones de shuffle de datos en comparación con el shuffle basado en trabajadores.
Las tareas de streaming que entran en el estado JOB_STATE_RUNNING siguen ejecutándose indefinidamente hasta que se cancelan o se agotan, a menos que se produzca un error en la tarea. Las tareas por lotes se detienen automáticamente cuando se completa todo el procesamiento o si se produce un error irrecuperable. En función de cómo se detenga el trabajo, Dataflow asigna al trabajo uno de los varios estados finales, como JOB_STATE_CANCELLED, JOB_STATE_DRAINED o JOB_STATE_DONE.
Prácticas recomendadas para la fiabilidad de las canalizaciones
En esta sección se describen los errores que pueden producirse al trabajar con Dataflow y las prácticas recomendadas para los trabajos de Dataflow.
Sigue los principios de aislamiento
Una recomendación general para mejorar la fiabilidad general de la canalización es seguir los principios de aislamiento de las regiones y las zonas. Asegúrate de que tus pipelines no tengan dependencias críticas entre regiones. Si tienes una canalización que depende de forma crítica de servicios de varias regiones, un fallo en cualquiera de esas regiones puede afectar a tu canalización. Para evitar este problema, despliega en varias regiones para tener redundancia y copias de seguridad.
Crear capturas de Dataflow
Dataflow ofrece una función de captura que proporciona una copia de seguridad del estado de un flujo de procesamiento. Puedes restaurar la captura de la canalización en una nueva canalización de Dataflow de streaming en otra zona u otra región. A continuación, puedes iniciar el reprocesamiento de los mensajes de los temas de Pub/Sub o Kafka a partir de la marca de tiempo de la instantánea. Si configuras instantáneas periódicas de tus canalizaciones, puedes minimizar el tiempo de objetivo de recuperación (RTO).
Para obtener más información sobre las capturas de Dataflow, consulta el artículo sobre cómo usar capturas de Dataflow.
Gestionar errores de envío de trabajos
Envías tareas de Dataflow que no son de plantilla con el SDK de Apache Beam. Para enviar la tarea, ejecuta el flujo de procesamiento con Dataflow Runner, que se especifica como parte de las opciones del flujo de procesamiento. El SDK de Apache Beam pone en el área de stage los archivos en Cloud Storage, crea un archivo de solicitud de tarea y envía el archivo a Dataflow.
Por otro lado, las tareas creadas a partir de plantillas de Dataflow usan métodos de envío diferentes, que suelen depender de la API de plantillas.
Es posible que Dataflow devuelva errores diferentes que indiquen que se ha producido un fallo en las tareas de plantilla y en las tareas que no son de plantilla. En esta sección se describen los distintos tipos de errores de envío de trabajos y las prácticas recomendadas para gestionarlos o mitigarlos.
Reintentar el envío de tareas después de errores transitorios
Si una tarea no se inicia debido a un problema del servicio Dataflow, vuelve a intentarlo varias veces. Reintentar mitiga los problemas transitorios del servicio.
Mitigar los fallos de zona especificando una región de trabajador
Dataflow ofrece disponibilidad regional y está disponible en varias regiones. Cuando un usuario envía un trabajo a una región sin especificar explícitamente una zona, Dataflow dirige el trabajo a una zona de la región especificada en función de la disponibilidad de recursos.
La opción recomendada para colocar tareas es especificar una región de trabajador con la marca --region en lugar de la marca --zone siempre que sea posible. Este paso permite que Dataflow proporcione un nivel adicional de tolerancia a fallos para tus canalizaciones, ya que elige automáticamente la mejor zona posible para esa tarea. Las tareas que especifican una zona explícita no tienen esta ventaja y fallan si se producen problemas en la zona. Si se produce un error al enviar un trabajo debido a un problema zonal, a menudo puede resolver el problema volviendo a intentar enviar el trabajo sin especificar una zona.
Mitigar los fallos regionales almacenando datos en varias regiones
Si una región completa no está disponible, prueba a ejecutar el trabajo en otra región. Es importante tener en cuenta la disponibilidad de los datos cuando las tareas fallan en diferentes regiones. Para protegerte frente a fallos en una sola región sin tener que copiar datos manualmente en varias regiones, usa Google Cloud recursos que almacenen datos automáticamente en varias regiones. Por ejemplo, usa ubicaciones multirregionales de BigQuery para conjuntos de datos o segmentos birregionales y multirregionales de Cloud Storage. Si una región deja de estar disponible, puedes volver a ejecutar la canalización en otra región en la que los datos estén disponibles.
Para ver un ejemplo de cómo usar servicios multirregionales con Dataflow, consulta Alta disponibilidad y redundancia geográfica.
Gestionar fallos en flujos de procesamiento en ejecución
Una vez que se ha enviado un trabajo y se ha aceptado, las únicas operaciones válidas para el trabajo son las siguientes:
- cancelar tareas por lotes
- Actualizar, vaciar o cancelar tareas de streaming
No puedes cambiar la ubicación de los trabajos en ejecución después de enviarlos. Si no usas FlexRS, las tareas suelen empezar a procesar datos en unos minutos después de enviarse. Las tareas de FlexRS pueden tardar hasta seis horas en empezar a procesar los datos.
En esta sección se describen los errores que se producen al ejecutar trabajos y las prácticas recomendadas para gestionarlos.
Monitorizar los trabajos para identificar y resolver problemas causados por errores transitorios
En el caso de los trabajos por lotes, los paquetes que incluyen un elemento con errores se vuelven a intentar cuatro veces. Dataflow finaliza el trabajo cuando un solo paquete ha fallado cuatro veces. Este proceso se encarga de muchos problemas transitorios. Sin embargo, si se produce un fallo prolongado, normalmente se alcanza rápidamente el límite máximo de reintentos, lo que permite que la tarea falle rápidamente.
Para la monitorización y la gestión de incidentes, configura reglas de alertas para detectar tareas fallidas. Si un trabajo falla, inspecciona los registros del trabajo para identificar los fallos causados por elementos de trabajo fallidos que hayan superado el límite de reintentos.
En el caso de las tareas de streaming, Dataflow vuelve a intentar procesar los elementos de trabajo fallidos indefinidamente. El trabajo no se ha terminado. Sin embargo, es posible que la tarea se detenga hasta que se solucione el problema. Crea políticas de monitorización para detectar señales de una canalización detenida, como un aumento de la latencia del sistema y una disminución de la actualidad de los datos. Implementa el registro de errores en el código de tu canalización para identificar los bloqueos de la canalización causados por elementos de trabajo que fallan repetidamente.
Reiniciar trabajos en otra zona si se produce una interrupción del servicio en una zona
Una vez que se inicia una tarea, los trabajadores de Dataflow que ejecutan el código de usuario se limitan a una sola zona. Si se produce una interrupción zonal, los trabajos de Dataflow suelen verse afectados, en función del alcance de la interrupción.
En el caso de las interrupciones que solo afecten a los back-ends de Dataflow, el servicio gestionado migra automáticamente los back-ends a otra zona para que puedan continuar con el trabajo. Si el trabajo usa Dataflow Shuffle, el backend no se puede mover entre zonas. Si se produce una migración del backend de Dataflow, las tareas pueden detenerse temporalmente.
Si se produce una interrupción zonal, es probable que los trabajos en ejecución fallen o se detengan hasta que se restaure la disponibilidad de la zona. Si una zona no está disponible durante un periodo prolongado, detén las tareas (cancela las tareas por lotes y vacía las tareas de streaming) y, a continuación, reinícialas para que Dataflow elija una zona nueva y en buen estado.
Reiniciar trabajos por lotes en otra región si se produce una interrupción del servicio regional
Si se produce una interrupción regional en una región en la que se están ejecutando tus tareas de Dataflow, estas pueden fallar o detenerse. En el caso de las tareas por lotes, reinicia la tarea en otra región si es posible. Es importante asegurarse de que sus datos estén disponibles en diferentes regiones.
Mitigar las interrupciones regionales mediante la alta disponibilidad o la conmutación por error
En el caso de los trabajos de streaming, en función de la tolerancia a fallos y del presupuesto de tu aplicación, tienes diferentes opciones para mitigar los fallos. En caso de interrupción regional, la opción más sencilla y rentable es esperar a que finalice. Sin embargo, si tu aplicación es sensible a la latencia o si el procesamiento de datos no debe interrumpirse o debe reanudarse con un retraso mínimo, en las siguientes secciones se describen las opciones.
Alta disponibilidad: sensible a la latencia sin pérdida de datos
Si tu aplicación no puede tolerar la pérdida de datos, ejecuta dos pipelines duplicados en paralelo en dos regiones diferentes y haz que los pipelines consuman los mismos datos. Las mismas fuentes de datos deben estar disponibles en ambas regiones. Las aplicaciones de nivel inferior que dependen de la salida de estas canalizaciones deben poder cambiar entre la salida de estas dos regiones. Debido a la duplicación de recursos, esta opción implica el coste más alto en comparación con otras opciones. Para ver un ejemplo de implementación, consulta la sección Alta disponibilidad y redundancia geográfica.
Conmutación por error: sensible a la latencia con una posible pérdida de datos
Si tu aplicación puede tolerar una posible pérdida de datos, haz que la fuente de datos de streaming esté disponible en varias regiones. Por ejemplo, con Pub/Sub, mantén dos suscripciones independientes al mismo tema, una para cada región. Si se produce una interrupción regional, inicia una canalización de sustitución en otra región y haz que la canalización consuma datos de la suscripción de copia de seguridad.
Reproduce la suscripción de copia de seguridad en el momento adecuado para minimizar la pérdida de datos sin sacrificar la latencia. Las aplicaciones posteriores deben saber cómo cambiar a la salida de la canalización en ejecución, de forma similar a la opción de alta disponibilidad. Esta opción usa menos recursos que la ejecución de flujos de trabajo duplicados, ya que solo se duplican los datos.
Alta disponibilidad y redundancia geográfica
Puedes ejecutar varias canalizaciones de streaming en paralelo para procesar datos de alta disponibilidad. Por ejemplo, puedes ejecutar dos tareas de streaming paralelas en regiones diferentes, lo que proporciona redundancia geográfica y tolerancia a fallos para el procesamiento de datos.
Si tienes en cuenta la disponibilidad geográfica de las fuentes y los sumideros de datos, puedes operar flujos de procesamiento integrales en una configuración multirregional de alta disponibilidad. En el siguiente diagrama se muestra un ejemplo de implementación.
En el diagrama se muestra el siguiente flujo:
Pub/Sub se ejecuta en la mayoría de las regiones del mundo, lo que permite que el servicio ofrezca un acceso rápido y global a los datos, al tiempo que te da control sobre dónde se almacenan los mensajes. Pub/Sub puede almacenar automáticamente los mensajes publicados en la Google Cloud región más cercana a los suscriptores. También puedes configurarlo para que use una región o un conjunto de regiones específicos mediante políticas de almacenamiento de mensajes.
A continuación, Pub/Sub entrega los mensajes a los suscriptores de todo el mundo, independientemente de dónde se almacenen. Los clientes de Pub/Sub no tienen que saber las ubicaciones de los servidores a los que se conectan, ya que los mecanismos de balanceo de carga globales dirigen el tráfico al centro de datos más cercano donde se almacenan los mensajes.Google Cloud
Dataflow se ejecuta en regiones Google Cloud específicas. Si ejecutas las canalizaciones en paralelo en diferentes Google Cloud regiones, puedes aislar tus trabajos de los fallos que afecten a una sola región. En el diagrama se muestran dos instancias de la misma canalización, cada una de ellas ejecutándose en una región Google Cloud independiente.
BigQuery ofrece ubicaciones de conjuntos de datos regionales y multirregionales. Si eliges una ubicación multirregional, tu conjunto de datos se encontrará en al menos dos regiones geográficas. En el diagrama se muestran dos flujos de procesamiento independientes, cada uno de los cuales escribe en un conjunto de datos multirregional independiente.