全5020文字
PR

 あるデータベース(DB)でインデックスの容量が上限値を超えた――。みずほ銀行で2021年2月28日に発生したシステム障害では、運用上のささいなミスが巨大なトラブルに発展した。ATMが通帳やキャッシュカードを5244件も取り込み、多くの顧客が数時間も立ち往生した。みずほ銀行に何が起きたのか。障害拡大の真因を分析する。

 本特集の第1回で紹介したように、みずほ銀行が2021年2~3月に起こした4件のシステム障害は、システムの設定に関する見落としやプログラムのバグ、ハードの故障といった避けがたいよくあるトラブルが起点だった。しかし金融機関ではあり得ないような問題点が35件もあったため、顧客に大きな影響を与えた。

 そうした問題点はなぜ発生したのか。本誌はみずほフィナンシャルグループ(FG)が設置した「システム障害特別調査委員会(第三者委員会)」の報告書を基に、疑問点を12個抽出した。その中から今回は(1)なぜデータベースは更新不能になったのか、(2)なぜDBの更新不能がATMのカード取り込みにつながったのか、という2つの疑問点について解説しよう。

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

(1)なぜデータベースは更新不能になったのか

 2月28日に発生したシステム障害の起点は、勘定系システム「MINORI」のサブシステムである「定期性預金システム」において、DBが更新不能になったことだった。なぜDBが更新不能になったのか。MINORIにおける分散トランザクションの仕組みからひもとこう。

 2019年7月に本格稼働したMINORIは、前身の「STEPS」時代はメインフレーム上でモノリシック(一枚岩)な状態で稼働していた勘定系システムを、機能別に様々なサブシステムに分割した。各サブシステムはメインフレームやUNIXサーバー、Linuxサーバーといった異なるサーバー上で分散稼働し、開発ベンダーやデータベース管理システム(DBMS)の種類もバラバラだ。

みずほ銀行勘定系システムの構成図
みずほ銀行勘定系システムの構成図
出所:みずほフィナンシャルグループ
[画像のクリックで拡大表示]
MINORIの各業務システムの担当ベンダーと採用ソフトウエア
業務システム担当ベンダーOSデータベース
流動性預金富士通メインフレーム(z/OS)IMS
内国為替取引富士通メインフレーム(z/OS)IMS
取引メイン日本IBMメインフレーム(z/OS)IMS
CIF日本IBMメインフレーム(z/OS)Db2
手数料日本IBMメインフレーム(z/OS)IMS
定期性預金富士通Red Hat Enterprise Linux(RHEL)Symfoware Server
与信取引日立製作所RHELHiRDB
ローン日立製作所RHELHiRDB
外国為替取引日立製作所RHELHiRDB
日計日立製作所RHELHiRDB
還元計表富士通RHELOracle Database
業務チャネル富士通RHELSymfoware
外部チャネル富士通RHELSymfoware
信託日本IBMRHELDb2
DM日本IBMAIXDb2

 MINORIにおいて取引を処理する際には、顧客データを管理するサブシステム「CIF(カスタマー・インフォメーション・ファイル)」や「流動性預金システム」、「定期性預金システム」、「内国為替システム」といった様々なサブシステムにまたがる分散トランザクションを実行する。MINORIにおける分散トランザクションは「取引メイン」と呼ばれるメインフレーム上で稼働するサブシステムが制御している。

 例えば、顧客が普通預金口座にある預金を定期預金口座に振り替える場合。まず取引メインは顧客のCIFレコードに対して排他処理を行い、他のトランザクションからCIFを更新できないようロックする。その上で流動性預金システムにアクセスして普通預金の残高を減少させ、定期性預金システムにアクセスして定期性預金の残高を増加させ、最後にCIFのロックを解除する。

「取消情報管理テーブル」とは?

 MINORIは分散トランザクションが途中で失敗した場合に取り消し(ロールバック)したり、取引成立後にも取り消ししたりできるように、各サブシステムのDBに「取消情報管理テーブル」を設けている。各サブシステムは取引メインから依頼された口座への入出金といったトランザクションを実行すると、その内容を取消情報管理テーブルに記録する。取引メインは分散トランザクションを取り消す際、取消情報管理テーブルにある情報を利用して、各DBで行われた個別のトランザクションを取り消していく。

 2021年2月28日朝、みずほ銀行は1年以上記帳が無い定期預金の口座約45万件について、通帳を発行しない「みずほe-口座」へ一括して切り替える処理を始めた。これ自体はバッチ処理(集中記帳処理)である。ただしMINORIにおいてはバッチ処理は1件1件のオンライン処理に分解され、取引メインが分散トランザクションとして実行していく。

 しかし9時50分ごろ、定期性預金システムにおける取消情報管理テーブルのインデックスファイルが更新できなくなり、それによって取消情報管理テーブル自体も更新不能になった。MINORIの分散トランザクションにおいては取消情報管理テーブルの更新は必須である。よって取消情報管理テーブルの更新が不可になることで、「定期明細テーブル」など定期性預金システムのDBに存在する他のテーブル(取消情報管理テーブルに対して業務テーブルと呼んでいる)もすべて更新不能になった。

 実は定期性預金システムにおける取消情報管理テーブルのインデックスファイルは、1日当たりの更新件数が64万2969件を超えると、それ以上は更新できなくなる設定だった。この日はe-口座への一括切替処理45万件以外に、通常の月末取引に関するセンター集中記帳処理が11万2000件あり、それにATMやオンラインバンキング「みずほダイレクト」からの日中のトランザクションが加わったことで、上限を突破した。

富士通「Symfoware」の仕様上の制約

 インデックスファイルの容量に上限があり、それを越えると更新不能になったのは、定期性預金システムのDBMSである富士通の「Symfoware Server」の仕様や、運用上の事情が関連していた。