Upgrade to Pro — share decks privately, control downloads, hide ads and more …

品質検査としてのWebパフォーマンス計測手法

 品質検査としてのWebパフォーマンス計測手法

Webパフォーマンス(表示速度)は、非機能要求であり、その品質保証には、世界的には統計的品質管理が用いられています。

今、日本で広く用いられているGoogle PageSpeed Insightsや、WebPage Testなどは、品質検査ツールではなく、ITの専門家たるエンジニアは、統計的品質管理による品質保証を行わなくてはいけません。

では、具体的にどのような標準化や規格があり、どのような団体が存在し、どのような計測手法があるのでしょうか?

その詳細と統計分析の観点での重要な概念を解説しました。

Yoichiro Takehora

June 19, 2019
Tweet

More Decks by Yoichiro Takehora

Other Decks in Technology

Transcript

  1. 開発は請負契約 • 開発については、従来通り請負型の契約となる。 • 超上流工程は、専門家が設計するため、実現可能性が高くな る – システム化の方向性 – システム化計画立案

    – 要件定義策定 • 超上流工程に問題がある場合には、その作業を行った専門家 が善管注意義務を負う • 超上流工程で、専門家が設計した、実現可能性が担保された システムを構築するので、理論上は、その通りにつくれば良 いので、請負契約となる
  2. 性能品質とは • 性能品質が良い・悪い – バラツキが小さい事が、「品質が良い」 – バラツキが大きい事が、「品質が悪い」 • ある目標値に達しているかどうかも大事だが、 その達成度がばらついている場合には、品質が

    悪い • 品質管理の目的は、「品質目標に適合しないも のを世に出さない」こと。 – Webパフォーマンスの場合、それは不可能で あるため、「将来」の結果へと繋げる
  3. 標準化の重要性 • 経産省が進める「戦略的国際標準化加速事業」 – 世界に対してモノやサービスを販売する際に、そ の品質の優位性をアピールする、もしくは品質検 査して品質保証する必要がある – 独自の品質検査では、相手に受け入れられない –

    品質検査の標準化が重要 – 標準化された品質検査手法に則り、品質保証を行 う事で、品質保証がスムーズに進む – 品質検査手法が、適切ではない場合に、適切な指 標の設定と、その品質検査を標準化することで、 独自の市場を開拓していく
  4. The Art of Computer Systems Performance Analysis Techniques for Experimental

    Design, Measurement, Simulation, and Modeling 米国ワシントン大学をはじめとして、コンピューターシステムのパフォーマ ンス計測についての定番教科書
  5. 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
  6. ISO25000における3つの非機能要求 • 時間挙動(Time Behavior) – 一般的に、時間挙動の評価が最も一般的なパフォーマンステストの目的。 – パフォーマンス・テストのこの側面では、コンポーネントまたはシステムが、指定さ れた時間内に指定された条件下でユーザーまたはシステムの入力に応答する能力を調 べる。

    – 時間挙動の測定値はシステムが消費する「エンドツーエンド」時間、ユーザー入力へ の応答時間、ソフトウェア・コンポーネントが特定のタスクを実行するために必要な CPUサイクル数などがある。 • リソース使用率(Resource Utilization) – システム・リソースの可用性がリスクとして識別されると、特定の性能試験を実施す ることにより、これらの資源(例えば、限られたRAMの割り当て)の利用状況を調査す ることができる。 • キャパシティ(Capacity) – システムの要求される容量限界におけるシステム挙動の問題(ユーザー数やデータ量 など)がリスクとして特定された場合、性能試験を実施してシステムアーキテクチャ の適合性を評価してもよい。
  7. パフォーマンステストの種別 1 • パフォーマンステスト – パフォーマンステストは包括的な用語で、さまざまな負荷の下でのシステムまたはコンポーネントのパ フォーマンス(応答性)に焦点を当てたあらゆる種類のテストを含む。 • 負荷テスト –

    負荷テストは、制御された数の同時ユーザーまたはプロセスによって生成されたトランザクション要求か ら生じる、予想される現実的な負荷の増加レベルを処理するシステムの機能に焦点を当てている。 • ストレステスト – ストレステストは、予測または指定されたワークロードの限界または限界を超えるピーク負荷を処理する システムまたはコンポーネントの能力に重点を置く。 – ストレステストは、アクセス可能なコンピューティング能力、使用可能な帯域幅、メモリなど、リソース の可用性が低下した場合のシステムの処理能力を評価するためにも使用される。 • スケーラビリティテスト – 拡張性テストは、現在必要とされている以上の将来の効率要件を満たすシステムの能力に焦点を当てる。 – このテストの目的は、現在指定されているパフォーマンス要件に違反したり障害が発生したりすることな く、システムが拡張(たとえば、ユーザー数が多いほど、保存されるデータの量が増える)できるかどうかを 判断すること。 – スケーラビリティの限界がわかったら、本番環境でしきい値を設定して監視し、発生する可能性のある問 題を警告する。また、適切な量のハードウェアを使用して本番環境を調整することもできる。
  8. パフォーマンステストの種別 2 • スパイクテスト – スパイクテストは、ピーク負荷の突然のバーストに正しく応答し、その後定常状態に 戻るシステムの能力に焦点を当てている。 • 耐久性テスト –

    耐久性テストでは、システムの運用コンテキストに固有の時間枠におけるシステムの 安定性に重点が置く。 – このタイプのテストでは、最終的にパフォーマンスの低下やブレークポイントでの障 害の原因となるリソース容量の問題(メモリー・リーク、データベース接続、スレッ ド・プールなど)がないことを確認する。 • 同時接続性テスト – 同時接続性テストでは、特定のアクションが同時に発生した場合(たとえば、多数の ユーザーが同時にログインする場合)の影響に重点が置かれる。 – 同時接続性の問題は、特に本番環境のようにテストがほとんど制御できない環境で問 題が発生した場合、発見して再現することが非常に困難であることで知られている。 • キャパシティテスト – 容量テストでは、特定のシステムでサポートされ、規定されたパフォーマンス目標を 満たすユーザーやトランザクションの数を決定する。 – これらの目標は、取引から生じるデータ量に関しても設定される。
  9. 品質モデル ISO/IEC 2501n 品質モデルと品質測定値 34 製品品質モデル ISO/IEC25010 データ品質モデル ISO/IEC25012 利用時品質モデル

    ISO/IEC25010 人間―コンピュータシステム 情報システム 通信システム 対象コンピュータシステム ハードウェア 非対象 ソフトウェア 対象 ソフトウェア 対象 データ 非対象 データ 一次利用者 二次利用者 もしくは 間接利用者 利用環境 Webパフォーマンスは、利用時品質に属します。
  10. 利用時品質モデル 利用時の品質 有効性 有効性 効率性 効率性 満足性 実用性 信用性 快感性

    快適性 リスク回避性 経済リスク緩 和性 健康・安全リ スク緩和性 環境リスク緩 和性 利用状況網羅 性 利用状況完全 性 柔軟性 35
  11. 品質評価プロセス(JIS X0133-1= ISO/IEC14598) 39 評価要求の確立 評価の仕様化 評価の設計 評価の実施 評価目的の確立 評価対象製品の種別の識別

    品質モデルの仕様化 測定法の選択 測定法のための評定水準の確立 総合評価のための基準の確立 評価計画の作成 測定値の収集 基準との比較 結果との総合評価
  12. Developer Toolは「プロファイラー」 • プロファイリングとは – ソフトウェアエンジニアリングにおいて、プロファイリン グとは、動的プログラム解析の一種で、例えばプログラム の空間(メモリ)とか計算時間、特定の命令の使用、関数呼 び出しの頻度と時間経過を計測する。 –

    通常、プロファイリングの情報は、プログラムの最適化の 助けとなるために提供される。 – プロファイリングは、プログラムのソースコードや実行可 能バイナリのどちらかをプロファイラー(もしくはコード プロファイラー)と呼ばれるツールで計測することで成さ れる。 – プロファイラーは、イベントベース、統計的、計測、シ ミュレーション手法など、多数の異なるテクニックが使わ れる。
  13. 設計 実装 テスト プ ロ フ ァ イ リ ン

    グ リリース 運用 Web パ フ ォ ー マ ン ス 管 理 フィードバッ ク プロファイリングとパフォーマンス管 理
  14. Webサイトパフォーマンスの計測・監視 手法 Last Mile First Mile Middle Mile web server

    エンドユーザ NTT KDDI エンドユーザ 1次ISP RUM Synthetic Server side Last Mile
  15. 各計測の補完関係 計測種別 商品名 長所 短所 サーバサイド監視 (Server-side Monitoring) OnPrem インターネットの影響を

    受けていないWebサーバ 本来の表示速度を計測で きる。 サードパーティーコンテ ンツ、インターネットの 通信状況の影響が見られ ない。 合成監視 (Synthetic Monitoring) Synthetic Monitoring インターネットの影響を 受けた、ISP毎の表示速度 を計測できる。 実験計画法に基づいた計 測により、問題点を特定 する事が可能。 計測対象ページ以外につ いては、データが得られ ない。 リアルユーザ監視 (Real User Monitoring) Real User Monitoring エンドユーザが体験して いる表示速度を取得する ことが可能。 エラー率が分からないの で可用性分析には使えな い。 エラーになったユーザの データは取得出来ない。 実験に介入できていない ので、因果関係の証明は できない。 表示速度に関わる変数が 非常に多く、それらの数 値が得られないため、品 質管理では使えない。
  16. 外形監視という言葉は日本製 • 勝手に言葉をつくるな • Synthetic Monitoringを「外形監視」と称しているが、 Synthetic Monitoringの語源は、Synthetic Dataから来 ている。外形監視というのは、適切な訳語ではない。

    • 合成データは「直接測定によって得られていない所定の 状況に適用できる生成データ」である。 – Webパフォーマンスの場合、直接測定によって得ら れたデータはRUM(Real User Monitoring)である。 – Synthetic Monitoringは、測定機器から能動的に1 ユーザとしてアクセスすることで、生成されたパ フォーマンスのデータを獲得するものである。
  17. 世界で用いられている計測手法 Synthetic Monitoring(合成監視) • 統計学に基づいた品質管理手法 – 計測データは、必ずばらつきます。 • システムの状態 •

    負荷状態 • インターネット通信網の状態の変化 – 計測値は、決して、一つの値に定まりません。 – 現在の表示速度が、どのくらいの確率で確かな値であるか を求める必要があります。 • 統計学では、「信頼区間」と言います。 信頼区間とは、同じ計測を行った場合に、どれくらいの確率で 同じ結果となるかを指し示す言葉です。 • 合成監視は、実験計画法に基づいた品質管理用計測です。
  18. 何故、RUM(Real User Monitoring)ではダメなの? • 値を形作った変動要因(変数)があまりに多く、且つ、分解できない – ネットワーク要因 – 端末要因 –

    プラグインの影響 • 品質管理の原則 – 値を知っても、そこに手を出すことができない – コントロール可能な限界はどこかを知り、そこで計測する • 欠損値の存在の有無が確認できない – エラーになったり、観測値が取得できなかった場合には、その存在を知りえない – 欠損値のモデルをつくって分析しなくてはいけない – 欠損値を除外して分析すると、偏ったデータであるため、誤った結論へと導かれる (Garbage in, Garbage out) • Cookieベースの実装が多く、初回訪問の値は取得できない – AppleのITP(Intelligent Tracking Prevention)の影響をモロに受ける • 観察者効果がある – 計測用のJavaScriptが、パフォーマンスに影響を及ぼす
  19. Webパフォーマンスの「真値」とは? • RUMの値が「真値」なのか? web server エンドユーザ NTT KDDI エンドユーザ 1次ISP

    コントロール可能な範疇 コントロール大 コントロール小 コントロール不可能な範疇 表示完了1秒 表示完了1.2秒 表示完了1.5秒
  20. 正確度と精度 低い 低い 正確度 高い 精度 高い 真値~ 神様だけが 知っている値

    Synthetic Monitoringの値 RUMの値 確率的に推測で きる 割り算で 劣化率が測れる 変数を分解できない のでたどり着けない
  21. 偏差 ~ 平均値との「距離」を見る 平均 パフォーマン ス 時 間 の 経

    過 平均と実際の計測値との 差 1秒 2秒 3秒 4秒 5秒 6秒 7秒 8秒
  22. 中央値(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ミリ秒
  23. 代表性とは • 調査・統計において、標本が母集団をよく代表 しているかどうかの程度を指す。 • モバイルサイトの計測をするのに、4Gエミュ レートをして計測した結果は、携帯網でのパ フォーマンスを真に代表するにふさわしいの か?→ No

    • 自社のネットワークで計測した値は、他のISPで の値を代表するにふさわしいのか?→ No • 東京で計測した値は、日本全国を代表するにふ さわしいのか?→No
  24. 実験計画法 • 三つの基本原則 – 局所管理化 影響を調べる要因以外の全ての要因を可能な限り、 一定にする。 – 反復 実験ごとの偶然のばらつき(誤差)の影響を除くた

    めに、同条件で反復して行う。 – 無作為化(ランダム化) 局所管理化や反復でも制御できない可能性のある 要因の影響を取り除き、偏りを小さくするために 条件を無作為化する。 計測を行う地域、時間、順序の影響を取り除くた めに、ランダム化する。
  25. 合成計測における実験計画法3原則の適用 • 三つの基本原則 – 局所管理化 影響を調べる要因以外の全ての要因を可能な限り、一定にする。 → 計測機器の統一、回線帯域の統一、ブラウザの統一 – 反復

    実験ごとの偶然のばらつき(誤差)の影響を除くために、同条件 で反復して行う。 → 5~60分に1回の計測を24時間365日自動で計測する – 無作為化(ランダム化) 局所管理化や反復でも制御できない可能性のある要因の影響を 取り除き、偏りを小さくするために条件を無作為化する。 計測を行う地域、時間、順序の影響を取り除くために、ランダ ム化する。 → 計測を行う時間をランダム化
  26. デスクトップサイトの 品質検査計測の計画 • 主要動線での計測を行う – トランザクション計測と言う – テンプレートが同じであれば、他のページでもほぼ同じ値となるので、全てのページ を計測する必要はない –

    ヒューリスティックキャッシュの影響を考慮して、現実的なパフォーマンス計測が可 能 • 計測は、Synthetic Monitoringで行う – 変数を止めて、精度が高い、分解可能なデータを得る事ができる – 複数のISPで行うことが重要 – 計測拠点とISPは、当然ながら、実際のユーザの所在地の分布を考えて選出する – 実務上は、東京と大阪の、NTTとKDDIの計測で、人口の40%以上をカバーできる • 計測期間は、最低でも1カ月行う – 日次パターンだけでなく、週次パターンも得る事ができる。 – 15分に1回の計測であれば、1日あたりの標本の大きさは、1 ISPあたり96なので、十 分な大きさ。 – 1か月計測すると、2,976の標本サイズなので確からしさは十分にある。
  27. モバイルサイトの 品質検査計測の計画 • 主要動線での計測を行う – トランザクション計測と言う – テンプレートが同じであれば、他のページでもほぼ同じ値となるので、全てのページを計測する必 要はない –

    ヒューリスティックキャッシュの影響を考慮して、現実的なパフォーマンス計測が可能 • 計測は、Synthetic Monitoringで行う – 変数を止めて、精度が高い、分解可能なデータを得る事ができる – できれば、3キャリアのリアル4Gで行う – 4Gエミュレートも併せて計測する – リアル4Gと4Gエミュレートと双方計測することで、遅延があった場合に、基地局やキャリアのコ アネットワークに起因するのか、サーバに起因するのか、判別できる • 計測期間は、最低でも1カ月行う – 日次パターンだけでなく、週次パターンも得る事ができる。 – 15分に1回の計測であれば、1日あたりの標本の大きさは、1 ISPあたり96なので、十分な大きさ。 – 1か月計測すると、2,976の標本サイズなので確からしさは十分にある。