昨日、2020年10月1日に発生した東証のシステム障害について、いろいろな情報に目を通しているが、おそらく数年は語られるであろうこの件についていろいろ考えていた。影響が大きすぎるので軽はずみなことも書けず、まとまらなかったので昨日時点での記事の作成は避けたが、そろそろ落ち着いてきたので書きたい。
はじめに入ってきた情報は「機器障害」「ハードウェア障害」という文言だった。しかし、ハードウェアの問題であったら冗長化構成にて待機系に切り替わるのが本筋であると思う。それでも機器障害が理由として通る場合は、多重障害である。待機系も同時に壊れた。これならば理屈は通るし、一般的には過去はそういった事例も存在した。
しかし、実際はそうではなかった。運用系システムの中にストレージサーバーがいて、もちろん冗長化していたけれども、うまく待機系に切り替わらなかったとのこと。ストレージサーバーの冗長化の仕組みと、メモリーの仕組みについて、おそらくもっとも理解しやすい資料は下記であろうと思う。
上記の図のように、独立した２つのコントローラーは、搭載ディスク全てに対しアクセス可能で、かつ読み込み・書き込みのために使うメモリー（ここではNVRAM）は互いにレプリケーションしている。
何かコントローラでハードウェア障害等が発生し正常に機能しないと判断される場合は、自動的に片側に処理が引き継がれることで、ほぼ無影響の縮退運用を実現するというロジックになっている。
もちろん、同じ機械ではないだろうし、ロジックも異なる可能性はあるが、ストレージサーバーの冗長構成を理解する上ではとてもわかりやすい。
また、ストレージサーバーなのになぜメモリーが必要？という問いに対しては、これはもうストレージサーバーの基本中の基本である。
直接ディスクに書き込むと処理が遅くなるため、処理が速いメモリーに一度入れておいて、非同期でディスクと同期する。メモリーの利用を前提としているため、これが故障することはすなわちストレージサーバー全体の機能が消失するのと同じ意味を持つ。だからこそ、待機系に絶えず複製されているのであり、縮退されるべきであった。
しかし、されなかった。
記者会見時に、メモリーのハードウェア故障に対して興味が集中したのだが、「ハードウェアは壊れて当たり前」という答えに落ち着くのはごくごく当然だと思う。しかし陽動作戦というか、本来の問題はここではないと思う。なぜ、待機系に引き継がれなかったのか。問題の本質の一つはここにある。
昨晩のうちに、おそらく問題が起こったストレージサーバーのコントローラーはメモリーごと予防交換された気がしている。ログ上からはメモリーの障害であることが濃厚だが、おそらく、ベンダーである富士通はコントローラーごと持って帰り今調査しているのではないか。調査は週末の土日も含めて行い、24時間体制で調査を進めるだろう。一方の東証の現場は、原因が判明するまでは再発するかもしれないという仮定のもと、人力で監視強化すると言っているのだから、富士通ももちろん全力で調査に取り組むことだろう。
再発防止に向けて東証は今後、原因が判明するまで当面の間、共有ディスク装置の動作状況や切り替えについて人的監視を強化することで対応するとしている。
今回の被疑箇所以外にも、ストレージサーバーはもちろん使っているはずで、同時に他の箇所の点検もベンダーは進めなければいけない。こういったToDoを整理し実行し、報告にまとめることは東証の責任ではあるが、ベンダーも一体となって進めていくものである。
さて、システム、ということを考えた場合にはもう一つ考慮するべき点がある。ストレージサーバーの停止というインフラ起因の問題に対し、一日の間システム停止をしなければいけなかったシステムの脆弱性である。
もし再開すると、ユーザー側がアブノーマルな対応を行わなければならなくなり、取引所としての機能を果たせないというビジネス的な判断があった。
今日中に再起動した場合、投資家や市場参加者に混乱が生じて円滑な売買が困難になることが予想されることから、市場参加者と協議して終日売買停止の判断をしたとしている。
この「再起動」というのは、もちろんストレージサーバーの話ではない。各種システムのOSがこの問題が発生したストレージサーバーのボリュームをマウントしていて、当然のことながら読み込み・書き込みができない状態となった。したがってシステム上のアプリケーション動作がそこで止まってしまうことになる。この中途半端なシステム上の状態のままOSを含めシステム全体を再起動させた場合、そのつじつま合わせで大混乱が起こる、という判断だったと思われる。
OSがネットワーク越しにストレージをマウントする方法にはいくつかあって、WindowsならCIFS、Linux系ならNFS、あるいはiSCSIなど複数のプロトコルがある。どんなプロトコルであってもストレージに問題があると、OSのロードアベレージと呼ばれる負荷が急上昇する。これは入出力待ちのプロセスがスタック（積み上がる）ためである。こうなると、実際ストレージサーバー側を再起動したとしても復旧しないことが多い。ストレージサーバー復旧後にOSを再起動するのが賢明である。
しかし、OSが再起動するということは、アプリケーションは異常停止させられ、そこからリカバリーを行わなければいけない。リカバリーをアプリケーション開発者指導のもと行ったからと言って、その前段階に正しく戻れるかはわからない。
このように、ストレージ障害は、ときにシステム全体の運用に非常に深刻な影響を及ぼす。
さて、東証として考えるべきは、このようなストレージの問題が発生したときですら、リカバリーを素早く整えることを今後できないのか、という視点であろうと思う。
ハードウェアが冗長化されているから大丈夫、ではミッションクリティカルシステムにおいては不十分。ストレージサーバーがアクセス不能になったとして、再起動後も速やかに正常運用に復帰し、できるだけ損失を抑える。いわゆるフェイルセーフの考え方で言えば、さらなる答えが要求されるに違いないと考える。
暫定対応は人的監視の強化でパワープレイするとして、恒久的にはどうするのか。同種の障害が起きた場合に、一日取引停止とはならない方策があるのか。これはインフラ基盤側が冗長化構成の改善に取り組む一方で、アプリケーション開発側にも努力が求められることとなると思われる。
東証の記者会見にて、真摯にマスコミ記者へ返答する関係者の姿勢に好感が広がっている一方で、これから取り組まなければいけない課題は山積していて、現場はまだ全く落ち着いていないと思われる。日本社会を支える超重要ミッションクリティカルシステムでの今回の件は、一次対応だけではなく、本件がクローズされるまで、今後の障害対応の教科書となるべき一件になろうと思われる。
