まとめの限定公開に「リンク限定」が追加されました。URLを伝えてまとめを共有しよう!

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

自分用メモ。内部はCOBOLで動くWindows勘定系とか、3年で2度延期されたホストリプレースの現場とか、金融系運用に関わってきた身にとっては興味深いおはなし。 追記:前提のCOBOL特性まとめ ケルビン氏の『なんでCOBOLがリプレースされんのかという話』 https://togetter.com/li/1316410
運用 COBOL システム管理
3374view 3コメント
19
ケルビン@斜壊人 @legendkelbin
リプレースに関して言えば、わかり易いイメージだと「ハウルの動く城を一旦全部解体して、全て整理して再設計した上で再建築する」という感じになるわけです。オプションとして「但し稼働は止めてはいけない」までつくのかな。たかがCOBOLかもしれないですが、積み上がると化物になるわけです。
(๑╹◡╹๑) @tsuchie88
これわりかしあって、単純なリプレースで今あるレガシーシステムをJavaとかで単純に置き換えができればいいんだけど、分散配置されたシステムを単一システムに統合とか要素が加わってくると、とたんに「システム更新」と「業務合理化」が合体してしまって、テスト工程以降がとてつもなく複雑化すんだな
(๑╹◡╹๑) @tsuchie88
スコープを限定して置き換えだけに焦点を絞るとかになると、「置き換えだけにそんな金かけんのか」って投資経済性の話になってやりにくいし。不可避案件ばっかやってたらレガシーが残り続ける問題。
(๑╹◡╹๑) @tsuchie88
まぁ統合案件とかは、レガシーシステムのまま統合や合理化を進めて、リプレースはそのあとにやったほうが楽な気がする(個猫の感想です)
(๑╹◡╹๑) @tsuchie88
まぁレガシー案件というとメインフレームやオフコンの話が多くなる傾向にあるんですが、実はオープン系でも結構こういう話があって、レガシーなオープン系(UNIXとか古いWindowsとか)や、わしの古巣のFA系とかの方が結構苦しいんですよね。DOSとかマイコン制御現役だし
(๑╹◡╹๑) @tsuchie88
UNIX案件は、結構古いCのコードとかだと素直だからLinuxでmakeしたらそのまま動いちゃうとか多いのでそこまで面倒じゃないけど、Shellが噛んでるやつとかになるとあれーとかなる。
(๑╹◡╹๑) @tsuchie88
古いLinuxとかWindowsを動かすために、古いバージョンのVMを動かすために、Embeddedクラスのサーバハードが調達して何とかするなんて黒魔術が生まれたりしてかなり嫌
(๑╹◡╹๑) @tsuchie88
この点、メインフレームとかオフコンOSとかだと、バイナリレベルで最新OSでも互換性あったりするんで、維持は楽な感じはあったりする(そこがダメだという意見もあるが)
(๑╹◡╹๑) @tsuchie88
ところで、「こんなにCOBOLやメインフレームで維持するのが面倒なのに、ITがコストセンターになってる銀行基幹系でまだ残ってるのか」って話すると、次の三つの理由があるんじゃないかと思うんですよね。
(๑╹◡╹๑) @tsuchie88
第一に、垂直総合の解体。現代の銀行勘定系の元になったのは、1980年代の第三次オンラインシステム(三オン)で、基本的には機能はあまり変わってないんだけど、中身はかなり変化している。
(๑╹◡╹๑) @tsuchie88
三オンができた頃って、オンラインシステムはメインフレームを中核とした垂直統合的なシステムで、昼間はオンラインを実行して夜間はバッチ処理をやるみたいな感じで、全部の業務処理がホスト機に集中していた。
(๑╹◡╹๑) @tsuchie88
ところが、三オンのテーマにもなっているけど、この時代からバッチ処理は情報系にどんどん外出しして、勘定系はオンライン制御に特化する設計だった。時代を経るにしたがって、勘定系で持ってる機能を外部化していって、それらがオープン化されていくわけです。
(๑╹◡╹๑) @tsuchie88
例えば、90年代にはDWHが流行るんですけど、この時代くらいから情報系からDWHにデータを集めて営業系で使うようになったり、帳票出力処理も情報系でやるようになっていくわけです。
(๑╹◡╹๑) @tsuchie88
これが現代的にいうと、統合DBに一旦データを集めて、そこからDWHやら営業端末やら、チャネル系や帳票系にデータを変換して渡すみたいな仕組みにつながってるわけなんですよね。
(๑╹◡╹๑) @tsuchie88
逆の言い方をすると、勘定系に集中していた処理が、周辺系に機能が移っていって、負荷が重い処理とか、新規に開発するシステムは外部化されていったという感じになる。
(๑╹◡╹๑) @tsuchie88
二つ目なんだけど、新規開発の部分は極力Javaとかに置き換えられているという点。あまりいじらない基本的な機能はCOBOLのまま残しておいて、新規機能はJavaで作るという感じが増えてる。
(๑╹◡╹๑) @tsuchie88
銀行に限らず、業務基幹系システムを10年も維持すると、新規に投入するコード量は元のシステムの10倍くらいになったりすることもある。機能向上はなくても、法令改正対応みたいな不可避案件も多いのでこれは仕方がない。
(๑╹◡╹๑) @tsuchie88
そうすると、元のレガシーなコードを極力いじらずに、新規開発をCOBOL以外のコードで書いたり、プラットフォームにRDBやオープンシステムを使う形で、置き換えて維持する形態が生まれてくる。
(๑╹◡╹๑) @tsuchie88
もちろん、元のコードを全くいじらないというわけじゃなくて、新規開発部分で入出力をしやすいように、出力形式を標準化したり、コンテナ化、システム間接続にEAIを使ってインターフェースを統一するとかいろいろな工夫をやってる。
(๑╹◡╹๑) @tsuchie88
例えば、これは(10年くらい前の)三菱UFJ銀行の基幹系構成図なんだけど、EAI基盤を使って勘定系ホスト中心の垂直統合システムから、分散化されたシステムから標準化された通信手順で機能を呼び出すようなシステムに大きく変わっている。 pic.twitter.com/KwcgtsxacQ
 拡大
(๑╹◡╹๑) @tsuchie88
三つ目なんだけど、メインフレームの性能が向上したこと。90年代くらいまでは、メインフレームの性能は分散化されたオープン系と比べてしょぼかったんだけど、いろいろな要因でメインフレームの性能はかなり上がった。
(๑╹◡╹๑) @tsuchie88
例えば、IBM Zの最新機種のz14のケースでみると、1システムに搭載できるCPUは240CPUで、動作クロックは5Ghzを超える。並列シスプレックス接続すればクラスタリングでさらに性能を上げられる。
(๑╹◡╹๑) @tsuchie88
従来的なメインフレームのソフトウェアだけでなく、メインフレーム自体でJavaやRDBを稼働させても、性能的にオープン系よりも早いようなケースが多い。
(๑╹◡╹๑) @tsuchie88
しかも、メインフレームは、論理分割や仮想化が昔からあるので、例えばメインフレームの筐体を論理分割して、メインフレームOSとLinuxを走らせてメモリ上でデータ連携する(Hyper Socket)ような新しい使い方もできる。
(๑╹◡╹๑) @tsuchie88
以上の話を踏まえると、大手銀行で基幹系のクラウド化が視野に入っているというのはそれほど不思議な話じゃないんですよ。基幹業務が外部に切り出されて周辺化されていっていて、それらを稼働させるためのプライベートクラウドが既に存在している。
残りを読む(3)

コメント

倉瀬美都 @clausemitz 11日前
『残響のテロル』ってアニメのもじりだって何人が気づくんだよ。これ。OP曲は神がかっていて良いから、ぜひ聴いてほしい。
kartis56 @kartis56 10日前
この辺から進化すごいよね、そして前世紀と比べてストレージが大きく早くなったのもある >メインフレームの筐体を論理分割して、メインフレームOSとLinuxを走らせてメモリ上でデータ連携する
nekosencho @Neko_Sencho 6日前
考えてみりゃ、パソコンなんて存在しなかったころからいろいろ積み上がってきてるんだもんな。
ログインして広告を非表示にする
ログインして広告を非表示にする