2021/8/20に発生したみずほ銀行のシステム障害について、記者会見をNHKのサイトにて閲覧しました。
勘定系システム「MINORI」のハードウェア部分で発生したシステム障害により、8月20日朝からみずほ銀行とみずほ信託銀行の店頭窓口で入出金や振り込みが一時できなくなっていた問題で、みずほフィナンシャルグループ（FG）は同日、緊急の会見を開き、MINORIと店舗の事務処理端末をつなぐシステムが故障していたと明らかにした。バックアップも機能しなかったといい、故障原因やバックアップが作動しなかった原因について「調査中」としている。
何かあったら日本国中に注目されてしまうシステムを運用するというのは、それはもう大変なことです。グループCEOや銀行頭取も責められていましたが、トップは「再発防止策を考えます」で逃げられるかもしれないが、銀行窓口や営業店（フロント）には大いに負荷をかけてしまう。しかももう今年に入って5回目ですから、フロントが作り上げてきた信用を都度都度壊してしまう。障害を起こさなくする、というのは一言で言えますが、なぜそれをやらなければいけないかと言うと、全くの信用問題だからだと言えます。
度重なる障害の結果作り上げられた再発防止策。それを実施していた最中に再発してしまう。しかも今回の障害は、ハード障害とのことで、場所は違いますが3月12日に発生した「DBサーバーディスク装置」ということで、そこから5か月経っているのになぜ、これだけ広範な業務影響が出てしまうのかということが、会見中でも記者から何度も質問されていました。
なお、3月12日の障害においては、日立の名前が出されたのですが、今回は非公開とのこと。
日立製作所は５日、みずほ銀行で３月１２日に発生した外貨建て送金遅延について陳謝した。みずほフィナンシャルグループは同日、障害は日立が保有・管理するサーバーとディスク装置が故障ししたために発生し、日立側で万一に備えた早期復旧手順と体制が確立されていなかったなどと指摘した。
前回は、「ベンダー側で手順や体制が確立できていなかった」という結論となりましたが、今回は会見を聴く限りは様相が違いました。
「複雑な壊れ方をした」ということばが何度か出てきました。DBサーバーディスク装置と言う表現は、あたかも物理サーバーのローカルディスクの用にも聞こえますが違うようで、いわゆるストレージサーバーなのだと思います。
このストレージサーバー、どの機種も似た構成ですが、「CPUやメモリー、ファームウェア、ディスクコントローラー」などを乗せたシステムボードを、アクティブ－スタンバイ、もしくはアクティブ－アクティブで、二系統持っています。
そして、ディスクの集合体に対して、二系統がつながりアクセスできるようになっています。
今回は、バックアップ、という言葉も出てきましたので、アクティブ－スタンバイで動作していたのでしょう。アクティブ側が故障を発生したのでスタンバイ側に切り替わろうとしたけれども、切り替わらなかった、いや、切り替わったのだけれど中途半端に切り替わり「複雑な壊れ方をした」、と会見で伺いました。
さて、この話自体は、ベンダー自身が説明したわけでもなく、まだ原因未定のフェーズだったので、話としてはもっと解像度を上げて説明がされると考えます。
3月12日に同様の障害が起きた、ということが気になって、二か月前にみずほより提出された再発防止策をのぞいてみました。
2021 年 3 月 11 日 23 時 39 分、①MINORI の共通基盤に存在するストレージ装置内の通信制御装置が故障したことで、ストレージ装置とサーバの間の通信が遮断され、同サーバ上で稼働する業務システムが停止しました。そのうち、②「統合ファイル授受」（センター集中記帳処理に必要なファイル等の受け渡しを基盤間で行う業務システム）の停止により、センター集中記帳処理が遅延し、これにより、③主に外国為替送金処理が遅延する等の影響が生じました。
エラーを検知後、直ちにストレージ装置の復旧対応を行いましたが、通信制御装置の交換後も接続が回復せず、全サーバ復旧までは 6 時間 41 分、統合ファイル授受の復旧までは 6 時間 59 分を要しました。
「統合ファイル授受」復旧後、センター集中記帳処理が順次再開されましたが、外為システムにおいて適切な復旧（リカバリ）手順が取られず、規定の時限までに処理が完了しませんでした。
• ベンダーによる復旧に約7時間
• みずほ側の復旧作業においても手順ミス
前回と様子が違うのが、みずほ行内での対応に不備はなく、「ハードウェア障害」というキーワードが強調された会見ということでした。
ただ、前回はベンダー名として日立が出て来たのに、今回は非公開というのは、この前の東証システムトラブルの際に非公開を貫いた事例があったからなのかはわかりませんが、ちょっとちぐはぐな気もしました。
さて、3月、8月と、似たようなハードウェア障害が発生したのですが、一つ分かったことがあるのではないでしょうか。
「ストレージサーバーは、システムトラブルが起こると復旧には10時間前後かかる」、と。
ベンダーと、ハードウェア障害が起こっても短時間で回復できる仕組みを今から考えると言う趣旨の発言もありましたが、結局は前回も、今回も時間はかかったわけです。
だから、ストレージサーバーは壊れるし冗長化してもすぐには復旧しないことがある、と言うことを前提にシステム増強を進めるべきです。
いろんな機能によってこの基幹システムMINORIは成り立っていますが、それぞれの機能において、ハードウェア構成が独立した正副のシステムを動作させ、システムごと副系に切り倒すことは有効でしょう。
もしくは、システム性能を2倍以上にしたA系、B系を稼働し、それぞれアクティブ-アクティブで使うという方法も取れます。仮にA系が停止した場合はB系で2倍稼働させる。
以上は、AとBで2系統の話ですが、場合によりA、B、C・・・などと3系統以上にすることも実装可能です。
二日前ほどに、集中管理は危険というお話をしたばかりですが。
１つのハードウェアが停止したら、重要業務が止まり、会社の信用問題に関わるというのは正直言って脆弱な設計のように見えます。
そして、複数の機能が今回のように１つのハードウェアが停止したら止まるのであれば、リスクは掛け算になります。どの機能が欠けても、大騒ぎになるのですから。
CEOや頭取が記者会見をして、ハードウェアの構成からシステム障害のロジックまで語らなければいけないのは、これはメガバンクほどの巨大組織としてはレベルが低いと思います。
１つや２つのハードウェアが想定外に停止しても、業務が継続されるべき、です。
もし、今回ハードウェア障害の原因を突き止めたとしても、全く同じ理由で障害が起こることはほぼありません（修正されるため）。しかし、また違う理由で何かが起こるのです。3月にも8月にも起こったのですから。
機器の冗長化レベルの話に済ませるのではなく、システム全体の冗長化が必要、ということですね。ハードウェアのレイヤーを仮想化し、ソフトウェアたる業務は動作が継続できるような作りにしなければいけません。
それぐらい、日本に取って重要システムですから。
ひとまずは今日の感想です。もっと詳しい情報が出てきたらまた考察します。
