FSI の視点: 費用の最適化

Last reviewed 2025-07-28 UTC

Google Cloud Well-Architected Framework: FSI の視点のこのドキュメントでは、 Google Cloudで金融サービス業界（FSI）のワークロードの費用を最適化するための原則と推奨事項の概要について説明します。このドキュメントの推奨事項は、Well-Architected Framework の費用最適化の柱に沿っています。

金融サービス ワークロードの費用を最適化するには、次の基本要素が必要です。

  • 無駄なリソース使用量と価値を生み出すリソース使用量を特定する機能。
  • 財務上の説明責任を果たす文化が根付いている。

費用を最適化するには、組織全体の費用要因とリソースのニーズを包括的に把握する必要があります。大規模な組織、特にクラウド導入の初期段階にある組織では、1 つのチームが多数のドメインにわたる費用の最適化を担当することがよくあります。このアプローチは、効率向上のための価値の高い機会を特定するうえで、中核チームが最適な立場にあることを前提としています。

一元化されたアプローチは、クラウド導入の初期段階や重要度の低いワークロードでは成功する可能性があります。ただし、1 つのチームが組織全体の費用最適化を推進することはできません。リソースの使用量や規制の監視レベルが増加すると、一元化されたアプローチは持続可能ではなくなります。一元化されたチームは、特に多数の金融商品やサービスを扱う場合に、スケーラビリティの課題に直面します。プロダクトとサービスを所有するプロジェクト チームは、外部チームによる変更に抵抗する可能性があります。

費用を効果的に最適化するには、費用関連のデータを明確に把握し、ワークロードに近いエンジニアや他のクラウド ユーザーが費用を最適化するための行動を起こすようにする必要があります。組織の観点から見ると、費用最適化の課題は、最適化すべき領域を特定し、その領域を担当するエンジニアを特定し、必要な最適化アクションを実行するよう説得することです。このドキュメントでは、この課題に対処するための推奨事項について説明します。

このドキュメントの費用最適化に関する推奨事項は、次のコア原則にマッピングされています。

Google Cloud ツールを使用して無駄を特定する

Google Cloud には、無駄を特定するのに役立つプロダクト、ツール、機能がいくつか用意されています。以下の推奨事項を検討してください。

自動化と AI を使用して、最適化する対象を体系的に特定する

Active Assist は、マイクロサービス用の Cloud Run、データ分析用の BigQuery、コア アプリケーション用の Compute Engine、リレーショナル データベース用の Cloud SQL など、FSI に不可欠なサービス全体でインテリジェントな推奨事項を提供します。Active Assist の推奨事項は、無料で提供され、ユーザーによる構成は必要ありません。推奨事項は、アイドル状態のリソースと使用率の低いコミットメントを特定するのに役立ちます。

統合インターフェースで FinOps のモニタリングと制御を一元化する

Cloud Billing レポートと FinOps ハブを使用すると、包括的な費用モニタリングを実装できます。この包括的なビューは、財務監査担当者と社内の財務チームがクラウド費用を追跡し、財務状況を評価し、さまざまなビジネス ユニットや費用センターの FinOps の成熟度を評価し、一貫した財務ナラティブを提供するために不可欠です。

費用データを分析して拡充し、価値を特定する

Active Assist は、明らかな無駄を特定するのに効果的です。ただし、ワークロードが不適切なプロダクトにある場合や、ワークロードがビジネス価値と明確に連携していない場合は、価値を特定するのが難しくなることがあります。FSI ワークロードの場合、ビジネス価値はコスト削減だけではありません。この価値には、リスクの軽減、規制の遵守、競争優位性の獲得が含まれます。

クラウドの費用と価値を包括的に理解するには、費用がどこから発生しているか、費用がどのビジネス機能に影響しているか、問題のワークロードのリファクタリングや最適化の技術的な実現可能性など、複数のレベルで完全に理解する必要があります。

次の図は、データ、情報、知識、知恵（DIKW）ピラミッドと Google Cloud ツールを適用して、クラウドの費用と価値を包括的に把握する方法を示しています。

データ、情報、知識、知恵（DIKW）のピラミッドは、クラウド費用のデータを使用して意思決定を行う方法を示しています。

上の図は、DIKW アプローチを使用して、クラウド費用の生データをビジネス価値を高める実用的な分析情報と意思決定に変換する方法を示しています。

  • データ: このレイヤでは、クラウド リソースの使用状況と費用に関する未加工のデータ ストリームを収集します。中央の FinOps チームは、Cloud Billing の請求書、請求のエクスポート、Cloud Monitoring などのツールを使用して、詳細なデータを取得します。たとえば、app1-test-vmA という名前の VM が us-central1 リージョンで 730 時間実行され、費用が 70 米ドルだったというデータポイントがあります。
  • 情報: このレイヤでは、中央の FinOps チームが Cloud Billing レポートや FinOps Hub などのツールを使用して、未加工データを構造化し、「どのカテゴリのリソースに費用が費やされているか」などの質問に答えます。たとえば、米国の 2 つのリージョンでマシンタイプ n4-standard-2 の VM に合計 1,050 米ドルが費やされたことがわかります。
  • 知識: このレイヤでは、中央の FinOps チームが、誰が、どのような目的で費用を費やしたかに関する適切なビジネス コンテキストで情報を拡充します。タグ付け、ラベル付け、リソース階層、請求先アカウント、カスタム Looker ダッシュボードなどのメカニズムを使用します。たとえば、米国の app1 テストチームが 7 月の第 2 週にストレステストの一環として 650 米ドルを費やしたと判断できます。
  • Wisdom: このレイヤでは、プロダクト チームとアプリケーション チームがコンテキスト化された知識を使用して、クラウド費用のビジネス価値を評価し、情報に基づいた戦略的な意思決定を行います。チームは次のような質問に答えることができます。
    • データ分析パイプラインに費やした 5,000 米ドルは、ビジネス価値を生み出しているか？
    • パフォーマンスを低下させることなく、パイプラインを再設計して効率を高めることはできますか？

クラウド費用のデータを分析する際は、次の推奨事項を検討してください。

Google Cloudから提供された費用データを分析する

BigQuery にエクスポートされた Cloud Billing の詳細データと、Monitoring ログで使用可能なデータから始めます。実用的な分析情報を導き出して意思決定を行うには、このデータを構造化し、ビジネス コンテキストで拡充する必要があります。

利用可能なツールでデータを可視化する

BigQuery エクスポートで Looker Studio などのツールを使用して、カスタム レポートで組み込みの Google Cloud ダッシュボードを拡張します。財務チームは、クラウド費用を財務指標、規制レポートの要件、ビジネス ユニットの収益性と照らし合わせてコンテキスト化するカスタム ダッシュボードを作成できます。これにより、経営幹部が分析と意思決定を行うための明確な財務ナラティブを提供できます。

アカウンタビリティを高めるために費用を割り当てる

クラウド支出の要因を把握したら、誰が、なぜ費用を支出しているのかを特定する必要があります。このレベルの理解には、クラウド リソースにビジネス関連のメタデータを関連付ける堅牢な費用配分プラクティスが必要です。たとえば、特定のリソースが Banking-AppDev チームで使用されている場合、team=banking_appdev などのタグをリソースに付加して、チームがそのリソースで発生する費用を追跡できます。理想的には、クラウド費用の 100% を支出の発生源に割り当てる必要があります。実際には、100% の費用配分をサポートするメタデータ構造の構築は複雑な作業であるため、低い目標値から始めることをおすすめします。

費用配分をサポートするメタデータ戦略を策定するには、次の推奨事項を検討してください。

  • 有効性: タグがビジネス関連の重要業績評価指標（KPI）と規制要件の特定に役立つことを確認します。この関連付けは、内部チャージバック、規制レポート、クラウド費用とビジネス ユニットの目標の調整に不可欠です。たとえば、次のタグは、費用チーム、そのリージョン、担当するプロダクトを明確に識別します。team=banking_appdev、region=emea、product=frontend。
  • 自動化: タグ付けのコンプライアンスを高いレベルで達成するには、自動化によってタグ付けを適用します。手動タグ付けはエラーや不整合が発生しやすく、監査可能性と財務の正確性が最優先される FSI 環境では許容できません。自動タグ設定により、リソースの作成時にリソースが正しく分類されます。
  • シンプルさ: 相関関係のないシンプルな要因を測定します。FSI 環境は複雑です。このような環境で費用配分ルールを理解しやすく、適用しやすくするには、ルールをできるだけシンプルにする必要があります。非常に特殊な（エッジ）ケースのルールを過度に複雑にしないようにします。複雑なルールは、運用チームの混乱や抵抗につながる可能性があります。

タグを使用して割り当て戦略を定義したら、戦略を実装する粒度を決定する必要があります。必要な粒度は、ビジネスニーズによって異なります。たとえば、組織によってはプロダクト レベルで費用を追跡する必要がある場合もあれば、各費用センターの費用データが必要な場合もあります。また、環境（開発、ステージング、本番環境）ごとに費用データが必要な場合もあります。

組織に適したレベルの費用配分粒度を実現するには、次のアプローチを検討してください。

  • Google Cloud のプロジェクト階層を、費用配分の自然な出発点として使用します。プロジェクトは Google Cloudでのポリシー適用ポイントを表します。デフォルトでは、IAM 権限、セキュリティ ポリシー、費用はプロジェクトとフォルダに割り当てられます。Cloud Billing からエクスポートされた費用データを確認すると、フォルダ階層と費用データに関連付けられているプロジェクトを表示できます。Google Cloud リソース階層に組織の費用の説明責任構造が反映されている場合は、これが費用配賦を実装する最も簡単な方法です。
  • 追加の粒度には、タグとラベルを使用します。請求関連のエクスポートでリソースを分類する柔軟な方法が提供されます。タグとラベルを使用すると、アプリケーションと環境別に費用の内訳を詳細に把握できます。

多くの場合、効果的な費用配分を行うには、プロジェクト階層とタグ付け、ラベル付けを組み合わせて使用する必要があります。選択する費用配分アプローチに関係なく、堅牢なメタデータ戦略（検証、自動化、シンプルさ）を開発するために、前述の推奨事項に従ってください。

アカウンタビリティを高め、エンジニアの行動を促す

クラウド FinOps チームは、組織が費用と価値を意識するように推進する責任を負います。個々のプロダクト チームとエンジニアリング チームは、費用最適化に必要なアクションを実行する必要があります。これらのチームは、金融サービス ワークロードの費用行動にも責任を負い、ワークロードがビジネス価値を提供することを保証します。

説明責任を推進し、チームが費用を最適化するよう動機づけるには、次の推奨事項を検討してください。

ガバナンスのための FinOps 中央チームを設立する

Cloud FinOps のプラクティスは自然に成長するものではありません。FinOps 専任チームは、次のことを行って FinOps 手法を定義し、確立する必要があります。

  • 必要なプロセス、ツール、ガイダンスを構築します。
  • 必須のタグ付け、予算のレビュー、最適化プロセスなど、必要なポリシーを作成、伝達、実施します。
  • エンジニアリング チームに費用の説明責任を負うよう促します。
  • エンジニアリング チームが費用の所有権を引き受けない場合は、介入します。

経営陣の支持と権限を得る

CTO、CFO、CIO などの上級リーダーは、組織全体で FinOps 文化への移行を積極的に推進する必要があります。経営幹部のサポートは、費用の説明責任を優先し、FinOps プログラムにリソースを割り当て、部門横断的な参加を確保し、FinOps 要件への準拠を推進するうえで不可欠です。

チームに費用の最適化を促す

エンジニアやエンジニアリング チームは、費用最適化に自発的に取り組まない可能性があります。チームと個人の目標を費用対効果に合わせるには、次のようなインセンティブを導入することが重要です。

  • 費用最適化による削減額の一部を、最適化を達成したチームに再投資します。
  • 費用最適化の取り組みと成功を公に認め、称えます。
  • ゲーミフィケーション手法を使用して、費用を効果的に最適化したチームに報酬を与えます。
  • 効率性の指標をパフォーマンス目標に統合します。

ショーバックとチャージバックの手法を実装する

チームが所有するクラウド リソースと費用を明確に把握できるようにします。チーム内の適切な担当者に財務責任を割り当てます。厳格なタグ付けを適用し、共有費用の割り当てに関する透明性の高いルールを実装するために、正式なメカニズムを使用します。

費用ではなく価値と TCO に焦点を当てる

クラウド ソリューションを評価する際は、長期的な総所有コスト（TCO）を考慮してください。たとえば、アプリケーションのデータベースをセルフホストする方が、Cloud SQL などのマネージド データベース サービスを使用するよりも安価に思えるかもしれません。ただし、長期的な価値と TCO を評価するには、セルフホスト データベースに関連する隠れたコストを考慮する必要があります。このような費用には、FSI ワークロードの重要な要件であるパッチ適用、スケーリング、セキュリティ強化、障害復旧のための専用エンジニアリング作業が含まれます。マネージド サービスは長期的に大きな価値をもたらし、インフラストラクチャの費用を相殺します。マネージド サービスは、堅牢なコンプライアンス機能を提供し、信頼性機能が組み込まれており、運用オーバーヘッドの削減に役立ちます。

価値と TCO に焦点を当てるには、次の推奨事項を検討してください。

リソースの最適化にプロダクト固有の手法とツールを使用する

Google Cloudプロダクトで提供されるコスト最適化ツールと機能（次のようなもの）を活用します。

割引を受ける

Google が提供する割引を利用して、クラウド リソースの課金レートを可能な限り低くします。通常、リソースの最適化は個々のプロダクト チームとエンジニアリング チームが管理します。組織全体のリソース要件を把握しているため、請求レートの最適化は中央の FinOps チームが担当します。そのため、要件を集約して、コミットメント ベースの割引を最大限に活用できます。

Google Cloud リソースには、次のタイプの割引を利用できます。

  • エンタープライズ割引は、組織が Google Cloud での合計最小費用を確約し、請求レートを削減することに基づいて交渉される割引です。
  • リソースベースの CUD は、1 年間または 3 年間に最小限の Compute Engine リソースを使用することを確約することと引き換えに適用されます。リソースベースの CUD は、特定のプロジェクトとリージョンにあるリソースに適用されます。複数のプロジェクト間で CUD を共有するには、割引の共有を有効にします。
  • 費用ベースの CUD は、1 年間または 3 年間の期間に特定のプロダクトで最低限の金額を使用するというコミットメントと引き換えに適用されます。費用ベースの割引は、請求先アカウント レベルで適用されます。割引は、プロダクトに応じて地域単位またはグローバル単位で適用されます。

エンタープライズ割引に加えて CUD を使用すると、大幅な費用削減を実現できます。

CUD に加えて、次の方法で請求レートを削減します。

  • フォールト トレラントで柔軟なワークロードには、Spot VM を使用します。Spot VM は、通常の VM と比べて 80% 以上安価です。
  • BigQuery には、コミットメントと自動スケーリングの要件に基づくオンデマンド料金とエディション ベースの料金など、複数の料金モデルが用意されています。大量の BigQuery リソースを使用する場合は、適切なエディションを選択して、分析ワークロードのスロットあたりの費用を削減します。
  • 使用する必要があるサービスの利用可能な Google Cloud リージョンを慎重に評価します。費用目標と、レイテンシやコンプライアンス要件などの要因に沿ったリージョンを選択します。コスト、持続可能性、レイテンシのトレードオフを理解するには、Google Cloud Region Picker を使用します。
前へ
信頼性
次へ
パフォーマンスの最適化