インフラストラクチャ リソースを App Hub アプリケーションに効果的に整理するには、アプリケーション管理のセットアップ モデルを選択する必要があります。App Hub では、次のモデルが提供されています。
- アプリ管理用フォルダ（プレビュー）: 新しいアプリ グループ化の実装におすすめのモデル。アプリケーション管理用の標準の Google Cloud フォルダを構成し、アプリケーション中心の Google Cloud で利用可能なすべての機能を有効にします。
- ホスト プロジェクト: 既存の App Hub ユーザー向けのサポートされているモデル。標準の Google Cloud プロジェクトを構成してリソースをグループ化します。
次の表は、利用可能なアプリケーション管理設定モデルを比較したものです。主な違いをまとめて確認し、ニーズに最適なオプションを選択するのに役立ちます。
| 機能 | アプリ対応フォルダ | ホスト プロジェクト |
|---|---|---|
| 推奨事項 | 新規ユーザーにおすすめ | 既存ユーザー向けのサポート対象モデル |
| プライマリ境界 | アプリ対応フォルダとそのすべてのサブエントリ | ホスト プロジェクトと手動で接続されたサービス プロジェクト |
| リソース検出 | フォルダとその子孫内で自動的に実行 | サービス プロジェクトの手動接続が必要 |
| 管理プロジェクト | Google によって自動的に作成された | 該当なし |
| 主な機能 | Cloud Hub と Google Cloud Observability プロダクトのモニタリングの強化、App Design Center でのアプリケーションの設計とデプロイ、Gemini Cloud Assist を使用したアプリケーションの最適化など、アプリケーション中心の Google Cloud 機能へのフルアクセス | 基本的なアプリケーション グループ化。App Hub、Cloud Logging、Cloud Monitoring、Cloud Trace でのオブザーバビリティ データの表示は限定的にサポート |
| IAM 戦略 | フォルダ、管理プロジェクト、個々のアプリケーション レベルでの詳細な権限制御 | プロジェクト レベルの権限制御 |
| API の有効化 | 管理プロジェクトで自動 | ホスト プロジェクトでの手動 |
| スケーラビリティ | 組織規模に対応した設計 | プロジェクト リソースによる制限 |
| 設定の難易度 | フォルダ構造の事前計画 | 手動リンクによる直接初期設定 |
| 設定手順 | アプリ管理用フォルダを使用して App Hub を設定する | ホスト プロジェクトを使用して App Hub を設定する |
このページでは、アプリケーション管理のニーズに最適なモデルを選択するためのガイドとして、モデルのメリット、考慮事項、機能の違いについて詳しく説明します。
アプリ対応フォルダ
推奨アプリ対応フォルダは、アプリケーション管理用に構成する標準の Google Cloud フォルダです。このモデルは、アプリケーションの管理境界として機能し、アプリケーション中心の Google Cloud でのアプリケーション管理エクスペリエンスの基盤となります。
フォルダでアプリケーション管理を有効にすると、そのフォルダ内に管理プロジェクトが自動的に作成されます。 Google Cloud この管理プロジェクトには、App Hub や Application Design Center などのサービスのすべてのアプリケーション モデル、メタデータ、構成が保存されます。また、必要な API の自動有効化も処理します。
メリット:
- 階層型リソース検出: アプリ対応フォルダ内のすべてのプロジェクトまたはネストされたフォルダにあるサポートされているサービスとワークロードを単一のアプリケーションとしてグループ化します。
- すべての機能へのアクセス: アプリケーションの設計とデプロイを行う Application Design Center や、Gemini Cloud Assist の AI を活用したアシスタンスなど、アプリケーション管理機能のすべてを利用できます。
- 一元化されたメタデータ: アプリ対応フォルダに作成された管理プロジェクトは、アプリケーションの定義と属性の信頼できる唯一の情報源となります。
- スケーラブルなガバナンス: フォルダを使用して、アプリケーション管理を組織構造に合わせます。
考慮事項:
- フォルダ構造: Google Cloud リソース階層を慎重に計画します。アプリ対応フォルダ内のアプリケーションには、そのフォルダまたはその子孫内の任意のプロジェクトのリソースを含めることができます。ニーズに合わせて、ビジネス ユニット、環境、チームごとにフォルダを整理することを検討してください。
- IAM 戦略: 通常、標準の IAM 継承ルールに従って、アプリ対応フォルダ自体または管理プロジェクトに権限を付与できます。この方法により、きめ細かいアクセス制御が可能になります。
- 課金: 課金がどのように関連付けられているかを理解することをおすすめします。特に、アプリケーション内で自動的に有効になるか使用される API とサービスについては、理解しておくことをおすすめします。
- API の有効化: アプリケーション中心の Google Cloud の主要な API は、管理プロジェクトで自動的に有効になります。
設定手順については、アプリ管理用フォルダを使用して App Hub を設定するをご覧ください。
ホスト プロジェクト
ホスト プロジェクトは、サービスとワークロードを App Hub アプリケーションにグループ化するために使用できる標準の Google Cloud プロジェクトです。ホスト プロジェクトは、既存の App Hub ユーザーがサポートする設定モデルです。ただし、アプリケーション中心の Google Cloud のアプリケーション管理機能のすべてをサポートしているわけではなく、リソースを含めるには手動で構成する必要があります。
制限事項:
- リソースの手動リンク: アプリケーションとしてグループ化するリソースを含む各サービス プロジェクトを、ホスト プロジェクトに手動でアタッチする必要があります。リンクされていないプロジェクトのリソースは App Hub に表示されません。
- 機能セットの制限: ホスト プロジェクトは、アプリ対応フォルダで使用できる機能（Application Design Center の統合や、管理プロジェクトによる API の自動有効化など）をサポートしていません。
- プロジェクト リソース境界: アプリケーション管理は、ホスト プロジェクトと手動で接続されたサービス プロジェクトの範囲内に限定されます。これは組織構造を反映していない可能性があります。
既存のホスト プロジェクト ユーザーには、移行の計画をおすすめします。設定手順については、ホスト プロジェクトを使用して App Hub を設定するをご覧ください。
リソース階層の構造を計画する
App Hub アプリケーションを整理するための基盤は、選択した設定モデルに応じて、アプリ対応フォルダまたはホスト プロジェクトのいずれかです。App Hub のデータモデルは、標準の Google Cloud リソース階層に基づいて構築されており、同じ階層ルールと継承ポリシーが維持されます。
Google Cloud リソース階層のメリットと App Hub のアプリケーション機能を効果的に組み合わせるには、想定されるアプリケーション境界を、設定モデルの基盤となるアプリ対応フォルダまたはホスト プロジェクトにマッピングします。App Hub のデータモデルは、標準の Google Cloud リソース階層のオーバーレイと考えることができます。
- フォルダとプロジェクトは境界です。Resource Manager のフォルダとプロジェクトは、アプリ対応フォルダやホスト プロジェクトがアプリケーションの管理境界を定義するのと同じ方法で、ポリシーの継承と組織のリソースをグループ化します。
- ロールと権限は継承されます: App Hub の IAM ロールと権限は、標準の IAM 継承ルールに従って、管理プロジェクト、アプリ対応フォルダ自体、またはホスト プロジェクトに付与されます。
- メタデータが集中管理される: 管理プロジェクトまたはホスト プロジェクトでアプリケーション メタデータが集中管理され、リソース管理にアプリケーション対応レイヤが追加されます。
リソースの整理の詳細については、リソースの整理のコンセプトとアプリ管理用のフォルダを構成するをご覧ください。
リソース階層に関する考慮事項
アプリ対応フォルダとホスト プロジェクトのどちらを選択するかは、App Hub のリソースの整理方法に大きく影響します。ベスト プラクティスとして、 Google Cloud リソース階層の慎重な計画が不可欠です。
アプリケーションを管理する設定モデルを選択する際は、リソース階層について次の点を考慮することをおすすめします。
アプリ対応フォルダ:
- サービスとワークロードは、フォルダの管理境界内の App Hub アプリケーションに登録できるように、アプリ対応フォルダまたはその子孫のプロジェクト内に存在する必要があります。
- サービスとワークロードの自動検出は、特定のアプリ対応フォルダとその子孫のプロジェクトの境界内で動作します。
フォルダ構造を慎重に計画します。
- 1 つのアプリ対応フォルダを使用して、そのフォルダ内の複数のプロジェクトにわたってアプリケーションを管理します。
- アプリ対応のネストされたフォルダを作成して、アプリケーション管理をさまざまなチームやビジネス ユニットに委任し、アプリケーションをよりきめ細かく制御できるようにします。
ホスト プロジェクト:
- App Hub アプリケーションにリソースを登録できるように、すべてのリソースはホスト プロジェクトに手動でアタッチするサービス プロジェクトに存在する必要があります。
一般的な組織アプローチについては、リソース構造のパターンをご覧ください。
フォルダ内のアプリケーションの管理で説明されているように、親フォルダ（F1 など）でアプリケーション管理を有効にすると、そのフォルダ内のアプリケーションは、そのフォルダ内のプロジェクト（P10 や P11 など）のリソースだけでなく、ネストされたフォルダ（F2 内の P20 や P21 など）内のプロジェクトのリソースも直接含めることができます。
ネストされたフォルダ F2 でアプリケーション管理のみを有効にすると、そのフォルダ内のアプリケーションは、P20 や P21 などのフォルダ内のプロジェクトのリソースのみを使用できます。親フォルダ F1 のリソース（P10 や P11 など）は、F2 のアプリでは使用できません。プロジェクトのリソースを親フォルダに含めるには、そのプロジェクトを F2 に移動する必要があります。
リソース構造のパターン
フォルダとプロジェクトを構造化する際の推奨パターンは次のとおりです。
- 単一のアプリ対応フォルダ: 小規模な組織や初期導入で構成を開始し、単一の管理境界内でアプリケーション管理を統合します。
- 環境ごとにアプリ対応フォルダ: 開発環境間の強力な分離を適用し、異なるポリシーを許可してリスクを軽減します。
- 事業部門またはチームごとにアプリ対応フォルダを作成する: 管理を組織構造とチームの責任に合わせ、自律性を高めます。この方法を実装するには、複数の独立したアプリ対応フォルダを構造化します。
- アプリ対応フォルダのネスト構造: 階層型制御を考慮して整理します（ビジネス ユニット、チーム、環境など）。ビジネス ユニットの最上位フォルダを作成し、各ユニット内に開発環境、ステージング環境、本番環境のネストされたフォルダを作成できます。このパターンでは、リソース階層に関する考慮事項で説明されているアプリ対応フォルダ構造を利用します。
- アプリケーションまたはアプリケーション グループごとに 1 つのホスト プロジェクト: 標準プロジェクトの既存のリソースを整理します。プロジェクトベースの関心の分離に慣れている組織や、この方法で管理されている既存のアプリケーションがある組織に適しています。