Google Cloud Well-Architected Framework: 費用の最適化

Last reviewed 2025-02-14 UTC

Google Cloud Well-Architected Framework の費用の最適化の柱では、 Google Cloudでワークロードの費用を最適化するための原則と推奨事項について説明します。

対象読者は次のとおりです。

  • 戦略的なコスト管理を担当する CTO、CIO、CFO などの幹部。
  • 組織のクラウド ジャーニーのすべての段階で費用に影響する意思決定を行うアーキテクト、デベロッパー、管理者、オペレーター。

オンプレミス ワークロードとクラウド ワークロードの費用モデルは大きく異なります。オンプレミスの IT 費用には、資本的支出（CapEx）と運用上の支出（OpEx）が含まれます。オンプレミスのハードウェア アセットとソフトウェア アセットは取得され、取得費用はアセットの運用期間で減価償却されます。クラウドでは、ほとんどのクラウド リソースの費用は OpEx として扱われます。この場合、クラウド リソースの使用時に費用が発生します。この根本的な違いは、費用最適化の次のコア原則の重要性を示しています。

AI ワークロードと ML ワークロードに固有の費用最適化の原則と推奨事項については、Well-Architected フレームワークの AI と ML の視点: 費用の最適化をご覧ください。

基本原則

Well-Architected フレームワークの費用の最適化の柱の推奨事項は、次のコア原則にマッピングされています。

  • クラウドの費用をビジネス価値と調整する: IT の費用をビジネス目標と調整することで、クラウド リソースが測定可能なビジネス価値をもたらすことを確認します。
  • コスト意識の高い文化を育む: 組織全体のユーザーが意思決定やアクティビティによる費用への影響を考慮し、情報に基づいた意思決定に必要な費用情報にアクセスできるようにします。
  • リソース使用量を最適化する: 必要なリソースのみをプロビジョニングし、使用したリソースに対してのみ料金を支払います。
  • 継続的に最適化する: クラウド リソースの使用状況と費用を継続的にモニタリングし、必要に応じて事前に調整して費用を最適化します。このアプローチでは、重大な問題になる前に潜在的な費用の非効率性が特定し、対処します。

これらの原則は、クラウド FinOpsの基本原則と密接に関連しています。FinOps は、組織の規模やクラウドの成熟度に関係なく、すべての組織に関連しています。これらの原則を採用し、関連する推奨事項に従うことで、クラウドへの移行全体で費用を管理し、最適化できます。

寄稿者

著者: Nicolas Pintaux | カスタマー エンジニア、アプリケーション モダナイゼーション スペシャリスト

その他の寄稿者:

クラウド費用をビジネス価値と調整する

Google Cloud Well-Architected Framework の費用最適化の柱にこの原則では、 Google Cloud リソースの使用を組織のビジネス目標に合わせるための推奨事項が示されています。

原則の概要

クラウド費用を効果的に管理するには、クラウド リソースが提供するビジネス価値を最大化し、総所有コスト（TCO）を最小限に抑える必要があります。クラウド ワークロードのリソース オプションを評価する場合は、リソースのプロビジョニングと使用の費用だけでなく、リソースの管理費用も考慮してください。たとえば、Compute Engine の仮想マシン（VM）は、アプリケーションをホストするための費用対効果の高いオプションです。ただし、VM の維持、パッチ適用、スケーリングのオーバーヘッドを考慮すると、TCO が増加する可能性があります。一方、Cloud Run などのサーバーレス サービスは、より大きなビジネス価値を提供できます。運用のオーバーヘッドが軽減されるため、チームはコア アクティビティに集中でき、アジリティを高めることができます。

クラウド リソースが最適な価値を提供できるようにするには、次の要素を評価します。

  • プロビジョニングと使用の費用: リソースの購入、プロビジョニング、使用時に発生する費用。
  • 管理費用: パッチ適用、モニタリング、スケーリングなどのタスクを含む、リソースの運用と保守にかかる定期的な費用。
  • 間接費用: ダウンタイム、データ損失、セキュリティ侵害などの問題を管理するために発生する費用。
  • ビジネスへの影響: 収益の増加、顧客満足度の向上、製品化までの時間の短縮など、リソースから得られる潜在的なメリット。

クラウド費用をビジネス価値と調整することには、次のようなメリットがあります。

  • 価値に基づく意思決定: チームは、ビジネス価値を最大限に高めるソリューションを優先し、短期的および長期的な費用の影響を検討できます。
  • 情報に基づくリソースの選択: チームは、さまざまなデプロイ オプションのビジネス価値と TCO を評価するために必要な情報と知識が得られるため、費用対効果の高いリソースを選択できます。
  • チーム間の調整: ビジネスチーム、財務チーム、技術チームの部門横断型のコラボレーションにより、クラウドに関する意思決定が組織全体の目標と一致するようにします。

推奨事項

クラウドの費用をビジネス目標に合わせて調整するには、次の推奨事項を検討してください。

マネージド サービスとサーバーレス プロダクトの優先順位を決める

可能であれば、マネージド サービスとサーバーレス プロダクトを選択して、運用のオーバーヘッドとメンテナンス費用を削減します。これにより、チームはコアビジネス アクティビティに集中できます。新機能や機能が迅速に提供されるため、イノベーションと価値の向上を促進できます。

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

  • PostgreSQL、MySQL、Microsoft SQL Server サーバー データベースを実行する場合は、これらのデータベースを VM にデプロイするのではなく、Cloud SQL を使用します。
  • Kubernetes クラスタを実行して管理する場合、VM にコンテナをデプロイするのではなく、Google Kubernetes Engine（GKE）Autopilot を使用します。
  • Apache Hadoop または Apache Spark の処理が必要な場合は、Dataproc と Dataproc Serverless を使用します。秒単位で課金されるため、オンプレミスのデータレイクと比べると、TCO を大幅に削減できます。

費用対効果とビジネスのアジリティを両立する

費用の管理とリソース使用率の最適化は重要な目標ですが、これらの目標と、迅速なイノベーション、変化への迅速な対応、価値の迅速な提供を可能にする柔軟なインフラストラクチャの必要性とバランスを取る必要があります。以下に、このバランスを実現する方法の例を示します。

  • ソフトウェア デリバリーのパフォーマンスに DORA 指標を採用します。変更の失敗率（CFR）、検出時間（TTD）、復元時間（TTR）などの指標は、開発プロセスとデプロイ プロセスのボトルネックを特定して修正する際に役立ちます。ダウンタイムを短縮してデリバリーを迅速化することで、運用効率とビジネス アジリティの両方を実現できます。
  • サイト信頼性エンジニアリング（SRE）の手法に従って運用の信頼性を向上させます。SRE は自動化、オブザーバビリティ、インシデント対応に重点を置いているので、ダウンタイムの短縮、復旧時間の短縮、顧客満足度の向上につながります。ダウンタイムを最小限に抑え、運用の信頼性を向上させることで、収益の損失を防ぎ、停止に対応するためのセーフティ ネットとしてリソースを過剰にプロビジョニングする必要がなくなります。

セルフサービス最適化を有効にする

チームにセルフサービスの費用最適化ツール、オブザーバビリティ ツール、リソース管理プラットフォームを提供し、テストと探索の文化を浸透させます。クラウド リソースを自動的にプロビジョニング、管理、最適化できるようにします。このアプローチは、所有権の意識を高め、イノベーションを加速させ、チームがコスト効率に配慮しながら、変化するニーズに迅速に対応できるようにします。

FinOps の導入と実装

FinOps を導入して、誰もが費用と価値のバランスを考慮し、情報に基づく意思決定を行えるコラボレーション環境を構築します。FinOps は財務アカウンタビリティを促進し、クラウドで効果的な費用の最適化を促進します。

価値重視で TCO に配慮した考え方を推進する

チームメンバーに、クラウド費用に対して包括的な姿勢を取り、初期費用だけでなく TCO に重点を置くよう促します。バリュー ストリーム マッピングなどの手法を用いて、ソフトウェア提供プロセスにおける価値の流れを可視化して分析し、改善が必要な領域を特定します。アプリケーションとサービスに単位あたりの費用を実装し、コスト要因を詳細に把握して、費用の最適化の機会を見つけます。詳細については、クラウド FinOps でビジネスの価値を最大化をご覧ください。

費用を意識する文化を育む

Google Cloud Well-Architected Framework の費用最適化の柱にこの原則では、組織全体で費用意識を高め、チームメンバーが十分な情報に基づいて意思決定するために必要な費用情報を確実に把握できるようにするための推奨事項が示されています。

従来、費用管理の責任は少数の選ばれたステークホルダーに集中し、主にプロジェクトの初期アーキテクチャの決定に焦点を当てていました。ただし、すべてのクラウド ユーザーロール（アナリスト、アーキテクト、デベロッパー、管理者）のチームメンバーは、Google Cloudのリソース費用の削減に貢献できます。費用データを適切に共有することで、チームメンバーが開発プロセスとデプロイ プロセス全体で費用対効果の高い意思決定を行えるようにします。

原則の概要

プロダクト オーナー、デベロッパー、デプロイ エンジニア、管理者、財務アナリストなど、さまざまな役割のステークホルダーは、関連する費用データとそのビジネス価値との関係を把握する必要があります。クラウド リソースのプロビジョニングと管理には、次のデータが必要です。

  • 予測されるリソース費用: 設計とデプロイ時の費用見積もり。
  • リアルタイムのリソース使用量の費用: 継続的なモニタリングと予算の検証に使用できる最新の費用データ。
  • ビジネス指標にマッピングされた費用: クラウド費用が主要業績評価指標（KPI）にどのように影響するかに関する分析情報により、チームは費用対効果の高い戦略を特定できます。

すべてのユーザーが費用の元データにアクセスする必要はありません。ただし、個々の意思決定が費用に影響する可能性があるため、すべての役割で費用に対する意識を高めることが重要です。

費用の可視性を高め、費用管理手法の明確な所有権を確保することで、すべての人が選択の財務的な影響を認識し、組織の費用最適化目標に積極的に貢献できるようになります。一元化された FinOps チームと分散モデルのどちらであっても、効果的な費用最適化の取り組みには、アカウンタビリティを確立することが重要です。

推奨事項

費用意識を高め、チームメンバーが十分な情報に基づいて意思決定するために必要な費用情報を確実に把握できるようにするには、次の推奨事項を検討してください。

組織全体の費用を可視化する

組織全体の費用の可視性を実現するために、費用管理を担当するチームは次のアクションを実施できます。

  • 費用の計算と予算を標準化する: 一貫した方法で、割引と共有費用を考慮したクラウド リソースの総費用を決定します。組織の目標に沿って、費用を事前に管理できる明確で標準化された予算プロセスを確立します。
  • 標準化された費用管理ツールと可視化ツールを使用する: クラウドの費用に関するリアルタイムの分析情報を提供して、費用の推移のスナップショットを定期的に（週単位など）生成する適切なツールを使用します。これらのツールを使用すると、予算編成、予測、最適化の機会を事前に特定できます。ツールには、クラウド プロバイダのツール（Google Cloud Billing ダッシュボードなど）、サードパーティ ソリューション、費用アトリビューション ソリューションなどのオープンソース ソリューションがあります。
  • 費用割り当てシステムを実装する: クラウドの全体的な予算の一部を各チームまたはプロジェクトに割り当てます。このような割り当てにより、チームはクラウド支出に対する所有権を意識し、割り当てられた予算内で費用対効果の高い意思決定を行うよう促されます。
  • 透明性を促進する: 設計と意思決定のプロセスで、費用への影響をチームで話し合うようにします。費用の最適化に関するアイデアや懸念事項を共有するための、安全で支援的な環境を構築します。一部の組織では、リーダーボードや表彰プログラムなどのポジティブな強化メカニズムを使用しています。ビジネス上の懸念から、組織で未加工の費用データの共有が制限されている場合は、費用情報と分析情報を共有するための代替アプローチを検討してください。たとえば、集計指標（環境や機能の合計費用など）や相対指標（トランザクションまたはユーザーあたりの平均費用など）を共有することを検討してください。

クラウド リソースの課金方法を理解する

Google Cloud リソースの料金は、リージョンによって異なる場合があります。リソースによっては、固定料金で毎月請求されるものもあれば、使用量に基づいて請求されるものもあります。 Google Cloud リソースの課金方法を確認するには、Google Cloud 料金計算ツールとプロダクト固有の料金情報（Google Kubernetes Engine（GKE）の料金など）を使用します。

リソースベースの費用最適化オプションについて

使用する予定のクラウド リソースの種類ごとに、使用率と効率を最適化する戦略を検討します。戦略には、適切なサイズの調整、自動スケーリング、サーバーレス テクノロジーの採用が含まれます。以下に、いくつかのプロダクトの費用最適化オプションの例を示します。 Google Cloud

  • Cloud Run では、常に割り当てられる CPU を構成して、デフォルトの割り当て方法（リクエストの処理中にのみ割り当てられる CPU）のわずかな費用で予測可能なトラフィック ロードを処理できます。
  • BigQuery スロット コミットメントを購入すると、データ分析にかかる費用を節約できます。
  • GKE は、費用最適化オプションを把握するのに役立つ詳細な指標を提供します。
  • ネットワーク料金がデータ転送の費用に与える影響と、特定のネットワーキング サービスの費用を最適化する方法について学びます。たとえば、Cloud CDN または Google Cloud Armor を使用すると、外部アプリケーション ロードバランサのデータ転送費用を削減できます。詳細については、外部アプリケーション ロードバランサの費用を削減する方法をご覧ください。

割引ベースの費用最適化オプションについて

Google Cloud が提供する割引プログラム（次の例など）をよく理解してください。

  • 確約利用割引（CUD）: CUD は、使用量が予測可能で安定しているリソースに適しています。CUD では、一定期間（通常 1 ～ 3 年）にわたる特定のリソース使用を確約することで、大幅な割引を受けることができます。CUD 自動更新を使用して、有効期限が切れたときにコミットメントを手動で再購入する必要がなくなります。
  • 継続利用割引: Compute Engine や GKE などの特定の Google Cloud プロダクトでは、特定の期間のしきい値を超えてリソースを継続的に使用すると、自動的に割引クレジットを受け取ることができます。
  • Spot VM: フォールト トレラントで柔軟なワークロードの場合、Spot VM を使用すると Compute Engine の費用を削減できます。Spot VM の費用は、通常の VM よりも大幅に低くなります。ただし、Compute Engine は処理能力を調整するため、Spot VM をプリエンプティブに停止または削除する場合があります。Spot VM は、プリエンプションを許容でき、高可用性の要件がないバッチジョブに適しています。
  • 特定のプロダクト オプションの割引: BigQuery などの一部のマネージド サービスでは、専用または自動スケーリングのクエリ処理容量を購入すると割引が適用されます。

ワークロードの特性と使用パターンに合った割引オプションを評価して選択します。

費用見積もりをアーキテクチャ ブループリントに組み込む

さまざまなデプロイ オプションと構成の費用見積もりが含まれるアーキテクチャ ブループリントを開発するよう、チームに働きかけます。この方法により、チームは費用を事前に比較し、技術的な目標と財務的な目標の両方に沿って十分な情報に基づいて意思決定できるようになります。

すべてのリソースに整合性のある標準的なラベルセットを使用する

ラベルを使用すると、費用を追跡し、リソースを特定して分類できます。具体的には、ラベルを使用して、さまざまなプロジェクト、部門、コストセンターに費用を割り当てることができます。組織内の主要な関係者のニーズに合わせて正式なラベル付けポリシーを定義すると、費用をより広範囲に可視化できます。ラベルを使用して、ターゲット オーディエンスに基づいてリソースの費用と使用状況のデータをフィルタすることもできます。

Terraform などの自動化ツールを使用して、作成されるすべてのリソースにラベル付けを適用します。費用の可視性とアトリビューションをさらに強化するには、オープンソースの費用アトリビューション ソリューションで提供されるツールを使用します。

費用レポートをチームメンバーと共有する

費用レポートをチームメンバーと共有することで、チームメンバーがクラウドの費用を管理できるようにします。この方法により、費用対効果の高い意思決定、継続的な費用最適化、費用配分モデルの体系的な改善が可能になります。

費用レポートには、次のような種類があります。

  • 定期的な費用レポート: 定期的なレポートは、現在のクラウド費用についてチームに通知します。従来、これらのレポートはスプレッドシートのエクスポートでした。より効果的な方法としては、自動メールや専用のダッシュボードなどがあります。費用レポートで、受信者に不要な詳細情報を提供することなく、関連性の高い実用的な情報を提供するには、レポートを対象グループに合わせて調整する必要があります。カスタマイズされたレポートを設定することは、よりリアルタイムでインタラクティブな費用の可視化と管理に向けた基本的なステップです。
  • 自動通知: 費用レポートを構成して、費用の異常値、予算のしきい値、費用の最適化の機会について、関連するステークホルダーに事前に通知できます（メールやチャットなど）。自動アラートは、対応できるユーザーにタイムリーな情報を直接提供することで、迅速な対応を促し、費用の最適化に積極的なアプローチを促進します。
  • Google Cloud ダッシュボード: Google Cloud の組み込みの課金ダッシュボードを使用して、費用の内訳に関する分析情報を取得し、費用の最適化の機会を特定できます。 Google Cloud には、費用の削減状況をモニタリングし、費用の最適化に関する推奨事項を取得できる FinOps ハブも用意されています。AI エンジンを搭載した FinOps ハブは、現在デプロイされているすべてのリソースの費用最適化の機会を推奨します。これらの推奨事項へのアクセスを制御するには、ロールベースのアクセス制御（RBAC）を実装します。
  • カスタム ダッシュボード: 費用データを分析データベース（BigQuery など）にエクスポートして、カスタム ダッシュボードを作成できます。Looker Studio などの可視化ツールを使用して分析データベースに接続し、インタラクティブなレポートを作成し、ロールベースの権限によるきめ細かいアクセス制御を有効にします。
  • マルチクラウド費用レポート: マルチクラウド デプロイでは、包括的な分析、予算編成、最適化を行うために、すべてのクラウド プロバイダの費用を統合したビューが必要です。BigQuery などのツールを使用して、複数のクラウド プロバイダの費用データを一元化して分析し、Looker Studio を使用してチーム固有のインタラクティブなレポートを作成します。

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

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
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 などの特定のサービスに割り当てを構成して、プロビジョニングできるインスタンス数、CPU、ストレージ容量を制限します。 Google Cloud
  • リソースタイプ固有の割り当て: Compute Engine VM、Cloud Storage バケット、Cloud Run インスタンス、GKE ノードなどの個々のリソースタイプに割り当てを適用して、使用量を制限し、予期しない費用超過を防ぎます。
  • 割り当てアラート: 割り当て使用量（プロジェクト単位）が最大値の割合に達したときに通知を受け取ります。

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

継続的に最適化する

Google Cloud Well-Architected Framework の費用最適化の柱にこの原則では、絶えず変化し進化するビジネス目標に基づいてクラウド デプロイの費用を最適化するための推奨事項が示されています。

ビジネスの成長と進化に伴い、クラウド ワークロードはリソース要件と使用パターンの変化に適応する必要があります。クラウドの費用から最大限の価値を引き出すには、ビジネス目標を継続的にサポートしながら費用対効果を維持する必要があります。そのためには、継続的な改善と最適化に重点を置いた、予防的かつ適応力のあるアプローチが必要です。

原則の概要

費用を継続的に最適化するには、クラウド環境を事前にモニタリングして分析し、現在の要件を満たすように適切に調整する必要があります。エンドユーザーのエクスペリエンスに直接影響し、ビジネス目標と一致し、継続的な改善のための分析情報を提供する重要業績評価指標（KPI）にモニタリングを集中させます。このアプローチにより、非効率性を特定して対処し、変化するニーズに適応し、クラウドの費用を戦略的なビジネス目標と継続的に調整できます。包括的なオブザーバビリティと費用対効果のバランスを取るには、リソース使用量のモニタリングの費用とメリットを理解し、適切なプロセス改善と最適化戦略を使用します。

推奨事項

環境を効果的にモニタリングし、費用を継続的に最適化するには、次の推奨事項を検討してください。 Google Cloud

ビジネスに関連する指標に焦点を当てる

効果的なモニタリングは、ビジネスと顧客にとって最も重要な指標を特定することから始まります。具体的には次のような指標があります。

  • ユーザー エクスペリエンスの指標: レイテンシ、エラー率、スループット、顧客満足度の指標は、アプリケーションの使用時にエンドユーザーがどのようなエクスペリエンスを得ているかを把握するのに役立ちます。
  • ビジネス成果の指標: 収益、顧客数の増加、エンゲージメントをリソース使用量と関連付けて、費用最適化の機会を特定できます。
  • DevOps Research and Assessment（DORA）指標: デプロイ頻度、変更のリードタイム、変更の失敗率、復元時間などの指標は、ソフトウェア デリバリー プロセスの効率性と信頼性に関する分析情報を提供します。これらの指標を改善することで、生産性の向上、ダウンタイムの短縮、費用の最適化を実現できます。
  • サイト信頼性エンジニアリング（SRE）の指標: エラー バジェットは、許容できるサービス中断レベルを定量化して管理するのに役立ちます。信頼性に関する明確な期待値を確立することで、エラー バジェットにより、チームは安全余裕を把握しながら、より自信を持ってイノベーションを起こし、変更をデプロイできます。このプロアクティブなアプローチは、イノベーションと安定性のバランスを促進し、大規模な停止や長時間のダウンタイムに関連する過剰な運用コストを回避するのに役立ちます。

オブザーバビリティを使用してリソースを最適化する

オブザーバビリティを使用してクラウド デプロイメントのリソースのボトルネックと十分に活用されていないリソースを特定するための推奨事項は次のとおりです。

  • リソースの使用率をモニタリングする: リソース使用率の指標を使用して、十分に活用されていないリソースを特定します。Google Cloud たとえば、CPU やメモリ使用率などの指標を使用して、アイドル状態の VM リソースを特定します。Google Kubernetes Engine（GKE）の場合、費用の内訳と費用関連の最適化指標の詳細を確認できます。Google Cloud VMware Engine の場合は、リソース使用率を確認して、CUD、ストレージ使用量、ESXi の適切なサイズ設定を最適化します。
  • クラウドの推奨事項を使用する: Active Assist は、クラウド運用の最適化に役立つインテリジェントなツールのポートフォリオです。これらのツールは、コスト削減、パフォーマンスの向上、セキュリティの改善、持続可能性に重点を置いた意思決定に役立つ実用的な推奨事項を提供します。たとえば、VM のサイズ適正化に関する分析情報を使用すると、リソースの割り当てを最適化し、不要な費用を回避できます。
  • リソース使用率とパフォーマンスを関連付ける: リソース使用率とアプリケーション パフォーマンスの関係を分析し、ユーザー エクスペリエンスに影響を与えることなく、費用の低いリソースにダウングレードできるかどうかを判断します。

トラブルシューティングのニーズと費用のバランスを取る

詳細なオブザーバビリティ データは、問題の診断とトラブルシューティングに役立ちます。ただし、過剰な量のオブザーバビリティ データを保存したり、不要なデータを外部モニタリング ツールにエクスポートしたりすると、不要な費用が発生する可能性があります。効率的なトラブルシューティングを行うには、次の推奨事項を検討してください。

  • トラブルシューティングに十分なデータを収集する: 問題が発生したときに効率的に診断して解決できるように、モニタリング ソリューションで十分なデータをキャプチャするようにします。このデータには、さまざまな粒度のログ、トレース、指標が含まれる場合があります。
  • サンプリングと集計を使用する: サンプリングと集計の手法を使用して、詳細なデータの必要性と費用の考慮事項のバランスを取る。このアプローチでは、過度のストレージ費用が発生することなく、代表的なデータを収集できます。
  • モニタリング ツールとサービスの料金モデルを理解する: さまざまなモニタリング ソリューションを評価し、プロジェクトの特定のニーズ、予算、使用パターンに合ったオプションを選択します。選択する際は、データ量、保持要件、必要な機能などの要素を考慮してください。
  • モニタリングの構成を定期的に確認する: 不要な指標やログを削除して、過剰なデータの収集を回避します。

ロールに合わせてデータ収集を調整し、ロール固有の保持ポリシーを設定する

さまざまな役割の特定のデータニーズを考慮します。たとえば、デベロッパーは主にトレースやアプリケーション レベルのログにアクセスする必要がありますが、IT 管理者はシステムログとインフラストラクチャ指標に重点を置く場合があります。データ収集を調整することで、不要なストレージ費用を削減し、無関係な情報でユーザーを圧倒しないようにすることができます。

また、各ロールのニーズと規制要件に基づいて保持ポリシーを定義することもできます。たとえば、デベロッパーは短い期間の詳細なログにアクセスする必要がある一方で、財務アナリストは長期のデータが必要になる場合があります。

規制要件とコンプライアンス要件を考慮する

特定の業界では、規制要件によりデータの保持が義務付けられています。法的および財務的なリスクを回避するには、モニタリングとデータ保持の運用が関連する規制に準拠していることを確認する必要があります。同時に、費用対効果を維持する必要があります。以下の推奨事項を参考にしてください。

  • 業界または地域に固有のデータ保持要件を特定し、モニタリング戦略がそれらの要件を満たしていることを確認します。
  • 適切なデータ アーカイブと取得メカニズムを実装して、ストレージ コストを最小限に抑えながら、監査とコンプライアンスのニーズを満たします。

スマート アラートを実装する

アラートを使用すると、問題をタイムリーに検出して解決できます。ただし、最新情報を常に把握できるアプローチと、通知で圧倒されるアプローチのバランスが必要です。インテリジェントなアラート システムを設計することで、ビジネスへの影響が大きい重要な問題を優先できます。以下の推奨事項を参考にしてください。

  • お客様に影響する問題を優先する: ウェブサイトの停止、レスポンス時間の遅延、トランザクションの失敗など、カスタマー エクスペリエンスに直接影響する問題に対して迅速にトリガーされるアラートを設計します。
  • 一時的な問題に合わせて調整する: 適切なしきい値と遅延メカニズムを使用して、一時的な問題や、お客様に影響しないセルフヒーリング システムの問題に関する不要なアラートを回避します。
  • アラートの重大度をカスタマイズする: 重大なアラートと重大でないアラートを区別して、最も緊急の問題にすぐに対応できるようにします。
  • 通知チャンネルを賢く使用する: アラートの重大度と緊急性に基づいて、アラート通知に適したチャンネル（メール、SMS、ページング）を選択します。