このガイドでは、App Hub と Application Design Center を使用して、アプリケーション中心の Google Cloud で App Hub アプリケーションを設計、定義、管理するためのベスト プラクティスについて説明します。これらのプラクティスに従うことは、ビジネス目標に沿った運用可能で管理可能かつ効率的なアプリケーションを作成するうえで重要です。
アプリケーション管理の基本原則
次の基本原則に沿って、アプリケーション中心の方法で Google Cloud インフラストラクチャを管理することで、得られる価値を最大化できます。
明確な境界を定義する: 運用、モニタリング、ガバナンス、トラブルシューティングに論理的な方法でアプリケーション管理境界を設定します。また、この境界内のリソースをアプリケーション コンポーネントとして使用する場合は、管理を簡素化し、リスクを軽減するために、共同の運用ライフサイクルまたはビジネス価値を共有することが理想的です。
運用上の目的で、アプリケーション管理境界とオブザーバビリティ スコープの違いを理解することが重要です。
- アプリケーション管理境界は、主なコンセプトで説明されているように、アプリケーションの設計、作成、管理に使用できる Google Cloud リソースを含むプロジェクトのコレクションを定義します。
- Google Cloud Observability のオブザーバビリティ スコープを使用すると、複数のプロジェクトのテレメトリーをまとめて表示できます。
ログ、指標、トレースのスコープには、アプリケーション管理境界に含まれるプロジェクトと同じプロジェクトのデータを含める必要があります。オブザーバビリティ スコープの詳細については、オブザーバビリティ スコープを構成するをご覧ください。
ビジネス機能を反映する: 技術レイヤだけでなく、ビジネス機能やエンドツーエンドのワークフローを中心にアプリケーションを定義します。アプリケーションは、ビジネスの明確な価値ストリームを表す必要があります。
明確な所有権とメタデータを確立する: 各アプリケーションに明確な属性を割り当てて、チームが App Hub でアプリケーションを効果的に検索、理解、管理できるようにします。これらの属性は、検出可能性とガバナンスをサポートします。検出可能性とは、デベロッパーやオペレーターなどの関連チームがアプリケーションを見つけられることを意味します。ガバナンスでは、各アプリケーションの所有者と責任者を明確に定義します。
App Hub では、次のような重要な属性を定義できます。
- 環境: アプリケーションのライフサイクルのステージ（本番環境、ステージング環境、テスト環境、開発環境など）。この属性を使用すると、チームはデプロイ ステージに基づいてコンポーネントをフィルタして管理できます。
- 重要度: アプリケーションとそのコンポーネントのビジネス上の重要度（ミッション クリティカルかどうかなど）。この属性は、モニタリングとインシデント対応の優先度を判断するのに役立ちます。
- オーナー: アプリケーションを担当するさまざまなチームの連絡先情報。説明責任の明確化、コミュニケーションの効率化、責任の明確化に役立ちます。
Application Design Center はこれらの属性をサポートしており、アプリケーション コンポーネントのロケーションと構成の詳細も含まれています。これらの属性と詳細を一貫して適用することは、検出、ガバナンス、レポート作成に不可欠です。
進化を考慮した設計: App Design Center では、アプリケーションの再利用可能なテンプレートを作成できるため、進化を考慮した設計を行うことができます。基盤となるテンプレートを更新すると、アプリケーションを再デプロイして変更を適用できます。これにより、需要を満たし、新機能を導入し、アーキテクチャを変更して、将来の成長と進化するインフラストラクチャのニーズに対応できます。
アプリケーション モデルを反復して改善する: 組織の構造、ビジネスの優先事項、技術アーキテクチャの変更を反映するように、アプリケーション定義を定期的に見直して調整します。Cloud Hub は、Application Design Center テンプレートからデプロイされたアプリケーションの利用可能な更新を一元的に表示します。これにより、進化するニーズを反映するようにアプリケーション定義を確認して調整できます。
データモデルに関する推奨事項
App Hub のフレームワーク内で実際のシステムをアプリケーション、サービス、ワークロードとしてモデル化する方法を理解することで、 Google Cloud環境でアプリケーション管理機能を効果的に使用できます。
アプリケーションを定義する際は、属性を使用して明確な所有権とメタデータを確立するなど、アプリケーション管理の基本原則を適用することが重要です。
このフレームワークを念頭に置いてアプリケーション コンポーネントをモデル化するには、推奨されるユースケースの次の例を検討してください。
例: マイクロサービス ベースのアプリケーション
オンライン ストアの OpenTelemetry デモで説明されているような e コマース システムは、マイクロサービス ベースのアプリケーションの例です。このようなシステムは、単一のアプリケーションとしてモデル化することをおすすめします。このアプローチでは、商品検索から購入手続きまで、ビジネス機能全体の統一されたビューが提供されます。たとえば、 Google Cloudで実行されている既存のリソースの次のモデルについて考えてみましょう。
アプリケーション: App Hub で、
my-ecommerce-siteなどの名前の単一のアプリケーションを作成または定義します。このアプリケーションは、オンライン ストア全体を単一の管理可能な単位として表します。次のリソースをアプリケーションに登録して、オンライン ショップのビジネス機能を共同で提供するコンポーネントの論理グループを作成します。- ワークロードとしてのマイクロサービス: Ad、Cart、Checkout などの e コマース システムを構成する個々のマイクロサービスを、アプリケーション内のワークロードとして登録します。これらは、ビジネス ロジックの個別の部分を実行するバイナリコードを含むコンピューティング リソースであり、Google Kubernetes Engine（GKE）デプロイとして実行されます。
- サービスとしてのネットワーク エンドポイント: ロードバランサなどのマイクロサービスのネットワーク エンドポイントを、アプリケーションのサービスとして登録します。これらは、オンライン ストアの機能をクライアントに公開します。
各マイクロサービスを独自のアプリケーションとして登録することは避けてください。このアプローチでは、ビジネス コンテキストが断片化され、オンライン ショップの健全性とパフォーマンスを包括的に把握することが難しくなります。
すべてのマイクロサービスを 1 つのアプリケーションにグループ化すると、次のメリットがあります。
- 包括的な可視性: 広告機能から購入手続き機能まで、e コマース ユーザーの購入プロセス全体の健全性とパフォーマンスを 1 つの統合ビューでモニタリングできます。
- 明確なビジネス コンテキスト: アプリケーションは、インフラストラクチャを、オンライン ストアというビジネス機能に合わせます。このアプローチにより、アプリケーションの健全性と費用を簡単に把握できます。
- トラブルシューティングの簡素化: 問題が発生したときに、アプリケーション内のさまざまなマイクロサービス間の依存関係を確認できるため、根本原因の分析を迅速に行うことができます。
例: 3 層ウェブ アプリケーション
3 層ウェブ アプリケーションは、アプリケーションをフロントエンド層、バックエンド層、データベース層に分離するアーキテクチャ パターンです。このユースケースでは、各階層を分離されたコンポーネントとして扱うのではなく、完全なビジネス機能を単一のアプリケーションとしてモデル化する方法を示します。
次のモデルは、技術レイヤを 3 層ウェブ アプリケーションにマッピングします。
アプリケーション: ウェブ アプリケーションを構成するすべてのコンポーネントの論理コンテナとして機能する単一のアプリケーション（
my-web-appなど）を作成します。サービス: 機能を他の階層やユーザーにサービスとして公開するネットワーク インターフェースを登録します。例:
- ユーザートラフィックを受信するフロントエンド ロードバランサ。
- フロントエンドとバックエンド間のトラフィックを管理する内部ロードバランサ。
- バックエンド ロジック階層にデータサービスを公開する Cloud SQL または Spanner データベース インスタンス。
ワークロード: アプリケーションのコードを実行するコンピューティング リソースをワークロードとして登録します。例:
- フロントエンド ユーザー インターフェースを提供するマネージド インスタンス グループ（MIG）または Google Kubernetes Engine のデプロイ。
- バックエンド ビジネス ロジックを実行する MIG または Google Kubernetes Engine デプロイ。
3 つの階層を 1 つのアプリケーションにグループ化すると、次のメリットがあります。
- 統合された可観測性: 3 つの別々のアプリケーションからデータを収集するのではなく、アプリケーション モニタリングの単一のダッシュボードからアプリケーション全体の健全性とパフォーマンスをモニタリングできます。
- 明確な所有権:
my-web-appアプリケーションにビジネス オーナー、デベロッパー オーナー、オペレーター オーナーを割り当て、ビジネス機能全体のアカウンタビリティを明確にできます。 - ガバナンスの簡素化:
my-web-appレベルでポリシーとアクセス制御を適用し、すべての階層で一貫したガバナンスをサポートできます。
アプリケーションの設計とガバナンスの戦略
App Hub と App Design Center の設定がスケーラブルで、管理可能で、運用方法に沿ったものになるように、次の戦略を採用します。
グローバル アプリケーションとリージョン アプリケーションのどちらかを選択する
アプリケーションのロケーション（グローバルまたはリージョン）の選択は、データ処理、レイテンシ、コンプライアンスに影響する基本的な決定です。
- リージョン アプリケーションを優先する: 可能な限り、アプリケーションをリージョンとして定義します。この手法には、レイテンシの短縮、費用の削減、データ所在地に関する要件への準拠などのメリットがあります。すべてのアプリケーション コンポーネントが単一の Google Cloud リージョン内に存在する場合、リージョン アプリケーションをおすすめします。リージョン固有の Google Cloud 機能と障害ドメインとの互換性が確保されます。高可用性システムの構築に関するガイダンスについては、リソースの冗長性による高可用性システムを構築するをご覧ください。
- グローバル アプリケーションを戦略的に使用する: システムのコンポーネントが複数のリージョンに分散されている場合や、グローバル外部アプリケーション ロードバランサなどのグローバル Google Cloud リソースが関係している場合にのみ、グローバル アプリケーションを選択します。
- マルチリージョン システムを分解する: 単一のまとまりのあるグローバル関数を形成しない複数のリージョンにリソースがある場合は、各リージョン内のコンポーネントに対して個別のリージョン アプリケーションを定義することを検討してください。この方法により、各デプロイの地域化のメリットを最大限に活用できます。
App Hub のさまざまなデプロイの地域間の詳細な比較については、グローバル アプリケーションとリージョン アプリケーションをご覧ください。
環境を個別のアプリケーションに分離する
セキュリティ、権限、運用リスクの分離をサポートするには、開発、ステージング、本番などのさまざまなデプロイ環境を個別のアプリケーションとして表します。たとえば、アプリケーションを my-app-dev、my-app-staging、my-app-prod として構造化できます。
環境を個別のアプリケーションに分離すると、アクセス制御、ポリシーの適用、モニタリングに正確な上限を設定できます。また、アプリケーション コンポーネントで属性、構成の詳細、ロケーションを一貫して使用すると、検出可能性が高まり、ガバナンスが強化されます。これらの属性は、フィルタリング、レポート作成、ポリシー適用に役立つ豊富なメタデータを提供します。たとえば、Environment 属性は、個別のデプロイ環境ポリシーに対して、きめ細かい詳細とリソース固有の制御を提供します。この属性とその他の属性について詳しくは、プロパティと属性をご覧ください。
アプリケーション管理の境界をチーム構造に合わせる
組織構造、特にアプリケーションの開発と運用を担当するチームを、アプリケーション管理の境界内で表します。
この方法では、アプリケーション モデルが、ビジネスでタスクの分割、グループ化、調整方法を定義するために使用するフレームワークを反映しているため、所有権とコミュニケーションが簡素化されます。
アプリケーションのライフサイクルに沿う
App Hub を Application Design Center と統合して、シームレスなアプリケーション ライフサイクル エクスペリエンスを実現します。
- アプリケーションに登録する既存のリソースがある場合: App Hub を使用して、既存の Google Cloud リソースをアプリケーションのサービスまたはワークロードとして登録します。このプラクティスにより、現在のインフラストラクチャに対する統合された可視性と運用制御を迅速に実現できます。必要に応じて、後で実行中のアプリケーションから App Design Center でテンプレートを作成し、今後のデプロイのアーキテクチャを標準化できます。
- アプリケーションに登録する既存のリソースがない場合: Application Design Center を使用して、管理された再利用可能なテンプレートから新しいアプリケーションを設計してデプロイします。Application Design Center テンプレートからアプリケーションをデプロイすると、コンポーネントが App Hub に自動的に登録されるため、アプリケーション モデルは意図した設計を正確に反映します。Application Design Center は、テンプレート リビジョンに基づいて一貫したアプリケーション更新を管理するのにも役立ちます。テンプレートを更新すると、アプリケーションを再デプロイして変更を反映し、一貫性とガバナンスをサポートできます。
リソース階層に関する考慮事項
Google Cloud のリソース階層は、実用的なアプリケーション管理の基盤となります。管理プロジェクトの構成を通じて、その階層の上にアプリケーション管理レイヤを導入し、アプリケーション管理の境界を定義します。アプリケーション中心の Google Cloud ソリューションの一部としてさまざまなプロダクトが連携する仕組みの概要については、アプリケーション中心の Google Cloud をご覧ください。
アプリケーション管理のための Google Cloud リソース階層を慎重に計画することは、論理グループを確立するために不可欠です。アプリケーション管理の境界を定義するために単一のプロジェクト、フォルダ、または一連のプロジェクトを選択すると、ガバナンス、ポリシーの適用、リソース検出が根本的に変わります。また、アプリケーション中心の Google Cloud プロダクトのサポートは、このアプリケーション管理境界の定義方法によって異なります。
リソース階層とビジネスニーズに最適なアプリケーション管理境界を定義し、さまざまなリソース構造パターンに対するプロダクト サポートについて学習するには、アプリケーション設定モデルを選択するをご覧ください。
継続的な改善
アプリケーション設計は静的ではなく、通常は時間の経過とともに進化します。アプリケーションを定期的に見直して改善し、ビジネス機能、チーム構造、変化するアーキテクチャに沿っていることを確認します。
Cloud Hub と Gemini Cloud Assist の分析情報を使用して、最適化の機会を特定し、それに応じてアプリケーションを調整することをおすすめします。Application Design Center を使用して、アーキテクチャの変更をモデル化してデプロイし、テンプレートを使用してアプリケーションのライフサイクルを管理します。