全3313文字
PR

 2020年10月1日に東京証券取引所(以下、東証)のシステム障害が発生した。前編では、システム障害の発生理由を探るべく、クラスタリングに関する基本知識とActive-Standby(アクティブ/スタンバイ)構成の問題点について説明した。後編では、今後どのような構成に変えればよいのか、運用に問題はなかったのかについて考察してみたい。

検証と切り替えテストが十分だったのかという疑問

 東証のシステム障害に対し、「切り替えテストを十分に行っていなかったのではないか」という疑問の声が上がっているようだが、それは違うだろう。実際、東証は切り替えテストを実施したと発表している。このような基幹システムで十分な切り替えテストを行っていないわけがない。筆者が担当者なら、十分なテストを行わなければとても安心して寝ることはできない。

2020年10月2日付日本経済新聞の証券面
2020年10月2日付日本経済新聞の証券面
前日に発生したシステム障害で東証が株式全銘柄の売買を終日停止したため、株価の数字が紙面から消えた。(写真:日経クロステック)
[画像のクリックで拡大表示]

 十分なテストを実施したとしても、ハードウエアの故障に関しては予想外のことが発生する。そのため、前編でも述べた通り、筆者はActive-Standby構成のHA(High Availability)クラスターには否定的なのである。

 HAクラスターでは、ハードウエアの故障についてシミュレーションテストを行う。例えば、OS上でハードウエアを故障した場合と近い状況に設定した上でテストする。しかし、実際にハードウエアを壊してテストすることはないだろうし、メモリーの故障といってもさまざまな故障の仕方がある。筆者もハードウエアを取り外してテストを行ったことはあるが、物理的な故障を起こしてテストを実施したことはない。発生し得る全ての異常事態を確認する完璧なテストを実施することは難しい。

 これは技術的な問題ではない。HAクラスターはどうしてもそのリスクが残ってしまうのである。

クラスタリングの構成
クラスタリングの構成
(出所:メディアスケッチ)
[画像のクリックで拡大表示]

障害の発生を防ぐには

 今回のシステム障害に関しては、「なぜ、異常を検知してうまく切り替えられなかったのか」という点に絞って調査されるだろう。その上で、できる限りハードウエアの状況監視を強化し、完全な故障ではなくても、それを異常と検知するように改善しなければならない。今回問題になっているシステムを開発したのは富士通だ。同社はハードウエアを開発しているので、ハードウエアの異常検知に関しては検証と開発が可能なはずだ。

 そして、それとは別に、ハードウエアの異常を完全には検知できないことを想定し、処理時間の遅延やデバイスのI/Oエラーなどをソフトウエアによって監視しなければならないだろう。

 ただし、監視を強化した場合、誤検知の可能性が高まる懸念がある。Active-Standby構成では、切り替えの際に一時的に処理停止が伴う。そのため、運用としては、可能な限り切り替えを行いたくないという心理が働く。加えて、それまで長期間動いていなかったスタンバイ側にいきなり全ての処理を切り替えて、本当に正常に処理できるのかという不安が付きまとう。

 筆者の経験も踏まえて言わせてもらえば、Active-Standby構成はリスクが高いため、中・長期的にはActive- Active(アクティブ/アクティブ)構成を検討すべきだと思う。例えば、Active- Active構成によって4台のディスクに分散して処理を行った場合、1台が壊れたとしても、故障箇所だけ切り離して残りの3台で引き続き運用できる。従って、わずかな異常でも切り離し処理を行いやすい。加えて、Active-Standby構成の場合は2台でしか運用できないが、Active- Active構成の場合は3台以上での負荷分散も可能なため、ハードウエアの負荷も抑えることができる。ただし、故障が発生した縮退運転状態でも十分な処理能力を有する構成にしなければならない。

 システム障害を起こした高速取引システム「アローヘッド(arrowhead)」では、ほとんどのサーバーが負荷分散による構成になっている。にもかかわらず、今回問題となったディスク部分だけActive-Standby構成にしたことには理由があるはずだ。その理由を踏まえた上で、本当にActive- Active構成が不可能なのかについて改めて検証する必要があるだろう。

 確かに、Active- Active構成の実現は容易ではない。Active-Active構成を実現するには、それに対応したアプリケーションを開発しなければならない。加えて、ディスク間でリアルタイムに情報を共有しなければならないので、信頼できる高速通信による確実なデータ共有が必要になる。

 東証のようなシステムの場合、大量の処理を行う一方で、一部の処理だけ完了しないという運用は許されない。そのため、処理をできる限り分散させたくないという考えがあるのかもしれない。

 システムの要件や状況を詳しく把握しない限り、どのような構成がベストかは言えないのだが、稼働率を少しでも上げるためのクラスタシステムに関する技術は日々進化している。従って、今回のシステム障害を機に、できる限り何かに頼らないようなシステムに変えて稼働率をさらに上げていく必要があるだろう。