|
| ８．メインフレームだからできる「CPUのムダとり」手法 （FUJITSUファミリ会 2010年投稿論文） 論文要旨 GS初である「CPUのムダとり」手法を確立し、お客様の本番システムで効果をあげている事例を紹介する。 高信頼が強みであるGSでも性能品質の悪化が進んでいる。 運用中のシステムに性能品質を作り込んでいくには、リプレース時の①性能予測、運用時の②GSメタボ診断、③CPUのムダとりの ３点がポイントである。 CPUのムダとりは12項目からなる性能評価プロセスに従って実施する。 改善のターゲットはユーザアプリであり、改善作業はお客様が行ない、私どもは支援をする。 工夫点は、①CPUのムダが一目で見える仕組み（CPU/IO頻度分析）、②CPU時間の削減予想、③プログラム内の問題を見つけ出す手法 （詳細分析＋ヒアリング）、④お客様が改善したくなる場作りである。 ムダは想像以上にたくさん存在している。 CPUのムダに関するリテラシーを高め、オープンシステムにも展開していきたい。 論文目次 １．はじめに １．１ 当社概要 １．２ 背景 ２．性能品質の作り込み ２．１ 理想的な性能品質の作り込み ２．２ 新・GS性能品質の作り込み ３．CPUリのムダとり手法 ３．１ 性能評価プロセス ３．２ CPUのムダとりのステップ（見える化） ３．３ CPUのムダとりのステップ（原因分析～改善） ３．４ GSだからできるCPUのムダとり ４．CPUのムダとり事例 ５．評価と課題 本編 論文はメンバー専用のページに公開中です。 ↓↓↓
（FUJITSUファミリ会 2008年投稿論文） ※よくわかるGSセミナー 「GSのメタボ化とその診断手法」 論文要旨 GSからGSへCPUをリプレースするとき、CPU能力を２～３割あげることが慣例だった。 最近では、コストを抑えるためにCPU能力を低下（ダウングレード）させる要望が増えている。 しかし、現場では未だ長年の経験と勘に頼っていることが多く、性能問題を起こしていることもある。 昨年発表したGSメタボ診断はお客様システムでの実践を重ね、メタボの検出からCPUダウングレードの実現性を検証する ツールとして変化を遂げた。 この過程で、GSのリプレース難易度チェックシートが完成し、後にCPUダウングレードを実現するプロセスを確立した。 具体的には、初めに３つの簡易的な検証を実施する。 ３つとは、①CPUの余裕度、②ダウングレード後の性能予測、③リスク評価である。 ダウングレードが現実的であると判断されれば、次に３つの本検証と改善が行われる。 本論文では実例を使い検証方法を紹介している。 CPUリプレースに関するリテラシーを高め、お客様の満足度を高めていきたい。 論文目次 １．はじめに １．１ 当社概要 １．２ 背景 ２．GSメタボ診断の効果 ２．１ はじめに～Ｘシステムの稼動状況 ２．２ CPU/IO頻度分析の活用事例 ２．３ オンライン処理の稼動状況 ２．４ バックアップ・リカバリ運用 ３．CPUリプレースの考え方 ３．１ GSリプレースの難易度 ３．２ CPU性能と能力の違い ４．CPUダウングレードを実現するプロセス ４．１ CPUの余裕度 ４．２ ダウングレード後の性能予測 ４．３ リスク評価 ５．評価と課題 本編 論文はメンバー専用のページに公開中です。 ↓↓↓
（FUJITSUファミリ会 2008年投稿論文） ※よくわかるGSセミナー 「GSのメタボ化とその診断手法」 論文要旨 富士通メインフレームGSの「メタボ化」が進行し、長年築いてきたお客様の信頼を損なう危機に直面している。 GSのメタボとは、外のメタボ（過剰投資）と内のメタボ（リスク）によりシステムが膨張している状態と定義する。 外のメタボとは必要以上に大きなハードウェアを導入している状態、内のメタボとはソフトウェアが必要以上のリソースを 使用、またはシステムの信頼性、安定稼動を阻害する可能性がある状態をいう。 従来の性能評価ではGSのメタボは検出できず、メタボ診断の手法を構築した。ポイントはCPUとI/Oのバランス （CPU/IO頻度）の診断とメモリの使用状況からのシステム特性の診断であり、６システムの実例を使って紹介し 考察する。診断はあくまで手段であり、お客様によりよい価値が提供できるよう改善するのが目的である。 メタボに関するリテラシーを高め、満足度向上の取組みを推進していきたい。 論文目次 １．はじめに １．１ 当社概要 １．２ 背景 ２．GSのメタボ化 ２．１ GSのメタボの定義 ２．２ GSのメタボの例 ３．性能評価の限界 ３．１ 従来の性能評価例 ３．２ 右肩下がりの性能評価 ４．CPUとI/Oのバランスと診断手法 ４．１ CPUバウンド・I/Oバウンドとは ４．２ CPU/IO頻度という考え方 ４．３ CPU/IO頻度による診断 ４．４ CPU使用率との関係 ５．メモリによる診断 ５．１ 従来の性能評価 ５．２ 仮想メモリによる診断 ５．３ 実メモリによる診断 ６．サービスレベルの把握 ７．考察 ７．１ メタボ診断の効果 ７．２ 改善へのアプローチ ８．評価と課題 本編 論文はメンバー専用のページに公開中です。 ↓↓↓
（FUJITSUファミリ会 2007年投稿論文） 論文要旨 多くのメインフレームは長年、性善説に立ったシステム開発、運用管理を行っている。本番環境と開発環境が同一 システムに混在し、ID管理を行っていないケースも非常に多い。2006年末から、メインフレームで内部統制を構築する ための問題点を整理し、富士通をはじめ各部門の方々とも意見交換や情報共有を行ってきた。 内部統制の当事者のほとんどはメインフレームを知らない現実の中で、「メインフレームの特徴を生かしたIT全般統制 （ITGC）」を実現するには、システムの稼動状況の見える化が有効である。これによりリスクを網羅的に検出するとともに 権限を持ったシステム管理者の透明性を高めることが狙いである。 事例を通して見える化の手法を紹介するとともに、ITGC構築のポイントを考察する。統制はすべてを自動化（IT化）する 必要はなく、本来の目的を理解し、人間系も使って対応していくことが重要である。 論文目次 １．はじめに １．１ 当社概要 １．２ 背景 １．３ 論点 ２．ITGCから見たメインフレームの現状 ２．１ セキュリティレス・統制レスのシステム ２．２ 把握できていないシステムの運用状況 ２．３ RACFに対する誤解 ３．システムの稼動状況の見える化（事例） ３．１ ジョブの稼動状況 ３．２ TSS/AIFの稼動状況 ３．３ オンライン業務の稼動状況 ３．４ プログラム、ユーティリティの使用状況 ３．５ データベース、データセットのアクセス状況 ４．ITGC構築のポイント ４．１ システムの開発・変更、保守 ４．２ システムの運用・管理 ４．３ システムの安全性の確保 ４．４ 提言 ５．評価と課題 本編 論文はメンバー専用のページに公開中です。 ↓↓↓
４．メインフレーム改革！ 性能品質向上への挑戦 － CPU統合の見える化と改善 － （FUJITSUファミリ会 2006年後期投稿論文） ※よくわかるGSセミナー 「CPUリプレースの考え方」 論文要旨 メインフレーム上で、システムの性能品質の悪化が進んでいる。2007年問題とは関係ない。やるべきことをやって いないだけである。問題の本質を見極め、基本に忠実に対応することが今求められている。新・性能評価プロセスの 実践が重要となる。 CPUのダウングレードとともに、CPU統合のニーズが増えてきた。そこで、CPU統合プロセスを見える化し、CPU見積り 手法「CPU能力積上げ方式」の考察と、３つの性能品質問題について事例を使って紹介する。 ① AVM（仮想化）を使うと、ジョブの処理時間が不安定になることの分析と対応 ② ブラックボックス化したシステム環境への対応 ③ 性能品質の悪いアプロケーション（CPUループが頻発）への対応 前回の論文と合わせて、性能評価プロセスの見える化手法も一通り完成した。この取組みは性能品質の向上だけで なく、今後内部統制とも密接に関係してくるので一日でも早い着手をお勧めする。 論文目次 １．はじめに １．１ 当社概要 １．２ 背景 １．３ 論点 ２．CPU統合の現状と問題点 ２．１ CPU統合プロジェクトの現状 ２．２ あいまいなCPU選定 ３．性能評価事例 ３．１ 不安定な処理時間 ３．２ ブラックボックス化したシステム環境 ３．３ 性能品質の悪いアプリケーション ４．評価と課題 本編 論文はメンバー専用のページに公開中です。 ↓↓↓
３．メインフレーム改革！ お客様視点・現場重視の性能評価 － ３割のコスト削減・性能向上・満足度向上運動 － （FUJITSUファミリ会 2006年前期投稿論文） ※よくわかるGSセミナー 「有賀式－性能評価手法」 論文要旨 メインフレーム変革！ レガシーだ、コスト高だと言われ放題のメインフレームだが、信頼性、運用性をはじめ優れた サーバであると私は評価している。 10年後もメインフレームを安心して使い続けて頂くために「３割のコスト削減・性能向上・満足度向上（通称Triple３） 運動」を開始した。中核となる性能評価はよくわからない、むずかしいと昔から指摘を受けており、お客様視点・現場 重視に変えることが最優先課題であると考え、次の３点に取り組んだ。 ① 性能評価プロセスの透明化 ② 徹底した見える化 － CPU/ＩＯ頻度分析など見える化ツール群の開発 ③ 原因分析サイクル、改善サイクルのスピードアップ 運動は始まったばかりだが、性能品質を向上させながら強いシステムに変革していく過程と成果を３つの事例を 使って紹介する。 論文目次 １．はじめに １．１ 当社概要 １．２ 背景 １．３ 論点 ２．性能評価プロセス ２．１ 性能評価プロセスとは ２．２ 見える化ツール ～ CPU/IO頻度分析 ２．３ 見える化ツール ～ DASDのI/O分析 ２．４ 問題抽出 ～ 性能指標値21 ２．５ 原因分析 ～ 仮説検証型性能解析 ３．性能評価事例 ３．１ 事例１：夜間バッチ処理時間を短縮したい ３．２ 事例２：オンラインレスポンスを改善したい ３．３ 事例３：次期CPU選定のアプローチ ４．評価 ５．今後の課題 ６．おわりに 本編 論文はメンバー専用のページに公開中です。 ↓↓↓
２．性能管理・改善のプレークスルー － 自らの常識を破り、どのように性能改善を実現したか － （FUJITSUファミリ会 2005年前期投稿論文） 論文要旨 大型メインフレームGS21 600で動く10時間の夜間バッチ処理を3時間以上の短縮に成功。 オンラインサービス時間の延長、リカバリ時間の確保に加え、年間2,000万円以上のコストメリットも生み出した。 地道なチューニングとともに、性能管理・改善の課題を以下の3点と設定しプロジェクトを推進した。 １．性能管理者自身の常識のブレークスルー ２．管理者視点からお客様視点でのブレークスルー ３．個人プレイからチームプレイへ 従来の常識を破ることが最大のポイントであり、ブレークスルーしていく過程１・２を事例を使って解説する。 技術的に見ても富士通社内でも例のないものが多い。 ３は継続中の課題として、ハイパフォーマンスな性能管理チーム作りの興味深い取り組みを紹介する。 論文目次 １．はじめに １．１ 当社概要 １．２ 背景 ２．性能管理・改善の課題 ３．性能管理者自身の常識のブレークスルー（課題１） ３．１ 少ない工数で最大の効果が得られる改善から始める 事例 特定部署にクローズしたため、効果が出るのが遅れた ３．２ 誰にでも効くチューニング項目 事例 VSAMバッファを指定したらCPU時間が最大67%増加してしまった ４．お客様視点でブレークスルーしたチューニング事例（課題２） ４．１ SORTがCPUを多量に使うのは仕様である 事例 CPU時間を60%削減 ４．２ 磁気テープへのバックアップが遅いのは当然である 事例 処理時間を1/10に削減 ４．３ ユーザアプリケーションのチューニングはむずかしい 事例 一つのプログラムでCPU時間を最大17分削減（GS21 600/10を使用） ５．チームプレイの性能管理を目指して（課題３：進行中） （１）研修で工夫した点 （２）参加者の評価 ６．評価・効果 ６．１ コスト効果 ６．２ サービスレベル向上 ７．今後の課題 ８．おわりに 本編 論文はメンバー専用のページに公開中です。 ↓↓↓
１．メインフレームのパフォーマンス改革 － お客様が感動したチューニング効果とコスト削減のプロローグ － （FUJITSUファミリ会 2004年後期投稿論文） 論文要旨 オープン全盛期の現在でも富士通メインフレーム上で4,000システムが動作している。 CPU本体のハードウェア費用が下がってきた今、「メインフレームのパフォーマンス改革」を提案する。 システムの稼動状況を分析し、適切な管理と改善をすることにより、オープン化よりも簡単にコストを削減し、性能・信頼性の高いシステムの構築が可能となる。 本編では事例を中心に、 （１）稼動状況分析フェーズにおける重大問題をお客様と富士通に提起。また、 （２）お客様が感動したチューニング －リコンパイルのみで夜間バッチの終了が40分短縮、 システム起動プロシジャの変更で10秒以上のオンラインレスポンスが1秒未満に改善、 プログラム環境定義の修正で一日7,200秒のCPU削減－ といった事例を紹介する。 これらの改善作業を行い、次期システム導入に向けて、お客様が主導権を握り、作業・コストの見える化によりコスト削減と品質向上を課題として現在取り組んでいる。 論文目次 １．はじめに １．１ 当社概要 １．２ 背景 １．３ メインフレームの性能評価の特殊性 ２．仮説のブレークダウン ３．現状の問題点と解決策（事例） ３．１ システムの稼動状況を分析できない 事例１ PDAで出てこないレポートやSMQN名がある（OS共通） 事例２ PDAでX0レポートが出力されないことがある（XSP） 事例３ AVM/EX配下でPDLを採取すると、CPU使用率の精度が極端に悪化しているにもかかわらず、ユーザはその値を信じてしまう。 ３．２ 適切な管理と改善ができていない 事例１ 夜間バッチのCPU時間が1時間以上短縮（システム全体の30%相当） 夜間バッチ終了時間が40分以上短縮 事例２ 10秒以上の一時的なレスポンス悪化が1秒未満に改善 オンラインジョブ全体のCPU使用時間が35%削減 事例３ オンラインジョブのCPU時間が一日7,200秒削減 オンライン処理時間が80%以上短縮 ３．３ コストを削減できない （１）仮説設定 （２）コスト削減の方向性 （３）Ａ社での事例 （４）今後の課題 ４．むすび 用語説明、解説 本編 論文はメンバー専用のページに公開中です。 ↓↓↓
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
 株式会社 アイビスインターナショナル 134-0003 東京都江戸川区春江町4-17-12 |
| All rights reserved, Copyright (c) IBIS International Inc. 2005-2015 |