App Hub の概要

App Hub を使用すると、 Google Cloud インフラストラクチャをアプリケーションとしてグループ化して管理できます。このアプリケーション中心のアプローチにより、リソース階層だけでなく、複数のプロジェクトにわたるビジネス機能を中心にリソースを整理できます。

App Hub はアプリケーションの一元的なレジストリであり、アプリケーション中心の Google Cloud のアプリケーション データモデルを提供します。レジストリは、アプリケーション中心の Google Cloud 全体で、オーナー権限、依存関係、ビジネス コンテキストに関する信頼できる唯一の情報源です。

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 Deployment または 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: サービスを複数のアプリケーションに登録できます。この値は、サービスが共有サービスであることを示します。

      共有サービスと排他的サービスについては、App Hub でサポートされているサービスのリストをご覧ください。

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

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

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

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

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

      • 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 をご覧ください。アプリケーション管理の境界を定義する方法については、アプリケーション設定モデルを選択するをご覧ください。

次のステップ