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 | |
| GKE |
|
| Cloud Storage |
|
| BigQuery |
|
| Google Cloud VMware Engine |
|
リソース共有を最適化する
クラウド リソースの使用率を最大化するには、アプリケーションのセキュリティ要件やその他の要件を満たしながら、同じインフラストラクチャに複数のアプリケーションまたはサービスをデプロイします。たとえば、開発環境とテスト環境では、同じクラウド インフラストラクチャを使用してアプリケーションのすべてのコンポーネントをテストできます。本番環境では、インシデントが発生した場合の影響範囲を制限するために、各コンポーネントを別々のリソースセットにデプロイできます。
この推奨事項を実装する方法の例を次に示します。
- 複数の非本番環境に単一の 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 ノードなどの個々のリソースタイプに割り当てを適用して、使用量を制限し、予期しない費用の超過を防ぎます。
- 割り当てアラート: 割り当て使用量（プロジェクト レベル）が最大値の一定の割合に達したときに通知を受け取ります。
割り当てと上限を予算編成とモニタリングと組み合わせて使用すると、費用管理に対する事前対応型の多層アプローチを構築できます。このアプローチにより、クラウドの費用が定義された範囲内に収まり、ビジネス目標と一致することが保証されます。これらの費用管理は永続的または厳格なものではありません。費用管理が現在の業界標準に沿ったものであり、変化するビジネスニーズを反映したものとなるように、管理を定期的に見直し、新しいテクノロジーとベスト プラクティスを含めるように調整する必要があります。