By David Chapel

2008 年9月、東京証券取引所（東証）は「リモート取引参加サービス」についての計画を発表しました。これは日本に支店を持たない海外の機関投資家が直接日本の 市場に参加できるようになる、画期的な提案です。当初、入札段階では東証は新Arrowhead システムにFIXゲートウェイの搭載を検討していましたが、取引所参加者に対するアンケートで、会員はグローバル・コミュニケーション・プロトコルに対し てほとんど興味を示していないという結果が出ました。
こ のアンケート結果に多くの人が驚きましたが、東証の会員を詳しく見てみると、国内の小規模プレーヤーに大きく偏っていることがわかりました。現在、東証に は106社の証券会社（現地支店を「国内全般取引所参加者」として登録している外資系証券会社も含む）および11社の国外証券会社が会員として登録されて います。そのうち、約40社のみ（日本法人を通して登録している外資系証券会社と、国際的な取引を行っている国内の証券会社とはほぼ同数に分かれる）が FIXゲートウェイの必要性を感じていると推測されます。
標 準化された取引所API を通し、現地の取引所と相互取引できるプロトコルに興味を持っているArrowheadの将来のリモート会員に対してFIXゲートウェイを導入するメリッ トを考えると、現在国内の会員の間ではニーズが低いとしても、東証はその決定を再考するべきだと私たちは考えています。
なぜFIX なのか?
FIX は日本では新しいコンセプトではありません。メタビットにおいては、2004年から日本の主要な証券取引所接続にFIX / 取引所APIを変換する取引所ゲートウェーを提供しています。Arrowhead の開発によって、当社では低レイテンシーと拡張性に重点を置いた既存のFIXゲートウェイの再構築が促進されました。スピードに対するこうした需要は、 FIXは遅いと取引所の間で思われていることを考慮すると特に重要性を持ちます。私たちの目標は、継続的な負荷がかかる状態でFIX / 取引所APIを変換するゲートウェーと取引所までのレーテンシーを500マイクロ秒以下にすることでしたが、私たちはこの目標よりも低いレーテンシーを持 続することに成功しました。さらに私たちは、Orc CameronFIX Universal Serverを広範囲に活用しFIXの確かな接続性を実現しました。
FIXの技術的課題と解決策
FIXゲートウェイのアップグレード版を開発している際、FIXを取引所に直接接続するためには、次のような技術的課題が検討対象となりました。

• パ フォーマンスが最重要：リクエスト・レイテンシー（取引所までの電文処理時間）とリクエスト・スループット（１秒あたりのリクエスト数）が主な指標となり ます。世界中の会員の多くが1,000分の1秒以下のレイテンシーと1秒当たり1,000件以上のスループットを要求しています。
• 拡 張性については、日本のほとんどの取引所システムアーキテクチャでは物理的に複数の接続が求められています（仮想サーバ）。各仮想サーバは特定数のスルー プットが上限として取引所で定められています。スループットを高くするには、証券会社が仮想サーバの割り当て枠を多数確保する必要があります。費用の問題 から、大手の証券会社は取引所あたり100個以上の仮想サーバの枠を持っているのに対し、中小の証券会社は通常20～40個の仮想サーバしか確保していま せん。効率的な運用とそうした大量の接続にかかるロードバランシングによって複雑性はかなり高くなっています。
• そ れぞれの取引所APIは、固有のメッセージ・プロトコルとメッセージ・ストラクチャを有しています。様々な商品を開発するには導入案件ごとにFIXマッピ ングを行うことが必要です。目的はグローバルなFIXプロトコルに準拠しつつカスタムFIXタグを最小限に維持することです。
• FIX APIはシンプルな非同期型モデルで、ハイスループットで双方向のメッセージングに適しています。しかし、日本における多くの取引所APIは同期型のデリ バリーモデルを使用しており、スループットを上げるために注文のバッチ処理リクエスト（バッチあたり20注文）が提供されます。これにより、FIXによる ものと取引所API との間のマッピングが複雑になり、導入の複雑性が高くなります。
• 会員は多くの異なったハードウェアやオペレーティングシステム（OS）を使うことがあります。そのため、ベンダーはできる限り多くのシステムをサポートする必要に迫られています。

これらの課題については、これまでの経験から、以下のように対処することを考えています。

• 当 社のシステムは100% 純粋なJava 1.6 を使用しています。「一度書いたプログラムはどの環境でも使える」JVM技術によってプラットフォームの独立性が保たれます。たとえば、共通 OS（Solaris/Unix/Linux/Windows）、CPU（Intel/Sun/AMD）およびアドレッシングモード（32/64 bit）は変更せずにどの製品でもサポートできます。
• Java はサーバサイドの開発プラットフォームであり、従来のC++システムに近い、場合によってはそれを上回るパフォーマンスを提供します。最近のJVMが提供 するランタイム・メモリ管理および再コンパイル／最適化は安定性が向上したパフォーマンスの高いシステムを実現しています。低レイテンシーを実現するため に、メタビットではFIXベースの取引所接続コードの最適化によって、変換、データのシリアライゼーション、パーシスタンス、ロギングといったハイコス ト・オペレーション（執行スピードの面で）をターゲットとしてきました。
• 一 貫したパフォーマンスを実現するためには、レイテンシーのスパイクを低減しなければなりません。一般にスパイクの原因となるのは通常スレッドの相互作用と ガーベジコレクションです。当社のスレッドモデルではスレッドの競合性を確実に最低限に維持します。ガーベジコレクションも、メモリ割り当ての最適化とオ ブジェクトプーリングなどの技術の使用を通して劇的に低減されています。
• 並行コードを慎重に使うことによって、パフォーマンスを損なうことなく数個の仮想サーバから100個の仮想サーバのスケールを保ちつつ、システムをスレッドセーフに維持することができます。
• コアシステムに対して包括注文オブジェクトモデルを使用することによって拡張性が実現できます。FIX（現在バージョン4.0から4.4）および日本の取引所の特性に合った接続可能なアダプターが提供されます。

2008 年以降、日本の取引所では低レイテンシー取引アクセスが重視されるようになりました。FIX プロトコルは海外からのアクセスを刺激して日本の市場への直接取引アクセスを増やそうと努力してきました。その結果、業界にコスト効率のよい取引所プロト コルの提供能力、およびFIXが遅いという悪評を払拭できる低レイテンシーのスループット提供能力があることを証明するに十分な機会を得ることができまし た。
現在では東京工業品取引所（TOCOM）でFIXを 利用するようになりましたが、FIXコミュニティでは、東証などの組織がハイパフォーマンスFIXゲートウェイをその取引所システムに提供しないという自 身の決定の再検討を望んでいます。当社は、FIXプロトコルは世界中の市場からの支持を得て、さらに流動性を高め、安定した価値あるものと信じています。

事例研究
東京工業品取引所でのFIX導入
東 京工業品取引所（TOCOM）は、新取引所システムのネイティブAPIに加え、会員にFIXゲートウェイを提供する日本で初めての取引所となりました。 TOCOMはその取引所システム構築のため、世界最大の取引所システムプロバイダーであるNASDAQ OMXを選びました。その選定のポイントとなったのはTOCOMの国内のサポートパートナーであるNTTDデータとの融合とパフォーマンス、拡張性、安定 性があげられます。
メタビットは2008年に NASDAQ OMXによって取引所システムにFIXゲートウェイを組み込む日本でのパートナーとして指名されました。その使命はパフォーマンスとレイテンシーの増大を 最小限に留めた取引所APIと適合するFIX取引所ゲートウェイを構築しNASDAQ OMXの新取引所システムに国内外のTOCOM会員のFIXオーダーフローを直接つなぐ機会を提供することでした。
メ タビットは現在の東京証券取引所、大阪証券取引所およびJASDAQで使用されている接続性と同じ技術のフレームワークを使用したFIXゲートウェイを構 築しました。アーキテクチャのコアにはOrc 社CameronFIXエンジンを採用しています。完成したTOCOMのFIXゲートウェイは現在、安定した低レイテンシーで高スループットのパフォーマ ンスを提供しています。
FIXをベースとしたマーケット アクセスを支持するTOCOMの決定、および海外のベンダーによる取引所プラットフォームを採用するという決定は、TOCOMの会員に最先端の執行場所を 提供するだけでなく、TOCOMを日本の取引所の中で指導的立場に押し上げることになります。
2009年5月7日、TOCOMの新取引所システムは順調に稼動を開始しました。取引時間はすでに午後11時まで延長されており、次のステージでは24時間の取引サービスに移行することが予定されています。