re:Invent 2024: Goldman SachsのInvestOneシステムAWS移行事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Replatforming for reinvention: Modernizing mainframes at Goldman Sachs (FSI312)
この動画では、Goldman Sachsにおけるメインフレームのモダナイゼーションプロジェクトについて、具体的な実装手法とその成果が紹介されています。2兆ドル以上の運用資産を持つアセットマネジメント部門で、30年以上使用してきたInvestOneシステムを、AWSクラウドへReplatformingする取り組みを解説しています。メインフレームエミュレーターを活用したLift & Shiftアプローチを採用し、Systems Manager、EventBridge、CloudWatchなどのAWSサービスを組み合わせて既存インターフェースを維持しながら、スケーラビリティと処理能力の向上を実現した過程が詳しく説明されています。また、COBOLコードの開発環境整備やセキュアなデータ転送の実装など、実践的な知見も共有されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Goldman Sachsのメインフレームモダナイゼーション：プロジェクト概要
おはようございます。FS 312「Replatforming for Reinvention: Goldman Sachsにおけるメインフレームのモダナイゼーション」へようこそ。今日、お客様はメインフレームをクラウドに移行・モダナイズする上で、多くのビジネス上の理由をお持ちです。これらの移行が複雑で、様々な課題やリスクを伴うことは私たちも認識しています。幸いなことに、AWSでの経験に基づき、成功したメインフレーム移行プロジェクトから学び、皆様の今後のメインフレーム移行に活用できる設計プラクティス、パターン、教訓を特定してきました。
メインフレームのモダナイゼーションには、すべてに適合する単一の設計パターンは存在しませんが、一貫してお客様にメリットをもたらすパターンが1つあります。それがReplatformingです。その理由は、短期的にも長期的にもメリットがあるからです。短期的には、クラウドへのメインフレーム移行を加速し、長期的には、すでにクラウド上にあるため、そのワークロードでさらなるモダナイゼーションを実現できます。
本日は、Goldman Sachsの優秀なチームによる実際のプロジェクトとユースケースを通じて、このトピックを探っていきます。彼らは、メインフレームのモダナイゼーションと移行に関する一連のジャーニーについてご紹介します。このセッションの最後には、彼らがどのようにしてプロジェクトのスピードを加速し、スケーラビリティと処理能力を向上させ、しかもビジネスやお客様への約束を損なうことなくこれを達成したかを学んでいただけます。私はSheri Moranと申します。Goldman Sachs担当のAWS Principal Solutions Architectを務めています。
アジェンダの概要を簡単にご説明します。まず、Goldman Sachsのアセットビジネスとその時代に応じた進化についてお話しします。次に、このプレゼンテーションの焦点となるInvestOne、つまり彼らのビジネスクリティカルなメインフレームワークロードについて説明します。彼らが直面した課題と、移行・モダナイズを決断した理由について触れます。その後、より技術的な内容に入り、レガシーの設計、コンポーネント、依存関係を検討し、AWSクラウド上で再構築された設計をサービスと設計パターンの観点から比較します。最後に、COBOLのSDLC開発について議論し、得られた教訓で締めくくります。
Goldman Sachsチームをご紹介できることを光栄に思います。Goldman SachsのManaging DirectorであるVictor Baltaが事業面について説明し、技術面についてはGoldman SachsのTechnology FellowであるYitz Lorinerが説明します。
Goldman Sachsのアセットマネジメント部門：構造と課題
ご参加いただき、ありがとうございます。まず初めに、皆様、本日はお時間を取ってお越しいただき、私たちの話を聞いていただき、誠にありがとうございます。私はVictor Baltaと申します。Goldman Sachsで10年間働かせていただいております。Goldman Sachsに入社する前は、Cityのキャピタルマーケットエンジニアリングチームで働いており、キャリアの始まりはヘッジファンド向けのソリューション開発でした。現在はGoldman Sachsのアセットマネジメント部門でPortfolio Servicingエンジニアリングの共同責任者を務めています。当部門は2兆ドル以上の運用資産を監督しており、これにより私たちはトップ10のアセットマネージャーの一つとなっています。そして、アクティブ運用のグローバルリーダーであることを誇りにしています。
アセットマネジメントについて説明すると、基本的に2つの部門があります：パブリック部門とオルタナティブ部門です。パブリック部門では、債券、マネーマーケット、ETFなどの標準的な商品を扱うパブリックファンドを取り扱っています。機関投資家や年金基金などのお客様が、投資戦略を実現するために私たちのファンドをご利用になっています。
オルタナティブ部門では、プライベートマーケットとリキッドオルタナティブ戦略の両方にわたる戦略を展開しています。このような戦略をご利用になるお客様は、成長の促進、ポートフォリオの分散化、収益の創出を目的としています。私たちの商品は、プライベートクレジットやエクイティから、ライフサイエンス、不動産まで、その間のほぼすべての分野をカバーしています。
これが2つの部門の説明です。では、エンジニアリング組織として、より大きなアセットマネジメント部門の中でどのような位置づけにあるのでしょうか？私たちはClient and Portfolio Servicing Engineeringと呼ばれる大きなグループの一部で、このエリアはパブリック部門とオルタナティブ部門の両方をサポートしています。主に3つのグループがあります。1つ目はInvestment and Portfolio Servicingグループで、これは取引執行後のすべて、つまり約定確認、決済、ポートフォリオ会計、照合などを担当しています。2つ目のClient Servicingは、口座開設、請求、レポーティングなど、外部のお客様とのやり取りを担当します。そして最後にData Platform and Servicesがあり、商品データ、ベンチマーク等のデータの配信と利用を担当しています。本日のセッションでは、特にポートフォリオ会計、具体的にはIBOR（Investment Book of Record）に焦点を当てていきます。
アセットマネジメント部門におけるポートフォリオ会計について説明すると、主に2つのコンポーネントがあります。1つ目はFISが提供するInvestOneというベンダーソフトウェアです。このソフトウェアは、IBORを作成し、純資産価値（NAV）と総勘定元帳のビューを作成するための会計機能を提供します。2つ目のコンポーネントは、Goldman Sachs独自の自社開発COBOLオーケストレーションレイヤーです。私たちのオーケストレーションレイヤーとInvestOneは両方ともMainframe上で動作していますが、このオーケストレーションレイヤーは基本的にInvestOneをカプセル化し、Goldman Sachs Asset Managementの独自の問題やユースケースに対応できるようにしています。
この分野についていくつかの重要な事実をご紹介します：私たちは1991年にInvestOneとの関係を開始し、この30年間、このプラットフォームの開発と改良を積極的に進めてきました。現在、20名以上のグローバルエンジニアチームがプラットフォームのサポートを行っています。計算リソースについて言えば、約60%がInvestOneに、残りの40%がGoldmanの独自のCOBOLオーケストレーションレイヤーに使用されています。
こちらが私たちがカバーしている機能の一覧です：Shadow Book、ポートフォリオ会計、取引処理、計算処理 - すべてのオーバーナイト処理を含みます。ここでShadow Bookについて、なぜこれが私たちのビジネスにとって重要なのか、少しお時間をいただいて説明させていただきます。アセットマネージャーとして、私たちはビジネスのバイサイドに位置しており、取引の保管機関ではありません。実際、40以上のカストディアンと取引を行っています。Shadow Bookが私たちにもたらす価値は、ポジションと取引の全体像を把握できることです。さらには、コーポレートアクション、サービスイベント、購読や償還なども含まれます。これは私たちにとって非常に重要です。なぜなら、ポートフォリオマネージャーやトレーダーが翌日の取引を行うために、信頼できるデータソースが必要だからです。
次のスライドは、中央の緑のボックスがInvestOneである現在のアーキテクチャの高レベルな概要図です。InvestOneの上部には、すべてのデータ生成元があります - 取引、購読償還、各種アセットサービスイベント、証券の移転などです。これらはすべて私たちのポートフォリオ会計プラットフォームに送られます。下流では、コンプライアンス、規制当局、ポートフォリオマネージャーへのデータ配信が行われます。そして右側がShadow Book機能につながっており、ここではカストディアンだけでなく、ブローカー、ファンドアドミニストレーター、電子確認プラットフォームなど、多くの外部関係者との連携が必要です。これらすべてを統合して、毎晩のShadow Bookを作成しています。
InvestOneシステムの現状と移行への道筋
私たちは30年間この取り組みを続けてきましたが、その間多くのビジネス上の課題に直面してきました。まず第一に、ベンダーが全ユーザーをメインフレームから新しいプラットフォームに移行させようとしています。また、より現代的なアーキテクチャのプラットフォームと比べて、メインフレームでの運用コストが非常に高額です。統合の複雑さも課題です。メインフレームではAPIやデータ契約の選択肢が限られており、できることが制限されています。さらに、金融バックグラウンドを持つ高度なCOBOLエンジニアの確保が現代では難しくなっています。しかし、おそらく最大の問題であり、今日ここにいる理由は、もはや水平方向にスケールできないことです。これが私たちの最大のビジネス上の課題となっています。
ビジネスサイドからは成長を続けたいという要望があります。SMAダイレクトインデックスのような特定の分野では、アカウント数が大幅に増加しており、それに伴って毎晩処理しなければならない取引数やタックスロットの数も膨大になっています。そのため、ビジネスをサポートするための処理能力を提供することが重要な課題となっています。また、プラットフォーム全体の近代化については、5年以上の長期的な視点で取り組んでいく必要があることも認識しています。
しかし、ビジネスはそれほど長く、つまり5年もの間待つことはできませんでした。 そこで、私たちは複数の選択肢を検討することになりました。最初の選択肢は、COBOLのオーケストレーション層、つまりGoldmanの自社開発したCOBOLコードを書き直すことでした。しかし、これは2つの理由で採用しませんでした。1つ目は、最終的な目標状態が分からない中で、何かを書き直し始めることは避けたかったからです。2つ目は、そこには30年分のカスタマイズが施されており、書き直しやリファクタリングを行うのは現実的ではなかったからです。
次に、私たちのCOBOL層やMainframeコードの最適化を検討しました。実は、これは過去30年間ずっと取り組んできたことで、この20年以上もビジネスのペースについていけたのは、チームの努力と創意工夫の証といえます。しかし、現在の実装は単一のCICS regionで動作しており、MPSつまり計算能力やメモリの割り当てには制限があるため、私たちは限界に達していました。複数のCICS regionによる実装に移行する必要がありましたが、それにはすべての大規模なリファクタリングが必要となり、現実的ではありませんでした。
その後、ベンダーのMainframeからMainframe以外のバージョンのコードへの移行を検討しました。しかし、ここでも問題があります。40%が自社コードであるため、半分だけを移行するというのは機能しないのです。最終的に私たちが行き着いた解決策は、現実的なアプローチを取ることでした。つまり、エミュレーター上で実行し、MainframeからAWSへのリフト＆シフトを行うことです。ここで、実装の詳細について説明するため、同僚のYitzに引き継ぎたいと思います。
メインフレームからAWSへ：アーキテクチャの再設計
ありがとう、Victor。おはようございます。新しいアプローチの紹介に入る前に、少し時間を取って従来のデザインについて話をしましょう。何がうまく機能していて、何が機能していないのか、なぜ再設計が必要なのか、そして新しい設計がどのように既存システムの短所に対処するのかについてです。 設計について説明する前に、Mainframeに関するいくつかの概念を紹介する必要があります。Mainframeはモノリスであり、つまり単一のシステムにすべてが含まれています。SDLC、セキュリティ、モニタリング、ストレージ、データベース、アプリケーションサーバーがすべて含まれているのです。新しいプラットフォームに移行するためには、これらを分割する必要があります。
ご覧のように、これがInvestOneシステムで、中央の緑のボックスで示されています。 右側のセクションは、ベンダーの観点から私たちが相互作用するさまざまなシステムを示しています。これは完全な図ではありません - 1枚のスライドにすべてを収めることは不可能です。上部には、データストリーミングのための相互作用が示されています - これはトランザクションデータ、参照データ、その他のさまざまなデータです。上部の2つの赤いボックスに注目してください。1つはリアルタイム用で、もう1つはバッチまたはSFXとMQ/EMS用です。これについては後ほど詳しく説明します。
左側には、リアルタイムのインタラクションがあります。これは、クライアントとのやり取りや、変更を加える運用作業と考えることができます。その一部はベンダーが提供し、一部は長年にわたって私たちが開発してきたものです。 最後に、下部にはダウンストリームがあり、データはバッチとリアルタイムの両方で出力されます。ここでも2つの赤いボックスが見えますが、これはMQとSFXです。MQとSFXについて説明しましょう。これは全体的な再設計に関連してくるからです。MQはIBMが提供するリアルタイムメッセージングのためのベンダープラットフォームで、Message Queuingと呼ばれ、システム間の非同期メッセージングやデカップリングのための標準的なソリューションです。SFXはGoldman Sachsが自社開発したSecure File Exchangeで、SFTPのラッパーとして機能し、ワークフロー、ライフサイクル管理、監査機能、リトライ制御などを提供します。
InvestOneシステムとのほぼすべてのやり取りが、SFXかMQのいずれかを通じて行われているということが重要なポイントです。多くのシステムが存在し、様々なアプローチがありますが、すべてがバッチかリアルタイムのどちらかになります。 中央のこのボックスがInvestOneのエコシステムです。その中に4つのボックスがあります：リアルタイム、バッチ、マニュアル、そしてデータ抽出です。これらは4つのインタラクションタイプに対応しています。左上には現金と取引があり、先ほど説明したように、通常はMQを通じてリアルタイムで処理されます。右上には様々な参照データシステムがあります。ポートフォリオやポジションを構築するには、取引やトレードのセットだけでは不十分です。それらに関する情報、口座情報、商品情報、価格情報（ポジションの価値を知るため）、その他の参照データが必要です。また、調整が必要な場合のための人的要素として、マニュアル入力も存在します。
このマニュアル入力のコンポーネントは、不正確なデータが入ってきたり、ミスが発生したりした場合の上書き、変更、修正を処理するために、人間の関与が必要です。最後に、下部にある抽出は、主にバッチ処理ですが、一部リアルタイム処理も含まれています。様々なクライアントやダウンストリームシステム（コントローラー、レポーティング、クライアントデータ送信、政府や規制当局へのレポーティング、同じデータを使用する他のGoldman Sachsシステムとの照合など）により、一貫性を維持しています。
既存のメインフレームアーキテクチャを見ると、レイヤーケーキのように考えることができます。 一番下にはオペレーティングシステムがあります。私たちが普段使っているLinuxやWindowsではなく、IBMが提供するz/OSです。その上にファイルストレージレイヤーがあります。まず、DB2があり、これは標準的なデータテーブルを持つ関係データベース管理システムの機能を提供し、ほとんどの分散プラットフォームと同様です。メインフレームで異なるのは、VSAMとフラットファイルです。VSAMファイルは、標準的なツリー形式を使用して高速に検索可能な、単一のデータタイプを持つインデックスまたは単一テーブルと考えることができます。フラットファイルは、基本的にそれ以外のすべてを含みます。これらの後者2つ、フラットファイルとVSAMは、メインフレーム特有のものです。DB2はメインフレームにおける選択肢ですが、ほとんどのシステムで見られる標準的な関係データと非常によく似ています。
これらのレイヤーの上には、アプリケーションとオペレーティングシステムの間に位置するサービスレイヤーがあります。Victorが言及したCICSリージョンがあり、これはTomcatなどのアプリケーションサーバーと同様に、アプリケーションをインストールする場所を提供します。メインフレーム内でバッチ処理を可能にするTSOがあります。また、オペレーティングシステムとの対話、セキュリティ認証、認可、IAM、その他のユーティリティのための様々なインターフェースやシェルがあります。その上に構築されているのが、投資アプリケーションを表す2つのインフラストラクチャです：1つはベンダーが提供するコア部分で、もう1つは過去30年間にわたって私たちが構築してきたETLまたはオーケストレーションレイヤーです。
また、Schedulerもあります。InvestOneは基本的にイベント駆動型のシステムです。つまり、アクションを開始したりポーリングを行ったりするのではなく、イベントに反応する仕組みになっています。イベントの例としては、日中処理の終了、夜間バッチの完了、バッチファイルの到着、価格ファイルの生成などが挙げられます。これらのイベントに対しては、コア内に組み込まれたものとは別に、TWSで管理されるオーケストレーションを通じて対応し、アプリケーションのイベント駆動型の性質を制御しています。最後にSDLCがありますが、これは少し異質な存在です。通常のアプリケーションにはSDLCは組み込まれていませんが、Mainframeには組み込まれています。これは先ほど述べたように、Mainframeがすべてを含むモノリスだからです。
ここで、非機能要件について説明しましょう。どのアプリケーションにも、納期やSLAを満たすための要件、そしてビジネスニーズに対応するために必要な要件があります。Victorが言及したように、このプロジェクトの主な推進力は、ビジネスの成長に対応するためのスケーリングの必要性です。ビジネスは年間30%の成長率で拡大しており、今後もさらなる成長が期待されています。私たちはこれに対応できる必要があります - これが主要な成功基準です。しかし、レジリエンシーも重要です。データを失ったり、大規模なダウンタイムを経験したりすることは避けなければなりません。ただし、ある程度のダウンタイムは許容できます。
ほとんどの方にとって馴染みのある2つの概念、RTOとRPOについて説明しましょう。Recovery Time Objectiveは、アプリケーションがダウンしている状態をどれだけ許容できるかを示します。これはデータ損失を意味するわけではなく、アプリケーションにアクセスできない時間を指します。ビジネスの観点から、私たちは4時間のダウンタイムを許容できると考えています。これなら、Wall Street Journalの一面を飾るような事態にはならないでしょう。ただし、これは4時間分のデータ損失を許容するという意味ではありません。システムを復旧する際には、現在のデータに合理的に近い状態まで戻せる必要があり、どのデータを失ったかを特定できなければなりません。私たちは15分のRecovery Point Objectiveを許容しています。つまり、すべてのデータを失って別のRegionやAvailability Zoneで復旧する必要がある場合、選択したレジリエンシーモデルに応じて、最大15分分のデータをリプレイする必要があることを許容しています。
AWSでのReplatforming：新しいアーキテクチャの詳細
15分のデータ損失を許容できる理由は、SFXとMQの組み合わせを使用しているからです。これらはどちらも、必要に応じてデータをリプレイできるソリューションです。例えば、SFXでは、クライアントとサーバー間のワークフローを処理する中間サーバーやソースサーバーで、一定期間データが削除されないため、必要に応じてリプレイすることができます。MQも同様で、キューからデータが取り出された後でも、MQの基盤となるストレージメカニズムとレジリエンシーモデルにより、必要に応じてリプレイすることができます。
私たちのアプリケーションに特有の要件がいくつかあります。興味深い要件の1つは、セカンダリRegionや、RegionやAZのどちらを選択するにせよ、セカンダリインフラストラクチャへの復旧がCI/CDに依存してはならないということです。その理由は、Goldmanの内部CI/CDもAWSを使用していますが、Region 1のみを使用しているからです。もし復旧モデルがCI/CDに依存している場合、例えばIACとCI/CDを使用してデプロイメントするインフラストラクチャに切り替える場合、実質的に単一のAZに制限されてしまい、必要なRTO とRPOを達成することが不可能になってしまいます。
これまでは、Mainframeと既存の設計について話してきましたが、ここからは新しく再設計されたアプローチについてお話ししたいと思います。この再設計されたアプローチの中核となるのが、NTT Dataが提供するエミュレーターです。ここで重要なのは、このエミュレーターはMainframe全体の代替となるものではないということです。このエミュレーターが提供するのは、COBOLのランタイム環境です。私たちの多くはCOBOLを使用した経験はありませんが、これは独自のコンパイラー、ランタイム、そしてユーティリティセットを持つ、もう一つのプログラミング言語に過ぎません。しかし、Mainframeアプリケーションを実行するために必要なすべてを提供しているわけではありません。例えば、SDLCは提供していません。コンパイルしてランタイム用のバイナリを生成できる環境は提供していますが、すべてを提供しているわけではないのです。
ここに示されているのが、私たちが取り得る様々なアプローチです。すべてを詳しく説明するつもりはありませんが、これらのアプローチには、データの移行、アプリケーションの移行、あるいは再設計が含まれています。私たちが選択したのは「Replatform」というアプローチです。Replatformとは、アプリケーションのロジックやバイナリを変更するのではなく、それが動作するインフラストラクチャを変更することを意味します。特定のユーティリティはMainframe固有のものであるため、100%完璧に実現することは不可能ですが、基本的にはアーキテクチャやアプリケーションロジック自体を作り直すのではなく、同じコードを新しい環境で実行することを目指しています。Mainframeが提供する機能を、Linux OSが提供する機能に置き換えていくことになります。
このスライドを見ると、左側には以前の数枚のスライドを要約したもので、Mainframe内に含まれる様々な機能が示されています。InvestOne Core、InvestOne ETL、イベント駆動型パラダイムのスケジューラー、そしてSDLCがあります。右側を見ると、いくつかの例外を除いて、ほぼすべての機能が存在していることがわかります。中央のボックスが、新しいInvestOneアプリケーションの中核となります。ベンダーアプリケーションであるInvestOne Core、Goldman Sachsが提供したコードであるInvestOne ETLまたはオーケストレーター、そしてLinuxオペレーティングシステムではサポートされていないMainframe固有のファイルであるVSAMファイルとフlatファイルがあります。しかし、データベースはもうここにはありません。これらはRDSに抽出されることになります。スケジューラーも別のベンダーアプリケーションとして切り離されます。また、Mainframe自体に組み込まれている他の様々なユーティリティもありません。
これは、レジリエンシーを考慮に入れていないアーキテクチャです - レジリエンシーについては次のスライドで説明します。上から見ていくと、VPCがありますが、これは実際には共有VPCです。Goldman Sachsでは、本日も参加してくださっているRaganとそのチームが開発したFast Trackと呼ばれるランタイム環境やインフラストラクチャ設計に基づいて、共有VPCモデルを使用しています。ありがとう、Ragan。
ベストプラクティスのアプリケーションは、私たちの部門のVPC内の共有VPC内で実行されることになります。VPC内には2つのサブネットがあります：GS RouteableサブネットとCloud Routeableサブネットです。これは顧客データを保護するために行っています。実際のアプリケーションが実行され、データが処理されるCloud Routeableサブネットは、インターネットにアクセスできません。GS Networkに直接アクセスすることもできませんし、もちろんGS Networkからも直接アクセスすることはできません。代わりに、GSとCloud Routeableサブネットの両方へのアクセスとルーティングテーブルを持つGS Routeableサブネットがあります。
GS routable subnetには、cloud routable subnetとの双方向通信を可能にするインフラストラクチャが配置されます。cloud routable subnet内に配置されるのが、アプリケーションの中核部分となります。先ほど述べたように、主要なものはエミュレーターで、これがCOBOLのランタイムとなります。また、スケジューラーも置き換えました。それぞれのAuto Scaling Groupを個別に見ていきましょう。メインフレームエミュレーターのAuto Scaling Groupは3つのコンポーネントで構成されています：AMI、EC2インスタンス、そしてEBSボリュームです。EFSやFSXなど様々なアプローチを試しましたが、私たちのケースではパフォーマンスと信頼性のバランスが最も良かったのがEBSでした。
提供されるAMIはGoldman Sachs内部で構築されています。ベンダーから提供されるバイナリ、私たちが提供するバイナリ、そして必要な各種ユーティリティが含まれています。また、クライアントデータを安全に扱うために、Goldman Sachsのテクノロジーリスクチームから提供される様々なコンポーネントも含まれています。EC2インスタンスは、スケーラビリティを実現する上で非常に重要です。同じAMIと類似のEBSボリュームを使用できるため、大小様々な環境を用意し、スピンアップしたり、スケールアップ・ダウンしたりすることができます。環境によってGP3を使用したり、IO2を使用したりできますが、AMIとAuto Scaling Groupの観点からは全く同じように見えます。
スケジューラーもほぼ同じで、AMI、EC2インスタンス、永続ストレージ用のEBSボリュームという3つのコンポーネントで構成されています。このアプリケーションではEBSが重要な役割を果たしています。というのも、3種類のストレージがあるからです。1つはスケジューラーの下にあるボックスに示されているリレーショナルデータベースのOracleです。残りの2つは、VSAMファイルとフラットファイルで、これらはすべてEBS内に格納されます。ストレージがローカルで高速である必要があるという意味で、私たちは実質的にデータベースを開発していると考えることができます。
cloud routable subnet内に配置される他のコンポーネントには、データの送受信に必要な各種Lambda関数があります。GS routable subnet内には、いくつかのコンポーネントがあります。1つはSFXアクセスポイントで、SFXは環境間でバルクデータを転送するために使用しています。Goldman Sachs内の他のアカウントに対してもS3バケットへのアクセスは許可せず、代わりにバケットはこの特定のアカウント内に留め、アクセスポイントのみがアクセスできるようにしています。アクセスポイントは、Goldman Sachs内部で開発されたRBACシステムを使用して、必要に応じて他のGoldman Sachsアカウントにアクセスを許可します。
また、GSネットワークからのインバウンドトラフィックをcloud routable subnetに転送するプロキシまたはゲートウェイとして機能するNetwork Load Balancerも設置しています。左側には、インバウンドとアウトバウンドの両方のトラフィックに対応するGSプロキシがあります。プロキシが課す条件の1つは、Goldman Sachsのクライアント証明書を使用したMTLSが必要というもので、これについては後ほど詳しく説明します。subnet内には配置されていませんが、システムの運用に必要な様々なAWSサービスもあります。
リージョン間の冗長化とフェイルオーバー戦略
通知には SNS を使用しています。一時的なデータには S3 を使用していますが、S3 には永続的なデータは保存しません。永続的なデータはすべて EBS か RDS に保存されます。監視には CloudWatch を使用しています。イベント駆動型システムには EventBridge を使用しており、これによってデータの転送に応じてイベントに反応し、Lambda 関数や様々なフローをトリガーします。また、Systems Manager も使用していますが、これについては後ほど詳しく説明します。
このスライドは前のスライドの内容を繰り返したものですが、両方のリージョンを示しています。 私たちは、アベイラビリティゾーンではなく、リージョンによる冗長化を選択しました。その理由は、リージョンやリージョンへのアクセスが定期的に停止する可能性があり、その停止が4時間以上続く可能性があるためです。先ほど説明したように、私たちの RTO と RPO はそれぞれ4時間と15分です。4時間以上のダウンタイムは許容できません。そのため、インフラストラクチャのすべての要素を両方のリージョンにデプロイします。RDS データベース、EBS ボリューム、EC2 インスタンス、Systems Manager、S3 など、すべてを両方のリージョンにデプロイします。
2番目のインスタンスにフェイルオーバーする必要がある場合、その実装方法は永続的なデータの種類によって異なります。 VSAM ファイル（インデックスやフラットファイル、一時ファイルなど）用の EBS ボリュームの場合は、DRS を使用します。DRS は Disaster Recovery Service の略で、プライマリ環境がダウンした場合にセカンダリ環境でインフラストラクチャ一式を起動するための調整レイヤーとして機能する Amazon のサービスです。プライマリ環境をシャドーイングし、待機状態を維持し、プライマリの EBS ボリュームのスナップショットを取得してセカンダリの EBS ボリュームを再構築することで動作します。
DRS については、Oracle Enterprise を直接使用します。Oracle は、例えば UAT 環境のような低コストの環境で、リージョンが1つしかない場合のすべてを管理します。 プライマリとセカンダリの両方を持つ UAT は1つしかないため、セカンダリリージョンは必要ありません。この場合、はるかに安価なライセンスである標準の Oracle を使用します。最後に、接続性については、Goldman が社内で開発した Nimbus という DNS ソリューションを使用します。これは最初にプライマリリージョンの GS プロキシを指し、セカンダリリージョンでは重み付けがゼロの状態で設定されています。Goldman のネットワークから AWS ネットワークへの接続内であるため、Route 53 は使用していません。基準に基づいて重み付けを行うことができ、最初はプライマリリージョンに100%の重みを与えます。ABCP の場合、プライマリリージョンに0%、セカンダリリージョンに100%の重みを与えます。
ファイル転送とイベント処理：AWSサービスを活用した設計パターン
ここで、私たちが発見したいくつかの設計パターンに焦点を当ててみましょう。これらは、プロジェクトを進める中で見つけた方法で、上流システムや下流システムとのさまざまなやり取りを簡素化し、標準化することができました。これらを共通の方法で活用することで、後ほど説明するような他の機能を構築することができました。
まず1つ目は、インバウンドのファイル転送についてです。先ほど触れたように、SFXはGoldman Sachsが境界を越えたファイル転送に採用しているツールです。これはAWSとGoldman Sachs間、Goldman Sachsとクライアント間、クライアントからGoldman Sachsへなど、様々な転送に使用できます。 この標準化を検討する際、私たちが採用したアプローチはMDSと呼ばれるシステムから始まります。MDSはMarket Data Servicesの略で、特定の資産の価格付けに必要な市場価格を提供する価格サービスです。ポジションを算出する際には、一連の取引で構成されていますが、その資産の現在価値を知らなければポジションの価値を把握することができません。1ヶ月前や1年前に購入した資産であれば、価格情報がなければ価値を知ることができません。そのため、私たちが注目している様々な商品の価格を得るために、市場の様々なベンダーにアクセスするMDSからの継続的なフィードが必要なのです。まず、MDSは今までと同じ方法で情報を配信します。クライアントに影響を与える変更は避けたいので、MDSは過去20年間行ってきたのと同じようにFTPを使用します。
ただし、シグナルを受け取って直接ファイルを消費する代わりに、プッシュモデルに変更します。このプッシュモデルは、先ほど説明したバケットに書き込みを行います。このバケットはアクセスポイントで制御されており、他者からのアクセスはできません。バケットに書き込まれると、EventBridgeを使用してそれらのイベントを監視します。イベントがトリガーされると、Lambdaが起動し、Parameter Storeからこのイベントやファイルに関連する情報を取得して、どのSystems Manager自動化を開始するかを決定します。
ここで、Systems Managerに馴染みのない方のために説明させていただきます。Systems Managerは、自動化、セッション、コマンド、パラメータなど、複数のコンポーネントで構成されています。セッションでは、実行中のEC2インスタンスなどとのインタラクションを作成できます。自動化では、ワークフローを作成できます - これはStep Functionsや他の自動化ツールと非常によく似ています。制御された方法で、繰り返し可能な方法で実行でき、エラー処理なども行えます。パラメータでは、ディレクトリサービス、JNDI、その他のクラウド内の情報検索場所のような情報を検索できます。最後のサブシステムはコマンドと呼ばれ、これはボックスへのSSHのようなものと考えることができます。Windowsマシンでも、他のマシンでも構いません。私たちの場合は、すべてをLinux上で実行しています。これにより、マシンにログインしてシェルスクリプトを実行する、事前に用意されたコマンドを作成できます。
Systems Manager自動化マネージャーを起動すると、最初に CloudWatchにすべてをログとして記録します。これは監査証跡の維持、いつ何が起きているかを知ること、何かが起きていない場合の対応、そしてすべてのイベントを追跡するために非常に重要です。次に、エミュレータ（現在はInvestOneのコアアプリケーションであるメインフレームエミュレータ）にログインするコマンドを作成します。ログインし、S3バケットに行き、ファイルをダウンロードして、EBSボリュームに配置します。この時点で、ファイルはInvestOne内で利用可能になります。
しかし、InvestOneはまだそのことを認識していません。先ほど述べたように、これはイベント駆動型システムで、イベントが発生するまでInvestOneは処理すべき価格があることを認識しません。例えば、日次のポジション生成を待っているとします。イベントが発生するまで、価格が入ってきたことを知ることができません。そこでスケジューラーにイベントを発行します。これで、スケジューラーは価格が利用可能であることを認識し、最後にCloudWatchに戻ってログを記録し、このジョブが完了した、あるいは少なくともイベントが内部で発行されたことを示します。データ転送ジョブに関しては、これで完了です。下部を見ると、SNSのパスがあることがわかります。何か問題が発生した場合、SNSトピックに通知が送られ、Goldman Sachsがオンコールサポートとエラー処理に使用しているPagerDutyに全ての通知が送信されます。
このシステムにはどのようなメリットがあるのでしょうか？その1つは、サポートチームにアクセス権を付与する際に、リソースへの直接アクセスを与える必要がないという点です。サポートチームは時々、他のシステムと同様に問題が発生した際に対応する必要があります。私たちとしては、サポートチームにEmulatorで直接スクリプトを実行する権限を与えるのではなく、実行可能なRunbookとしてまとめ、そのRunbookがEmulatorでスクリプトを実行するためのRoleを引き受ける方法を採用しています。その代わりに、Emulatorでスクリプトを実行するための専用のRoleを用意し、サポートチームにはSystems Managerのドキュメントや自動化を実行する権限のみを与えています。Systems Manager自体がそのRoleを引き受けて、マシンにログインできるようになっています。これにより、サポートチームが誤って問題を引き起こすことを防ぐ保護層が確保されます。また、これらの実行可能なRunbookがあることで、非本番環境で安全にすべてをテストすることができます。さらに、Systems Manager自体がすべてをログに記録するため、何か起きた際には確実に記録が残ります。
アウトバウンドのファイル転送は、インバウンドのファイル転送とほぼ同じです。少し手短に説明させていただきます。ここではいくつか興味深い点があります。この場合、トリガーや開始のきっかけは外部ソースからではなく、Emulator自体から発生します。
この場合、イベントは他のすべてと同様にCloudWatch Logsに書き込むInvestOneによってトリガーされます。先ほど申し上げたように、ステップ3が興味深い点です。Goldmanでは、AWSからGoldmanのネットワーク（GSI netと呼んでいます）への通信にはmTLSの使用が必要です。しかし、私たちが使用しているLambda関数では、Goldman証明書を使用したmTLSは標準では利用できません。そこで、Lambda関数の周りにサイドカーまたはラッパーを設置し、GSI netとの通信を制御することでこれを実現しています。このサイドカープロセスには、GS Proxyを経由してSFXに接続するための、GSの証明書を使用したmTLSを可能にするクライアント証明書が含まれています。
このプロセスをカプセル化することで、障害条件やCloudWatchのログ記録がすべて整っています。カプセル化により、これを再現可能にし、必要に応じてサポートが実行できるようにし、何か問題が発生した場合にはPagerDutyを通じてオンコール担当者に通知されるようにすることができます。3番目のケースは前の2つとほぼ同じですが、さらにシンプルです。これはインバウンドシグナル用です。ほとんどのやり取りはバッチで行われます - データの受信、送信、消費、処理などです。時々バッチ処理が発生します。例えば、End of Dayが発生したことを通知してほしい場合などです。
Goldmanは各リージョンのビジネスデーまたはトレーディングデーで運営されています。例えば、上流システムがInvestOneに対して、もう取引が来ないのでプロセスを実行できることを知らせたい場合 - これがEnd of Dayです。これはシグナルです。取引のバッチファイルや取引ファイルはありません。取引自体は一日を通じて行われていたかもしれません。代わりに、シグナルを送信したいのです。これは比較的シンプルで、必要なことを実行するLambdaを設定するだけでもできました。しかし、私たちは全く同じプロセスを使用することを選択しました。
COBOLのSDLC環境構築：クラウドでの開発ワークフローの最適化
これも MDS を通じて実行されます。というのも、私たちが使い慣れている簡単な方法だからです。同じ CloudWatch ログを送信し、 の API エンドポイントにヒットし（直接公開することもできましたが）、最後に CloudWatch にログを記録します。このようにした理由は、再現性を確保するためです。また、オンコールサポートが直接アクセスできない エンドポイントへのアクセスを制御できるようにするためです。Systems Manager を経由する必要があり、これによって制御とログ記録が可能になります。
前述の通り、SDLC はメインフレーム内に構築されています。SDLC - ソフトウェア開発ライフサイクルについては皆さんご存知でしょう。これは変更管理を可能にするもので、CI/CD や DevOps など、様々な呼び方がされています。しかし、SDLC の本質は、新しい要件や環境の変化に対応してソフトウェアを変更できる能力にあります。エミュレータはメインフレームが提供していた機能をすべて提供しているわけではありません。その1つが SDLC です。私たちは独自の SDLC を構築する必要がありましたが、大規模なチームは望んでいませんでした。既製のコンポーネントを使用して、コンプライアンスを満たし、望む機能をできるだけ早く提供できる SDLC を作りたいと考えました。
SDLC で達成しようとしていることを見てみましょう。 いくつかの標準的な要件があります。まず監査可能であることが必要です - 監査可能でなければ、業界の規制当局は、特定の事象が発生した理由、どのソフトウェアが実行されているのか、誰がその変更を行い、なぜその変更が行われたのかを証明できないことを快く思いません。また、環境を立ち上げる必要がある場合に、顧客の資金を扱っているため、何かが起きた理由を理解するために特定の時点でのソフトウェアの状態に戻れるという意味で、再現可能である必要があります。最後に、分散環境での SDLC のやり方に必ずしも慣れていない COBOL 開発者が使えるものでなければなりません。
独自の SDLC を構築するために、Goldman 内で利用可能なツールと、業界全体で利用可能な様々なオープンソースやその他のツールを活用しようとしました。いくつかの概念とテクノロジーを紹介しますが、多くは皆さんにとって馴染みのあるもので、一部は少し新しいものかもしれません。最初の1つは N で、UNIX、Windows、その他様々なオペレーティングシステム用のパッケージマネージャーです。これの利点は、開発者それぞれが標準フォーマットで利用できるように、事前にパッケージ化できることです。次は Coder で、開発者のワークスペースを素早くスピンアップできます。Goldman には、これらのワークスペースを提供するチームがあります。社内のリモート開発や、本番環境に似た環境の作成に使用できます。Coder 開発の機能である dot files も使用しています。
Coder の開発環境は、開発に必要なすべてのパッケージ、IDE、ユーティリティで構成される開発者ワークスペース全体をスピンアップするインストールスクリプトを作成します。それについて見ていきましょう。最後に、VS Code と GitLab があります。私たちの多くは通常 Intel を使用していますが、VS Code を選んだのは、COBOL 開発用の VS Code プラグインが優れているからです。これは COBOL 開発分野のリーダーである Micro Focus が提供しています。VS Code 用のプラグインは、リモート開発をサポートし、リファクタリングのサポートが充実しており、Web ベースの IDE も含まれています。GitLab は Goldman のソースコード保存の標準です。
3つのワークフローと、COBOLの開発者向けに充実したSDLC環境を構築するために各コンポーネントをどのように活用しているかについて説明していきましょう。DEV環境では、開発者が素早くイテレーションを行い、コードやバイナリをシステムにすばやくプッシュできるようにしたいと考えています。必ずしもGitLabを経由する必要はなく、ローカルで実行するようなイメージです。ただし、ローカルにはCOBOL環境がないため実行できません。そこで、以前開発したファイル転送の仕組みを使用してSFXに送信し、メインフレームエミュレーター上でコードを利用可能にするための完全なワークフローを構築しました。
UAT環境はより複雑です。規制上、セキュアで監査可能である必要があるためです。最初のステップは同じですが、その間にGitLabパイプラインを導入しています。開発者のワークスペースから直接ファイル転送を行うのではなく、GitLabパイプラインを通してファイルを送信します。これにより、すべてがGitLabに集約され、同じユーティリティを使用することで、開発者から見ると、GitLabパイプラインを経由してエミュレーター側で作成したスクリプトによってデプロイされる点を除けば、同じように見えます。
本番環境はその中間的な位置づけです。ここでは「AREA」という新しい概念が導入されています。これはGoldman内部のストレージメカニズムで、本番コードを実行するすべてのバイナリに対して必要とされ、監査性と再現性を確保します。コード変更によってパイプラインを開始するのではなく、GitLabエコシステム内のブランチ、タグ、またはリリースタグによってトリガーします。このパイプラインには、AREAへの送信という追加ステップがありますが、それ以外は同じです。ただし、本番ホストに展開されるため、特定のアカウント実行権限に制限されています。
前述の通り、私たちには多くの環境を運用する必要があります。これにはInvestOneの運用方法に関連する多くの理由があります。33年分の履歴を保持しており、特定のユースケースではその全履歴が必要となります。例えば、取引を処理する際には税務上の影響を把握する必要があり、ウォッシュセールやその他の税務上の影響を考慮するため、特定の名義で行われたアカウント内のすべての取引履歴を知る必要があります。
様々なシステムをテストするために、上流・下流のシステムを起動できる必要があります。本番環境を反映したUAT環境が必要ですが、コストは抑えたいと考えています。フルスケールの本番環境の運用はかなりコストがかかります。EBSやRDSの非常に高いIOPS、そしてEC2エミュレーターを実行する高価なマシンが必要です。スケジューラーはワークロードの性質上、それほど高コストではありません。私たちが目指しているのは、多くの環境を素早く起動することです。これは数週間前に撮影したADOのスクリーンショットです。左側に環境が表示されていますが、現在10個のUAT環境があります。
3つの環境が費用の大部分を占めており、約85%がこれらの3つの環境から、残りの約10%が他の7つの環境から発生していることがわかります。大規模な環境は、小規模な環境の20倍もの費用がかかることがあります。右側のグラフでは、10の環境全体におけるAWSサービスごとの費用を示しています。費用の大部分を占めているのは、RDS、EBS、EC2という3つのサービスです。これは理にかなっています。RDSは高価なOracleデータベースですし、EBSは高性能なストレージを使用しているため高額です。そしてEC2は多数のコアと大量のRAMを使用しているため高額になっています。これは本質的にスケーラビリティの話です。
これらすべてを、私たちはかなりシンプルな方法で管理しています。コードをトークン化し、先ほど述べたようにFastTrackを使用してCDKですべてのビルドを行っています。すべてのトークン化を1つのファイルで行い、そのファイルに全環境間の違いを記述しています。これらの環境の1つがUAT1で、もう1つが確かUAT4だったと思います。24行目を見ると、左側はRDSのIOPSが64,000で、右側は3,000というように違いがあります。これが、同じサイズの環境であっても、一方が他方の20倍のコストがかかる理由を説明しています。このアプローチにより、見た目は同じでもコスト面で大きく異なる環境を簡単にスピンアップできます。
セキュアなデータ転送と学んだ教訓：プロジェクトの総括
本日の最後のトピックは、アカウント間でのデータ転送の方法についてです。これは顧客の取引データ履歴や現在のポジション、その他の機密情報を含むため、社内のテクニカルリスク部門にとって非常に重要な懸念事項です。私たちが考案したアプローチは、すべてを3つの部分に分けています：3つのキー、3つのスナップショット、そして3つのプロセスステップです。これがどのように顧客データのセキュリティを確保するのか説明します。まず本番環境について - ここで議論している2つの環境は本番環境とUAT環境です。本番環境には共有されることのない独自のキーがあり、そのキーはEBSボリュームの管理に使用されます。RDSについても同様ですが、私たちが持っている永続ストレージはこの2つだけなので、ここではEBSに焦点を当てて説明します。
EBSについては、本番環境でのみ使用される専用キーと、UAT環境でのみ使用される別の専用キーがあります。これらのキーは他のアカウントと共有することはできず、そのキーだけがEBSの実行と書き込みにアクセスできます。毎晩実行されるプロセスの最初のステップとして、EBSボリュームのスナップショットを作成します。次に、UAT環境と共有される2番目のキーを使用してそのスナップショットをコピーします。この2番目のキーには興味深い特徴があります：同じアプリケーションに属する別のアカウントとのみ共有可能で、その共有は私たちが行うのではありません - 実際、その権限すら持っていません。共有はIACを通じてのみ行われ、これはキーが外部に流出しないようにするための管理策です。これは同じアプリケーションに属する他のGoldmanアカウントに対してのみ実行できます。
2番目のスナップショットはSystems Managerを使用して夜間メンテナンス中に作成されますが、すぐには他のアカウントと共有されません。代わりに、2番目のステップである共有ステップがあります。これは、ログに記録され監視される昇格された権限ロールを使用して、人間が実行する必要があります。このステップは単にEBSスナップショットの所有者として2番目のアカウントを追加するだけです。この時点で、夜間メンテナンスジョブは主キーを使用して最初のスナップショットを作成し、共有キーを使用して2番目のスナップショットをコピーとして作成していますが、まだスナップショットは共有されていません。次に、運用担当者が2番目のアカウントとスナップショットを共有する権限を引き受けることができますが、まだ2番目のアカウントにインポートはされていません。2番目のアカウントの観点からすると、2番目のスナップショットを取り込んでコピーする必要があります。なぜなら、そのスナップショットを暗号化している2番目のキーは2番目のアカウントで一般的に使用することができないからです。その代わりに、私たちは
それをもう一度コピーして、そのSnapshotを別のSnapshotに変換します。これはUATアカウントに属するキーを使用して暗号化され、その後ボリュームに変換することができます。ここで、学んだ教訓についてVictorに説明を譲りたいと思います。質問がある方は、後ほど私たちに自由に声をかけていただければと思います。Q&Aセッションは予定していませんが、Victorと私は質問やコメントがある方のために対応可能です。
このプロセスを通じて学んだ重要なポイントがいくつかあります。まず、Emulatorで動作させることは最初のステップに過ぎず、今説明があったように環境を再構築するには多大な作業が必要です。次に学んだことは、Mainframeには多くのデータの消費者と生産者がいたため、既存のインターフェースを変更しないという方針を重視したということです。変更の影響範囲を最小限に抑えたかったので、現在のインターフェースを新しい環境でも一貫して機能させることを目指しました。そして最後は、非常に実用的なアプローチを取ったことです。Mainframeのモダナイゼーションを見ると、とても気が重くなる可能性がありますが、このアプローチでは、まずは実用的に動作させることを目指してLift and Shiftを行い、これが私たちにとって非常に成功したパターンであることが分かりました。
ここで特別な感謝を述べさせていただきたいと思います。会場にいらっしゃるBraha Cohenは私たちのマネージャーで、このプロジェクトを推進するための素晴らしいスポンサーとなってくれました。最近Goldman Sachsのパートナーに昇進されました。また、Sheri Moranにも大きな感謝を申し上げたいと思います。リソースへのアクセスなどのサポートだけでなく、答えが分からない時には、私たちを助けてくれるAWSの専門家たちを紹介してくれました。これらの取り組みの中には、Goldman側では前例のないものもあり、専門知識も持ち合わせていませんでしたが、彼女はプロジェクトの成功に大きく貢献してくれました。
先ほど申し上げたように、私たちはこの後も会場におりますので、質問にお答えしたり、経験を共有したりすることができます。ご来場ありがとうございました。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion