クラウド インフラストラクチャを開発する際に、複数のプロジェクトにまたがってリソースを整理することがあります。このアプローチでは、リソースの管理と整理が難しくなる可能性があります。App Hub は、これらのリソースをアプリケーション中心の方法でグループ化し、インフラストラクチャをビジネス機能に合わせるのに役立ちます。
App Hub は、 Google Cloud上のアプリケーションの基盤となるデータモデルと中央レジストリとして機能します。リソースの所有権、依存関係、ビジネス コンテキストを明確にする信頼できる唯一の情報源が作成されます。これにより、他の Google Cloud サービスは必要なアプリケーション中心のコンテキストでサポートされます。このアプリケーション中心のモデルとそのリソース構成の詳細については、アプリケーション中心の Google Cloud をご覧ください。
このドキュメントでは、App Hub の概念的な概要について説明します。App Hub の設定や管理を行う前に、その機能とメリットを理解するのに役立ちます。
App Hub を使用する理由
App Hub は、個々のインフラストラクチャ コンポーネントからそれらが形成するアプリケーションに焦点を移すことで、大規模なガバナンスと運用の合理化を支援します。
App Hub は、次の実装に役立ちます。
アプリケーションを整理してカタログ化する: 1 つ以上のプロジェクトから分散したリソースを論理アプリケーションにグループ化します。次に、所有者、ビジネスの重要度、環境などの属性を使用してこれらのアプリケーションを分類し、検出可能性とアカウンタビリティを向上させることができます。詳細については、サポートの検出可能性とガバナンスをご覧ください。
チームの統合ビューを作成する: App Hub でアプリケーションを定義すると、他の Google Cloudサービスに重要なコンテキストが提供されます。たとえば、次の機能を有効にします。
- Cloud Hub の運用と分析情報の一元的なビュー。アプリケーションのコンテキストでアラート、インシデント、パフォーマンス データが表示されます。
- Gemini Cloud Assist の AI を活用したアシスタンス。App Hub のデータモデルを使用して、アプリケーションの設計、運用、トラブルシューティングを支援します。
- Google Cloud Observability を使用したアプリケーション モニタリング。アプリケーションとそのリソースのテレメトリー データを表示することで、エラーのトラブルシューティングとパフォーマンスの改善に役立ちます。
リソースの所有権と依存関係を明確にする: アプリケーションの構成と、コンポーネント間の依存関係を把握します。この機能は、デベロッパーとオペレーターがアプリケーション アーキテクチャを可視化し、所有者を特定して問題を解決するのに役立ちます。
App Hub がアプリケーション ライフサイクル全体にどのように適合するかについては、アプリケーション中心の Google Cloud をご覧ください。
コンセプトとデータモデル
App Hub は、アプリケーション、サービス、ワークロードという次の主要なコンセプトに基づくデータモデル上に構築されています。これらの用語は一般的ですが、App Hub では特定の意味で使用されます。次の表に、App Hub の定義と業界での一般的な使用方法を比較します。
| コンセプト | App Hub の定義 | 一般的な業界での使用例 |
|---|---|---|
| アプリケーション | ビジネス機能をまとめて提供するサービスとワークロードの論理グループ。 | 単一のデプロイ可能なユニット、コードベース、または広範なシステムを参照できます。 |
| サービス | ロードバランサなど、クライアントに機能を公開するネットワークまたは API インターフェース。 | 多くの場合、独自のビジネス ロジックとデータを持つデプロイ可能なコンポーネントであるマイクロサービスを指します。 |
| ワークロード | GKE デプロイや Compute Engine インスタンス グループなど、個別のビジネス機能ユニットを実行するバイナリ デプロイ。 | コンピューティング リソースを消費するプロセスまたはコンポーネントのより一般的な用語。 |
これらの中心的なコンセプトの詳細については、基本的なコンセプトをご覧ください。
地理的分布の要件に基づいて、App Hub アプリケーションを定義できます。次の場所を指定できます。
- グローバル アプリケーションは、複数のGoogle Cloud リージョンのサービスとワークロードをグループ化できます。
- リージョン アプリケーションには、すべて単一のリージョン内に存在するリソースが含まれています。
この選択は、登録できるリソースに影響し、データ所在地要件にとって重要になる可能性があります。適切なロケーションを選択するための詳細な比較については、グローバル アプリケーションとリージョン アプリケーションをご覧ください。
サービスとワークロードの登録ステータス
Google Cloud リソースの組織構造は、App Hub がサービスやワークロードとどのように連携し、それらをアプリケーションにグループ化する方法に影響します。アプリケーションに登録できるサービスとワークロードには、次のいずれかの登録ステータスがあります。
- 検出済み: 設定モデルのリソース階層の一部であり、他のアプリケーションに登録されていないため、アプリケーションに登録できるサービスとワークロード。検出されたサービスとワークロードには、アプリケーションから削除または登録を解除したサービスやワークロードも含まれますが、再登録できます。
- 登録済み: アプリケーションに登録され、App Hub によって管理されているサービスとワークロード。登録できるのは検出されたサービスとワークロードのみで、それぞれが 1 つのアプリケーションの一部にのみなります。サービスまたはワークロードを登録すると、登録ステータスが [検出済み] から [登録済み] に更新されます。
接続解除: アプリケーションにコンポーネントとして登録されているサービスまたはワークロード。基盤となるリソースが設定モデルのリソース階層の一部ではなくなったため、App Hub で管理またはモニタリングできません。アプリケーションに登録されているサービスとワークロードの登録ステータスが [接続解除] に変更されるのは、次のような理由が考えられます。
- 基盤となるリソースが削除されます。たとえば、サービスによって表される転送ルールを削除すると、サービスの登録ステータスが 接続解除に変わります。
- ホスト プロジェクトの場合: 設定モデルにホスト プロジェクトを使用し、登録されたサービスまたはワークロードの基盤となるリソースを含むサービス プロジェクトがホスト プロジェクトから削除されます。
- 管理プロジェクトの場合: 設定モデルに管理プロジェクトを使用し、登録されたサービスまたはワークロードの基盤となるリソースを含むアプリ管理用フォルダの子孫プロジェクトがアプリ管理用フォルダから移動された場合。
接続が解除されたサービスとワークロードは、登録を解除するまでアプリケーションに残ります。
プロジェクトをセットアップ モデルのアプリケーション管理境界から移動すると、切り離されたサービスとワークロードが別の境界のアプリケーションで検出可能になる可能性があります。検出可能なサービスとワークロードは、アプリケーション管理境界によって確立されたリソース階層に準拠して、再度登録できます。
サービスとワークロードの登録ステータスを表示するには、サービスとワークロードの詳細を表示するをご覧ください。
検出可能性とガバナンスをサポートする
データモデルを拡充するために、App Hub では、アプリケーションの検出可能性、アカウンタビリティ、リソース ガバナンスをサポートするプロパティと属性を公開できます。これらの値をアプリケーション メタデータとして定義すると、リソースを大規模にフィルタリング、管理し、ポリシーを適用できます。
プロパティと属性の定義と機能は次のとおりです。
プロパティは、登録されたサービスまたはワークロードの基盤となるインフラストラクチャ（プロジェクト ID、ロケーション、ゾーンなど）を記述する変更不可能なフィールドです。これらは自動的に検出され、App Hub で編集することはできません。
属性は、アプリケーション、サービス、ワークロードに適用して整理および管理できる、変更可能なユーザー定義のメタデータです。主な属性は次のとおりです。
オーナー: デベロッパー、オペレーター、ビジネス チームの連絡先情報。サポートされているオーナータイプは次のとおりです。
developer_owners: 開発とコーディングを担当する開発チーム。operator_owners: ランタイムとオペレーションの完全性を維持するオペレーター チーム。business_owners: 品質を維持し、ユーザーの期待に応えるビジネスチーム。
重要度: ビジネスにとってのリソースの重要度。サポートされている値は次のとおりです。
- ミッション クリティカル
- 高
- 中
- 低
環境: リソースのライフサイクル ステージ。サポートされている値は次のとおりです。
- 本番環境
- ステージング
- テスト
- 開発
App Hub リソースモデル
アプリケーション中心の機能を有効にするため、App Hub は次の Google Cloud フォルダとプロジェクトに基づくモデルを使用します。
推奨: アプリ対応フォルダ: アプリケーション管理用に構成された標準の Google Cloud フォルダ。このフォルダは、アプリケーションの管理境界として機能します。フォルダがアプリ対応になると、 Google Cloud はそのフォルダ内に管理プロジェクトを自動的に作成します。この Google が作成したプロジェクトは、すべてのアプリケーション モデルとメタデータの中央リポジトリとして機能します。これは、アプリケーション中心の Google Cloud プロダクトを使用する場合に推奨されるパスであり、アプリケーション管理機能の完全なサービスにアクセスするために必要です。
ホスト プロジェクト: サービスとワークロードを App Hub のアプリケーションとしてグループ化するために使用できる Google Cloud プロジェクト。ただし、アプリケーション管理機能の完全なセットへのアクセスはサポートされていません。
アプリケーション中心のリソースモデルの詳細については、リソースの編成のコンセプトをご覧ください。開始手順の詳細については、設定モデルを選択するをご覧ください。
次のステップ
- App Hub に登録できる Google Cloud リソースについては、サポートされているリソースをご覧ください。
- App Hub の設定を開始するには、アプリ管理用フォルダを使用して App Hub を設定するをご覧ください。
- App Hub の使用に必要な権限については、ロールと権限をご覧ください。