Cloud Composer 1 | Cloud Composer 2
En esta página, se describe la arquitectura de los entornos de Cloud Composer 2.
Configuración de la arquitectura del entorno
Los entornos de Cloud Composer 2 pueden tener las siguientes opciones de configuración de la arquitectura:
Cada configuración altera ligeramente la arquitectura de los recursos del entorno.
Proyectos del cliente y el usuario
Cuando creas un entorno, Cloud Composer distribuye los recursos del entorno entre un proyecto del usuario y uno del cliente.
El proyecto de cliente es un proyecto de Google Cloud en el que creas tus 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 un 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 de entorno.
Un componente del 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 proyecto del usuario o 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 para la cantidad máxima de intercambios de tráfico de VPC se aplican al proyecto de cliente, por lo que una vez que el proyecto alcance esta cantidad máxima de intercambios de tráfico, no podrás crear entornos adicionales.
Clúster del entorno
El clúster del entorno es un clúster de Google Kubernetes Engine nativo de la VPC de modo Autopilot de tu entorno:
Los nodos del entorno son VM en el clúster del entorno.
Los pods del clúster del entorno ejecutan contenedores con otros componentes del entorno, como los trabajadores y los programadores de Airflow. Los pods se ejecutan en nodos de entorno.
Los recursos de las cargas de trabajo del clúster de tu entorno administran conjuntos de pods en el clúster de tu entorno. Muchos componentes del entorno se implementan como diferentes tipos de recursos de las cargas 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 las vulnerabilidades de seguridad. Estas operaciones ocurren durante los períodos de mantenimiento que especificas para tu entorno.
Programadores de Airflow, activador, trabajadores y cola de Redis
Los programadores de Airflow controlan la programación de las ejecuciones del DAG y las tareas individuales de los DAG. Los programadores distribuyen las tareas entre 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 implementaciones en el clúster de tu entorno.
Los trabajadores de Airflow ejecutan tareas individuales desde los DAG. Para ello, las toman de la cola de Redis. Los trabajadores de Airflow se ejecutan como recursos personalizados en el clúster de tu entorno.
El activador de Airflow supervisa de forma asíncrona todas las tareas diferidas en tu entorno. Puedes configurar la cantidad de instancias del activador cuando creas o actualizas entornos de Cloud Composer. Cloud Composer admite las siguientes configuraciones de activadores:
Recuento de activadores:
- Resiliencia estándar: puedes ejecutar hasta 10 activadores
- Resiliencia alta: al menos 2 activadores, hasta un máximo de 10
Puedes establecer la cantidad de activadores en cero, pero necesitas al menos una instancia de activador en tu entorno (o al menos dos en entornos de alta resiliencia) para usar operadores diferibles en tus DAG. Si la cantidad de activadores está configurada en cero, el clúster de tu entorno seguirá ejecutando una carga de trabajo para ellos, pero sin pods, lo que no genera costos.
Asignación de recursos del activador:
- Máximo de
1 vCPUpor activador - Memoria máxima igual a la cantidad de CPU del activador multiplicada por
6.5
- Máximo de
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 StatefulSet en el clúster de tu entorno, para que los mensajes se mantengan en los reinicios de los contenedores.
Servidor web de Airflow
El servidor web de Airflow ejecuta la IU de Airflow de tu entorno.
En Cloud Composer 2, el servidor web de Airflow se ejecuta como una implementación en el clúster de tu entorno.
Cloud Composer 2 proporciona acceso a la interfaz en función de las identidades de los usuarios y las vinculaciones de políticas de IAM definidas para los usuarios. En comparación con Cloud Composer 1, Cloud Composer 2 usa un mecanismo diferente que no se basa en Identity-Aware Proxy.
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 del flujo de trabajo y la 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 total de acceso a tus datos.
Otros componentes del entorno
Un entorno de Cloud Composer tiene varios componentes adicionales del entorno:
Almacenamiento de Cloud SQL: Almacena las copias de seguridad de la base de datos de Airflow. Cloud Composer realiza copias de seguridad de los metadatos de Airflow diariamente para minimizar la posible pérdida de datos.
El almacenamiento de Cloud SQL 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 con la base de datos de Airflow.
Tu entorno de IP pública puede tener una o más instancias de proxy de Cloud SQL según el volumen de tráfico hacia la base de datos de Airflow.
En el caso del entorno de IP pública, un proxy de Cloud SQL se ejecuta como una implementación en el clúster de tu entorno.
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 u otro servicio de Google Cloud.
Supervisión de Airflow: Informa las métricas de entorno a Cloud Monitoring y activa el DAG
airflow_monitoring. El DAGairflow_monitoringinforma los datos de estado del entorno, que se usan más adelante, por ejemplo, en el panel de supervisión de tu entorno. La supervisión de Airflow se ejecuta como una implementación en el clúster de tu entorno.El agente del compositor realiza operaciones de entorno, como crear, actualizar, mejorar y borrar entornos. En general, este componente es responsable de realizar cambios en el entorno. Se ejecuta como un Job 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 los sube a Cloud Logging. Se ejecuta como un DaemonSet en el clúster de tu entorno.
Suscripciones de Pub/Sub: Tu entorno se comunica con el agente de servicio de GKE a través de suscripciones de Pub/Sub. Se basa en el comportamiento predeterminado de Pub/Sub para administrar mensajes. No borres los temas
.*-composer-.*de Pub/Sub. Pub/Sub admite un máximo de 10,000 temas por proyecto.El extremo de PSC conecta a los programadores y trabajadores de Airflow a la base de datos de Airflow en la arquitectura de IP privada con PSC.
El adaptador de métricas personalizadas de Stackdriver informa las métricas de tu entorno para el ajuste de escala automático. Este componente se ejecuta como una implementación en el clúster de tu entorno.
El controlador del conjunto de trabajadores de Airflow escala automáticamente tu entorno según las métricas del adaptador de Stackdriver de métricas personalizadas. Este componente se ejecuta como una implementación en el clúster de tu entorno.
Cloud Storage FUSE: Activa el bucket de tu entorno como un sistema de archivos en los trabajadores, los programadores y el servidor web de Airflow para que estos componentes puedan acceder a los datos del bucket. Se ejecuta como un DaemonSet en el clúster de tu entorno.
Arquitectura del entorno de IP pública
En una arquitectura del entorno de IP pública para Cloud Composer 2, haz lo siguiente:
- El proyecto de usuario aloja una instancia de Cloud SQL y el almacenamiento de Cloud SQL.
- El proyecto del cliente aloja todos los demás componentes del entorno.
- Los programadores y los trabajadores de Airflow en el proyecto del cliente se comunican con la base de datos de Airflow a través de una instancia del proxy de Cloud SQL ubicada en el proyecto del cliente.
Arquitectura del entorno de IP privada
De forma predeterminada, Cloud Composer 2 usa Private Service Connect para que tus entornos de IP privada se comuniquen de forma interna sin el uso de intercambio de tráfico de VPC. También es posible usar intercambios de tráfico de VPC en lugar de Private Service Connect en tu entorno. Esta es una opción no predeterminada.
En la arquitectura del entorno de IP privada, sigue estos pasos:
- El proyecto de usuario aloja una instancia de Cloud SQL y el almacenamiento de Cloud SQL.
- 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 extremo PSC configurado.
Arquitectura de IP privada altamente resiliente
Los entornos de Cloud Composer de alta resiliencia son entornos de Cloud Composer 2 que usan mecanismos de redundancia y conmutación por error integrados que reducen la susceptibilidad del entorno a fallas zonales y de interrupciones de puntos únicos.
En este tipo de entorno de IP privada, sucede lo siguiente:
- Una instancia de Cloud SQL de tu entorno está configurada para alta disponibilidad (es una instancia regional). Dentro de una instancia regional, la configuración se compone de una instancia principal y una instancia en espera.
- El entorno ejecuta dos programadores de Airflow, dos servidores web y, si se usan activadores, un mínimo de dos activadores (hasta diez en total). Estos pares de componentes se ejecutan en dos zonas separadas.
- La cantidad mínima de trabajadores se establece en dos, y el clúster de tu entorno distribuye las instancias de trabajador entre las zonas. En caso de una interrupción zonal, las instancias de trabajador afectadas se reprograman en una zona diferente.
Integración en Cloud Logging y Cloud Monitoring
Cloud Composer se integra en Cloud Logging y Cloud Monitoring de tu proyecto de Google Cloud para que tengas un lugar central en el que consultar los registros de flujo de trabajo y 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 inmediatamente 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 en tu proyecto de Google Cloud, puedes detener la transferencia de todos los registros. No inhabilites Logging.