東京証券取引所様の株式売買システム「arrowhead」で発生した障害の原因と対策について

東京証券取引所様の株式売買システム「arrowhead」で発生した障害の原因と対策について

2020年10月19日
富士通株式会社

東京証券取引所様に共有ディスク装置として納入した当社ストレージ製品「ETERNUS(エターナス) NR1000」において、メモリ故障に起因してデータを正しく読みだせない状態が継続する事象(以下、特定事象)が発生いたしました。

当該共有ディスク装置は一つの筐体内で二重化(1、2号機の2つで構成)されており、1号機においてメモリ故障に起因する特定事象が発生した場合、当該装置の有する障害時の切替機能として、2号機に自動切替が行われるはずでしたが、実際には自動切替が行われませんでした。

当該共有ディスク装置のマニュアルには、メモリ故障等に起因する特定事象が発生した場合は、必ず自動切替が行われる旨の記載がありました。

実際の製品では、設定によっては、メモリ故障等に起因する特定事象が発生した場合、自動切替が行われない仕様となっておりました。今回は特定事象発生時に自動切替が行われない設定になっておりました。

マニュアルの記載と実際の仕様の齟齬が生じた原因は、当該共有ディスク装置のオペレーティングシステムのバージョンアップにより製品仕様が変更された際に、マニュアルの記載が変更されていなかったことによるものです。

東京証券取引所様にて稼働中のOEM製品について、製品仕様とマニュアル記載内容の再レビューを実施します。また、製品仕様とマニュアル記述の一致、および仕様追加、仕様変更等の通知徹底等OEMベンダーと連携強化するとともに、当社として、OEM製品の評価プロセスを改善し、確実な再発防止に努めます。


Fujitsu Storage ETERNUS series NR1000 ネットワークディスクアレイ

NR1000 seriesは NASストレージ業界のリーディングカンパニーであるNetApp社のOEM製品です。
VMware仮想化環境における効率的な運用管理を実現するVSC(Console Storage Virtual)


自動バックアップ、5年間オフのまま 東証システム障害、富士通のマニュアルに不備


システム構築時に富士通側と検討した際、マニュアルには自動切り替えが動作すると記載されていたことから、実際の稼働テストを行わなかったという。

 テストを行わなかったのは、これまでのアローヘッドの稼働実績を鑑みた結果だとしている。東証の担当者によると、製品マニュアルから自動切り替えの発動パターンをメモリやCPUの故障、ネットワークの切断と想定していたという。
ネットワーク切断については切り替えテストを行ったが、メモリなどの故障については「NASの設定値とマニュアルの整合性については富士通内の製品出荷プロセスで検証されている前提だった」とし、テストを行っていなかった。

マニュアルに不備があったのは、機器を製造した米国企業の仕様変更が原因だという。2010年1月に稼働を始めた初代アローヘッドでは自動切り替えが「オフ」でも、トラブルを検知すると15秒後に予備に切り替わる仕組みだったが、2015年9月に導入した2代目からは「オフ」時にはバックアップが作動しない方式に変更されていた。

 これを富士通が把握せず、初期設定を「オフ」にして東証に納入。マニュアルにも反映されていなかったため、東証も気付かないままシステムを運用していたという。システム障害を受け、10月5日から設定を変更した。

東証は併せて、「システム障害による売買停止後の再開に向けたルールが整備されていなかったことも問題」として、証券会社など市場関係者で構成する「再発防止策検討協議会」を設置することも明らかにした。

感想

・F社出身者として、20数年前に課長が教えてくれた東証サーバ障害対応のお話は未だに鮮明に覚えています。
起動不能なサーバについて調査して、マザーボードやメモリなど全部交換して治らなかったが、最後CPUの問題であった事が分かったそうです。

・自分が直接な担当ではなかったが前々職のY社ではストレージ障害で、利用者メールデータ消失の大障害がありました。
障害の原因は、ベンダーとの連携が不十分で、脆弱性のあるストレージのOSバージョンアップの怠慢がありました。
再発防止の一貫として最終的にストレージベンダーをNetAppに変更し、ベンダー連携を強化しました。

しかし今回はNetApp製品の不具合でした。なお、きちんとバージョンアップもしていました。
残念ながら、変更後の大事な設定を漏れました。。

・arrowheadの件は、テスト漏れ及変更管理が不十分である事は原因になります。
現在のドキュメントのレビュー、OEMベンダーとの連携強化、リリース手順の見直し、設定チェックリストの見直しもそうですが、
今後の変更に伴う管理プロセスの精査がもっと重要かと思います。
依存関係が複雑で、どこまでチェックするか難しいと思いますが、手順が煩雑になり、firewareやsoftwareなどのアップデートの回数が減るでしょうね。。

ANAシステム障害 顧客DB同期処理失敗? その2にもあるように、
「自動的に切り替わる設計」のシステムは、障害時に切り替わらない事が本当にいっぱいあります。
なので、あらゆる障害をシミュレーションして、定期的に訓練しないといけません。
バックアップシステムの訓練が行われない限り、再発防止が完全ではないと思いますね。