SOAなのにトラブルが連鎖、みずほ銀行システム障害の謎

　みずほ銀行で2021年2月28日に起きたシステム障害には大きな謎がある。それはサービス指向アーキテクチャー（SOA）を採用したとされる勘定系システムの「MINORI」で連鎖障害が発生したことだ。第三者委員会の報告書は「MINORIの構造、仕組み自体に欠陥はない」とするが、それを疑問視する声もある。

　本特集はこれまで、MINORIで大規模な障害が発生した詳細を解説してきた。今回は「(9)なぜe-口座への一括切替処理を2～3月に実施したのか」「(10)なぜインデックスファイルをメモリーに置いたのか」「(11)なぜインデックスファイルのリスクを見逃したのか」「(12)なぜSOAなのに被害が拡大したのか」を取り上げ、今回のシステム障害にまつわる「謎」を解き明かす。

疑問9　なぜe-口座への一括切替処理を2～3月に実施したのか

　みずほ銀行は2021年2月27日から6回に分けて、1年以上記帳が無い定期性預金の口座約259万件を、通帳を発行しない「みずほe-口座」へ一括して切り替える計画だった。1回につき切り替える口座は45万件だ。

　しかし2月28日、定期性預金システムでは45万件のe-口座一括切替処理に加えて、月末取引のバッチ処理が25万1000件予定されていた。合計は70万1000件だ。それに対して、定期性預金システムの「取消情報管理テーブル」のインデックスファイルは、1日当たりの更新が64万2969件を超えると容量オーバーになる設定だった。

　月末や年度末の処理がある2～3月にe-口座への一括切替を強行したのは、3月末までに259万件の通帳を廃止できれば、印紙税を年間約16億円削減できると見込んでいたためだ。

「突き抜け」の心配は無かった

　またみずほ銀行は45万件のバッチ処理がリスクになると認識していなかった。そもそも45万件のバッチ処理は、決して規模は大きくない。実際にみずほ銀行は2月27日に、45万件の定期性預金口座をe-口座へ一括切替したが、処理は1時間25分で完了した。一般にバッチ処理で最も警戒されるのは、制限時間内に処理が完了しない「突き抜け」だ。今回のバッチ処理は突き抜けが起きる心配も少なかった。みずほ銀行が警戒を怠っていたのは、定期性預金システムのインデックスファイルに存在した容量制限という落とし穴だ。

疑問10　なぜインデックスファイルをメモリーに置いたのか

　定期性預金システムには、1日当たりの更新が64万2969件を超えるとデータベース（DB）が更新不能になる落とし穴があった。「取消情報管理テーブル」のインデックスファイルをメモリーに保存していたためだ。

　みずほ銀行はMINORI開発中の2017年11月に、定期性預金システムで実施する「おまとめ処理」というバッチ処理において、処理が制限時間中に終わらなくなる懸念に直面した。そこで同システムのDBにある「定期明細」や「定期取引明細」などの「業務テーブル」のインデックスファイルと、取消情報管理テーブルのインデックスファイルの保存先をメモリーに変更することで、バッチ処理の高速化を図った。

　取消情報管理テーブルは、定期性預金システムが処理したトランザクションの内容を記録し、後から取り消せるようにするために設けたものだ。トランザクションが発生する度に、テーブルのレコードは増える。

インデックスの更新は重い処理

　DBのインデックスは、参照するだけなら非常に高速だが、インデックスを更新するのには時間がかかる。特にテーブルにレコードを追加すると、インデックスのノードを分割する必要などが生じるため、更新にさらに時間がかかる。毎回レコードが増える取消情報管理テーブルのインデックスは、ノード分割などが頻繁に発生するため、保存先をメモリーに変更して処理の高速化を図ったのだと推測できる。