リソース使用量を最適化する

Last reviewed 2024-09-25 UTC

Google Cloud アーキテクチャ フレームワークの費用最適化の柱にこの原則では、クラウド ワークロードの要件と使用パターンに合わせてリソースを計画してプロビジョニングするための推奨事項が示されています。

原則の概要

クラウド リソースの費用を最適化するには、ワークロードのリソース要件と負荷パターンを十分に理解する必要があります。この理解は、総所有コスト(TCO)を予測し、クラウド導入の過程で費用の要因を特定できる、明確に定義された費用モデルの基礎となります。クラウドの費用を事前に分析して予測することで、リソースのプロビジョニング、使用率、費用の最適化について十分な情報に基づいて選択できます。このアプローチにより、クラウドの費用を管理し、過剰なプロビジョニングを回避し、クラウド リソースをワークロードと環境の動的なニーズに合わせて調整できます。

推奨事項

クラウド リソースの使用を効果的に最適化するには、次の推奨事項を検討してください。

環境固有のリソースを選択する

デプロイ環境ごとに、可用性、信頼性、スケーラビリティの要件は異なります。たとえば、デベロッパーは、アプリケーションを迅速にデプロイして短時間実行できる環境を好む場合がありますが、高可用性は必要としない場合があります。一方、本番環境では通常、高可用性が必要です。リソースの使用率を最大化するには、ビジネスニーズに基づいて環境固有の要件を定義します。次の表に、環境固有の要件の例を示します。

環境 要件
本番環境
  • 高可用性
  • 予測可能なパフォーマンス
  • 運用の安定性
  • 堅牢なリソースによるセキュリティ
開発とテスト
  • 費用対効果
  • バースト容量を備えた柔軟なインフラストラクチャ
  • データの永続性が不要な場合のエフェメラル インフラストラクチャ
その他の環境(ステージング環境や QA 環境など)
  • 環境固有の要件に基づくカスタマイズされたリソース割り当て

ワークロード固有のリソースを選択する

クラウド ワークロードごとに、可用性、スケーラビリティ、セキュリティ、パフォーマンスの要件が異なる場合があります。費用を最適化するには、リソースの選択を各ワークロードの特定の要件に合わせて調整する必要があります。たとえば、ステートレス アプリケーションでは、ステートフル バックエンドと同じレベルの可用性や信頼性が要求されない場合があります。次の表に、ワークロード固有の要件の例を示します。

ワークロード タイプ ワークロードの要件 リソース オプション
ミッション クリティカル 継続的な可用性、堅牢なセキュリティ、高パフォーマンス 高可用性とデータのグローバルな整合性を確保するためのプレミアム リソースとマネージド サービス(Spanner など)。
重要でない 費用対効果の高い自動スケーリング インフラストラクチャ 基本機能を持つリソースと、Spot VM などのエフェメラル リソース。
イベント ドリブン 容量とパフォーマンスの現在の需要に基づく動的スケーリング Cloud RunCloud Run functions などのサーバーレス サービス。
試験運用版ワークロード 迅速な開発、反復処理、テスト、イノベーションのための低コストで柔軟な環境 基本機能を持つリソース、Spot VM などのエフェメラル リソース、費用の上限が定義されたサンドボックス環境。

クラウドのメリットは、特定のワークロードに最も適したコンピューティング能力を利用できることです。一部のワークロードはプロセッサ インストラクション セットを活用するように開発されていますが、そうでないワークロードもあります。それに応じてワークロードをベンチマークしてプロファイリングします。ワークロードを分類し、ワークロード固有のリソースを選択します(Compute Engine VM に適したマシン ファミリーを選択します)。この方法は、コストの最適化、イノベーションの実現、ワークロードに必要な可用性とパフォーマンスのレベルの維持に役立ちます。

この推奨事項を実装する方法の例を次に示します。

  • グローバルに分散したユーザーにサービスを提供するミッション クリティカルなワークロードの場合は、Spanner の使用を検討してください。Spanner は、すべてのリージョンでデータの信頼性と整合性を確保することで、複雑なデータベースのデプロイを不要にします。
  • 負荷レベルが変動するワークロードの場合は、自動スケーリングを使用して、負荷が低いときに費用が発生しないようにし、現在の負荷に対応するのに十分な容量を維持します。Compute Engine VMGoogle Kubernetes Engine(GKE)クラスタCloud Run など、多くの Google Cloud サービスで自動スケーリングを構成できます。オートスケーリングを設定するときに、最大スケーリングの上限を構成して、費用が指定した予算内に収まるようにすることができます。

費用の要件に基づいてリージョンを選択する

クラウド ワークロードの場合は、利用可能な Google Cloud リージョンを慎重に評価し、費用目標に合ったリージョンを選択します。費用が最も低いリージョンが、最適なレイテンシを提供していない場合や、持続可能性の要件を満たしていない場合があります。ワークロードをデプロイする場所について十分な情報に基づいて判断し、望ましいバランスを実現します。Google Cloud リージョン選択ツールを使用すると、費用、持続可能性、レイテンシなどの要素のトレードオフを把握できます。

組み込みの費用最適化オプションを使用する

Google Cloud プロダクトには、リソース使用量を最適化し、費用を管理するための組み込み機能が用意されています。次の表に、一部の Google Cloud プロダクトで使用できる費用最適化機能の例を示します。

製品 費用の最適化機能
Compute Engine
  • 自動スケーリングを使用して、現在の負荷に基づいて VM を自動的に追加または削除します。
  • カスタム マシンタイプを作成して使用することで、オーバープロビジョニングを回避する
  • ワークロードの要件を満たす
  • 重要でないワークロードやフォールト トレラントなワークロードの場合は、Spot VM を使用して費用を削減します。
  • 開発環境では、VM の実行時間を制限するか、VM が不要な場合は一時停止または停止することで、費用を削減します。
GKE
Cloud Storage
  • オブジェクトのライフサイクル管理を使用して、データの経過時間やアクセス パターンに基づいて、データを低コストのストレージ クラスに自動的に移行します。
  • Autoclass を使用して、使用パターンに基づいて最も費用対効果の高いストレージ クラスにデータを動的に移動します。
BigQuery
  • 容量ベースの料金を使用して、安定状態のワークロードのクエリ処理費用を削減します。
  • パーティショニングとクラスタリングの手法を使用して、クエリのパフォーマンスと費用を最適化します。
Google Cloud VMware Engine
  • CUD、ストレージ使用量の最適化、ESXi クラスタのサイズの適正化などの費用最適化戦略を使用して、VMware の費用を削減します。

リソース共有を最適化する

クラウド リソースの使用率を最大化するには、アプリケーションのセキュリティなどの要件を満たしながら、同じインフラストラクチャに複数のアプリケーションまたはサービスをデプロイします。たとえば、開発環境とテスト環境では、同じクラウド インフラストラクチャを使用してアプリケーションのすべてのコンポーネントをテストできます。本番環境では、各コンポーネントを個別のリソースセットにデプロイして、インシデントが発生した場合の影響範囲を制限できます。

この推奨事項を実装する方法の例を次に示します。

  • 複数の非本番環境に単一の Cloud SQL インスタンスを使用する。
  • 適切なアクセス制御を使用して GKE Enterprise のフリート チーム管理機能を使用すると、複数の開発チームが GKE クラスタを共有できます。
  • GKE Autopilot を使用して、GKE がデフォルトで実装するビンパッキングや自動スケーリングなどの費用最適化手法を利用します。
  • AI ワークロードと ML ワークロードの場合は、マルチインスタンス GPU、タイム シェアリング GPU、NVIDIA MPS などのGPU 共有戦略を使用して GPU 費用を節約します。

リファレンス アーキテクチャを開発して維持する

さまざまなデプロイ環境とワークロード タイプの要件を満たすように調整されたリファレンス アーキテクチャのリポジトリを作成して維持します。個々のプロジェクトの設計と実装プロセスを効率化するために、Cloud Center of Excellence(CCoE)などのチームによってブループリントを一元的に管理できます。プロジェクト チームは、明確に定義された基準に基づいて適切なブループリントを選択することで、アーキテクチャの整合性を確保し、ベスト プラクティスを採用できます。プロジェクトに固有の要件については、プロジェクト チームと中央アーキテクチャ チームが協力して新しいリファレンス アーキテクチャを設計する必要があります。リファレンス アーキテクチャを組織全体で共有することで、ナレッジ共有を促進し、利用可能なソリューションのリポジトリを拡張できます。このアプローチにより、一貫性が確保され、開発が加速し、意思決定が簡素化され、リソースの効率的な使用が促進されます。

さまざまなユースケースとテクノロジーについて、Google が提供するリファレンス アーキテクチャを確認します。これらのリファレンス アーキテクチャには、リソースの選択、サイズ設定、構成、デプロイに関するベスト プラクティスが組み込まれています。これらのリファレンス アーキテクチャを使用すると、開発プロセスを加速し、最初から費用を節約できます。

組織のポリシーを使用して費用の管理を強化する

組織のポリシーを使用して、チームメンバーが使用できる Google Cloud のロケーションとプロダクトを制限することを検討してください。これらのポリシーは、チームが費用対効果の高いソリューションに準拠し、費用の最適化目標に沿ってロケーションにリソースをプロビジョニングできるようにします。

現実的な予算を見積もる、予算の上限を設定する

各プロジェクト、ワークロード、デプロイ環境の詳細な予算を策定します。予算には、インフラストラクチャの費用、ソフトウェア ライセンス、人員、予想される成長など、クラウド運用のすべての側面が含まれていることを確認してください。費用超過を防ぎ、財務目標との整合性を確保するには、プロジェクト、サービス、または特定のリソースに明確な費用上限またはしきい値を設定します。これらの上限に対してクラウド費用を定期的にモニタリングします。事前割り当てアラートを使用すると、費用超過の可能性を早期に特定し、タイムリーに是正措置を講じることができます。

予算を設定するだけでなく、割り当てと上限を使用して、費用の抑制を強化し、予期しない支出の急増を防ぐこともできます。プロジェクト、サービス、特定のリソースタイプなど、さまざまなレベルで割り当てを設定することで、リソース使用量をきめ細かく制御できます。

この推奨事項を実装する方法の例を次に示します。

  • プロジェクト レベルの割り当て: プロジェクト レベルで費用の上限またはリソース割り当てを設定して、全体的な費用の範囲を確立し、プロジェクト内のすべてのサービスでリソースの使用量を制御します。
  • サービス固有の割り当て: Compute Engine や BigQuery などの特定の Google Cloud サービスに割り当てを構成して、プロビジョニングできるインスタンス数、CPU、ストレージ容量を制限します。
  • リソースタイプ固有の割り当て: Compute Engine VM、Cloud Storage バケット、Cloud Run インスタンス、GKE ノードなどの個々のリソースタイプに割り当てを適用して、使用量を制限し、予期しない費用超過を防ぎます。
  • 割り当てアラート: 割り当て使用量(プロジェクト レベル)が最大値の割合に達したときに通知を受け取ります。

割り当てと上限を予算編成とモニタリングと組み合わせて使用することで、費用管理に対するプロアクティブで多層的なアプローチを構築できます。このアプローチにより、クラウドの費用が定義された境界内に収まり、ビジネス目標に沿って維持されます。これらの費用管理は永続的なものではなく、厳格なものでもありません。コスト管理が最新の業界基準に沿って維持され、変化するビジネスニーズを反映するようにするには、管理を定期的に確認し、新しいテクノロジーとベスト プラクティスを組み込むように調整する必要があります。