銀行システムにメインフレームが残る理由 by @tsuchie88

(๑╹◡╹๑) @tsuchie88

銀行の勘定系システムって、レガシーの典型的な例に挙げられることが多いんだけど、実際これをオープン系に移行すればコストが下がるんじゃないか、と思われがちなんだけど、そんな単純な話だったら、今メインフレームなんか残ってないと思う

(๑╹◡╹๑) @tsuchie88

理由はいくつかあって、例えばネット銀行や一部の銀行ではRDB(OracleやMS-SQL)を使ってるケースがあるけど、上位地銀やメガクラスになるとかなり難しい。先進的な銀行ではIMSを使ってる例もあるが、ほとんどがトランザクションモニターとファイルの塊みたいな運用

(๑╹◡╹๑) @tsuchie88

IMSは階層型データモデルのデータベースなんだけど、実際に多く使われてるのはIMS FastPathなんかが多い。こいつは、NoSQLみたいなもので機能を絞り込んでとにかく高速化させた特殊なIMSのバージョン。元々は、日本の銀行の要求で開発されたもの

(๑╹◡╹๑) @tsuchie88

いまだと、IBMのSAIL/IMSとか、JRIのOpenDIOSA、日本ユニシスのMIDMOSTみたいな近代的なミドルウェアがあるけど、そんなものなかった時代にスクラッチでシステムを構築していったので独自性が強くなってる。そういうのをパッケージ化していったという流れもあるが

(๑╹◡╹๑) @tsuchie88

勘定系なんて特に応答速度が求められるので(ATMで操作してお金が出てくるのに5分かかってたらダメだろうし)、高速化のためにアセンブラで置き換えたりとかしていた時代もあった。そもそも、勘定系でCOBOLが入ってきたのはかなり最近の話

(๑╹◡╹๑) @tsuchie88

クラスタリングで解決、ってのも一つの手だろうし、分散化の流れもある。実際に、大手銀行だと90年代に住友銀行が第四次オンラインシステムで、店群別システムを導入しているし、世界最大級の郵貯オンラインは富士通製メインフレームクラスタを使ってる。

(๑╹◡╹๑) @tsuchie88

ただし、クラスタリングひとつとってみてもオープン系システムで置き換えるのはかなり難しい。例えば、Oracleのクラスタはソフトウェアでクラスタを行うので、例えば64CPU分の能力のシステムを2台クラスタさせたとしても、オーバーヘッドがあるので96CPU分くらいにしかならない

(๑╹◡╹๑) @tsuchie88

一方で、メインフレームはハードウェアレベルでクラスタ対応していて、OSやミドルウェアレベルでも対応しているので、ノードを増やすとシームレスに性能が上がる。演算部分と通信部分を別プロセッサがやってるので、CPU増やすと本当にその分だけ性能が上がる。

(๑╹◡╹๑) @tsuchie88

信頼性の面でも、ハードウェアの徹底的な二重化が行われているし、トランザクションレベルでの実効性の保証ができるようになっているので、こいつをオープン系に置き換えるとそれだけでかなりの計算機資源を使ってしまい、コスト的にかなり苦しくなる

(๑╹◡╹๑) @tsuchie88

あと、トランザクションの粒度の問題。例えば、WikiのRDBの処理だと多くても100くらいのSelectが走る程度だと思うけど、銀行の勘定系だと千から万単位がたぶん流れてる。それも、「不正口座リスト」みたいな総なめするような処理がやたらとある

(๑╹◡╹๑) @tsuchie88

そんなクソ重い処理が、メガバンクだとおそらく秒間1000トランザクション以上、設計上は1万トランザクションくらいの設計になってると思う。しかも、このオンライン時間の間にも無数のバッチが平行して走ってる。重いバッチは夜間だけど、夜間もオンラインは停められない

(๑╹◡╹๑) @tsuchie88

で、しかもこういうシステムを少なくとも10年、やばい銀行だと20年とかハードウェア換えずに平気で使ってるから、長くても10年くらいしかサポートしないオープン系だとかなり苦しい。

(๑╹◡╹๑) @tsuchie88

もうひとつはコスト構造だ。金融機関のシステム構築は、要件定義とテストがものすごいコストがかかってる。要件定義に2年かけて、詳細設計とコーディングに1年かけて、2年くらいテストやってるような時間感覚。勢い、コーディングの生産性とかあんまり重要じゃない。むしろ、安全性が求められる