Arquitetura de ambiente do Cloud Composer

Cloud Composer 1 | Cloud Composer 2

Nesta página, descrevemos a arquitetura de ambientes do Cloud Composer 1.

Configurações de arquitetura de ambiente

Os ambientes do Cloud Composer 1 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 de 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 Google Kubernetes Engine no modo padrão, nativo de VPC ou baseado em rotas. cluster 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 1, o servidor da Web Airlfow é uma instância do App Engine Flex que é executada 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 para contas de usuário que têm permissões suficientes para acessar o servidor da Web.

O servidor da Web do Airflow é executado em uma conta de serviço diferente daquela dos workers e dos programadores do Airflow. A conta de serviço para o servidor da Web é gerada automaticamente durante a criação do ambiente e deriva 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.

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 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 de ambiente:

  • 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.

    O 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 Airlfow é 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.

  • Sincronização de buckets Esse processo sincroniza buckets do ambiente nos projetos de cliente e locatário. Esse componente é usado no IP particular com a arquitetura de ambiente DRS. Esse componente é executado como um contêiner nos pods de outros componentes que usam buckets 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 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.

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 1:

  • 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

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

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 na arquitetura do ambiente do DRS.

No IP particular com a 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 é 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