みずほ銀行で2021年2月28日に起きたシステム障害は、同行が保有する7割超のATMに不具合が出るなど、顧客に大きな影響を与えた。直接の原因は、同日に行った定期預金に関するデータ更新作業でシステムのキャパシティーを超えた負荷がかかり、処理に失敗したことだ。
「見積もりをした上でテストしたが、これが不十分。運用面で見積もりの甘さがあった」。3月1日に開いた記者会見で、みずほ銀行の藤原弘治頭取は、システム負荷が想定を超えた理由に言及した。
会見で質疑応答が進み、障害が発生した経緯、処理内容、データ量などが明らかになるにつれ、ある疑問が湧いてきた。もしかしたら障害を回避できる可能性があったのではないか。気になるのが「前日の運用」だ。
想定以上のデータ量でメモリー不足に
まず2月28日の日曜日に何が起きたのかを会見内容を基に追っていこう。定期預金に関するデータ更新作業は2種類あった。1つは定期預金の積み立てといった定例のデータ更新、もう1つは1年以上通帳の記帳がない顧客口座についてシステム上で「不稼働」のフラグを立てるステータス変更だ。
28日は定例更新が25万件、ステータス変更が45万件の合計70万件のデータが処理対象だった。2種類のデータ更新作業を実行したところ、システムのキャパシティー不足で処理が失敗した。キャパシティーとはメモリー容量と推測できる。「メモリーについては5倍に増強した。これにより現在は復旧している」（藤原頭取）という対処策を打っているからだ。
「ステータス変更は臨時作業であり、これまでやったことはない」。片野健常務執行役員が話したように、2019年7月に全面稼働した同行の勘定系システム「MINORI」にとって、このステータス変更の処理は初めてだった。
ただし、ステータス変更自体は「それほど難易度の高い作業ではない」（片野常務）。データベースのテーブルにあるレコードのステータスを変更するだけだ。MINORIで定期性預金システムを構築したのは富士通であり、データベースは同社の「Symfoware Server」を用いている。簡単なSQLでステータスを変更できるはずだ。
処理は簡単だが、データの処理量が想定を上回りメモリー不足を引き起こした。今回実施したステータス変更の作業は3週間程度にわたって行う予定であり、1回当たりに処理するデータ量が45万件だ。これに、その日の定例更新のデータ量を合わせたものが、処理すべき全量となる。「（2月）28日は月末のため、通常取引が25万件と想定以上に多かった。この影響を見誤ったのが反省点だ」（片野常務）。
結果として70万件の処理に失敗したが、何件だったらさばけたのか。実はこれは証明済みの数字があり、10万件少ない60万件なら問題なく処理できた。なぜなら、前日の2月27日（土曜日）に45万件のステータス変更を含む同様の処理を実施しているからだ。「土曜日にはこの処理が問題なく行われた。通常の定期預金の更新処理は土曜日が15万件、日曜日が25万件だった」（藤原頭取）。
さて、ここからが本題。27日に正常に終えた60万件の処理実績を、28日の70万件の障害回避に生かせなかったのだろうか。これが疑問の中身だ。
