Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3
Nesta página, descrevemos a arquitetura dos ambientes do Cloud Composer.
Configurações de arquitetura de ambiente
Os ambientes do Cloud Composer 1 podem ter as seguintes configurações de arquitetura:
- Arquitetura de IP público
- Arquitetura de IP privado com peerings de VPC
- IP particular com arquitetura de compartilhamento restrito de domínio (DRS)
Projetos de clientes e locatários
Quando você cria um ambiente, o Cloud Composer distribui os recursos dele entre um projeto de locatário e um 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 de locatário fornece controle de acesso unificado e uma camada adicional de segurança de dados para o ambiente. Cada ambiente do Cloud Composer tem um projeto de locatário próprio.
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 seu ambiente.
Cluster do ambiente
O cluster do ambiente é um cluster do Google Kubernetes Engine no modo Padrão nativo de VPC ou baseado em rotas do seu ambiente:
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 acontecem durante as janelas de manutenção que você especifica para o ambiente.
Bucket do ambiente
O 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 está localizado no projeto do cliente.
Quando você faz o upload dos arquivos DAG para a pasta /dags no bucket do ambiente, o Cloud Composer sincroniza os DAGs com os componentes do Airflow do ambiente.
Servidor da Web do Airflow
O servidor da Web Airflow executa a interface do Airflow do seu ambiente.
No Cloud Composer 1, o servidor da Web do Airflow é executado no projeto de locatário do seu ambiente.
O servidor da Web do Airflow é integrado ao Identity-Aware Proxy. O Cloud Composer oculta os detalhes de integração do IAP e fornece acesso ao servidor da Web com base nas identidades dos usuários e nas vinculações de políticas do IAM definidas para os usuários.
No Cloud Composer 1, o servidor da Web do Airflow é executado em uma conta de serviço diferente dos workers e dos programadores do Airflow. A conta de serviço do servidor da Web é gerada automaticamente durante a criação do ambiente e derivada do domínio do servidor da Web. Por exemplo, se o domínio for example.appspot.com, a
conta de serviço será example@appspot.gserviceaccount.com.
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.
Outros componentes do Airflow
Outros componentes do Airflow que são executados no seu ambiente são:
Os programadores do Airflow analisam arquivos de definição do DAG, programam execuções de DAG com base no intervalo de programação e enfileiram tarefas para execução por workers do Airflow. No Cloud Composer 1, os processadores do Airflow do DAG são executados como parte dos componentes do programador.
Os workers do Airflow executam tarefas programadas pelos programadores do Airflow.
Arquitetura de ambiente de IP público
Em uma arquitetura de ambiente de IP público para o Cloud Composer 1:
- O projeto de locatário hospeda uma instância do Cloud SQL, o armazenamento do Cloud SQL e uma instância do App Engine Flex que executa o servidor da Web do Airflow.
- 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 instâncias de proxy do Cloud SQL localizadas no projeto do cliente.
- O servidor da Web do Airflow no projeto de locatário se comunica com o banco de dados do Airflow por meio de uma instância de proxy do Cloud SQL localizada no projeto de locatário.
Arquitetura do ambiente de IP privado
Em uma arquitetura de ambiente de IP privado:
- O projeto de locatário hospeda uma instância do Cloud SQL, armazenamento do Cloud SQL e duas instâncias do App Engine que executam o servidor da Web do Airflow.
- 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 processo HAProxy no cluster do ambiente.
- A carga do processo HAProxy equilibra o tráfego à instância do Cloud SQL entre duas instâncias do Cloud SQL Proxy, localizadas no projeto de locatário. Devido às limitações da rede, os ambientes de IP privado usam duas instâncias do Cloud SQL Proxy porque o projeto do cliente não acessa o banco de dados diretamente. Duas instâncias são necessárias para garantir que os componentes do ambiente tenham sempre acesso ao banco de dados.
IP particular com DRS
Se a política organizacional de Compartilhamento restrito de domínio (DRS, na sigla em inglês) estiver ativada no projeto, o Cloud Composer usará o IP particular com a arquitetura do ambiente do DRS.
No IP privado com arquitetura de ambiente DRS:
O projeto de locatário hospeda uma instância do Cloud SQL, armazenamento do Cloud SQL e duas instâncias do App Engine que executam o servidor da Web do Airflow.
O projeto de locatário hospeda o bucket adicional do ambiente. O servidor da Web do Airflow acessa esse bucket diretamente.
O projeto do cliente hospeda todos os outros componentes do ambiente.
O projeto do cliente hospeda o processo de sincronização do bucket no cluster do ambiente. Esse processo sincroniza dois buckets do ambiente.
Os programadores e workers do Airflow se conectam ao banco de dados do Airflow por meio do processo HAProxy no cluster do ambiente.
A carga do processo HAProxy equilibra o tráfego à instância do Cloud SQL entre duas instâncias do Cloud SQL Proxy, localizadas no projeto de locatário. Devido às limitações da rede, os ambientes de IP privado usam duas instâncias do Cloud SQL Proxy porque o projeto do cliente não acessa o banco de dados diretamente. Duas instâncias são necessárias para garantir que os componentes do ambiente tenham sempre acesso ao banco de dados.
Integração com o Cloud Logging e o Cloud Monitoring
O Cloud Composer se integra ao Cloud Logging e ao Cloud Monitoring do seu projeto do Google Cloud para que você tenha um local central para visualizar os registros do DAG e 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 visualizar os registros emitidos por componentes do Airflow imediatamente, em vez de esperar que eles apareçam no bucket do Cloud Storage do seu ambiente.
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.