Cloud Composer のテナント戦略を評価する
Google Cloud Japan Team
※この投稿は米国時間 2023 年 10 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。
はじめに
お客様は、単一の組織内に多数のデータ分析チームを擁し、それぞれがワークフローやデータ パイプラインのオーケストレーションを必要とする場合があります。組織の効率性、スケーラビリティ、セキュリティを向上させるには、実装のテナント設計を評価することが重要です。
Google Cloud が提供しているフルマネージド ワークフロー オーケストレーション サービスの Cloud Composer は Apache Airflow 上に構築されており、BigQuery、Dataflow、Dataproc、Datastore、Cloud Storage、Pub/Sub、Vertex AI などの Google Cloud プロダクトとのエンドツーエンドのインテグレーションを実現します。
このガイドでは、Cloud Composer のさまざまなテナント戦略の長所と短所を比較し、マルチテナント Composer 戦略と単一テナント Composer 戦略の違いを評価します。つまり、すべてのデータチームが単一の Composer 環境を共有する場合と、データチームごとに個別の Composer 環境を使用する場合を比較します。
注: このドキュメントでは、単一の大規模な Composer 環境と多数の小規模な Composer 環境の DAG あたりの費用を比較する際、Composer 環境の推奨プリセット（大、中、小）と Composer 2 の料金モデルを使用しています。
マルチテナント Composer 環境の場合
マルチテナントの長所
+ ガバナンスの一元化
単一の環境に対する構成の変更、権限に関する問題、ロールベース アクセス制御の割り当てを、1 つの Google Cloud プロジェクト内で管理できます。複数のデータチームにおけるこれらのリクエストは、中央のプラットフォーム チームが管理します。
+ DAG あたりの最良の費用
2 つ以上の中規模環境プリセットや 3 つ以上の小規模環境プリセットの代わりに、1 つの大規模環境プリセットを使用するほうが、DAG 単位での費用対効果が高くなる場合があります。
+ 統合 CI / CD
単一の CI / CD パイプラインにより、複数のデータチームに対してテスト、検証、DAG のデプロイが行われます。
マルチテナントの短所
- 不十分な分離
すべての DAG に対して単一のデフォルト サービス アカウントを使用するということは、チームとその認証が単一の大きな認証スコープに統合されるということです。そのため、あるチームが別のチームのデータにアクセスする DAG を記述できるという制限がプロダクトに生じます。
- 単一障害点
このアーキテクチャ設計では、エラーや障害が生じる潜在的なリスクが大きくなります。また、ノイジー ネイバー（リソースを独占する共同テナント）に関連する信頼性も限定的なものとなり、データレイク全体で単一障害点が生じることが懸念されます。次のような方法で、潜在的なリスクを軽減します。
- DAG 数 / 最大同時実行 DAG 数 / 最大同時実行タスク数の合計を、推奨される制限内に収める
- HA のベスト プラクティスに沿って対応する（2 つのスケジューラ、自動スケーリング）
- 堅牢なスナップショット障害復旧戦略を策定する
- 構成 / 権限変更の SLA をユーザーに認識させる
- メンテナンスの時間枠を設定し、認識させる
- DAG を本番環境にデプロイする前に、下位環境で徹底的にテスト / 検証を行う
- 限定的なスケーラビリティ
Google Cloud のベスト プラクティスでは、大規模な Composer 環境のプリセットを、合計 DAG 数 1,000、最大同時実行 DAG 数 250、最大同時実行タスク数 400 に設定することを推奨しています。多くのデータレイクで単一の共有環境を使用している場合、これらのソフトリミットに達する可能性はさらに高くなります。
ただし、次のようなさまざまな方法で環境のスケーラビリティを最大化できます。
- Airflow コンポーネントごとに、マシンタイプが最大の大規模環境プリセットを使用する
- 定期的なデータベースのメンテナンスのために、Airflow データベース クリーンアップ DAG を活用する
- Airflow DAG の改良を通じて Cloud Composer を最適化する
- Cloud Composer のメリットを最大限に活用し、解析時間を短縮する
- スナップショットとアップグレードへの影響
単一の Composer 環境では、Airflow メタデータ データベースが大きくなるにつれて、より多くの問題が発生します。データベースのサイズはアップグレードに影響します。データベースのサイズが 16 GB を超えると環境をアップグレードできなくなり、20 GB を超えるとスナップショットを作成できなくなります。
定期的なデータベースのメンテナンスには、Airflow データベース クリーンアップ DAG を利用してください。
- 最終的には論理グループが必要
単一の共有環境が上述のソフトリミットに達した場合、スケールするために追加の Composer 環境を導入する必要があります。方法のひとつは、shared-environment-1、shared-environment-2、shared-environment-3 を作ることです。ただし、これは任意の方法であり、環境間の論理的な依存関係は表されません。複数の DAG にまたがる開発には、論理グループの使用が有効です。これはマルチテナント アプローチの出発点でもあります。
- 逃した収益
特定の障害が発生した場合、Composer 環境全体 / データ オーケストレーション ソリューションが機能しなくなる可能性があります。このような状況が生じると、大規模な Composer 環境のプリセットを使用していた場合、中規模または小規模な Composer 環境と比較して、逃した収益が費用面のメリットをはるかに上回ります。
- 開発の遅れ
構成や権限のリクエストには、中央チームによる承認が必要です。各データレイクの応答時間の SLA を作成し、開発の障害や中断を最小限に抑える必要があります。
専用の単一テナント Composer 環境の場合
単一テナントの長所
+ 分離された障害点
あるデータレイクで構成やパフォーマンスに障害が発生しても、別のデータレイクの DAG に直接影響することはありません。
+ 分離されたセキュリティ
明示的に共同作業し、クロス環境の依存関係を構築していない限り、開発者は他のチームの DAG やデータにアクセスできません。
+ 開発者の生産性の向上
迅速なデプロイ、構成の変更、権限の割り当てにより、QOL が向上します（リクエストは中央チームを経由する必要がなくなり、データレイクのオーナーが責任を負うようになることを前提とします）。
+ データレイク間の論理的な関係
データレイク間で DAG を横断する依存関係の処理が、論理的にわかりやすくなります。プロジェクト 1 の特定のプロセスがプロジェクト 2 を必要とすることがわかっている場合、プロジェクト 2 の Composer 環境で直接作業できます。
+ 組織固有の Airflow DAG のパフォーマンス向上
組織のワークロードに合わせてカスタマイズした Airflow 構成では、一般的な構成の共有環境よりもパフォーマンスが向上します。
+ スケーリング対策の必要性が少ない
近い将来に単一のデータチームで 1,000 DAG の制限を超えることはないため、環境のスケーリングも必要ありません。大規模または中規模環境のプリセットを一度デプロイすれば十分です。Airflow メタデータ データベースのサイズへの影響も小さいため、スナップショットやアップグレードも自由に実施できます。
+ ロギング / モニタリングの整理と簡素化
単一のデータチームで、開発者が診断を行う必要があるたびに Cloud Logging や Airflow UI をフィルタする必要がなくなります。
+ 費用追跡の簡素化
データチームの Composer 関連費用が単一の環境に限定されます。
+ メンテナンス作業の影響範囲の限定
さまざまなチームがそれぞれの開発ニーズに合わせて、メンテナンス、スナップショット、環境アップグレードのスケジュールを設定できます。
単一テナントの短所
- データレイク間の依存関係
密結合した複数のデータレイク プロセスがある場合、DAG 間の依存関係を維持するために追加の開発とインフラストラクチャが必要となります。これは、Pub/Sub と Airflow センサーを使用して実現できます。代わりに、Cloud Run を使用して Pub/Sub メッセージをインターセプトし、コンテンツを読み取り、トリガーする Composer 環境と DAG を決定することもできます。
- DAG あたりの費用
特定のデータレイクの運用に中規模または小規模の環境プリセットしか必要としない場合、共有の大規模環境プリセットを使用する場合よりも DAG あたりの支払い額は多くなります（それでも全体としては少なくなります）。
- 複数の Composer 環境の管理
たとえば、複数のデータレイク間で 10,000 DAG を実行する場合、共有環境アプローチでは大規模 Composer 環境が 10 個必要になります。一方、専用環境アプローチでは、要件の異なる複数のデータレイクを管理する必要があります。プロジェクト間の環境のモニタリングをチェックして、これらのタスクを簡素化してください。
まとめ
マルチテナント Composer 環境は、Composer を使い始めたばかりの小規模な組織や、少数のデータレイクとシンプルなワークフローを使用している組織に適したオプションです。このアプローチでは、複数の Composer 環境を作成して管理するよりも費用対効果が高く、ガバナンスと管理を一元化することもできます。
大規模で成熟しているお客様や急速に成長しているお客様には、チームごとに専用の単一テナント Composer 環境を用意するほうが適しています。この戦略では、セキュリティ、スケーラビリティ、可用性、開発者の生産性を優先しています。
Airflow のマルチテナントに関する最新の議論については、Airflow Summit 2023 の「Multi-tenancy State of the Union」をご覧ください。
-戦略的クラウド エンジニア Christian Yarros
