Google Cloud Well-Architected Framework のこの柱では、Google Cloudのワークロードのパフォーマンスを最適化するための推奨事項について説明します。
このドキュメントは、 Google Cloudでワークロードの計画、設計、デプロイ、管理を行うアーキテクト、デベロッパー、管理者を対象としています。
この柱の推奨事項は、組織の効率的な運用、顧客満足度の向上、収益の増加、費用の削減に役立ちます。たとえば、アプリケーションのバックエンド処理時間が短くなると、レスポンス時間が短くなり、ユーザー維持率の向上と収益の増加につながります。
パフォーマンスの最適化プロセスでは、パフォーマンスと費用のトレードオフが発生する可能性があります。ただし、パフォーマンスを最適化することで費用を削減できる場合もあります。たとえば、負荷が増加すると、自動スケーリングによってシステム リソースが過負荷にならないようにすることで、予測どおりのパフォーマンスを実現できます。また、自動スケーリングにより、負荷が低いときに未使用のリソースを削除することで、費用を削減することもできます。
パフォーマンスの最適化は継続的なプロセスであり、1 回限りのアクティビティではありません。次の図は、パフォーマンス最適化プロセスの各ステージを示しています。
パフォーマンス最適化プロセスは継続的なサイクルで、以下のようなステージがあります。
- 要件の定義: アプリケーションを設計・開発する前に、アプリケーション スタックの各レイヤに対して詳細なパフォーマンス要件を定義します。リソース割り当てを計画するには、主なワークロードの特性とパフォーマンスの期待値を考慮します。
- 設計とデプロイ: パフォーマンス要件を満たすうえで役立つ柔軟でスケーラブルな設計パターンを使用します。
- モニタリングと分析: ログ、トレース、指標、アラートを使用してパフォーマンスを継続的にモニタリングします。
最適化: アプリケーションの進化に伴う再設計の可能性を検討します。クラウド リソースを適正サイズに調整し、新しい機能を使用して変化するパフォーマンス要件を満たします。
上の図に示すように、モニタリング、要件の再評価、クラウド リソースの調整のサイクルを継続します。
AI ワークロードと ML ワークロードに固有のパフォーマンス最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: パフォーマンスの最適化をご覧ください。
基本原則
Well-Architected Framework のパフォーマンス最適化の柱における推奨事項は、次の基本原則にマッピングされています。
寄稿者
著者:
- Daniel Lees | クラウド セキュリティ アーキテクト
- Gary Harmson | プリンシパル アーキテクト
- Luis Urena | デベロッパー リレーションズ エンジニア
- Zach Seils | ネットワーキング スペシャリスト
その他の寄稿者:
- Filipe Gracio 博士 | カスタマー エンジニア
- Jose Andrade | エンタープライズ インフラストラクチャ カスタマー エンジニア
- Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
- Marwan Al Shawi | パートナー カスタマー エンジニア
- Nicolas Pintaux | カスタマー エンジニア、アプリケーション モダナイゼーション スペシャリスト
- Ryan Cox | プリンシパル アーキテクト
- Radhika Kanakam | シニア プログラム マネージャー、Cloud GTM
- Samantha He | テクニカル ライター
- Wade Holmes | グローバル ソリューション ディレクター
リソースの割り当てを計画する
Google Cloud Well-Architected Framework のパフォーマンス最適化の柱におけるこの原則では、Google Cloudのワークロードのリソースを計画するうえで役に立つ推奨事項が示されています。クラウドへのデプロイまたは移行用のアプリケーションを設計・開発する前に、詳細な要件を定義することの重要性を強調しています。
原則の概要
ビジネス要件を満たすには、設計・開発の前に、アプリケーションのパフォーマンス要件を定義することが重要です。パフォーマンス要件は、アプリケーション全体とアプリケーション スタックの各レイヤについて、可能な限り詳細に定義します。たとえば、ストレージ レイヤでは、アプリケーションが必要とするスループットと入出力操作毎秒（IOPS）を考慮する必要があります。
最初から、パフォーマンスとスケーラビリティを考慮してアプリケーション設計を計画します。ユーザー数、データ量、時間の経過に伴う増加の可能性などの要素を考慮します。
各ワークロードのパフォーマンス要件は、ワークロードの種類によって異なります。各ワークロードには、固有のパフォーマンス特性を持つコンポーネント システムとサービスを組み合わせることができます。たとえば、大規模なデータセットの定期的なバッチ処理を行うシステムには、インタラクティブな仮想デスクトップ ソリューションとは異なるパフォーマンスの要求があります。最適化戦略は、各ワークロードの固有のニーズに対応する必要があります。
各ワークロードのパフォーマンス目標に沿ったサービスと機能を選択します。パフォーマンスの最適化には、万能のソリューションはありません。各ワークロードを最適化すると、システム全体で最適なパフォーマンスと効率を実現できます。
パフォーマンス要件に影響する可能性がある次のワークロード特性を考慮してください。
- デプロイ アーキタイプ: アプリケーションに対して選択するデプロイ アーキタイプは、プロダクトと機能の選択に影響を与え、アプリケーションから期待できるパフォーマンスを決定します。
- リソースの配置: アプリケーション リソースに Google Cloudリージョンを選択する場合は、エンドユーザーの低レイテンシを優先し、データ ローカリゼーション規制を遵守して、必要な Google Cloud のプロダクトとサービスの可用性を確保することをおすすめします。
- ネットワーク接続: データアクセスとコンテンツ配信を最適化するネットワーク サービスを選択します。 Google Cloudのグローバル ネットワーク、高速バックボーン、相互接続ロケーション、キャッシュ サービスを利用できます。
- アプリケーションのホスティング オプション: ホスティング プラットフォームを選択する際は、各オプションのパフォーマンスに関するメリットとデメリットを評価する必要があります。たとえば、ベアメタル、仮想マシン、コンテナ、サーバーレス プラットフォームについて考えてみましょう。
- ストレージ戦略: パフォーマンス要件に基づいて最適なストレージ戦略を選択します。
- リソース構成: マシンタイプ、IOPS、スループットはパフォーマンスに大きな影響を与える可能性があります。また、設計フェーズの早い段階で、適切なセキュリティ機能とリソースへの影響について検討する必要があります。セキュリティ機能を計画する際は、予期しない影響を回避するために必要なパフォーマンスのトレードオフに対応できるように準備しておきます。
推奨事項
最適なリソース割り当てを確実にするために、以下のセクションの推奨事項を検討してください。
割り当ての構成と管理
アプリケーションがメモリ、ストレージ、処理能力などの必要なリソースのみを使用するようにします。過剰な割り当てを行うと不必要な費用が発生する可能性がありますが、割り当てが不足するとパフォーマンスの低下を招く場合があります。
弾性スケーリングに対応し、十分なリソースを確保できるように、割り当ての容量を定期的にモニタリングします。また、割り当ての使用量を追跡調査して潜在的なスケーリング制約や過剰割り当ての問題を特定し、リソースの割り当てについて十分な情報に基づいた意思決定を行います。
教育と認知度の向上
パフォーマンス要件をユーザーに伝え、効果的なパフォーマンス管理手法に関する教育リソースを提供します。
進捗状況を評価し、改善の余地がある部分を特定するには、目標のパフォーマンスと実際のパフォーマンスを定期的に記録します。アプリケーションの負荷テストを行い、潜在的なブレークポイントを見つけて、アプリケーションをスケーリングする方法を把握します。
パフォーマンス指標をモニタリングする
Cloud Monitoring を使用して、パフォーマンス指標の傾向分析、テストの影響分析、重要な指標に対するアラートの定義、事後分析を行います。
Active Assist は、リソース使用率の最適化に役立つ分析情報と推奨事項を提供できる一連のツールです。これらの推奨事項は、リソースの割り当てを調整してパフォーマンスを向上させるのに役立ちます。
弾力性を活用する
Google Cloud Well-Architected Framework のパフォーマンス最適化の柱におけるこの原則では、ワークロード要件の変化に基づいてリソースを動的に調整できる弾力性を組み込むための推奨事項が示されています。
弾力性により、システムのさまざまなコンポーネントを個別にスケーリングできます。このような対象を絞ったスケーリングにより、リソースのプロビジョニングで過不足なく必要な場所にリソースを正確に割り当てることで、パフォーマンスを向上させ、費用対効果を高めることができます。
原則の概要
システムのパフォーマンス要件は、システムの垂直スケーリングと水平スケーリングのタイミングと方法に直接影響します。システムの容量を評価し、ベースラインでシステムが処理すると想定される負荷を決定する必要があります。次に、負荷の増減にシステムがどのように対応するかを決定する必要があります。
負荷が増加する場合、システムは水平方向にスケールアウトするか、垂直方向にスケールアップするか、あるいはその両方を行う必要があります。水平方向のスケーリングの場合は、レプリカノードを追加して、システム全体に増加した需要を満たすのに十分な容量があることを確認します。垂直方向のスケーリングの場合は、アプリケーションの既存のコンポーネントを、容量、メモリ、ストレージがより大きいコンポーネントに置き換えます。
負荷が減少すると、システムは（水平方向、垂直方向、またはその両方で）スケールダウンする必要があります。
システムがスケールアップまたはスケールダウンする状況を定義します。トラフィックの増加が予想される期間には、システムを手動でスケールアップする計画を立てます。負荷の増減に対応する自動スケーリングなどのツールを使用します。
推奨事項
弾力性を活用するには、以下のセクションの推奨事項を検討してください。
ピーク負荷期間に備えて計画する
顧客の需要の増加が予想される期間など、既知のイベントに対して効率的なスケーリング パスを計画する必要があります。
トラフィックの増加が予想される期間に先立って、システムのスケールアップを検討してください。たとえば、小売業であれば、季節ごとのセール中に需要が増加することが予想されます。そうしたセールの前にシステムを手動でスケールアップまたはスケールアウトして、システムが負荷の増加に即座に対応できるようにするか、既存の上限を直接調整することをおすすめします。そうしなければ、リアルタイムの変更に応じてリソースを追加するまでに数分かかることがあります。アプリケーションの容量がすぐには増加せず、一部のユーザーで遅延が発生する場合があります。
需要やトラフィックの急増といった未知のイベントや予期しないイベントに対しては、自動スケーリング機能を使用すると、指標に基づいて弾力的なスケーリングをトリガーできます。このような指標としては、CPU 使用率、ロードバランサの処理能力、レイテンシ、Cloud Monitoring で定義したカスタム指標などがあります。
たとえば、Compute Engine マネージド インスタンス グループ（MIG）で実行されるアプリケーションを考えてみましょう。このアプリケーションには、平均 CPU 使用率が 75% に達するまで各インスタンスが最適に動作するという要件があります。この例では、CPU 使用率がしきい値に達するとインスタンスをさらに作成する自動スケーリング ポリシーを定義します。新しく作成されたインスタンスが負荷の吸収を助け、MIG に構成されたインスタンスの最大数に達するまで、平均 CPU 使用率が最適なレートで維持されます。需要が減少すると、自動スケーリング ポリシーによって不要になったインスタンスが削除されます。
BigQuery のリソース スロット予約を計画するか、マネージド オートスケーラーを使用して Spanner の自動スケーリング構成の上限を調整します。
予測スケーリングを使用する
システム コンポーネントに Compute Engine が含まれている場合は、予測自動スケーリングがワークロードに適しているかどうかを評価する必要があります。予測自動スケーリングは、指標の過去のトレンド（CPU 使用率など）に基づいて将来の負荷を予測します。予測は数分ごとに再計算されるため、オートスケーラーは予測を直近の負荷の変化にすばやく適応できます。予測自動スケーリングがなければ、オートスケーラーは、リアルタイムで観測された負荷の変化に基づいて受動的にグループをスケーリングすることしかできません。予測自動スケーリングは、リアルタイム データと過去のデータの両方を使用して、現在の負荷と予測される負荷の両方に対応します。
サーバーレス アーキテクチャを実装する
以下のような、本質的に弾力性のあるサーバーレス サービスを使用して、サーバーレス アーキテクチャを実装することを検討してください。
ルールのファインチューニングが必要な他のサービスの自動スケーリング（Compute Engine など）とは異なり、サーバーレス自動スケーリングは即時実行され、リソースをゼロまでスケールダウンできます。
Kubernetes の Autopilot モードを使用する
Kubernetes をより大きく制御する必要がある複雑なアプリケーションの場合は、Google Kubernetes Engine（GKE）の Autopilot モードを検討してください。Autopilot モードでは、デフォルトで自動化とスケーラビリティが提供されます。GKE は、トラフィックに基づいてノードとリソースを自動的にスケーリングします。GKE はノードの管理、アプリケーション用の新しいノードの作成、自動的なアップグレードと修復の構成を行います。
モジュラー設計を推進する
Google Cloud Well-Architected Framework のパフォーマンス最適化の柱におけるこの原則では、モジュラー設計を促進するうえで役に立つ推奨事項が示されています。モジュラー コンポーネントと明確なインターフェースにより、柔軟なスケーリング、独立した更新、将来のコンポーネント分離が可能になります。
原則の概要
アプリケーション コンポーネントとシステム コンポーネントの依存関係を理解して、スケーラブルなシステムを設計します。
モジュラー設計を採用すると、最初にモノリシック アーキテクチャとマイクロサービス アーキテクチャのどちらがデプロイされたかにかかわらず、柔軟性と復元力が実現されます。明確なインターフェースを備え、明確に定義された独立したモジュールにシステムを分解することで、特定の需要に合わせて個々のコンポーネントをスケーリングできます。
対象を絞ったスケーリングを使用すると、以下のような方法でリソース使用率を最適化し、費用を削減できます。
- 各コンポーネントに必要なリソースのみをプロビジョニングし、需要の少ないコンポーネントには少ないリソースを割り当てます。
- トラフィックの増加時にはリソースを追加して、ユーザー エクスペリエンスを維持します。
- パフォーマンスを損なうことなく、使用率の低いリソースを削除します。
モジュール化により、メンテナンス性も向上します。小規模で自己完結型のユニットは、理解、デバッグ、更新が容易であるため、開発サイクルの短縮とリスクの低減につながります。
モジュール化には大きなメリットがありますが、潜在的なパフォーマンスのトレードオフを評価する必要があります。モジュール間の通信が増えると、レイテンシとオーバーヘッドが発生する可能性があります。モジュール化とパフォーマンスのバランスをとるよう努力します。高度なモジュラー設計が、例外なく適しているわけではありません。パフォーマンスが重要である場合は、より緊密に結合されたアプローチが適している場合があります。システム設計は反復的なプロセスであり、モジュラー設計を継続的に見直して改良します。
推奨事項
モジュラー設計を推進するには、以下のセクションの推奨事項を検討してください。
疎結合となるように設計する
疎結合アーキテクチャを設計します。依存関係を最小限に抑えた独立したコンポーネントを使用すると、スケーラブルで復元力のあるアプリケーションを構築するうえで役立ちます。サービスの境界を計画する際は、可用性とスケーラビリティの要件を考慮する必要があります。たとえば、1 つのコンポーネントの要件が他のコンポーネントと異なる場合は、そのコンポーネントをスタンドアロン サービスとして設計できます。プライマリ サービスの応答時間に影響しない、重要度の低いサブプロセスやサービスの正常な障害の計画を実装します。
同時実行と並列処理を考慮した設計
複数のタスクを同時にサポートするようにアプリケーションを設計します。たとえば、複数のユーザー リクエストの処理や、ユーザーがシステムを操作している間のバックグラウンド ジョブの実行などです。大きなタスクを、複数のサービス インスタンスで同時に処理できる小さなチャンクに分割します。タスクの同時実行を使用すると、自動スケーリングなどの機能を使用して、以下のようなプロダクトのリソース割り当てを増やすことができます。
モジュール化をバランスよく配置して柔軟なリソース割り当てを実現する
可能であれば、各コンポーネントが特定のオペレーションに必要なリソース（メモリ、ストレージ、処理能力など）のみを使用するようにします。リソース割り当てが過剰になると不必要な費用が発生する可能性がある一方で、リソース割り当てが不足するとパフォーマンスが低下する可能性があります。
明確に定義されたインターフェースを使用する
モジュール式のコンポーネントは明確で標準化されたインターフェース（API やメッセージ キューなど）を介して効率的に通信し、変換レイヤや余計なトラフィックによるオーバーヘッドを削減します。
ステートレス モデルを使用する
ステートレス モデルを使用すると、各リクエストやサービスとのやり取りをこれまでのリクエストとは独立して処理できるようになります。このモデルでは、進行中のリクエストやプロセスに必要なデータを失うことなく、サービスを拡大、縮小、再起動できるため、スケーラビリティと復元性が向上します。
補完的なテクノロジーを選択する
モジュラー設計を補完するテクノロジーを選択します。モジュール化のサポートについて、プログラミング言語、フレームワーク、データベースを評価します。
詳しくは、次のリソースをご覧ください。
パフォーマンスを継続的にモニタリングして改善する
Google Cloud Well-Architected Framework のパフォーマンス最適化の柱におけるこの原則では、パフォーマンスを継続的にモニタリングして改善するうえで役に立つ推奨事項が示されています。
アプリケーションをデプロイした後、ログ、トレース、指標、アラートを使用してパフォーマンスを継続的にモニタリングします。アプリケーションが成長し、進化するにつれて、これらのデータポイントのトレンドを使用して、パフォーマンス要件を再評価できます。パフォーマンスを維持または改善するために、いずれはアプリケーションの一部を再設計する必要が生じる場合があります。
原則の概要
パフォーマンスを継続的に改善するには、安定しているモニタリング ツールと戦略が必要です。Cloud オブザーバビリティ ツールを使用すると、レイテンシ、スループット、エラー率、リソース使用率などの主要パフォーマンス指標（KPI）を収集できます。クラウド環境では、アプリケーション、ネットワーク、エンドユーザー エクスペリエンスで詳細なパフォーマンス評価を行うさまざまな方法が用意されています。
パフォーマンスの向上は、多角的なアプローチを必要とする継続的な取り組みです。パフォーマンスの向上に役立つ主要なメカニズムとプロセスは以下のとおりです。
- 明確な方向性を示し、進捗状況をトラッキングできるように、ビジネス目標に沿ったパフォーマンス目標を定義します。具体的で（specific）、測定可能な（measurable）、達成可能な（achievable）、現実の問題に直結する（relevant）、期限付き（time-bound）の SMART 目標を設定します。
- パフォーマンスを測定して改善が必要な領域を特定するために、KPI 指標を収集します。
- システムの問題を継続的にモニタリングするために、モニタリング ツールで可視化されたワークフローを使用します。アーキテクチャ プロセスのマッピング手法を使用して、冗長性と非効率性を特定します。
- 継続的な改善の文化を構築するために、従業員の成長をサポートするトレーニングとプログラムを用意します。
- 積極的で継続的な改善を促すために、社員と顧客にインセンティブを与えて、アプリケーションのパフォーマンスに関するフィードバックを継続的に提供してもらいます。
推奨事項
モジュラー設計を推進するには、以下のセクションの推奨事項を検討してください。
明確なパフォーマンスの目標と指標を定義する
ビジネスの目標に沿った明確なパフォーマンス目標を定義します。これには、アプリケーションのアーキテクチャと各アプリケーション コンポーネントのパフォーマンス要件を深く理解する必要があります。
コアビジネス機能とユーザー エクスペリエンスに直接影響する最も重要なコンポーネントを優先的に最適化します。これらのコンポーネントが引き続き効率的に実行され、ビジネスニーズを確実に満たせるように、具体的で測定可能なパフォーマンス目標を設定します。パフォーマンス目標としては、レスポンス時間、エラー率、リソース使用率のしきい値などがあります。
この事前対応型のアプローチにより、潜在的なボトルネックを特定して対処し、リソースの割り当てを最適化することが可能になり、最終的にはユーザーにシームレスで高パフォーマンスのエクスペリエンスを提供できます。
パフォーマンスの追跡
クラウド システムのパフォーマンスの問題を継続的にモニタリングし、潜在的な問題に対してアラートを設定します。モニタリングとアラートを使用すると、ユーザーに影響が及ぶ前に問題を検出して修正することが可能となります。アプリケーション プロファイリングは、ボトルネックの特定とリソース使用量の最適化を行ううえで役立ちます。
効果的なトラブルシューティングとネットワークの最適化を容易にするツールを使用できます。Google Cloud Observability を使用して、CPU 使用量、メモリ使用量、ネットワーク使用量が多い領域を特定します。これらの機能は、デベロッパーが効率を高め、費用を削減し、ユーザー エクスペリエンスを向上させるのに役立ちます。Network Intelligence Center は、ネットワーク インフラストラクチャのトポロジを可視化し、レイテンシの大きいパスを特定するのに役立ちます。
継続的な改善を奨励する
アプリケーションとユーザー エクスペリエンスの両方にメリットをもたらす継続的な改善の文化を構築します。
クラウド サービスにおけるパフォーマンス手法に関するスキルと知識を向上させるトレーニングと開発の機会を従業員に提供します。実践共同体（CoP）を設立し、メンタリングとコーチングのプログラムを提供して、従業員の成長を支援します。
パフォーマンス管理を事後対応型ではなく事前対応型にするために、従業員、顧客、関係者からの継続的なフィードバックを奨励します。パフォーマンスに関する KPI を追跡調査し、これらの指標をリーグ表の形式でチームに頻繁に提示することで、プロセスをゲーム化する方法を検討できます。
パフォーマンスとユーザーの満足度を長期的に把握するために、ユーザー フィードバックを定量的かつ定性的に測定することをおすすめします。HEART フレームワークを使用すると、次の 5 つのカテゴリにわたってユーザーからのフィードバックを収集できます。
- 満足度
- エンゲージメント
- 導入
- リテンション
- タスク成功
このようなフレームワークを使用すると、データドリブンのフィードバック、ユーザー中心の指標、行動につながるインサイト、目標の明確な理解によってエンジニアを動機付けることができます。