arrowheadシステム障害により、証券会社約90社のうち、約40社で一部の東証・名証・地取の株式売買が出来なくなった。
メリルリンチ日本証券から東証が大量の通信電文を受信したことにより、接続装置が高負荷になったことが直接的な原因と報告されている。
・午前 7 時 31 分、同社の仮想サーバーと arrowhead のゲートウェイサーバー（東証ＧＷ１）の間で TCP コネクションが正常に確立した直後、同社の別の仮想サーバーが重複した TCP コネクションの確立を試みたことにより、TCP コネクションの管理番号で不整合が発生し、極めて短い間隔で大量の再送要求電文を送信した。
・2 台の仮想サーバーに同一の IP アドレス・ポート番号を設定した状態で、同社が誤って同時に arrowhead に接続を試みたことによるもの。
・arrowhead の接続装置の負荷が高まったことで、システムの安全機構が働き、ゲートウェイサーバー（東証ＧＷ１）の機能を停止させ、今回の事象に至った。
２．arrowheadシステム障害の考察
証券会社と東証arrowheadをつなぐ４系統あるうちの東証ＧＷ１が障害。
東証ＧＷ１に繋がる、証券会社側仮想サーバ１は、当然２重化されており、東証ＧＷ１も２重化されているはずだが、今回は過負荷により両系ダウンした。
午前7時31分接続開始前の時間帯、すでに両系ダウンしている東証ＧＷ１に、他の証券会社仮想サーバが繋ごうとした場合、サービス時間外なのか、障害なのかは、わからない。
この場合の仮想サーバの動きとしては、サービスが開始されるまで、接続をリトライするという動きが一般的だろう。
いったん、接続が確立し、接続が切れたときにはじめて、障害を検知できる。
東証は、午前8時3分と午前8時7分に証券会社向けの通知を出し、当日は接続装置2号機から 4号機に接続されている仮想サーバーを利用するように依頼した。
＜想定される証券会社の対応＞
- 東証GW１障害前に、接続を確立していた証券会社は、障害時に接続断を検知し自動切換え。
- 東証GW１障害後に、接続を試行していた証券会社は、仮想サーバを強制終了し手動切換え。
- 注文受付開始のタイムリミットをチェックしていた証券会社は、自動／手動切換え。
- たまたま、東証GW１と繋がる仮想サーバがない証券会社は、障害なし。
- たまたま、東証GW１と繋がる仮想サーバが、名証、福証、札証の場合もある。
預かり注文、予約注文等をＱＵＥに溜め込んでいる場合、簡単には手動切換えできない事情も考えられる。
また、システムの思想として、東証ＧＷ１が両系終日ダウンする前提がなかったのではないか？
新しいarrowheadでは、２重化された仮想サーバ１が両系障害になったとき、別の仮想サーバ２が障害仮想サーバ１の仕掛り注文を代行、再送取得し引き継ぐ機能（仮想サーバ代行機能という）が廃止された。
東証ＧＷ１は２重化されており、終日両系ダウンはありえないという前提に立った上で取り除かれた機能と考えられる。
しかし、今回、東証ＧＷ１の両系終日障害が発生した。
※仮想サーバ１は２重化され、通常秒間６０件処理できる（秒間５件、６０件、２００件の料金体系）。回線障害時の即時継続（新規発注）の考慮、処理能力増強を考慮する場合は、仮想サーバ２～４を追加する（多くて３００、秒間１８,０００件？）。仮想サーバの種類を増やすことで処理能力、冗長性は高まるが、コストも発生する。
なお、東証ＧＷ１、仮想サーバ１が両系障害となる場合、仮想サーバの発注の結果通知は同じ仮想サーバに返される仕様のため、代行機能がない以上は、東証ＧＷ１の障害が回復するまで、結果通知（新規、訂正、取消、約定）を取得することができない。
今回の障害は、注文受付開始前の障害のため、たまたま、上記問題は発生しなかった。
３．ＤＭＡについて
DMAとは、ダイレクトマーケットアクセス。
個人のネット取引も、広義にはDMAと呼ばれる。
問題になるのは、証券会社のシステムをバイパスした、スポンサードアクセス。
仮想サーバの名義を貸し、直接アクセスさせる場合、証券会社はリスクを管理する機能（事前チェック、事後チェック）を備えていなければならない。
この管理も放棄した場合は、ネイキッドアクセスと呼ばれる。
運転免許のない友達に、クルマとカギを渡し同乗しない行為として、米国、東証では禁止している。
４．高速取引業者について
コロケーションを問わず、仮想サーバの名義を借り、自動売買を行う業者は、高速取引業者であり、金融商品取引業者（金商業者）ではない場合は、登録が求められる。(2018年4月より施行)
例．「関東財務局長（高速）第〇号」
60社該当していると見られたが、障害10月9日現在、登録10社。
日本国内に事務所を置かない海外業者は、関東財務局の管轄。
10月9日現在、登録事業者は、日本、オーストラリア、シンガポール、香港、英国の10社。
事前に新聞・雑誌で報道されていた、米国住所の業者はいない。
高速取引業者は、内閣総理大臣が登録し、金融庁で監督される。
監督指針には、注文発注時の暴走等の記載はあるが、ログイン時の暴走を考慮する旨の記載はない。
高速取引業者が、発注に対して万全の注意を払っていたとしても、ログインにおける指針がなければ、対応が漏れることも、考えられる。
今回の事象を事前に想定できなかったのだろうか？
個人的には想定できないと思う。
高速取引業者に限った障害でもない。
高速取引業者の登録審査は、金商業者よりも緩い。
最短で、海外での実績・体制があれば、２か月で登録できると思われる。
プロである証券会社管理の下、問題を起こさないような仕組みがあることが前提だろう。
金商業者ではない高速取引業者は、日本の投資家に勧誘を行わないため、規制も緩い。
という視点で見ると、高速取引業者に非はないことになる。
（高速取引の想定接続モデル図）
５．規制について
法によって、基本的な自由権を危険にさらさないためにはどうするべきか。
規制されるような事実に対して、システム対策が求められる。
なぜ問題がおきるか？
それは、制度や管理、人的機能が、想定どおりに果たせないからである。
そうであるならば、システムによる対策と自動化が求められる。
６．具体的なシステム対策案
（１）IPアドレス・ポート番号の設定ミスが問題であれば、人間が設定しなくても接続できるようなシステム対策。気の利いたシステムは利用可能な情報を自動で検知できる。
（２）直接の原因となったログインの再試行、多くの証券会社で対応できない不具合が起きている理由は、接続開始前の障害ケースが、システム仕様上明確になっていないからだろう。
こういう部分は、取引所がライブラリ化・ＡＰＩ化することにより、共通の振る舞いを実装できる。
想定外の事象発生時には、ライブラリ１か所を修正し配布すれば、証券会社との接続テストケースも減らすことができ、労力も削減できる。
多くの参加者に、何通りもの実装、創意工夫の余地を与えないことで、安全な接続が共有される。
結果、ライブラリの不具合により、全参加者が障害になる場合もあるが、全参加者公平に売買不可の状態では、相場の混乱・不平不満は避けられる。
（３）現状、仮想サーバが冗長化されても、障害仮想サーバの仕掛りの復旧、障害中成立した約定情報を引き継ぐ手続きが、arrowheadにはない。
終日障害が起きうる事実を前提とした、仮想サーバ代行機能の実装がarrowheadには必要だろう。
（４）証券会社との間で障害テストを行う対策は、システム仕様、運用手順の不備を究明できるという点で、前進するだろう。
※HFT、DEA、DMA、sponsored access、naked access等の分類。
日本国内、オーストラリア、カナダ、香港、サウジアラビア、シンガポール、英国、欧州連合（EU）、および米国の法律・地方(Local)の法律、規制、海を越えた取引の国際相互間のルール等、東証障害、リスクに係るリンク。
2014年7月
米国市場の複雑性とHFTを巡る議論(JPX)
2016年6月
諸外国における市場構造と HFT を巡る規制動向(FSA)
2017年6月
高速取引行為（ＨＦＴ）規制(DIR)
2017年10月
平成29年金融商品取引法改正に係る政令・内閣府令案等の公表について(FSA)
2018年4月
高速取引行為を行うみなさまへ(FSA)
2018年10月
東証のシステム障害、大手証券とネット・外資系で明暗が分かれた訳(Diamond)
10月9日に株式売買システムで発生した障害について(JPX)
2018年10月に発生した東京証券取引所のシステム障害についてまとめてみた(Kango)
リスク
2017年7月
東証市場における売買に関するコンティンジェンシー・プラン(JPX)
0 件のコメント:
コメントを投稿