Airflow gerenciado (Geração 3) | Airflow gerenciado (Geração 2) | Airflow gerenciado (Geração 1 legada)
Esta página descreve 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 peering 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 Google Cloud projeto em que você cria seus ambientes. É possível criar mais de um ambiente em um único projeto do cliente.
_Projeto do 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 o próprio projeto do locatário.
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 executado no Google Cloud 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 modo Padrão nativo de VPC ou Baseado em rotas de cluster do Google Kubernetes Engine do seu ambiente:
Por padrão, o Airflow gerenciado permite upgrades automáticos de nós 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
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 seu
ambiente, o Airflow gerenciado sincroniza os DAGs com os componentes do Airflow do ambiente.
Servidor da Web do Airflow
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 do usuário e nas vinculações de políticas do IAM definidas para os usuários.
No Airflow gerenciado (Geração 1 legada), 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 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 são:
Programadores do Airflow analisam arquivos de definição 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 DAG do Airflow são executados como parte dos componentes do programador.
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 particular
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 é integrado ao Cloud Logging e ao Cloud Monitoring do seu Google Cloud projeto, 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 através de painéis e gráficos.
Devido à natureza de streaming do Cloud Logging, é possível visualizar os registros emitidos pelos componentes do Airflow imediatamente em vez de esperar que os registros do Airflow apareçam no bucket do Cloud Storage do ambiente.
Para limitar o número de registros no seu Google Cloud projeto, você pode parar o processamento de todos os registros. Não desative o Logging.