スポンサーリンク
東京証券取引所（東証）のシステムが2020年10月1日に丸1日ダウンした。
1か月弱経ったが、分かった問題点について思うところを書く。
IT業界に関するニュースのまとめはこちら。
10月1日に東証で株の取引を扱う基幹システムであるarrowheadがダウンし、取引すべてが停止した。
午前中にほぼ復旧のめどがたったが、東証はその日の取引を停止する決断をした。
その影響は諸外国にはなにもなく、日本限定の問題はスルーされるという、国の存在価値の低下が露呈された。
これがUSであれば、世界中の株式市場が混乱したのだろう。
当日からの報道や昨今の立ち入り検査の報道から、その原因はハードの故障によるもので、
しかし故障検出時に冗長構成をするシステムが待機系に切り替わらなかったためだった。
東証のシステム構成を把握していないので、正確ではないかもしれない。一般的な冗長構成について書く。
冗長構成とは、名前の通り、普段であれば冗長＝余分な機材を持つシステムの構成方式だ。
いくつか種類があるが最も簡単で良くあるのが、ACT系とSBY系という、2系統を持つシステムだ。
ACT系とはアクティブ、つまり稼働している系統で、SBY系とはスタンバイ、つまり待機している系統だ。
2つの系統を切り替えるスイッチがあり、ひとたび稼働系に問題があると発見されると、自動で待機系に
切り替わる。そういうスイッチを含めた構成が冗長構成だ。
ここで問題となるのは、東証でも原因らしいが、スイッチがきちんと切り替えてくれず、せっかくの待機系が
待機したままになってしまうことだ。
仮に正常な状態で動いているとしても、切り替える判断処理にはタイムラグがつきものなので、
若干のロスがある。
東証ほどのシステムならおそらく理論的には切り替えは1秒もかからないはずだが、その間に処理すべき
トランザクションは数十ではきかないだろう。切り替えにかかる時間が長いほど、システムが提供する
サービス全体に対するダメージが大きくなる。
このやり方では問題があるとなった場合は、冗長構成を2系統ではなく3系統、4系統にしたり、
待機系を無くしてどちらも稼働系にして負荷分散したりと、いろいろなバリエーションが
考えられてきているが、どれも完全な障害によるサービス停止の回避策にはなっていない。
稼動率とはそのシステムが提供する機能が動いている確率だ。常に動くシステムは100％といえる。
一方で故障率という定義もあり、これはシステムが機能を提供できない確率で100％から
稼働率を引いた数値になる。
例えば故障率が3％のシステムがあれば、稼働率は97%である。
故障率というものは構成する機器や部品の故障率から計算される。先の冗長構成を理論的に考えると、
片方の系統が壊れてももう1つが生きていればシステムとしては死んでいないので、
冗長構成のシステムが故障する確率は、1系統の故障時に、同時に他系統も故障する場合に限られる。
例えば先の故障率3%のシステムを2系統の冗長構成にすれば、同時に故障する確率は3%x3%=0.09％になる。
1系統だけで運用しているときと比べるとぐんと故障する確度は低くなり、稼働率は実に
97％から99.91％に上がる。
97%のままであれば年間11日が故障で停止している計算になるが、99.91%になると故障で停止する
時間は年間で7.9時間にまでさげることができる。
さらに様々な構成をいれて、クラウドサービスでは稼働率を99.99％ぐらいにすることが多い。
興味があれば、信頼性工学でや稼働率計算で検索すると有用な情報を得られるだろう。
確率の理論計算は以上のようになるが、現実はそうならない。
こういう手の話しは良くあるものだが、問題は、絶対に止まってはいけないシステムが止まって
しまうことによる社会影響だ。例えばNASAが作ったロケット、例えば国防システム、
そういうものはプログラムのバグによりシステムが停止するとロケットに乗るパイロットの人命や
国の防衛ができなくなる。
そんなシステムは多額のお金と時間をかけて、何度も試験をして納品されるものだ。
それなのに、納期と予算に縛られて十分なテストができない場合がある。
もちろん、それは契約違反なのだが、故意ではない場合が多い。人間だから間違えることがある。
ソフトウェア設計者の中ではよく知られていることだが、「銀の弾丸はない」だ。
古典的な話だが、狼男を仕留める銀の弾丸はソフトウェアに対しては存在しない。
どんなに準備をして時間をかけて検証しても、完ぺきではない。それはソフトウェアの巨大さ、
複雑さにより確認すべき事項が増えて人間の頭では追いきれなくなった、という事だろう。
今回の問題は日本の技術力の低下、危機管理能力のなさを露呈したといえる。
いろいろ対策すべきことがあるだろう。それは政治の立場だけでなく、IT技術者もとめられない
システムのための設計、構築プロセスの見直しという観点で自戒しないといけないと思う。
PR
