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

Cloud Composer 1 | Cloud Composer 2

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

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

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

構成ごとに環境リソースのアーキテクチャは若干異なります。

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

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

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

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

環境コンポーネント

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

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

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

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

環境のクラスタ

環境のクラスタは、標準モードの 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 ワーカーは、環境のクラスタで Deployment として動作します。

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

Airflow ウェブサーバー

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

Cloud Composer 1 において、Airflow ウェブサーバーは、環境のテナント プロジェクトで実行される App Engine Flex インスタンスです。

Airflow ウェブサーバーは Identity-Aware Proxy と統合されます。Cloud Composer は IAP 統合の詳細を隠し、ユーザーのために定義されたユーザー ID と IAM ポリシー バインディングに基づいてウェブサーバーへのアクセスを提供します。

Airflow ウェブサーバーは、Airflow ワーカーや Airflow スケジューラとは異なるサービス アカウントで動作します。ウェブサーバーのサービス アカウントは、環境作成時に自動生成され、ウェブサーバー ドメインから派生します。たとえば、ドメインが example.appspot.com の場合、サービス アカウントは example@appspot.gserviceaccount.com になります。

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 インスタンスへのアクセスも承認されます。

  • HAProxy。Cloud SQL インスタンスへのトラフィックを、テナント プロジェクトで実行される 2 つの Cloud SQL Proxy インスタンスに負荷分散します。Cloud Composer 1 の場合、このコンポーネントはプライベート 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 のトピックをサポートします。

  • バケットの同期このプロセスでは、顧客プロジェクトとテナント プロジェクトの環境バケットが同期されます。このコンポーネントは、DRS 環境アーキテクチャのプライベート IP で使用されます。このコンポーネントは、環境バケットを使用する他のコンポーネントのポッドでコンテナとして実行されます。

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

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

    Cloud Composer 1 のパブリック IP 環境アーキテクチャでは、各リソースが次のように機能します。

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

    プライベート IP 環境のアーキテクチャ

    テナント プロジェクトと顧客プロジェクトのプライベート IP Cloud Composer 環境のリソース
    図 2. プライベート 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 環境リソースを使用したプライベート IP（クリックして拡大）
    図 3. プライベート 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 サービスとワークフローのログを一元的に表示できます。

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

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

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

    次のステップ