東京証券取引所の株式売買システム「arrowhead」。ミリ秒レベルで応答する高速性が話題になったが、それは注文を受け付ける処理のことである。同システムでは約定処理もレスポンスの高速化を図っており、可用性も高い。プロジェクトに携わったNTTデータの平田氏と東京証券取引所の田倉氏に、その仕組みと取り組みを解説してもらう。

　株式売買システムの「arrowhead」が行っていることは、その昔、取引所の立会場で人手で行っていた業務を写し取ったものと考えるとよい。取引参加者（証券会社）からの注文を受け付け、銘柄ごとに分かれた板へ登録後、売り注文・買い注文の付け合わせを行って約定させ、約定した結果を通知する流れとなる。立会場のころであれば、取引所の職員と場立ちの人が注文をやり取りすることで事足りた。

　現在は、数千万件/日の注文を処理しつつ、数ミリ秒の速度を要求されるため、世界の取引所では高速、大容量のコンピュータシステムによる株式売買システムが必須となっている。

　東京証券取引所では2006年から次世代システムとしてarrowheadを検討し、ミリ秒レベルのレスポンス、99.999％の可用性、1週間程度でのキャパシティー拡張など、求める要求を明確にした。開発を請け負った富士通はこうした要求を実現するに当たり、新たなミドルウエア「Primesoft Server」を開発。このソフトはメモリーデータベース機能を提供し、メモリー中のデータの3重化やデータ同期により可用性も確保している。

　2010年3月号ではプロジェクトとしての話をまとめている。本稿では、高速性と可用性に注目し、どのような技術や取り組みで実現したかを説明する。

キューもテーブルもすべてメモリー

　図1は、株式の売買に直接かかわるarrowheadの処理の流れである。業務視点で見た場合、注文系処理と約定系処理の二つがある。注文系処理とは、注文を受け付けたことを確認、内容をチェック後、サーバーへ登録し、それを通知するまでの処理である。ニュースなどで取り上げられている「ミリ秒レベルのレスポンス」とは、この注文系処理のレスポンスのことである。

　注文系処理の後、売り注文と買い注文をマッチング（板登録、付け合わせ）して約定し、約定したらその結果を通知する。これら一連の処理が約定系処理である。約定系処理はあまり報道されていないが、注文系処理と同様、従来のシステムと比べて数百倍のレスポンスの高速化を実現している。

　システム構成は、「参加者GWサーバー」「注文管理サーバー」「トレーディングサーバー」などからなる。いずれも富士通のIAサーバー「PRIMEQUEST」で、OSはLinuxである。

　では、高速処理のポイントを五つ説明し（図2）、その後可用性について説明する。

(1)すべてをオンメモリーで処理
　注文を受け付けてから約定結果を通知するまで、ディスク入出力は発生しない。ディスクへの書き込みは、記録のために約定処理後に行っている。

　arrowheadは複数のアプリケーションプロセスから成り立っており、プロセス間のデータの受け渡しに「キュー」を、データの保管に「テーブル」を用いている。テーブルはRDBではないものの、データベース機能を提供し、インデックスによる高速アクセスが可能である。特徴的なのは、キューとテーブルはメモリーに存在することである。Primesoft Serverの機能で実現している。

　キューやテーブルへの書き込み処理はトランザクションとして実装されているが、コミットしてもディスクに書き込まず、ノード間でメモリー同期を行う（Primesoft Serverの）機能によりデータを保護する。その仕組みは、後の可用性にて説明する。

(2)キューだがポーリング不要
　キューは非同期でデータの受け渡しができるので、処理待ちにならない。同期処理だと受け取った側の処理が終わるまで待つことになり、次の処理に進むことができない。半面、キューにデータが届いたかどうかは、受け取る側がポーリング（定期的に参照すること）で知るのが一般的である。それが遅延の原因になりやすい。

　arrowheadの場合、キューにデータを投入すると、データを受け取る側にそのことが通知されるので（Primesoft Serverの機能として提供）、ポーリングが不要であり、データの受け渡しに遅れが発生せず後続処理を速やかに実行することができる。

(3)UDPベースの高速通信
　ノード（サーバー）間通信はTCPではなく、シンプルなプロトコルであるUDPをベースとした通信方式を使用しており、高速通信が行える。UDPはTCPに比べ信頼性に欠ける面があるが、Primesoft Serverが独自技術で補完している。

(4)証券会社ごと、銘柄ごとに並列処理
　大量注文を高速処理するには、処理を並列化し、プロセス間の競合ができるだけ起こらないようにするのがポイントである。注文は証券会社から送られてくるので、注文系処理は証券会社ごとに処理するのが効率的である。

　約定系処理のマッチングは株式銘柄ごとに独立して実行できるので、銘柄ごとに処理するのが効率的であり、注文データを銘柄ごとに分けることができれば、複数処理を並列実行できる。そのための工夫が、「証券会社別注文キュー」と「銘柄別注文キュー」である。

　証券会社から送られてくる注文は、最初、証券会社別注文キューに入れられる。arrowhead内部ではそのキューから注文データを取り出し、銘柄別キューに入れ直している（これを「処理機軸の変換」と呼んでいる）。こうすることにより、参加者GWサーバー、注文管理サーバーでは証券会社ごと、トレーディングサーバーでは銘柄ごとに並列に処理を実行し、大量注文を高速に処理できるようにしている。

(5)性能に関する各種規約
　アプリケーション部分にも目を配った。性能を確保するための設計規約やコーディング規約（後述）を作成したほか、業務ロジックの見直しを重ね、不要なロジックを排除した。