Google Cloud Well-Architected Framework: 金融サービス（FS）の視点のこのドキュメントでは、 Google Cloudで FS ワークロードのパフォーマンスを最適化するための原則と推奨事項の概要について説明します。このドキュメントの推奨事項は、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）に、より効率的または包括的に関連付けます。
- システムレベルでのパフォーマンスの最適化に重点を置きます。従来の「銀行の変革」と「銀行の運営」の分離、フロント オフィスとバック オフィスのサイロ化を超えて、
未実証のリスクのためにパフォーマンスを犠牲にすることなく、セキュリティを優先
金融サービス組織のセキュリティと規制遵守は、間違いなく高い水準でなければなりません。クライアントを失うことを回避し、組織のブランドに修復不可能な損害を与えないようにするには、高い基準を維持することが不可欠です。多くの場合、生成 AI などの技術革新や、Spanner などの独自のマネージド サービスによって、最大の価値がもたらされます。運用リスクが大きすぎる、または規制コンプライアンス体制が不十分であるという誤解から、このようなテクノロジー オプションを自動的に破棄しないでください。
Google Cloud は、G-SIFI と緊密に連携して、マネー ロンダリング対策（AML）に AI ベースのアプローチを、機関が顧客にサービスを提供する管轄区域全体で使用できるようにしています。たとえば、HSBC は、金融犯罪（Fincrime）部門のパフォーマンスを大幅に向上させ、次のような結果を得ました。
- 確認された不審なアクティビティが約 2 ～ 4 倍増加。
- 誤検出を 60% 以上削減し、リスクの高い、対応が必要なアラートのみに調査時間を集中させることで、運用コストを削減します。
- 監査可能で説明可能な出力により、規制遵守をサポートします。
以下の推奨事項を参考にしてください。
- 使用するプロダクトが、事業を展開する管轄区域のセキュリティ、復元性、コンプライアンスの要件を満たしていることを確認します。この目標を達成するには、 Google Cloudのアカウント チーム、リスクチーム、プロダクト チームと連携します。
- AI の説明可能性を活用して、より強力なモデルを作成し、お客様に透明性を提供します。
説明可能性が不十分な場合は、バリューストリームの意思決定ステップを分離し、AI を使用して意思決定以外のステップのみを自動化します。場合によっては、説明可能な AI では不十分なことや、規制上の懸念（GDPR 第 22 条など）により、プロセスに人間の介入が必要になることがあります。このような場合は、人間のエージェントが意思決定に必要なすべての情報を 1 つのコントロール ペインに表示しますが、データの収集、取り込み、操作、要約のタスクを自動化します。
アーキテクチャを再考して、新しい機会と要件に適応する
クラウドベースの機能で現在のアーキテクチャを拡張すると、大きな価値が得られます。より革新的な成果を達成するには、クラウド ファーストのアプローチを使用して、アーキテクチャを定期的に見直す必要があります。
ワークロードのアーキテクチャを定期的に見直してパフォーマンスをさらに最適化するには、次の推奨事項を検討してください。
オンプレミスの HPC システムとスケジューラの代わりにクラウドベースの代替手段を使用する
高い弾力性、セキュリティ ポスチャーの向上、広範なモニタリングとガバナンス機能を活用するには、クラウドで HPC ワークロードを実行するか、オンプレミス ワークロードをクラウドにバーストします。ただし、投資戦略のシミュレーションや XVA モデリングなど、特定の数値モデリングのユースケースでは、Kubernetes と Kueue を組み合わせることで、より強力なソリューションを実現できる可能性があります。
シミュレーション用にグラフベースのプログラミングに切り替える
モンテカルロ シミュレーションは、Dataflow などのグラフベースの実行システムでより高いパフォーマンスを発揮する可能性があります。たとえば、HSBC は Dataflow を使用して、以前のアプローチと比較して 16 倍高速にリスク計算を実行しています。
クラウドベースの取引所と取引プラットフォームを運営する
Google Cloud のお客様との会話から、市場と取引アプリケーションのパフォーマンス要件に 80/20 のパレートの法則が適用されることがわかります。
- 取引アプリケーションの 80% 以上は、極めて低いレイテンシを必要としません。ただし、クラウドの復元性、セキュリティ、エラスティック機能から大きなメリットを得られます。たとえば、外国為替マルチディーラー プラットフォームである BidFX は、クラウドを使用して新しいプロダクトを迅速にリリースし、リソースを増やすことなく可用性とフットプリントを大幅に向上させています。
- 残りのアプリケーション（20% 未満）では、メッセージの配信に低レイテンシ（1 ミリ秒未満）、決定論、公平性が必要です。従来、これらのシステムは、柔軟性に欠ける高価なコロケーション施設で運用されていました。このカテゴリのアプリケーションでも、エッジまたはクラウド ファースト アプリケーションとして、クラウドでプラットフォームが再構築されることが増えています。
現在および将来のビジネスニーズに対応する、将来を見据えたテクノロジー
歴史的に、多くの金融サービス組織は競争上の優位性を得るために専有技術を構築してきました。たとえば、2000 年代初頭、成功を収めた投資銀行や取引会社は、pub-sub システムやメッセージ ブローカーなどの基盤テクノロジーを独自に実装していました。オープンソース テクノロジーとクラウドの進化に伴い、このようなテクノロジーはコモディティ化し、ビジネス価値の向上をもたらさなくなっています。
テクノロジーを将来にわたって有効に活用するために、次の推奨事項を検討してください。
Data as a Service（DaaS）アプローチを採用して、製品化までの時間を短縮し、費用の透明性を高める
金融サービス組織は、多くの場合、有機的成長と合併および買収（M&A）の組み合わせによって進化します。そのため、組織は異種のテクノロジーを統合する必要があります。また、データ ベンダー、データ ライセンス、統合ポイントなどの重複するリソースを管理する必要もあります。 Google Cloud は、合併後の統合で差別化された価値を創出する機会を提供します。
たとえば、BigQuery Sharingなどのサービスを使用して、分析に対応した Data-as-a-Service（DaaS）プラットフォームを構築できます。このプラットフォームは、市場データと代替ソースからの入力の両方を提供できます。このアプローチにより、冗長なデータ パイプラインを構築する必要がなくなり、より価値の高いイニシアチブに集中できます。さらに、合併または買収された企業は、合併後のデータ ライセンスとインフラストラクチャのニーズを迅速かつ効率的に合理化できます。統合されたビジネスは、レガシー データ資産とオペレーションの適応と統合に労力を費やす代わりに、新しいビジネス チャンスに集中できます。
抽象化レイヤを構築して既存のシステムを分離し、新しいビジネスモデルに対応する
銀行の競争上の優位性は、コア バンキング システムではなく、カスタマー エクスペリエンス レイヤにあります。しかし、レガシー バンキング システムでは、Cobol などの言語で開発され、バンキングのバリュー チェーン全体に統合されたモノリシック アプリケーションがよく使用されています。この統合により、バリュー チェーンのレイヤを分離することが困難になり、このようなシステムのアップグレードやモダナイズはほぼ不可能でした。
この課題に対処するソリューションの一つは、API 管理システムなどの分離レイヤ、または Spanner などのステージング レイヤを使用して、記録簿を複製し、高度な分析と AI を使用してサービスのモダナイゼーションを促進することです。たとえば、Deutsche Bank は、Spanner を使用してレガシー コア バンキング資産を分離し、イノベーションへの取り組みを開始しました。