【IT】COBOLをサーバーレスへ アクセンチュアの新マイグレ策
■ このスレッドは過去ログ倉庫に格納されています
アクセンチュアがCOBOLアプリをサーバーレスで稼働させるマイグレーションサービスを発表。仏ブルーエイジ(Blu Age)と共同で2019年7月からサービスを開始した。
COBOLプログラムを稼働させるハードウエアの保守・運用には多大なコストが発生するのが一般的だ。だが、クラウド基盤の活用によって、この状況を改善できる可能性が出てきた。例えば仏ブルーエイジが手掛けている「Serverless COBOL for AWS」の利用だ。国内ではアクセンチュアが同サービスを使ったマイグレーションサービスを開始した。
Serverless COBOL for AWSは、「AWS Lambda」を使って既存のCOBOLシステムをサーバーレス環境で動かすサービスである。サーバーレス処理は、プログラムが稼働するときだけサーバーが立ち上がるので、コスト効率に優れている。ブルーエイジのティエリ・マソン シニアソフトウエアアーキテクトは、「サーバーレスに移行できれば、メインフレームの保守・運用に費やしていたコストを8割削減できる」と話す。
バイトコードにリコンパイル
Serverless COBOL for AWSは、COBOLプログラムをJavaバイトコードにリコンパイルし、AWSLambda上のJavaランタイムで実行する(図1)。
利用するには、COBOLプログラムの移行箇所の特定やその影響範囲を判断するため、ブルーエイジのアナライザーを使ってプログラムを解析する。その後、コードエディターのVisual Studio Code(VSCode)の拡張機能を使い、Javaバイトコードにリコンパイルする。
VSCodeの拡張機能やCOBOLコンパイラーはブルーエイジが開発した。コンパイラーはブルーエイジがクラウド上に配備している。VSCode上でコンパイルの処理を指定すると、クラウド上で実行し、開発者にコンパイル後のJARファイルを送る仕組みだ。
そして、開発者がJARファイルをデプロイ(配置)してAWS Lambda上で実行する。マソン氏は「多くの場合は、COBOLプログラムを書き換えることなく、リコンパイルするだけでそのままAWS Lambda上で動く」と話す。
ただし、Serverless COBOL for AWSの利用には注意点がある。処理時間に上限があるAWS Lambdaは、「長いトランザクション処理などは苦手」(マソン氏)という。このような処理は、COBOLプログラムの分割やリライトといった変更が必要になるだろう。さらにリコンパイル後のプログラムの実行では、LambdaがJava実行環境を立ち上げる。初回実行時は処理に時間がかかることに注意が必要だ。
アクセンチュアのテクノロジーコンサルティング本部 インテリジェントソフトウェアエンジニアリングサービス グループ 中野恭秀アソシエイト・ディレクターは「プログラムの規模や複雑性によってはAWS Lambdaへの移行ではなく、リホストが向く場合もある。企業のCOBOL資産の特性に合わせて最適なマイグレーション方法を提案していきたい」と話す。
https://tech.nikkeibp.co.jp/atcl/nxt/mag/sys/18/022800004/080600073/ つまりDBのアクセスが必要な処理には向かないってことじゃん 基幹業務の業務標準化を受け入れられず、社内独自のやり方に固執する日本企業
非効率と高コストの温床 オンラインはともかくとして、バッチ処理はどうするんだろう? COBOLのトランザクションって性質上だいたい長くないか
デイリーでバッチ回すところも当然多いだろうし、8割カットできるものなんかね? トランザクション処理、つまりはオンラインでの対話処理に向いてないって事。
オンラインでの対話処理はユーザー画面に何かを送って、その応答を待つからな。その間、基本的はプログラムは常駐しっ放しになる。
コンピューターの世界ではユーザーレスポンスなんてのは永遠に近いくらい遅い。
逆に得意なのはプログラム処理だけで全てが終わる処理、つまりはバッチ処理。
って事だろ。 こういうのはさ、日立とか富士通、日電がアマゾンと組んでやれよ
もう自社ハード売って存続できる状況じゃないだろ
独自アーキテクチャの差異を吸収できるようにするだけで既存客そのまま取り込めるんだから、変なシステム提案するよりずっといいぞ >>5
処理できませんでしたで許されるようなところばかりじゃないんで、実績に偏重するのは致し方ない >>1 の最後にあるけど、これで釣っておいて、リホストに誘導するのでは? 「昨日、お客様の口座に3億円振り込まれた?
あー!確かに振り込み元の銀行のログに残ってましたー。
申し訳ございませーん。3億増やして置きますんでー。
それでは失礼しまーす。」
じゃあ済まないものな。 >>7
8割削減は、「移行できれば」の話
ホストより、その下のオフコンクラスのリプレースに使えるかどうか
AS400のリプレース狙いだったりして 問題は何年使えるかや
2年末おしまいしゃんしゃんってやられたらどうする >>13
IBMで思い出した
政府システム調達失敗のあそこか COBOLがどうのじゃなくて汎用機とPCサーバーの関係じゃないのか? この手の話って経験上99%誇張だからな
言ってる方も聞いてる方も実はよくわかってるwww 社内の長老が「COBOLは自作コンパライラ製と言う南斗聖拳や、アセンブラと言う北斗神拳がある」といつも言うがそんなのも移植出来るのか? 仕様も実装も古すぎてよく判らねーからエミュレーションしてごまかそう サーバーレスってwww
サーバーなかったら動かないwww 複雑なトランザクションができないCOBOLなど飛べない豚と同じで役立たず アクセンチュアに反応する人ゼロかw
「御社のシステムはカスタマイズが必要となりますので、再見積もりが必要です」 転用が効かない、他に使いみちの無いCOBOL専業PGの救済目的かね。 >>30
VSCodeに慣れさせて、転用支援…ではないかw 高校でCOBOLは教えてくれたけど
JCLは教えてくれなかった つまんねー仕事
マイグレした結果、数値計算合わなくなりましたーとか言ったら笑う >>32
取り敢えずENV...DEVは講師が指定したものを書け!という初期指導方法は悪くないと思うがなあ。
COBOLで書く事の訓練には不用だし、情報処理二種の午後対策なら無用の知識だったし。
80年代中盤のIBMスパイ事件が大騒ぎにならなきゃ、JCLはメインフレーム各社共通だったかもな。
しかしアクセンチュアの中の人も
「動作環境規模によりリホスト必要」
と断ってんのな…書くだけマシとは言え、ここからもう一歩踏み込まないのが日経BPらしい記事ではある。 メインフレームをオープン化すれば保守費用が浮くってコンサルタントの口癖 >>35
システムは稼働して久しいんだし、
コンサル費用浮かす方がよっぽど節約になる気がする。 >>9
日本企業は提案する側される側も >>10 止まり
移行によって発生するかもしれない問題をピックアップして
検証することすら出来ないレベル
IT後進国は舐めてはいけない アクセンチュアで仕事したら
COBOLの開発は中国に丸投げしていて
びっくらこいた。 >>8
サーバレス特化したプログラムだと、応答を待つんじゃなく別のプロセスとして処理するように書くんだが
昔のプログラムそのままじゃ辛いだろうね ■ このスレッドは過去ログ倉庫に格納されています