富士通メインフレームの本質を見る～CPUリプレースの考え方

第1回　移行パスと性能管理の現状

概要

御社ではメインフレームの性能評価や性能見積りをして機種選定をしていますか？ 「富士通メインフレームの本質を見る」の第２弾として「CPUリプレースの考え方」について解説します。第１回は移行パス（見積り不要の機種選定方法）が生まれた背景とその内容について考えます。

目次
１．１　メインフレームの市場動向
１．２　移行パスという考え方
１．３　富士通メインフレーム特有の性能管理

１．１　メインフレームの市場動向

４～５年前、メインフレームは無くなるのではという議論が活発でしたが、結局どうなったのでしょう。 　(社)電子情報技術産業協会(JEITA)の調査によると、国内メインフレームの出荷台数、金額は表１のように推移しています。2006年度は10年前と比較すると、出荷台数は70%減、金額は80%減まで大幅に縮小しています。

 

表１　メインフレームの国内出荷台数・金額
　 IBMはメインフレームのオープン化を進めて見事に復活し、ワールドワイドで売上もシェアも着実に延ばし一人勝ちの状況です。 その間、富士通は有効な対策は打ちませんでした。それでも現在3,000以上のお客様でメインフレームは使われており、今後も高度な信頼性を要求される社会インフラと位置付け、2009年度には次期エンハンスを計画していると公表しています。 現在メインフレームを使っているお客様の今後の動向は図１のように考えられます。
 
図１　メインフレームの動向
しばらくは再リースをして様子を見る。
オープン化が進み、CPUをダウングレードする。
複数台保有しているので、CPUを統合する。
オープン化が完了したのでCPUは撤去する。
　 このような状況下で、今使っているメインフレームのリプレースをどうすればよいのか、皆さんと一緒に考えていきたいと思います。
 
 

１．２　移行パスという考え方

◆解説
 
　私の予想･･･いずれも可能性がありますが、①が10%、②が45%、③が45%くらいに分かれるのではないでしょうか。 
　メーカとしての正解は③です。私がユーザなら①を期待します。
　依頼を受けたメーカの担当者は、現状の性能評価をする／しないの選択肢があります。 現状の性能評価をせず（実際はこれがほとんどです）、リプレース後に性能問題を起こさないためには、新しいCPUに最低でも20%の余裕値が必要となります。これが移行パスという概念の基礎となります。 
　 ②のように同等のCPU性能（10→10）にリプレースをすると、多くのお客様（メーカの担当者も）は処理が遅くなるとは思っていないでしょう。CPU時間で考えると、私の経験上2割が短縮（速くなる）、2割が遅延（遅くなる）、6割が不変、増減の幅は±約20%、平均して同等性能ということになります。これはCPUとメモリの特性によります。 
　 最近のバッチ処理時間はメインフレームであってもCPU時間の比率が大きいため、運悪くクリティカルなジョブが遅延すると性能問題となります。②のようなケースでは移行前の性能データが残っていないことも多いので、事実を特定することさえむずかしく、問題解決までには長い時間を要します。 
　 ①では、メーカの担当者もお客様自身も遅くなるリスクを想定し、処理遅延が起きても何とか改善していこうと決意していることを期待します。「業務上問題がない処理なら少しくらい遅くなってもいいじゃないか」という割り切りも必要です。 
　 ①、②で性能悪化というリスクをコントロールするには、現状の性能評価と改善、性能予測が有効です。メーカは「性能問題が起きても一切責任を取りませんよ」と念を押すことでリスクを回避しようとしますので、お客様主導で性能評価から進めるしか実際には手がありません。
 
◆移行パスの本質とは
 
　移行パスというのは、メーカ視点で性能問題を未然防止するための仕掛けでした。
　10年前であればメインフレーム上での処理量も増加していたので、ＡというCPUはＡ’以上にリプレースせよという発想は良かったと思います。しかし、１．１で紹介した通り環境は大きく変わり、お客様のニーズとのミスマッチが生じています。
　これに対して、何もしなかったことが結果的にメーカの戦略となったと考えます。メーカとしては移行パスに合わない高リスクのリプレースを推進するより、再リースをしてもらった方がメリットがあるのではないでしょうか。そういう意味では、移行パスはメーカの利益分岐点と考えるとわかりやすいかもしれません。
 
 

１．３　富士通メインフレーム特有の性能管理

◆解説 

　 性能管理手法も10年前とは大きく変わっています。標準的な性能管理の手法をメインフレームに適用しても多くのお客様では効果は期待できない可能性があります。その理由を簡単に説明します。

    1. パフォーマンス管理（短期的な管理）について

ハードウェア性能が著しく向上したため、従来の指標値（例．CPU使用率80%）との比較では問題の本質が見えてきません。ここ数年の傾向として、アプリケーションの性能品質の評価が重要といえます。性能品質については「富士通メインフレームの本質を見る～バッチ処理の性能評価と改善事例から」の第1回、第４回などで詳しく説明しています。

    1. キャパシティ管理（長期的な管理）について

多くのメインフレームでは業務量が減少しています（右肩下がり）。即ち、CPUをダウングレードする方法論が確立されていないと、現実的な効果は期待できません。CPUのダウングレードについては次回説明をする予定です。

    1. OS、ミドルウェアについて

業務量の増加ではなく、アプリケーションの性能品質の問題により、OS、AIM、DBMSの内部にボトルネックが発生しやすくなっています。この評価をせずに安定した性能は望めません。

    1. 性能管理をしないもまた真である

移行パスに従っていれば性能管理は不要でもあり、性能管理をしないから移行パスができたとも言えます。ほとんどのお客様は性能管理をしなくても（表面上）問題なく運用しています。

◆性能管理の本質とは

　 目的を明確にして、性能評価プロセスを回すことです。CPUのダウングレードを目指しているなら、性能品質の評価は重要になります。
　 性能評価プロセスは、http://www.ibisinc.co.jp/colum0601.htmに解説しています。
　 将来的には、性能管理と内部統制のIT統制が融合していきます。これも機会があれば紹介したいと思います。

以　上

連載一覧

コメント

筆者紹介

有賀　光浩（ありが　みつひろ）

株式会社アイビスインターナショナル　代表取締役

1963年生まれ。1985年富士通株式会社入社。1992年～2003年まで社内共通技術部門で国内外のメインフレームの性能コンサルティングを実施、担当したシステム数は1,000を超える。2000年からは大規模SIプロジェクトへの品質コンサルティング部門も立ち上げた。

2004年に株式会社アイビスインターナショナルを設立。富士通メインフレームの性能コンサルティングとIT統制コンサルティングを行っている。

技術情報はhttp://www.ibisinc.co.jp/で公開中。富士通やSI’erからのアクセスが多い。

当サイトには、同名シリーズ「富士通メインフレームの本質を見る～IT全般統制の考え方」を3回、「富士通メインフレームの本質を見る～バッチ処理の性能評価と改善事例から」を6回、「富士通メインフレームの本質を見る～CPUリプレースの考え方」を3回、「富士通メインフレームの本質を見る～性能改善の現場」を7回、「富士通メインフレームの本質を見る～2009年度の最新トッピックス」を3回、「富士通メインフレームの本質を見る～2008年度の最新トピックス」を2回にわたり掲載。

バックナンバー