品質検査としてのWebパフォーマンス計測手法
•
3 likes•2,310 views
Webパフォーマンス(表示速度)は、非機能要求であり、その品質保証には、世界的には統計的品質管理が用いられています。 今、日本で広く用いられているGoogle PageSpeed Insightsや、WebPage Testなどは、品質検査ツールではなく、ITの専門家たるエンジニアは、統計的品質管理による品質保証を行わなくてはいけません。 では、具体的にどのような標準化や規格があり、どのような団体が存在し、どのような計測手法があるのでしょうか？ その詳細と統計分析の観点での重要な概念を解説しました。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 品質検査としてのWebパフォーマンス計測手法
Similar to 品質検査としてのWebパフォーマンス計測手法 (20)
More from Yoichiro Takehora
More from Yoichiro Takehora (20)
Recently uploaded
Recently uploaded (9)
品質検査としてのWebパフォーマンス計測手法
- 5. V&Vモデル(Verification& Validation) Verification(検証) … 設計どおりに実装されたかどうか Validation(妥当性確認) … 設計され実装されて実現した機能や性能は、本来意図された用 途や目的に適って妥当か？
- 7. VerificationとValidation • Verification – 請負契約での開発についての品質を担保する • Validation – 超上流工程での成果物がそもそも妥当でない場 合には、その責任がValidationで問われる – 超上流工程での成果物が妥当で、開発工程に問 題がある場合にも、その責任がValidationで問わ れる
- 8. 性能品質とは • 性能品質が良い・悪い – バラツキが小さい事が、「品質が良い」 – バラツキが大きい事が、「品質が悪い」 • ある目標値に達しているかどうかも大事だが、その 達成度がばらついている場合には、品質が悪い • 品質管理の目的は、「品質目標に適合しないものを 世に出さない」こと。 – Webパフォーマンスの場合、それは不可能である ため、「将来」の結果へと繋げる
- 11. 標準化の重要性 • 経産省が進める「戦略的国際標準化加速事業」 – 世界に対してモノやサービスを販売する際に、その 品質の優位性をアピールする、もしくは品質検査して 品質保証する必要がある – 独自の品質検査では、相手に受け入れられない – 品質検査の標準化が重要 – 標準化された品質検査手法に則り、品質保証を行う 事で、品質保証がスムーズに進む – 品質検査手法が、適切ではない場合に、適切な指標 の設定と、その品質検査を標準化することで、独自 の市場を開拓していく
- 12. 標準化に合わせる重要性 • 共通の「ものさし」で語り合える • 標準化された計測手法に従う事で、正しい計測手法を 導入できる • その都度、相手に要望された「手法」で計測する必要が なくなる ↓ 品質の比較 品質検査の正しさの保証 業務の効率化
- 13. W3C Web Performance Working Group https://www.w3.org/webperf/
- 15. Resource Timing
- 18. American Software Testing Qualifications Board, Inc. https://astqb.org
- 19. The Art of Computer Systems Performance Analysis Techniques for Experimental Design, Measurement, Simulation, and Modeling 米国ワシントン大学をはじめとして、コンピューターシステムのパフォーマンス計測 についての定番教科書
- 20. Foundations of Software and System Performance Engineering
- 22. Foundation Level Specialist Syllabus Performance Testing 2018 https://astqb.org/assets/documents/ISTQB-CTFL-PT-Syllabus-2018.pdf
- 23. Principles of Performance Testing • Performance testing is not limited to the web-based domain where the end user is the focus. It is also relevant to different application domains with a variety of system architectures, such as classic client-server, distributed and embedded. Technically, performance efficiency is categorized in the ISO 25010 [ISO25000] Product Quality Model as a non-functional quality characteristic with the three subcharacteristics described below. Proper focus and prioritization depends on the risks assessed and the needs of the various stakeholders. Test results analysis may identify other areas of risk that need to be addressed. International Software Testing Qualifications Board
- 25. ISO25000における3つの非機能要求 • 時間挙動(Time Behavior) – 一般的に、時間挙動の評価が最も一般的なパフォーマンステストの目的。 – パフォーマンス・テストのこの側面では、コンポーネントまたはシステムが、指定された時間 内に指定された条件下でユーザーまたはシステムの入力に応答する能力を調べる。 – 時間挙動の測定値はシステムが消費する「エンドツーエンド」時間、ユーザー入力への応答 時間、ソフトウェア・コンポーネントが特定のタスクを実行するために必要なCPUサイクル数 などがある。 • リソース使用率(Resource Utilization) – システム・リソースの可用性がリスクとして識別されると、特定の性能試験を実施することに より、これらの資源(例えば、限られたRAMの割り当て)の利用状況を調査することができる。 • キャパシティ(Capacity) – システムの要求される容量限界におけるシステム挙動の問題(ユーザー数やデータ量など) がリスクとして特定された場合、性能試験を実施してシステムアーキテクチャの適合性を評 価してもよい。
- 26. パフォーマンステストの種別 1 • パフォーマンステスト – パフォーマンステストは包括的な用語で、さまざまな負荷の下でのシステムまたはコンポーネントのパフォーマンス (応答性)に焦点を当てたあらゆる種類のテストを含む。 • 負荷テスト – 負荷テストは、制御された数の同時ユーザーまたはプロセスによって生成されたトランザクション要求から生じる、予 想される現実的な負荷の増加レベルを処理するシステムの機能に焦点を当てている。 • ストレステスト – ストレステストは、予測または指定されたワークロードの限界または限界を超えるピーク負荷を処理するシステムま たはコンポーネントの能力に重点を置く。 – ストレステストは、アクセス可能なコンピューティング能力、使用可能な帯域幅、メモリなど、リソースの可用性が低 下した場合のシステムの処理能力を評価するためにも使用される。 • スケーラビリティテスト – 拡張性テストは、現在必要とされている以上の将来の効率要件を満たすシステムの能力に焦点を当てる。 – このテストの目的は、現在指定されているパフォーマンス要件に違反したり障害が発生したりすることなく、システム が拡張(たとえば、ユーザー数が多いほど、保存されるデータの量が増える)できるかどうかを判断すること。 – スケーラビリティの限界がわかったら、本番環境でしきい値を設定して監視し、発生する可能性のある問題を警告す る。また、適切な量のハードウェアを使用して本番環境を調整することもできる。
- 27. パフォーマンステストの種別 2 • スパイクテスト – スパイクテストは、ピーク負荷の突然のバーストに正しく応答し、その後定常状態に戻るシス テムの能力に焦点を当てている。 • 耐久性テスト – 耐久性テストでは、システムの運用コンテキストに固有の時間枠におけるシステムの安定性 に重点が置く。 – このタイプのテストでは、最終的にパフォーマンスの低下やブレークポイントでの障害の原因 となるリソース容量の問題(メモリー・リーク、データベース接続、スレッド・プールなど)がない ことを確認する。 • 同時接続性テスト – 同時接続性テストでは、特定のアクションが同時に発生した場合(たとえば、多数のユーザー が同時にログインする場合)の影響に重点が置かれる。 – 同時接続性の問題は、特に本番環境のようにテストがほとんど制御できない環境で問題が 発生した場合、発見して再現することが非常に困難であることで知られている。 • キャパシティテスト – 容量テストでは、特定のシステムでサポートされ、規定されたパフォーマンス目標を満たす ユーザーやトランザクションの数を決定する。 – これらの目標は、取引から生じるデータ量に関しても設定される。
- 30. 品質モデル ISO/IEC 2501n 品質モデルと品質測定値 30 製品品質モデル ISO/IEC25010 データ品質モデル ISO/IEC25012 利用時品質モデル ISO/IEC25010 人間―コンピュータシステム 情報システム 通信システム 対象コンピュータシステム ハードウェア 非対象 ソフトウェア 対象 ソフトウェア 対象 データ 非対象 データ 一次利用者 二次利用者 もしくは 間接利用者 利用環境 Webパフォーマンスは、利用時品質に属します。
- 34. 品質要求プロセス 34 機能要求仕様 品質要求分析 プロセスレベル 制約条件等 • 品質要求分析標準 • 品質モデル • 品質計測 品質要求仕様
- 37. パフォーマンス計測の目的 • 速いことを確認するのではなく、遅い観測値ができ るだけないことを確認する • 遅い観測値がある＝ばらつきが生じている • インターネットの状況は、刻々と変化しているため、 一意に値は定まらない • 計測して検査した期間については結果を語れるが、 将来を保証するものではない – 変化し続けるから
- 39. Developer Toolは「プロファイラー」 • プロファイリングとは – ソフトウェアエンジニアリングにおいて、プロファイリングと は、動的プログラム解析の一種で、例えばプログラムの 空間(メモリ)とか計算時間、特定の命令の使用、関数呼 び出しの頻度と時間経過を計測する。 – 通常、プロファイリングの情報は、プログラムの最適化の 助けとなるために提供される。 – プロファイリングは、プログラムのソースコードや実行可 能バイナリのどちらかをプロファイラー(もしくはコードプロ ファイラー)と呼ばれるツールで計測することで成される。 – プロファイラーは、イベントベース、統計的、計測、シミュ レーション手法など、多数の異なるテクニックが使われる。
- 42. 設計 実装 テスト プ ロ フ ァ イ リ ン グ リリース 運用 Web パ フ ォ ー マ ン ス 管 理 フィードバック プロファイリングとパフォーマンス管理
- 43. プロファイリングと計測は違う • プロファイリング – 特定環境での調査・試験 – 本番運用して、全国に展開した場合に、そのプロ ファイリングの結果どおりになるとは限らない – 必ずばらつく • 計測 – 本番運用におけるバラツキの観測 – 実際の品質計測
- 44. Webサイトパフォーマンスの計測・監視手法 Last Mile First MileMiddle Mile web server エンドユーザ NTT KDDI エンドユーザ １次ISP RUM Synthetic Server side Last Mile
- 45. 各計測の補完関係 計測種別 商品名 長所 短所 サーバサイド監視 (Server-side Monitoring) OnPrem インターネットの影響を受け ていないWebサーバ本来の 表示速度を計測できる。 サードパーティーコンテンツ、 インターネットの通信状況の 影響が見られない。 合成監視 (Synthetic Monitoring) Synthetic Monitoring インターネットの影響を受け た、ISP毎の表示速度を計測 できる。 実験計画法に基づいた計測 により、問題点を特定する 事が可能。 計測対象ページ以外につい ては、データが得られない。 リアルユーザ監視 (Real User Monitoring) Real User Monitoring エンドユーザが体験してい る表示速度を取得すること が可能。 エラー率が分からないので 可用性分析には使えない。 エラーになったユーザの データは取得出来ない。 実験に介入できていないの で、因果関係の証明はでき ない。 表示速度に関わる変数が 非常に多く、それらの数値 が得られないため、品質管 理では使えない。
- 46. 外形監視という言葉は日本製 • 勝手に言葉をつくるな • Synthetic Monitoringを「外形監視」と称しているが、 Synthetic Monitoringの語源は、Synthetic Dataから来て いる。外形監視というのは、適切な訳語ではない。 • 合成データは「直接測定によって得られていない所定の 状況に適用できる生成データ」である。 – Webパフォーマンスの場合、直接測定によって得られ たデータはRUM(Real User Monitoring)である。 – Synthetic Monitoringは、測定機器から能動的に1 ユーザとしてアクセスすることで、生成されたパフォー マンスのデータを獲得するものである。
- 49. 世界で用いられている計測手法 Synthetic Monitoring(合成監視） • 統計学に基づいた品質管理手法 – 計測データは、必ずばらつきます。 • システムの状態 • 負荷状態 • インターネット通信網の状態の変化 – 計測値は、決して、一つの値に定まりません。 – 現在の表示速度が、どのくらいの確率で確かな値であるかを 求める必要があります。 • 統計学では、「信頼区間」と言います。 信頼区間とは、同じ計測を行った場合に、どれくらいの確率で同じ結 果となるかを指し示す言葉です。 • 合成監視は、実験計画法に基づいた品質管理用計測です。
- 50. 何故、RUM(Real User Monitoring)ではダメなの？ • 値を形作った変動要因（変数）があまりに多く、且つ、分解できない – ネットワーク要因 – 端末要因 – プラグインの影響 • 品質管理の原則 – 値を知っても、そこに手を出すことができない – コントロール可能な限界はどこかを知り、そこで計測する • 欠損値の存在の有無が確認できない – エラーになったり、観測値が取得できなかった場合には、その存在を知りえない – 欠損値のモデルをつくって分析しなくてはいけない – 欠損値を除外して分析すると、偏ったデータであるため、誤った結論へと導かれる(Garbage in, Garbage out) • Cookieベースの実装が多く、初回訪問の値は取得できない – AppleのITP(Intelligent Tracking Prevention)の影響をモロに受ける • 観察者効果がある – 計測用のJavaScriptが、パフォーマンスに影響を及ぼす
- 51. 正確度と精度 系統誤差と偶然誤差
- 52. 正確度と精度 • 正確度 – その値が「真値」に近い値であるかを示す尺度。 – 系統誤差の小ささを指す。 • ある測定における測定値に、同じ手法を用いて測定する限 り、「真の値」に対して系統的にずれて測定されるような誤 差 • 精度 – 複数回の観測値の間でのバラツキの小ささを示す尺 度 – 偶然誤差の小ささを指す。 • 測定ごとにばらつく誤差
- 60. 1回だけの計測は、何も保証できない • 統計学的には、最低でも1日あたり20～30の標本が 欲しい – 標本数が少ない場合は、検定が必須 • データの粒度 – 日単位の表示速度を算出したいのか – 時間単位の表示速度を算出したいのか
- 61. 偏差 ～ 平均値との「距離」を見る 平均 パフォーマンス 時 間 の 経 過 平均と実際の計測値との 差 1秒 2秒 3秒 4秒 5秒 6秒 7秒 8秒
- 62. 平均値と標準偏差
- 65. 1時間の計測
- 66. 12時間の計測
- 67. 24時間の計測
- 68. 7日間の計測
- 69. 30日間の計測
- 70. 中央値（Median）と75パーセンタイル値の 変化 中央値 75パーセンタイル値 1時間 896.00ミリ秒 1087.00ミリ秒 6時間 886.50ミリ秒 1057.00ミリ秒 24時間 855.00ミリ秒 950.00ミリ秒 1週間 847.00ミリ秒 943.00ミリ秒 2週間 846.00ミリ秒 962.00ミリ秒
- 73. 代表性とは • 調査・統計において、標本が母集団をよく代表して いるかどうかの程度を指す。 • モバイルサイトの計測をするのに、4Gエミュレートを して計測した結果は、携帯網でのパフォーマンスを 真に代表するにふさわしいのか？→ No • 自社のネットワークで計測した値は、他のISPでの値 を代表するにふさわしいのか？→ No • 東京で計測した値は、日本全国を代表するにふさわ しいのか？→No
- 75. 実験計画法に基づく計測 • 実験計画法 – 統計学の大家R・A・ フィッシャーが1920年代 に発案 – 現在の統計分析のデー タ取得の基礎となる。
- 76. 実験計画法 • 三つの基本原則 – 局所管理化 影響を調べる要因以外の全ての要因を可能な限り、 一定にする。 – 反復 実験ごとの偶然のばらつき(誤差)の影響を除くため に、同条件で反復して行う。 – 無作為化(ランダム化) 局所管理化や反復でも制御できない可能性のある要 因の影響を取り除き、偏りを小さくするために条件を 無作為化する。 計測を行う地域、時間、順序の影響を取り除くために、 ランダム化する。
- 77. 合成計測における実験計画法3原則の適用 • 三つの基本原則 – 局所管理化 影響を調べる要因以外の全ての要因を可能な限り、一定にする。 → 計測機器の統一、回線帯域の統一、ブラウザの統一 – 反復 実験ごとの偶然のばらつき(誤差)の影響を除くために、同条件で反復 して行う。 → 5～60分に1回の計測を24時間365日自動で計測する – 無作為化(ランダム化) 局所管理化や反復でも制御できない可能性のある要因の影響を取り 除き、偏りを小さくするために条件を無作為化する。 計測を行う地域、時間、順序の影響を取り除くために、ランダム化す る。 → 計測を行う時間をランダム化
- 80. 請負についての追完等の請求 引渡し日 契約目的不適合を顧客に通知 1年間 追完等の請求を1年以内に 品質の検査 請負側が行う （試験しないと知りようがないため通知その ものができないので重過失）
- 81. デスクトップサイトの 品質検査計測の計画 • 主要動線での計測を行う – トランザクション計測と言う – テンプレートが同じであれば、他のページでもほぼ同じ値となるので、全てのページを計測す る必要はない – ヒューリスティックキャッシュの影響を考慮して、現実的なパフォーマンス計測が可能 • 計測は、Synthetic Monitoringで行う – 変数を止めて、精度が高い、分解可能なデータを得る事ができる – 複数のISPで行うことが重要 – 計測拠点とISPは、当然ながら、実際のユーザの所在地の分布を考えて選出する – 実務上は、東京と大阪の、NTTとKDDIの計測で、人口の40%以上をカバーできる • 計測期間は、最低でも1カ月行う – 日次パターンだけでなく、週次パターンも得る事ができる。 – 15分に1回の計測であれば、1日あたりの標本の大きさは、1 ISPあたり96なので、十分な大 きさ。 – 1か月計測すると、2,976の標本サイズなので確からしさは十分にある。
- 82. モバイルサイトの 品質検査計測の計画 • 主要動線での計測を行う – トランザクション計測と言う – テンプレートが同じであれば、他のページでもほぼ同じ値となるので、全てのページを計測す る必要はない – ヒューリスティックキャッシュの影響を考慮して、現実的なパフォーマンス計測が可能 • 計測は、Synthetic Monitoringで行う – 変数を止めて、精度が高い、分解可能なデータを得る事ができる – できれば、3キャリアのリアル4Gで行う – 4Gエミュレートも併せて計測する – リアル4Gと4Gエミュレートと双方計測することで、遅延があった場合に、基地局やキャリアの コアネットワークに起因するのか、サーバに起因するのか、判別できる • 計測期間は、最低でも1カ月行う – 日次パターンだけでなく、週次パターンも得る事ができる。 – 15分に1回の計測であれば、1日あたりの標本の大きさは、1 ISPあたり96なので、十分な大 きさ。 – 1か月計測すると、2,976の標本サイズなので確からしさは十分にある。