このガイドでは、App Hub 内でアプリケーションを設計して定義するためのベスト プラクティスについて説明します。効果的なアプリケーション設計は、アプリケーション中心の Google Cloud のメリットを最大限に活用するための鍵となります。これにより、可視性、ガバナンス、運用効率が向上します。
アプリケーション設計の基本原則
次の基本原則に沿ってアプリケーションを作成すると、堅牢で保守しやすく、ビジネス目標に沿ったアプリケーションを作成できます。これにより、App Hub から得られる価値を最大化できます。
ビジネス機能を反映する: 技術レイヤや個々のマイクロサービスだけでなく、ビジネス機能やエンドツーエンドのワークフローを中心に App Hub アプリケーションを定義します。アプリケーションは、ビジネスの個別の価値ストリームを表す必要があります。
明確な所有権を決定する: 各アプリケーションに明確なプロパティと属性を割り当て、検出可能性とガバナンスをサポートします。特に、アプリケーション オーナーを追加すると、説明責任が明確になり、コミュニケーションが効率化されます。
アプリケーション境界を検討する: 運用、モニタリング、ガバナンスに適した境界を定義します。アプリケーション内のリソースは、管理を簡素化し、運用リスクを軽減するために、共通の運用ライフサイクルと影響ドメインを共有することが理想的です。
運用上の目的でアプリケーションの境界を検討する際は、Google Cloud Observability がデータ収集と表示をどのように構造化しているかを理解することが重要です。App Hub はアプリケーションの境界に重点を置いていますが、Google Cloud Observability はスコープを使用して、プロジェクト間で可視化および分析可能なテレメトリー データを定義します。これらのオブザーバビリティ スコープの構成は、ホスト プロジェクトまたは管理プロジェクトと特定の関係があり、さまざまなプロジェクトのテレメトリー データを集計して表示する方法を決定します。統合ビュー用にこれらを構成する方法については、オブザーバビリティ スコープを構成するをご覧ください。
進化に対応する: アプリケーションを設計して、アーキテクチャの将来の変更と成長に対応します。
反復的に改善する: 組織の構造、チーム、ビジネスの優先事項の変更を反映するように、アプリケーションを定期的に見直して調整します。
アプリケーションとして定義するもの
App Hub でのアプリケーションの構成要素を理解することは、Google Cloudでアプリケーション管理機能を効果的に統合するうえで不可欠です。アプリケーションは、特定のビジネス機能をまとめて提供するサービスとワークロードをグループ化します。App Hub のアプリケーション、サービス、ワークロードの基本コンセプトの詳細については、コンセプトとデータモデルをご覧ください。
App Hub アプリケーションの適切な境界を判断するには、次の重要な質問を検討してください。
- このリソースのコレクションは、どのようなユーザー価値またはビジネス価値を提供しますか？
- これらのコンポーネントは共通の運用ライフサイクルを共有していますか？
- これらのリソース全体で明確で統一された所有権がありますか？
- このグループ化は、効果的なモニタリングとトラブルシューティングに役立ちますか？
例: OpenTelemetry デモのアーキテクチャ
OpenTelemetry デモ アーキテクチャは、Ad、Cart、Checkout などのマイクロサービスを含む e コマース システムを表しています。App Hub でこのアプリケーションを最適に定義するには、次の推奨事項を検討してください。
e コマース システム全体を 1 つの App Hub アプリケーションとしてモデル化します（例:
my-ecommerce-site）。- 個々のマイクロサービスのコンピューティング インスタンス（Google Kubernetes Engine（GKE）デプロイなど）は、App Hub のワークロードにマッピングされます。
- ロードバランスされた gRPC/HTTP インターフェースなどのネットワーク エンドポイントは、App Hub のサービスにマッピングされます。
Ad、Cart、Checkout などの各マイクロサービスを独自の App Hub アプリケーションとして登録しないでください。このアプローチでは、ビジネス コンテキストが断片化されます。
App Hub がサービスとワークロードとしてサポートするインフラストラクチャ リソースの詳細については、App Hub でサポートされているリソースをご覧ください。
設計戦略
次の設計戦略を採用して、App Hub の設定がスケーラブルで、管理可能で、運用方法に沿ったものになるようにします。
グローバル アプリケーションとリージョン アプリケーションのどちらかを選択する
App Hub アプリケーションを設計する際の基本的な決定事項は、アプリケーションをグローバルとして定義するか、リージョンとして定義するかです。この選択は、含めることができるリソース、データ処理、レイテンシ、費用、コンプライアンスに影響します。
- グローバル アプリケーションは、複数の Google Cloud リージョンに分散しているサービスやワークロード、またはグローバル アプリケーション ロードバランサなどのグローバル リソースに依存するサービスやワークロードに最適です。
- すべてのアプリケーション コンポーネントが単一の Google Cloud リージョン内に存在する場合は、リージョン アプリケーションが推奨されます。この方法は、アーキテクチャで許容される場合は通常、最適なアプローチです。
次のベスト プラクティスは、グローバル アプリケーションとリージョン アプリケーションのどちらを選択するかを判断するのに役立ちます。
- リージョン アプリケーションを優先する: レイテンシの短縮、リージョン間のネットワーク トラフィックのコスト削減、データの局所性要件との整合性、リージョン固有のGoogle Cloud 機能と障害ドメインとの固有の互換性などのメリットを活用するために、可能な限りアプリケーションをリージョンとして設計します。
- グローバル アプリケーションを戦略的に使用する: システム コンポーネントがリージョンに分散している場合や、グローバル Google Cloud サービスが関係している場合にのみ、グローバル アプリケーションを選択します。
- マルチリージョン システムを分解する: 単一のまとまりのあるグローバル関数を形成しないリソースが複数のリージョンにある場合は、各リージョン内のリソースに対して個別のリージョン アプリケーションを定義することを検討してください。この方法により、各デプロイのリージョン化のメリットを最大限に活用できます。
詳細な比較と、この選択の影響の詳細については、グローバル アプリケーションとリージョン アプリケーションをご覧ください。
環境を個別のアプリケーションとして定義する
さまざまなデプロイ環境を個別の App Hub アプリケーションとして表すことができます。このアプローチは、セキュリティ、権限、運用リスクに対して強力な分離を提供し、環境間の偶発的な影響を防ぎます。
たとえば、開発環境、ステージング環境、本番環境のアプリケーションをそれぞれ my-app-dev、my-app-staging、my-app-prod として構造化できます。
単一のアプリケーション内で Environment 属性を使用してリソースにタグを付けることはできますが、環境を個別のアプリケーションに分離すると、アクセス制御、ポリシーの適用、モニタリングの境界を正確に設定できます。環境固有のアプリケーション内のリソースで Environment 属性を一貫して使用して、詳細な情報を提供し、ロールをさらに指定する必要があります。この属性と他の属性の詳細については、ガバナンスに属性を使用するをご覧ください。
チーム構造に沿って調整する
アプリケーション境界を、開発と運用を担当するチームに合わせることを検討します。この方法では、App Hub のアプリケーション モデルが組織の構造を反映しているため、所有権とコミュニケーションを簡素化できます。
ガバナンスに属性を使用する
属性をすべてのアプリケーション リソースに一貫して適用して、検出可能性を高め、ガバナンスを適用します。これらの属性は、フィルタリング、レポート作成、ポリシーの適用に役立つ豊富なメタデータを提供します。
- 重要度: モニタリングとインシデント対応のリソースの優先順位付けに役立ちます。
- 環境: フィルタリングと環境固有のポリシーをサポートします。
- オーナー: 可視性と説明責任を提供します。
これらの属性でリソースにタグ付けするための組織標準を確立します。詳細については、サポートの検出可能性とガバナンスをご覧ください。
アプリケーション管理のユースケースを特定する
App Hub を Application Design Center と統合して、設計から運用まで、シームレスなアプリケーション ライフサイクル エクスペリエンスを実現します。
- アプリケーションとして登録する既存のリソースがある: 設定モデルの既存の Google Cloud リソースを App Hub のアプリケーションに登録して、一元的な可視性と運用制御を実現します。
- アプリケーションとして登録する既存のリソースがない場合: Application Design Center を使用して、新しいアプリケーションを設計してデプロイします。Application Design Center は、デプロイされたリソースを App Hub に自動的に登録するため、モデルは意図した設計を正確に反映します。App Design Center は、アプリケーションの更新の管理にも役立ちます。アプリケーション テンプレートが変更された場合は、テンプレートに基づくインスタンスを更新して、アプリケーションの更新の一貫性を確保できます。
リソース階層
標準の Google Cloud リソース階層は、組織、フォルダ、プロジェクトのリソースで構成されます。App Hub は、設定モデルに応じて、アプリ対応フォルダとホスト プロジェクトのコンセプトを通じて、その階層の上にアプリケーション管理レイヤを導入します。
選択した設定モデルが既存の Google Cloudリソース階層にどのように適合するかを理解することで、効果的なガバナンス、ポリシーの適用、リソース検出が可能になります。アプリケーションの管理用に設定モデルを選択する際は、推奨される構造を確認し、リソース階層を計画します。
継続的な改善
アプリケーション設計は静的ではなく、通常は時間の経過とともに進化します。アプリケーションを定期的に見直し、改善して、ビジネスニーズ、チーム構造、変化するアーキテクチャに沿っていることを確認します。
Cloud Hub と Gemini Cloud Assist の分析情報を使用して最適化の機会を特定し、それに応じてアプリケーションを調整することをおすすめします。また、App Design Center を使用して、アプリケーションのライフサイクルを管理することもできます。Cloud Hub の [デプロイ] ページには、ベースとなった App Design Center テンプレートから利用可能な更新があるアプリケーションが表示され、更新プロセスが効率化されます。