スキル

グローバル企業はどのようにメインフレームのキャパシティ危機を解決しているのか:3つの実例 

大手企業は、ソースコードを一切変更することなく、バッチCOBOLのCPU使用量を最大97%削減しています。先進企業がどのようにピーク負荷を管理し、キャパシティを取り戻し、競合を解消しているのか──シームレスなワークロード再配置による最新の手法をご紹介します。

私たちは毎日、大量のものを管理する固有の課題についてお客様と話しています メインフレーム 効率とコスト抑制が最優先される環境において、容量の懸念は常に高いとは限らないことを私たちは理解しています。 ワークロード ワークロードの量、同じリソースの同じウィンドウに過負荷が集中しすぎているということです。 

リソース競合が発生するのは、次のような場合です。 

JOPAZ 重いものを再分配して天秤を再均衡させる COBOL バッチワークロードをより効率的なエンジンに移行し、アプリケーションに触れることなくピーク時の動作を変更します。 

何が変わるのか? 実行パス、CPUの動作、および実行時環境JVM

何がそうでないか: COBOLソースコード、データ、スケジューリングフレームワーク、および出力 

以下では、異なる業界の3つの主要企業が、競合問題を根本的に解決しつつ、いかにして驚異的なCPUリソースの削減を実現したかについて見ていきます。 

1. 会員サービス組織:R4HAのピーク問題の解決 

北米の大手会員制サービス組織(自動車、旅行、金融サービスを提供)にとって、予測可能性の創出は最優先事項でした。 バッチ処理 ローリング4時間平均(R4HA)コストが上昇しており、ワークロードのより良い分散が急務となっています。 

戦略:

同組織は、ワークロードの競合の根本原因に対処するため、JOPAZに協力を求めた。 

  • COBOLバッチソースコードをJavaバイトコードにコンパイルしました 
  • そのコードは Unix System Services 上の JVM で実行されました 

これにより、IBMを活用できるようになりました ジーアイピー エンジン、GPピーク圧力を実行を再分散することにより低減 

セットアップ: 

結果:

その影響は即座かつ甚大であった。 

JOPAZなし 

  • CPU時間 47.96秒 

JOPAZ 使用時 

  • CPU 時間 2.47 秒(95% 削減) 
  • バッチ COBOL の CPU 使用量を 94.84% 削減 
  • 新たなワークロード向けに MSU を再確保 
  • 元のソースコードには一切変更は必要ありませんでした。 

2. 小売エネルギー事業者:効率化への投資

大規模な Db2 基盤を抱える北米の大手エネルギー供給事業者は、既存の処理リソースをより戦略的に活用する方法を必要としていました。

戦略

最初の事例と同様に、この顧客もバッチ COBOL を zIIP エンジンで実行可能にするため、JOPAZ を採用しました。今回のケースでは、当初 JOPAZ が利用できる zIIP の空き容量が限られていたため、初期結果が成功を収めた後、2 台目の zIIP が追加されました。

セットアップ:

  • COBOL Db2 環境
  • 3 つのバッチ処理を使用しました。これらの各バッチ処理には Db2 にアクセスする COBOL プログラムが含まれており、さらにそれぞれ複数のステップで構成されていました。

結果

JOPAZなし

  • CPU時間 2分26秒27
  • 処理時間 14 分 10 秒

JOPAZ 利用時:zIIP エンジン 1基

  • CPU 時間 14.4 秒(90% 削減)
  • 処理時間 5分44秒(60%削減)
  • バッチ COBOL の CPU 使用量を 76% 削減

JOPAZ搭載 – zIIPエンジン2基

  • CPU 時間 6.97 秒(95% 削減)
  • 処理時間 8分40秒(39% 減)
  • バッチ COBOL の CPU 使用量を 96.7% 削減

初期テストの結果が非常に有望だったため、顧客はプロジェクト完遂に向けて即座に専任リソースを投入することを決定しました。何よりも重要なのは、コードやビジネスロジックを一切変更することなく、この成果を実現できた点です。


3. 決済テクノロジー企業:複雑性と VSAM への挑戦

南米では、大手決済テクノロジー企業が年間数十億件の取引を処理しています。他の例とは異なり、これは純粋な VSAM 従来のデータベースがない環境で、例外的に大規模で複雑なアプリケーションが特徴でした。

戦略

ラック内には十分に活用されていない zIIP プロセッサが 4 基も搭載されていたことから、同社は JOPAZ を GP キャパシティ回復の最適解と捉えました。まずは 5万4千行に及ぶ複雑なプログラムを再コンパイルするところから着手しました。顧客の言葉を借りれば、『このアプリケーションを JOPAZ が処理できるなら、どんなアプリケーションでも処理できる』ということです。

セットアップ:

  • 全体のワークロードの 35% を COBOL バッチが占めています
  • 従来型データベースを一切使用しない、純粋な VSAM 環境
  • 十分に活用されていない zIIP プロセッサが 4 基存在

結果

  • バッチ COBOL の CPU 使用量を 97% 削減
  • 既存のメインフレーム環境からより多くのキャパシティを引き出し、ROI を最大化
  • 業務に一切の中断を発生させることなく、通常どおりの運用を維持

結論

お客様も証明されているように 近代化 クラウドへのリスクを伴う長年の移行である必要はありません。課題はCOBOLが機能するかどうかではありません。それは、少数のジョブがクリティカルなウィンドウ中に不均衡なプレッシャーを引き起こしているかどうかです。ワークロードを変更する(書き換え、スケジュール変更、削除)のではなく、企業は実行場所を変更することで、バッチCOBOL CPU使用率のほぼすべてを取り戻しています。

Db2、VSAM のいずれをお使いの場合でも、 Adabas、あるいはシーケンシャルファイルの場合でも、実績のあるビジネスロジックをそのまま維持したまま、CPU使用率を80%以上、多くの場合97%もの大幅な削減を実現しています。