全4088文字
PR

 みずほ銀行で2021年2月28日に発生したシステム障害では、勘定系システム「MINORI」のサブシステムで発生したエラーがシステムの中枢に波及し、トラブルの範囲が拡大した。なぜエラーは連鎖したのか。そこには設計と運用に関わるミスがあった。

 本特集はこれまで、MINORIのサブシステム「定期性預金システム」でデータベース(DB)が更新不能になった原因や、それがATMにおける通帳やキャッシュカードの取り込みにつながった経緯を説明した。

ささいなミスが大規模障害に発展した原因
疑問点概要
1なぜデータベースは更新不能になったのか
2なぜDBの更新不能がATMのカード取り込みにつながったのか
3なぜ「二重エラー」が発生したのか
4なぜ一度減ったATMのカード取り込みが急増したのか
5なぜ警告やエラーは見逃されたのか
6なぜ障害の規模や原因を見誤ったのか
7なぜ頭取に情報が届かなかったのか
8なぜ営業店での顧客対応が遅れたのか
9なぜe-口座への一括切替処理を2~3月に実施したのか
10なぜインデックスファイルをメモリーに置いたのか
11なぜインデックスファイルのリスクを見逃したのか
12なぜSOAなのに被害が拡大したのか

 第3回である今回は、「(3)なぜ『二重エラー』が発生したのか」と、「(4)なぜ一度減ったATMのカード取り込みが急増したのか」を解説しよう。

(3)なぜ「二重エラー」が発生したのか

 みずほ銀行が2021年2月28日朝、定期性預金の口座約45万件について、通帳を発行しない「みずほe-口座」へ一括して切り替える処理を始めた。すると午前9時50分ごろ、定期性預金システムのDBにある「取消情報管理テーブル」のインデックスファイルが更新できなくなり、これをトリガーに定期性預金システムのDB全体が更新不能になった。

 定期性預金システムのデータベース管理システム(DBMS)はトランザクションに際して、必ず複数のテーブルを更新しようとする。具体的には「定期明細テーブル」「定期口座残高テーブル」といった口座情報に関する「業務テーブル」と、業務テーブルに対する更新内容を記録しておく取消情報管理テーブルだ。

 定期性預金システムのDBMSは、取消情報管理テーブルが更新不能になった際に、業務テーブルや取消情報管理テーブルに対して行われていた更新を、すべて取り消し(ロールバック)していた。これはDBMSとして正しい動作である。

アプリケーション側のエラー設計に問題あり

 しかしDBMSが正しく更新をロールバックしていたにも関わらず、DBMSに対してクエリーを発行する定期性預金システムのアプリケーションが更新状態の判定を誤り、取引メインに対してDBの「更新状態不明」が発生したと報告してしまった。定期性預金システムのアプリケーションにおけるエラー設計に問題があった。

MINORIで二重エラーが発生した経緯
MINORIで二重エラーが発生した経緯
[画像のクリックで拡大表示]

 DBの更新状態不明は、勘定系システムでは起きてはならない深刻なエラーである。取引メインはこのエラーによって、定期性預金システムにおいて預金残高などに不整合が生じる恐れがある「元帳不整合不明」のシステムエラーが発生したと判断した。そこでエラーを起こしたトランザクションを確実に取り消すよう、定期性預金システムに対して更新取り消し処理を要求した。

 MINORIにおいては分散トランザクションを取り消す際に、各サブシステムのDBMSが記録する取消情報管理テーブルを参照して、取り消すべきトランザクションを特定する。しかしこのケースでは取消情報管理テーブルの更新そのものが失敗していたので、取消情報管理テーブルには取り消すべき更新の情報が無かった。そのため取引メインによる更新の取り消しが失敗してしまう。

 定期性預金システムで更新状態不明のエラーが発生しただけでなく、その更新を取り消そうとする処理もエラーになってしまった。ここで取引メインは「二重エラー」が発生したと判断した。