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 Framework の AI と ML の視点: 費用の最適化をご覧ください。

基本原則

Well-Architected Framework の費用最適化の柱における推奨事項は、次の基本原則にマッピングされています。

  • クラウドの費用をビジネス価値と調整する: 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 が不要になったときに 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 ノードなどの個々のリソースタイプに割り当てを適用して、使用量を制限し、予期しない費用の超過を防ぎます。
  • 割り当てアラート: 割り当て使用量（プロジェクト レベル）が最大値の一定の割合に達したときに通知を受け取ります。

割り当てと上限を予算編成とモニタリングと組み合わせて使用すると、費用管理に対する事前対応型の多層アプローチを構築できます。このアプローチにより、クラウドの費用が定義された範囲内に収まり、ビジネス目標と一致することが保証されます。これらの費用管理は永続的または厳格なものではありません。費用管理が現在の業界標準に沿ったものであり、変化するビジネスニーズを反映したものとなるように、管理を定期的に見直し、新しいテクノロジーとベスト プラクティスを含めるように調整する必要があります。

継続的に最適化する

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

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

原則の概要

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

推奨事項

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

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

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

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

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

オブザーバビリティを使用して、クラウド環境のリソースのボトルネックと使用率の低いリソースを特定するための推奨事項は次のとおりです。

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

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

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

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

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

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

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

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

特定の業界では、規制要件によりデータ保持が義務付けられています。法的リスクと財務リスクを回避するには、モニタリングとデータ保持のプラクティスが関連する規制の遵守に役立つようにする必要があります。同時に、費用対効果を維持する必要があります。以下の推奨事項を参考にしてください。

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

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

アラートは、問題をタイムリーに検出して解決するのに役立ちます。ただし、最新情報を把握できるアプローチと、通知が多すぎて煩わしく感じるアプローチとのバランスが必要です。インテリジェントなアラート システムを設計することで、ビジネスへの影響が大きい重要な問題を優先的に処理できます。次の推奨事項を検討してください。

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