3forgeは、世界でもっとも要求の厳しい取引環境のいくつかの中心にあります。それが内部からどのように見えるのかを理解するため、私たちはAmit Kumar Mishra氏に話を聞きました。高頻度取引でリアルタイムの運用システムを長年にわたり構築してきたエンジニアです。150の分断された画面から単一の運用席への移行、それを可能にするアーキテクチャ、そしてなぜ動きの速い市場では可視性だけでは不十分なのかを語ってもらいました。
3forgeと最初に出会ったきっかけ、そしてそれを引き寄せた課題は何でしたか。
3forgeとの最初の出会いは2023年ごろ、高頻度取引の環境で働いていたときでした。当時もっとも大きな運用上の課題は断片化でした。運用監視は取引インフラ全体で150を超えるアクティブなRDPセッションに依存しており、各サーバーが独自のレポーティングシステム、スクリプト、監視ユーティリティ、孤立したワークフローを抱えていました。
可視性の大部分は、時間をかけて寄せ集められた個別のツールやカスタムスクリプトに依存していました。多くのサマリーや取引所レベルのレポートは市場終了後にしか得られず、運用上の判断はリアルタイムではなく後追いになりがちでした。
経営からの要件は非常に明確でした。すべてを統一された運用ビューにまとめること。取引、アルゴリズム単位のPnL、ネットポジション、損失、リジェクト、アラートへの可視性を、オフィスでもリモートでも、単一の席からリアルタイムに監視できるようにすることでした。それが私の3forgeとの最初の実践的な出会いでした。
何を解決しようとしていて、最初に何が印象に残りましたか。
当初の焦点は、運用の統合と継続的な監視でした。分断されたレポーティングシステムへの依存をなくし、重要な取引・インフラ情報を継続的に追跡できる統一レイヤーを作ろうとしていました。
すぐに際立ったのは、複数のシステムからのライブデータを、構造化された対話的な運用ビューに集約できることでした。終業後のサマリーを待つ代わりに、損失、リジェクト、取引活動、戦略単位のPnLがリアルタイムで見えるようになりました。
もう一つの重要な変化は、プラットフォームが可視化だけにとどまらなかったことです。同じデータを、分析、監視、ワークフロー駆動のアクションにも使えました。それはダッシュボードに対する考え方をすっかり変えました。受動的なレポーティングから、運用インテリジェンスへと移行したのです。
3forge以前、リアルタイム取引システムは通常どのように組み立てられていましたか。
私が見てきたリアルタイム取引環境の多くは、統一された運用プラットフォームというより、分断されたシステムの寄せ集めとして組み立てられていました。各チームが、個々のアプリケーションやサーバーの周りに、自前のレポーティングユーティリティ、ダッシュボード、スクリプト、監視レイヤーを作っていました。
運用上、これは重複と断片化を生みました。複数のRDPセッション、孤立したレポーティングツール、別々のデータベース、スプレッドシート、カスタムスクリプト、独立した監視ユーティリティが当たり前でした。リアルタイムシステムは特定のワークフローや個人に強く結合しがちで、トラブルシューティングには複数のシステムを行き来する必要があり、手作業の調整に大きく依存していました。
もう一つの大きな摩擦は、可視性の遅延でした。多くの重要なサマリーやレポートは市場終了後や終業時にしか得られませんでした。異常、損失、リジェクト、執行の問題が見えるようになるころには、先回りして対応する機会はすでに過ぎていました。
ライブ市場フィード、履歴データセット、分析エンジン、可視化レイヤー、運用ワークフローを統合することにも大きな複雑さがありました。多くの環境ではこれらが独立して進化し、ロジックの重複、データの繰り返し移動、インフラの負荷を生みました。3forgeで際立ったのは、監視・分析・ワークフロー・ライブな運用状態が、はるかに統合された形で共存できる、中央集権的でイベント駆動のモデルへ移行できることでした。
時間とともに、プラットフォームに対する見方はどう変わりましたか。
当初、3forgeは主にレポーティングとダッシュボードのレイヤー、つまりリアルタイムのPnLサマリーや運用指標をより見やすく可視化する手段だと捉えていました。本番環境で利用を拡大するにつれ、より重要なアーキテクチャ上の側面が見えてきました。
最初の気づきの一つは、HFT環境ではダッシュボードそのものは実は簡単な部分だということです。本当の難しさは、大規模な分散インフラ全体でのデータの移動と同期にあります。数百台のサーバーからポーリングで運用データを継続的に取得すると、ネットワーク負荷、スケーリングの困難、レイテンシ、運用の複雑さが生じます。
次第に重要になったのは、3forgeがリアルタイムの状態伝播とデルタベースの処理をどう扱うかでした。完全なデータセットを繰り返し転送する代わりに、増分の変更だけがネットワークを流れます。大規模な環境では、この違いが大きく効きます。継続的な可視性を保ちながら、不要なトラフィックを減らせるからです。
プラットフォームのモジュール性も際立ちました。最初のダッシュボードを超えて進むと、異なるコンポーネントが運用上つながったまま独立して進化できる、より広いワークフローを支えられることが分かりました。そして使いやすさも重要でした。基本的な技術知識のあるチームが、長い開発サイクルなしで有用な運用ビューを作れたのです。これがインフラチーム、運用チーム、ビジネス利用者の間の障壁を下げました。時間とともに、私の理解は3forgeを可視化プラットフォームと見るところから、リアルタイムの運用フレームワークと見るところへと移りました。
HFT環境で「デフォルトを超える」とは、具体的にどういう意味ですか。
HFTでは反応時間が決定的で、アーキテクチャを従来のポーリングベースのモデルに据えることはできません。ポーリングは遅延、不要なネットワークトラフィック、スケーリングの負荷を生み、データを取得して処理し終えるころには、対応する機会がすでに失われていることがあります。
多くのデフォルト構成の限界の一つは、システムがモノリシックな環境で楽にスケールするという前提です。実際には、モノリシックなアーキテクチャはすぐにボトルネックになります。依存が一つ増えるたびに、競合、遅延、復旧の複雑さが加わるからです。私たちにとってモジュラーなデプロイは極めて重要になりました。取り込み、ワークフロー、可視化、分析を分離することで、状態を同期させたまま、インフラへの負荷と運用上の脆さの両方を減らせました。
もう一つの課題はデータフローの信頼性です。レイテンシが低くても、受信側のレイヤーは情報を取りこぼさずに、更新のバーストを継続的に取り込めなければなりません。
そして可視性だけでは不十分です。人間がリアルタイムの変化を瞬時に見られても、人間の反応時間自体がボトルネックになります。次の進化は、システムが取引データ、運用イベント、市場状態の変化に直接サブスクライブし、自動的にアクションをトリガーするイベント駆動のワークフローです。そこでアーキテクチャは、ダッシュボードと監視から、リアルタイムの運用オーケストレーションへと移ります。
特にCenter、Web、Relayといったコンポーネントについて、モジュール性はどんな役割を果たしますか。
取引インフラにおいて、モジュール性は単なる設計上の好みではなく、運用上の必然です。コンポーネントが同じ物理マシン上で動いていても、責務を分けておくことで、環境のスケール、トラブルシューティング、進化が容易になります。
私の考え方はシンプルです。Relayは取り込みを担い、Centerインスタンスはデータの処理と保持を担い、Webは表示とユーザー操作に集中すべきだ、というものです。私たちはRelayを使ってKafkaからデータを取得し、関連する消費インスタンスへ条件付きで転送していました。これにより不要なデータ移動を避け、下流のモジュールが必要なものだけにサブスクライブできました。
責務が一つのモノリシックな構成にまとめられていると、スキーマ変更のような小さな変更でさえ再起動を要したり、より広い混乱を招いたりします。モジュール性があれば、各コンポーネントが独立して自分の役割を果たします。あるモジュールは取引データを処理し、別のモジュールはPnLを計算し、別のモジュールはアラートやサブスクリプションを扱い、Webレイヤーは処理結果をまとめて表示します。これにより、各段階が前段の完了を待つのではなく、計算とワークフローを並列に実行できます。
あるモジュールで処理されたデータが、別のモジュールのソースにもなり得ます。そうしてリアルタイムワークフローの連鎖が生まれ、複数のインスタンスが同時に動き、システム全体を止めることなく、それぞれがデータフローに価値を加えます。そこに、分離が生む真の運用価値があります。レジリエンスの向上、不要な依存の削減、並列処理、そして環境の特定部分を独立してスケールしたり変更したりできることです。
低レイテンシ環境で、リアルタイムのデータアーキテクチャが難しいのはなぜですか。
難しいのは、システムが速度・信頼性・継続的な状態の正確さを同時に両立させなければならないからです。HFTでは、データは均等には届きません。取り込みのスパイク、イベントのバースト、受信側がキューを継続的に空け続けなければならない時間帯があります。キューが積み上がり始めると、システムは技術的にはまだ動いていても、運用上はすでに市場に遅れ始めています。
最大の課題は、取り込みのスパイク、レイテンシと信頼性のトレードオフ、そしてライブデータと履歴データの収束です。ライブのシステムは待てません。たとえば注文のリジェクトは、すぐに見えて即座に対応されなければならず、さもなければビジネスへの影響はすでに発生しています。履歴のシステムは性質が異なり、バッチ処理、リプレイ、集約、より長い期間のパターン分析ができます。私たちの場合、6か月のローリング期間で市場の状況や運用の挙動を見られることが、分析と戦略改善にとって価値あるものになりました。
ライブフィード、履歴データ、分析、可視化、ワークフローを同じアーキテクチャに組み合わせようとすると、課題は大きくなります。ライブのシステムはリアルタイムのリソース、高速な処理、即時の応答能力を必要とし、履歴のシステムはストレージ、集約、リプレイ性を重視します。ライブ環境では、スループット、キューの掃けぐあい、ワークフローのサブスクリプション応答時間がいずれも重要です。データを表示するだけでは不十分で、システムは関連イベントにサブスクライブし、素早く処理し、ボトルネックを生まずに応答をトリガーしなければなりません。だからこそリアルタイムの取引アーキテクチャは、最初からイベントフロー、バッファリング、状態管理、応答時間を中心に設計されるべきなのです。
インドの取引テクノロジーのエコシステムで、どんなトレンドが見えていますか。
インドの取引テクノロジーのエコシステムは非常に速く進化しており、リアルタイムシステムへの期待はこの数年で大きく変わりました。かつて多くの環境は、スクリプト、孤立したレポーティングツール、手作業の監視、終業時のサマリーで組み立てられていました。今日では、企業は注文、取引、リジェクト、PnL、リスク、インフラの健全性、運用上の例外へのライブな可視性をますます求めています。
自動化、リアルタイム監視、市場データ処理、運用ダッシュボード、イベントへのより速い対応への重点が高まっています。アルゴリズム取引とインフラの近代化はもはやニッチではなく、主流の運用上の優先事項になっています。もう一つの大きなトレンドは、受動的な表示としてのダッシュボードから、運用の制御レイヤーとしてのダッシュボードへの移行です。チームは、ライブデータにサブスクライブし、異常を検知し、アクションをトリガーし、下流システムに供給し、人間の反応時間を縮めるシステムを求めています。
同時に、多くの企業はいまだに、断片化したツール、人に依存したワークフロー、レガシーシステム、遅れた可視性による摩擦に直面しています。今の好機は、分析・監視・ワークフロー・ライブなデータ処理が不要な重複なしにつながる、モジュラーでイベント駆動のアーキテクチャへ移行することです。インド市場は、企業が「データを見られるか」だけを問う段階から、「システムは何が変わったかを理解し、意味を持つほど速く反応できるか」を問う段階へと入りつつあります。
ダッシュボードからイベント駆動のワークフローへ、期待はどう変化していますか。
期待は明らかに、受動的な可視化ツールとしてのダッシュボードを超えつつあります。PnL、取引、ポジション、注文、例外を一か所に表示するダッシュボードは依然として重要ですが、高頻度の環境では可視性だけではもはや不十分です。
本当の問いは、システムが変化を検知したあと、何が起きるかです。注文がリジェクトされたら、戦略が想定の挙動から外れたら、PnLが急に悪化したら、あるいはインフラの健全性が変わったら、システムはそれを単に表示するだけであってはなりません。イベントにサブスクライブし、条件を評価し、ワークフローをトリガーし、適切な人に通知し、必要に応じて下流システムへ供給して次のアクションにつなげるべきです。そこで取引インフラは、ダッシュボードからイベント駆動の運用システムへと進化します。
私たちの環境では、リアルタイムのサブスクリプションと運用ワークフローが不可欠になりました。手作業の観察への依存を減らし、運用上の反応時間をできる限り短くするため、リアルタイムの監視条件によってトリガーされるSlackベースのアラートやキルスイッチの仕組みを実装しました。人間の反応時間は大きな要因です。動きの速い市場では、誰かがダッシュボードで問題に気づいて手動で反応するころには、影響はすでに発生しているかもしれません。企業はますます、可視化以上のことをするプラットフォーム、すなわちサブスクリプション、アラート、自動アクション、外部システムとの統合、そして運用インテリジェンスを即時の対応へ変える能力を求めています。
時間をかけて使う中で、3forge自体はどのように進化しましたか。
当初、3forgeは主にレポーティングと可視化のレイヤーだと捉えており、私たちの最初のユースケースは運用の統合でした。取引、PnL、損失、リジェクト、監視を統一されたリアルタイムビューにまとめることです。時間とともに、私の理解は大きく変わりました。
最初の大きな気づきの一つは、3forgeがカスタムのワークフローや統合と組み合わさることで、単なるダッシュボードシステムにとどまらず、はるかに広い運用アーキテクチャへと進化し得るということでした。深く探るにつれ、インメモリの表形式データ処理、履歴ストレージ、リアルタイムのサブスクリプション、トリガー、AMIScriptのワークフローといった機能がますます重要になりました。私たちは、情報を上に表示するだけでなく、プラットフォームの周りに運用ロジックを構築し始めました。
進化は段階的でした。最初は外部のPythonプロセスを使ってデータをポーリングし、計算を行い、処理結果を書き戻して、当時のデフォルト機能を超えるワークフロー、たとえば戦略固有のPnLやカスタムの運用分析を支えていました。後にはより緊密でネイティブな統合のために、JavaでカスタムのAMIモジュールを開発しました。それによってプラットフォームへの見方は、可視化ツールから、柔軟なリアルタイム運用フレームワークへと変わりました。
もう一つの大きな変化は、サブスクリプション駆動のモデルでした。状態の変化を継続的にポーリングする代わりに、システムは関連する更新にサブスクライブしてリアルタイムに反応できました。これは、反応時間が直接効いてくる、監視やオープンポジションの手仕舞いのようなワークフローで特に重要でした。戦略的に価値があったのは、アーキテクチャの開放性です。カスタムの処理レイヤーを統合し、履歴とリアルタイムのデータを組み合わせ、トリガーとワークフローを構築し、全体を作り直すことなくシステムを段階的に進化させられました。時間とともに、私の見方はレポーティングプラットフォームから、分析・ワークフロー・監視・サブスクリプション・自動化・カスタム統合をともに支えるリアルタイムの運用エコシステムへと移りました。
要求の厳しい環境で3forgeを導入するチームに、どんな助言をしますか。
まず、取引システムを通るイベントのライフサイクル全体をマッピングすることから始めるべきです。データが取り込みからワークフロー、分析、ストレージ、そして最後にダッシュボードや自動アクションへとどう流れるかを理解することです。取引では、取り込まれた一つの注文が複数の独立したワークフローを同時にトリガーし得ます。同じパケットが、未約定の注文簿、注文履歴、約定簿、リジェクト簿、取消簿、ネットポジション、注文分析モジュールを同時に更新しなければならないこともあります。後にはネット簿の計算が約定簿のデータに依存し、リアルタイムの価格は市場データシステムから別途取得する必要があるかもしれません。
重要なアーキテクチャ上の判断は、どのワークフローが逐次で、どれが並列に実行できるかを見極めることです。プロセスを同時に実行できるなら、長い逐次の連鎖を強いるのではなく、パケットを直ちに複数のインスタンスへ転送すべきです。チームが犯しがちな最大の誤りの一つは、すべてのフローを同じ処理インスタンスに置くことです。そのモデルでは、前の注文がすべての段階を終えるまで次の注文が効率よく進めず、不要なレイテンシとボトルネックを生みます。代わりに、各インスタンスが特定の責務を担い、下流のモジュールが必要なデータだけにサブスクライブする、モジュラーで並列な処理を中心に設計すべきです。
データ設計も重要です。チームはしばしば、フィールドのカーディナリティを評価せずに、受け取ったままのデータを保存します。3forgeはカラム型のストレージモデルを使うため、高カーディナリティのフィールドはライブ環境で不要なメモリ圧迫を生み得ます。履歴のシステムは、データを時間をかけて圧縮・再編成できるため最適化しやすいのですが、ライブのシステムは最初から慎重なメモリ計画を必要とします。
設計の早い段階で、ダッシュボードの先を考えることも強く勧めます。本当の利点は、サブスクリプション、トリガー、カスタムのロジックで自動化できるワークフローを見極めることから生まれます。最大の意識の転換は、ダッシュボードはアーキテクチャの一つのレイヤーにすぎないと理解することです。本当の競争優位は、運用上の反応時間を縮め、ワークフローを賢く分散し、リアルタイムの可視性をリアルタイムのアクションに変えることから生まれます。私がよく立ち返る言葉があります。「次は何か……なぜ、より良くしないのか？」
