Cloud Composer 1 | Cloud Composer 2
Questa pagina descrive l'architettura degli ambienti Cloud Composer 2.
Configurazioni dell'architettura dell'ambiente
Gli ambienti Cloud Composer 2 possono avere le seguenti configurazioni dell'architettura:
Ogni configurazione altera leggermente l'architettura delle risorse dell'ambiente.
Progetti di clienti e tenant
Quando crei un ambiente, Cloud Composer distribuisce le risorse dell'ambiente tra un tenant e un progetto del cliente.
Un progetto cliente è un progetto Google Cloud in cui crei i tuoi ambienti. Puoi creare più di un ambiente in un singolo progetto cliente.
Il progetto tenant è un progetto tenant gestito da Google. Il progetto tenant offre controllo dell'accesso unificato e un ulteriore livello di sicurezza dei dati per il tuo ambiente. Ogni ambiente Cloud Composer ha il proprio progetto tenant.
Componenti dell'ambiente
Un ambiente Cloud Composer è costituito da componenti di ambiente.
Un componente dell'ambiente è un elemento di un'infrastruttura Airflow gestita che viene eseguita su Google Cloud, come parte del tuo ambiente.
I componenti di ambiente vengono eseguiti nel tenant o nel progetto cliente del tuo ambiente.
Alcuni dei componenti del tuo ambiente si basano su prodotti Google Cloud autonomi. Quote e limiti per questi prodotti si applicano anche ai tuoi ambienti. Ad esempio, gli ambienti Cloud Composer utilizzano i peering VPC. Le quote del numero massimo di peering VPC si applicano al progetto cliente, quindi, una volta che il tuo progetto raggiunge questo numero massimo di peering, non puoi creare altri ambienti.
Cluster dell'ambiente
Il cluster dell'ambiente è un cluster Google Kubernetes Engine in modalità Autopilot nativo di VPC del tuo ambiente:
I nodi di ambiente sono VM nel cluster dell'ambiente.
I pod nel cluster dell'ambiente eseguono container con altri componenti dell'ambiente, come gli scheduler e i worker di Airflow. i pod vengono eseguiti sui nodi dell'ambiente.
Le risorse del carico di lavoro del cluster del tuo ambiente gestiscono gli insiemi di pod nel cluster dell'ambiente. Molti componenti del tuo ambiente vengono implementati come diversi tipi di risorse dei carichi di lavoro. Ad esempio, i worker di Airflow vengono eseguiti come Deployment. Oltre ai deployment, nell'ambiente sono disponibili anche tipi di carichi di lavoro StatefulSet, DaemonSet e Job.
Per impostazione predefinita, Cloud Composer attiva upgrade automatici dei nodi e riparazione automatica dei nodi, per proteggere il cluster del tuo ambiente da vulnerabilità di sicurezza. Queste operazioni vengono eseguite durante i periodi di manutenzione specificati per il tuo ambiente.
Scheduler, triggerer, worker e coda Redis Airflow
Gli scheduler Airflow controllano la pianificazione delle esecuzioni di DAG e delle singole attività dei DAG. Gli scheduler distribuiscono le attività ai worker di Airflow utilizzando una coda Redis, che viene eseguita come applicazione nel cluster del tuo ambiente. Gli scheduler Airflow vengono eseguiti come Deployment nel cluster del tuo ambiente.
I lavoratori Airflow eseguono singole attività dai DAG prendendole dalla coda Redis. I worker di Airflow vengono eseguiti come risorse personalizzate nel cluster del tuo ambiente.
L'attivatore Airflow monitora in modo asincrono tutte le attività differite nel tuo ambiente. Puoi configurare il numero di istanze dell'attivatore quando crei o aggiorna gli ambienti di Cloud Composer. Cloud Composer supporta le seguenti configurazioni di trigger:
Conteggio triggerer:
- Resilienza standard: puoi eseguire fino a 10 triggerer
- Elevata resilienza: almeno 2 triggerer, fino a un massimo di 10
Puoi impostare il numero di trigger su zero, ma devi avere almeno un'istanza di triggerer nel tuo ambiente (o almeno due in ambienti altamente resilienti) per utilizzare gli operatori differibili nei DAG. Se il numero di trigger è impostato su zero, il cluster del tuo ambiente esegue comunque un carico di lavoro per questi trigger, ma senza pod non è previsto alcun costo.
Allocazione delle risorse del triggerer:
- Massimo
1 vCPUper attivatore - Memoria massima uguale al numero di CPU dell'attivatore moltiplicato per
6.5
- Massimo
Coda Redis contiene una coda di singole attività dei DAG. Gli scheduler Airflow riempiono la coda; i worker di Airflow eseguono le proprie attività da lì. La coda Redis viene eseguita come applicazione StatefulSet nel cluster del tuo ambiente, in modo che i messaggi vengano mantenuti dopo i riavvii dei container.
Server web Airflow
Il server web Airflow esegue l'UI di Airflow del tuo ambiente.
In Cloud Composer 2, il server web Airflow viene eseguito come deployment nel cluster del tuo ambiente.
Cloud Composer 2 fornisce l'accesso all'interfaccia in base alle identità utente e alle associazioni di criteri IAM definite per gli utenti. Rispetto a Cloud Composer 1, Cloud Composer 2 utilizza un meccanismo diverso che non si basa su Identity-Aware Proxy.
Database Airflow
Il database Airflow è un'istanza Cloud SQL in esecuzione nel progetto tenant del tuo ambiente. Ospita il database di metadati Airflow.
Per proteggere le informazioni sensibili sulla connessione e sul flusso di lavoro, Cloud Composer consente l'accesso al database solo all'account di servizio del tuo ambiente.
Bucket dell'ambiente
Il bucket dell'ambiente è un bucket Cloud Storage in cui sono archiviati i DAG, i plug-in, le dipendenze dei dati e i log di Airflow. Il bucket dell'ambiente si trova nel progetto del cliente.
Quando carichi i file DAG nella cartella /dags del bucket del tuo ambiente, Cloud Composer sincronizza i DAG con i worker, gli scheduler e il server web del tuo ambiente. Puoi archiviare gli artefatti del flusso di lavoro nelle cartelle data/ e logs/ senza preoccuparti dei limiti di dimensioni e mantenere il pieno controllo dell'accesso dell'accesso ai dati.
Altri componenti dell'ambiente
Un ambiente Cloud Composer ha diversi componenti di ambiente aggiuntivi:
Archiviazione Cloud SQL. Archivia i backup del database Airflow. Cloud Composer esegue quotidianamente il backup dei metadati Airflow per ridurre al minimo la potenziale perdita di dati.
Cloud SQL Storage viene eseguito nel progetto tenant del tuo ambiente. Non puoi accedere ai contenuti di Cloud SQL Storage.
Proxy Cloud SQL. Connette altri componenti del tuo ambiente al database Airflow.
Il tuo ambiente IP pubblico può avere una o più istanze di proxy Cloud SQL, a seconda del volume di traffico verso il database Airflow.
Nel caso di un ambiente IP pubblico, un proxy Cloud SQL viene eseguito come deployment nel cluster del tuo ambiente.
Una volta eseguito il deployment nel cluster del tuo ambiente, il proxy Cloud SQL autorizza anche l'accesso all'istanza Cloud SQL da un'applicazione, un client o un altro servizio Google Cloud.
Monitoraggio del flusso d'aria. Segnala le metriche di ambiente a Cloud Monitoring e attiva il DAG airflow_monitoring. Il DAG airflow_monitoring segnala i dati di integrità dell'ambiente che vengono utilizzati in seguito, ad esempio, nella dashboard di monitoraggio del tuo ambiente. Il monitoraggio di Airflow viene eseguito come
deployment nel cluster del tuo ambiente.
L'agente Composer esegue operazioni relative all'ambiente come la creazione, l'aggiornamento, l'upgrade e l'eliminazione degli ambienti. In generale, questo componente è responsabile dell'introduzione di modifiche nell'ambiente. Viene eseguito come Job nel cluster del tuo ambiente.
Airflow InitDB crea un'istanza Cloud SQL e uno schema di database iniziale. Airflow InitDB viene eseguito come Job nel cluster del tuo ambiente.
FluentD. Raccoglie i log da tutti i componenti dell'ambiente e li carica in Cloud Logging. Viene eseguito come DaemonSet nel cluster del tuo ambiente.
Sottoscrizioni Pub/Sub. Il tuo ambiente comunica con l'agente di servizio GKE tramite gli abbonamenti Pub/Sub. Si basa sul comportamento predefinito di Pub/Sub per gestire i messaggi. Non eliminare .*-composer-.* argomenti Pub/Sub. Pub/Sub supporta un massimo di 10.000 argomenti per progetto.
L'endpoint PSC connette scheduler e worker Airflow al database Airflow nell'architettura IP privato con PSC.
L'adattatore per le metriche dei clienti genera report sulle metriche del tuo ambiente per la scalabilità automatica. Questo componente viene eseguito come deployment nel cluster del tuo ambiente.
Controller Airflow Worker Set scala automaticamente il tuo ambiente in base alle metriche fornite dall'adattatore Stackdriver per le metriche dei clienti. Questo componente viene eseguito come deployment nel cluster del tuo ambiente.
FUSE di Cloud Storage Monta il bucket del tuo ambiente come file system su worker, scheduler e server web Airflow, in modo che questi componenti possano accedere ai dati dal bucket. Viene eseguito come DaemonSet nel cluster del tuo ambiente.
Architettura dell'ambiente IP pubblico
In un'architettura di ambiente IP pubblico per Cloud Composer 2:
- Il progetto tenant ospita un'istanza Cloud SQL e spazio di archiviazione di Cloud SQL.
- Il progetto del cliente ospita tutti gli altri componenti dell'ambiente.
- Gli scheduler e i worker di Airflow nel progetto del cliente comunicano con il database Airflow tramite un'istanza proxy Cloud SQL situata nel progetto del cliente.
Architettura dell'ambiente IP privato
Per impostazione predefinita, Cloud Composer 2 utilizza Private Service Connect, in modo che i tuoi ambienti IP privati comunichino internamente senza l'utilizzo di peering VPC. Nel tuo ambiente puoi anche utilizzare i peering VPC anziché Private Service Connect. Questa è un'opzione non predefinita.
Nell'architettura dell'ambiente IP privato:
- Il progetto tenant ospita un'istanza Cloud SQL e spazio di archiviazione di Cloud SQL.
- Il progetto del cliente ospita tutti gli altri componenti dell'ambiente.
- Gli scheduler e i worker di Airflow si connettono al database Airflow tramite l'endpoint PSC configurato.
Architettura degli IP privati altamente resilienti
Gli ambienti Cloud Composer altamente resiliente sono ambienti Cloud Composer 2 che utilizzano meccanismi di ridondanza e failover integrati che riducono la suscettibilità dell'ambiente a errori a livello di zona e single point of failure.
In questo tipo di ambiente IP privato:
- Un'istanza Cloud SQL del tuo ambiente è configurata per l'alta disponibilità (è un'istanza a livello di regione). All'interno di un'istanza a livello di regione, la configurazione è composta da un'istanza principale e un'istanza in standby.
- Il tuo ambiente esegue due scheduler Airflow, due server web e, se vengono utilizzati gli attivatori, almeno due (fino a dieci in totale). Queste coppie di componenti vengono eseguite in due zone distinte.
- Il numero minimo di worker è impostato su due e il cluster del tuo ambiente distribuisce le istanze worker tra le zone. In caso di interruzione di una zona, le istanze worker interessate vengono riprogrammate in una zona diversa.
Integrazione con Cloud Logging e Cloud Monitoring
Cloud Composer si integra con Cloud Logging e Cloud Monitoring del tuo progetto Google Cloud , in modo da avere una posizione centrale in cui visualizzare i log del flusso di lavoro e dei servizi Airflow.
Cloud Monitoring raccoglie e importa metriche, eventi e metadati da Cloud Composer per generare insight tramite dashboard e grafici.
Grazie alla natura in modalità flusso di Cloud Logging, puoi visualizzare i log emessi immediatamente dallo scheduler e dai worker di Airflow invece di attendere che i log di Airflow vengano visualizzati nel bucket Cloud Storage del tuo ambiente. Poiché i log di Cloud Logging per Cloud Composer sono basati su google-fluentd, hai accesso a tutti i log prodotti dagli scheduler e dai worker di Airflow.
Per limitare il numero di log nel progetto Google Cloud, puoi interrompere l'importazione di tutti i log. Non disabilitare Logging.