中堅企業向けシステム開発におけるコンパクトな性能検証の進め方「このシステムは性能要件を98%達成しています」と言える検証プロセス
ＮＥＣネクサソリューションズ
技術開発事業部
小池輝明

Ｐａｇｅ １

Copyright NEC Nexsolutions, Ltd. 2014

ＮＥＣネクサソリューションズについて

Ｐａｇｅ  １－１

Copyright NEC Nexsolutions, Ltd. 2014

ＳＩ開発のシステムの種類と今回のターゲット
システムの種類

目的

システム例

関連するシステム

社会インフラ

社会生活の基盤維持

交通、金融、通信など

複数企業のシステムが密接に関連

顧客サービス

売上拡大

ＢｔｏＣ
ショッピングサイト

顧客向けシステムと企業内システム

企業内システム

業務効率化（コスト削減）基幹システム業務システム、ｅｔｃ

企業内システムと取引先企業

今回性能検証のターゲットとしているシステム領域
顧客は中堅企業
Ｐａｇｅ  ２

Copyright NEC Nexsolutions, Ltd. 2014

企業内システムにおける顧客とベンダーの課題（１）
顧客は社内業務のコスト削減に取り組む一方で予算が縮小。
開発ベンダーは受注金額の縮小により利益確保が必要。
顧客

開発ベンダー

コスト削減に取り組んでいる。

売上げを増やしたい

企業内システムはコスト的位置づけ

顧客の発注規模は減少傾向

企業内システムの開発コストが削減される

低予算での開発を目指す

Ｐａｇｅ  ３Copyright NEC Nexsolutions, Ltd. 2014

企業内システムにおける顧客とベンダーの課題（２）システム構築における顧客の発注はマルチベンダー化が進む。
しかし、利用者のクレームはＳＩｅｒに向けられる。
クレーム

ＳＩｅｒ
（システムベンダー）

顧客

発注

構築

利用者

業務システム（アプリケーション）
インフラ

インフラ担当ベンダー

構築（ＯＳ、仮想環境などＢ）

ネットワーク担当
ベンダー

構築

ネットワークシステムの階層

Ｐａｇｅ  ３－１

Copyright NEC Nexsolutions, Ltd. 2014

低予算の中で性能検証を実施するジレンマ
低予算での開発であっても性能検証は実施したい。
しかし、開発スケジュールへの影響は最小限にしたい。
結合テストフェーズで負荷テストを行う○：環境コストが１つで済む
×：負荷テスト中は環境を占有（テスト遅延リスク）

単体
テスト

リリース

結合テスト

負荷テスト

修正
リリース

システムテスト

修正
リリース

システムテスト

結合テストと負荷テストを平行で実施
結合テスト○：テスト期間の短縮が可能
×：各々の環境が必要（コスト増）

単体
テスト

リリース
負荷テスト

結合テストを妨げないために、性能検証を効率的に行いたい。
Ｐａｇｅ  ４

Copyright NEC Nexsolutions, Ltd. 2014

性能検証の効率化の阻害要因
性能要件や検証作業があいまいで、手戻り作業の発生リスクが大きい。
性能要件

性能要件は“３秒以内”
実施結果の信頼性が不明確で再テスト

負荷テスト設計

性能検証妥当性検証“３秒以内”の裏づけが不明確 負荷テスト
結果分析
性能検証を試行錯誤
負荷テスト実施

全体的に場当たり的な検証作業
場当たり的な検証作業を見直し、性能検証のゴールを明確にする。
Ｐａｇｅ  ５

Copyright NEC Nexsolutions, Ltd. 2014

課題のまとめと対策
開発予算が限られている中で効率的に性能検証を行う。
ただし、短期期間で行い開発を妨げない。
課題“アドホック”な性能検証

性能検証作業の達成度があいまい

低予算での開発

性能検証プロセスをコンパクト化し効率的に性能検証を行う
施策【コンパクト化施策①】
性能要件の見える化
Ｐａｇｅ  ６

【コンパクト化施策②】
検証結果の見える化
Copyright NEC Nexsolutions, Ltd. 2014

【コンパクト化施策③】
効率的な性能検証コンパクト化施策① 性能要件の見える化による性能検証の効率化

負荷テストシナリオのパターン分けによる性能要件の見える化
業務面において性能検証ニーズの多い３パターンを策定。
性能検証結果イメージの具体化を狙う。
シナリオタイプ

継続実行

一斉ログイン

一斉処理

概要

特定業務を繰り返し実行

複数ユーザーが一斉ログインし業務を実行

高負荷な業務処理を一斉に実行

業務の例

伝票業務
店舗業務
受付業務

出退勤処理
商品検索
ワークフロー

帳票出力
店舗業務
締め処理

性能要件
ポイント

継続利用時のリスクがないか

短時間に大量処理を行えるか全ての処理が実行されるかＰａｇｅ  ７

Copyright NEC Nexsolutions, Ltd. 2014

コンパクト化施策① 性能要件の見える化による性能検証の効率化

負荷テスト設計に向けたシナリオと負荷状態の組み合わせ
３つのシナリオと負荷条件を組み合わせ、システム負荷状態による性能要件の達成度合いを確認する
継続実行

一斉ログイン一斉処理

負荷条件

順次ログイン

ｌｏｇｉｎ

ｌｏｇｉｎ

負荷増加条件ｌｏｇｉｎ

・ユーザー増加数・増加間隔・増加上限

ｌｏｇｉｎ
業務処理

ｌｏｇｏｕｔ

多重処
理

業務処理

ｌｏｇｏｕｔ

多重処理

待機業務処理 業務処理

負荷テスト設計
Ｐａｇｅ  ８

Copyright NEC Nexsolutions, Ltd. 2014

連続運転条件多重処
理・ユーザー数・運転時間

コンパクト化施策① 性能要件の見える化による性能検証の効率化

負荷テスト設計に向けたシナリオと負荷状態の組み合わせ

シナリオタイプ「継続実行」
ログインしたユーザーは、一定期間、業務処理を繰り返す。
【想定業務】
・販売管理：受注伝票の入力・店舗業務：レジ業務
・コールセンター：受付業務
Ｐａｇｅ  ８－１

Copyright NEC Nexsolutions, Ltd. 2014

コンパクト化施策① 性能要件の見える化による性能検証の効率化

負荷テスト設計に向けたシナリオと負荷状態の組み合わせ

シナリオタイプ「一斉ログイン」
ログイン後、ユーザーは業務処理を繰り返し、ログアウトする。
【想定業務】
・勤務管理：出退勤入力
・販売業務：商品検索・ワークフロー：承認処理
Ｐａｇｅ  ８－２

Copyright NEC Nexsolutions, Ltd. 2014

コンパクト化施策① 性能要件の見える化による性能検証の効率化

負荷テスト設計に向けたシナリオと負荷状態の組み合わせ

シナリオタイプ「一斉処理」
特定業務の担当者が、比較的高負荷の業務を一斉に実施。
【想定業務】
・販売管理：帳票出力
・店舗業務：支店への通達
・業務共通：各種締め処理
Ｐａｇｅ  ８－３

Copyright NEC Nexsolutions, Ltd. 2014

コンパクト化施策① 性能要件の見える化による性能検証の効率化

負荷テスト設計に向けたシナリオと負荷状態の組み合わせ

テストの目的別に、負荷条件を設定する。
要件を超えたときのシステム状態

高負荷継続稼働時のシステム状態

接続数

要件内でのシステム状態

接続数の要件

経過時間

Ｐａｇｅ  ８－４

Copyright NEC Nexsolutions, Ltd. 2014

コンパクト化施策① 性能要件の見える化による性能検証の効率化

負荷テスト設計に向けたシナリオと負荷状態の組み合わせ【要求された接続数での負荷】接続数要求された接続数で連続稼働させる。
連続稼働でリソースリークが発生しないか確認する。

接続最大数
（要件）

経過時間

Ｐａｇｅ  ８－５

Copyright NEC Nexsolutions, Ltd. 2014

コンパクト化施策① 性能要件の見える化による性能検証の効率化

負荷テスト設計に向けたシナリオと負荷状態の組み合わせ【要件を大きく超えた接続数】
要求を大きく超えた接続数で連続稼働させる。
システムの不安定状態（リソースリスク）を起こさせる。

Ｐａｇｅ  ８－６

Copyright NEC Nexsolutions, Ltd. 2014

コンパクト化施策① 性能要件の見える化による性能検証の効率化

負荷テスト設計に向けたシナリオと負荷状態の組み合わせ【接続数を段階的に増やす】

接続数接続数を一定間隔で増加させて、連続稼働させる。
増加によりシステムリソースの変化を見る。

接続最大数
（要件）

経過時間

Ｐａｇｅ  ８－７

Copyright NEC Nexsolutions, Ltd. 2014

負荷条件と性能検証するグラフの関連付け【最大接続数の一定負荷】

パレート図

最大接続数で一定時間稼働↓

性能目標の達成状況【接続数の段階的増加】

時系列グラフ

接続数増加で一定時間稼働↓

リソースリスクを計測

Ｐａｇｅ  ８－８

Copyright NEC Nexsolutions, Ltd. 2014

コンパクト化施策② 検証結果の見える化による検証プロセスの短縮「性能要件の達成度」の見える化
パレート図により、性能要件の達成度（未達成度）を定量的に判断可能に。

達成比率

性能要求の応答時間内で実施した処理の割合を提示

性能要求の応答時間

Ｐａｇｅ  ９Copyright NEC Nexsolutions, Ltd. 2014

コンパクト化施策② 検証結果の見える化による検証プロセスの短縮「システムのリソースリスク」の見える化
時系列グラフにより、負荷状況の変化によるリソースリスクを把握可能。
高負荷長時間運用（リソース枯渇状態での継続運用）

高負荷利用（接続要求以上）
通常利用（接続要求内）

接続数増加とガベージ処理によりＣＰＵ負荷が増大

メモリメモリ不足のリスク
空き容量の枯渇によりガベージが発生

接続数

経過時間

ＣＰＵ

Ｐａｇｅ  １０

Copyright NEC Nexsolutions, Ltd. 2014

ＣＰＵ利用率、メモリ利用可能率（％）

接続ユーザー数

限界利用（リソース枯渇）

コンパクト化施策③ 効率的な性能検証作業

分析パターンと採取データのテンプレート化
負荷テストで採取したデータの集計作業効率化がポイント。
テンプレートを作成し、データのインポートでグラフを自動化
採取データの設定
分析結果のパターン化

集計結果の自動生成

採取データのインポート
Ｐａｇｅ  １１

Copyright NEC Nexsolutions, Ltd. 2014

実施にあたっての工夫点

負荷テストの自動実行化
開発チームと同一の環境を使用した場合、負荷テストは限られる。
そこで、自動実行環境を構築し負荷テストを夜間に実施。
業務時間

開発チーム

検証チーム

開発データセット

夜間

開発作業

分析作業

負荷テスト
データセット

負荷テスト（自動実行※）※負荷テストツールの起動をバッチ化しスケジュール起動で実現。

夜間に負荷テストを自動で実行させることにより、開発環境の占有時間を最短にし、分析作業に注力可能になった。
Ｐａｇｅ  １２

Copyright NEC Nexsolutions, Ltd. 2014

実施結果①
性能検証作業はコンパクト化されたか？
開発案件毎に個別にアドホックに進めていた性能検証が短縮された

Ｂｅｆｏｒｅ

場当たり的性能検証 （ＡＳ－ＩＳ）
性能要件
業務要件

負荷テスト
シナリオ
検討

負荷テスト
設計書

レポート
採取データ
検討

レポート様式
採取データ

負荷テスト
実施

採取データ

レポート集計（手動）

策定済みの検証の流れに適合させるプロセスへ整理された性能検証  （ＴＯ－ＢＥ）
Ａｆｔｅｒ

業務要件

負荷テスト
パターン

レポート作成テンプレートＰａｇｅ  １３

負荷テスト
シナリオ
検討

施策①
施策②

負荷テスト
設計書

負荷テスト
実施

採取データ

施策③
レポート集計（自動）

Copyright NEC Nexsolutions, Ltd. 2014

検証作業を予め策定し、検証期間を短縮化

実施結果②「性能要件の達成度」の見える化
同じ負荷をかけ続けた場合の性能要件の達成度をパレート図で確認。
達成度の判定だけでなく、応答時間の分布状況も把握可能。
応答時間 分布
100

100%
90%

1010%

00%

「応答時間３秒以内」の達成率は“９８％”～3.86720%～3.60020～3.33330%～3.06730～2.80040%～2.53340～2.26750%～2.00050～1.733

60%～1.46760～1.20070%～0.93370～0.66780%～0.40080～0.133

件数

90

累計割合

累積件数

データ個数

応答時間（秒）

Ｐａｇｅ  １４

Copyright NEC Nexsolutions, Ltd. 2014

実施結果③「システムの限界」の見える化
負荷を段階的に増加させたときのシステムの許容状態を把握
閾値を割り込むと急速にリソースが枯渇し、不安定になることを確認。

Ｐａｇｅ  １５

Copyright NEC Nexsolutions, Ltd. 2014

実施結果③「システムの限界」の見える化
負荷をかけた状態をステージとして定義することで、システムの振る舞いを表現↓「何人まで使える？」に対する回答が明瞭になった。

ステージ

通常利用

高負荷利用

限界利用

高負荷長時間運用

ステージの説明安定して利用可能負荷が高くなり始める

業務失敗のリスクが高いシステムが不安定になるシステム状況

システムは安定、ＴＡＴも安定。

Ｐａｇｅ  １５－１

応答時間は業務を止めるなどの徐々に悪化。
処置が必要。
リソースも閾値近く。
Copyright NEC Nexsolutions, Ltd. 2014

メモリが枯渇し、ＧＣの発生が頻発

実践的な性能検証シナリオ
シナリオ／負荷状態／検証のパターン化の組み合せにより実業務を想定した負荷テストが可能になる。
例：小売店向けシステムで、セールによる売上が接続最大数を超えることが予想される場合。
予想より多くの店舗から接続が増加

本店業務は担当スタッフが業務を実施

負荷条件

時系列グラフＰａｇｅ  １５－２

負荷条件

要件を上回る接続数での稼働によるシステムリスクと応答時間の達成率を把握↓
対策立案
Copyright NEC Nexsolutions, Ltd. 2014

パレート図

さいごに
▐ 従来、性能検証は対象のシステムに合わせて実施作業を個別に策定していた（ＡＳ－ＩＳ）。この方法では汎用性に乏しく、やり直しリスクも高い。
▐ そこで、本来あるべき性能検証作業を決め、実際の検証作業をこれにフィッティングさせる方法に変更した（ＴＯ－ＢＥ）▐ このことにより、負荷テストで何をするのか、そのために性能要件をどのように設定するのかが見えてきた。
▐ また、集計作業の効率化や負荷テストの自動実行により、検証作業を実施するための制約が緩和された。
▐ 今後はシステム構成に合わせたバリエーションを増やし、効果を高めていきたい。
Ｐａｇｅ  １６

Copyright NEC Nexsolutions, Ltd. 2014使用した検証ツールと参考文献▐ 検証ツールl XenApp環境：Citrix® EdgeSight for Load Testingl Webアプリケーション：Oralce® Load Testing▐ 参考文献l ＩＩＭパフォーマンス管理セミナー資料l 非機能要求グレード（ＩＰＡ）

Ｐａｇｅ  １７

Copyright NEC Nexsolutions, Ltd. 2014

Copyright NEC Nexsolutions, Ltd. 2014