Arquitectura del entorno de Cloud Composer

Cloud Composer 1 | Cloud Composer 2

En esta página, se describe la arquitectura de los entornos de Cloud Composer 1.

Configuración de la arquitectura del entorno

Los entornos de Cloud Composer 1 pueden tener las siguientes configuraciones de arquitectura:

Cada configuración altera un poco la arquitectura de los recursos del entorno.

Proyectos de usuario y de cliente

Cuando creas un entorno, Cloud Composer distribuye los recursos del entorno entre un usuario y un proyecto de cliente.

El proyecto del cliente es un proyecto de Google Cloud en el que creas los entornos. Puedes crear más de un entorno en un solo proyecto de cliente.

El proyecto de usuario es un proyecto de usuario administrado por Google. El proyecto de usuario proporciona control de acceso unificado y una capa adicional de seguridad de datos para tu entorno. Cada entorno de Cloud Composer tiene su propio proyecto de usuario.

Componentes del entorno

Un entorno de Cloud Composer consta de componentes del entorno.

Un componente de entorno es un elemento de una infraestructura administrada de Airflow que se ejecuta en Google Cloud, como parte de tu entorno.

Los componentes del entorno se ejecutan en el usuario o en el proyecto del cliente de tu entorno.

Algunos de los componentes de tu entorno se basan en productos independientes de Google Cloud. Las cuotas y los límites de estos productos también se aplican a tus entornos. Por ejemplo, los entornos de Cloud Composer usan intercambios de tráfico de VPC. Las cuotas sobre la cantidad máxima de intercambios de tráfico de VPC se aplican a tu proyecto de cliente, por lo que, una vez que tu proyecto alcance esta cantidad máxima, no podrás crear entornos adicionales.

Clúster del entorno

El clúster del entorno es un modo estándar nativo de VPC o basado en rutas de Google Kubernetes Engine clúster de tu entorno:

  • Los nodos del entorno son VM en el clúster del entorno.

  • Los pods en el clúster del entorno ejecutan contenedores con otros componentes del entorno, como los trabajadores y programadores de Airflow. Los pods se ejecutan en nodos de entorno.

  • Los recursos de cargas de trabajo del clúster de tu entorno administran conjuntos de pods en el clúster de tu entorno. Muchos componentes de tu entorno se implementan como tipos diferentes de recursos de carga de trabajo. Por ejemplo, los trabajadores de Airflow se ejecutan como implementaciones. Además de las implementaciones, tu entorno también tiene tipos de carga de trabajo StatefulSets, DaemonSets y Jobs.

De forma predeterminada, Cloud Composer habilita las actualizaciones automáticas de nodos y la reparación automática de nodos para proteger el clúster de tu entorno de vulnerabilidades de seguridad. Estas operaciones ocurren durante los períodos de mantenimiento que especifiques para el entorno.

Programadores, trabajadores y cola de Redis de Airflow

Los programadores de Airflow controlan la programación de las ejecuciones de DAG y las tareas individuales desde DAG. Los programadores distribuyen tareas a los trabajadores de Airflow mediante una cola de Redis, que se ejecuta como una aplicación en el clúster de tu entorno. Los programadores de Airflow se ejecutan como Deployments en el clúster del entorno.

Los trabajadores de Airflow ejecutan tareas individuales desde los DAG; para ello, los toman de la cola de Redis. Los trabajadores de Airflow se ejecutan como implementaciones en el clúster del entorno.

La cola de Redis contiene una cola de tareas individuales de tus DAG. Los programadores de Airflow llenan la cola. Los trabajadores de Airflow toman sus tareas de ella. La cola de Redis se ejecuta como una aplicación de StatefulSet en el clúster del entorno, de modo que los mensajes persistan en los reinicios del contenedor.

Servidor web de Airflow

El servidor web de Airflow ejecuta la IU de Aiflow en tu entorno.

En Cloud Composer 1, el servidor web de Airlfow es una instancia de App Engine Flex que se ejecuta en el proyecto de usuario de tu entorno.

El servidor web de Airflow está integrado en Identity-Aware Proxy. Cloud Composer oculta los detalles de integración de IAP y proporciona acceso al servidor web para las cuentas de usuario que tienen suficientes permisos a fin de acceder al servidor web.

El servidor web de Airflow se ejecuta en una cuenta de servicio diferente a la de los trabajadores de Airflow y los programadores de Airflow. La cuenta de servicio para el servidor web se genera de forma automática durante la creación del entorno y se deriva del dominio del servidor web. Por ejemplo, si el dominio es example.appspot.com, la cuenta de servicio es example@appspot.gserviceaccount.com.

Base de datos de Airflow

La base de datos de Airflow es una instancia de Cloud SQL que se ejecuta en el proyecto de usuario de tu entorno. Aloja la base de datos de metadatos de Airflow.

Para proteger la información sensible y el flujo de trabajo de conexión, Cloud Composer permite el acceso a la base de datos solo a la cuenta de servicio de tu entorno.

Bucket del entorno

El bucket de entorno es un bucket de Cloud Storage que almacena DAG, complementos, dependencias de datos y registros de Airflow. El bucket del entorno reside en el proyecto del cliente.

Cuando subes tus archivos DAG a la carpeta /dags en el bucket de tu entorno, Cloud Composer sincroniza los DAG con los trabajadores, los programadores y el servidor web de tu entorno. Puedes almacenar tus artefactos de flujo de trabajo en las carpetas data/ y logs/ sin preocuparte por las limitaciones de tamaño y conservar el control de acceso completo a tus datos.

Otros componentes del entorno

Un entorno de Cloud Composer tiene varios componentes adicionales de entorno:

  • Almacenamiento de Cloud SQL. Almacena las copias de seguridad de la base de datos de Airflow. Cloud Composer crea una copia de seguridad diaria de los metadatos de Airflow para minimizar la posible pérdida de datos.

    Cloud SQL Storage se ejecuta en el proyecto de usuario de tu entorno. No puedes acceder al contenido de Cloud SQL Storage.

  • Proxy de Cloud SQL. Conecta otros componentes de tu entorno a la base de datos de Airflow.

    Tu entorno puede tener una o más instancias del proxy de Cloud SQL que desempeñen funciones diferentes, según la arquitectura de tu entorno.

    Un proxy de Cloud SQL se ejecuta como una implementación en el clúster de tu entorno o en una instancia de App Engine Flex en el proyecto de usuario. ,

    Cuando se implementa en el clúster de tu entorno, el proxy de Cloud SQL también autoriza el acceso a tu instancia de Cloud SQL desde una aplicación, un cliente o algún otro servicio de Google Cloud.

  • HAProxy. El balanceo de cargas carga el tráfico a la instancia de Cloud SQL entre dos instancias del proxy de Cloud SQL que se ejecutan en el proyecto de usuario. Este componente se usa en arquitecturas de entorno de IP privada y se ejecuta como contenedor en la implementación del proxy de Cloud SQL.

  • Supervisión de Airflow. Informa las métricas de entorno a Cloud Monitoring y activa el DAG airflow_monitoring. El DAG de airflow_monitoring informa los datos de estado del entorno, que más tarde se demanda, por ejemplo, en el panel de supervisión de tu entorno. La supervisión de Airlfow se ejecuta como una implementación en el clúster de tu entorno.

  • Composer Agent realiza operaciones de entorno, como crear, actualizar, actualizar y borrar entornos. En general, este componente es responsable de ingresar cambios en el entorno. Se ejecuta como un Trabajo en el clúster de tu entorno.

  • Airflow InitDB crea una instancia de Cloud SQL y un esquema de base de datos inicial. Airflow InitDB se ejecuta como un Job en el clúster de tu entorno.

  • FluentD. Recopila registros de todos los componentes del entorno y sube los registros a Cloud Logging. Se ejecuta como un DaemonSet en el clúster del entorno.

  • Suscripciones de Pub/Sub. Tu entorno se comunica con su agente de servicio de GKE a través de las suscripciones de Pub/Sub. Se basa en el comportamiento predeterminado de Pub/Sub para administrar los mensajes. No borres los temas de Pub/Sub .*-composer-.*. Pub/Sub admite un máximo de 10,000 temas por proyecto.

  • Sincronización de depósitos. En este proceso, se sincronizan los depósitos de entorno en los proyectos del usuario y del cliente. Este componente se usa en la IP privada con la arquitectura del entorno de DRS. Este componente se ejecuta como un contenedor en los pods de otros componentes que usan depósitos de entorno.

Arquitectura del entorno de IP pública

Recursos del entorno de IP pública de Cloud Composer en el proyecto de usuario y el proyecto de cliente
Figura 1: Arquitectura del entorno de IP pública (haz clic para ampliar)

En una arquitectura de entorno de IP pública para Cloud Composer 1:

  • El proyecto de usuario aloja una instancia de Cloud SQL, un almacenamiento de Cloud SQL y una instancia de App Engine Flex que ejecuta el servidor web de Airflow.
  • El proyecto del cliente aloja todos los demás componentes del entorno.
  • Los programadores y trabajadores de Airflow en el proyecto del cliente se comunican con la base de datos de Airflow a través de instancias de proxy de Cloud SQL ubicadas en el proyecto del cliente.
  • El servidor web de Airflow en el proyecto de usuario se comunica con la base de datos de Airflow a través de una instancia de proxy de Cloud SQL ubicada en el proyecto de usuario.

IP privada

Recursos del entorno de IP privada de Cloud Composer en el proyecto de usuario y el proyecto de cliente
Figura 2: Arquitectura del entorno de IP privada (haz clic para ampliar)

En una arquitectura de entorno de IP privada para Cloud Composer 1:

  • El proyecto de usuario aloja una instancia de Cloud SQL, almacenamiento de Cloud SQL y dos instancias de App Engine que ejecutan el servidor web de Airflow.
  • El proyecto del cliente aloja todos los demás componentes del entorno.
  • Los programadores y trabajadores de Airflow se conectan a la base de datos de Airflow a través del proceso HAProxy en el clúster del entorno.
  • En el proceso de HAProxy, se balancean las cargas del tráfico a la instancia de Cloud SQL entre dos instancias del proxy de Cloud SQL que se encuentran en el proyecto de usuario. Los entornos de IP privadas usan dos instancias del proxy de Cloud SQL porque el proyecto del cliente no accede a la base de datos directamente debido a las limitaciones de la red. Se necesitan dos instancias para garantizar que los componentes de tu entorno tengan acceso a la base de datos en todo momento.

IP privada con DRS

Recursos del entorno de Cloud Composer en el proyecto de usuario y el proyecto de cliente (haz clic para agrandar)
Figura 3: Arquitectura del entorno de IP privada (haz clic para ampliar)

Si la política de la organización de uso compartido restringido al dominio (DRS) está activada en tu proyecto, Cloud Composer usa la IP privada con la arquitectura del entorno de DRS.

En una IP privada con arquitectura de entorno de DRS:

  • En el proyecto de usuario, se aloja una instancia de Cloud SQL, Cloud SQL Storage y dos instancias de App Engine que ejecutan el servidor web de Airflow.

  • El proyecto de usuario aloja un bucket de entorno adicional. El servidor web de Airflow accede a este bucket directamente.

  • El proyecto del cliente aloja todos los demás componentes del entorno.

  • El proyecto del cliente aloja el proceso de sincronización de depósitos en el clúster del entorno. En este proceso, se sincronizan dos depósitos de entorno.

  • Los programadores y trabajadores de Airflow se conectan a la base de datos de Airflow a través del proceso HAProxy en el clúster del entorno.

  • En el proceso de HAProxy, se balancean las cargas del tráfico a la instancia de Cloud SQL entre dos instancias del proxy de Cloud SQL que se encuentran en el proyecto de usuario. Los entornos de IP privadas usan dos instancias del proxy de Cloud SQL porque el proyecto del cliente no accede a la base de datos directamente debido a las limitaciones de la red. Se necesitan dos instancias para garantizar que los componentes de tu entorno tengan acceso a la base de datos en todo momento.

Integración en Cloud Logging y Cloud Monitoring

Cloud Composer se integra en Cloud Logging y Cloud Monitoring de tu proyecto de Google Cloud , de modo que tengas un lugar central para ver los registros de flujo de trabajo y del servicio de Airflow.

Cloud Monitoring recopila y transfiere métricas, eventos y metadatos de Cloud Composer para generar estadísticas a través de paneles y gráficos.

Debido a la naturaleza de transmisión de Cloud Logging, puedes ver los registros que el programador y los trabajadores de Airflow emiten de inmediato en lugar de esperar a que los registros de Airflow aparezcan en el bucket de Cloud Storage de tu entorno. Debido a que los registros de Cloud Logging para Cloud Composer se basan en google-fluentd, tienes acceso a todos los registros que producen los trabajadores y programadores de Airflow.

Para limitar la cantidad de registros del proyecto de Google Cloud, puedes detener la transferencia de todos los registros. No inhabilites Logging.

¿Qué sigue?