動かないコンピューターとみずほ銀行のトラブル

日経コンピューターには動かないコンピューターというコンピューターシステムで発生した大きなトラブルの真因を探る恒例の記事がありますが、今回は先日のみずほ銀行のトラブルが取り上げられていました。

記事の内容そのものはほぼ公開されている情報が利用されているようで、まだ深掘りというわけではなかったです。「障害の発端は定期預金関連のデータ更新処理に起因するメモリー容量不足にある」とされているところのメカニズムについては、まだよく判りませんでした。「取り消し情報管理テーブル」でメモリー容量が不足したと書かれています。

動的に拡張するメモリテーブル？

処理件数は数十万件のオーダーなので、さほど性能的にシビアな条件ではないと思えたのですが、「取り消し情報管理テーブル」というのは動的に拡張をしていくメモリテーブルだったということでしょうか。普通に考えれば、データベースのテーブルと実装しても良かったのではないかと思えたのですが、ここが一点判りませんでした。

リソース不足時の局所化の優先順位

また、メモリ容量が不足したときの障害対策の優先順位がどのようになっていたのかも気になります。ATMなど利用者接点の優先順位は非常に高く、最後まで稼働が続けられるように設計し、逆に行内の都合で実施しているような処理は一刻も早く止めてメモリを開放する設計になっていたのではないかと思います。

なぜ、自行のATMの7割が動作不能になるほどの状況になってしまったのか、そのメカニズムもよく判りませんでした。

今後は検証委員会による検証結果の発表などもあると思いますので、待ちたいと思います。

【2021年4月6日追記】

日立製作所に損害賠償を請求する可能性に言及

みずほ銀行で３月１２日に発生した外貨建て送金のトラブルについて、基幹システムに取引データを送るための機器が壊れたことが原因と特定したようです。そして、この危機を納入してメンテナンスも担っていた日立製作所に対して損害賠償を含む一定の負担を請求する可能性をみずファイナンシャルグループでは示しました。

機器の故障で動くはずであったバックアップも稼働せずに装置の復旧に約７時間を要したとのことです。２０２０年１０月に東京証券取引所で丸一日取引を停止したトラブルの際には早い段階で東証側では富士通に対する賠償請求を否定しました。その判断とは、みずほＦＧの判断は大きく異なっていることが特徴的です。