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 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
Cluster do ambiente é um modoPadrão de cluster do Google Kubernetes Engine nativo de VPC ou Baseado em rotas 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, 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 Airflow do seu ambiente.
No Cloud Composer 1, o servidor da Web do Airflow é uma instância do App Engine Flex 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 com base nas identidades de usuários e nas vinculações de políticas do IAM definidas para os usuários.
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 é 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.
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.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
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.
Arquitetura de ambiente de IP privado
Figura 2. Arquitetura de ambiente de IP particular (clique para ampliar) 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
Figura 3. Arquitetura de ambiente de IP particular (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 com a arquitetura do ambiente do DRS.
Na arquitetura de ambiente de IP privado com 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, pare o processamento de todos os registros. Não desative o Logging.
A seguir