情報システムの性能マネジメントについて

Copyright © 2015 Takashi Natsume All Rights Reserved.
情報システムの性能マネジメントについて
公益社団法人日本技術士会
登録グループ IT21の会 2015年9月例会
2015年9月4日（金）
夏目貴史
技術士（情報工学部門・総合技術監理部門）

自己紹介
【名前】夏目貴史（なつめたかし）
【学位・資格】
• 修士（工学） ― 電子情報工学専攻
• 技術士（情報工学部門・総合技術監理部門） ― 情報システム・データ工学
• 米国PMI認定PMP
【業務経歴】
オープンソースソフトウェアとミッションクリティカルな大規模システムに関する
システム開発や評価（検証）、情報システムの性能評価、性能問題解決に従
事。
現在はOpenStackを利用したIaaSシステムの開発およびOpenStackのコミュニ
ティ活動に従事。
【日本技術士会での活動】
• 日本技術士会国際委員会委員(2015年7月～)
• 日本技術士会情報工学部会幹事(2015年3月～)
2

開発フェーズ
企画要件定義設計実装テスト運用
開発のそれぞれのフェーズで情報システムの性能を確保する
ために行うべきこと、注意すべき点を説明します。
ウォーターフォール・モデル
注：開発モデル、開発方法論によってはフェーズの定義や用語が違う場合があります。
（一般的には上記のフェーズよりも細かく分かれます。）
例えば、「TERASOLUNA開発手順」（※1）では12のプロセス体系となっており、
「基本構想プロセス（BP）」、「システム要件定義プロセス（RD）」、
「AP外部設計プロセス（ED）」、「AP内部設計プロセス（ID）」などのプロセスが
定義されています。
※1: TERASOLUNA のご紹介
http://www.terasoluna.jp/announcement/pdf/TERASOLUNA.pdf
3

開発における性能確保の考え方
各フェーズにおいて「不確実性」を低減させていく。
運用時にも「不確実性」（リスク）が残るので、それを監視する。
要件定義設計実装テスト運用
高
低
不確実性
残存する
部分が
存在する
4

要件定義
• 性能要件をきちんと決める
• 性能要件＝負荷要件＋性能目標
• 負荷要件
• 情報システムへの「入力」
• 性能目標
• 情報システムの「出力」
情報システム出力入力
5

性能要件
非機能要求グレード（※2）から抜粋すると以下のようになる。
• 負荷条件
• ユーザ数
• 同時アクセス数
• データ量
• オンラインリクエスト件数
• バッチ処理件数
• 業務量増大度
（ユーザ数増大率、オンラインリクエスト件数増大率、他）
• 他
• 性能目標
• オンラインレスポンス
• バッチレスポンス（ターンアラウンドタイム）
• オンラインスループット
• バッチスループット
• 他
※2：非機能要求グレード
http://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html
6

性能要件定義の注意点
• 「非機能要求グレード」に補うべき項目がある
• 「非機能要求グレード」は「発注者と受注者との認識の行き違い」
を「防止することを目的」したもの
• 他に考慮すべき主な項目
• データベースのテーブルのカーディナリティ（値の種類、偏り）
• 競合（オンラインとバッチ）
• 事例
• 主要な機能のみ性能目標が定義されていた
• 動画配信の機能については定義されていたが、その他は未定義
• 単位時間を決めるのは難しい
（例：1時間当たり何件のリクエスト）
• オンラインのレスポンスタイムはパーセンタイル値（例: 90パーセ
ンタイル値）がお勧め
（「非機能要求グレード」では「順守率」の表現）
• 性能測定の起点（インターネット・アクセスがあるシステムで、
データセンタの「入り口」における目標を定義。）
7

サイジング
• ハードウェアについては発注してから納品されるまで
タイムラグがある（オンプレミスのシステム）
• 以下について見積もりを行う
• CPU
• メモリ
• ディスク容量
• ディスクのI/O帯域
• ネットワーク（帯域）
8

サイジング方法
• CPU
• 方法
• 類似システム
• ベンチマーク
• SPECint、TPC-Cなど
• プロトタイプ
• シミュレーション・ツール
• 精度を上げるため、複数の方法を使用して見積りを行なう
• 「類似」の定義は難しい
• メモリ/ディスク容量/ディスクのI/O帯域/ネットワーク
（帯域）
• 積み上げ方式
• 安全率を使用する
• 安全率としてこの値を使用するのが良いという値はない
9

設計
• 設計での考慮点はいろいろとあるが今回は時間の
都合により省略
• 事例
• 「塵も積もれば山となる」（ループ処理）
• ディスクI/Oのパス（帯域）も設計する
• 拡張性設計
• スケールアウトさせてもリニアに性能は向上しない場合もある
• 運用設計
• 性能問題発生時の解析
• 監視（情報取得）ツールをあらかじめ導入しておく
• 商用環境に後からツールを入れることに難色を示すお客様もいる
• クラウド・コンピューティング・サービスにおける仮想リソースの上
限増加申請のリードタイムも考慮する。
10

実装
• 実装での考慮点はいろいろとあるが今回は時間
の都合により省略
• 事例
• データベース（RDB）のインデックスがきちんと使用され
ているか確認する
11

テスト
• 性能テストを行なう
• テストデータ
• DBレコード
• カーディナリティを考慮し、システム・ライフサイクルにおける
想定される最大件数のデータを準備する
• 負荷クライアント
• 例えばHTTPリクエストを送る負荷ツール
• その負荷ツールがクライアントのリソースを使い切って
しまい、想定の負荷がかからないことがある
12

パフォーマンス・チューニングの考え方
• 性能要件を満たさない場合はチューニングを行う
• チューニングを止める（完了させる）のはいつか？
→性能要件を満たすようになった時
開始
性能テスト
ボトルネック解析
チューニング
終了
性能要件を満たしているか？
Yes
No
あるボトルネックを解消すると
別の箇所がボトルネックとなる
13

運用
• システムテスト（性能テスト）でのボトルネック候補を監
視してプロアクティブに対応する
• 性能問題発生の兆候が出たら、事前に対策・対応する
• 事例
• テスト環境と商用環境の差異
• テスト環境は商用環境に比べリソースを落としているケースがある
• 性能特性が異なると性能問題の再現に影響が出ることがある
14

性能問題解決に行き詰ったケース
• 性能問題解決に行き詰った
• チューニングも限界にきている
• リソース（ハードウェア）の増強もすぐにはできない
• 処理期限の迫ったデータが山積みになっている
運用対処を行なった。
性能問題発生の原因はデータベースのアクセスパスに
問題があったことである。（テーブルのフルスキャンが発生。）
運用対処として、特定の機能の使用禁止、特定の画面にお
ける検索キーの入力を必ず行ってもらう、などの対策を行
なって運用を続けた。
15

まとめ
• 開発の各フェーズで不確実性を減少させていく
• 各フェーズでやるべきことをやる
• 残存する不確実性（リスク）は運用時に監視する
• 最後の手段として運用対処で乗り切る方法も
16

今後の発表・講演予定
• FIT 2015(第14回情報科学技術フォーラム)で発表
します
• 9月16日（水）15:30-17:30（のうちの20分）
• 愛媛県松山市
• OpenStackのコミュニティ活動について（新機能提案に
おける傾向分析）
• http://www.ipsj.or.jp/event/fit/fit2015/FIT2015_web_pr
ogram/data/html/abstract/B-003.html
• OpenStack Summit Tokyoで講演を行ないます
• 10月29日（木）9:00-9:40AM
• 品川
• タイトル：「NTT's journey with OpenStack」
• NTT研究所のOpenStackの取り組みについて
• http://sched.co/49vA
17

ご清聴ありがとうございました。

情報システムの性能マネジメントについて

Recommended

Recommended

More Related Content

Similar to 情報システムの性能マネジメントについて

Similar to 情報システムの性能マネジメントについて (20)

More from Takashi Natsume

More from Takashi Natsume (8)

情報システムの性能マネジメントについて