富士通メインフレームの本質を見る~2008年度の最新トピックス

第3回 GSのメタボ化

概要

FUJITSU FORUM 2008が5月16、17日に東京国際フォーラムで開催されました。富士通メインフレームの今後を語るセミナーには100名以上の方が聴講し、今年も好評のようでした。ここでは、発表内容の裏にある本質を探り、考察を進めていきます。

 2008年7月、あるSE会社の研修会で、社外講師としてGSのメタボ化について講演をしました。今GSで何が起きているのか、今後も使い続けるときのポイントは何か、お客様の目線で紹介したいと思います。

 

などについて説明しました。第5回は、具体的な品質管理を実業務へどのように組み入れるかについて説明します。

 

目次
3.1 GSの強みと現状認識
3.2 GSのメタボ化

3.1 GSの強みと現状認識

 第1回で紹介したようにGSの次々機種エンハンス(2013年頃)が公表され、今後もサポートしていく旨の主張に説得力が出てきました。GSを使い続ける理由としては、
    • ハードウェアの高信頼、高品質
    • 安定した性能
    • アプリケーション資産の継承
が上位になると思います。
 実際、ハードウェアが壊れたという話しは最近聞いたことがありません。しかし、業務アプリケーションの暴走や運用ミスによるトラブルはどうでしょうか。
 
 表1は、私自身が性能コンサルティングの現場で直面したトラブル事例をまとめたものです(2006年上期)。いずれも、社会システムや基幹システムですが、数ヶ月間適切な対策がとられていないものもありました。いずれも「GSのメタボ化」が影響していると考えられます。
表1 トラブル事例
 

3.2 GSのメタボ化

外のメタボと内のメタボによりシステムが膨張している状態をGSのメタボ化と定義します(図1)。各々について説明します。
 
 (1) 外のメタボ(過剰投資)
 図1左(理想形)に示すように、システム構築時には機能実現に必要なリソース量(rとする)が見積もられ、そこからハードウェアの大きさ(xとする)が決定されます。リソースにはCPU、メモリ、I/O装置等がありますが以下はCPUについて説明します。
 
 GSはWebシステムと違い業務量を予測しやすいので、CPUの大きさxは余裕をみてもr<x<2rくらいになります。(2rとは余裕を見て2倍の大きさにする意味)
 
 4~5年ごとにリプレースされるとすると、次期システムのCPUは業務量の増加がなくても1.3x前後となります。これを移行パスといいます。リプレースを2回行えば1.7x、3回行えば2.2xとなります。丁度よい大きさのCPUモデルがないときには1.3倍以上になることもあります。
 
 業務が追加されると、その分のCPUレベルアップは提案されますが、業務が削除されてもCPUをダウングレードすることはほとんどありません。
 
 業務量が増加しているときはこのやり方でも良かったのですが、減少傾向になると必要なCPU量r’<rが減少し、r’と1.3x, 1.7x, 2.2x, ・・・の差が拡大します。このように、必要以上に大きなハードウェアを導入している状態を外のメタボと言います。
 
 実際、CPUを30%程度しか使っていないシステムも珍しくありません。GSはオープン系のサーバとは違い、CPU使用率が100%に近づいても安定して動作します。GSのコスト削減のヒントがここにあります。
 
図1 GSのメタボ化
 
(2) 内のメタボ(リスク)
 ソフトウェアがシステムの信頼性や安定稼動を阻害する可能性がある状態を内のメタボと言います。
 
 品質の悪い業務プログラムを例にすると、機能実現に必要なリソース量rに対し、実際にはR(2r<R、2倍以上)のリソースを使っているケースがあります。リソースの無駄遣いかつ性能の悪化です。これは、単体レベルの性能検証がされていないことが根本的な問題です。稼動後にこのようなケースの検出は困難でしたが、CPU/IO頻度分析などでその検出が可能となりました。
 
 
 (3) GSのメタボの例
  【外のメタボの例】
 
CPUとDASD構成がアンバランスなシステム
  ⇒ CPU能力と処理できるI/O回数は比例する
性能上、運用上意味のないハードウェアを増強した
  ⇒ 何の評価もせずに、遅いからCPUやメモリを増強するケース
使われていないリソースがある
  ⇒ SSU(システム記憶)やメモリなど搭載しすぎているケース
  【内のメタボの例】
 
異常に重いアプリケーションが動き、リソースを使い切ってしまう
  ⇒ 表1のCPUループなど
大きなリスクに気づかないままシステムを運用している
  ⇒ ログの設計、リカバリテストが不十分なケース
遅い処理に慣れてしまっている
  ⇒ 遅すぎるオンライン業務を使い続けているケース
 メタボは病気ではないので直ぐにトラブルを誘発するものではありません。しかし、GSがこれからも価値を生み続け、進化していくためにはシステムが健康であることが重要だと考えます。
 
3.3 GSのメタボ診断のポイント
 
 (1) CPUとI/Oのバランス(CPU/IO頻度)
 人のメタボ診断ではまず腹回を測定しますが、GSのメタボ診断ではCPUとI/Oのバランスを測定する必要があります。CPU/IO頻度分析では標準値が20~40になるように算出されています。図2の例を使って説明します。
従来の性能評価は業務量の右肩上がりが前提なので、メタボ診断は「右肩下がりの性能評価」とも言えます。
 
 
 (3) 効果
 ブラックボックス化するシステムの稼動状況が、客観的かつわかりやすく見える化されます。
 
 メタボ診断の結果から気づきを生み、知恵を出しあい、GSシステムの5年後10年後をデザインして頂ければと思います。
 異常が検出されたときは詳細な診断(精密検査)を受けることをお勧めします。原因を必ず判明できるのがGSの強みでもあります。
 
 2008年度の最新トピックスをCPUのエンハンス、IT全般統制、メタボ化の視点で3回にわたって紹介しました。今、PRIMEQUEST 520Xの性能分析を行っていますが、新しい情報は随時お知らせしたいと思います。
 
以 上

連載一覧

コメント

筆者紹介

有賀 光浩(ありが みつひろ)

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

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回にわたり掲載。

バックナンバー