Cloud Composer の概要

このページでは、Cloud Composer 環境と Apache Airflow のデプロイに使用される Google Cloud Platform プロダクトの概要について説明します。

Cloud Composer は、Airflow を基に構築された、フルマネージド ワークフロー オーケストレーション サービスです。Cloud Composer では、オンプレミスのデプロイの場合と同様、Airflow を実行するために複数のコンポーネントをデプロイします。このページでは、GCP コンポーネント、それらの機能、およびワークフローの実行方法について説明します。

また、オンプレミスのデプロイの場合と同様、Cloud Composer でワークフローを正常に実行するには特定の構成を利用する必要があります。Cloud Composer が利用している構成の接続や通信を変更した場合、意図しない結果が生じたり、Airflow のデプロイが中断されたりする可能性があります。このページでは、その重要な環境の構成について説明します。

環境

Airflow は、マイクロサービス アーキテクチャのフレームワークです。Cloud Composer では、Airflow を分散設定でデプロイするために、いくつかの GCP コンポーネントをプロビジョニングします。これらの GCP コンポーネントをまとめて Cloud Composer 環境と呼んでいます。

環境は Cloud Composer の中核的な概念です。プロジェクト内には 1 つ以上の Cloud Composer 環境を作成できます。環境は、Google Kubernetes Engine に基づく自己完結型の Airflow デプロイメントです。環境は、Airflow に組み込まれているコネクタを介して GCP サービスと連携します。

サポートされているリージョンに Cloud Composer 環境を作成し、その環境を Compute Engine ゾーン内で実行します。最もシンプルなユースケースでは、1 つのリージョンに 1 つの環境を作成できます。一方、複雑なユースケースでは、単一リージョンまたは複数リージョン内に複数の環境を作成できます。Airflow では、プロダクトの公開 API を介して他の GCP プロダクトと通信します。

アーキテクチャ

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

テナント プロジェクトと顧客プロジェクトの Cloud Composer 環境リソース(クリックで拡大)
Cloud Composer 環境のリソース(クリックで拡大)

テナント プロジェクトのリソース

Cloud Composer では、Cloud SQL と App Engine がテナント プロジェクトにデプロイされます。これにより、Cloud Identity and Access Management(Cloud IAM)のアクセス制御の統合とデータ セキュリティ強化ができます。

Cloud SQL

Cloud SQL は Airflow のメタデータを格納します。Cloud Composer はデータベース アクセスを、デフォルトまたは環境の作成に使用される、指定されたカスタム サービス アカウントに制限します。これは機密性の高い接続とワークフロー情報の保護のためです。また、Cloud Composer では Airflow のメタデータが毎日バックアップされます。これによりデータ損失の可能性が最小限に抑えられます。

Cloud Composer 環境を作成するために使用されるサービス アカウントは、Cloud SQL データベース内のデータにアクセスできる唯一のアカウントです。アプリケーション、クライアント、その他の GCP サービスから Cloud SQL データベースへのアクセスをリモートで承認するために、Cloud Composer では GKE クラスタに Cloud SQL プロキシが用意されています。

App Engine

App Engine フレキシブル環境は Airflow ウェブサーバーをホストします。デフォルトでは、Airflow ウェブサーバーは Cloud Identity-Aware Proxy と統合されています。Composer では、Cloud IAP 統合の詳細を意識することなく、Composer IAM ポリシーを使用してウェブサーバー アクセスを管理できます。composer.user 役割の割り当てや、環境内の他のリソースへのアクセス権を提供する、異なる Cloud Composer 役割の割り当てを行うことで、Airflow ウェブサーバーに対してのみアクセス権を付与できます。また、Cloud Composer では、組織に対する追加のアクセス制御要件のために、顧客プロジェクトでの自己管理型の Airflow ウェブサーバーのデプロイもサポートしています。

顧客プロジェクトのリソース

Cloud Composer では、顧客プロジェクトに Cloud Storage、Google Kubernetes Engine、Stackdriver がデプロイされます。

Cloud Storage

Cloud Storage では、DAGプラグイン、データ依存関係、ログのステージングためのストレージ バケットが用意されています。ワークフロー(DAG)をデプロイするには、環境のバケットにファイルをコピーします。Cloud Composer により、ワーカー、スケジューラ、ウェブサーバーの間で DAG の同期が行われます。Cloud Storage を使用すると、ワークフロー アーティファクトのサイズ制限を気にせず data/ フォルダと logs/ フォルダに格納したまま、データへの完全なアクセス制御を保持できます。

Google Kubernetes Engine

Cloud Composer は、Airflow スケジューラ、ワーカーノード、CeleryExecutor などのコア コンポーネントを GKE クラスタにデプロイします。CeleryExecutor のメッセージ ブローカーである Redis は、StatefulSet アプリケーションとして実行されるため、メッセージはコンテナの再起動後も維持されます。

GKE でスケジューラとワーカーを実行すると、KubernetesPodOperator を使用してコンテナ ワークロードを実行できます。Cloud Composer では、デフォルトで自動アップグレード自動修復が有効であるため、GKE クラスタがセキュリティの脆弱性から保護されます。自動アップグレード サイクルの前に Cloud Composer GKE クラスタをアップグレードする必要がある場合は、手動アップグレードを実行できます。

Airflow のワーカーノード、スケジューラ ノード、Airflow ウェブサーバーは、異なるサービス アカウントで実行されます。

  • スケジューラとワーカー: 環境作成中にサービス アカウントを指定しない場合、環境はデフォルトの Compute Engine サービス アカウントで実行されます。
  • ウェブサーバー: サービス アカウントは環境作成中に自動生成され、ウェブサーバー ドメインから取得されます。たとえば、ドメインが foo-tp.appspot.com である場合、サービス アカウントは foo-tp@appspot.gserviceaccount.com になります。

環境の詳細serviceAccountairflowUri の情報を確認できます。

Stackdriver

Cloud Composer は Stackdriver Logging や Stackdriver Monitoring と統合されているため、Airflow サービスとワークフローのログのすべてを一元的に表示できます。

Stackdriver Logging のストリーミングの性質上、Airflow ロギング モジュールの同期を待たずに、Airflow スケジューラとワーカーが出力するログを即座に表示できます。Cloud Composer の Stackdriver のログは google-fluentd に基づいているため、デベロッパーはスケジューラとワーカー コンテナが生成するすべてのログにアクセスできます。これらのログにより、デバッグが大幅に改善され、有用なシステムレベルと Airflow 依存関係の情報が得られます。

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

重要な構成情報

  • Airflow パラメータのいくつかは Cloud Composer 環境用に事前構成されます。これらの構成は変更することはできません。その他のパラメータは環境を作成するときに構成します。
  • Cloud Composer が Airflow のデプロイに使用するスタンドアロンの GCP プロダクトに適用される割り当てや制限は、使用する環境にも適用されます。
  • Cloud Composer では、ワークフローを正常に実行するために次の構成を利用します。
    • Cloud Composer サービス バックエンドは、サブスクリプションを使用することで Cloud Pub/Sub を介して GKE サービス エージェントと連携し、Cloud Pub/Sub のデフォルト動作を利用してメッセージを管理します。.*-composer-.* トピックを削除しないでください。Cloud Pub/Sub は、プロジェクトごとに最大 10,000 のトピックをサポートします。
    • Cloud Composer サービスは Stackdriver と連動してロギングを行います。GCP プロジェクト内のログ数を制限するには、すべてのログの取り込みを停止します。Stackdriver を無効にしないでください。
    • Cloud Composer サービス アカウントに関する Cloud Identity and Access Management ポリシー バインディングを変更しないでください(service-your-project-number@cloudcomposer-accounts.iam.gserviceaccount.com など)。
    • Airflow データベース スキーマを変更しないでください。
  • gcloud コマンドライン ツールにより Airflow CLI を実行できます。データベース オペレーションに影響を与えないようにするには、Airflow コマンド resetdbinitdbupgradedb を発行しないでください。
  • Airflow 安定版を実行している Cloud Composer リリースには、Airflow の将来のバージョンからバックポートされる Airflow アップデートを含めることができます。
  • ワーカーノードとスケジューラ ノードの容量はそれぞれ異なり、Airflow ウェブサーバーとは異なるサービス アカウントで実行されます。Airflow ウェブサーバーで DAG が失敗するのを回避するために、DAG の構文解析の際に、負荷の高い計算処理やウェブサーバーからアクセスできない GCP リソースへのアクセスを行わないでください。
  • 環境を削除しても、顧客プロジェクト内に存在する、環境用 Cloud Storage バケットと Stackdriver ログのデータは削除されません。GCP アカウントに変更が生じないようにするには、必要に応じてデータをエクスポート、削除してください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...