El desarrollo de canalizaciones involucra diferentes etapas y tareas, como el desarrollo de código, la prueba y la entrega en producción. En este documento, se explica lo siguiente:
- Las consideraciones para que la integración continua y la entrega continua (CI/CD) admitan la compilación automatizada, la prueba y la implementación de canalizaciones en diferentes entornos.
- Las funciones de Dataflow para optimizar el rendimiento y el uso de los recursos en la producción
- Los enfoques y los puntos de análisis para actualizar las canalizaciones de transmisión en la producción
- Las prácticas recomendadas para mejorar la confiabilidad de las canalizaciones en la producción
Integración continua
La integración continua (CI) requiere que los desarrolladores combinen código en un repositorio compartido con frecuencia, lo que es útil para aplicaciones que cambian mucho, como los sitios web que se actualizan con frecuencia. Si bien las canalizaciones de datos no suelen cambiar tanto como otros tipos de aplicaciones, las prácticas de CI ofrecen muchos beneficios para el desarrollo de canalizaciones. Por ejemplo, la automatización de pruebas proporciona comentarios rápidos cuando se encuentran defectos y reduce la probabilidad de que las regresiones ingresen en la base de código.
La automatización de pruebas es una parte importante de la CI. Cuando se combina con la cobertura de prueba adecuada, la automatización de pruebas ejecuta tu paquete de pruebas en cada confirmación de código. Tu servidor de CI puede funcionar junto con una herramienta de automatización de compilación como Maven para ejecutar tu paquete de pruebas como uno o más pasos de la canalización de CI. Puedes empaquetar el código que pasa con éxito las pruebas de unidades y las pruebas de integración en artefactos de implementación desde los que se inician las canalizaciones. Esta compilación se conoce como una compilación aprobada.
La cantidad y los tipos de artefactos de implementación creados a partir de una compilación aprobada varían según cómo se inicien las canalizaciones. Con el SDK de Java de Apache Beam, puedes empaquetar tu código de canalización en un archivo JAR de ejecución automática. Luego, puedes almacenar el archivo JAR en un bucket que esté alojado en el proyecto para un entorno de implementación, como el proyecto de producción o de preproducción de Google Cloud. Si usas plantillas clásicas (un tipo deejecución de plantilla ), los artefactos de implementación incluyen un archivo de plantillas JSON, el archivo JAR para tu canalización y una plantilla de metadatos opcional. Luego, puedes implementar los artefactos en diferentes entornos de implementación con la entrega continua, como se explica en la siguiente sección.
Implementación y entrega continua
La entrega continua (CD) copia los artefactos de implementación en uno o más entornos de implementación que están listos para iniciarse de manera manual. Por lo general, los artefactos que compila el servidor de CI se implementan en uno o más entornos de preproducción para ejecutar pruebas de extremo a extremo. El entorno de producción se actualiza si todas las pruebas de extremo a extremo se pasan con éxito.
En el caso de las canalizaciones por lotes, la implementación continua puede iniciar la canalización directamente como un trabajo de Dataflow nuevo. Como alternativa, otros sistemas 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.
Las canalizaciones de transmisión pueden ser más complejas de implementar que las canalizaciones por lotes, por lo que puede ser más difícil automatizar la implementación con la implementación continua. Por ejemplo, es posible que debas determinar cómo reemplazar o actualizar una canalización de transmisión existente. Si no puedes actualizar una canalización, o si decides no actualizarla, puedes usar otros métodos, como coordinar varios trabajos de Dataflow para minimizar o evitar la interrupción de los negocios.
Identidades y funciones necesarias para la CI/CD
Tu canalización de CI/CD interactúa con diferentes sistemas para compilar, probar y, también, implementar canalizaciones. Por ejemplo, tu canalización necesita acceso a tu repositorio de código fuente. Para habilitar estas interacciones, asegúrate de que tu canalización tenga las identidades y las funciones adecuadas. Las siguientes actividades de canalización también pueden requerir que tu canalización tenga identidades y funciones específicas.
Prueba de integración con servicios externos, incluido Google Cloud
Cuando usas Direct Runner para ejecutar pruebas ad hoc o pruebas de integración del sistema, tu canalización usa las credenciales de Google Cloud CLI para consumir fuentes de datos y receptores de Google Cloud, o usa las credenciales que proporciona la variable de entorno GOOGLE_APPLICATION_CREDENTIALS. Asegúrate de que la cuenta de servicio que se usa para obtener las credenciales para los recursos de Google Cloud a los que accede la canalización tenga suficientes roles y permisos.
Implementa artefactos en diferentes entornos de implementación
Cuando sea posible, usa credenciales únicas para cada entorno (de manera efectiva para cada proyecto) y limita el acceso a los recursos según corresponda.
Usa cuentas de servicio únicas para cada proyecto para leer y escribir artefactos de implementación en buckets de almacenamiento. Según si tu canalización usa una plantilla, es posible que tu proceso de implementación deba almacenar en etapa intermedia varios artefactos. Por ejemplo, la creación y el almacenamiento en etapa intermedia de una plantilla de Dataflow requiere permisos para escribir los artefactos de implementación necesarios para iniciar tu canalización, como el archivo de plantillas de la canalización, en un bucket de Cloud Storage.
Implementa canalizaciones en diferentes entornos de implementación
Cuando sea posible, usa cuentas de servicio únicas para cada proyecto para acceder a los recursos de Google Cloud dentro del proyecto y administrarlos, incluido el acceso a Dataflow en sí.
La cuenta de servicio que usas para crear y administrar trabajos de Dataflow debe tener permisos suficientes de IAM para la administración de trabajos. Para obtener más detalles, consulta la sección Cuenta de servicio de Dataflow en la página de seguridad y permisos de Dataflow.
La cuenta de servicio de trabajador que usas para ejecutar trabajos de Dataflow necesita permiso para administrar los recursos de Compute Engine mientras se ejecuta el trabajo y la interacción entre la canalización de Apache Beam y el servicio de Dataflow. Para obtener más detalles, consulta la sección Cuenta de servicio de trabajador en la página de seguridad y permisos de Dataflow.
Si deseas especificar una cuenta de servicio de trabajador administrada por el usuario para un trabajo, usa la opción de canalización --serviceAccount.
Si no especificas una cuenta de servicio del trabajador cuando creas un trabajo, Dataflow intenta usar la cuenta de servicio predeterminada de Compute Engine.
Recomendamos que, en su lugar, especifiques una cuenta de servicio del trabajador administrada por el usuario para los entornos de producción, ya que la cuenta de servicio predeterminada de Compute Engine suele tener un conjunto más amplio de permisos que los necesarios para tus trabajos de Dataflow.
En situaciones de producción, te recomendamos usar cuentas de servicio diferentes para la administración de trabajos de Dataflow y para la cuenta de servicio del trabajador, lo que mejora la seguridad en comparación con el uso de una sola cuenta de servicio. Por ejemplo, es posible que la cuenta de servicio que se usa para crear trabajos de Dataflow no necesite acceder a fuentes de datos ni a receptores, ni usar otros recursos que usa la canalización. En este caso, la cuenta de servicio del trabajador que se usa para ejecutar trabajos de Dataflow recibe permisos para usar recursos de canalización. A una cuenta de servicio diferente destinada a la creación de trabajos se le otorgan permisos para administrar los trabajos de Dataflow (incluida la creación).
Ejemplo de canalización de CI/CD
En el siguiente diagrama, se proporciona una vista de la CI/CD para las canalizaciones de datos que es general e independiente de las herramientas. Además, en el diagrama se muestra la relación entre las tareas de desarrollo, los entornos de implementación y los ejecutores de canalizaciones.
En el diagrama, se muestran las siguientes etapas:
Desarrollo de código: Durante el desarrollo de código, un desarrollador ejecuta el código de canalización de manera local con Direct Runner. Además, los desarrolladores usan un entorno de zona de pruebas para la ejecución de la canalización ad hoc con Dataflow Runner.
En las canalizaciones de CI/CD típicas, el proceso de integración continua se activa cuando un desarrollador realiza un cambio en el sistema de control de origen, como el envío de código nuevo a un repositorio.
Compilación y prueba: El proceso de integración continua compila el código de canalización y, luego, ejecuta pruebas de unidades y pruebas de integración de transformación con Direct Runner. También pueden ejecutarse las pruebas opcionales de integración del sistema, que incluyen pruebas de integración con fuentes externas y receptores que usan conjuntos de datos de prueba pequeños.
Si las pruebas son exitosas, el proceso de CI almacena los artefactos de implementación, que pueden incluir archivos JAR, imágenes de Docker y metadatos de plantillas, necesarios para lanzar la canalización a ubicaciones a las que puede acceder el proceso de entrega continua. Según los tipos de artefactos de implementación generados, puedes 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 producción previa o hace que estos artefactos estén disponibles para su uso dentro de ese entorno. Los desarrolladores pueden ejecutar pruebas de extremo a extremo de forma manual con Dataflow Runner, o pueden usar la implementación continua para iniciar la prueba automáticamente. Por lo general, un enfoque de implementación continua es más fácil de habilitar para las canalizaciones por lotes que para las canalizaciones de transmisión. Debido a que las canalizaciones por lotes no se ejecutan de forma continua, es más fácil reemplazarlas por una nueva versión.
El proceso de actualización de las canalizaciones de transmisión podría ser simple o complejo, y debes probar las actualizaciones en el entorno de preproducción. Los procedimientos de actualización pueden no ser siempre coherentes entre las versiones. Por ejemplo, una canalización puede cambiar de tal manera que haga que las actualizaciones locales sean imposibles. Por esta razón, a veces es difícil automatizar las actualizaciones de canalización con la implementación continua.
Si se pasan todas las pruebas de extremo a extremo, puedes copiar los artefactos de implementación o hacer que estén disponibles para el entorno de producción como parte del proceso de entrega continua. Si la canalización nueva actualiza o reemplaza una canalización de transmisión existente, usa los procedimientos probados en el entorno de preproducción para implementar la canalización nueva.
Ejecución de trabajos sin plantillas frente a con plantillas
Puedes crear un trabajo de Dataflow con el SDK de Apache Beam directamente desde un entorno de desarrollo. Este tipo de trabajo se denomina trabajo sin plantillas. Aunque este enfoque es conveniente para los desarrolladores, es posible que prefieras separar las tareas de desarrollo y ejecución de canalizaciones. Para realizar esta separación, puedes usar plantillas de Dataflow, que te permiten almacenar en etapa intermedia las canalizaciones y ejecutarlas como tareas independientes. Después de que una plantilla se almacena en etapa intermedia, otros usuarios, incluidos los que no son desarrolladores, pueden ejecutar los trabajos desde la plantilla con Google Cloud CLI, la consola de Google Cloud o la API de REST de Dataflow.
Dataflow ofrece los siguientes tipos de plantillas de trabajo:
- Plantillas clásicas: Los desarrolladores usan el SDK de Apache Beam para ejecutar el código de la canalización y guardar el grafo de ejecución serializado JSON como la plantilla. El SDK de Apache Beam almacena en etapa intermedia el archivo de plantillas en una ubicación de Cloud Storage, junto con las dependencias que requiere el código de la canalización.
- Plantillas flexibles: Los desarrolladores usan Google Cloud CLI para empaquetar la canalización como una imagen de Docker, que luego se almacena en Artifact Registry. También se genera un archivo de especificaciones de la plantilla flexible y se lo almacena en una ubicación de Cloud Storage especificada por el usuario de forma automática. El archivo de especificaciones de la plantilla flexible contiene metadatos que describen cómo ejecutar la plantilla, como parámetros de canalización.
Además de las características de la plantilla de Flex que se explican en la documentación vinculada, las plantillas flexibles ofrecen ventajas sobre las plantillas clásicas para la administración de plantillas.
- Con las plantillas clásicas, es posible que varios artefactos, como los archivos JAR, se almacenen en una ubicación de etapa de pruebas de Cloud Storage, pero sin ninguna función para administrar varios artefactos. En comparación, una plantilla flexible se encapsula dentro de una imagen de Docker. La imagen empaqueta todas las dependencias además de las especificaciones de la plantilla de Flex, que se necesitan para tu canalización en un artefacto de implementación que administra Artifact Registry.
- Puedes usar las características de administración de imágenes de Docker para tus plantillas flexibles. Por ejemplo, puedes compartir de forma segura las plantillas de Flex si otorgas permisos de extracción (y, de manera opcional, de envío) a Artifact Registry. También puedes usar etiquetas de imágenes de Docker para diferentes versiones de tus plantillas de Flex.
Los desarrolladores pueden usar plantillas clásicas y plantillas flexibles para iniciar trabajos en un proyecto distinto del proyecto que es propietario del registro y del bucket de almacenamiento que aloja los elementos de la plantilla, o solo el bucket de almacenamiento si usas plantillas clásicas. Esta función es útil si necesitas aislar el procesamiento de datos de varios clientes en diferentes proyectos y trabajos de canalización. Con las plantillas flexibles, puedes especificar diferentes versiones de una imagen de Docker para usarla cuando inicies una canalización. Esta función simplificará el reemplazo por fases de las canalizaciones por lotes o las canalizaciones de transmisión en varios proyectos cuando actualices las plantillas más adelante.
Funciones de Dataflow para optimizar el uso de los recursos
Dataflow proporciona las siguientes funciones específicas del ejecutor para optimizar el uso de los recursos, lo que puede mejorar el rendimiento y reducir los costos:
- Streaming Engine: Streaming Engine traslada la ejecución de las canalizaciones de transmisión fuera de los trabajadores de VM hacia un servicio dedicado. Los beneficios incluyen una capacidad de respuesta mejorada de ajuste de escala automático, reducciones en los recursos consumidos de la VM de trabajador y actualizaciones automáticas del servicio sin reimplementación. En algunos casos, también puedes reducir el uso de recursos mediante el procesamiento al menos una vez para casos de uso que pueden tolerar duplicados. Se recomienda habilitar Streaming Engine para las canalizaciones de transmisión. La función está habilitada de forma predeterminada cuando usas las versiones más recientes del SDK de Java de Apache Beam o el SDK de Python.
- Dataflow Shuffle: Dataflow Shuffle traslada las operaciones de reproducción aleatoria de canalizaciones por lotes fuera de los trabajadores de VM hacia un servicio dedicado. Los beneficios incluyen una ejecución más rápida de la mayoría de las canalizaciones por lotes, un consumo de los recursos reducido por parte de la VM de trabajador, una capacidad de respuesta mejorada del ajuste de escala automático y una tolerancia a errores mejorada. Se recomienda habilitar Dataflow Shuffle para las canalizaciones por lotes. La función está habilitada de forma predeterminada con el SDK de Java de Apache Beam y el SDK de Python más reciente.
- Programación flexible de recursos (FlexRS): FlexRS reduce los costos de procesamiento por lotes con el uso de técnicas de programación avanzadas, el servicio de Dataflow Shuffle y una combinación de instancias de VM interrumpibles y VMs normales.
Actualiza canalizaciones de transmisión en la producción
Consulta Actualiza una canalización de transmisión.
La vida útil de un trabajo de Dataflow
Un trabajo de Dataflow pasa por un ciclo de vida que se representa con varios estados del trabajo.
Para ejecutar un trabajo de Dataflow, envíalo a una región.
El trabajo se enruta a un backend de Dataflow disponible en una de las zonas de la región. Antes de que Dataflow asigne un backend, verifica que tengas suficiente cuota y suficientes permisos para ejecutar el trabajo. Cuando se completen estas verificaciones previas y se haya asignado un backend, el trabajo pasará a un estado JOB_STATE_PENDING. En el caso de los trabajos de FlexRS, la asignación de backend podría retrasarse hasta un tiempo en el futuro, por lo que estos trabajos ingresarían en un estado JOB_STATE_QUEUED.
El backend asignado toma el trabajo que se ejecutará e intenta iniciar los trabajadores de Dataflow en tu proyecto de Google Cloud. La zona que se elige para las VMs de trabajador depende de una variedad de factores. Para los trabajos por lotes que usan Dataflow Shuffle, el servicio también intenta garantizar que el backend de Dataflow y las VMs de trabajador se encuentren en la misma zona para evitar el tráfico entre zonas.
Después de que se inician los trabajadores de Dataflow, solicitan el trabajo desde el backend de Dataflow. El backend es responsable de dividir el trabajo en fragmentos paralelizables, llamados paquetes, que se distribuyen entre los trabajadores. Si los trabajadores no pueden manejar el trabajo existente y si el ajuste de escala automático está habilitado, el backend inicia más trabajadores para manejar el trabajo. De manera similar, si se inician más trabajadores de los necesarios, algunos se cierran.
Una vez que se inician los trabajadores de Dataflow, el backend de Dataflow actúa como el plano de control para organizar la ejecución del trabajo. Durante el procesamiento, el plano de datos del trabajo realiza operaciones aleatorias, como GroupByKey, CoGroupByKey y Combine.
Los trabajos usan una de las siguientes implementaciones de plano de datos para operaciones aleatorias:
- El plano de datos se ejecuta en los trabajadores de Dataflow y los datos aleatorios se almacenan en discos persistentes.
- El plano de datos se ejecuta como un servicio, externo a las VM de trabajador. Esta implementación tiene dos variantes, que especificas cuando creas el trabajo: Dataflow Shuffle para las canalizaciones por lotes y Streaming Engine para canalizaciones de transmisión. La redistribución basada en servicios mejora de forma significativa el rendimiento y la escalabilidad de las operaciones de redistribución de datos en comparación con la redistribución basada en el trabajador.
Los trabajos de transmisión que ingresan al estado JOB_STATE_RUNNING siguen ejecutándose de forma indefinida hasta que se cancelan o se vacían, a menos que se produzca un error en el trabajo. Los trabajos por lotes se detienen de forma automática cuando se completa todo el procesamiento o se produce un error irrecuperable. Según cómo se detenga el trabajo, Dataflow establecerá el estado del trabajo como uno de los varios estados de la terminal, incluidos JOB_STATE_CANCELLED, JOB_STATE_DRAINED o JOB_STATE_DONE.
Prácticas recomendadas para la confiabilidad de las canalizaciones
En esta sección, se analizan las fallas que pueden ocurrir cuando trabajas con Dataflow y las prácticas recomendadas para los trabajos de Dataflow.
Siga los principios de aislamiento
Una recomendación general para mejorar la confiabilidad de las canalizaciones en general es seguir los principios de aislamiento de las regiones y zonas. Asegúrate de que las canalizaciones no tengan dependencias críticas entre regiones. Si tienes una canalización que tiene una dependencia crítica en servicios de varias regiones, una falla en cualquiera de esas regiones puede afectar tu canalización. Para evitar este problema, implementa en varias regiones para obtener redundancia y copias de seguridad.
Crea instantáneas de Dataflow
Dataflow ofrece una función de instantáneas que proporciona una copia de seguridad del estado de una canalización. Puedes restablecer la instantánea de la canalización en una nueva canalización de Dataflow de transmisión en otra zona o región. Luego, puedes iniciar el reprocesamiento de mensajes en los temas de Pub/Sub o Kafka a partir de la marca de tiempo de la instantánea. Si configuras instantáneas regulares de las canalizaciones, puedes minimizar el tiempo del objetivo de tiempo de recuperación (RTO).
Para obtener más información de las instantáneas de Dataflow, consulta Usa instantáneas de Dataflow.
Controla fallas de envío de trabajos
Debes enviar los trabajos de Dataflow que no son de plantilla con el SDK de Apache Beam. Para enviar el trabajo, debes ejecutar la canalización con Dataflow Runner, que se especifica como parte de la canalización opciones de la canalización. El SDK de Apache Beam almacena en etapa intermedia archivos en Cloud Storage, crea un archivo de solicitud de trabajo y envía el archivo a Dataflow.
Como alternativa, los trabajos creados a partir de plantillas de Dataflow usan diferentes métodos de envío, que generalmente se basan en la API de plantillas.
Es posible que veas diferentes errores de Dataflow que indican la falla de los trabajos de plantillas y de trabajos que no son de plantillas. En esta sección, se analizan diferentes tipos de fallas en el envío de trabajos y las prácticas recomendadas para solucionarlas o mitigarlas.
Reintenta los envíos de trabajos después de las fallas transitorias
Si un trabajo no se inicia debido a un problema del servicio de Dataflow, vuelve a intentarlo varias veces. Los reintentos mitigan los problemas de servicio transitorios.
Mitiga las fallas zonales con la especificación de una región para el trabajador
Dataflow proporciona disponibilidad regional y está disponible en varias regiones. Cuando un usuario envía un trabajo a una región sin especificar de forma explícita una zona, Dataflow enruta el trabajo a una zona en la región especificada según la disponibilidad del recurso.
La opción recomendada para la ubicación del trabajo es especificar una región de trabajador con la marca --region en lugar de la marca --zone siempre que sea posible. Esto permite que Dataflow proporcione un nivel adicional de tolerancia a errores para tus canalizaciones con la selección automática de la mejor zona posible para ese trabajo. Los trabajos que especifican una zona explícita no tienen este beneficio y fallan si ocurren problemas dentro de la zona. Si un envío de trabajos falla debido a un problema zonal, a menudo puedes solucionar el problema si reintentas el trabajo sin especificar una zona de forma explícita.
Mitiga las fallas regionales con el almacenamiento de los datos en varias regiones
Si una región completa no está disponible, intenta realizar el trabajo en otra región. Es importante pensar en la disponibilidad de tus datos cuando los trabajos fallen en las regiones. Para protegerte contra fallas en una sola región sin copiar los datos de forma manual en varias regiones, usa recursos de Google Cloud que almacenen los datos automáticamente en varias regiones. Por ejemplo, usa ubicaciones multirregionales de BigQuery para conjuntos de datos o buckets de dos regiones y de varias regiones 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 estén disponibles los datos.
Para ver un ejemplo del uso de servicios multirregionales con Dataflow, consulta Alta disponibilidad y redundancia geográfica.
Controla las fallas en las canalizaciones en ejecución
Después de enviar un trabajo y que se haya aceptado, las únicas operaciones válidas para el trabajo son las siguientes:
- Cancelar, para trabajos por lotes
- Actualizar, desviar o cancelar, para los trabajos de transmisión
No puedes cambiar la ubicación de los trabajos en ejecución después de enviar el trabajo. Si no usas FlexRS, los trabajos suelen comenzar a procesar datos unos minutos después del envío. Los trabajos de FlexRS pueden tardar hasta seis horas en comenzar el procesamiento de datos.
En esta sección, se analizan las fallas de la ejecución de trabajos y las prácticas recomendadas para resolverlas.
Supervisa los trabajos para identificar y resolver los problemas causados por los errores transitorios
En los trabajos por lotes, los paquetes que incluyen un elemento con errores se reintentan cuatro veces. Dataflow finaliza el trabajo luego de que un solo paquete falla cuatro veces. Esto soluciona muchos problemas transitorios. Sin embargo, si se produce una falla prolongada, el límite máximo de reintentos suele alcanzarse con rapidez, lo que permite que el trabajo falle con rapidez.
En el caso de la supervisión y la administración de incidentes, configura las reglas de alerta para detectar los trabajos con errores. Si un trabajo falla, inspecciona los registros del trabajo para identificar las fallas que generan los elementos con errores que superaron el límite de reintentos.
En el caso de los trabajos de transmisión, Dataflow vuelve a intentar los elementos con errores de forma indefinida. El trabajo no se finalizó. Sin embargo, el trabajo podría detenerse hasta que se resuelva el problema. Crea políticas de supervisión para detectar signos 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 la canalización para ayudar a identificar las detenciones de las canalizaciones producidas por elementos de trabajo que fallan en repetidas ocasiones.
Reinicia los trabajos en una zona diferente si se produce una interrupción zonal
Después de que se inicia un trabajo, los trabajadores de Dataflow que ejecutan el código de usuario están limitados a una zona única. Si ocurre una interrupción zonal, los trabajos de Dataflow a menudo se ven afectados, según el alcance de la interrupción.
Para las interrupciones que afectan solo a los backends de Dataflow, el servicio administrado migra de forma automática los backends a una zona diferente para que puedan continuar el trabajo. Si el trabajo usa Dataflow Shuffle, el backend no se puede mover a otra zona. Si se produce una migración del backend de Dataflow, los trabajos podrían detenerse de forma temporal.
Si ocurre una interrupción zonal, es probable que los trabajos en ejecución fallen o se detengan hasta que se restablezca la disponibilidad de la zona. Si una zona deja de estar disponible durante un período prolongado, detén los trabajos (cancélalos si son trabajos por lotes y vacíalos si son trabajos de transmisión) y, luego, reinícialos para que Dataflow elija una zona nueva y en buen estado.
Reinicia los trabajos por lotes en una región diferente si ocurre una interrupción regional
Si ocurre una interrupción regional en una región en la que se ejecutan tus trabajos de Dataflow, estos pueden fallar o detenerse. En el caso de los trabajos por lotes, reinicia el trabajo en una región diferente si es posible. Es importante asegurarse de que tus datos estén disponibles en diferentes regiones.
Mitiga las interrupciones regionales con la alta disponibilidad o la conmutación por error
En el caso de los trabajos de transmisión, según la tolerancia a errores y el presupuesto de tu aplicación, tienes diferentes opciones para mitigar las fallas. En el caso de una interrupción regional, la opción más simple y rentable es esperar hasta que finalice la interrupción. Sin embargo, si tu aplicación es sensible a la latencia o si el procesamiento de datos no se debe interrumpir o se debe reanudar con una demora mínima, en las siguientes secciones se analizan las opciones.
Alta disponibilidad: sensible a la latencia y sin pérdida de datos
Si tu aplicación no puede tolerar la pérdida de datos, ejecuta canalizaciones duplicadas en paralelo en dos regiones diferentes y haz que las canalizaciones consuman los mismos datos. Las mismas fuentes de datos deben estar disponibles en ambas regiones. Las aplicaciones descendentes que dependen de los resultados de estas canalizaciones deben poder alternar entre los resultados de estas dos regiones. Debido a la duplicación de recursos, esta opción implica el costo 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 y con posible pérdida de datos
Si tu aplicación puede tolerar una posible pérdida de datos, haz que la fuente de datos de transmisión esté disponible en varias regiones. Por ejemplo, con Pub/Sub, mantén dos suscripciones independientes para el mismo tema, una para cada región. Si ocurre una interrupción regional, inicia una canalización de reemplazo en otra región y haz que la canalización consuma los datos de la suscripción de copia de seguridad.
Vuelve a reproducir la suscripción de copia de seguridad en un momento apropiado para mantener la pérdida de datos al mínimo sin sacrificar la latencia. Las aplicaciones descendentes deben saber cómo cambiar al resultado de la canalización en ejecución, similar a la opción de alta disponibilidad. Esta opción usa menos recursos que ejecutar canalizaciones duplicadas porque solo se duplican los datos.
Alta disponibilidad y redundancia geográfica
Puedes ejecutar varias canalizaciones de transmisión en paralelo para el procesamiento de datos de alta disponibilidad. Por ejemplo, puedes ejecutar dos trabajos de transmisión paralelos en diferentes regiones, lo que proporciona redundancia geográfica y tolerancia a errores para el procesamiento de datos.
Si consideras la disponibilidad geográfica de las fuentes de datos y los receptores, puedes operar canalizaciones de extremo a extremo en una configuración multirregional con alta disponibilidad. En el siguiente diagrama, se muestra una implementación de ejemplo.
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 acceso rápido y global a los datos, a la vez que te permite controlar dónde se almacenan los mensajes. Pub/Sub puede almacenar automáticamente los mensajes publicados en la región de Google Cloud que está más cerca de los suscriptores o puedes configurarlos para que usen una región específica o un conjunto de regiones con las políticas de almacenamiento de mensajes.
Luego, Pub/Sub envía los mensajes a los suscriptores de todo el mundo, sin importar dónde se almacenen los mensajes. Los clientes de Pub/Sub no necesitan conocer las ubicaciones del servidor a las que se conectan, ya que los mecanismos globales de balanceo de cargas dirigen el tráfico al centro de datos de Google Cloud más cercano en el que se almacenan los mensajes.
Dataflow se ejecuta en regiones específicas de Google Cloud. Si ejecutas canalizaciones paralelas en regiones distintas de Google Cloud, puedes aislar tus trabajos de las fallas que afectan a una sola región. En el diagrama, se muestran dos instancias de la misma canalización, cada una de las cuales se ejecuta en una región diferente de Google Cloud.
BigQuery proporciona ubicaciones de conjuntos de datos regionales y multirregionales. Cuando eliges una ubicación multirregional, tu conjunto de datos se encuentra en al menos dos regiones geográficas. En el diagrama, se ilustran dos canalizaciones distintas, cada una de las cuales escribe en un conjunto de datos multirregional independiente.