Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3
このページでは、Cloud Composer 環境のアーキテクチャについて説明します。
環境アーキテクチャの構成
Cloud Composer 1 環境には、次のアーキテクチャ構成を設定できます。
顧客プロジェクトとテナント プロジェクト
環境を作成すると、Cloud Composer によってテナントのプロジェクトと顧客プロジェクトの間で環境のリソースが分配されます。
- 顧客プロジェクトは、環境を作成する Google Cloud プロジェクトです。1 つの顧客プロジェクトに複数の環境を作成できます。
テナント プロジェクトは、Google が管理するテナント プロジェクトです。 テナント プロジェクトでは、統合されたアクセス制御と環境のデータ セキュリティの追加レイヤが提供されます。各 Cloud Composer 環境には独自のテナント プロジェクトがあります。
環境コンポーネント
Cloud Composer 環境は、環境コンポーネントから構成されます。
環境コンポーネントは、環境の一部として Google Cloud で実行されるマネージド Airflow インフラストラクチャの要素です。 環境コンポーネントは、環境のテナント プロジェクトまたは顧客プロジェクトで実行されます。
環境のクラスタ
環境のクラスタは、標準モードの VPC ネイティブまたはルートベースの Google Kubernetes Engine クラスタです。
Cloud Composer では、デフォルトでノードの自動アップグレードとノードの自動修復が有効になり、セキュリティ上の脆弱性から環境のクラスタが保護されます。これらのオペレーションは、環境に指定したメンテナンスの時間枠に行われます。
環境のバケット
環境のバケットは、DAG、プラグイン、データ依存関係、Airflow ログを保存する Cloud Storage バケットです。環境のバケットは顧客プロジェクトに配置されています。
環境のバケット内の /dags フォルダに DAG ファイルをアップロードすると、DAG は、Cloud Composer によって環境の Airflow コンポーネントと同期されます。
Airflow ウェブサーバー
Airflow ウェブサーバーは環境の Aiflow UI を実行します。
Cloud Composer 1 では、Airflow ウェブサーバーは環境のテナント プロジェクトで実行されます。
Airflow ウェブサーバーは Identity-Aware Proxy と統合されています。Cloud Composer は IAP 統合の詳細を隠し、ユーザーのために定義されたユーザー ID と IAM ポリシー バインディングに基づいてウェブサーバーへのアクセスを提供します。
Cloud Composer 1 では、Airflow ウェブサーバーは Airflow ワーカーや Airflow スケジューラとは異なるサービス アカウントで動作します。ウェブサーバーのサービス アカウントは、環境作成時に自動生成され、ウェブサーバー ドメインから派生します。たとえば、ドメインが example.appspot.com の場合、サービス アカウントは example@appspot.gserviceaccount.com になります。
Airflow データベース
Airflow データベースは、環境のテナント プロジェクトで実行される Cloud SQL インスタンスです。Airflow メタデータ データベースをホストします。
Cloud Composer では、機密性の高い接続とワークフロー情報を保護するため、ご使用の環境のサービス アカウントへのデータベース アクセスのみが許可されます。
その他の Airflow コンポーネント
環境で実行されるその他の Airflow コンポーネントは次のとおりです。
Airflow スケジューラは、DAG 定義ファイルを解析し、スケジュール間隔に基づいて DAG の実行をスケジュールして、Airflow ワーカーが実行するタスクをキューに入れます。Cloud Composer 1 では、Airflow DAG プロセッサはスケジューラ コンポーネントの一部として実行されます。
Airflow ワーカーは、Airflow スケジューラによってスケジュールされたタスクを実行します。
パブリック IP 環境のアーキテクチャ
Cloud Composer 1 のパブリック IP 環境アーキテクチャでは、各リソースが次のように機能します。
- テナント プロジェクトは、Cloud SQL インスタンス、Cloud SQL ストレージ、Airflow ウェブサーバーを実行する App Engine フレキシブルインスタンスをホストします。
- 環境のその他のすべてのコンポーネントは、お客様のプロジェクトによってホストされます。
- 顧客プロジェクトの Airflow スケジューラとワーカーは、顧客プロジェクトにある Cloud SQL プロキシ インスタンスを介して Airflow データベースと通信します。
- テナント プロジェクトの Airflow ウェブサーバーは、テナント プロジェクトに配置された Cloud SQL プロキシ インスタンスを介して Airflow データベースと通信します。
プライベート IP 環境のアーキテクチャ
プライベート IP 環境のアーキテクチャでは、各リソースが次のように機能します。
- テナント プロジェクトは、Cloud SQL インスタンス、Cloud SQL ストレージ、Airflow ウェブサーバーを実行する 2 つの App Engine インスタンスをホストします。
- 環境のその他のすべてのコンポーネントは、お客様のプロジェクトによってホストされます。
- Airflow スケジューラとワーカーは、環境のクラスタ内の HAProxy プロセスを介して Airflow データベースに接続します。
- HAProxy プロセスは、テナント プロジェクトにある 2 つの Cloud SQL Proxy インスタンス間で Cloud SQL インスタンスへのトラフィックをロード バランシングします。プライベート IP 環境では、ネットワークの制約により顧客プロジェクトはデータベースに直接アクセスしないため、2 つの Cloud SQL Proxy インスタンスを使用します。環境のコンポーネントが常にデータベースにアクセスできるようにするには、2 つのインスタンスが必要です。
DRS を使用したプライベート IP
プロジェクトでドメインで制限された共有（DRS）組織のポリシーが有効になっている場合、Cloud Composer は DRS 環境アーキテクチャでプライベート IP を使用します。
DRS 環境を使用するプライベート IP のアーキテクチャでは、各リソースが次のように機能します。
テナント プロジェクトは、Cloud SQL インスタンス、Cloud SQL ストレージ、Airflow ウェブサーバーを実行する 2 つの App Engine インスタンスをホストします。
テナント プロジェクトは、追加の環境のバケットをホストします。Airflow ウェブサーバーは、このバケットに直接アクセスします。
環境のその他のすべてのコンポーネントは、お客様のプロジェクトによってホストされます。
顧客プロジェクトは、環境のクラスタで バケットの同期プロセスをホストします。このプロセスでは、2 つの環境バケットが同期されます。
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 と DAG のログを一元的に表示できます。
Cloud Monitoring が Cloud Composer から指標、イベント、メタデータを収集し取り込むことにより、ダッシュボードとグラフを介して分析情報を得ることができます。
Cloud Logging のストリーミングの性質上、環境の Cloud Storage バケットに Airflow ログが表示されるのを待たずに、Airflow コンポーネントが出力するログを即座に表示できます。
Google Cloud プロジェクト内のログ数を制限するために、すべてのログの取り込みを停止できます。Logging を無効にしないでください。