https://tech.nikkeibp.co.jp/atcl/nxt/news/18/02939/
https://tech.nikkeibp.co.jp/atcl/nxt/news/18/02939/181009-JPX-paper.jpg
電文を処理する各系統は、負荷分散装置を2台、GWサーバーを4台で冗長化していた。
負荷分散装置はGWサーバーに送る受発注の電文を動的に振り分け、特定のサーバーへの負荷集中を防ぐ。
さらに証券会社側のエラーなどで異常な受発注の電文が発生しても、その内容を基に電文を廃棄するなど、
エラーを回避できる仕組みを取り入れていた。

しかし「今回のようなインフラ運用レベルのシステム電文が大量発生する想定はできていなかった」（横山CIO）ため、
2台の負荷分散装置がともに止まるという障害に至ったという。
取引時間中にこの1系統の復旧を図ると新たな障害を呼ぶリスクもあるため、9日は復旧を断念。
問題となる電文を送信した証券会社に連絡を取り、ネットワーク設定を見直し再発防止を確認したうえで、
10日朝からシステムを正常稼働させると決めた。

GWサーバーへの接続は4系統あり、規約で「（証券会社など）取引参加者は必ず複数の系統に接続する」（横山CIO）と決まっている。
つまり1系統の障害が発生しても、生きている別系統に注文電文を流すことで売買を継続できたはずだ。
実際に、9日は通常通りに取引を継続できた証券会社も多くあった。

一方で、注文処理が滞った証券会社もあった。
横山CIOは、そうした証券会社の発注システムが、「複数系統のうち1系統で障害が起こった場合に、うまく対応できなかった可能性がある」と指摘した。
障害が発生した系統を検知して障害がない別系統に注文処理を流すなど、障害発生を想定したシステム開発ができていなかったとの見方である。

そのうえで、横山CIOは「複数系統を用意していたとはいえ、
証券会社とのコミュニケーションが不十分だった」との問題を認めた。 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)