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 値アトリビューションなどの手法を使用すると、モデルの決定を入力レベルの特定の特徴に帰属させることができます。
説明可能性が十分でない場合は、バリューストリームで意思決定ステップを分離し、意思決定以外のステップのみを 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 を使用して、従来のコア バンキング エステートを分離し、イノベーションの取り組みを開始しました。