Well-Architected Framework: 金融サービス業界（FSI）の視点

Last reviewed 2025-07-28 UTC

Google Cloud Well-Architected Framework のこのドキュメントでは、運用、セキュリティ、信頼性、費用、パフォーマンスの目標を満たす金融サービス業界（FSI）アプリケーションを Google Cloud で設計、構築、管理するうえで役立つ原則と推奨事項について説明します。

このドキュメントの対象読者は、 Google Cloudで FSI ワークロードの設計、構築、デプロイ、保守を行う意思決定者、アーキテクト、管理者、デベロッパー、オペレータです。このガイダンスの対象となる FSI 組織の例としては、銀行、決済インフラストラクチャ事業者、保険会社、資本市場運営会社などがあります。

FSI 組織には、特にアーキテクチャと復元力に関して、考慮すべき事項があります。これらの考慮事項は、主に規制、リスク、パフォーマンスの要件によって決まります。このドキュメントでは、世界中の幅広い FSI 顧客で確認された設計上の考慮事項に基づいて、大まかなガイダンスを提供します。ワークロードが完全にクラウドにあるか、ハイブリッド クラウドまたはマルチクラウドのデプロイに移行しているかにかかわらず、このドキュメントのガイダンスは、規制要件とさまざまなリスクの視点を満たすように Google Cloud でワークロードを設計するのに役立ちます。このガイダンスは、すべての組織に固有の課題に対応しているわけではありません。これは、FSI 組織の主要な規制要件の多くに対応する基盤となります。

クラウド ワークロードの設計における主な課題は、クラウド デプロイとオンプレミス環境の調整です。特に、セキュリティ、信頼性、復元力に対する一貫したアプローチを目指す場合は、この課題が顕著になります。クラウド サービスは、管理オーバーヘッドの削減、費用の最適化、セキュリティの強化、信頼性と復元力の向上を実現するために、アーキテクチャを根本的に見直す機会を提供します。

次のページでは、Well-Architected Framework の各柱について、FSI ワークロードに固有の原則と推奨事項について説明します。

寄稿者

著者:

  • Gino Pelliccia | プリンシパル アーキテクト
  • Alex Stepney | リード プリンシパル アーキテクト
  • Phil Bryan | EMEA FSI リード プリンシパル アーキテクト
  • Stathis Onasoglou | EMEA FSI プリンシパル アーキテクト
  • Sam Moss | EMEA FinOps プロフェッショナル サービス リード

その他の寄稿者:

  • Daniel Lees | クラウド セキュリティ アーキテクト
  • Danielle Fisla | 米国 FS ポートフォリオ リード、PSO
  • Filipe Gracio, PhD | カスタマー エンジニア兼 AI / ML スペシャリスト
  • Henry Cheng | プリンシパル アーキテクト
  • John Bacon | パートナー ソリューション アーキテクト
  • Jose Andrade | カスタマー エンジニア兼 SRE スペシャリスト
  • Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
  • Laura Hyatt | カスタマー エンジニア兼 FSI
  • Michael Yang | 業界別ソリューション AI コンサルティング リード、FSI
  • Nicolas Pintaux | カスタマー エンジニア、アプリケーション モダナイゼーション スペシャリスト
  • Omar Saenz | EMEA パートナー エンジニア、セキュリティ
  • Radhika Kanakam | Google Cloud Well-Architected Framework プログラム リード
  • Steve McGhee | 信頼性アドボケイト
  • Tarun Sharma | プリンシパル アーキテクト
  • Yuriy Babenko | カスタマー エンジニア、FSI

FSI の視点: 効果的な運用

Google Cloud Well-Architected Framework: FSI の視点のこのドキュメントでは、 Google Cloudで堅牢な金融サービス業界（FSI）ワークロードを構築、デプロイ、運用するための原則と推奨事項の概要について説明します。これらの推奨事項は、オブザーバビリティ、自動化、スケーラビリティなどの基本的な要素を設定するのに役立ちます。このドキュメントの推奨事項は、Well-Architected Framework のオペレーショナル エクセレンスの柱に沿っています。

FSI ワークロードは規制が厳しく、機密性が高いため、 Google Cloud では運用効率が非常に重要です。オペレーショナル エクセレンスにより、クラウド ソリューションは進化するニーズに適応し、価値、パフォーマンス、セキュリティ、信頼性に関する要件を満たすことができます。これらの分野で障害が発生すると、多額の財務上の損失、規制上の罰則、評判の低下につながる可能性があります。

オペレーショナル エクセレンスは、FSI ワークロードに次のメリットをもたらします。

  • 信頼と評判を維持する: 金融機関は顧客の信頼に大きく依存しています。業務の中断やセキュリティ侵害は、この信頼を大きく損ない、顧客離れを引き起こす可能性があります。運用上の卓越性は、こうしたリスクを最小限に抑えるのに役立ちます。

  • 厳格な規制要件を満たす: FSI は、次のような多数の複雑な規制の対象となります。

    規制遵守を実証し、罰則を回避するには、堅牢な運用プロセス、モニタリング、インシデント管理が不可欠です。

  • ビジネスの継続性と復元性を確保する: 金融市場とサービスは、多くの場合、継続的に運営されています。そのため、高可用性と効果的な障害復旧が最も重要になります。オペレーショナル エクセレンスの原則は、復元性に優れたシステムの設計と実装を導きます。この分野については、信頼性の柱で詳しく説明しています。

  • 機密データを保護する: 金融機関は、機密性の高い顧客データと金融データを大量に処理します。データ漏洩を防ぎ、プライバシーを維持するには、強力な運用管理、セキュリティ モニタリング、迅速なインシデント対応が不可欠です。セキュリティ ピラーでは、この分野に関するガイダンスを提供しています。

  • クリティカル アプリケーションのパフォーマンスを最適化する: 取引プラットフォームやリアルタイム分析など、多くの金融アプリケーションでは、高パフォーマンスと低レイテンシが求められます。これらのパフォーマンス要件を満たすには、高度に最適化されたコンピューティング、ネットワーキング、ストレージの設計が必要です。この点については、パフォーマンス最適化の柱で詳しく説明しています。

  • 費用を効果的に管理する: 金融機関は、セキュリティと信頼性に加えて、費用対効果も重視しています。運用上の優秀性には、リソース使用率の最適化とクラウド費用の管理に関するプラクティスが含まれます。この分野については、費用最適化の柱で詳細なガイダンスを提供しています。

このドキュメントのオペレーショナル エクセレンスの推奨事項は、次の基本原則にマッピングされています。

SLA とそれに対応する SLO / SLI の定義

多くの FSI 組織では、アプリケーションの可用性は通常、目標復旧時間（RTO）と目標復旧時点（RPO）の指標に基づいて分類されます。外部顧客にサービスを提供するビジネス クリティカルなアプリケーションの場合は、サービスレベル契約（SLA）も定義されることがあります。

SLA には、ユーザー満足度の観点からシステムの動作を表す指標のフレームワークが必要です。サイト信頼性エンジニアリング（SRE）の手法は、必要なレベルのシステム信頼性を実現する方法を提供します。指標のフレームワークを作成するには、ユーザーの視点からシステムの健全性を把握するための重要な数値指標を定義してモニタリングします。たとえば、レイテンシやエラー率などの指標は、サービスのパフォーマンスを定量化します。これらの指標は、サービスレベル指標（SLI）と呼ばれます。効果的な SLI を開発することは、信頼性を客観的に評価するために必要な生データを提供するため、非常に重要です。

意味のある SLA、SLI、SLO を定義するには、次の推奨事項を検討してください。

  • 各重要なサービスの SLI を開発して定義します。許容可能なパフォーマンス レベルを定義する目標値を設定します。
  • SLI に対応するサービスレベル目標（SLO）を開発して定義します。たとえば、リクエストの 99.9% のレイテンシが 200 ミリ秒未満である必要があるという SLO を設定できます。
  • サービスが SLO を満たしていない場合に実施する必要がある内部の是正措置を特定します。たとえば、プラットフォームの復元力を高めるために、開発リソースを問題の修正に集中させる必要がある場合があります。
  • 各サービスの SLA 要件を検証し、SLA をサービス ユーザーとの正式な契約として認識します。

サービスレベルの例

次の表に、支払いプラットフォームの SLI、SLO、SLA の例を示します。

ビジネス指標 SLI SLO SLA
支払トランザクションの成功

開始されたすべての支払いトランザクションのうち、正常に処理されて確認されたトランザクションの割合を定量的に測定したものです。

例: （成功したトランザクション数 ÷ 有効なトランザクションの合計数）× 100。5 分間のローリング ウィンドウで測定されます。

特定の期間にわたって、支払い取引の成功率を高い水準で維持するための内部目標。

例: 無効なリクエストと計画メンテナンスを除き、ローリングの 30 日間の期間で 99.98% の支払いトランザクション成功率を維持する。

支払い取引処理の成功率と速度に関する契約上の保証。

例: サービス プロバイダは、クライアントが開始した支払い取引の 99.0% が 1 秒以内に正常に処理され、確認されることを保証します。
お支払い処理のレイテンシ

クライアントによる開始から最終確認までの支払いトランザクションの処理にかかる平均時間。

例: 5 分間のローリング ウィンドウで測定された、トランザクション確認の平均レスポンス時間（ミリ秒単位）。

支払いトランザクションの処理速度に関する内部目標。

例: 30 日間のローリング ウィンドウで、支払いトランザクションの 99.5% が 400 ミリ秒以内に処理されるようにします。

指定された期間内に決済処理に関する重大な問題を解決するという契約上のコミットメント。

例: 重要な支払い処理の問題（トランザクションの 1% 以上に影響する停止と定義）の場合、サービス プロバイダは、問題が報告または検出されてから 2 時間以内に解決することを約束します。
プラットフォームの可用性

コアの支払い処理 API とユーザー インターフェースが動作し、クライアントからアクセスできる時間の割合。

例: （合計運用時間 - ダウンタイム）÷ 合計運用時間 × 100（1 分ごとに測定）。

コア決済プラットフォームの稼働時間に関する内部目標。

例: 予定されたメンテナンスの時間枠を除き、1 暦月あたり 99.995% のプラットフォームの可用性を実現します。

支払いプラットフォームの最小稼働時間に関する、お客様に対する正式な法的拘束力のあるコミットメント。これには、コミットメントを満たせなかった場合の責任も含まれます。

例: プラットフォームは、予定されたメンテナンスの時間枠を除き、各暦月で 99.9% 以上の可用性を維持します。可用性が最低レベルを下回った場合、クライアントは、0.1% の低下ごとに月額サービス料金の 5% のサービス クレジットを受け取ります。

SLI データを使用して、システムが定義された SLO 内にあるかどうかをモニタリングし、SLA が満たされていることを確認します。明確に定義された SLI のセットを使用することで、エンジニアとデベロッパーは次のレベルで FSI アプリケーションをモニタリングできます。

  • アプリケーションがデプロイされているサービス（GKE や Cloud Run など）内。
  • ロードバランサなどのインフラストラクチャ コンポーネントから提供されるログを使用する。

OpenTelemetry は、指標、トレース、ログなど、あらゆる種類のテレメトリーをキャプチャするためのオープンソース標準と一連のテクノロジーを提供します。Google Cloud Managed Service for Prometheus は、指標と Prometheus の大規模な運用のためのフルマネージドでスケーラビリティの高いバックエンドを提供します。

SLI、SLO、エラー バジェットの詳細については、SRE ハンドブックをご覧ください。

効果的なアラートとモニタリングのダッシュボードとメカニズムを開発するには、Google Cloud Observability ツールと Google Cloud モニタリングを併用します。セキュリティ固有のモニタリング機能と検出機能については、セキュリティ ピラーをご覧ください。

インシデント管理プロセスの定義とテスト

明確に定義され、定期的にテストされるインシデント管理プロセスは、 Google Cloudの FSI ワークロードの価値、パフォーマンス、セキュリティ、信頼性に直接貢献します。これらのプロセスは、金融機関が厳格な規制要件を満たし、機密データを保護し、事業継続性を維持し、顧客の信頼を維持するのに役立ちます。

インシデント管理プロセスの定期的なテストには、次のようなメリットがあります。

  • ピーク負荷時のパフォーマンスを維持する: 定期的なパフォーマンス テストと負荷テストを実施することで、金融機関は、クラウドベースのアプリケーションとインフラストラクチャが、パフォーマンスの低下を招くことなく、ピーク時の取引量、市場の変動、その他の高需要のシナリオに対応できることを確認できます。この機能は、シームレスなユーザー エクスペリエンスを維持し、金融市場のニーズを満たすために不可欠です。
  • 潜在的なボトルネックと制限事項を特定する: ストレステストでは、システムを限界までプッシュします。これにより、金融機関は、重要なオペレーションに影響が及ぶ前に、潜在的なボトルネックとパフォーマンスの制限事項を特定できます。この事前対応型のアプローチにより、金融機関はインフラストラクチャとアプリケーションを調整して、最適なパフォーマンスとスケーラビリティを実現できます。
  • 信頼性と復元力を検証する: カオス エンジニアリングやシミュレートされた障害などの定期的なテストは、金融システムの信頼性と復元力を検証するのに役立ちます。このテストにより、システムが障害から正常に復旧し、高可用性を維持できることが保証されます。これは、事業継続に不可欠です。
  • 効果的な容量計画を実施する: パフォーマンス テストでは、さまざまな負荷条件でのリソース使用率に関する貴重なデータが提供されます。これは、正確な容量計画に不可欠です。金融機関は、このデータを使用して、将来の容量ニーズを事前に予測し、リソース制約によるパフォーマンスの問題を回避できます。
  • 新機能とコード変更を正常にデプロイする: 自動テストを CI/CD パイプラインに統合すると、変更と新しいデプロイが本番環境にリリースされる前に、徹底的に検証されます。このアプローチにより、運用の中断につながる可能性のあるエラーや回帰のリスクが大幅に軽減されます。
  • システムの安定性に関する規制要件を満たす: 金融規制では、重要なシステムの安定性と信頼性を確保するために、堅牢なテスト手法を導入することが求められることがよくあります。定期的なテストは、これらの要件への準拠を実証するうえで役立ちます。

インシデント管理プロセスを定義してテストするには、次の推奨事項を検討してください。

明確なインシデント対応手順を確立する

確立された一連のインシデント対応手順には、次の要素が含まれます。

  • インシデント コマンダー、調査担当者、コミュニケーション担当者、技術専門家に対して定義された役割と責任。効果的かつ協調的な対応を確保します。
  • インシデント発生時に情報が迅速かつ効果的に共有されるように定義された、コミュニケーション プロトコルとエスカレーション パス。
  • コミュニケーション、トリアージ、調査、解決の手順を概説するランブックまたはプレイブックに記載されている手順。
  • チームが効果的に対応するための知識とスキルを身につけるための定期的なトレーニングと準備。

パフォーマンス テストと負荷テストを定期的に実装する

定期的なパフォーマンス テストと負荷テストを実施することで、クラウドベースのアプリケーションとインフラストラクチャがピーク時の負荷を処理し、最適なパフォーマンスを維持できるようになります。負荷テストでは、現実的なトラフィック パターンをシミュレートします。ストレステストでは、システムを限界まで動作させて、潜在的なボトルネックとパフォーマンスの制限を特定します。Cloud Load Balancing などのプロダクトや負荷テスト サービスを使用して、実際のトラフィックをシミュレートできます。テスト結果に基づいて、クラウド インフラストラクチャとアプリケーションを調整し、最適なパフォーマンスとスケーラビリティを実現できます。たとえば、リソース割り当てを調整したり、アプリケーション構成を調整したりできます。

CI / CD パイプライン内のテストを自動化する

自動テストを CI/CD パイプラインに組み込むと、デプロイ前に変更を検証することで、クラウド アプリケーションの品質と信頼性を確保できます。このアプローチにより、エラーや回帰のリスクが大幅に軽減され、より安定した堅牢なソフトウェア システムを構築できます。CI/CD パイプラインには、単体テスト、統合テスト、エンドツーエンド テストなど、さまざまな種類のテストを組み込むことができます。Cloud Build や Cloud Deploy などのプロダクトを使用して、CI/CD パイプラインを作成して管理します。

改善とイノベーションを継続的に行う

クラウドの金融サービス ワークロードの場合、クラウドへの移行は最初のステップにすぎません。継続的な強化とイノベーションは、次の理由で不可欠です。

  • イノベーションを加速する: AI などの新しいテクノロジーを活用して、サービスを改善します。
  • コストを削減する: 非効率な部分を排除し、リソースの使用を最適化します。
  • アジリティの強化: 市場や規制の変化に迅速に対応します。
  • 意思決定の改善: BigQuery や Looker などのデータ分析プロダクトを使用して、情報に基づいた選択を行います。

継続的な改善とイノベーションを確保するには、次の推奨事項を検討してください。

定期的に事後検証を行う

振り返りは、インシデント対応手順を継続的に改善し、定期的なパフォーマンス テストと負荷テストの結果に基づいてテスト戦略を最適化するために不可欠です。レトロスペクティブを効果的に行うには、次のことを行います。

  • チームに、経験を振り返り、うまくいったことを特定し、改善すべき点を特定する機会を与えます。
  • プロジェクトのマイルストーン、重大なインシデント、重要なテスト サイクルの後に、振り返りを行います。チームは成功と失敗の両方から学び、プロセスとプラクティスを継続的に改善できます。
  • 開始-停止-継続モデルなどの構造化されたアプローチを使用して、振り返りセッションが生産的で、実行可能なステップにつながるようにします。
  • 振り返りを使用して、変更管理の自動化をさらに強化して信頼性を高め、リスクを軽減できる領域を特定します。

学びの文化を育てる

学習文化は、Google Cloudでの新しいテクノロジーの安全な探索を促進します。たとえば、AI や ML の機能を活用して、不正行為の検出やパーソナライズされた財務アドバイスなどのサービスを強化します。学習文化を促進するには、次のことを行います。

  • チームが実験を行い、知識を共有し、継続的に学習することを奨励します。
  • 失敗を成長と改善の機会と捉える、誰も責めない文化を採用します。
  • チームがリスクを冒して革新的なソリューションを検討できる、心理的に安全な環境を構築します。チームは成功と失敗の両方から学び、より回復力と適応力のある組織につながります。
  • インシデント管理プロセスとテスト演習から得られた知識の共有を促進する文化を育みます。

クラウド テクノロジーの最新情報を入手する

継続的な学習は、新しいセキュリティ対策を理解して実装し、高度なデータ分析を活用してより優れた分析情報を取得し、金融業界に関連する革新的なソリューションを採用するために不可欠です。

  • 最新の進歩、機能、ベスト プラクティスに関する情報を常に把握することで、 Google Cloud サービスの可能性を最大限に引き出します。
  • 新しい機能とサービスが導入されたら、プロセスをさらに自動化し、セキュリティを強化し、アプリケーションのパフォーマンスとスケーラビリティを向上させる機会を特定します。 Google Cloud
  • 関連するカンファレンス、ウェビナー、トレーニング セッションに参加して、知識を広げ、新機能を理解します。
  • チームメンバーに Google Cloud 認定資格の取得を促し、組織がクラウドで成功するために必要なスキルを確実に身につけられるようにします。

FSI の視点: セキュリティ、プライバシー、コンプライアンス

Google Cloud Well-Architected Framework: FSI の視点のこのドキュメントでは、 Google Cloudの金融サービス業界（FSI）ワークロードのセキュリティ、プライバシー、コンプライアンスの要件に対応するための原則と推奨事項の概要について説明します。推奨事項は、復元力とコンプライアンスに優れたインフラストラクチャの構築、機密データの保護、顧客の信頼の維持、複雑な規制要件への対応、サイバー脅威の効果的な管理に役立ちます。このドキュメントの推奨事項は、Well-Architected Framework のセキュリティの柱に沿っています。

クラウド コンピューティングのセキュリティは、FSI 組織にとって重要な懸念事項です。FSI 組織は、顧客の詳細情報や財務記録など、大量の機密データを管理しているため、サイバー犯罪者にとって非常に魅力的な標的となります。セキュリティ侵害の結果は非常に深刻で、多額の経済的損失、長期にわたる評判の低下、多額の規制上の罰金などが考えられます。したがって、FSI ワークロードには厳格なセキュリティ管理が必要です。

包括的なセキュリティとコンプライアンスを確保するには、お客様（FSI 組織）と Google Cloudの間の責任共有を理解する必要があります。 Google Cloud は、物理的セキュリティやネットワーク セキュリティなど、基盤となるインフラストラクチャの保護を担当します。お客様は、データとアプリケーションの保護、アクセス制御の構成、セキュリティ サービスの構成と管理を行う責任があります。セキュリティ対策を支援するため、Google Cloud パートナー エコシステムでは、セキュリティ統合とマネージド サービスを提供しています。

このドキュメントのセキュリティに関する推奨事項は、次の基本原則にマッピングされています。

安全性を重視した設計を実装する

Payment Card Industry Data Security Standard（PCI DSS）、米国の Gramm-Leach-Bliley Act（GLBA）、さまざまな国の金融データ保護法などの金融規制では、セキュリティを最初からシステムに統合することが義務付けられています。設計によるセキュリティの原則は、開発ライフサイクル全体にセキュリティを統合して、最初から脆弱性を最小限に抑えることを重視しています。

Google Cloudの FSI ワークロードに設計によるセキュリティ原則を適用するには、次の推奨事項を検討してください。

  • Identity and Access Management（IAM）で、きめ細かいロールベース アクセス制御（RBAC）を適用して最小権限の原則を適用し、必要な権限のみが付与されるようにします。RBAC の使用は、多くの金融規制で重要な要件となっています。
  • VPC Service Controls を使用して、 Google Cloud 内の機密性の高いサービスとデータの周囲にセキュリティ境界を適用します。セキュリティ境界は、規制で義務付けられているように、機密データとリソースをセグメント化して保護し、データの引き出しや不正アクセスを防ぐのに役立ちます。
  • Terraform などの Infrastructure as Code（IaC）ツールを使用して、セキュリティ構成をコードとして定義します。このアプローチでは、初期のデプロイ フェーズからセキュリティ制御が組み込まれるため、一貫性と監査可能性を確保できます。
  • 静的アプリケーション セキュリティ テスト（SAST）を Cloud Build を使用して CI/CD パイプラインに統合し、アプリケーション コードをスキャンします。自動化されたセキュリティ ゲートを確立して、準拠していないコードのデプロイを防ぎます。
  • Security Command Center を使用して、セキュリティ分析のための統合インターフェースを提供します。Security Command Center を使用すると、規制違反につながる可能性のある構成ミスや脅威を継続的にモニタリングし、早期に検出できます。ISO 27001 や NIST 800-53 などの標準の要件を満たすには、ポスチャー管理テンプレートを使用します。
  • 本番環境のデプロイで特定された脆弱性の減少と、セキュリティのベスト プラクティスに準拠している IaC デプロイの割合を追跡します。Security Command Center を使用すると、脆弱性とセキュリティ標準への準拠に関する情報を検出して表示できます。詳細については、脆弱性の検出結果をご覧ください。

ゼロトラストを実装する

現代の金融規制では、厳格なアクセス制御と継続的な検証の必要性がますます強調されています。これらの要件は、内部と外部の両方の脅威と悪意のある行為者からワークロードを保護することを目的としたゼロトラストの原則を反映しています。ゼロトラストの原則では、すべてのユーザーとデバイスの継続的な検証が推奨されています。これにより、暗黙的な信頼が排除され、ラテラル ムーブメントが軽減されます。

ゼロトラストを実装するには、次の推奨事項を検討してください。

  • IAM 制御と Chrome Enterprise Premium を組み合わせることで、ユーザー ID、デバイスのセキュリティ、場所などの要素に基づいてコンテキストアウェア アクセスを有効にできます。このアプローチにより、財務データとシステムへのアクセスが許可される前に継続的な検証が実施されます。
  • Identity Platform（または Workforce Identity 連携を使用する場合は外部 ID プロバイダ）を構成して、安全でスケーラブルな ID とアクセス管理を提供します。ゼロトラストの実装と規制遵守の確保に不可欠な多要素認証（MFA）などの制御を設定します。
  • すべてのユーザー アカウント、特に機密データやシステムにアクセスできるアカウントに MFA を実装します。
  • ユーザー アクセスとネットワーク アクティビティの包括的なロギングとモニタリングを確立することで、規制遵守に関連する監査と調査をサポートします。
  • Private Service Connect を使用して、Google Cloud 内のサービスとオンプレミス環境間のプライベートで安全な通信を有効にします。これにより、トラフィックが公共のインターネットに公開されることはありません。
  • VPN トンネルなどのネットワーク ベースのセキュリティ メカニズムに依存するのではなく、Identity-Aware Proxy（IAP）を使用して、きめ細かい ID 制御を実装し、アプリケーション レベルでアクセスを承認します。このアプローチは、環境内のラテラル ムーブメントを減らすのに役立ちます。

シフトレフト セキュリティを実装する

金融規制当局は、予防的なセキュリティ対策を推奨しています。開発ライフサイクルの早い段階で脆弱性を特定して対処することで、セキュリティ インシデントのリスクと、コンプライアンス違反の罰則を受ける可能性を軽減できます。シフトレフト セキュリティの原則は、早期のセキュリティ テストと統合を促進し、修復のコストと複雑さを軽減します。

シフトレフト セキュリティを実装するには、次の推奨事項を検討してください。

  • Cloud Build を使用して、コンテナの脆弱性スキャンや静的コード解析などのセキュリティ スキャン ツールを CI/CD パイプラインに統合し、開発プロセスの早い段階で自動セキュリティ チェックを実施します。

  • Artifact Registry を使用して、ソフトウェア パッケージとコンテナ イメージ用の安全で一元化されたリポジトリを統合された脆弱性スキャンとともに提供し、安全なアーティファクトのみがデプロイされるようにします。仮想リポジトリを使用して、リモート リポジトリよりもプライベート アーティファクトを優先することで、依存関係の混乱攻撃を軽減します。

  • Security Command Center の一部である Web Security Scanner を開発パイプラインに統合して、ウェブ アプリケーションを自動的にスキャンし、一般的な脆弱性を検出します。

  • ソフトウェア アーティファクトのサプライ チェーン レベル（SLSA）フレームワークを使用して、ソースコード、ビルドプロセス、コードの来歴のセキュリティ チェックを実装します。Binary Authorization などのソリューションを使用して、環境で実行されるワークロードの出所を適用します。Assured Open Source を使用して、ワークロードで検証済みのオープンソース ソフトウェア ライブラリのみが使用されるようにします。

  • 開発ライフサイクルで特定および修復された脆弱性の数、セキュリティ スキャンに合格したコード デプロイの割合、ソフトウェアの脆弱性によって発生したセキュリティ インシデントの減少を追跡します。 Google Cloud には、さまざまな種類のワークロードの追跡に役立つツールが用意されています。たとえば、コンテナ化されたワークロードの場合は、Artifact Registry のコンテナ スキャン機能を使用します。

プリエンプティブなサイバー防御を実装する

金融機関は、高度なサイバー攻撃の格好の標的です。規制では、堅牢な脅威インテリジェンスとプロアクティブな防御メカニズムが求められることがよくあります。予防的なサイバー防御は、高度な分析と自動化を使用して、脅威のプロアクティブな検出と対応に重点を置いています。

以下の推奨事項を参考にしてください。

  • Mandiant の脅威インテリジェンス、インシデント対応、セキュリティ検証サービスを使用して、潜在的な脅威を事前に特定して軽減します。
  • Google Cloud Armor を使用して、ネットワーク エッジでウェブ アプリケーションと API をウェブ エクスプロイトと DDoS 攻撃から保護します。
  • Security Command Center を使用して、セキュリティの検出結果と推奨事項を集計して優先順位を付けます。これにより、セキュリティ チームは潜在的なリスクに事前に対処できます。
  • 定期的なセキュリティ シミュレーションとペネトレーション テストを実施して、予防的防御とインシデント対応計画を検証します。
  • セキュリティ インシデントの検出と対応に要する時間、DDoS 軽減策の有効性、防止されたサイバー攻撃の数を測定します。必要な指標とデータは、Google Security Operations SOAR と SIEM のダッシュボードから取得できます。

AI を安全かつ責任を持って使用し、セキュリティに AI を活用する

AI と ML は、不正行為の検出やアルゴリズム取引などの金融サービス ユースケースでますます使用されています。規制では、これらのテクノロジーを倫理的、透明性、安全性の高い方法で使用することが求められています。AI はセキュリティ機能の強化にも役立ちます。AI の使用に関する次の推奨事項を検討してください。

  • Vertex AI を使用して、安全で管理された環境で ML モデルを開発してデプロイします。モデルの説明可能性や公平性指標などの機能は、責任ある AI に関する懸念に対処するのに役立ちます。
  • Google Security Operations のセキュリティ分析と運用の機能を活用します。この機能は、AI と ML を使用して大量のセキュリティ データを分析し、異常を検出し、脅威対応を自動化します。これらの機能は、全体的なセキュリティ体制の強化とコンプライアンス モニタリングに役立ちます。
  • セキュリティと倫理に関する考慮事項を含め、AI と ML の開発とデプロイに関する明確なガバナンス ポリシーを確立します。
  • セキュア AI フレームワーク（SAIF）の要素に沿って、AI システムのセキュリティとリスクに関する懸念事項に対処するための実践的なアプローチを提供します。
  • AI を活用した不正検出システムの精度と有効性、セキュリティ アラートの誤検知の削減、AI を活用したセキュリティ自動化による効率の向上を追跡します。

規制、コンプライアンス、プライバシーのニーズに対応する

金融サービスは、データ所在地要件、特定の監査証跡、データ保護基準など、さまざまな規制の対象となります。センシティブ データが適切に識別、保護、管理されるようにするには、FSI 組織に堅牢なデータ ガバナンス ポリシーとデータ分類スキームが必要です。規制要件を満たすために、次の推奨事項を検討してください。

  • Assured Workloads を使用して、機密性の高いワークロードと規制対象のワークロードの Google Cloud にデータ境界を設定します。これにより、FedRAMP や CJIS などの政府や業界固有のコンプライアンス要件を満たすことができます。
  • Cloud Data Loss Prevention（Cloud DLP）を実装して、財務情報などの機密データを特定、分類、保護します。これにより、GDPR や CCPA などのデータ プライバシー規制を遵守できます。
  • Cloud Audit Logs を使用して、管理アクティビティとリソースへのアクセスの詳細を追跡します。これらのログは、多くの金融規制で規定されている監査要件を満たすために不可欠です。
  • ワークロードとデータのGoogle Cloud リージョンを選択する場合は、データ所在地に関連する現地の規制を考慮してください。 Google Cloud グローバル インフラストラクチャを使用すると、データ所在地の要件を満たすのに役立つリージョンを選択できます。
  • Cloud Key Management Service を使用して、保存時と転送時に機密性の高い財務データの暗号化に使用される鍵を管理します。このような暗号化は、セキュリティとプライバシーに関する多くの規制の基本的な要件です。
  • 規制要件に対応するために必要な制御を実装します。コントロールが想定どおりに機能することを確認します。外部監査人によってコントロールを再度検証し、ワークロードが規制に準拠していることを規制当局に証明します。

セキュリティ イニシアチブの優先順位付けを行う

セキュリティ要件の幅広さを考慮すると、金融機関はリスク評価と規制要件に基づくイニシアチブを優先する必要があります。次の段階的なアプローチをおすすめします。

  1. 強固なセキュリティ基盤を確立する: ID とアクセス管理、ネットワーク セキュリティ、データ保護など、セキュリティのコア領域に重点を置きます。この重点的な取り組みにより、堅牢なセキュリティ体制を構築し、進化する脅威に対する包括的な防御を確保できます。
  2. 重要な規制に対応する: PCI DSS、GDPR、関連する国内法などの重要な規制の遵守を優先します。これにより、データ保護が確保され、法的リスクが軽減され、顧客との信頼関係が構築されます。
  3. 高度なセキュリティを実装する: ゼロトラスト、AI を活用したセキュリティ ソリューション、プロアクティブな脅威ハンティングなどの高度なセキュリティ対策を段階的に導入します。

金融サービス業界の視点: 信頼性

Google Cloud Well-Architected Framework: FSI の視点のこのドキュメントでは、Google Cloudで信頼性の高い金融サービス業界（FSI）のワークロードを設計、デプロイ、運用するための原則と推奨事項の概要について説明します。このドキュメントでは、高度な信頼性プラクティスとオブザーバビリティをアーキテクチャ ブループリントに統合する方法について説明します。このドキュメントの推奨事項は、Well-Architected Framework の信頼性の柱に沿っています。

金融機関にとって、信頼性と復元力に優れたインフラストラクチャは、ビジネス上のニーズと規制上の義務の両方です。Google Cloud の FSI ワークロードの信頼性を確保するには、潜在的な障害点を理解して軽減し、リソースを冗長的にデプロイして、復旧を計画する必要があります。運用の復元力は信頼性の結果です。これは、中断を吸収し、適応し、復旧する能力です。運用の復元力は、FSI 組織が厳格な規制要件を満たすのに役立ちます。また、お客様に許容できない損害が生じるのを防ぐこともできます。

Google Cloud の信頼性の重要な構成要素は、リージョン、ゾーン、クラウド リソースのさまざまなロケーション スコープ（ゾーン、リージョン、マルチリージョン、グローバル）です。マネージド サービスの使用、リソースの分散、高可用性パターンの実装、プロセスの自動化により、可用性を向上させることができます。

規制要件

FSI 組織は、米国の Federal Reserve System、EU の European Banking Authority、英国の Prudential Regulation Authority などの規制機関による厳格な信頼性要件の下で運営されています。世界中の規制当局は、金融の安定性と消費者保護に不可欠なオペレーショナル レジリエンスを重視しています。オペレーショナル レジリエンスとは、中断に耐え、効果的に復旧し、重要なサービスを維持する能力のことです。これには、技術的なリスクと第三者への依存関係を管理するための調和のとれたアプローチが必要です。

ほとんどの法域の規制要件には、次の共通のテーマがあります。

  • サイバーセキュリティと技術的な復元力: サイバー脅威に対する防御を強化し、IT システムの復元力を確保します。
  • サードパーティ リスク管理: 情報通信技術（ICT）のプロバイダへのサービスのアウトソーシングに関連するリスクを管理します。
  • 事業継続とインシデント対応: 混乱時に重要なオペレーションを維持し、効果的に復旧するための堅牢な計画。
  • 金融の安定性を保護する: 金融システム全体の健全性と安定性を確保します。

このドキュメントの信頼性に関する推奨事項は、次の基本原則にマッピングされています。

マルチゾーンとマルチリージョンのデプロイを優先する

重要な金融サービス アプリケーションには、少なくとも 2 つのリージョンと、各リージョン内の 3 つのゾーンに分散されたマルチリージョン トポロジを使用することをおすすめします。このアプローチは、ゾーンとリージョンの停止に対する復元力を高めるうえで重要です。1 つのゾーンまたはリージョンで障害が発生した場合、ほとんどの法域では、2 つ目のゾーンで重大な中断が発生する可能性が高いと見なされるため、このアプローチが規制で規定されていることがよくあります。1 つのロケーションで障害が発生すると、他のロケーションで異常に大量の追加トラフィックが発生する可能性があるためです。

ゾーンとリージョンの停止に対する復元力を構築するには、次の推奨事項を検討してください。

  • 位置情報の範囲が広いリソースを優先します。可能であれば、ゾーンリソースではなくリージョン リソースを使用し、リージョン リソースではなくマルチリージョン リソースまたはグローバル リソースを使用します。このアプローチは、バックアップを使用してオペレーションを復元する必要性を回避するのに役立ちます。
  • 各リージョンで、2 つではなく 3 つのゾーンを活用します。フェイルオーバーを処理するには、見積もりよりも 3 分の 1 ほど容量をオーバー プロビジョニングします。
  • 次の例のように、アクティブ / アクティブ デプロイを実装して、手動復元の手順を最小限に抑えます。
    • Spanner などの分散データベースは、リージョン間の冗長性と同期を組み込みで提供します。
    • Cloud SQL の HA 機能は、ゾーン間の読み取りレプリカを使用して、アクティブ / アクティブに近いトポロジを提供します。リージョン間の目標復旧時点（RPO）は 0 に近い値になります。
  • Cloud DNS を使用してリージョン間でユーザー トラフィックを分散し、各リージョンにリージョン ロードバランサをデプロイします。要件と重要度に応じて、グローバル ロードバランサを検討することもできます。詳細については、マルチリージョン デプロイでのグローバル ロード バランシングの利点とリスクをご覧ください。
  • データを保存するには、Spanner や Cloud Storage などのマルチリージョン サービスを使用します。

単一障害点を排除する

リソースを異なるロケーションに分散し、冗長リソースを使用して、単一障害点（SPOF）がアプリケーション スタック全体に影響しないようにします。

SPOF を回避するには、次の推奨事項を検討してください。

詳細については、 Google Cloudのワークロードに適した信頼性の高いインフラストラクチャを設計するをご覧ください。

集約の可用性を理解して管理する

システムの全体的な可用性または集約された可用性は、システムの各階層またはコンポーネントの可用性の影響を受けることに注意してください。アプリケーション スタックの階層数は、スタックの総可用性とは逆の関係です。集約の可用性を管理する際は、次の推奨事項を検討してください。

  • tier1_availability × tier2_availability × tierN_availability の式を使用して、多層スタックの総可用性を計算します。

    次の図は、4 つのサービスで構成されるマルチティア システムの集約可用性の計算を示しています。

    4 つのサービスがあるマルチティア サービスの集計可用性の式。

    上の図では、各階層のサービスは 99.9% の可用性を提供しますが、システムの総可用性は 99.6%（0.999 × 0.999 × 0.999 × 0.999）と低くなります。一般に、多層スタックの総可用性は、可用性が最も低い階層の可用性よりも低くなります。

  • 可能な場合は、チェーンよりも並列化を選択します。並列化されたサービスでは、エンドツーエンドの可用性は個々のサービスの可用性よりも高くなります。

    次の図は、チェーンと並列化のアプローチを使用してデプロイされた 2 つのサービス A と B を示しています。

    チェーン化されたサービスと並列化されたサービスを比較した、集計可用性の式。

    上記の例では、両方のサービスの SLA が 99% であるため、実装アプローチに応じて次の集計可用性が得られます。

    • チェーン化されたサービスの可用性は、98%（0.99 × 0.99）にしかなりません。
    • 並列化されたサービスでは、各サービスが独立して実行され、個々のサービスが他のサービスの可用性の影響を受けないため、集約された可用性が 99.99% と高くなります。集約された並列化サービスの式は 1 − (1 − A) × (1 − B) です。

  • アプリケーション スタックに必要な全体的な稼働時間を満たすのに役立つ、稼働時間 SLA を備えた Google Cloud サービスを選択します。

  • アーキテクチャを設計する際は、可用性、運用の複雑さ、レイテンシ、費用のトレードオフを考慮してください。一般的に、可用性の 9 の数を増やすとコストが増加しますが、規制要件を満たすことができます。

    たとえば、99.9% の可用性（スリー ナイン）は、24 時間の 1 日で 86 秒のダウンタイムが発生する可能性があることを意味します。一方、99%（ツーナイン）は、同じ期間で 864 秒のダウンタイムを意味します。これは、スリーナインの可用性よりも 10 倍長いダウンタイムです。

    重要な金融サービスの場合、アーキテクチャ オプションが制限されることがあります。ただし、可用性の要件を特定し、可用性を正確に計算することが重要です。このような評価を行うことで、設計上の決定がアーキテクチャと予算に与える影響を評価できます。

堅牢な DR 戦略を実装する

ゾーン停止やリージョン停止など、さまざまな障害シナリオに対応した明確な計画を作成します。明確に定義された障害復旧（DR）戦略により、中断から復旧し、影響を最小限に抑えて通常の運用を再開できます。

DR と高可用性（HA）は異なるコンセプトです。一般に、クラウド デプロイでは、DR はマルチリージョン デプロイに適用され、HA はリージョン デプロイに適用されます。これらのデプロイ アーキタイプは、さまざまなレプリケーション メカニズムをサポートしています。

  • HA: 多くのマネージド サービスでは、デフォルトで単一リージョン内のゾーン間で同期レプリケーションが行われます。このようなサービスは、目標復旧時間（RTO）と目標復旧時点（RPO）がゼロまたはほぼゼロです。このサポートにより、SPOF のないアクティブ / アクティブ デプロイ トポロジを作成できます。
  • DR: 複数のリージョンにデプロイされるワークロードの場合、マルチリージョン サービスまたはグローバル サービスを使用しない場合は、レプリケーション戦略を定義する必要があります。レプリケーション戦略は通常、非同期です。このようなレプリケーションが重要なアプリケーションの RTO と RPO に与える影響を慎重に評価します。フェイルオーバーに必要な手動または半自動のオペレーションを特定します。

金融機関の場合、フェイルオーバー リージョンの選択は、データ主権とデータ所在地に関する規制によって制限されることがあります。2 つのリージョンにまたがるアクティブ / アクティブ トポロジが必要な場合は、特にデータ レプリケーションが重要な場合に、Spanner や Cloud Storage などのマネージド マルチリージョン サービスを選択することをおすすめします。

以下の推奨事項を参考にしてください。

  • データにマネージド マルチリージョン ストレージ サービスを使用します。
  • 永続ディスク内のデータのスナップショットを作成し、マルチリージョン ロケーションに保存します。
  • リージョン リソースまたはゾーンリソースを使用する場合は、他のリージョンへのデータ レプリケーションを設定します。
  • DR 計画を定期的にテストして、計画が有効であることを確認します。
  • RTO と RPO、およびそれらと管轄区域の金融規制で規定されている影響許容度との相関関係を把握します。

詳細については、クラウド インフラストラクチャの停止に対する障害復旧の設計をご覧ください。

マネージド サービスを活用する

可能な場合は、マネージド サービスを使用して、バックアップ、HA、スケーラビリティの組み込み機能を利用します。マネージド サービスを使用する際の推奨事項は次のとおりです。

  • Google Cloudでマネージド サービスを使用します。SLA に基づく HA を提供します。また、バックアップ メカニズムと復元力機能も備えています。
  • データ管理には、Cloud SQL、Cloud Storage、Spanner などのサービスを検討してください。
  • コンピューティングとアプリケーション ホスティングには、Compute Engine マネージド インスタンス グループ（MIG）と Google Kubernetes Engine（GKE）クラスタを検討してください。リージョン MIG と GKE リージョン クラスタは、ゾーンの停止に対する復元力を備えています。
  • リージョンの停止に対する復元力を高めるには、マネージド マルチリージョン サービスを使用します。
  • 独自の特性を持つサービスについて撤退計画の必要性を特定し、必要な計画を定義します。FCA、PRA、EBA などの金融規制当局は、クラウド プロバイダとの関係が終了した場合に、データ取得と運用の継続性に関する戦略と緊急時対応計画を企業に要求しています。企業は、クラウド契約を締結する前に移行の実現可能性を評価し、運用の中断なしにプロバイダを変更できる能力を維持する必要があります。
  • 選択したサービスが、CSV、Parquet、Avro などのオープン形式へのデータのエクスポートをサポートしていることを確認します。サービスがオープン テクノロジーに基づいているかどうかを確認します。たとえば、Open Container Initiative（OCI）形式の GKE サポートや、Apache Airflow 上に構築された Cloud Composer などです。

インフラストラクチャのプロビジョニングと復旧のプロセスを自動化する

自動化により、人的ミスを最小限に抑え、インシデントへの対応に必要な時間とリソースを削減できます。自動化を使用すると、障害からの復旧が迅速になり、結果の一貫性が高まります。リソースのプロビジョニングと復元を自動化するには、次の推奨事項を検討してください。

  • Terraform などの Infrastructure as Code（IaC）ツールを使用して、人的ミスを最小限に抑えます。
  • フェイルオーバー プロセスを自動化して、手動による介入を減らします。自動レスポンスを使用すると、障害の影響を軽減することもできます。たとえば、Eventarc または Workflows を使用して、監査ログで検出された問題に対応して修復アクションを自動的にトリガーできます。
  • オートスケーリングを使用して、フェイルオーバー中にクラウド リソースの容量を増やします。
  • プラットフォーム エンジニアリングを採用して、サービス デプロイ時にクラウド トポロジー全体にわたって規制要件のポリシーとガードレールを自動的に適用します。

FSI の視点: 費用の最適化

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 を使用します。

FSI の視点: パフォーマンスの最適化

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

パフォーマンスの最適化は、金融サービスで長い歴史があります。FSI 組織が技術的な課題を克服するのに役立ち、新しいビジネスモデルの作成を可能にするか、加速させるものとして、ほぼ常に機能してきました。たとえば、ATM（1967 年に導入）は現金の払い出しプロセスを自動化し、銀行がコアビジネスのコストを削減するのに役立ちました。OS カーネルのバイパスや、コンピューティング コアへのアプリケーション スレッドの固定などの手法により、取引アプリケーションの決定性と低レイテンシを実現しました。レイテンシの短縮により、金融市場のスプレッドが縮小し、流動性が高まりました。

クラウドは、パフォーマンスの最適化に新たな機会をもたらします。また、これまで受け入れられてきた最適化パターンの一部にも異議を唱えています。具体的には、次のトレードオフはクラウドでより透明性が高く、制御可能です。

  • 製品化までの時間と費用のバランス。
  • システム レベルのエンドツーエンドのパフォーマンスとノードレベルのパフォーマンス。
  • 人材の可用性とテクノロジー関連の意思決定の俊敏性。

たとえば、特定のスキル要件に合わせてハードウェアと IT リソースを調整することは、クラウドでは簡単なタスクです。GPU プログラミングをサポートするために、GPU ベースの VM を簡単に作成できます。クラウドで容量をスケーリングして、リソースを過剰にプロビジョニングすることなく需要の急増に対応できます。この機能により、非農業部門雇用者数の発表日や取引量が過去の水準を大幅に上回る場合など、ワークロードがピーク時の負荷を処理できるようになります。個々のサーバー レベルで高度に最適化されたコード（C 言語で高度にチューニングされたコードなど）の作成や、従来のハイ パフォーマンス コンピューティング（HPC）環境用のコードの作成に時間を費やす代わりに、適切に設計された Kubernetes ベースの分散システムを使用して、最適なスケールアウトを実現できます。

このドキュメントのパフォーマンス最適化の推奨事項は、次の基本原則にマッピングされています。

テクノロジーのパフォーマンス指標を主要なビジネス指標に合わせる

パフォーマンスの最適化をビジネス価値の成果にマッピングする方法はいくつかあります。たとえば、バイサイドのリサーチ デスクでは、ビジネス目標として、リサーチ時間あたりのアウトプットを最適化することや、シャープ レシオが高いなど、実績のあるチームの実験を優先することが考えられます。販売側では、分析を使用してクライアントの関心を追跡し、最も関心の高い研究をサポートする AI モデルへのスループットを優先順位付けできます。

パフォーマンスの目標をビジネスの重要業績評価指標（KPI）に結び付けることも、パフォーマンスの改善に資金を投入するうえで重要です。ビジネスのイノベーションと変革の取り組み（change-the-bank の取り組みとも呼ばれます）には、異なる予算が割り当てられており、通常業務（BAU）や run-the-bank の運用と比較して、リソースへのアクセス権が異なる可能性があります。たとえば、 Google Cloud は、G-SIFI のリスク管理チームとテクノロジー チームが、フロント オフィス定量アナリストと協力して、リスク分析計算（XVA など）を数時間または数日ではなく数分で実行するソリューションを開発するのに役立ちました。このソリューションにより、組織は関連するコンプライアンス要件を満たすことができました。また、トレーダーは顧客との会話の質を高めることができ、スプレッドの縮小、流動性の強化、費用対効果の高いヘッジが可能になりました。

パフォーマンス指標をビジネス指標に合わせる際は、次の推奨事項を考慮してください。

  • 各テクノロジー イニシアチブを、収益や利益の増加、コストの削減、リスクの軽減など、関連するビジネスの目標と主要成果（OKR）に結び付けます。
  • システム レベルでのパフォーマンスの最適化に重点を置きます。従来の change-the-bank と run-the-bank の分離や、フロント オフィスとバック オフィスのサイロ化を超えて、

未確認のリスクのためにパフォーマンスを犠牲にすることなく、セキュリティを優先する

FSI 組織のセキュリティと規制コンプライアンスは、間違いなく高い水準でなければなりません。高い基準を維持することは、顧客の喪失を回避し、組織のブランドに修復不可能な損害が発生するのを防ぐために不可欠です。多くの場合、最も高い価値は、生成 AI などのテクノロジー イノベーションや、Spanner などの独自のマネージド サービスを通じて得られます。運用リスクが大きすぎる、または規制遵守の姿勢が不十分であるという誤解に基づいて、このような技術オプションを自動的に破棄しないでください。

Google Cloud は、G-SIFI と緊密に連携し、マネー ロンダリング防止（AML）のための AI ベースのアプローチを、金融機関が顧客にサービスを提供しているすべての法域で使用できるようにしています。たとえば、HSBC は、次の結果により、金融犯罪（Fincrime）部門のパフォーマンスを大幅に向上させました。

  • 確認された不審なアクティビティが約 2 ～ 4 倍増加します。
  • 誤検出を 60% 以上削減し、リスクの高い、対応が必要なアラートを集中的に調査することで、運用コストを削減できます。
  • 規制遵守をサポートする監査可能で説明可能な出力。

以下の推奨事項を参考にしてください。

  • 使用する予定のプロダクトが、事業を展開する地域のセキュリティ、復元性、コンプライアンスの要件を満たすのに役立つことを確認します。この目標を達成するため、 Google Cloudアカウント チーム、リスクチーム、プロダクト チームと連携します。
  • AI の説明可能性（Shapley 値の帰属など）を活用して、より強力なモデルを作成し、顧客に透明性を提供します。Shapley 値アトリビューションなどの手法を使用すると、モデルの決定を入力レベルの特定の特徴に帰属させることができます。

  • ソースの引用、グラウンディング、RAG などの手法を使用して、生成 AI ワークロードの透明性を実現します。

  • 説明可能性が十分でない場合は、バリューストリームで意思決定ステップを分離し、意思決定以外のステップのみを AI で自動化します。場合によっては、説明可能な AI では不十分であったり、規制上の懸念（GDPR 第 22 条など）によりプロセスに人間の介入が必要になることがあります。このような場合は、人間のエージェントが意思決定に必要なすべての情報を 1 つのコントロール パネルに表示しますが、データの収集、取り込み、操作、要約のタスクは自動化します。

新しい機会と要件に対応するためにアーキテクチャを再考する

既存のアーキテクチャをクラウドベースの機能で拡張すると、大きなメリットが得られます。より大きな変革を実現するには、クラウド ファーストのアプローチを使用してアーキテクチャを定期的に見直す必要があります。

パフォーマンスをさらに最適化するために、ワークロードのアーキテクチャを定期的に再検討する際は、次の推奨事項を検討してください。

オンプレミス HPC システムとスケジューラに代わるクラウドベースのシステムを使用する

弾力性の向上、セキュリティ体制の改善、広範なモニタリングとガバナンス機能を活用するには、クラウドで HPC ワークロードを実行するか、オンプレミス ワークロードをクラウドにバーストします。ただし、投資戦略のシミュレーションや XVA モデリングなどの特定の数値モデリング ユースケースでは、Kubernetes と Kueue を組み合わせることで、より強力なソリューションを実現できる可能性があります。

シミュレーションのグラフベースのプログラミングに切り替える

モンテカルロ シミュレーションは、Dataflow などのグラフベースの実行システムで大幅にパフォーマンスが向上する可能性があります。たとえば、HSBC は Dataflow を使用して、以前のアプローチと比較して 16 倍の速さでリスク計算を実行しています。

クラウドベースの取引所と取引プラットフォームを運営する

お客様との会話から、市場と取引アプリケーションのパフォーマンス要件にパレートの 80/20 の法則が当てはまることがわかりました。 Google Cloud

  • 取引アプリケーションの 80% 以上は、極めて低いレイテンシを必要としません。ただし、クラウドの復元力、セキュリティ、伸縮性の機能から大きなメリットを得られます。たとえば、外国為替マルチディーラー プラットフォームである BidFX は、クラウドを使用して新製品を迅速にリリースし、リソースを増やすことなく可用性とフットプリントを大幅に拡大しています。
  • 残りのアプリケーション（20% 未満）では、低レイテンシ（1 ミリ秒未満）、決定論性、メッセージ配信の公平性が必要です。従来、これらのシステムは、厳格で高価なコロケーション施設で実行されていました。このカテゴリのアプリケーションも、エッジまたはクラウド ファースト アプリケーションとして、クラウドでリプラットフォームされることが増えています。

現在と将来のビジネスニーズに対応できるようテクノロジーを将来にわたって活用

これまで、多くの FSI 組織は競争優位性を獲得するために独自のテクノロジーを構築してきました。たとえば、2000 年代初頭には、成功を収めた投資銀行や取引会社が、pub-sub システムやメッセージ ブローカーなどの基盤となるテクノロジーを独自に実装していました。オープンソース テクノロジーとクラウドの進化により、このようなテクノロジーはコモディティ化され、ビジネス価値の向上にはつながりません。

テクノロジーを将来にわたって活用するために、次の推奨事項を検討してください。

データ アズ ア サービス（DaaS）アプローチを採用して、市場投入までの時間を短縮し、コストの透明性を高める

FSI 組織は、多くの場合、有機的成長と合併・買収（M&A）の組み合わせによって進化します。そのため、組織は異なるテクノロジーを統合する必要があります。また、データベンダー、データライセンス、統合ポイントなどの重複するリソースを管理する必要もあります。 Google Cloud は、合併後の統合で差別化された価値を生み出す機会を提供します。

たとえば、BigQuery 共有などのサービスを使用して、分析対応のデータ アズ ア サービス（DaaS）プラットフォームを構築できます。このプラットフォームは、市場データと代替ソースからの入力の両方を提供できます。このアプローチにより、冗長なデータ パイプラインを構築する必要がなくなり、より価値の高いイニシアチブに集中できます。さらに、合併または買収された企業は、合併後のデータ ライセンスとインフラストラクチャのニーズを迅速かつ効率的に合理化できます。統合された企業は、旧来のデータ資産やオペレーションの適合や結合ではなく、新しいビジネス機会に集中することができます。

既存のシステムを分離し、新しいビジネスモデルに対応するための抽象化レイヤを構築する

銀行の競争優位性は、コア バンキング システムではなく、カスタマー エクスペリエンス レイヤにあります。しかし、従来の銀行システムでは、Cobol などの言語で開発され、銀行のバリュー チェーン全体に統合されたモノリシック アプリケーションがよく使用されています。この統合により、バリュー チェーンのレイヤを分離することが困難になり、このようなシステムのアップグレードと最新化はほぼ不可能になりました。

この課題に対処する 1 つの方法は、API 管理システムなどの分離レイヤを使用するか、Spanner などのステージング レイヤを使用して、記録簿を複製し、高度な分析と AI を使用したサービスのモダナイズを促進することです。たとえば、Deutsche Bank は Spanner を使用して、従来のコア バンキング エステートを分離し、イノベーションの取り組みを開始しました。