Webサイトパフォーマンス管理の基礎知識
•
43 likes•13,728 views
2016年3月5日に大阪・梅田で開催された、frontend conference 2016での講演資料です。
Recommended
More Related Content
What's hot
What's hot (10)
Viewers also liked
Viewers also liked (20)
Similar to Webサイトパフォーマンス管理の基礎知識
Similar to Webサイトパフォーマンス管理の基礎知識 (20)
More from Yoichiro Takehora
More from Yoichiro Takehora (13)
Webサイトパフォーマンス管理の基礎知識
- 1. frontend conference 2016 Webサイトパフォーマンス管理 の基礎知識 2016年3月5日 竹洞 陽一郎 yoichiro.takehora@spelldata.co.jp ytakehora@catchpoint.com
- 2. 自己紹介 株式会社Spelldata 代表取締役社長、Catchpoint Systems日本代表 ACM(Association for Computing Machinery)会員 CMG(Computer Measurement Group)会員 ISACA(Information Systems Audit and Control Association)会員 日本統計学会賛助会員 html5j パフォーマンス部部長 統計学を基礎から学ぶ! 中西塾主催 Webサイトパフォーマンスに関係する仕事を始めて、もう13年目 やってきた事 VMware … 日本人初のVCPトレーナー Akamai … プロフェッショナルサービス Verizon Business … プリンシパルコンサルタント Keynote Systems … 日本代表
- 4. Catchpoint SystemsのCEO Mehdi Daoudi
- 7. 今日、お話する内容 「速さ」はなぜ、重要なのか? 人によって違う速度の感じ方 遅延は止める理由 Webサイトパフォーマンス計測手法 その秒数は、何をどこまで保証できるのか? 層別に計測・分析する Webサイトパフォーマンス改善の手順 おまけ まとめ
- 13. Webサイトに期待するもの Webサイトに期待すること 1 2 3 4 サンプ ル数 平均レート コンテンツの新しさや更新頻度 39% 400 29% 295 19% 191 13% 127 1,013 2.04 パフォーマンス （バッファリングなしで、動画再生、 ページの読み込みが速い等） 52% 523 26% 266 9% 87 14% 137 1,013 1.84 モバイルサイトとデスクトップサイト の体験が同一であること 20% 205 27% 274 35% 356 17% 177 1,012 2.50 パーソナライズされたコンテンツ 12% 117 18% 182 26% 259 44% 447 1,005 3.03 Limelight Networks http://img03.en25.com/Web/LLNW/%7Bb97f8e45-2370-4f4b-8c8e-fa4141051c72%7D_2014StateoftheUserExperience.pdf
- 15. 速いサイトは、見てもらえる
- 19. ヴェーバー ― フェヒナーの法則 精神物理学 ヴェーバー ― フェヒナーの法則 心理的な感覚量(心理量:R)は、物理的な刺激の量(物理量:S)の対数に比例 する 𝑅 = 𝑘log10 𝑆 (kは感覚定数)
- 22. 年齢による時間の感覚のズレ Yomiuri Online ― 「こころの元気塾」 時間感覚…年齢、状況でずれる「心の時計」 http://www.yomidr.yomiuri.co.jp/page.jsp?id=35447
- 23. New Scientistの記事 ミネソタ大学のGeoffrey Ghose とBlaine Schneiderの研究発表 (2012年10月30日) ニューロンの活動が活発である と、時間感覚が伸びる 逆にストレスを感じているときは、 アドレナリンがニューロンの活 動を妨げるため、時間感覚が 速くなる http://www.newscientist.com/article/dn22446-brain-circuits-run-their-own-clocks.html
- 25. 年齢層に対するバイアスを外す どんな年代であっても、新しいものが好きな人と、そうでない人がい る 若い世代＝トレンドについてきている、年配の年代＝トレンドについ てこれない、などとは思わないように! 総務省「平成26年情報通信メディアの利用時間と情報に関する調 査」などを参照して下さい。 http://www.soumu.go.jp/main_content/000357568.pdf
- 26. Webサイトパフォーマンス改善手法 Best Practice V.S. Evidence-based Improvements
- 28. 速くなりません
- 32. 事象の背後にある原因が違うと、解決策は 変わる 問題の 事象 解決策B 解決原因B 原因A 原因C 解決策C 解決策A
- 33. 事象例：画像が重い 計測してみたら、画像が重いと出た ベストプラクティス： 画像を軽量化しなさい→速くならない 過去の事例 Windowsのサーバを使っており、NTFSでフォーマットされたディスクパーティ ションを80%以上使っていた NFSでNASをマウントして使っていた HTMLの生成と、画像の配信を同じディスク上で行って、ディスクのアクセス 競合が発生していた
- 34. ベストプラクティスとは? ある結果を得るのに、最も効率の良い技法、手法、プロセス、活動 の事。 ベストプラクティスは、変化のない固定的なものではない。 ベストプラクティスとは、常に学習し、改善し続ける精神であるとも言 える。
- 35. 健康法
- 42. 治療＝改善作業
- 43. エンジニアは「医師」であるべき
- 45. 計測の仕方 Last Mile First MileMiddle Mile web server エンドユーザ NTT KDDI エンドユーザ １次ISP RUM （Real User Monitoring） Synthetic Monitoring Server-side Monitoring
- 46. 各計測の補完関係 計測種別 長所 短所 サーバサイド計測 (Server-side Monitoring) インターネットの影響を受けていない Webサーバ本来の表示速度を計測で きる。 サードパーティーコンテンツ、インター ネットの通信状況の影響が見られない。 合成計測(Synthetic Monitoring) インターネットの影響を受けた、ISP毎 の表示速度を計測できる。 実験計画法に基づいた計測により、問 題点を特定する事が可能。 計測対象ページ以外については、 データが得られない。 リアルユーザ計測 (Real User Monitoring) エンドユーザが体験している表示速度 を取得することが可能。 エラー率が分からないので可用性分 析には使えない。 エラーになったユーザのデータは取得 出来ない。 実験に介入できていないので、因果関 係の証明はできない。 表示速度に関わる変数が非常に多く、 それらの数値が得られないため、品質 管理では使えない。
- 48. お勧めの計測手法 ― 合成計測 統計的品質管理で重要な「実験計画法」に基づいた計測 Actionable Data（実行可能データ）が取得できる 数学的に証明が可能
- 49. 実験計画法に基づく計測 実験計画法 統計学の大家R・A・フィッシャー が1920年代に発案 現在の統計分析のデータ取得の 基礎となる。
- 50. 実験計画法 三つの基本原則 局所管理化 影響を調べる要因以外の全ての要因を可能な限り、一定にする。 反復 実験ごとの偶然のばらつき(誤差)の影響を除くために、同条件で反復して行 う。 無作為化(ランダム化) 局所管理化や反復でも制御できない可能性のある要因の影響を取り除き、 偏りを小さくするために条件を無作為化する。 計測を行う地域、時間、順序の影響を取り除くために、ランダム化する。
- 51. The Art of Computer Systems Performance Analysis Techniques for Experimental Design, Measurement, Simulation, and Modeling 米国ワシントン大学をはじめとして、コンピューターシステムのパフォーマンス計測 についての定番教科書
- 52. 合成計測における実験計画法3原則の適用 三つの基本原則 局所管理化 影響を調べる要因以外の全ての要因を可能な限り、一定にする。 → 計測機器の統一、回線帯域の統一、ブラウザの統一 反復 実験ごとの偶然のばらつき(誤差)の影響を除くために、同条件で反復して行 う。 → 5～60分に1回の計測を24時間365日自動で計測する 無作為化(ランダム化) 局所管理化や反復でも制御できない可能性のある要因の影響を取り除き、 偏りを小さくするために条件を無作為化する。 計測を行う地域、時間、順序の影響を取り除くために、ランダム化する。 → 計測を行う時間をランダム化
- 53. 計測時間のパターン化
- 54. 計測時間のパターン化
- 55. 計測時間のランダム化
- 56. 計測時間のランダム化
- 57. 24時間365日計測する必要性 インターネットは高速道路と非 常によく似ている 自分が出発する道路状況だけ を見ていては、目的地に辿り着 く時間の予測が狂うのと同じ。 途中経路の混雑状況をチェック しなくては、確かな到着予想時 刻は算出できない。 インターネットの中は、常に状 況が変わっています。 ユーザに自社Webサイトが確実 に閲覧可能な状態かどうかは、 計測しないと分からない。
- 60. Resource Timing
- 62. 1時間のデータ
- 63. 6時間のデータ
- 64. 24時間のデータ
- 65. 1週間のデータ
- 66. 2週間のデータ
- 71. 1回だけの計測は、何も保証できない 統計学的には、最低でも1日あたり20～30の標本が欲しい 標本数が少ない場合は、検定が必須 データの粒度 日単位の表示速度を算出したいのか 時間単位の表示速度を算出したいのか
- 72. 偏差 ～ 平均値との「距離」を見る 平均 パフォーマンス 時 間 の 経 過 平均と実際の計測値との差 1秒 2秒 3秒 4秒 5秒 6秒 7秒 8秒
- 73. 平均値と標準偏差
- 75. 中心極限定理 ｎが大きい時、標本平均と真の平均の差、 തｘ -μが従う分布は、平均0、 分散σ2/𝑛の正規分布に近づく 平均തｘ 平均തｘ 平均തｘ
- 76. 中央値（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ミリ秒
- 79. 東京（NTT）
- 80. 東京（KDDI）
- 81. 東京（AWS）
- 82. 大阪（Azure）
- 84. 数値による要約 平均値 標準偏差 四分位 範囲 0% 25% 50% 75% 100% 大阪 Azure 1120.98 463.01 287.00 698 907 1008 1194 7965 東京 AWS 839.68 385.50 145.25 533 712 771 857.25 6184 東京 KDDI 921.90 548.69 131.00 551 802 865 933.00 18545 東京 NTT 844.77 372.71 115.00 539 738 789 853.00 7725 N=2121
- 85. 以下のグラフの平均値は同じ 1秒 2秒 3秒 4秒 5秒 6秒 7秒
- 87. 箱ひげ図 ― 配信品質を比べる
- 89. Webサイトパフォーマンス改善の手順 1. 計測計画を立案する 2. データの収集 3. データの分析 4. 問題を解決する 5. 計測して、事前・事後の変化を見る 6. 次の問題を明確化
- 90. 1. 計測計画の立案 主要動線でのページ遷移計測 ユーザ体験としての始めから終わりまでの時間としてのパフォーマンスを計 測する 分散の加法性 トップページ→商品検索→商品詳細→カート→決済という、5ページの遷移がある場合、 この動線の平均とばらつきは、各ページの平均やばらつきを合計したものとなる 制約条件の理論（TOC: Theory of Constraints） A chain is only as strong as its weakest link. 主要動線が分からない場合 トップページ〜システムの特性が分かりやすい RUMで計測して、全体を把握してみる
- 91. 「ザ・ゴール」
- 92. 2. データの収集 エラー率をまず把握する 繋がらないのが、最も悪い現象 10秒以上かかっている場合は、エラーと同じと見なす ユーザーは離脱してしまう 各種測定タグを入れていても、データを取得できないことが多い 全てのページを計測する必要はない 「テンプレート」と「サーバ構成」で考える 測定の単位を決める 1日単位の場合、最低でも1時間に1回の計測→24の標本を得ることができる 時間単位の場合、最低でも5分に1回の計測→12の標本を得ることができる 最低でも3日は計測する 普通は、2週間以上計測する 日次パターン、週次パターンを把握するため 月次パターンを把握するためには、3ヶ月以上計測する
- 93. 3. データの分析 全体から部分へと降りていく たまたまなのか、よくあることなのかを判断 パターンを把握する〜外れ値と思っても、実はパターンであることが多い 下のレイヤーから上のレイヤーへと分析を進める ネットワーク→ハードウェア→OS→アプリケーション→HTML, CSS, JavaScript ここ7〜8年の傾向として、サードパーティーコンテンツが遅延要因に なっているので、サードパーティーと交渉するための証拠としての データが必要
- 94. スマートフォンサイト（LTE）
- 95. 週次パターンの例
- 99. Google Page Speed Insightでは分からない
- 100. 4. 問題の解決 動線のページ遷移中のWeakest Link（一番遅いページ）から解決す る パレートの法則で改善する 「何かを加える」のではなく、「何かを減らす」考え方が大事 KISS（Keep It Simple, Stupid!）の法則 デザインの語源は「削る」という意味である。不要なものを消して、最適なも のを選ぶことだ。けっして「足して飾る」ことではない。（森 博嗣） 連動性を考える 画像を減らす→HDDのアクセスが軽減される Cache-Control Headerを設定する→If-Modified-Sinceリクエストが減る→ネッ トワークが楽になる（Self DoS攻撃） 本質的な情報だけを残す→ビジネスモデルや、セールスモデルの見直し 影響の範囲を考える DNSのTTLを短くする→DNSサーバの負荷が上がる、携帯網のDNSの負荷が 上がる
- 102. SSL NegotiationDNS Lookup Content Download Initial Connection First Byte Download Client Time 自社DNSサーバ 負荷 相手先DNS サーバ負 荷 DNS TTL DNS TTL DNS攻撃負 荷 接続負荷 Keep Alive設定 同時接続数 ページ滞留時 間 ページあたりの オブジェクト数 ページあたりの 容量 DNSラウンドロビン 暗号化方 式 瞬間鍵処 理能力 暗号化対 象 プログラミング言語 型類 推 CP U メモリ Webサーバ処 理時間 ハードウェア性 能 IOPS 動的生 成処理 サーバサイ ドキャッシュ DBサーバ処 理時間 DBタイプ ACID特性データ量 データ モデリング Webサー バ MO D プロセ ス優先 度 ディスク接続方式(Fibre Channel, iSCSI, SATA) ファイルシステ ム CP U ディスクアクセ ス 競合制御方式 ストレージ種別(SSD, HDD, Hybrid) パーティショ ン サイズ 暗号強 度 ロバストネス 性 ディス ク 使用 量 キャッシュメモリ動作方式(Write Through, Write Back) Webブラウザの種 類 ブラウザキャッシュ設 定 キャッ シュ有効 期限 アクセス パターン 圧縮配 信 事前圧 縮 CP U Web サ イ ト パ フ ォ ー マ ン ス DOM処理特 性 HTTP同時接続 数 独自実装 接続の順番 自社接続ドメイン 数 3rd Party接続ドメイン 数 ネットワーク状 態 レイテンシ 経路 JavaScript 処理性能 HTMLドキュメント構 成 HTML記 述 文法エ ラー divネスト構 造 DOMオブジェクト 数 ネットワーク状 態 帯域 経路 レイテンシ CSS定義構 造 読み込みファイル 数 Override定義 数 文法エ ラー SSL通信検査 JavaScriptコー ド 処理効率 バグ含有 率 接続応答 性 複雑 度 接続方式 実装方 式 特性要因図
- 103. ネットワークは混雑する一方
- 104. 「意外と」不安定なインターネット網 インターネットは、どこかの組織が 一元的に統括・管理しているわけで はない。 様々なネットワーク(AS)の集合体 ネットワーク間で、パケットをバケツ リレーしている 想像を絶する構成ノード数 ノード数の増加は、「ムーアの法則」(18ヶ 月毎に倍になる)に従っている 常にどこかでノードが故障している 2016年3月7日 104 ©2012 Keynote Systems, Inc. http://iopscience.iop.org/1367-2630/10/12/123027/fulltext/ AS(autonomous system)レベルでの ノード数の増加
- 105. 郊外の基地局配置 1つの円で20～30Kmをカバー。 その分、電波が強い。 色の違い＝チャネルのグループの違 い。 NTTドコモの場合、 800MHz帯を使い、 15MHzの幅がある。 それを12.5KHz幅で区切ることで、 15MHz/12.5KHz = 1200チャネルを持 つ。 もし7つのグルーピングを作るとすると、 各基地局は 1200/7≒170チャネルと なる。
- 107. ソフトバンクの「マイクロセル化」
- 108. 制約の多いモバイルネットワーク 電波干渉という問題 ユーザがそこに多く居るからと言って、電波塔（基地局）は増やせない 基地局を乱立するとどうなるか? – “Dirty WiFi”と同じ状況に 電波の「谷間」～基地局と基地局の中間点 「繋がる」事と「通信できる」事は、違う アンテナの表示が5本中5本立った! → 電波強度が十分というだけ 携帯基地局は、混雑するとネットワークを守るためにパケットを意図的にド ロップする レイテンシの問題 モバイルネットワークのレイテンシは3Gで100～200ms、4Gで40〜60ms 2016年3月7日 108 ©2012 Keynote Systems, Inc..
- 109. 携帯網のパケットドロップ率の影響 無線基地局のパケットドロップ率が20%、1パケット1KBの場合 1.全部で100KBのデータを送信する場合 失敗回数の期待値＝{100×(1-0.8)}÷0.8=25 失敗回数の分散={100×(1-0.8)}÷0.8^2 =31.25 失敗回数の標準偏差は、31.25の平方根、約6となります。 2σの考え方だと、 下値＝失敗回数の期待値－2×失敗回数の分散の平方根 上値＝失敗回数の期待値＋2×失敗回数の分散の平方根 2σ（シグマ）の範囲を計算すると、(25－2×6, 25+2×6)=(13, 37) 95%の確率で13～37回の失敗（パケットドロップ）が発生します。 2.全部で1,000KBのデータを送信する場合 失敗回数の期待値＝{1,000×(1-0.8)}÷0.8=250 失敗回数の分散={1,000×(1-0.8)}÷0.8^2 =312.5 失敗回数の標準偏差は、312.5の平方根、約18となります。 2σ（シグマ）の範囲を計算すると、(250－2×18, 250+2×18)=(214, 286) 95%の確率で214～286回の失敗（パケットドロップ）が発生します。
- 111. 5. 次の問題の明確化 高速化すると、必ずアクセス数が増える 今まで、問題として見えなかった箇所が、問題となる
- 114. DevOpsとは 開発担当者と運用担当者が連 携して協力する開発手法 Velocity 2009でFlickrのエンジニ アによって、初めて、この言葉 が使われた
- 115. 具体的なイメージを掴みたいなら… 「The DevOps 逆転だ!」 日経BP社 2200円 原題”The Phoenix Project”
- 117. トップページの容量
- 118. トップページの接続ホスト数
- 120. トップページのオブジェクト数
- 121. HTML文法エラー数
- 122. HTML文法エラー数0〜200個
- 124. まとめ Webサイトパフォーマンス管理は、品質管理です 統計学を学び、品質管理手法を学ぶと、Webサイトパフォーマンス の管理をする上で、幸せになれます Webサイトの高速化が何よりも大事です パフォーマンスの遅延は「病気」ですから、健康法の実践ではなく、 きちんと診察をして治療をしましょう いろいろ計測手法がありますが、実験計画法の三原則が鍵を握り ます 標本と真の値の違いを認識しましょう Webサイトパフォーマンスの改善にはPPDACサイクルを適用しましょ う DevOpsでは、パフォーマンスと可用性が品質の重要な指標です
- 126. Q&A