うん、まあ、カード吸い込まれたりATM使えなくなったりしたら「この銀行クソだ」って思いますよね。システム側の都合なんて利用者は知ったこっちゃないわけです。だからまあクソクソ言われることについてはある程度許容しなければならないと思いますが、それはそれとして特段の事情というか、決定的にクソというわけでもないというか、他の銀行が無条件に大丈夫ってわけでもないのですけど、みんなみずほの信頼性が不安になるのは確かですよね。ちょっと不当に批判されているような気もするので、ある程度安心感（ほんとに安心できるか？までは保証できませんが）のために解説できそうなところは解説してみようと思います。
まあ、中の人ではないので、公開されている情報を噛み砕いて、という話ではありますが…
MINORIシステムの全容についておさらい
みのりちゃんですが、日経に絵が上がっているのでご参照ください（会員じゃないと拡大できないですが、何となく読み取れるはず）
絵をざっと説明すると、
- ユーザーに直接触れるチャネル層（ATM、インバン、外部接続等々）
- HUB第一階層（フロントエンド）
- 取引メイン
- HUB第二階層（バックエンド）
- 勘定系コンポーネント
という構成ですね。で、絵に書いてあるとおり、CIFや手数料のような全トランザクションに関わるものは取引メイン直結になっていますね。あと、流動性預金、内為等、使用頻度とトランザクション量が多いものも直結になっています。これは取引メインと同じ「IBM z」というメインフレーム上のアプリケーションでハイパフォーマンスを実現している、ということですよね。
この構成で頑張っているのは、勘定系コンポーネントがそれぞれの取引の元帳（定期、融資、ローン等々）の更新処理をしなければならないのですが、それぞれのコンポは当然別筐体なので、コンポごとの取引の更新処理はそれぞれのコンポのデータベースがそれぞれのトランザクションで処理しているわけですね。流動性からお金を出して定期に入金する、という処理は従来の「ホスト一括管理」型の勘定系システムであれば、お金を出すトランザクションと定期に入金するトランザクションは同じトランザクションで更新されるため、不整合が起きません。しかし、MINORIの方式では当然システム障害により不整合が発生する可能性がありますので、異常系への対処がキモになっています。なので、取引取消フローとかが複雑になりますし、そこで以下にして整合性を保つか、ということがシステムの最大のポイントになるわけですね。
この、オンライントランザクションの整合性、という問題はこの手のシステムにはどうしてもついて回ります。特にお客さんのお金を預かっているシステムですから、残高が急に無くなったり、二重に振り込まれたり、というのは極力避けたい。そういうことが起きるくらいなら障害でダウンしたほうがマシ、ということに大体はなります（逆に言うと、そういう一時的な不整合をお客さんが認めてくれるのであればシステムの開発難易度は多分1/5くらいに下がるんですけどね…金融庁も含め、どうもよりコストを掛ける方向にしか不具合発生時の指導がされないので、みんながクソクソ言えば言うほど手数料は上がっていくんだと思いますが…）
今回の障害って何が起きたの？
報道されていることだけでわかることだけでは足りないのでかなり推測がまじりますが…
www.itmedia.co.jp
こちらの記事に書かれている通り、事の発端は
障害が起きた28日も、みずほ銀行は約45万件のデータ更新作業を行っていた。しかしこの日は、27日を10万件上回る25万件の月末処理が重なった。システム上の空き容量が不足した結果、インターネットバンキングやATMで定期預金の取引ができなくなる障害が発生したとしている。
ということになります。MINORIにおける勘定系のバッチ処理はオンライン型（バッチ取引をオンライン取引として流す）形になるので、実質大量のオンライン取引を行うのと代わりありません。今回の臨時的な処理がそれに該当するかはわかりませんが、おそらく該当するでしょう。で、ポイントはここに書かれている「定期預金の取引ができなくなる障害」なんですよね。これ、取引ができなくなるだけなら多分今回のような問題は起きません。ポイントは、定期預金は取引メインから呼ばれるコンポーネントだ、ということですね。取引の全体をつかさどる取引メインからすると、この状態において定期預金コンポからどういうエラーが返ってきたのかが問題です。やろうとしている処理が終わったのか、終わってないのかが最も重要で、処理が成功したか失敗したかは問題じゃないですよね。つまり、「処理結果不定」な状態が一番困ります。不定な状態だとそれ以上他の取引を進めることはできません。
ここからは推測ですが、今回の処理はメンテナンス系の処理だったので、ユーザーの意思によらず行われていますね。そうすると、ユーザーの知らないところで「処理結果が不定な口座」の状態が生まれてしまっていた、と思われます。そうするとどうなるか。まあ、定期預金って大体総合口座とかで普通預金とセットになってたりしますので、その一連口座について「処理結果不定でおかしい状態っすよ」ってなっちゃったのではないか。不思議なのは、そういう状態だってことが確定していれば別に普通にエラー出せば良いはずなのですが、なんでカードを飲んじゃったのか、ということですね。だから、今回システム的に問題があるとしたら、そういう状態になった場合の処理フローに不備があったとかでしょうか。もっとも、この種の基盤系障害で不整合が起きるのはよっぽど不運な多重障害のときだけ、と普通は考えますから、こんな簡単にしかも大量先に起きる、ということ自体が想定外だったのではないかと思います。でも、このパターンだとカード飲まずに済ませたかったですよね。
まあ、想定外だから許してちょってわけにはいかないんですけど…
MINORIシステムは脆弱なのか
このシステムを評して「真の統合がされてない」なんてことを言う人もいるようですけど、少なくとも勘定処理においては旧銀行のシステムの部分は完全に刷新されていますよね。コンポーネント化されているのもセクショナリズムや旧銀行の争いによるものではなく、システム戦略としての必然として生み出されたものです。もちろん、完璧な設計のシステム、というわけではないです（何しろ初期の構想は15年前のものだし）が、少なくとも、旧勘定系の時代より柔軟な変更、拡張ができるシステムにはなっていると思います。なにしろ旧勘定系はいろいろなものが密結合していて取引に項目を1個追加するにも「関係部署」が10個くらい集まって会議してたって聞きますからね…
ただ、アーキテクチャとしては非常に複雑になっているのは確かで、今回のような考慮が漏れる、という自体は発生するだろうし、今回の自体の期待値は「定期の取引だけができなくなる」だったはずなんですよね。これが全体の問題に広がってしまったことは非常に大きな問題だと思います。
とはいえ、今回の原因分析は内部的には素早く進むでしょう。システムの不透明なところが無くなっているので障害原因の特定は簡単だし、コンポーネント単位での修正対応もきっちり進むはずです。また、カードが飲まれる原因となった障害フローについては見直しが進むのではないかな。これは根本的な方針の部分もあるのでパッとは終わらないかもしれません。
まあ、それにしてもちょっとダメだよね、という評価になるのは避け得ないかな、と思ってはいますが、イキり倒してケチョンケチョンに言っている向きが言うほどではないと思うんですけどね。直接間接で被害を受けた人が怒る事自体は問題ないと思いますけどね。
