アプリケーション中心の Google Cloud を使用すると、 Google Cloud全体で一貫した方法でアプリケーションを作成、管理できます。App Hub と Application Design Center でアプリケーションの設計と管理のベスト プラクティスに沿って、ビジネスの目標に沿った、運用可能で、管理可能で、効率的なアプリケーションを構築できます。
アプリケーション管理の基本原則
次の基本原則を遵守することで、アプリケーション中心の方法で 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などの名前の単一のアプリケーションを作成または定義します。このアプリケーションは、オンライン ショップ全体を 1 つの管理可能なユニットとして表します。次のリソースをアプリケーションに登録して、オンライン ショップのビジネス機能を共同で提供するコンポーネントの論理グループを作成します。- ワークロードとしてのマイクロサービス: e コマース システムを構成する個々のマイクロサービス（Ad、Cart、Checkout など）を、アプリケーション内のワークロードとして登録します。これらは、ビジネス ロジックの個別の部分を実行するバイナリコードを含むコンピューティング リソースであり、Google Kubernetes Engine（GKE）デプロイとして実行されます。
- サービスとしてのネットワーク エンドポイント: これらのマイクロサービスのネットワーク エンドポイント（ロードバランサなど）をアプリケーションのサービスとして登録します。これらは、オンライン ショップの機能をクライアントに公開します。
各マイクロサービスを独自のアプリケーションとして登録することは避けてください。このアプローチでは、ビジネス コンテキストが断片化され、オンライン ショップの健全性とパフォーマンスを包括的に把握することが難しくなります。
すべてのマイクロサービスを 1 つのアプリケーションにグループ化すると、次のメリットがあります。
- 包括的な可視性: 広告機能から決済機能まで、e コマースのユーザー ジャーニー全体の健全性とパフォーマンスを 1 つの全体像でモニタリングできます。
- 明確なビジネス コンテキスト: アプリケーションは、インフラストラクチャを、それが提供するビジネス機能（オンライン ショップ）に合わせます。このアプローチにより、アプリケーションの健全性と費用を把握しやすくなります。
- トラブルシューティングの簡素化: 問題が発生したときに、アプリケーション内のさまざまなマイクロサービス間の依存関係を確認できるため、根本原因分析を迅速に行うことができます。
例: 3 層ウェブ アプリケーション
3 層ウェブ アプリケーションは、アプリケーションをフロントエンド層、バックエンド層、データベース層に分割するアーキテクチャ パターンです。このユースケースでは、各階層を独立したコンポーネントとして扱うのではなく、ビジネス機能全体を単一のアプリケーションとしてモデル化する方法を示します。
次のモデルは、技術レイヤを 3 層ウェブ アプリケーションにマッピングします。
アプリケーション: 1 つのアプリケーション（
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 と Application Design Center の設定がスケーラブルで、管理可能で、運用プラクティスに沿っていることを確認するには、次の戦略を採用します。
グローバル アプリケーションとリージョン アプリケーションの選択
アプリケーションに選択するロケーション（グローバルまたはリージョン）は、データの処理、レイテンシ、コンプライアンスに影響する基本的な決定です。
- リージョン アプリケーションを優先する: 可能な限り、アプリケーションをリージョンとして定義します。この手法には、レイテンシの短縮、コスト削減の可能性、データ所在地要件への準拠などのメリットがあります。リージョン アプリケーションは、すべてのアプリケーション コンポーネントが単一の Google Cloud リージョン内に存在する場合に推奨されます。これにより、リージョン固有の Google Cloud 機能と障害発生ドメインとの固有の互換性が提供されます。高可用性システムの構築に関するガイダンスについては、リソースの冗長性による高可用性システムを構築するをご覧ください。
- グローバル アプリケーションを戦略的に使用する: グローバル アプリケーションを選択するのは、システムのコンポーネントが複数のリージョンに分散している必要がある場合や、グローバル外部アプリケーション ロードバランサなどのグローバル Google Cloud リソースが関与する場合のみです。
- マルチリージョン システムを分解する: 複数のリージョンにリソースがあり、それらが 1 つのまとまったグローバル機能を形成していない場合は、各リージョン内のコンポーネントに個別のリージョン アプリケーションを定義することを検討してください。この方法により、各デプロイでリージョン化のメリットを最大限に活用できます。
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 に自動的に登録され、アプリケーション モデルが意図した設計を正確に反映します。App Design Center は、テンプレート リビジョンに基づいて一貫したアプリケーション アップデートを管理するのにも役立ちます。テンプレートを更新すると、アプリケーションを再デプロイして変更を反映し、一貫性とガバナンスをサポートできます。
リソース階層に関する考慮事項
Google Cloudのリソース階層は、実用的なアプリケーション管理の基盤となります。管理プロジェクトの構成により、その階層の上にアプリケーション管理レイヤを導入して、アプリケーション管理の境界を定義します。アプリケーション中心の Google Cloud ソリューションの一部としてさまざまなプロダクトが連携する仕組みの概要については、アプリケーション中心の Google Cloud をご覧ください。
アプリケーション管理用の Google Cloud リソース階層を論理グループとして慎重に計画することは不可欠です。アプリケーション管理の境界を定義するために、単一のプロジェクト、フォルダ、または一連のプロジェクトを選択することは、ガバナンス、ポリシーの適用、リソースの検出を根本的に形成します。さらに、アプリケーション中心の Google Cloud プロダクトのサポートは、このアプリケーション管理境界の定義方法によって異なります。
リソース階層とビジネスニーズに最適なアプリケーション管理境界を定義し、さまざまなリソース構造パターンのプロダクト サポートについて確認するには、アプリケーション設定モデルを選択するをご覧ください。
継続的な改善
アプリケーションの設計は静的なものではなく、通常は時間の経過とともに進化します。アプリケーションを定期的に確認して改良し、ビジネス機能、チーム構造、変化するアーキテクチャに引き続き適合するようにします。
Cloud Hub と Gemini Cloud Assist の分析情報を使用して、最適化の機会を特定し、それに応じてアプリケーションを適応させることをおすすめします。Application Design Center を使用して、アーキテクチャの変更をモデル化してデプロイし、テンプレートを使用してアプリケーションのライフサイクルを管理します。