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、Job ワークロード タイプもあります。

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

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

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

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

Airflow トリガーは、環境内のすべての遅延タスクを非同期でモニタリングします。triggerer のインスタンス数は、Cloud Composer 環境を作成または更新するときに構成できます。Cloud Composer は、次の triggerer 構成をサポートしています。

  • triggerer 数:

    • 標準的な復元力: 最大 10 個の triggerer を実行できます。
    • 高い復元力: 2 個以上、最大 10 個の triggerer

    triggerer の数はゼロに設定できますが、DAG で遅延可能な演算子を使用するには、環境内に少なくとも 1 つ（または復元性の高い環境では少なくとも 2 つ）の triggerer インスタンスが必要です。triggerer の数が 0 に設定されている場合でも、環境のクラスタは引き続き Pod なしでワークロードを実行します。この場合、料金はかかりません。

  • triggerer のリソース割り当て:

    • triggerer あたりの最大 1 vCPU
    • 最大メモリは、triggerer CPU の数に 6.5 を掛けた数と同じ

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

Airflow ウェブサーバー

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

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

Cloud Composer 2 では、ユーザー ID と、ユーザー用に定義された IAM ポリシー バインディングに基づいて、インターフェースにアクセスできます。Cloud Composer 1 と比較した場合、Cloud Composer 2 では Identity-Aware Proxy に依存しない別のメカニズムが使用されます。

Airflow データベース

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

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

環境のバケット

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

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

他の環境コンポーネント

Cloud Composer 環境には、複数の追加環境コンポーネントがあります。

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

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

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

    パブリック IP 環境には、Airflow データベースに送信されるトラフィック量に応じて、1 つ以上の Cloud SQL Proxy インスタンスを設定できます。

    パブリック IP 環境の場合、Cloud SQL Proxy は環境のクラスタで Deployment として実行されます。

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

  • 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 のトピックをサポートします。

  • PSC エンドポイントは、Airflow スケジューラとワーカーを、PSC でプライベート IP アーキテクチャの Airflow データベースに接続します。

  • 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 環境のアーキテクチャ

テナント プロジェクトと顧客プロジェクトの PSC Cloud Composer 環境リソースを使用したプライベート IP（クリックして拡大）
図 2. テナント プロジェクト内と顧客プロジェクト内のプライベート IP Cloud Composer 環境リソース（クリックして拡大）

デフォルトでは、Cloud Composer 2 は Private Service Connect を使用するため、プライベート IP 環境は VPC ピアリングを使用せずに内部通信を行います。ご使用の環境で Private Service Connect の代わりに VPC ピアリングを使用することもできます。これはデフォルト以外のオプションです。

プライベート IP 環境のアーキテクチャでは、各リソースが次のように機能します。

  • Cloud SQL インスタンスと Cloud SQL ストレージは、テナント プロジェクトによってホストされます。
  • 環境のその他のすべてのコンポーネントは、お客様のプロジェクトによってホストされます。
  • Airflow スケジューラとワーカーは、構成された PSC エンドポイントを介して Airflow データベースに接続します。

復元性に優れたプライベート IP アーキテクチャ

テナント プロジェクト内と顧客プロジェクト内の復元性に優れたプライベート IP 環境リソース（クリックして拡大）
図 3. テナント プロジェクト内と顧客プロジェクト内の復元性に優れたプライベート IP Cloud Composer 環境リソース（クリックして拡大）

復元力に優れた Cloud Composer 環境は、組み込みの冗長性とフェイルオーバー メカニズムを使用する Cloud Composer 2 環境で、ゾーン障害や単一障害点サービスに対する環境の影響を軽減します。

プライベート IP 環境の場合:

  • 環境の Cloud SQL インスタンスは高可用性向けに構成されています（リージョン インスタンス）。リージョン インスタンスはプライマリ インスタンスとスタンバイ インスタンスで構成されます。
  • 環境で 2 つの Airflow スケジューラ、2 つのウェブサーバーを実行し、triggerer が使用されている場合は、最小 2 個（最大で合計 10 個）の triggerer になります。これらのコンポーネントのペアは、2 つのゾーンで実行されます。
  • ワーカーの最小数は 2 に設定されており、環境のクラスタはゾーン間でワーカー インスタンスを分散します。ゾーンが停止した場合、影響を受けるワーカー インスタンスは別のゾーンで再スケジュールされます。

Cloud Logging および Cloud Monitoring との統合

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

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

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

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

次のステップ