らびっとブログ

趣味で映画、本、政治思想とか時々書きます(^^)/ ご意見はツイッター @rabit_gti まで

東証システム障害とITシステム

2020/10/1 東証の売買システムが終日停止した。当日は四半期初日で、中国や韓国の証券取引所も休みのために時差共存の世界市場のうちアジア地域で値が付かない深刻な影響になったようだ。

 

現時点、原因は共有ディスク装置1号機のメモリ故障(恐らくキャッシュ用またはコントローラ稼働用のメモリ)で、共有ディスク装置2号機への自動切替(フェイルオーバー)が何故かできなかったという。各取引サーバーは多重化されているが、各サーバーからデータ共有するディスク装置がネックとなった模様。

 

部外者の推測だが、切替機能の不具合(該当ファームウェアまたはソフトウェアの既知/潜在バグ)、故障の詳細状況(仮に中途半端な壊れ方の場合の切替機能による検知可能性)、人為ミス(切替テスト後の誤設定/誤操作)などが考えられると思う。

 

以下は夕方の東証記者会見を伝える日経XTECHとITMediaの記事で内容はほぼ同じ。

xtech.nikkei.com

 

www.itmedia.co.jp

 

どの業界でも基幹システムは障害対策で冗長化するが、最終的なデータ保管場所(通常はデータベース、オンメモリでも障害対策ログはディスク保存が基本)は整合性と処理効率のため無暗には分けられない(整合性のレベル次第では色々なクラスタリングやディスク複製技術も組み合わせできる。)

 

東証のシステムは、2005~2006年頃に障害多発し、2010年に信頼性と高速性を目的にした新システム「アローヘッド」が稼働し、2019年にはその更改もされた。

 

以下はアローヘッド構築を振り返った座談会。「"決して落としてはならないシステム”ができるまで 」とのタイトルが今は皮肉だが、しかし技術者から見れば「絶対落ちないシステム」などこの世に存在しないのも事実だ。

www.itmedia.co.jp

 

以下は2019年更改時の富士通プレスリリース。

pr.fujitsu.com

 

以下は当日夕方の富士通の声明で「当社の納入したハードウエアに障害が生じて多くの関係者の皆様に多大なるご迷惑をおかけしたことを、おわびいたします」と報道されたが、富士通Webサイトの当日のプレスリリースには掲示されていない。

www.nikkei.com

 

現時点で上記以上の詳細原因は未発表だが、部外者ながら関連していくつかコメントしたい。

  1. 大規模システム障害が発生するとすぐ「ベンダーはどこだ」「損害賠償すべき」と報道される。東証の基幹システムは富士通だが、周辺システムを含めればマルチベンダーで、各システムは通常は法的にはそのユーザーのシステムだ。要件も予算もユーザーで、ベンダーの瑕疵担保責任や故障等の役割分担は契約による。もちろんベンダーの各製品品質や技術力が影響する事もあるが、原因判明前に構築運用ベンダーを吊るし上げるのはおかしいし、背景には日本特有の「契約無視して業者に責任丸投げ」の日の丸親方的発想があると思う。今回東証の「市場運営の責任の所在は私どもにあり、(富士通への)損害賠償は現時点で考えていない」との発言は、主体性・責任感ある発言と思う。(勿論内部ではベンダーも率先して協力すべきだが。)
  2. また今回東証は、日中に復旧しても取引再開しないとの判断で、終日取引停止となった。過去の証券会社や銀行の大規模障害でも、障害直後の突然の取引再開でリトライ目的の重複入力や取引先ごとの不公平など不測の問題が発生して傷を広げたケースが多かった。特に株式売買では順序性が超重要だ。これも勇気のいる安全重視の決断だったと思う。
  3. システム障害があると「冗長性不足」との単純批判も見られる。しかし大組織の基幹業務で冗長化されていないシステムなど無く、普通の故障なら継続稼働(停止しても短時間)できる。それでも発生するのは、障害対策システム(クラスタリングなど)自体のレアな潜在不具合、中途半端な故障(間欠障害など半分壊れた状態で動き続ける)、ネットワーク定義変更、そして人間系(オペミス)など複雑な要因がありうる。
  4. 中には「クラウドの時代に」との批判もあるが、クラウドは重要だが適材適所で、応答性能命でAI高速取引(光ファイバーの光速を競い証券会社システムの1mでも近くに場所を借りて設置する)を競う東証基幹システムでクラウドは全くありえない
  5. 今回、東証マザーズジャスダック、更に同じシステム使用の札幌/名古屋/福岡も「全滅」に陥った。昔の大証東証に統合済だ。繰り返すが「絶対に落ちないシステム」は技術的にはこの世に存在しない。合理化・効率化には集約化だが、リスク分散でシステム分離(少なくとも疎結合)も組み合わせるべきではないか。(なお伝統的な大手銀行の勘定系システムは、2系統バックアップ構成で、本番機とバックアップ機のセットが2系統あり、各支店やATMへの回線も2系統あるので、クラスタ引継ぎ不可発生時でも半分の支店はまず落ちない。もちろん前提は2系統間のデータベース共有なので、物理筐体は冗長化する。更に全滅時でも最低限の応答を返すフロントエンドプロセッサも併用していたりする。高可用性・高コストが本当に必要か、過剰品質かは要件定義の問題だ。)

 

最近はデジタル庁も話題だが、技術の新旧より地道な障害対策(障害があっても最低限回る仕組み)を常に検討・構成・運用していることが重要と思う。

 

(2020/10/4 追記)以下の続編を書きました。

rabit-gti.hatenablog.com

 

(了)