2009年11月17日(Tue)〜2009年11月18日(Wed)の2日間、
NECラーニング:システム性能設計に参加してきました。
以下に、参加して私が得てきたことをまとめます。
システム性能設計まとめ:目次
- 使用するツール
- はじめに
- 基本概念
- システム開発における性能評価
- 性能予測
- シングルプロファイルの実施方法と
- 性能測定技術
- まとめ
- 性能予測・性能見積もりの実施手順
- モデリングについて
- シュミレーションについて
- 待ち行列理論と積み上げ方式による性能検証
- サービスレベルを考慮した性能設計
- 2日間のまとめに代えて
- 付録
使用するツール
IPS
# mevalet # NECのツール # Hyperformix # Hyperformix社のIPS
はじめに
SIの性能Goal
# 次の2つのバランスをとること # Resource requrement → リソース要求 * Workload * New Software * 将来を見越す # Capacity * システムの処理能力 # 性能とは # 品質特性の1つ ISOが定義する6つの特性 * 効率性 - 時間効率性 - 資源効率性 # 例 # 性能不足 * リソース要求>システム処理能力 # オーバースペック * リソース要求<システム処理能力 - システム要求の定義を的確にする必要がある # 理想 * リソース要求=システム処理能力 # 性能設計として考えること # リソース要求をよそ屈指システムの処理能力を定義する * システム能力を定義する手法を説明していく
システムリソース・4大要因
# CPU # 今も昔もボトルネック候補No1 # メモリ # 昔 * メモリ容量不足 # 今 * たくさんの容量はつむことができるようにはなった * 実行環境のサイジングを的確にする必要がでてきた - Java # JVM # ディスク # DBアクセス # ネットワーク # 機器の問題というよりもデータ転送 * データの大容量化
システムライフサイクルと性能評価
# 性能見積もり # 提案・受注段階 # 性能分析 # 設計・開発段階 # 負荷予測 # 運用・保守段階
基本概念
パフォーマンスとは?
# 性能の指標 # 量 (開発者視点) * スループット - 単位時間に完了する処理量 # 時間 (お客様視点) * レスポンスタイム - 結果の先頭が返ってきた時間 * ターンアラウンドタイム - レスポンスタイムに似ている - すべての結果が返ってくるまでの時間
スループットとレスポンス
# スループットとクライアント数を比較 # クライアント数が増える # レスポンスは悪化していく # スループットは増大する * ある一定以上からは踊り場にのってしまう
性能を決める要因と性能評価フロー
# 評価対象 # 3つの要素 * 単一トランザクション処理のサーバ負荷 - CPU使用率 * 複数トランザクションを並行処理する影響 * 処理要求発生頻度 - いわゆるトランザクション数 # 評価フロー # 性能指標 * システム動作モデル - シミュレーションモデル # Hyperformix - 数理モデル # 呼量 * シングルプロファイル×処理要求の発生頻度
シングル・プロファイルで考える
# 客観的指標 # 内部指標 # リソース単位で考えていく # 内部指標を集めていくと客観的指標を得ることができる
(参)シングル・プロファイル法
# 1を聞いてnを知る # 1を聞く * 1クライアント接続の実測 * 基礎データ # nを知る * n クライアント接続時の性能予測
システム開発における性能評価
パフォーマンス・エンジニアリングの狙い
# SPE approach の考え方 # 性能見積もり # 提案・受注段階 * ボトルネックの把握 - どのあたりに影響がでそうか? # 性能分析 # 設計・開発段階 * 性能ボトルネックの早期発見・解消 # 負荷予測 # 運用・保守段階 * 負荷特性の把握、問題点の解消
関連技術
# 性能への取り組み # Software Engineering * SPE Approach # Performance Management * 性能への取り組みを包括的にマネジメントする # Performance Tuning # Performance Modeling * 性能に関することを図にする - 見える化 # 動的 # 静的 # Software Quality Assurance * SLAの検討・導入 # Capacity Planing * システムの処理能力を定義すること
SIにおける性能の扱い
# SPE # Software Performance Engineering Approach * 現在の主流 - Web App の普及 * 開発の各工程ごとに考える - ものがない段階から性能を予測する # Fix-it-later approach # テスト段階で性能を考えていこうという考え # ものができないと評価できないという考え
効果
# 概要 # 上流工程から性能を考慮してシステム設計を行う # 設計・開発の節目節目で確認 * SPE approach # Best case , worst case を考える * 顧客にはBest case は見せない - テストを重ねることで性能値はBest case と warst case の中間におちる
SIプロジェクトへの適用
技術map
# 基礎データがない場合 # 推定 or プロトタイプはまねてもよい # サイジングはまねない
(参)高性能を実現するprinciple
# C.U.Smithさんの著書から一部を抜粋 # インタプリタよりもコンパイラ * 今はそうでもない # 占有時間をできるだけ短く * lock がないとデータの整合性の担保はむずかしい
(参)Instumenting Principle
# シングルプロファイリング # 測定ツールが重要 * ツールを使う場合の性能評価 * どのような測定ツールがよいか - サンプリング方式 # モニター # 不十分 # ツールなし # OSの統計コマンド * 高度なノウハウが必要 * 膨大な手間がかかる - イベントトレース方式 # イベント単位で行う # 十分 # ツールあり # 費用大 # mevalet など
mevalet による効率的なチューニング
性能予測
性能予測とは
# 性能指標を算出する技法 # 入力 * 性能基礎データ - シングルプロファイル # 手段 * システム動作モデル - シミュレーションモデル - 数理モデル # 出力 * 性能指標 - レスポンスタイム - スループット - システム資源利用率
システム動作モデル
# トランザクション並行処理時の動作を予測 # 数理モデル * 一般的に多い - 待ち行列網 * 方程式をたてる - 対象動作を確率過程として考える * 机上 # シミュレーションモデル * 価格が高い * 対象動作を模擬するソフトウェア * ツールを使用する
待ち行列網モデル
# 待ちの発生 # 影響 * レスポンスタイム * スループット # 資源競合による待ちの程度を評価 # ネットで詳しく調べる
シミュレーション・モデル
# 待ち時間が発生するということを説明する図
システム性能予測技術の特徴
# 数理モデル # 特徴 * ○ - モデル作成の手間 # 簡易的なモデリングでよい - 結果を得るまでの時間 # トランザクション数が増えても計算にかかる時間はかわらない # 机上での計算 - 見通しのよさ * × - システム動作の表現力 # シミュレーションモデル # 特徴 * ○ - システム動作の表現力 # 製品の詳細までシミュレーションできる * × - モデル作成の手間 # モデルがないと次の工程に進めない - 結果を得るまでの時間 # 試験の内容によっては大きく時間がかかってしまう # トランザクション数大にした場合など - 見通しのよさ
シングルプロファイルの実施方法とシングルプロファイルの結果を使った性能評価
単一トランザクションの測定と高精度測定ツール
# イベントトレース方式の測定イメージ
負荷発生ツール利用と従来型ツール利用
# サンプリング方式の測定イメージ # Load Runner * 有償 # OpenSTA * 無償 * ~ URL
シングルプロファイルを使った性能見積もり(基本的な考え方)
# 検証時、Appとインフラを切り分ける # App * 2割 # 基盤 * 8割
見積もり方法
# 図示化しましょう # フォーマットはとくにない # 各トランザクションの動作をモデル化 * 動的なモデル # 図示化のポイント # Sequence Diagram * UML - 図 - 表記法 # 13種類 # そのうちの1種 - 標準規格 # 表記の方法が決まっていればわかりやすい * UMLを書くためのツールの活用 - JUDE # OSS - SDAM # NECの製品 # 有償 # 一部無償 - ROSE # 有償 # コンポーネントの粒度は任意 * 基本はサーバ単位 - プロジェクトによって粒度を深堀 # プロセス # 関数 # オブジェクト # JavaBeans
利用者特性
# 呼量を求めるための基礎データ # トランザクション種別 * どのようなトランザクションが流れているか網羅 * 大きな割合を占めるとおもえるものを選定する # シングルプロファイル * トランザクションごとのシステム資源使用時間 # 負荷発生率 * ひとつのトランザクションにたいしてどれくらいの割合でおこなっていくのか - Tx1:70、Tx2:20、Tx3:1 # トランザクション発生率 * 単位時間当たりに発生するトランザクション数 * 要求発生頻度
トランザクション種別
# 図 # Hyperformixのモデル図と一緒
シングルプロファイル(例)
# イベントトレース方式で取得したプロファイルの例
トランザクションプロファイル(例)
# 種別 # DB参照 # DB更新
呼量による評価
# ρ=λh # λ * トランザクション - CPUはトランザクション量に比例して大きくなる # 0.6を目指す # ただし要件次第 # h * シングルプロファイル - トランザクション数
ボトルネックの性能チューニング
# ボトルネック # 概要 * 最も大きな使用率を示す資源がボトルネック - 常になくならない # 最も大きな使用率を示すものだから # それが問題になるのであれば、解決を図る * システム処理能力の上限を決定付ける資源 # 性能チューニング # 手法 * スケールアップ - 既存サーバの強化 * スケールアウト - サーバの追加 - 信頼性が向上する # 概要 * ボトルネック資源の使用率をさげること * ボトルネックの解消→次のボトルネックが浮上
キーポイント
# 参考までの内容 # ツールの使用を推奨しているため # 性能評価 # 呼量を求めることに費やされる # 基礎データをあつめるのに手間がかかる # イベントトレース方式でやることが成功のキーとはかぎらない * コストとのトレードオフ
性能測定技術
サンプリング方式の測定
# サンプリング方式 # ツール例 * sar - OS コマンド # 測定の仕方 * 一定時間ごとに測定対象資源の使用状況を取得 # 特徴 * 性能予測の基礎データは取得可能
イベントトレース方式の測定
# イベントトレース方式 # ツール例 * mevalet, Linux Trace Toolkit # 測定の仕方 * 1トランザクション中の処理資源の情報をすべて取得する # 特徴
サンプリングVSイベントトレース
測定方式の比較
# 3つの指標で方法を考える # データ量 * サンプリング方式 - 1データ/数秒 * イベントトレース方式 - 1データ/1イベント # 得意分野 * どれぐらい測定するのか - サンプリング方式 # 長期間 - イベントトレース方式 # 短時間 # 適所 * いつの開発工程で行う測定か - サンプリング方式 # 運用段階 - イベントトレース方式 # 設計段階 # そのた # 例 * 取得方法 # オーバヘッド * どれだけシステムに負担がかかるか # 因果関係 * 取得した結果(ログ)に関する話
(参)性能測定・分析ツール機能比較
# イベントトレース方式のツール例 # mevalet * いぜんは、Linux限定 - 現在は Windows も # glanceplus # VTune # Optimiseit # Jprobe
まとめ
システム性能評価
# 基本的な考え方は普遍 # シングルプロファイル # システム性能モデル
ソフトウェア・パフォーマンス・エンジニアリング
手順
# 性能基礎データ # サンプリング方式 # イベントトレース方式 # 性能予測 # 数理モデル * ρ=λh # 性能指標 # リソース使用率
性能予測・性能見積もりの実施手順
SI作業の流れ
モデリング〜解析のプロセス
# モデリングの概要 # システムの抽象化 * イメージする - 振る舞い # 動的 - システムのアーキテクチャ # 静的 # 性能モデルの作成 * 図の作成 - 図や表の形で記述する # 動的 # フロー * slide76 # 数理モデルでは書きやすい # シミュレーションモデルはキチンと記載しないとうごかない # 静的 # HW構成 * slide75 # データの収集 * サンプリング方式 * イベントトレース方式 - 監視には向かない # 条件の明確化 * システムに応じた優先順位を明確にする - CPU使用率 - チューニングの手法 * システムの制約条件などをいまいちど確認する - 何を評価するのか # CPU使用率 - 制約条件 # CPU使用率の制限 - 変更可能な条件 # トランザクション数 # サーバ台数 # CPU数 - 利用可能技術の検討、決定 # 性能見積もりの実施 * 性能予測と同義 - システム動作モデル # 数理モデル # 計算するプロセスが異なる * 待ち行列 * 単純積み上げ # 結果は同じになる # シミュレーションモデル - 必要に応じて複数回実施 # シミュレーションが使えるときは、机上でも考える # 見積もり結果の解析評価 * 5,6は必要に応じて繰り返し実施 * 2へもどり性能モデル修正 * 性能指標を出す
モデリングについて
モデリングについて
# 性能に関しては図が必要 # 動的 # 静的 # 表記にしたがって図を描くこと # 目的 # 振る舞いの記述 * トランザクションの流れ # 予測 # 方向性 # シミュレーションの実施 # 特徴 # 可視性 * わかりやすい # 全工程でおこなうことができる * シームレス # システムのモデリング # ポイント * ユーザにとってシンプルで理解しやすい # 静的 # 動的
シュミレーションについて
シミュレーションについて
# メリット # システム動作の表現力に優れている # 詳細な性能評価が可能 * 情報の網羅性 # 条件を変化させながら結果を検討できる # デメリット # 時間がかかることがある # 実際にものをつくらなくても解析が可能
シミュレーション技法とシミュレーションツール
# IPS Performance Optimizer # Hyperformix社
IPSの特徴
# Integrated Performance Suite
待ち行列理論と積み上げ方式による性能検証
待ち行列理論による性能検証
# サーバが安定して動作する条件 # λ < μ * λ - ユーザからのリクエスト到着率 # 件/秒 * μ - サーバの処理能力 # 件/秒 # サーバ内経過時間 # レスポンスタイム * μ - 1/h - サーバの処理能力 * Tr=(ρ/1-ρ)h + h # 複数サーバの取り扱い # サーバ台数、CPU数を考慮する # 待ち行列モデル * 1台のサーバへの到着トランザクション - 以下のものでわる # 台数 # CPU数 - λ / 台数×CPU数
レスポンスとスループットの関係
# スループットの計算式
単純積み上げ方式による性能検証
# 1CPUごとの使用率を算出 # CPU処理時間とトランザクション数から各プロセスのCPUコストを産出 # 各サーバごとにCPUコストを積み上げる
サービスレベルを考慮した性能設計
コミュニケーションツールとしてのSLA
# お客様とのコミュニケーションツール # システムやサービスのよさを伝える
SLAの必要性
# サービスレベルの必要性 # 身近なものでもSLAがないと困る * 病院 - 番号札の配布 * ATM * バス - あと何分でくる # 待ち時間が明確になる * サービスの向上 # ITにおけるSLA # サービスを実現するためにかかる費用を可視化できる # 補足 # SLAの目的 * システム品質を維持・向上するため # SLAとは * サービスの提供者と利用者との間で合意したサービスレベルを文章化したもの * 利用者に提供するサービスの品質のこと # SLAの運用の仕方 * SLA管理項目を決める - 書いていないことは無効 - 想定するイレギュラーな対応について書いておく # 了解を得る * 管理項目ごとに目標値を定める - サービス性能 - サービス可用性 # ケーススタディの3枚目、チェックシート
SLA・SLMとは?
# SLM # SLAを維持するためにシステム納入後も定期的にシステムの状態監視、評価、改善の計画/実施を行う一連の活動 # ITIL * サービス管理の手法 * 業務プロセス # SLAのカテゴリ # 機能保持性 # 拡張性 # 保守性
SLAの現状
# お客様のメリット # 費用対効果を把握しやすい # 導入に対する不安を払拭できる
サービスレベルの管理(SLM)
# SLAは絶対的な契約ではないかどうかはお客様による # 守れる前提 * お客様との話し合いは継続 - 契約の運用保守
SLMの導入効果
# お客様 # サービスに対するコストをしることができる # 開発者がわ # 無茶な要求を回避することができる * システム変更コストをしめすことができる * ただしケースバイケース - かならずしも回避できるわけではない - 費用を出して要求を通したいお客様もいる # 共通 # 信頼関係を築きやすくなった
SLA導入手順
# SLA実現へのSI作業の流れ # SLAの定義 * 運用時前にお客様との合意を得る * 設計フェーズから少しずつチェック項目を洗い出していく - 各フェーズでチェックリストを用意 # システム導入フェーズとSLAの定義 * 提案・要件分析フェーズ - サービスレベル管理項目の検討、意識あわせを行う * 設計フェーズ - サービスレベルの具体的な数値目標を決める # システムモデルの導入 * 構築フェーズ - 評価フェーズに向けての評価項目を作成する # 検証するのは評価フェーズ # 検討する項目を考えるのは構築フェーズ * 評価フェーズ - 設計フェーズで合意した目標値が妥当かつ監視可能か評価する * お客様との合意を得る * 運用フェーズ - 運用方針にそって運用する - SLA監視の結果を定期に顧客に報告 - 改善が必要な場合、お客様との合意のうえシステム保守を実施
SLAに関する補足事項
# SLAでの注意事項 # 過度なサービスレベル要求に対する相互確認 # 性能に関するSLA # 目標値に対する注意事項 * 評価に関する注意点 - 事前評価環境による調査 # モノがない段階での評価 - 実績データによる設定 # プロトタイプなどを参考に * 目標値は幅をもたせて書くようにする - サービスの拡張を考慮 # 表現の仕方を工夫 # 平均 # 数値を固定しない * 80〜90など - 目標値に若干の余裕を持たせる # 可用性に関する記述 * カブドットコムのプレスリリースの例
サービスレベル定義チェックリスト
# チェックリストによるSLAの作り込み # SLAの管理項目と目標値は必須 * それ以外はフリーフォーマット * 要件にあわせてカスタマイズする - 参考 # slide 116, 117
2日間のまとめに代えて
パフォーマンスエンジニアリングになぞらえて
# 性能問題撲滅への考え方 # リスクコスト * 予算超過を減らす努力 * 性能要件 - 結合テストの段階でかんがえるから問題になる - 後回しテスト # Fit-it-later-approach # 性能に関するお客様要件は正しく仕様化する * 仮説をたてる - 設計段階から机上の計算を行う * 実証する - コーディング - 単体試験 - 結合試験 - 実運用 # ワーストケースから考えよう # パフォーマンスエンジニアリングの具体的なアクション # 仮説 # 検証 * 性能検証 - 仮説が正しいことを確認する # お客様の要望が正しく仕様化されていなければならない # 見積もり # 性能問題を防止するための要素問題 # 分析 # モデル化 # シミュレーション * IPS * 待ち行列
SI系での性能検証の考え方
# 単体テストにおける性能検証の考え方 # ボトルネックの撲滅 * ボトルネックの解析 - 単体テストで行う # シングルプロファイルで考える # ボトルネックの解析 # 結合試験における性能検証の考え方 # リソース競合の有無 # かならず遅延は起こる * 設計どおりの遅延かどうか # システムテストでの性能検証の考え方 # お客様の要件が達成できていることを確認する
上流工程における性能要件の確定
# サンプル:性能要件定義テンプレート # 集められるだけ集める * RFP * お客様要件 # 性能要件確定 # 性能要件がどの時間帯のことをいっているのか * オフピーク * ピーク * 平常時 # すべての要件についてサイジングをする * お客様に性能要件を選択してもらう # 上流設計ファイズにおける性能設計手順 # システムのモデル化 * 横展開可能にしておく # 上流工程における性能見積もりの基本的な考え方 # APとミドルウェアをきりわけて考える
付録
# mevalet の概要 # mevalet の利用
QA
# シングルプロファイルで性能がよくなるかどうか? # NO * アプリケーション内部での処理 - 複雑多岐 # たとえば Oracle 、30年前の Source がまだ動いているものもある # 仮想化 # 同様に適用できるか? * 様々な競合要件を考慮する必要がある - ゲストOS同士の競合を考える - CPUの競合 - IOの競合 # 各ゲストで独立したIFを使えるのか? # ワーストケースから考えよう # マルチスレッドの未対応、発覚したらどうするか? # 設計をやり直す * 見える化 - どこにボトルネックがあるのか * ハードウェアによる解決 * ソフトウェアの改修