たまたま、毎月読んでいる雑誌2誌(文芸春秋 2011/5月号「丸の内コンフィデンシャル」、日経コンピュータ 2011/3/31号「緊急レポート東日本大震災」)が書いていたので、雑感としてまとめてみる。
まず、トラブルの発端について。
両誌とも原因は義援金の受付がそもそもの発端と書かれている。
日経コンピュータには、みずほ銀行は口座開設時に1日の振込件数がデフォルトで9999件に設定するが、大量の振込がある口座にはもっと大きな値を設定すると書かれている。
この9999という数が何ともシステム的ではある。
しかし、普通にDBの設計を行う際に大手都市銀が数値4ケタでオーバーフロー前提とはおかしくないかと思った。
そこで今度は文芸春秋をみてみると、みずほは店番号で決済データを管理しており、支店ごとの管理である旨書かれている。ちなみに他行は銀行全体で管理ともある。
この文面から推測(あくまで推測です!)するに、振込明細テーブルは支店番号と件数(ID?)が4件なのだろうか?または、ずほのDB設計は、支店ごとに振込明細テーブルを作成し、そのテーブルの件数(ID?)が数値4ケタで設定しているということではないのだろうか?
文芸春秋には、ほかの銀行は銀行全体で1か所で管理とあるので、振込明細データは銀行全体(全支店)で1本にし、IDも銀行全体で非常に大きな値で設計していると思われる。
しごくまっとうな設計である。
文芸春秋によると、本店や東京中央、兜町などの支店に震災義援金の払い込みが殺到しており、そこでオーバーフロー。夜間バッチに異常が発生した。そしてそれにより、他支店のバッチも終了せず、こうなったのではないか。
と思うと、みずほのシステムのDB設計は構造的に非常に問題があるように思うのだが...
そして、この設計から思うにほかにも構造的な問題がありそうである。
システム経費が掛かるかもしれないが、このような問題のある設計を排除するには、大規模な再構築する必要があるのではないだろうか?
文藝春秋によれば、システム更新を伸ばしてきたと書かれているが、昔はそのような設計でもよかったかもしれないが、時代が変わればデータ量も変わるし、それによりアーキテクチャやDB設計も変えなければならない。
昭和の香りがするシステム設計・DB設計と決別しない限り問題は起き続ける気がするが...
最近のコメント