Cloud Composer 環境のアーキテクチャ

Cloud Composer 1 | Cloud Composer 2

このページでは、Cloud Composer 2 環境のアーキテクチャについて説明します。

環境アーキテクチャの構成

Cloud Composer 2 環境には、次のアーキテクチャ構成を設定できます。

構成ごとに環境リソースのアーキテクチャが若干変更されます。

顧客プロジェクトとテナント プロジェクト

環境を作成すると、Cloud Composer によってテナントのプロジェクトと顧客プロジェクトの間で環境のリソースが分配されます。

顧客プロジェクトは、環境を作成する Google Cloud プロジェクトです。1 つの顧客プロジェクトに複数の環境を作成できます。

テナント プロジェクトは、Google が管理するテナント プロジェクトです。テナント プロジェクトは、統一されたアクセス制御と、環境に対する追加のデータ セキュリティ レイヤを提供します。Cloud Composer 環境ごとに独自のテナント プロジェクトがあります。

環境コンポーネント

Cloud Composer 環境は環境コンポーネントで構成されます。

環境コンポーネントは、環境の一部として Google Cloud で実行されるマネージド Airflow インフラストラクチャの要素です。

環境コンポーネントは、環境のテナント プロジェクトまたは顧客プロジェクトで実行されます。

環境のコンポーネントの一部は、スタンドアロンの Google Cloud プロダクトをベースにしています。これらのプロダクトの割り当てと上限は使用中の環境にも適用されます。たとえば、Cloud Composer 環境では VPC ピアリングを使用します。VPC ピアリングの最大数の割り当ては顧客プロジェクトに適用されるため、プロジェクトがこのピアリングの最大数に達すると、追加の環境は作成できなくなります。

環境のクラスタ

環境のクラスタは、環境の Autopilot モード VPC ネイティブ Google Kubernetes Engine クラスタです。

  • 環境ノードは、環境のクラスタ内の VM です。

  • 環境のクラスタ内にある Pod は、Airflow ワーカーやスケジューラなど、他の環境コンポーネントを持つコンテナを実行します。Pod は環境ノードで実行されます。

  • 環境のクラスタのワークロード リソースは、環境のクラスタ内のポッドのセットを管理します。環境の多くのコンポーネントは、さまざまな種類のワークロード リソースとして実装されます。たとえば、Airflow ワーカーは Deployment として実行されます。Deployment に加えて、環境には StatefulSet、DaemonSets、Jobs のワークロード タイプもあります。

Cloud Composer では、デフォルトでノードの自動アップグレードノードの自動修復が有効になり、環境のクラスタはセキュリティの脆弱性から保護されます。これらのオペレーションは、環境に指定したメンテナンスの時間枠内に行われます。

Airflow スケジューラ、ワーカー、Redis キュー

Airflow スケジューラは、DAG の実行と DAG の個々のタスクのスケジューリングを制御します。スケジューラは、環境のクラスタでアプリケーションとして実行される Redis キューを使用して、Airflow ワーカーにタスクを分散します。Airflow スケジューラは、環境のクラスタで Deployment として実行されます。

Airflow ワーカーは DAG の個々のタスクを、Redis キューから取得して実行します。Airflow ワーカーは、環境のクラスタで Deployment として実行されます。

Redis キューは、DAG の個々のタスクのキューを保持します。Airflow スケジューラは、キューに入力します。Airflow ワーカーはキューからタスクを取得します。Redis キューは環境のクラスタ内で StatefulSet アプリケーションとして実行されるため、メッセージはコンテナの再起動後も保持されます。

Airflow ウェブサーバー

Airflow ウェブサーバーは環境の Aiflow UI を実行します。

Cloud Composer 2 では、Airflow ウェブサーバーは環境のクラスタ内で Deployment として実行されます。

Identity-Aware Proxy は Cloud Composer 2 でのアクセスには使用されません。

Airflow データベース

Airflow データベースは、環境のテナント プロジェクトで実行される Cloud SQL インスタンスです。Airflow のメタデータ データベースをホストします。

Cloud Composer では、機密性の高い接続とワークフロー情報を保護するため、ご使用の環境のサービス アカウントへのデータベース アクセスのみが許可されます。

環境のバケット

環境のバケットは、DAG、プラグイン、データ依存関係、Airflow ログを保存する Cloud Storage バケットです。環境のバケットは顧客プロジェクト内に存在します。

環境のバケット内の /dags フォルダに DAG ファイルをアップロードすると、Cloud Composer によって DAG が環境のワーカー、スケジューラ、ウェブサーバーに同期されます。ワークフロー アーティファクトのサイズ制限を気にせず data/ フォルダと logs/ フォルダに格納したまま、データへの完全なアクセス制御を保持できます。

その他の環境コンポーネント

Cloud Composer 環境には、いくつかの追加環境コンポーネントがあります。

  • Cloud SQL ストレージ。Airflow データベースのバックアップを保存します。また、Cloud Composer では Airflow のメタデータが毎日バックアップされます。これによりデータ損失の可能性が最小限に抑えられます。

    Cloud SQL Storage は、ご利用の環境のテナント プロジェクトで実行されます。Cloud SQL ストレージのコンテンツにはアクセスできません。

  • Cloud SQL Proxy環境の他のコンポーネントを Airflow データベースに接続します。

    環境には、環境のアーキテクチャに応じて異なる役割を果たす 1 つ以上の Cloud SQL Proxy インスタンスを設定できます。

    Cloud SQL Proxy は、環境のクラスタまたはテナント プロジェクトの App Engine フレキシブル環境インスタンスの Deployment として実行されます。

    Cloud SQL Proxy を環境のクラスタにデプロイした場合は、アプリケーション、クライアント、その他の Google Cloud サービスから Cloud SQL インスタンスへのアクセスも承認されます。

  • HAProxyテナント プロジェクトで実行される 2 つの Cloud SQL Proxy インスタンス間での Cloud SQL インスタンスへのトラフィックを負荷分散します。このコンポーネントは、プライベート IP 環境のアーキテクチャで使用され、Cloud SQL Proxy デプロイのコンテナとして実行されます。

  • Airflow モニタリング。環境指標を Cloud Monitoring に報告し、airflow_monitoring DAG をトリガーします。airflow_monitoring DAG は環境のヘルスデータを報告します。これは後で、環境のモニタリング ダッシュボードなどで使用されます。Airflow モニタリングは、環境のクラスタ内で Deployment として実行されます。

  • Composer エージェントは、環境の作成、更新、アップグレード、削除などの環境オペレーションを実行します。一般に、このコンポーネントは環境への変更を導入します。環境のクラスタで Job として実行されます。

  • Airflow InitDB は Cloud SQL インスタンスと初期データベース スキーマを作成します。Airflow InitDB は、環境のクラスタ内で Job として実行されます。

  • FluentD。すべての環境コンポーネントからログを収集し、収集したログを Cloud Logging にアップロードします。環境のクラスタで DaemonSet として実行されます。

  • Pub/Sub サブスクリプション。環境は、Pub/Sub のサブスクリプションを介して GKE サービス エージェントと通信します。メッセージの管理は Pub/Sub のデフォルト動作に依存します。.*-composer-.* Pub/Sub トピックを削除しないでください。Pub/Sub は、最大でプロジェクトごとに 10,000 のトピックをサポートします。

  • Customer Metrics Stackdriver Adapter は、自動スケーリングのために、環境の指標を報告します。このコンポーネントは、環境のクラスタ内で Deployment として実行されます。

  • Airflow ワーカーセット コントローラは、カスタマー指標の Stackdriver Adapter の指標に基づいて、環境を自動的にスケーリングします。このコンポーネントは、環境のクラスタ内で Deployment として実行されます。

  • Cloud Storage FUSE Airflow ワーカー、スケジューラ、ウェブサーバーで環境のバケットをファイル システムとしてマウントし、それらのコンポーネントがバケットからデータにアクセスできるようにします。環境のクラスタで DaemonSet として実行されます。

パブリック IP 環境のアーキテクチャ

テナント プロジェクトと顧客プロジェクトのパブリック IP Cloud Composer 環境リソース
図 1. プライベート IP 環境のアーキテクチャ(クリックして拡大)

Cloud Composer 2 のパブリック IP 環境アーキテクチャの場合:

  • テナント プロジェクトは、Cloud SQL インスタンスと Cloud SQL ストレージをホストします。
  • 環境のその他のすべてのコンポーネントは、お客様のプロジェクトによってホストされます。
  • 顧客プロジェクトの Airflow スケジューラとワーカーは、顧客プロジェクトにある Cloud SQL プロキシ インスタンスを介して Airflow データベースと通信します。

プライベート IP

テナント プロジェクトと顧客プロジェクトのプライベート IP Cloud Composer 環境リソース
図 2. プライベート IP 環境のアーキテクチャ(クリックして拡大)

Cloud Composer 2 のプライベート IP 環境アーキテクチャの場合:

  • テナント プロジェクトは、Cloud SQL インスタンスと Cloud SQL ストレージをホストします。
  • 環境のその他のすべてのコンポーネントは、お客様のプロジェクトによってホストされます。
  • Airflow スケジューラとワーカーは、環境のクラスタ内の HAProxy プロセスを介して Airflow データベースに接続します。
  • HAProxy プロセスは、テナント プロジェクトにある 2 つの Cloud SQL Proxy インスタンス間で Cloud SQL インスタンスへのトラフィックを負荷分散します。プライベート IP 環境では、ネットワークの制限により、顧客プロジェクトがデータベースに直接アクセスしないため、2 つの Cloud SQL Proxy インスタンスを使用します。環境のコンポーネントがデータベースに常にアクセスできるように、2 つのインスタンスが必要です。

Cloud Logging および Cloud Monitoring との統合

Cloud Composer は Google Cloud プロジェクトの Cloud Logging および Cloud Monitoring と統合されているため、Airflow サービスとワークフローのログを一元的に表示できます。

Cloud Monitoring が Cloud Composer から指標、イベント、メタデータを収集し取り込むことにより、ダッシュボードとグラフを介して分析情報を得ることができます。

Cloud Logging のストリーミングの性質上、Airflow ログが環境の Cloud Storage バケットに表示されるのを待つのではなく Airflow スケジューラとワーカーが出力するログを即座に表示できます。Cloud Composer の Cloud Logging ログは google-fluentd に基づいているため、Airflow スケジューラとワーカーによって生成されるすべてのログにアクセスできます。

Google Cloud プロジェクト内のログ数を制限するために、すべてのログの取り込みを停止できます。Logging を無効にしないでください。

次のステップ