運用ノウハウを学ぶ

システム管理に関わるベーシック情報やトレンドをご案内します!

富士通メインフレームの本質を見る~2008年度の最新トピックス 第3回 GSのメタボ化
2008年08月20日 14:03

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

3.1 GSの強みと現状認識
 第1回で紹介したようにGSの次々機種エンハンス(2013年頃)が公表され、今後もサポートしていく旨の主張に説得力が出てきました。GSを使い続ける理由としては、
    • ハードウェアの高信頼、高品質
    • 安定した性能
    • アプリケーション資産の継承
が上位になると思います。
 実際、ハードウェアが壊れたという話しは最近聞いたことがありません。しかし、業務アプリケーションの暴走や運用ミスによるトラブルはどうでしょうか。

 表1は、私自身が性能コンサルティングの現場で直面したトラブル事例をまとめたものです(2006年上期)。いずれも、社会システムや基幹システムですが、数ヶ月間適切な対策がとられていないものもありました。いずれも「GSのメタボ化」が影響していると考えられます。
表1 トラブル事例
image007.PNG
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のメタボ化
080820_1.png
(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の例を使って説明します。
image008.PNG
図2 CPU/IO頻度分析の例
 Aはほとんどの点が20~40(縦の2つの線)の間にありバランスのよいシステムです。Bは0~80まで分散しておりバランスの悪いシステム、Cは0~20の間にありI/O頻度が高いシステムです。B、Cの原因は詳細な診断で判明します。同じCPU使用率でも、I/O頻度が高いシステムとCPU頻度の高いシステムでは評価結果は異なります。


 (2) 性能評価との違い
 GSのメタボ化は、従来の性能評価やキャパシティプランニングの手法では検出することはできません。メタボ診断との評価結果の違いを表2に示します。
表2 性能評価とメタボ診断の違い
image009.PNG
従来の性能評価は業務量の右肩上がりが前提なので、メタボ診断は「右肩下がりの性能評価」とも言えます。


 (3) 効果
 ブラックボックス化するシステムの稼動状況が、客観的かつわかりやすく見える化されます。

 メタボ診断の結果から気づきを生み、知恵を出しあい、GSシステムの5年後10年後をデザインして頂ければと思います。
 異常が検出されたときは詳細な診断(精密検査)を受けることをお勧めします。原因を必ず判明できるのがGSの強みでもあります。

 2008年度の最新トピックスをCPUのエンハンス、IT全般統制、メタボ化の視点で3回にわたって紹介しました。今、PRIMEQUEST 520Xの性能分析を行っていますが、新しい情報は随時お知らせしたいと思います。

以 上
運用研究レポート
富士通メインフレームの本質を見る~2008年度の最新トピックス

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

記事一覧へ
筆者紹介

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



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

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

コメントを書く
コメントを書く

未ログイン: ログインする

コメント: ログイン(会員登録)すると、コメントを書き込むことができます。

  • 新着Q&A
  • 最新の回答

システム管理者認定講座<全コース共通>試験のみ受験希望の方はこちら

動画で見るセミナー
動画で見るセミナー

こちらは、システム管理者認定講座の認定試験の受験のみ希望される方の申込みページです。 システム管理者認定講座のアソシエイト(初級)、バチェラー(中級)、マスタ

個人情報保護方針
運営者につい て
利用規約
サイトマップ