Well-Architected Framework の金融サービス（FS）の視点のこのドキュメントでは、 で FS ワークロードのパフォーマンスを最適化するための原則と推奨事項の概要について説明します。Google Cloud Google Cloudこのドキュメントの推奨事項は、Well-Architected Framework のパフォーマンス最適化の柱に沿っています。
金融サービスでは、パフォーマンスの最適化は長い歴史があります。FS 組織が技術的な課題を克服するのに役立ち、新しいビジネスモデルの創出を可能にするか、加速させるものでした。たとえば、 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 の分離や、フロントオフィスとバックオフィスのサイロを超えて検討します。
未検証のリスクのためにパフォーマンスを犠牲にすることなく、セキュリティを優先する
FS 組織のセキュリティと規制遵守は、間違いなく高い水準でなければなりません。高い水準を維持することは、クライアントの損失を防ぎ、組織のブランドに修復不可能な損害を与えることを防ぐために不可欠です。多くの場合、最も価値の高いものは、 生成 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 倍速くリスク計算を実行しています。
クラウドベースの取引所と取引プラットフォームを実行する
お客様との Google Cloud 会話から、市場と取引アプリケーションのパフォーマンス要件に 80/20 のパレートの法則 が適用されることがわかります。
- 取引アプリケーションの 80% 以上は、非常に低いレイテンシを必要としません。 ただし、クラウドの復元性、セキュリティ、弾力性の機能から大きなメリットを得られます。たとえば、 BidFX、 外国為替マルチディーラー プラットフォームである BidFX は、クラウドを使用して新しい プロダクトを迅速にリリースし、リソースを増やすことなく可用性と フットプリントを大幅に拡大しています。
- 残りのアプリケーション（20% 未満）では、低レイテンシ（1 ミリ秒未満）、決定性、メッセージ配信の公平性が必要です。 従来、これらのシステムは、厳格で高価なコロケーション施設で実行されていました。エッジまたはクラウド ファースト アプリケーションとして、このカテゴリのアプリケーションもクラウドに リプラットフォームされることが増えています。
現在と将来のビジネスニーズを満たすようにテクノロジーを将来にわたって維持する
これまで、多くの FS 組織は競争優位性を獲得するために独自のテクノロジーを構築してきました。たとえば、2000 年代初頭には、成功した投資銀行や取引会社は、Pub/Sub システムやメッセージ ブローカーなどの基盤テクノロジーを独自に実装していました。オープンソース テクノロジーとクラウドの進化により、このようなテクノロジーはコモディティ化され、ビジネス価値の向上にはつながりません。
テクノロジーを将来にわたって維持するには、次の推奨事項を考慮してください。
製品化までの時間の短縮とコストの透明性を高めるために、Data-as-a-Service（DaaS）アプローチを採用する
FS 組織は、有機的な成長と合併買収（M&A）の組み合わせによって進化することがよくあります。その結果、組織は異なるテクノロジーを統合する必要があります。また、データ ベンダー、データ ライセンス、統合ポイントなどの重複するリソースを管理する必要があります。 Google Cloud は、 合併後の統合で差別化された価値を創出する 機会を提供します。
たとえば、 BigQuery Sharing などのサービスを使用して、分析可能なデータサービス（DaaS）プラットフォームを構築できます。このプラットフォームは、市場データと代替ソースからの入力の両方を提供できます。このアプローチにより、冗長なデータ パイプラインを構築する必要がなくなり、より価値の高いイニシアチブに集中できます。さらに、合併または買収された企業は、合併後のデータ ライセンスとインフラストラクチャのニーズを迅速かつ効率的に合理化できます。旧来のデータ資産やオペレーションの適合や結合に労力を費やすのではなく、統合されたビジネスは新しいビジネス機会に集中できます。
既存のシステムを分離し、新しいビジネスモデルに対応するための抽象化レイヤを構築する
銀行の競争優位性は、コア バンキング システムではなく、カスタマー エクスペリエンス レイヤであることが増えています。ただし、従来のバンキング システムでは、Cobol などの言語で開発され、バンキングのバリューチェーン全体に統合されたモノリシック アプリケーションが使用されることがよくあります。この統合により、バリューチェーンのレイヤを分離することが困難になり、このようなシステムをアップグレードして最新化することはほぼ不可能でした。
この課題に対処する 1 つのソリューションは、API 管理システムなどの分離レイヤや、レコードの複製を行い、高度な分析と AI によるサービスの最新化を促進する Spanner などのステージング レイヤを使用することです。たとえば、 Deutsche Bank は Spanner を使用して、以前のコア バンキング アセットを分離し、 イノベーションの取り組みを開始しました。