アプリで作成

残響のCOBOL ~ 変わらないために変わり続ける

自分用メモ。内部はCOBOLで動くWindows勘定系とか、3年で2度延期されたホストリプレースの現場とか、金融系運用に関わってきた身にとっては興味深いおはなし。 追記:前提のCOBOL特性まとめ ケルビン氏の『なんでCOBOLがリプレースされんのかという話』 https://togetter.com/li/1316410
20
ケルビン@斜壊人 @legendkelbin

リプレースに関して言えば、わかり易いイメージだと「ハウルの動く城を一旦全部解体して、全て整理して再設計した上で再建築する」という感じになるわけです。オプションとして「但し稼働は止めてはいけない」までつくのかな。たかがCOBOLかもしれないですが、積み上がると化物になるわけです。

2019-02-05 18:16:45
(๑╹◡╹๑) @tsuchie88

これわりかしあって、単純なリプレースで今あるレガシーシステムをJavaとかで単純に置き換えができればいいんだけど、分散配置されたシステムを単一システムに統合とか要素が加わってくると、とたんに「システム更新」と「業務合理化」が合体してしまって、テスト工程以降がとてつもなく複雑化すんだな

2019-02-05 20:30:06
(๑╹◡╹๑) @tsuchie88

スコープを限定して置き換えだけに焦点を絞るとかになると、「置き換えだけにそんな金かけんのか」って投資経済性の話になってやりにくいし。不可避案件ばっかやってたらレガシーが残り続ける問題。

2019-02-05 20:31:49
(๑╹◡╹๑) @tsuchie88

まぁ統合案件とかは、レガシーシステムのまま統合や合理化を進めて、リプレースはそのあとにやったほうが楽な気がする(個猫の感想です)

2019-02-05 20:33:25
(๑╹◡╹๑) @tsuchie88

まぁレガシー案件というとメインフレームやオフコンの話が多くなる傾向にあるんですが、実はオープン系でも結構こういう話があって、レガシーなオープン系(UNIXとか古いWindowsとか)や、わしの古巣のFA系とかの方が結構苦しいんですよね。DOSとかマイコン制御現役だし

2019-02-05 20:43:22
(๑╹◡╹๑) @tsuchie88

UNIX案件は、結構古いCのコードとかだと素直だからLinuxでmakeしたらそのまま動いちゃうとか多いのでそこまで面倒じゃないけど、Shellが噛んでるやつとかになるとあれーとかなる。

2019-02-05 20:45:04
(๑╹◡╹๑) @tsuchie88

古いLinuxとかWindowsを動かすために、古いバージョンのVMを動かすために、Embeddedクラスのサーバハードが調達して何とかするなんて黒魔術が生まれたりしてかなり嫌

2019-02-05 20:46:45
(๑╹◡╹๑) @tsuchie88

この点、メインフレームとかオフコンOSとかだと、バイナリレベルで最新OSでも互換性あったりするんで、維持は楽な感じはあったりする(そこがダメだという意見もあるが)

2019-02-05 20:49:33
(๑╹◡╹๑) @tsuchie88

ところで、「こんなにCOBOLやメインフレームで維持するのが面倒なのに、ITがコストセンターになってる銀行基幹系でまだ残ってるのか」って話すると、次の三つの理由があるんじゃないかと思うんですよね。

2019-02-05 23:19:18
(๑╹◡╹๑) @tsuchie88

第一に、垂直総合の解体。現代の銀行勘定系の元になったのは、1980年代の第三次オンラインシステム(三オン)で、基本的には機能はあまり変わってないんだけど、中身はかなり変化している。

2019-02-05 23:20:34
(๑╹◡╹๑) @tsuchie88

三オンができた頃って、オンラインシステムはメインフレームを中核とした垂直統合的なシステムで、昼間はオンラインを実行して夜間はバッチ処理をやるみたいな感じで、全部の業務処理がホスト機に集中していた。

2019-02-05 23:21:32
(๑╹◡╹๑) @tsuchie88

ところが、三オンのテーマにもなっているけど、この時代からバッチ処理は情報系にどんどん外出しして、勘定系はオンライン制御に特化する設計だった。時代を経るにしたがって、勘定系で持ってる機能を外部化していって、それらがオープン化されていくわけです。

2019-02-05 23:23:05
(๑╹◡╹๑) @tsuchie88

例えば、90年代にはDWHが流行るんですけど、この時代くらいから情報系からDWHにデータを集めて営業系で使うようになったり、帳票出力処理も情報系でやるようになっていくわけです。

2019-02-05 23:24:29
(๑╹◡╹๑) @tsuchie88

これが現代的にいうと、統合DBに一旦データを集めて、そこからDWHやら営業端末やら、チャネル系や帳票系にデータを変換して渡すみたいな仕組みにつながってるわけなんですよね。

2019-02-05 23:25:39
(๑╹◡╹๑) @tsuchie88

逆の言い方をすると、勘定系に集中していた処理が、周辺系に機能が移っていって、負荷が重い処理とか、新規に開発するシステムは外部化されていったという感じになる。

2019-02-05 23:27:02
(๑╹◡╹๑) @tsuchie88

二つ目なんだけど、新規開発の部分は極力Javaとかに置き換えられているという点。あまりいじらない基本的な機能はCOBOLのまま残しておいて、新規機能はJavaで作るという感じが増えてる。

2019-02-05 23:28:06
(๑╹◡╹๑) @tsuchie88

銀行に限らず、業務基幹系システムを10年も維持すると、新規に投入するコード量は元のシステムの10倍くらいになったりすることもある。機能向上はなくても、法令改正対応みたいな不可避案件も多いのでこれは仕方がない。

2019-02-05 23:29:41
(๑╹◡╹๑) @tsuchie88

そうすると、元のレガシーなコードを極力いじらずに、新規開発をCOBOL以外のコードで書いたり、プラットフォームにRDBやオープンシステムを使う形で、置き換えて維持する形態が生まれてくる。

2019-02-05 23:31:26
(๑╹◡╹๑) @tsuchie88

もちろん、元のコードを全くいじらないというわけじゃなくて、新規開発部分で入出力をしやすいように、出力形式を標準化したり、コンテナ化、システム間接続にEAIを使ってインターフェースを統一するとかいろいろな工夫をやってる。

2019-02-05 23:32:27
(๑╹◡╹๑) @tsuchie88

例えば、これは(10年くらい前の)三菱UFJ銀行の基幹系構成図なんだけど、EAI基盤を使って勘定系ホスト中心の垂直統合システムから、分散化されたシステムから標準化された通信手順で機能を呼び出すようなシステムに大きく変わっている。 pic.twitter.com/KwcgtsxacQ

2019-02-05 23:35:55
拡大
(๑╹◡╹๑) @tsuchie88

三つ目なんだけど、メインフレームの性能が向上したこと。90年代くらいまでは、メインフレームの性能は分散化されたオープン系と比べてしょぼかったんだけど、いろいろな要因でメインフレームの性能はかなり上がった。

2019-02-05 23:37:41
(๑╹◡╹๑) @tsuchie88

例えば、IBM Zの最新機種のz14のケースでみると、1システムに搭載できるCPUは240CPUで、動作クロックは5Ghzを超える。並列シスプレックス接続すればクラスタリングでさらに性能を上げられる。

2019-02-05 23:41:15
(๑╹◡╹๑) @tsuchie88

従来的なメインフレームのソフトウェアだけでなく、メインフレーム自体でJavaやRDBを稼働させても、性能的にオープン系よりも早いようなケースが多い。

2019-02-05 23:43:38
(๑╹◡╹๑) @tsuchie88

しかも、メインフレームは、論理分割や仮想化が昔からあるので、例えばメインフレームの筐体を論理分割して、メインフレームOSとLinuxを走らせてメモリ上でデータ連携する(Hyper Socket)ような新しい使い方もできる。

2019-02-05 23:45:42
(๑╹◡╹๑) @tsuchie88

以上の話を踏まえると、大手銀行で基幹系のクラウド化が視野に入っているというのはそれほど不思議な話じゃないんですよ。基幹業務が外部に切り出されて周辺化されていっていて、それらを稼働させるためのプライベートクラウドが既に存在している。

2019-02-05 23:53:23
残りを読む(3)

コメント

kartis56 @kartis56 2019年2月7日
この辺から進化すごいよね、そして前世紀と比べてストレージが大きく早くなったのもある >メインフレームの筐体を論理分割して、メインフレームOSとLinuxを走らせてメモリ上でデータ連携する
0
nekosencho @Neko_Sencho 2019年2月12日
考えてみりゃ、パソコンなんて存在しなかったころからいろいろ積み上がってきてるんだもんな。
0