Esta página foi traduzida pela API Cloud Translation.
Switch to English

Arquitetura de ambiente do Cloud Composer

Quando você cria um ambiente, o Cloud Composer distribui os recursos dele entre um projeto de locatário gerenciado pelo Google e um de cliente.

Configurações do ambiente

Os ambientes do Cloud Composer podem ser criados em três configurações: IP público, IP privado e IP privado com compartilhamento restrito de domínio (DRS). Cada configuração altera um pouco a arquitetura dos recursos do projeto.

IP público

Em uma configuração de IP público, os recursos do ambiente são distribuídos entre os projetos do cliente e de locatário. O projeto de locatário hospeda uma instância do Cloud SQL para executar o banco de dados do Airflow e uma VM flexível do Google App Engine para executar o servidor da Web do Airflow.

O programador, os workers e o servidor da Web do Airflow se conectam ao banco de dados do Airflow usando processos de proxy do Cloud SQL, conforme mostrado na figura abaixo:

Recursos de ambiente de IP público do Cloud Composer no projeto de locatário e de cliente (clique para ampliar)
Arquitetura de IP público do Cloud Composer (clique para ampliar)

IP privado

Em uma configuração de IP particular, os recursos do Cloud Composer são distribuídos entre os projetos do cliente e de locatário. O projeto de locatário hospeda uma instância do Cloud SQL para executar o banco de dados do Airflow e uma VM flexível do Google App Engine para executar os processos do servidor da Web do Airflow e do Cloud SQL Proxy.

O programador e os workers do Airflow se conectam aos processos de proxy do Cloud SQL em execução no projeto de locatário usando um processo HAProxy em execução no cluster do GKE. O carregamento do processo HAProxy equilibra o tráfego para a instância do Cloud SQL entre duas instâncias do Cloud SQL Proxy em execução no projeto de locatário, conforme mostrado na figura abaixo:

Recursos de ambiente de IP particular do Cloud Composer no projeto de locatário e de cliente (clique para ampliar)
Arquitetura de IP particular do Cloud Composer (clique para ampliar)

IP particular com compartilhamento restrito de domínios

Se a política organizacional de compartilhamento restrito de domínios estiver ativada, o Cloud Composer criará um bucket adicional no projeto de locatário que o servidor da Web pode acessar diretamente. Um processo adicional também é executado no cluster do GKE do Cloud Composer, para sincronizar dados do bucket do Cloud Storage localizado no projeto do cliente com o bucket do Cloud Storage localizado no projeto do locatário.

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

Recursos do projeto de locatário

Para garantir o controle de acesso unificado do Identity and Access Management e uma camada extra de segurança de dados, o Cloud Composer implanta o Cloud SQL e o App Engine no projeto de locatário.

Cloud SQL

O Cloud SQL armazena os metadados do Airflow. O Cloud Composer limita o acesso de banco de dados à conta de serviço padrão ou à conta de serviço personalizada especificada que você usou para criar o ambiente. Isso protege informações confidenciais de conexão e fluxo de trabalho. O Cloud Composer faz o backup dos metadados do Airflow diariamente para reduzir as possíveis perdas de dados.

A conta de serviço usada para criar o ambiente do Cloud Composer é a única que pode acessar os dados no banco de dados do Cloud SQL. Para autorizar remotamente o acesso ao banco de dados do Cloud SQL a partir de um aplicativo, cliente ou outro serviço do Google Cloud, o Cloud Composer fornece o proxy Cloud SQL no cluster do GKE.

App Engine

O ambiente flexível do App Engine hospeda o servidor da Web do Airflow. Por padrão, o servidor da Web Airflow é integrado ao Identity-Aware Proxy. O Cloud Composer oculta os detalhes de integração de IAP e permite que você use a política de IAM do Cloud Composer para gerenciar o acesso ao servidor da Web. Para conceder acesso somente ao servidor da Web do Airflow, atribua o papel "composer.user" ou outros papéis do Cloud Composer que forneçam acesso a diferentes recursos no ambiente. Para as organizações com requisitos extras de controle de acesso, o Cloud Composer também aceita a implantação de um servidor da Web gerenciado automaticamente do Airflow no projeto de cliente.

Recursos do projeto de cliente

O Cloud Composer implanta o Cloud Storage, o Google Kubernetes Engine, o Cloud Logging e o Cloud Monitoring no projeto do cliente.

Cloud Storage

O Cloud Storage fornece o bucket de armazenamento para organizar DAGs, plug-ins, dependências de dados e registros. Para implantar fluxos de trabalho (DAGs), você copia os arquivos para o bucket do ambiente. O Cloud Composer cuida da sincronização dos DAGs entre os workers, os programadores e o servidor da Web. Com o Cloud Storage, é possível armazenar os artefatos de fluxo de trabalho nas pastas data/ e logs/ sem se preocupar com limitações de tamanho e manter o controle de acesso total aos dados.

Google Kubernetes Engine

Por padrão, o Cloud Composer implanta componentes básicos no GKE. Eles incluem o programador do Airflow, os nós de worker e o CeleryExecutor. Para maior escalonamento e segurança, o Cloud Composer também oferece suporte a clusters nativos de VPC usando IPs de alias.

O Redis é o agente de mensagens do CeleryExecutor. Ele é executado como um aplicativo StatefulSet para que as mensagens sejam mantidas nas reinicializações do contêiner.

Ao executar o programador e os workers no GKE, é possível usar o KubernetesPodOperator para executar qualquer carga de trabalho do contêiner. Por padrão, o Cloud Composer possibilita o upgrade e o reparo automáticos para proteger os clusters do GKE contra vulnerabilidades de segurança.

Além do servidor da Web do Airflow, os nós do programador e do worker do Airflow são executados em diferentes contas de serviço.

  • Programador e workers: se você não especificar uma conta de serviço durante a criação do ambiente, ele será executado na conta de serviço padrão do Compute Engine.
  • Servidor da Web: a conta de serviço é gerada automaticamente durante a criação do ambiente e derivada do domínio do servidor da Web. Por exemplo, se o domínio for foo-tp.appspot.com, a conta de serviço será foo-tp@appspot.gserviceaccount.com.

É´possível ver as informações de serviceAccount e airflowUri nos detalhes do ambiente.

Cloud Logging e Cloud Monitoring

O Cloud Composer integra-se ao Cloud Logging e ao Cloud Monitoring para que você tenha um local central para visualizar todos os serviços do Airflow e registros do fluxo de trabalho.

Devido à natureza de streaming do Cloud Logging, é possível visualizar os registros que o programador do Airflow e os workers emitem imediatamente em vez de esperar pela sincronização do módulo de registro do Airflow. Como os registros do Cloud Logging do Cloud Composer são baseados no google-fluentd, você tem acesso a todos os registros que o programador e os contêineres de worker produzem. Eles ajudam bastante na depuração e contêm informações úteis sobre a dependência do Airflow e o nível do sistema.

O Cloud Monitoring coleta e ingere métricas, eventos e metadados do Cloud Composer para gerar insights através de painéis e gráficos.

Informações de configuração do Airflow

Alguns parâmetros do Airflow são pré-configurados para os ambientes do Cloud Composer, de modo que não é possível alterá-los. Você configura outros parâmetros ao criar o ambiente.

O Cloud Composer depende das configurações a seguir para executar fluxos de trabalho:

  • O back-end de serviço do Cloud Composer coordena com o agente de serviço do GKE pelo Pub/Sub usando assinaturas e conta com o comportamento padrão de Pub/Sub para gerenciar mensagens. Não exclua tópicos .*-composer-.*. O Pub/Sub é compatível com no máximo 10.000 tópicos por projeto.
  • O serviço Cloud Composer coordena a geração de registros com o Cloud Logging. Para limitar o número de registros no projeto do Google Cloud, pare a ingestão de todos os registros. Não desative o Logging.
  • Não modifique a vinculação de política do Identity and Access Management da conta de serviço do Cloud Composer, por exemplo, service-your-project-number@cloudcomposer-accounts.iam.gserviceaccount.com.
  • Não altere o esquema do banco de dados do Airflow.

Observações importantes

  • Todas as cotas ou limites que se aplicam aos produtos independentes do Google Cloud que o Cloud Composer usa para a implantação do Airflow também se aplicam ao seu ambiente.
  • Uma versão do Cloud Composer executando uma versão estável do Airflow pode incluir atualizações do Airflow que são feitas a partir de uma versão posterior do Airflow.
  • Os nós do worker e do programador têm capacidades diferentes e são executados em uma conta de serviço distinta do servidor da Web do Airflow. Para evitar falhas de DAG no servidor da Web do Airflow, não faça cálculos pesados nem acesse recursos do Google Cloud aos quais o servidor da Web não tem acesso no momento da análise do DAG.
  • A exclusão do ambiente não exclui os seguintes dados no projeto do cliente: o bucket do Cloud Storage para seu ambiente, registros do Logging e o disco permanente usado pela Redis Queue em execução no cluster do GKE. Para evitar cobranças na sua conta do Google Cloud, exporte e exclua dados, conforme necessário.