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 2) podem ter as seguintes configurações de arquitetura:
- Arquitetura de IP público
- Arquitetura de IP particular
- Arquitetura de IP particular altamente resiliente
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 cluster do Google Kubernetes Engine nativo da VPC no modo Autopilot 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.
O Airflow gerenciado fornece acesso à interface com base nas identidades do usuário e nas vinculações de política do IAM definidas para os usuários.
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:
Os 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 2), os processadores de DAG do Airflow são executados como parte dos componentes do programador.
Os acionadores do Airflow monitoram de forma assíncrona todas as tarefas adiadas no seu ambiente. Se você definir o número de acionadores no ambiente acima de zero, poderá usar operadores adiáveis nos DAGs.
Os workers do Airflow executam tarefas programadas pelos programadores do Airflow. Os números mínimo e máximo de workers no ambiente mudam dinamicamente dependendo do número de tarefas na fila.
Arquitetura de ambiente de IP público
Em uma arquitetura de ambiente de IP público para o Airflow gerenciado (Geração 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.
Arquitetura de ambiente de IP particular
Por padrão, o Airflow gerenciado (Geração 2) usa o Private Service Connect para que os ambientes de IP particular se comuniquem internamente sem o uso de peerings de VPC. Também é possível usar peerings de VPC em vez do Private Service Connect no ambiente. Essa é uma opção não padrão.
Na arquitetura de ambiente de IP particular:
- 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 endpoint PSC configurado.
Arquitetura de IP particular altamente resiliente
Os ambientes do Airflow gerenciado altamente resilientes (de alta disponibilidade) são ambientes multizonais que usam mecanismos de redundância e failover integrados que reduzem a suscetibilidade do ambiente a falhas de zona e interrupções de ponto único de falha.
Nesse tipo de ambiente de IP particular:
- Um componente do Cloud SQL do ambiente tem uma instância principal e uma instância de espera que são distribuídas entre as zonas.
- O ambiente executa dois programadores do Airflow, dois servidores da Web e, se os acionadores forem usados, um mínimo de dois (até dez no total) acionadores. Esses pares de componentes são executados em duas zonas separadas.
- O número mínimo de workers é definido como dois, e o cluster do ambiente distribui instâncias de worker entre as zonas. Em caso de interrupção zonal, as instâncias de worker afetadas são reagendadas em uma zona diferente.
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 por meio 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.