クラウド インフラストラクチャを開発する際に、複数のプロジェクトにまたがって Google Cloudリソースを整理することがあります。また、1 つまたは複数のプロジェクト内に、論理的にグループ化したい統合ビジネス機能を提供するリソースが多数存在する可能性もあります。 Google Cloud のリソース階層では、このようなグループ化の目的でインフラストラクチャを管理および整理することが困難になる可能性があります。App Hub は、サービスとワークロードをグループ化して管理するアプリケーション中心の方法を提供し、インフラストラクチャをビジネス機能に合わせるのに役立ちます。
App Hub は、 Google Cloud上のアプリケーションの基盤となるデータモデルと中央レジストリとして機能します。リソースの所有権、依存関係、ビジネス コンテキストを明確にする信頼できる唯一の情報源が作成されます。これにより、他の Google Cloud プロダクトは、必要なアプリ中心のコンテキストでサポートされます。このアプリケーション中心のモデルとその機能の詳細については、アプリケーション中心の Google Cloud をご覧ください。
このドキュメントでは、App Hub の概念的な概要について説明します。App Hub の設定や管理を行う前に、その機能とメリットを理解するのに役立ちます。
App Hub を使用する理由
App Hub は、個々のインフラストラクチャ リソースからそれらが形成するアプリケーションに焦点を移すことで、大規模なガバナンスとオペレーションを効率化するのに役立ちます。
App Hub は、次のアプリケーション中心の機能の実装に役立ちます。
リソース登録の効率化: 複数のサービスとワークロードをアプリケーションに一度に登録します。一度に登録できるサービスとワークロードの数は 10 個までです。
アプリケーションを整理してカタログ化する: 1 つ以上のプロジェクトの分散した Google Cloudリソースを論理的な App Hub アプリケーションにグループ化します。その後、プロパティを見つけて、所有者、ビジネス上の重要度、環境などの属性でこれらのアプリケーションを分類し、検出可能性と説明責任を向上させることができます。詳細については、プロパティと属性をご覧ください。
チームの統合ビューを作成する: 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 の定義と一般的な業界での使用状況を比較します。
| コンセプト | App Hub の定義 | 一般的な業界での使用例 |
|---|---|---|
| アプリケーション | ビジネス機能をまとめて提供するサービスとワークロードの論理グループ。 | 単一のデプロイ可能なユニット、コードベース、または広範なシステムを参照できます。 |
| サービス | クライアントに機能を公開し、リクエストをワークロードに転送できるネットワークまたは API インターフェース（ロードバランサなど）。GKE クラスタなどの一部のサービスは、複数のアプリケーションに登録できる共有サービスとして指定されています。これは、登録タイプのプロパティで示されます。 | 独自のビジネス ロジックとデータを持つマイクロサービス、デプロイ可能なコンポーネント、バイナリコードを指すことが多い。 |
| ワークロード | アプリケーションのバイナリ デプロイがインストールされているコンピューティング リソース。これらのリソースのアプリケーション コードは、ビジネス ロジックの個別の部分を実行します。たとえば、ワークロードは、AI エージェントのコードを実行する GKE デプロイまたは Compute Engine マネージド インスタンス グループ（MIG）にできます。 | コンピューティング リソースを消費するプロセスまたはコンポーネントのより一般的な用語。 |
これらのコンセプトやその他のアプリケーション中心の Google Cloud の中心的なコンセプトの詳細については、主なコンセプトをご覧ください。アプリケーションでサービスまたはワークロードとして登録できる App Hub でサポートされているリソースのリストについては、App Hub でサポートされているリソースをご覧ください。
地理的な分布の要件に基づいて、App Hub アプリケーションを定義できます。ロケーションの選択は、アプリケーションに登録できるサービスとワークロードに影響し、データの所在地要件にとって重要になる可能性があります。次の場所を指定できます。
- グローバル アプリケーション: 複数のGoogle Cloud リージョンのサービスとワークロードをグループ化します。
- リージョン アプリケーション: すべてが単一のリージョン内に存在するサービスとワークロードをグループ化します。
適切なロケーションを選択するための詳細な比較については、グローバル アプリケーションとリージョン アプリケーションをご覧ください。
サービスとワークロードには、アプリケーションの登録ステータスが表示されます。また、アプリケーション、サービス、ワークロードには、プロパティと属性の形式のメタデータを含めることができます。
ロケーション、登録ステータス、メタデータなど、デプロイされたアプリケーションとそのサービスとワークロードの詳細を表示できます。詳細については、サービスとワークロードの詳細を表示するとアプリケーションの詳細を表示するをご覧ください。
サービスとワークロードの登録ステータス
Google Cloud リソースの組織構造は、App Hub がサービスとワークロードを管理する方法に影響し、アプリケーションに登録できます。アプリケーションに