Google Cloud Well-Architected Framework の費用最適化の柱におけるこの原則では、クラウド ワークロードの要件と消費パターンに合わせてリソースを計画してプロビジョニングするための推奨事項が示されています。
原則の概要
クラウド リソースの費用を最適化するには、ワークロードのリソース要件と負荷パターンを十分に理解する必要があります。この理解は、総所有コスト（TCO）を予測し、クラウド導入の過程全体で費用要因を特定できる、明確に定義された費用モデルの基礎となります。クラウド支出を事前に分析して予測することで、リソースのプロビジョニング、使用率、費用の最適化について、十分な情報に基づいた選択を行うことができます。このアプローチにより、クラウド支出を管理し、過剰なプロビジョニングを回避して、クラウド リソースをワークロードと環境の動的なニーズに合わせることができます。
推奨事項
クラウド リソースの使用量を効果的に最適化するには、次の推奨事項を検討してください。
環境固有のリソースを選択する
デプロイ環境ごとに、可用性、信頼性、スケーラビリティの要件が異なります。たとえば、デベロッパーは、アプリケーションを短時間でデプロイして実行できる環境を好むかもしれませんが、高可用性は必要ないかもしれません。一方、本番環境では通常、高可用性が必要です。リソースの使用率を最大化するには、ビジネスニーズに基づいて環境固有の要件を定義します。環境固有の要件の例を次に示します。
- プロダクション: 堅牢なリソースによる高可用性、予測可能なパフォーマンス、運用の安定性、セキュリティ。
- 開発とテスト: 費用対効果、バースト可能容量を備えた柔軟なインフラストラクチャ、データの永続性が必要ない場合のエフェメラル インフラストラクチャ。
- その他の環境（ステージングや QA など）: 環境固有の要件に基づいてリソースを割り当てます。
ワークロード固有のリソースを選択する
クラウド ワークロードごとに、可用性、スケーラビリティ、セキュリティ、パフォーマンスの要件が異なる場合があります。費用を最適化するには、各ワークロードの特定の要件に合わせてリソースを選択する必要があります。たとえば、ステートレス アプリケーションでは、ステートフル バックエンドと同じレベルの可用性や信頼性は必要ない場合があります。以降のサブセクションでは、ワークロード固有の要件の例をさらに紹介します。
ミッション クリティカルなワークロード
- ワークロードの要件: 継続的な可用性、堅牢なセキュリティ、高パフォーマンス。
- リソース オプション: データの高可用性とグローバル整合性を実現する Spanner などのプレミアム リソースとマネージド サービス。
重要度の低いワークロード
- ワークロードの要件: 費用対効果が高く、自動スケーリングが可能なインフラストラクチャ。
- リソース オプション: 基本機能を備えたリソースと、Spot VM などのエフェメラル リソース。
イベント ドリブン ワークロード
- ワークロードの要件: 容量とパフォーマンスの現在の需要に基づく動的スケーリング。
- リソース オプション: Cloud Run や Cloud Run functions などのサーバーレス サービス。
試験運用版のワークロード
- ワークロードの要件: 迅速な開発、イテレーション、テスト、イノベーションのための低コストで柔軟な環境。
- リソース オプション: 基本機能を備えたリソース、Spot VM などのエフェメラル リソース、費用上限が定義されたサンドボックス環境。
クラウドのメリットは、特定のワークロードに最適なコンピューティング能力を活用できることです。ワークロードによっては、プロセッサ命令セットを利用するように開発されているものもあれば、そうでないものもあります。ワークロードのベンチマークとプロファイリングを適宜行います。ワークロードを分類し、ワークロード固有のリソースを選択します（たとえば、Compute Engine VM に適したマシン ファミリーを選択します）。このプラクティスは、コストの最適化、イノベーションの促進、ワークロードに必要な可用性とパフォーマンスの維持に役立ちます。
この推奨事項を実装する方法の例を次に示します。
- グローバルに分散したユーザーにサービスを提供するミッション クリティカルなワークロードの場合は、Spanner の使用を検討してください。Spanner では、すべてのリージョンでデータの信頼性と整合性が確保されるため、複雑なデータベースをデプロイする必要がありません。
- 負荷レベルが変動するワークロードの場合は、自動スケーリングを使用して、負荷が低いときに費用が発生しないようにし、現在の負荷を満たすのに十分な容量を維持します。Compute Engine VM、Google Kubernetes Engine（GKE）クラスタ、Cloud Run など、多くのGoogle Cloud サービスに自動スケーリングを構成できます。自動スケーリングを設定するときに、最大スケーリングの上限を構成して、費用が指定された予算内に収まるようにできます。
コスト要件に基づいてリージョンを選択する
クラウド ワークロードについては、利用可能な Google Cloudリージョンを慎重に評価し、費用の目標に沿ったリージョンを選択します。最も費用が低いリージョンでは、最適なレイテンシが提供されない、またはサステナビリティ要件を満たさない可能性があります。ワークロードをデプロイする場所について十分な情報に基づいて意思決定し、望ましいバランスを実現します。Google Cloud リージョン選択ツールを使用すると、費用、サステナビリティ、レイテンシなどの要因間のトレードオフを把握できます。
組み込みの費用最適化オプションを使用する
Google Cloud プロダクトには、リソース使用量の最適化と費用の管理に役立つ組み込み機能が用意されています。一部の Google Cloud プロダクトで使用できる費用最適化機能の例を次に示します。
- Compute Engine
- 自動スケーリングを使用して、現在の負荷に基づいて VM を自動的に追加または削除する。
- ワークロードの要件に一致するカスタム マシンタイプを作成して使用することで、オーバープロビジョニングを回避します。
- 重要度の低いワークロードやフォールト トレラントなワークロードの場合は、Spot VM を使用してコストを削減します。
- 開発環境では、VM の実行時間を制限するか、不要な VM を一時停止または停止することで、費用を削減します。
- GKE
- クラスタ オートスケーラーを使用して、現在の負荷に基づいて GKE クラスタのサイズを自動調整します。
- ワークロードの要件に基づいてノードプールを自動的に作成して管理し、ノード自動プロビジョニングを使用してリソース使用率を最適化します。
- Cloud Storage
- オブジェクトのライフサイクル管理を使用して、データの経過時間またはアクセス パターンに基づいて、データを低コストのストレージ クラスに自動的に移行します。
- Autoclass を使用して、使用パターンに基づいて最も費用対効果の高いストレージ クラスにデータを動的に移動します。
- BigQuery
- 容量ベースの料金を使用して、定常状態のワークロードのクエリ処理費用を削減します。
- パーティショニングとクラスタリングの手法を使用して、クエリのパフォーマンスと費用を最適化する。
- Google Cloud VMware Engine
- CUD、ストレージ消費量の最適化、ESXi クラスタのサイズ適正化などの費用最適化戦略を使用して、VMware の費用を削減します。
リソース共有を最適化する
クラウド リソースの使用率を最大化するには、アプリケーションのセキュリティ要件やその他の要件を満たしながら、同じインフラストラクチャに複数のアプリケーションやサービスをデプロイします。たとえば、開発環境とテスト環境では、同じクラウド インフラストラクチャを使用してアプリケーションのすべてのコンポーネントをテストできます。本番環境では、各コンポーネントを個別のリソースセットにデプロイして、インシデントが発生した場合の影響範囲を制限できます。
この推奨事項を実装する方法の例を次に示します。
- 複数の非本番環境に単一の Cloud SQL インスタンスを使用します。
- 適切なアクセス制御を備えた GKE のフリート チーム管理機能を使用して、複数の開発チームが 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 ノードなどの個々のリソースタイプに割り当てを適用して、使用量を制限し、予期しない費用の超過を防ぎます。
- 割り当てアラート: 割り当て使用量（プロジェクト レベル）が最大値に達したときに通知を受け取ります。
割り当てと上限を予算編成とモニタリングと組み合わせて使用することで、費用管理に対するプロアクティブで多層的なアプローチを作成できます。このアプローチにより、クラウドの費用を定義された範囲内に抑え、ビジネスの目標に沿ったものにできます。これらの費用管理は、永続的でも厳格でもありません。費用管理が現在の業界標準に沿っており、進化するビジネスニーズを反映していることを確認するには、管理を定期的に確認し、新しいテクノロジーとベスト プラクティスを組み込むように調整する必要があります。