Cloud Composer 1 | Cloud Composer 2
Nesta página, descrevemos a arquitetura de ambientes do Cloud Composer 2.
Configurações de arquitetura de ambiente
Os ambientes do Cloud Composer 2 podem ter as seguintes configurações de arquitetura:
Cada configuração altera um pouco a arquitetura dos recursos do ambiente.
Projetos de clientes e locatários
Quando você cria um ambiente, o Cloud Composer distribui os recursos desse ambiente entre um locatário e um projeto do cliente.
Projeto do cliente é um projeto do Google Cloud em que você cria seus ambientes. É possível criar mais de um ambiente em um único projeto do cliente.
O projeto do locatário é um projeto de locatário gerenciado pelo Google. O projeto do locatário oferece controle de acesso unificado e uma camada adicional de segurança de dados para seu ambiente. Cada ambiente do Cloud Composer tem o próprio projeto do locatário.
Componentes do ambiente
Um ambiente do Cloud Composer consiste em componentes do ambiente.
Um componente de ambiente é um elemento de uma infraestrutura gerenciada do Airflow executada no Google Cloud, como parte do seu ambiente.
Os componentes do ambiente são executados no locatário ou no projeto do cliente do ambiente.
Alguns componentes do ambiente são baseados em produtos independentes do Google Cloud. As cotas e limites para esses produtos também se aplicam aos seus ambientes. Por exemplo, os ambientes do Cloud Composer usam peerings de VPC. As cotas do número máximo de peerings de VPC se aplicam ao projeto do cliente. Portanto, quando o projeto atingir esse número máximo de peerings, não será possível criar mais ambientes.
Cluster do ambiente
O cluster do ambiente é um cluster do Google Kubernetes Engine nativo da VPC no modo Autopilot do seu ambiente:
Os nós do ambiente são VMs no cluster do ambiente.
Os pods no cluster do ambiente executam contêineres com outros componentes, como workers e programadores do Airflow. Os pods são executados em nós do ambiente.
Os recursos de carga de trabalho do cluster do ambiente gerenciam os conjuntos de pods no cluster do ambiente. Muitos componentes do ambiente são implementados como tipos diferentes de recursos de carga de trabalho. Por exemplo, os workers do Airflow são executados como Implantações. Além das implantações, o ambiente também tem StatefulSets, DaemonSets e tipos de carga de trabalho de jobs.
Por padrão, o Cloud Composer permite upgrades automáticos e reparos automáticos de nós para proteger o cluster do ambiente contra vulnerabilidades de segurança. Essas operações ocorrem durante janelas de manutenção que você especifica para seu ambiente.
Programadores, gatilho, workers e fila do Redis do Airflow
Os programadores do Airflow controlam a programação de execuções do DAG e tarefas individuais dos DAGs. Os programadores distribuem tarefas para workers do Airflow usando uma fila do Redis, que é executada como um aplicativo no cluster do ambiente. Os programadores do Airflow são executados como Implantações no cluster do ambiente.
Os workers do Airflow executam tarefas individuais dos DAGs utilizando-os na fila do Redis. Os workers do Airflow são executados como recursos personalizados no cluster do ambiente.
O acionador do Airflow monitora de maneira assíncrona todas as tarefas adiadas no ambiente. É possível configurar o número de instâncias do acionador ao criar ou atualizar os ambientes do Cloud Composer. O Cloud Composer é compatível com as seguintes configurações do acionador:
Contagem de acionadores:
- Resiliência padrão: é possível executar até 10 acionadores
- Alta resiliência: pelo menos 2 e no máximo 10
É possível definir o número de acionadores como zero, mas é necessário ter pelo menos uma instância de acionador no ambiente (ou pelo menos duas em ambientes altamente resilientes) para usar operadores adiáveis nos DAGs. Se o número de acionadores for definido como zero, o cluster do ambiente ainda vai executar uma carga de trabalho para eles, mas sem pods. Isso não gera custos.
Alocação de recursos do acionador:
- Máximo de
1 vCPUpor acionador - Memória máxima igual ao número de CPUs do engatilhador multiplicado por
6.5
- Máximo de
A fila do Redis contém uma fila de tarefas individuais dos seus DAGs. Os programadores do Airflow preenchem a fila. Os workers do Airflow executam as próprias tarefas. A fila do Redis é executada como um aplicativo StatefulSet no cluster do ambiente para que as mensagens persistam durante a reinicialização do contêiner.
Servidor da Web do Airflow
O servidor da Web do Airflow executa a IU do Airflow do seu ambiente.
No Cloud Composer 2, o servidor da Web do Airflow é executado como uma implantação no cluster do ambiente.
O Cloud Composer 2 fornece acesso à interface com base nas identidades de usuários e nas vinculações de políticas do IAM definidas para os usuários. Em comparação com o Cloud Composer 1, o Cloud Composer 2 usa um mecanismo diferente que não depende do Identity-Aware Proxy.
Banco de dados do Airflow
O banco de dados do Airflow é uma instância do Cloud SQL executada no projeto de locatário do seu ambiente. Ele hospeda o banco de dados de metadados do Airflow.
Para proteger informações confidenciais de conexão e fluxo de trabalho, o Cloud Composer permite acesso ao banco de dados apenas para a conta de serviço do seu ambiente.
Bucket do ambiente
Bucket do ambiente é um bucket do Cloud Storage que armazena DAGs, plug-ins, dependências de dados e registros do Airflow. O bucket do ambiente reside no projeto do cliente.
Quando você faz upload dos arquivos do DAG para a pasta /dags no bucket do ambiente,
o Cloud Composer sincroniza os DAGs com
os workers, os programadores e o servidor da Web do ambiente. É possível armazenar
os artefatos de fluxo de trabalho nas pastas data/ e logs/ sem se preocupar
com as limitações de tamanho e manter o controle de acesso total dos dados.
Outros componentes de ambiente
Um ambiente do Cloud Composer tem vários outros componentes:
Cloud SQL Storage. Armazena os backups do banco de dados do Airflow. O Cloud Composer faz o backup dos metadados do Airflow diariamente para reduzir as possíveis perdas de dados.
O Cloud SQL Storage é executado no projeto de locatário do seu ambiente. Não é possível acessar o conteúdo do Cloud SQL Storage.
Cloud SQL Proxy. Conecta outros componentes do ambiente ao banco de dados do Airflow.
Seu ambiente de IP público pode ter uma ou mais instâncias do Cloud SQL Proxy, dependendo do volume de tráfego para o banco de dados do Airflow.
No caso do ambiente de IP público, um proxy do Cloud SQL é executado como uma implantação no cluster do ambiente.
Quando implantado no cluster do ambiente, o Cloud SQL Proxy também autoriza o acesso à instância do Cloud SQL a partir de um aplicativo, cliente ou outro serviço do Google Cloud.
Monitoramento do Airflow. Relata métricas do ambiente para o Cloud Monitoring e aciona o DAG
airflow_monitoring. O DAGairflow_monitoringinforma os dados de integridade do ambiente, que são usados posteriormente, por exemplo, no painel de monitoramento do ambiente. O monitoramento do Airflow é executado como uma Implantação no cluster do ambiente.O Agente do Composer executa operações de ambiente, como criar, atualizar, fazer upgrade e excluir ambientes. Em geral, esse componente é responsável por introduzir alterações no seu ambiente. É executado como um Job no cluster do ambiente.
O InitDB do Airflow cria uma instância do Cloud SQL e um esquema inicial de banco de dados. O InitDB do Airflow é executado como um job no cluster do ambiente.
FluentD. Coleta registros de todos os componentes do ambiente e faz upload deles para o Cloud Logging. É executado como um DaemonSet no cluster do ambiente.
Assinaturas do Pub/Sub. Seu ambiente se comunica com o agente de serviço do GKE por meio de assinaturas do Pub/Sub. Ele depende do comportamento padrão do Pub/Sub para gerenciar mensagens. Não exclua tópicos do Pub/Sub
.*-composer-.*. O Pub/Sub é compatível com no máximo 10.000 tópicos por projeto.O endpoint do PSC conecta os programadores e os workers do Airflow ao banco de dados do Airflow na arquitetura IP privado com PSC.
O adaptador de métricas do cliente do Stackdriver informa métricas do seu ambiente para escalonamento automático. Esse componente é executado como uma implantação no cluster do ambiente.
O controlador de conjunto de workers do Airflow faz o escalonamento automático do seu ambiente com base nas métricas do adaptador de métricas do cliente Stackdriver. Esse componente é executado como uma implantação no cluster do ambiente.
Cloud Storage FUSE. Ativado o bucket do ambiente como um sistema de arquivos em workers, programadores e servidor da Web do Airflow. Assim, esses componentes podem acessar os dados do bucket. É executado como um DaemonSet no cluster do ambiente.
Arquitetura de ambiente de IP público
Em uma arquitetura de ambiente de IP público para o Cloud Composer 2:
- O projeto de locatário hospeda uma instância e um armazenamento do Cloud SQL.
- O projeto do cliente hospeda todos os outros componentes do ambiente.
- Os programadores e workers do Airflow no projeto do cliente se comunicam com o banco de dados do Airflow por meio de uma instância de proxy do Cloud SQL localizada no projeto do cliente.
Arquitetura de ambiente de IP privado
Por padrão, o Cloud Composer 2 usa o Private Service Connect para que os ambientes de IP privado se comuniquem internamente sem o uso de peerings da VPC. Também é possível usar peerings de VPC em vez do Private Service Connect no seu ambiente. Essa é uma opção não padrão.
Na arquitetura do ambiente de IP privado:
- O projeto de locatário hospeda uma instância e um armazenamento do Cloud SQL.
- O projeto do cliente hospeda todos os outros componentes do ambiente.
- Os programadores e workers do Airflow se conectam ao banco de dados do Airflow por meio do endpoint PSC configurado.
Arquitetura de IP privado altamente resiliente
Os ambientes altamente resilientes do Cloud Composer 2 usam redundância e mecanismos de failover integrados que reduzem a suscetibilidade do ambiente a falhas zonais e interrupções de ponto único de falha.
Nesse tipo de ambiente de IP privado:
- Uma instância do Cloud SQL do seu ambiente é configurada para alta disponibilidade (é uma instância regional). Em uma instância regional, a configuração é composta de uma instância principal e uma de espera.
- Seu ambiente executa dois programadores do Airflow, dois servidores da Web e, se forem usados, um mínimo de dois (até dez no total). Esses pares de componentes são executados em duas zonas separadas.
- O número mínimo de workers é definido como dois e o cluster do ambiente distribui instâncias de worker entre zonas. No caso de uma interrupção zonal, as instâncias de worker afetadas são reprogramadas em uma zona diferente.
Integração com o Cloud Logging e o Cloud Monitoring
O Cloud Composer é integrado ao Cloud Logging e ao Cloud Monitoring do seu projeto do Google Cloud , para que você tenha um local central para visualizar os registros de serviço e fluxo de trabalho do Airflow.
O Cloud Monitoring coleta e ingere métricas, eventos e metadados do Cloud Composer para gerar insights por meio de painéis e gráficos.
Devido à natureza de streaming do Cloud Logging, é possível ver os registros que o programador e os workers do Airflow emitem imediatamente em vez de esperar que os registros do Airflow apareçam no bucket do Cloud Storage do ambiente. Como os registros do Cloud Logging para Cloud Composer são baseados em google-fluentd, você tem acesso a todos os registros produzidos pelos programadores e workers do Airflow.
Para limitar o número de registros no seu projeto do Google Cloud, pare o processamento de todos os registros. Não desative o Logging.