Cloud Composer の概要

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

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

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

環境

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

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

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

アーキテクチャ

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

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

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

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

Cloud SQL

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

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

App Engine

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

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

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

クラウド ストレージ

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

Google Kubernetes Engine

デフォルトで、Cloud Composer は、Airflow スケジューラ、ワーカーノード、CeleryExecutor などのコア コンポーネントを GKE にデプロイします。Cloud Composer は、スケールとセキュリティを強化するために、エイリアス IP を使用した VPC ネイティブ クラスタもサポートしています。

CeleryExecutor のメッセージ ブローカーである Redis は、StatefulSet アプリケーションとして実行されるため、メッセージはコンテナの再起動後も維持されます。

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

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

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

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

Cloud Logging と Cloud Monitoring

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

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

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

ネットワークとセキュリティ

デフォルトでは、Cloud Composer は、マシンとの通信にデフォルトの VPC ネットワークを使用するルートベースの GKE クラスタをデプロイします。セキュリティとネットワークの柔軟性を高めるため、Cloud Composer では次の機能もサポートされています。

共有 VPC

共有 VPC は、中央ホスト プロジェクトから共有ネットワーク リソースを管理できるようにし、プロジェクト間で一貫したネットワーク ポリシーを適用します。

Cloud Composer が共有 VPC に参加すると、Cloud Composer 環境がサービス プロジェクト内に配置され、他の Google Cloud プロジェクトでホストされているサービスを呼び出せるようになります。サービス プロジェクト内のリソースは、内部 IP アドレスを使用して、プロジェクトの境界を越えて安全な通信を行います。ネットワークとホスト プロジェクトの要件については、共有 VPC の構成をご覧ください。

VPC ネイティブ Cloud Composer 環境

VPC ネイティブでは、GKE クラスタの Pod と Service IP アドレスが Google Cloud ネットワーク内(VPC ネットワーク ピアリング経由も含む)でネイティブにルーティングできます。

この構成では、Cloud Composer は環境内のエイリアス IP アドレスを使用して VPC ネイティブ GKE クラスタをデプロイします。VPC ネイティブのクラスタを使用する場合、GKE は自動的にセカンダリ範囲を選択します。特定のネットワーキング要件では、Cloud Composer 環境の構成中に GKE Pod と GKE Service のセカンダリ範囲を構成することもできます。

プライベート IP Cloud Composer 環境

プライベート IP を使用すると、Cloud Composer ワークフローは公共のインターネットから完全に隔離されます。

この構成では、Cloud Composer は顧客プロジェクト内のエイリアス IP アドレスを使用して VPC ネイティブ GKE クラスタをデプロイします。環境内の GKE クラスタはプライベート クラスタとして構成され、Cloud SQL インスタンスはプライベート IP 用に構成されます。また、顧客プロジェクトの VPC ネットワークとテナント プロジェクトの VPC ネットワーク間のピアリング接続も作成されます。

重要な構成情報

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

次のステップ