ビッグデータの先駆者トレーディング技術を理解するホワイトペーパー株式会社イースティル（www.estijl.com）代表取締役源口宏（[email protected]） 2016 年 8 月注意本書は著者の個人的な意見や批評、解説を述べたものです。トレーディング分野以外の IT 担当の経営者や IT 技術者を読者として想定して、トレーディング分野に使われている技術の概要をイースティルでの取り組みを例に理解を深めていただくことを目的としているため、技術的な正確性を欠く記述が部分的に含まれている可能性があります。なお本書は作成された時点の著者の思考に基づくもので、普遍的な内容ではありません。 1 ビッグデータの先駆者トレーディング技術を理解するはじめに半導体メモリーへのアクセスが I/O と呼ばれるようになったように、光速は「速さ」の代名詞ではなくなった。トレーディング技術者にとって、光ファイバーの速度は 1km あたり 5 マイクロ秒の遅延を発生させる足かせと考えられるようになり、待ちきれない技術者達は山脈にトンネルを掘って経路短縮するだけでは満足せず、マイクロ波で地上アンテナを連ねて通信するようになった。トレーディング技術は特殊な技術ではない。普通に使われている IT 技術の集積だが、手に入る技術を大胆かつ徹底的に利用したビッグデータの処理系を構築し、信頼度高く運営管理しているにすぎない。CPU や OS の特性を十分に理解したうえで、スループット（単位時間当たりの処理容量）を最大化させつつレイテンシー（処理遅延）を最小に保ち、高信頼性をアーキテクチャ設計に組み込む、繊細で高度なネットワーク・プログラミングの世界だ。製造業で物流、すなわち輸送、ロジやマテハンを考慮しないで立地や工場レイアウトを決定することがありえないように、情報の流通「情流」(筆者の造語) は経営の基本中の基本でなければならない。特に派生的に情報が生成されるのではなく、情報が原材料や商材となる産業では、トレーディング技術に代表される情報流通インフラ技術が産業を支え企業の競争力を左右する基幹技術の一つとなってくる。ビッグデータの技術創造 IT 技術は常に進化しているので、業界の技術変化を捉えて追従し、可能であれば先駆けて変化を起こして競争優位に立つためには、人を育てる以外の選択肢は無い。欧米では HFT 業者やヘッジファンドだけでなく、取引所も投資銀行も IT 技術者を大量雇用し IT 基礎分野の研究開発を重ね、IT 技術力を競争力の中心に据えている。イースティルは研究開発費用を自己の資金で賄うようにしている。優秀な技術者が、必要とするだけ時間を使い、考え抜き、時にはゼロからやり直したりして、世界最高レベルのトレーディング技術を支えるソフトウェアをスクラッチから開発してきた。これからはサーバやネットワークなどのハードウェアとの連携を密にしなければならないので、SI の研究開発テーマも設定して技術の育成をしている。長期にわたる研究開発費は、顧客の支払う一時的な開発費で賄う事ができないので、イースティルは研究開発レベルのエンジニアを顧客サービスの運用管理をする ASP サービス事業に従事させ、研究開発に必要な営業キャッシュフローを創り出している。そしてトラブルなく運用することで研究開発時間を創 2 ビッグデータの先駆者トレーディング技術を理解するり出し、顧客が利用する ASP サービスに研究成果を惜しみなく適用する努力を怠らないことで、ASP サービスの競争力を高めるポジティブなスパイラルの構築を目指している。技術調達について、イースティルではソフトウェアではオープンソースか技術の境界に潜む障害のリスクを避けるために内製のものを使い、ハードウェアでも汎用の民生品を使うという基本方針を持っている。世界中の技術者が生み出したハードウェアやソフトウェアの人類共有の技術蓄積を活用して、足りない技術は自分で創り出し、物理限界まで汎用ハードウェアを使いこなすことができれば、他のどんな特殊技術にもひけを取らない。ビッグデータの構築技術トレーディング技術は扱う財が高額なため、信頼性という運用要件が厳しい点に特徴がある。イースティルは ISO 27001(ISMS), ISO 20000(ITSMS), ISO 22301(BCMS)を取得して運用を重視しているが、本書では 24 時間運用、キャパシティ制御、取引所のポリシー変更や取引制度変更への対応を含む運用技術やセキュリティは省いて構築技術についてのみ取り扱うものとする。上流 8つのつの主要つの主要デリバティブズ取引所グズ取引所グループ例 CME, ICE, CBOE, JPX, SGX, HKEx, Eurex 取引所固有のデータフォーマット・プロトコル正規化されたデータおよびイースティルデータセンター内ティッカープラントプロトコルパブリッシュ・サブスクライブメモリー上のストリーミング送信フィードハンドデータキャッ配信システラーシュおよびリムイベント駆動でアルタイムデータ登録計算 UIごとの取引所固有リクエスト・セッションの電文・プロトレスポンスの状態を管正規化されコルを正規化たマーケッ時系列デー理するコンバート・データ・スタベースタトア履歴価格等下流利用者ごとのセッションを維持重複ログイン禁止・データ利用記録ユーザインタフェース .NETチャート, Excel（RSS), HTML5 サービス利用者バイサイド・デリバティブズ・トレーダすべての取引所の知的財産権を満たす制御を行うエンタイトルメントデータベース・システムで下記のデータを収集し配布する 1) 取引所のポリシーに関するデータ（例：データの有償・無償の区別など） 2) User ID/パスワードおよび契約品質（リアルタイム/遅延データ）、フル板/Level1/Level2 3) 取引所からの外部監査用のデータ利用ログ有償・無償の区別など個別の取引所ごとのポリシー変更イースティルのソフトウェア資産で：国内外特許か、デジタルタイムスタンプで保護 (RFC 3161) 図 1 ティッカープラントの概念図図１は扱うデータの発生から消費までの情報の流通を切り口として、ビッグデータの処理 3 ビッグデータの先駆者トレーディング技術を理解する系であるティッカープラントを構成する処理コンポーネント間の連携を示した概念図である。なおメッセージング・システムはデータセンター内の各コンポーネント間のすべての接続に使われる。以下ではトレーディング技術が扱うシステム設計の課題を 7 つに分けて説明を行う。 1. ビッグデータの WAN ネットワーク層とトランスポート層設計一般の通信技術者には馴染の薄いマルチキャスト通信がトレーディング分野では多用されている。これはビッグデータであるというデータ量の問題と、情報へのアクセシビリティにおいて時間的に公平であるための同報性という要件を同時に満たす必要があるからである。取引所が電文をユニキャストで送信していては、通信のネットワーク層やトランスポート層制御のために取引所センター側に多数のサーバ設備が必要になってしまうし、厳密な同報性を保証できない。WAN でマルチキャストが配信できれば、サーバ 1 式だけで理論上無制限のクライアントに同報で送信することができる。このため取引所からの相場報道の電文（以下ではデータフィードと呼称する）は、通常数個から数十個の IP マルチキャストグループに分割される形で送信され、ネットワーク層では PIM-SM のようなルーティングで経路制御される。取引所のデータフィードは IP マルチキャスト上の UDP で送信されるので単純なエラーチェックしかできない。データグラムにエラーがあった場合には破棄されるし、伝送路の途中でバースト破壊されても、通信障害があったかどうかも UDP では検出することもできず、リカバリーすることもできない。このためデータフィードには取引所のオークション・システムが生成する冗長化された伝送経路でも一致する固有のシーケンス番号が附番され、電文の欠落をシーケンス番号の突合で検出できるようにしている。データフィードの受信仕様は、パケット再送やリカバリーなどのセッション層処理を含めたクライアント API が採用される事もあるが、プログラミング言語や CPU アーキテクチャの選択肢を広くするなら、ネットワーク・プロトコル仕様を定めた接続規約を用いるべきである。このとき、地域の通信事情がプロトコル設計に大きく影響する。WAN プロトコルを設計する場合には、伝送容量、エラー率とコストが大きな設計の前提条件として意識される。地域ごとに最適なプロトコル設計パラメータは異なり、さらにプロファイルの差はアプリケーションごとに大きく違っている。 4 ビッグデータの先駆者トレーディング技術を理解するイースティルは電気通信事業法の通信サービスを提供する届出業者で、ダークファイバーを使って顧客に L1, L2, L3 の広帯域通信サービスを提供しているが、昨今の IP 機器やケーブルの品質向上などによって通信品質は高く保たれ、実際のところ伝送路のエラー率が低い。国内のどの通信業者もおしなべて安定した通信サービスを提供しているので、日本では高い通信品質に頼ってセッション層のプロトコル設計をすることが多い。大規模な通信キャリアでは常にパケット・ロスをリアルタイムでモニタリングしていないので原因はわからないが、東京証券取引所や大阪取引所のデータフィードを運ぶオフィシャル・キャリアの 100Mbps 広域 LAN サービス等を 10 年以上利用してきた経験から、東京都の中心は 2~3 カ月に 1 回程度の散発的な WAN パケット・ロスが発生する程度のエラー率でしかない。比較すると、海外の取引所のプロトコル設計では伝送時の伝送路が低品質であっても処理できるようにする前提でセッション層が設計されていて、単発的なパケット・ロスに対する復旧と、完全に差分データのシーケンスを見失ったバースト破壊的な状況からのコヒーレンスを得るための同期手順が定められている。これによって海外の取引所は比較的エラー率の高い国際海底ケーブルを敷設して地球規模のネットワークを取引所が独自に構築し、取引需要のある世界中の金融都市に非常に安価に直接データを届けると同時に取引注文を掻き集めている。 2. ビッグデータの WAN セッション層設計データ量が非常に多いために、取引所からのデータフィードは最後に送信した状態からの差分データだけを更新データとして送信する。取引所で日締めの処理が終わると、それまでのデータフィードの状態が前日扱いになり状態が初期化されてから当日取引のための注文が入り始める。初期化されてからは、差分データの形式で送られるため、一つでもパケットを取りこぼすと取引所の正しいデータの状態を再現する方法は無い。その対策として WAN 回線 2 系統を受信して欠落パケットを補完することで、圧倒的に信頼性を高めることができる。以前はサーバの処理能力不足で、取引所固有のデータフィードの電文フォーマットや独自プロトコルを正規化する役割のフィードハンドラーが、上流に複数経路を持つ事はパフォーマンス面で難しかったが、マルチコア・マルチスレッド CPU や OS の SMP 進化などで処理性能面での問題は 10 年以上前に解決された。 WAN 経由の UDP で 2 系統の電文を受け取る時に、整列化の深刻な問題を引き起こす。たとえば取引所のオークション・システムが連続して一意な番号を付与してくれて、複数系統の伝送路を経て受け取ったフィードハンドラーがその番号を使って整列化できれば、 TCP の Window 制御のように順序性を担保することは容易である。しかしながら、データ 5 ビッグデータの先駆者トレーディング技術を理解するフィードにオークション・システムから一意な番号が付与されない取引所も存在する。このような場合には、データフィードのシーケンスを電文の内容から同一性を推定して比較することで欠落を判断しなければならないことになる。イースティルの国際特許の一つは、これらの整列化処理を統一した方法で実装するためのものである。取引所の異なる電文形式を正規化する変換処理に、レイテンシーを意識して NIC に装備されている FPGA を使うフィードハンドラー業者も少数ながら存在する。残念ながら FPGA 利用時に求められるデータフロー・プログラミングは人の思考と直線的に結びつかないために、フォーマット変換などの単純なアルゴリズム実装にしか使えず、保守の体制が安定的に構築できないことからイースティルでは CPU で変換処理をしている。 3. ビッグデータの LAN 高信頼性設計 LAN 環境では、送受信の全体が内部システムなのでプロトコル設計は自由である。IGMP で IP マルチキャストへのジョイン状況をスヌーピングすることで経路制御と効率化が行われるが、トランスポート層では純粋な UDP ではなく拡張 UDP として信頼性を作り込むことができる。拡張 UDP は、UDP のデータグラムに独自のシーケンス番号を付与することで信頼性を高める。連続するシーケンス番号をフロー制御しても取得できない場合に、クライアント側から送信元にアドホック的に TCP で NACK(Negative ACKnowledgement) 応答を返して再送を依頼するなどの欠損データのリカバリー処理を行う。これら一連の処理はパブリッシュ・サブスクライブを処理するメッセージング・システムで実装され、リクエスト・リプライの処理もメッセージング・システムに統合されている。拡張 UDP のプロトコル実装は、20 年以上前からいろんなメッセージング・システム (Reuters RMDS, TIBCO Rendezvous 等)で行われてきた。メッセージング・システムは、拡張 UDP だけでなく WAN 経由でブランチ・ディーリング・ルームを統合して接続するなどのために TCP を使うようにトランスポート層を簡単に設定で切り替えられるようになっている。また LAN 環境ではイースティルのティッカープラントは、すべての主要コンポーネントで冗長経路設計がなされていて非常に信頼性が高い。ネットワークや機器に障害があっても、それが直接接続する下流側のコンポーネント１つだけしか影響を受けないようにリカバリー単位の粒度を小さくする多層構造を採用することで、24 時間の連続運用サービスを信頼性高く提供できる。障害が発生した時にリカバリー単位が大きいと、データが大量なだけに復旧に時間がかかるだけでなく、復旧作業の大きなシステム負荷が系全体に不安定さをもたらしてしまうのである。1 か所の障害を契機にドミノ倒しでバタバタと正常なサーバが 6 ビッグデータの先駆者トレーディング技術を理解する停止する事故は、システム負荷が強いビッグデータでは、きちんとリカバリー設計がなされていない処理系で簡単に発生する。 4. ビッグデータのスループット設計世界最大のデリバティブズ取引所である CME Globex 取引所の 2016 年上半期のピーク電文数は実測で秒間 11 万件であった。つまり、取引所ごとに接続を処理するフィードハンドラーは秒間 11 万件をリアルタイム処理する必要があり、2 系統のデータフィードを受信して高信頼性を確保するフィードハンドラーは秒間 22 万件の電文を受け取る。通常は取引所に対応させて 1 式のフィードハンドラーで構成するが、スループットやレイテンシーの性能を稼ぎたい場合には、マルチキャストグループごとに 1 式のフィードハンドラーを割り当てることもできる。複数の取引所をサポートする必要のあるティッカープラント全体では、トレーディングのピーク時刻の分散を考慮しても一桁大きな処理性能が必要である。ところが PC サーバは発熱の問題から動作周波数の限界に達しており、クロックを上げることができない。したがって、PC サーバの処理性能を引き出すのは並列プログラミング技術である。当社ではティッカープラントの主要コンポーネントであるデータ・キャッシュに、Xeon のスレッド数の制限から１プロセスあたり秒間 32 万件までの電文を処理させるようにしている。直線的なデータ処理が特徴のフィードハンドラーでは 2 プロセスで処理させられる。ティッカープラントを構成するサーバに Xeon を規格外のオーバークロックで定常的に安定して動かせられる特別な BIOS やマザーボードで構成したサーバを使うこともある。むろんデータ・キャッシュ用のサーバもスケールアウトして使う事はできるが、サーバを冗長化して負荷分散させるためには、サーバはクライアントと疎な結合でなければならない。その間に必要な柔軟な経路制御、モニタリングやイベント処理にもメッセージング・システムが使われる。情報流通インフラ技術の中心はメッセージング・システムである。データ・キャッシュでは、電文の最新の状態を維持してイメージを保全するためにメモリー・データベースを利用して処理する必要がある。大規模な取引所のデータ・キャッシュを外部記憶装置へ配置するのはサーバの入出力チャネルの帯域制約、遅延や費用面から NVMe でも現時点では難しいからだ。バッファなどのメモリーの動的確保や管理にはプログラミング言語用の一般的なライブラリを利用するのではなく、自社独自のアプリケーションに特化したメモリー管理ツールセットで標準ライブラリを置き換えて利用するなどの対策が必要である。 7 ビッグデータの先駆者トレーディング技術を理解するアルゴリズム取引のロジックや投資戦略を策定・改良する時や、インフラの改定には膨大な量の過去データがバックテストの対象として必要になる。取引所の全データを保存してゆくためには専用のサーバを使うが、テラバイト級のディスク容量があっという間になくなってしまう。イースティルでは、取引所電文のジャーナルを約定だけでなく気配を含む形式で提供し、利用者が自由な加工ができるように、取引所の日締め処理後にファイルサービスとして FTP やプライベート・クラウド・サービスからの参照をできるようにしている。CME グループの主要 4 取引所の 1 日のデータ量は、取引が活況かどうかによって異なるが 100GB から 200GB 程度のファイル容量となる。 5. ビッグデータのレイテンシー設計取引可能な金融商品の１つに対応するサブジェクトは 1 秒間に数千回更新されることがあり、その多くは約定(売買の取引成立情報)ではなく気配(売買の注文登録・取消情報)だが、約定も市場が開いた直後はミリ秒間隔やそれ以下で更新されることがある。コンピュータ以外の人が注文処理をする場合、取引のトレンドを掴むために約定が使われ、データ量が多すぎるので取引のタイミングを掴むためだけに気配が使われることが多い。ブラウザなどで人が認知できるように数十銘柄程度のデータを表示するという用途では 100 ミリ秒単位での画面更新は、あまりにもちらつきが多くなってしまって人の認知限界を超えてしまうので不適切である。またスマホやタブレットなどのモバイル機器では電池の消費量が増えてしまうので高頻度更新は望ましくない。300 ミリ秒から 1 秒くらいの期間の差分の最終状態だけを送信するような処理を行う。デリバティブ取引所のデータのカバレッジは、オプションなどの金融商品があるので、CME Globex では 30 万銘柄以上の取引可能な金融商品が上場されている。コンピュータで取引市場を分析して注文するアルゴリズム取引の場合、投資戦略にも依存するが数千～数万の金融商品データが使われる程度が一般的であろう。いずれにせよ、アルゴリズムへの入力データとなる金融商品だけにデータの範囲が限定されて市場の全データを使うことは無いので、取引をする利用者側でのデータ量の多さはコンピュータで処理する限り気にならない。つまりスループットとレイテンシーは相反する要件だが、取引する利用者側ではレイテンシーが大きな要件となる。一般にアルゴリズム取引に許容される遅延は数ミリ秒以内、高頻度取引(HFT: High Frequency Trading)とよばれる取引では数十から百マイクロ秒程度以内を目指すことになる。光ファイバーの物理遅延から 1 マイクロ秒以内に通信遅延を収めるには 100m 以内の光ファイバー長で取引所のサーバと接続する必要があることになる。HFT 業者がサーバを 8 ビッグデータの先駆者トレーディング技術を理解する設置するコロケーション用データセンター内のラック位置にも敏感な理由はこういう所からきている。遅延は少なければ少ないほど良いので、取引対象や投資戦略に関わらずトレーディング技術では常に重要な評価対象となる。 2018 年 1 月に始まる予定の欧州連合（EU）の第 2 次金融商品市場指令（MiFID II）では、非アルゴリズム取引は 1 秒、アルゴリズム取引は 1 ミリ秒、高頻度アルゴリズム取引は 100 マイクロ秒でのタイムスタンプが取引関連記録として必要になる。NTP ではミリ秒以下の精度でサーバ間の時刻同期ができないので、PTP (IEEE 1588) プロトコルを使った GPS からの同期が求められることになる。遅延はあらゆる場所に存在していて、低遅延スイッチや低遅延 NIC や InfiniBand をインターコネクト技術として利用している事が多い。それらのハードウェアを使いこなすためのソフトウェアとして、カーネルバイパスやゼロコピーあるいは RDMA といったネットワーク I/O をユーザ空間で行なうことで、OS のコンテキスト・スイッチのオーバヘッドや CPU のパイプラインハザードを防ぎつつ、アプリケーションでは NUMA アーキテクチャを意識してデータ処理のローカリティを高めキャッシュヒットを稼ぐとともに、データへの絶対的なアクセス頻度を削減することで低遅延を達成しなければならない。アプリケーションレベルでは、永遠に続く並列プログラミングのチューニングが求められると考えなければならず、優秀なソフトウェア・エンジニアが常にデータの流量や流列の変化をモニタリングして改善を加えてゆく。このときに精度の高い絶対時刻でのタイムスタンプがチューニングの大きな判断材料になる。 Java を使っている場合、GC(Garbage Collection)のコントロールに苦労する。特に Full GC が発生すると JVM が停止している間に通信データが溢れてセッションが切断される。このためにコンカレント GC をチューニングして使うか、商用 JVM を使う。欧米の金融機関では非常に効率の高いコンカレント GC を自動的に行ってくれる商用 JVM が人気で、イースティルで検証した範囲では絶対レイテンシーを減少させ GC によるレイテンシーのゆらぎを無くすことができた。お金を払ってチューニングに要する時間を買うという選択肢を選ぶ企業は欧米には多い。 6. ビッグデータのリアルタイム計算取引所は VWAP/TWAP など単純四則演算、ソートしたランキングやイベントの数え上げなどの計算処理以外の、取引所データを加工して生成する派生データについて保守的である。指数などの取引所データを使った派生データの生成と配信は、通常情報ベンダーには許諾 9 ビッグデータの先駆者トレーディング技術を理解するされない。オプションなどの派生商品では、インプライド・ボラティリティや伝統的にギリシャ文字で表記されるためにグリークスと呼ばれるリスク評価値については計算が許諾されることがある。これらの評価値が無いと生データだけでは直感的にリスク尺度を人間が想像できない。グリークスの計算には浮動小数点演算が必要である。しかも、そのデータがリアルタイムで価値を産むために、計算は実時間内に完了させなければならない。このため小規模な量の演算であれば通常の CPU の浮動小数点命令を使って計算されるが、多くの計算が必要とされるために GPU を使って計算させることがある。GPU では 3000 個程度の浮動小数点演算装置を並列実行できるため、CPU の高々64 個程度のスレッドと比較すると優位性がある。たとえば Apple 社の株式の約定は 1 つだとしても、その派生商品である個別銘柄オプションは 3000 種類ほど上場されているので、Apple 社の株価が約定のたびに変動すると Apple 株オプションのグリークスなどを計算するには GPU のパワーは有効である。また、同様に大量の計算処理が必要なモンテカルロ法を使ったリアルタイム・リスク計算にも有効性がある。イースティルでは、現行サービスの範囲内でのリアルタイム・リスク計算量が限定されているために、金融工学的な計算処理には CPU を使っている。GPU を使うためには、専用のハードウェアに対する SIMD 計算処理といった特殊なプログラミング技能が必要になり、コスト面からも CPU と比較して十分な優位性が認められないと使いづらい。またリアルタイム計算の分野で CEP (Complex Event Processing) が使われることがある。 CEP はリアルタイムでの計算契機や処理分岐を、データの値によって制御するシステムである。分析や注文などの処理手順を GUI などで簡易に設定できる点で、様々な例外が発生したりして変更頻度が多い処理に向いている。イースティルでは、バッチのイベント同期や時刻制御を組み合わせて設定する制御系でメッセージング・システムに組み込んだ簡易 CEP を利用している。 7. ビッグデータのデータアクセス制御設計取引所の取引データは誰の知的活動の産物かという点で、投資家全体が知的財産権を共有すると著者は考えるが、実際には取引所が権利を主張する有料データであり、無料データであっても取引所の権利が留保された形で課金が無いだけで権利が放棄されることがない。このため、各取引所のデータの権利を守る義務は、取引所のデータフィードを受信して利 10 ビッグデータの先駆者トレーディング技術を理解する用者に再配信する契約をしているイースティルのような情報ベンダーと呼ばれる業者に課されている。データの権利保護のためのシステムをエンタイトルメント呼び、情報ベンダーが接続するすべての取引所から妥当な設計と見なされるエンタイトルメント・システムを備えていないと情報ベンダー契約は結べない。エンタイトルメントには、利用者の特定、同一利用者の複数デバイスの同時利用の禁止、データの権利・権限を守れるアプリケーションのみの利用制限といった管理を行わなければならないし、その管理手法に基づいた取引所への報告義務と利用者に課される取引所データの利用料金の回収代行を行わなければならない。また、利用者の個人情報の収集保全と監査体制など、多様な義務が情報ベンダーには課されている。もちろん利用者とは別に、情報ベンダーも取引所料金や接続料金を支払う必要がある。ここで問題なのは、取引所によって課金対象とする利用者の数え方が異なり、人数・デバイス数・ディーリングデスク数・画面数などさまざまな単位で課金の単位が設定されていることであり、課金ポリシーのばらつきや不定期なポリシーの変更に情報ベンダーはランタイムで対応する必要がある。たとえば 1 カ月単位の課金がポリシーで設定されているとき、どのタイムゾーンで利用時間を判定するのかが異なっている。シカゴと日本では時刻差があるので、シカゴのデータを日本で使う場合にはシカゴ時刻で課金を制御し、シカゴ時間の 0 時 0 分にリアルタイム・データから 10 分遅延させた遅延データにセッションを切断することなく切り替えられるようでなければならない。また、利用者の使うアプリケーションについても強い制限がある。利用者が自身の端末装置から取引所データをインターネットなどで他者に再配信してしまわないように管理する義務が情報ベンダーには課されている。このため、情報ベンダーはどんなアプリケーションでどのデータを使ったのかについて制御するとともに記録し、監査のための利用記録を保全しなければならない。あとがきトレーディング技術をビッグデータの先駆技術として概説した。内容の深みは一般的な IT 担当経営者や IT 技術者にとっての常識レベルに留めて、トレーディング以外をモチーフとするビッグデータ担当者にレベル感を示して俯瞰できるように注意したつもりだが、掘り下げ方の多少の凸凹についてはご勘弁いただきたい。イースティルの技術者を含めた世界で競うトレーディング技術者は、日々技術創造や技術革新を起こすためにビッグデータに向き合っている。AI や機械学習などのビッグデータの 11 ビッグデータの先駆者トレーディング技術を理解する応用分野は筆者も用途開発として今後の成熟に期待を持っているが、そういった付加価値創造の世界を支える「情流」としての情報流通インフラ技術は、これまでトレーディング以外の多くの分野で見過ごされてきた。情報流通インフラ技術の中心にあるメッセージング・システムは、高スループットや低レイテンシーといった基本性能や信頼性の高さから、海外では大規模なプラント制御やミサイルの姿勢制御などでも使われている。イースティルでは、これまでの運用経験や世界最大の取引所データを扱ってみて、ビッグデータ分野での情報流通インフラ設計や実装方法についての技術リスクが無いことを証明できたと考えている。イースティルでは基幹技術のすべてが内製である低コスト構造を武器にして、世界に数多くある取引所へ接続種類を増やして国際通信で世界中の顧客に再配信する海外市場向けの垂直展開と、ビッグデータ向けの情報流通インフラ技術の別産業への応用という水平展開という 2 つの課題に向けた次のステージへ歩みを進めようとしている。 Appendix メッセージング技術関連の用語野村総合研究所のレポートiでは、第一世代がクライアント・システム内にローカル・デーモンが存在するもの、第二世代がメッセージング・ルータとしてデーモンが独立したサーバとなりクライアントは通信ライブラリを経由してデーモンと通信するもの、第三世代をデーモンが存在せずに通信ライブラリのみで通信する形態と定めている。秒間数十万件のスループットを達成するためには、ボトルネックになる処理コンポーネントの無い第三世代を使う必要がある。高スループットはビッグデータには最も重要な要件で、メッセージング・システムは IoT などに欠かせない技術であるが、これを実現するためにはマルチスレッディングでのクリティカルセクション管理において、Lock Free かつ Wait Free のノンブロッキングと呼ばれるアルゴリズムを採用するメッセージング・システムを採用しなければならない。イースティル・リンクは、世の中に知られている既知のアルゴリズムではなく、独自開発のノンブロッキング・アルゴリズムを採用する事でスループットを向上させている。これにより、イースティル・リンクは同一筐体内で秒間 800 万件の電文を処理する高スループットを達成していて、欧米の超低遅延メッセージング・システムと肩を並べる世界最高レベルの能力を誇る。また筐体間のスループットでは、マルチキャストでもユニキャストでも 10GbE の低遅延 NIC をカーネルバイパスで接続した実測で秒間 60 万件以上のスループットで送信でき、ピーク時でもゆらぎのない 1 ミリ秒以下の低遅延で配信できるようにし 12 ビッグデータの先駆者トレーディング技術を理解するている。以下は、メッセージング・システムで使われる用語を説明する。パブリッシュ・サブスクライブ（Publish-Subscribe） 20 年以上前から使われている、疎結合のアプリケーション間通信モデルがパブリッシュ・サブスクライブである。分散システム間でのストリーミング通信で使われるモデルであり、特にリアルタイム処理ではポーリングする必要が無く、イベント・ドリブンで遅延なく高速処理ができるために多用されるモデルである。 IP マルチキャストのジョインのように、いったんサブスクライブするとパブリッシャがパブリッシュする電文がすべてサブスクライバに送信される。映像や音響などのストリーミング通信はパブリッシュ・サブスクライブのメッセージングの例である。リクエスト・レスポンス(Request-Response) パブリッシュ・サブスクライブと対比される、それ以前から古典的に使われてきた素結合のアプリケーション間通信モデルである。サービスプロバイダーのアプリケーションがクライアントからの要求に応える形で応答を返す。 Web サーバとブラウザはリクエスト・レスポンスのメッセージングの例である。サブジェクト(Subject) サブジェクトは、パブリッシュ・サブスクライブやリクエスト・レスポンスの対象となる、データの最小構成要素である。個々のサブジェクトに異なる名称が与えられ一意性が保たれており、利用者から検索時に指定される。グループ全体を一括して検索するときには、ワイルドカード文字を使って表記することが多い。東京証券取引所の当日上場されている全株式銘柄を検索したい時に利用する。ティッカープラントでは、取引所名、アセットクラス、取引対象の資産名称、限月、行使価格、プット・コールのオプション種別などから構造化された命名規則(Name Space)が使われることが多い。サブジェクトはメッセージング・システム全体に対して検索要求されるのであって、サー 13 ビッグデータの先駆者トレーディング技術を理解するバ名を特定して検索するものではない。このような高い抽象化によってサーバの冗長化やスケールアウトを実現できる。イメージ/アップデート(Image/Update) パブリッシュ・サブスクライブで識別されるデータの種類のこと。イメージは、サブジェクトの現在の最新の状態の全体を伝えるデータを指す。アップデートは直近のイメージからの差分更新を伝えるためのデータを指す。検索時には最初にイメージを取得して、続けてアップデートを取得しなければならない。しかしながらイメージを送信するセッションとアップデートを送信するセッションが分離されていて、厳密に同期できない場合には整列化の問題が発生する。以上 i 2009 年 3 月，ネットワーク分野における基盤技術－XTP による証券トレーディングシステムの高速化－https://www.nri.com/jp/opinion/it_solution/2009/pdf/IT20090303.pdf 14 ビッグデータの先駆者トレーディング技術を理解する