Arquitetura de ambiente do Cloud Composer

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 de recursos do ambiente.

Projetos de clientes e locatários

Quando você cria um ambiente, o Cloud Composer distribui os recursos dele entre um locatário e um projeto do cliente.

Customer project é 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 locatário projeto 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 de 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 seu 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 diferentes tipos 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, 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 implantações no cluster do ambiente.

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 Aiflow do seu ambiente.

No Cloud Composer 2, o servidor da Web do Airflow é executado como uma implantação no cluster do ambiente.

O Identity-Aware Proxy não é usado para acesso no Cloud Composer 2.

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 minimizar 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 seu ambiente ao banco de dados do Airflow.

    Seu ambiente pode ter uma ou mais instâncias do Cloud SQL Proxy que desempenham papéis diferentes, dependendo da arquitetura do ambiente.

    Um proxy do Cloud SQL é executado como uma implantação no cluster do ambiente ou em uma instância do App Engine Flex no projeto de locatário de dados.

    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.

  • HAProxy. A carga equilibra o tráfego da instância do Cloud SQL entre duas instâncias do Cloud SQL Proxy executadas no projeto de locatário. Esse componente é usado em arquiteturas de ambiente de IP privado e executado como um contêiner na implantação do Cloud SQL Proxy.

  • Monitoramento do Airflow. Relata métricas do ambiente para o Cloud Monitoring e aciona o DAG airflow_monitoring. O DAG airflow_monitoring informa os dados de integridade do ambiente, que são processados 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 Airflow InitDB cria uma instância do Cloud SQL e um esquema inicial do banco de dados. O InitDB do Airflow é executado como um job no cluster do ambiente.

  • FluentD (em inglês) 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 do serviço GKE por meio de assinaturas 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 aceita no máximo 10.000 tópicos por projeto.

  • 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

Recursos de ambiente do Cloud Composer de IP público no projeto de locatário e de cliente
Figura 1. Arquitetura de ambiente de IP público (clique para ampliar)

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.

IP privado

Recursos de ambiente de IP privado do Cloud Composer no projeto de locatário e no projeto do cliente
Figura 2. Arquitetura de ambiente de IP privado (clique para ampliar)

Em uma arquitetura de ambiente de IP privado 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 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 é 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, interrompa a ingestão de todos os registros. Não desative o Logging.

A seguir