Google Cloud Well-Architected フレームワークのこの柱では、Google Cloudのワークロードのパフォーマンスを最適化するための推奨事項について説明します。
このドキュメントは、 Google Cloudでワークロードの計画、設計、デプロイ、管理を行うアーキテクト、デベロッパー、管理者を対象としています。
この柱の推奨事項は、組織の効率的な運用、顧客満足度の向上、収益の向上、費用の削減に役立ちます。たとえば、アプリケーションのバックエンド処理時間が短くなると、レスポンス時間が短くなり、ユーザー維持率の向上と収益の増加につながります。
パフォーマンスの最適化プロセスでは、パフォーマンスと費用のトレードオフが発生する可能性があります。ただし、パフォーマンスを最適化することで費用を削減できる場合もあります。たとえば、負荷が増加すると、自動スケーリングによってシステム リソースが過負荷にならないようにすることで、予測可能なパフォーマンスを提供できます。また、自動スケーリングにより、負荷が低い期間に未使用のリソースを削除することで、費用を削減することもできます。
パフォーマンスの最適化は継続的なプロセスであり、1 回限りのアクティビティではありません。次の図は、パフォーマンス最適化プロセスの各ステージを示しています。
パフォーマンス最適化プロセスは、次のステージを含む継続的なサイクルです。
- 要件を定義する: アプリケーションを設計して開発する前に、アプリケーション スタックの各レイヤの詳細なパフォーマンス要件を定義します。リソース割り当てを計画するには、主なワークロードの特性とパフォーマンスの期待値を考慮します。
- 設計とデプロイ: パフォーマンス要件を満たすことに役立つ柔軟でスケーラブルな設計パターンを使用します。
- モニタリングと分析: ログ、トレース、指標、アラートを使用してパフォーマンスを継続的にモニタリングします。
最適化: アプリケーションの進化に伴う再設計を検討します。クラウド リソースを適正サイズに調整し、新しい機能を使用して、変化するパフォーマンス要件を満たします。
上の図に示すように、モニタリング、要件の再評価、クラウド リソースの調整のサイクルを継続します。
AI ワークロードと ML ワークロードに固有のパフォーマンス最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: パフォーマンス最適化をご覧ください。
基本原則
Well-Architected フレームワークのパフォーマンス最適化の柱の推奨事項は、次のコア原則にマッピングされています。
寄稿者
著者:
- 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
- Wade Holmes | グローバル ソリューション ディレクター
リソースの割り当てを計画する
Google Cloud Well-Architected Framework のパフォーマンス最適化の柱にこの原則では、Google Cloudのワークロードのリソースを計画するための推奨事項が示されています。クラウドへのデプロイまたは移行用のアプリケーションを設計して開発する前に、詳細な要件を定義することの重要性を強調しています。
原則の概要
ビジネス要件を満たすには、設計と開発の前に、アプリケーションのパフォーマンス要件を定義することが重要です。これらの要件は、アプリケーション全体とアプリケーション スタックの各レイヤについて、可能な限り詳細に定義します。たとえば、ストレージ レイヤでは、アプリケーションが必要とするスループットと 1 秒あたりの I/O オペレーション（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）を収集できます。クラウド環境では、アプリケーション、ネットワーク、エンドユーザー エクスペリエンス全体で詳細なパフォーマンス評価を行うさまざまな方法が用意されています。
パフォーマンスの向上は継続的な取り組みであり、多面的なアプローチが必要です。パフォーマンスを向上させるには、次の主要なメカニズムとプロセスが役立ちます。
- 明確な指針を示し、進捗状況をトラッキングできるように、ビジネス目標に沿ったパフォーマンス目標を定義します。具体的、測定可能、達成可能、関連性があり、期限が設定された SMART 目標を設定します。
- パフォーマンスを測定し、改善すべき領域を特定するには、KPI 指標を収集します。
- システムの問題を継続的にモニタリングするには、モニタリング ツールで可視化されたワークフローを使用します。アーキテクチャ プロセスのマッピング手法を使用して、冗長性と非効率性を特定します。
- 継続的な改善の文化を構築するには、従業員の成長をサポートするトレーニングとプログラムを提供します。
- 事前対応型の継続的な改善を促すには、社員とユーザーに、アプリケーションのパフォーマンスに関するフィードバックを継続的に提供するようインセンティブを与えます。
推奨事項
モジュラー設計を推進するには、次のセクションの推奨事項を検討してください。
明確なパフォーマンス目標と指標を定義する
ビジネス目標に沿った明確なパフォーマンス目標を定義します。これには、アプリケーションのアーキテクチャと各アプリケーション コンポーネントのパフォーマンス要件を深く理解する必要があります。
優先的に、コア ビジネス機能とユーザー エクスペリエンスに直接影響する最も重要なコンポーネントを最適化します。これらのコンポーネントが引き続き効率的に実行され、ビジネスニーズを満たせるように、具体的で測定可能なパフォーマンス目標を設定します。これらのターゲットには、レスポンス時間、エラー率、リソース使用率のしきい値などがあります。
この事前対応型のアプローチにより、潜在的なボトルネックを特定して対処し、リソースの割り当てを最適化して、最終的にはユーザーにシームレスで高パフォーマンスのエクスペリエンスを提供できます。
パフォーマンスの追跡
クラウド システムのパフォーマンスの問題を継続的にモニタリングし、潜在的な問題のアラートを設定します。モニタリングとアラートを使用すると、ユーザーに影響する前に問題を検出して修正できます。アプリケーション プロファイリングは、ボトルネックの特定とリソース使用量の最適化に役立ちます。
効果的なトラブルシューティングとネットワークの最適化を容易にするツールを使用できます。Google Cloud Observability を使用して、CPU 使用量、メモリ使用量、ネットワーク使用量が多い領域を特定します。これらの機能は、デベロッパーが効率を高め、費用を削減し、ユーザー エクスペリエンスを向上させるのに役立ちます。Network Intelligence Center は、ネットワーク インフラストラクチャのトポロジを可視化し、レイテンシの高いパスを特定するのに役立ちます。
継続的な改善を奨励する
アプリケーションとユーザー エクスペリエンスの両方にメリットをもたらす継続的な改善の文化を構築します。
クラウド サービス全体のパフォーマンス手法に関するスキルと知識を向上させるトレーニングと開発の機会を従業員に提供します。コミュニティ オブ プラクティス（CoP）を設立し、メンタリング プログラムとコーチング プログラムを提供して、社員の成長をサポートします。
パフォーマンス管理を事後対応型ではなく、事前対応型にするには、社員、顧客、関係者からの継続的なフィードバックを奨励します。パフォーマンスに関する KPI を追跡し、リーグ表の形式でこれらの指標をチームに頻繁に提示することで、プロセスをゲーム化する方法を検討できます。
パフォーマンスとユーザーの満足度を経時的に把握するには、ユーザー フィードバックを定量的かつ定性的に測定することをおすすめします。HEART フレームワークを使用すると、次の 5 つのカテゴリにわたるユーザー フィードバックを収集できます。
- 満足度
- エンゲージメント
- 導入
- リテンション
- タスク成功
このようなフレームワークを使用すると、データドリブンのフィードバック、ユーザー中心の指標、実用的な分析情報、目標の明確な理解によってエンジニアを動機付けることができます。