App Hub の概要

クラウド インフラストラクチャを開発する際に、複数のプロジェクトにまたがって 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 は、次のアプリケーション中心の機能の実装に役立ちます。

  • アプリケーションを整理してカタログ化する: 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 インターフェース。 独自のビジネス ロジックとデータを持つマイクロサービス、デプロイ可能なコンポーネント、バイナリコードを指すことが多い。
ワークロード アプリケーションのバイナリ デプロイがインストールされているコンピューティング リソース。これらのリソースのアプリケーション コードは、ビジネス ロジックの個別の部分を実行します。たとえば、ワークロードは、AI エージェントのコードを実行する GKE デプロイまたは Compute Engine マネージド インスタンス グループ（MIG）です。 コンピューティング リソースを消費するプロセスまたはコンポーネントのより一般的な用語。

これらのコンセプトとその他のアプリケーション中心の Google Cloud の中心的なコンセプトの詳細については、主なコンセプトをご覧ください。アプリケーションでサービスまたはワークロードとして登録できる App Hub でサポートされているリソースのリストについては、App Hub でサポートされているリソースをご覧ください。

地理的分布の要件に基づいて、App Hub アプリケーションを定義できます。ロケーションの選択は、アプリケーションに登録できるサービスとワークロードに影響し、データ所在地要件にとって重要になる可能性があります。次の場所を指定できます。

  • グローバル アプリケーション: 複数のGoogle Cloud リージョンのサービスとワークロードをグループ化します。
  • リージョン アプリケーション: すべてが単一のリージョン内に存在するサービスとワークロードをグループ化します。

適切なロケーションを選択するための詳細な比較については、グローバル アプリケーションとリージョン アプリケーションをご覧ください。

サービスとワークロードには、アプリケーションの登録ステータスが表示されます。また、アプリケーション、サービス、ワークロードには、プロパティと属性の形式でメタデータを含めることができます。

ロケーション、登録ステータス、メタデータなど、デプロイされたアプリケーションとそのサービスとワークロードの詳細を表示できます。詳細については、サービスとワークロードの詳細を表示するとアプリケーションの詳細を表示するをご覧ください。

サービスとワークロードの登録ステータス

Google Cloud リソースの組織構造は、App Hub がサービスとワークロードを管理する方法に影響し、アプリケーションに登録できます。アプリケーションに登録できるサービスとワークロードには、次のいずれかの登録ステータスがあります。

  • 検出済み: アプリケーション管理境界の一部であるため、アプリケーションに登録できるサービスとワークロード。他のアプリケーションに登録されていないか、複数のアプリケーションに登録できます。検出されたステータスには、アプリケーションから削除または登録解除されたが、再登録できるサービスとワークロードも含まれます。

  • 登録済み: アプリケーションに登録され、App Hub によって管理されているサービスとワークロード。登録できるのは、検出されたサービスとワークロードのみです。サービスまたはワークロードを登録すると、登録ステータスが [検出済み] から [登録済み] に更新されます。

  • 接続解除: アプリケーションに登録されているサービスまたはワークロード。基盤となる Google Cloud リソースが定義したアプリケーション管理境界の一部ではなくなったため、App Hub で管理またはモニタリングできません。アプリケーションに登録されているサービスとワークロードの登録ステータスは、次の理由で [接続解除] に変更されることがあります。

    • 基盤となるリソースが削除されます。たとえば、サービスによって表される転送ルールを削除すると、サービスの登録ステータスが 接続解除に変わります。
    • 登録されたサービスまたはワークロードの基盤となるリソースを含むプロジェクトまたはフォルダが、アプリケーション管理境界外に移動された。

    接続が解除されたサービスとワークロードは、登録を解除するまでアプリケーションに残ります。

    プロジェクトをアプリケーション管理境界外に移動すると、切り離されたサービスとワークロードが別の境界内のアプリケーションから検出可能になる可能性があります。アプリケーション管理境界によって確立されたリソース階層に準拠して、検出可能なサービスとワークロードを再度登録できます。

Google Cloud でリソース階層に適合するアプリケーション管理境界を選択し、App Hub がビジネスニーズを満たすサービスとワークロードを検出して登録できるようにするには、アプリケーション設定モデルを選択するをご覧ください。サービスとワークロードの登録ステータスを表示するには、サービスとワークロードの詳細を表示するをご覧ください。

プロパティと属性

データモデルを拡充するために、App Hub では、アプリケーションの検出可能性、アカウンタビリティ、ガバナンスをサポートするプロパティと属性を公開できます。これらの値をアプリケーション メタデータとして定義すると、アプリケーション コンポーネントを大規模にフィルタリング、管理し、ポリシーを適用できます。

アプリケーションのサービスとワークロードのプロパティと属性を表示するには、サービスとワークロードの詳細を表示するをご覧ください。

プロパティと属性の定義と機能は次のとおりです。

  • プロパティは、登録されたサービスまたはワークロードの基盤となるインフラストラクチャ（プロジェクト ID、ロケーション、タイプなど）を記述する変更不可能なフィールドです。これらは自動的に検出され、App Hub で編集することはできません。サポートされている主なプロパティは次のとおりです。

    • （プレビュー） 登録タイプ: サービスの場合、サービスを 1 つまたは複数のアプリケーションに登録できるかどうかを示す出力専用プロパティ。このプロパティで指定可能な値は次のとおりです。

      • EXCLUSIVE: サービスを登録できるのは 1 つのアプリケーションのみです。
      • SHARED: サービスを複数のアプリケーションに登録できます。この値は、サービスが共有サービスであることを示します。

    • （プレビュー） 機能タイプ: サービスまたはワークロードの既知の機能を識別する出力専用プロパティ。たとえば、Vertex AI Agent Engine などのマネージド プラットフォームを介して AI エージェントがデプロイされると、App Hub は AGENT 機能タイプ値でリソースを自動的に分類し、ワークロードが AI エージェントを実行していることを示します。

    • （プレビュー） 拡張メタデータ: サービスまたはワークロードに関する豊富な構造化情報を提供するスキーマ駆動型プロパティ。これは、詳細な型固有のデータを追加する Key-Value フィールドを指します。たとえば、機能タイプ値が AGENT のワークロードには、Agent2Agent（A2A）エージェント カードと互換性のあるエージェントに関する情報を含む apphub.googleapis.com/AgentProperties メタデータを含めることができます。サポートされているメタデータ型とそのスキーマの一覧については、拡張メタデータ スキーマをご覧ください。

    • （プレビュー） Identity: サービスまたはワークロードのサービス アカウントまたはマネージド ワークロード ID 名を含む出力専用プロパティ。

  • 属性は、アプリケーション、サービス、ワークロードに適用して整理および管理できる、変更可能なユーザー定義のメタデータです。アプリケーションを作成してリソースを登録するときに、アプリケーション、サービス、ワークロードに属性を追加できます。サービスとワークロードの属性を更新したり、アプリケーションの属性を更新したりすることもできます。主な属性は次のとおりです。

    • オーナー: デベロッパー、オペレーター、ビジネス チームの連絡先情報。サポートされているオーナータイプは次のとおりです。

      • developer_owners: 開発とコーディングを担当する開発チーム。
      • operator_owners: ランタイムとオペレーションの完全性を維持するオペレーター チーム。
      • business_owners: 品質を維持し、ユーザーの期待に応えるビジネスチーム。

    • 重要度: ビジネスに対するコンポーネントの重要度。サポートされている値は次のとおりです。

      • MISSION_CRITICAL
      • HIGH
      • MEDIUM
      • LOW

    • 環境: コンポーネントのライフサイクル ステージ。サポートされている値は次のとおりです。

      • PRODUCTION
      • STAGING
      • DEVELOPMENT
      • TEST

App Hub リソースモデル

アプリケーション中心の機能を有効にするため、App Hub は、管理プロジェクトとアプリケーション管理境界の概念を中心としたリソースモデルを使用します。

  • 推奨: フォルダレベルの境界: コンポーネントが Google Cloud フォルダ構造内で整理されている場合は、フォルダを境界として使用できます。このアプローチでは、ビジネス ユニット、環境、チームごとにアプリケーション管理境界を組織構造に合わせ、そのフォルダ内のすべてのプロジェクトが自動的に含まれます。
  • 単一プロジェクトの境界: すべての Google Cloud リソースが 1 つのプロジェクトに存在する小規模なアプリケーションの場合は、その単一のプロジェクトを境界として指定できます。これは、アプリケーション管理を始める最も簡単な方法です。プロジェクトをスタンドアロンの管理プロジェクトとして構成することで、単一プロジェクトの境界を定義できます。
  • （以前の）ホスト プロジェクトを含む複数プロジェクトの境界: 既存のユーザーの場合、App Hub は、 Google Cloud プロジェクトで App Hub API を有効にしてアプリケーション管理用のホスト プロジェクトを指定できる以前のモデルをサポートしています。次に、マルチプロジェクト リソース検出のために、サービス プロジェクトと呼ばれる他のプロジェクトを手動で接続します。 Google Cloud

App Hub が リソース階層 Google Cloudの上に導入するこのアプリケーション管理レイヤにより、App Hub は境界内のサポートされているリソースを検出できます。アプリケーションのセットアップ モデルを選択し、リソース階層とガバナンスのニーズに最適なアプリケーション管理境界を設定できます。

このリソース構成でのデータ処理と他のアプリケーション中心の機能については、アプリケーション中心の Google Cloud をご覧ください。開始方法とアプリケーション管理境界の定義について詳しくは、アプリケーション設定モデルを選択するをご覧ください。

次のステップ