全15806文字
PR

2月28日のシステム障害では、ささいなミスが巨大なトラブルに発展した。なぜデータベースは更新不能になり、それがATMの障害につながったのか。なぜ障害の兆候は見逃され、原因究明に時間を要したのか。11の疑問点を解き明かす。

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

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

 2019年7月に本格稼働したMINORIは、前身である「STEPS」時代はメインフレーム上でモノリシック(一枚岩)な状態で稼働していた勘定系システムを、機能別に様々なサブシステムに分割した。

図 勘定系システム「MINORI」の全体像
図 勘定系システム「MINORI」の全体像
複数のサブシステムを「取引メイン」が制御
[画像のクリックで拡大表示]

 各サブシステムはメインフレームやUNIXサーバー、Linuxサーバーといった異なるサーバー上で分散稼働し、開発ベンダーやデータベース管理システム(DBMS)の種類もバラバラだ。

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

図 MINORIの各業務システムの担当ベンダーと採用ソフトウエア
図 MINORIの各業務システムの担当ベンダーと採用ソフトウエア
サブシステムごとにOSもデータベースも異なる
[画像のクリックで拡大表示]

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

 CIFと流動性預金システムは米IBM製メインフレーム上で稼働する。CIFが採用するDBMSはIBMのリレーショナルデータベース(RDB)である「Db2」で、流動性預金システムのDBMSは階層型DBの「IMS」だ。一方、定期性預金システムは富士通のLinuxサーバー上で稼働し、DBMSには富士通のRDBである「Symfoware Server」を採用する。またメインフレームとLinuxサーバーの間のトランザクションは、「メインハブ」と呼ばれるUNIXサーバーが中継する。つまり分散トランザクションは異なる3つのアーキテクチャーをまたいでいる。

図 MINORIにおける分散トランザクションの例
図 MINORIにおける分散トランザクションの例
異なる3つのアーキテクチャーをまたぐ
[画像のクリックで拡大表示]