Airflow gerenciado (Geração 3) | Airflow gerenciado (Geração 2) | Airflow gerenciado (Geração 1 legada)
Nesta página, descrevemos a arquitetura dos ambientes do Airflow Gerenciado.
Configurações de arquitetura de ambiente
Os ambientes do Airflow gerenciado (geração 1 legada) podem ter as seguintes configurações de arquitetura:
- Arquitetura de IP público
- Arquitetura de IP particular 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 Airflow Gerenciado 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 de locatário é um projeto de locatário gerenciado pelo Google e pertence à organização Google.com. O projeto de locatário oferece controle de acesso unificado e uma camada adicional de segurança de dados para seu ambiente. Cada ambiente do Airflow Gerenciado tem um projeto de locatário próprio.
Componentes do ambiente
Um ambiente do Airflow gerenciado 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.
Cluster do ambiente
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 Airflow Gerenciado 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.
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 upload dos arquivos do DAG para a pasta /dags no bucket do ambiente, o Airflow Gerenciado sincroniza os DAGs com os componentes do Airflow do ambiente.
Servidor da Web do Airflow
O servidor da Web do Airflow executa a interface do Airflow do seu ambiente.
No Airflow Gerenciado (geração 1 legada), 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 Airflow gerenciado 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 eles.
No Airflow gerenciado (Geração 1 legada), o servidor da Web do Airflow é executado em uma conta de serviço diferente dos workers e 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 Airflow Gerenciado 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:
Os programadores do Airflow analisam arquivos de definição de DAG, programam execuções de DAG com base no intervalo de programação e colocam em fila as tarefas a serem executadas pelos workers do Airflow. No Airflow Gerenciado (geração 1 legada), os processadores de DAG do Airflow 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 Airflow gerenciado (geração 1 legada):
- 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
Em uma arquitetura de ambiente de IP particular:
- 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 Airflow Gerenciado usará o IP particular com a 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 Airflow Gerenciado se integra ao Cloud Logging e ao Cloud Monitoring do seu projeto Google Cloud , para que você tenha um local central para visualizar os registros do Airflow e do DAG.
O Cloud Monitoring coleta e ingere métricas, eventos e metadados do Airflow Gerenciado para gerar insights por meio de painéis e gráficos.
Devido à natureza de streaming do Cloud Logging, é possível ver os registros emitidos pelos componentes do Airflow imediatamente em vez de esperar que eles apareçam no bucket do Cloud Storage do ambiente.
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.