Cloudflareを活用したWebパフォーマンスチューニング
•
0 gefällt mir•265 views
Webパフォーマンスチューニングは、統計的品質管理の手法を用いる事が大事です。高速化をしたつもりでも、それが全体の配信において、どの程度達成できているのかを確認しなければ、気づかない内にエンドユーザに遅延を体験させてしまう事になります。Webパフォーマンスチューニングは、速くすることに意義があるのではなく、遅い体験をさせないことに意義があるのです。Webパフォーマンスの計測についておさらいしつつ、CDNを使う意義と、Cloudflareでの設定の勘所を解説しました。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Ähnlich wie Cloudflareを活用したWebパフォーマンスチューニング
Ähnlich wie Cloudflareを活用したWebパフォーマンスチューニング (20)
Mehr von Yoichiro Takehora
Mehr von Yoichiro Takehora (16)
Kürzlich hochgeladen
Kürzlich hochgeladen (11)
Cloudflareを活用したWebパフォーマンスチューニング
- 2. • 経歴 - VMware 日本人初認定トレーナー - Akamai 技術コンサルタント - Verizon Businessの首席コンサルタント - Keynote Systems 日本代表 - Catchpoint Systems 日本代表 • 所属 - 日本技術者教育認定機構 広報・普及委員会 - 日本統計学会 - 情報処理学会 - 日本科学技術連盟 - Association for Computing Machinery - Computer Measurement Group - International Association for Information and Data Quality 竹洞 陽一郎 略歴 2
- 4. Webパフォーマンスとは? Webパフォーマンスとは、WebページがユーザのWebブラウ ザにダウンロードされて表示される速度のことを指します。 WPO(Web Performance Optimization)は、Webパフォーマ ンスの向上に関する知識の分野です。 Web Performance ― Wikipedia https://en.wikipedia.org/wiki/Web_performance Webパフォーマンスは、パフォーマンスエンジニアリングに 属する
- 6. パフォーマンスチューニングの本質 • 計算量を減らす • 計算資源を活用する • 計算の複雑さを単純化する
- 8. Webパフォーマンスの指標値の変遷 年 指標 策定者 1995 Download Time Keynote Systems 2009 Response Time, First Paint(Render Start), onload(Document Complete), Time To Interactive Keynote Systems, Microsoft 2011 DOM Content Loaded, Load W3C Web Performance Working Group 2012 Speed Index Webpage Test 2015 First Paint, First Contentful Paint, First Meaningful Paint Google 2020 First Input Delay, Cumulative Layout Shift Google 8
- 9. 指標値の関係 Download Time Response Time DNS Lookup TCP 3way handshakes SSL Request Wait Load Render Start (First Paint) DOM Content Loaded First Contentful Paint First Meaningful Paint First Input Delay Largest Contentful Paint Cumulative Layout Shift Document Complete (Load, Time To Interactive) Speed Index
- 10. 押さえるべき指標は3つで十分 • Response Time • Webページの設計図であるHTMLが届くまでの時間 • Render Start • 表示開始時間 • 表示開始時間が高速であれば、他の細かな指標は、些末 • Document Complete(Load) • ≒表示完了時間 • 文書処理が終わった時間 • 実装によっては、Render Startと前後する
- 12. Lighthouseによる評価
- 15. Google PageSpeed Insightsの問題点 • 計測マシンが遅い • 負荷が高いので、数値のバラツキが負荷に左右さ れて大きく発生する • モバイルの計測の設定が古い • 下り1.6Mbps • レイテンシ100ms • CPU性能悪い
- 20. 24時間の散布図
- 21. 1週間の散布図
- 22. 1ヶ月の散布図
- 23. この高速化に代金を支払いますか？
- 24. 品質管理が無かった戦前の日本
- 28. ISPで層別分解
- 31. Webサイトパフォーマンスの計測・監視手法 Last Mile First MileMiddle Mile web server エンドユーザ NTT KDDI エンドユーザ １次ISP RUM Synthetic Server side Last Mile
- 34. 各計測の補完関係 計測種別 長所 短所 サーバサイド計測 (Server-side Monitoring) インターネットの影響を受けていな いWebサーバ本来の表示速度を計測 できる。 サードパーティーコンテンツ、イン ターネットの通信状況の影響が見ら れない。 合成計測(Synthetic Monitoring) インターネットの影響を受けた、 ISP毎の表示速度を計測できる。 実験計画法に基づいた計測により、 問題点を特定する事が可能。 計測対象ページ以外については、 データが得られない。 リアルユーザ計測 (Real User Monitoring) エンドユーザが体験している表示速 度を取得することが可能。 エラー率が分からないので可用性分 析には使えない。 エラーになったユーザのデータは取 得出来ない。 実験に介入できていないので、因果 関係の証明はできない。 表示速度に関わる変数が非常に多く、 それらの数値が得られないため、品 質管理では使えない。 34
- 35. Synthetic Monitoringの始まり • Keynote Systems • 1995年創業、世界で初めてWebパフォーマンス計測の サービスを開始 • ユーザが実際に体験しているWebパフォーマンス のデータを収集したいが、Webブラウザでエンド ユーザが体験している表示速度を取得することは できなかった • そこで、Synthetic Dataを取得する事に
- 36. Synthetic Data(合成データ)とは 合成データは「直接測定によって得られていない所定の状況に適用でき る生成データ」である。 データ管理の専門家であるクレイグ S. ムリンズは、生成データを「ビジ ネスプロセスを実行するために専門家によって持続的に保存され使用さ れる情報」と定義している。 ― 科学技術用語辞典(マグローヒル)
- 38. Real User Monitoringとは • W3C Web Performance Working Groupが2011年 に創設される • Navigation Timingという指標が制定され、その指 標の計測がWebブラウザ内に実装されるように • 一般的には、Navigation Timing APIをJavaScript で叩いて、値を得る • アクセスした全ユーザのWebパフォーマンスの値 の取得が可能に
- 39. Real User Monitoringがあれば、 Synthetic Monitoringは要らない？
- 41. なぜSynthetic Monitoringが必要なのか？ • Synthetic Monitoringは、因果関係を証明する「実験データ」を提供す る • 統計学品質管理の基礎となるデータの取得方法に準拠 • 実験計画法（フィッシャー三原則） • 「変数を止める」事ができるので、重要な変動要因の影響を明確にできる • バックエンド処理 • ネットワーク • フロントエンド処理 • Real User Monitoringは、「観察データ」であり、因果関係を証明でき ない 41
- 42. 証拠のレベル レベル データの取り方 証拠の種別 1++ 実験 質の高いメタ・アナリシス、ランダム化比較試験(RCT)のシステマチック・レビュー、偏りのリ スクが非常に低いランダム化比較試験 1+ 実験 良く実施されたメタ・アナリシス、ランダム化比較のシステマチック・レビュー、偏りのリスク が低いランダム化比較試験 1- 実験 メタ・アナリシス、ランダム化比較試験のシステマチック・レビュー、偏りのリスクが高いラン ダム化比較試験 2++ 観察 質の高いケース・コントロールやコホート研究のシステマチックレビュー。交絡因子や偏りのリ スクが非常に低く、関係が因果である確率が高い、質の高いケース・コントロールやコホート研 究 2+ 観察 良く実施された、交絡因子や偏りのリスクが低く、関係が因果である確率がほどほどのケース・ コントロールやコホート研究 2- 観察 交絡因子や偏りのリスクが高く、関係が因果ではない確率がかなり高いケース・コントロールや コホート研究 3 実験でも観察でもない 分析的な研究ではないもの。例えば、事例報告、事例集 4 実験でも観察でもない 専門家の意見 Depression(俯角) ― National Guideline Clearinghouse （米国 保険社会福祉省運営機関)
- 43. 実験計画法に基づく計測 • 実験計画法 • 統計学の大家R・A・ フィッシャーが1920年 代に発案 • 現在の統計分析のデー タ取得の基礎となる。 43
- 44. 実験計画法 • フィッシャーの三原則 • 局所管理化 影響を調べる要因以外の全ての要因を可能な限り一定にする • 反復 実験ごとの偶然のばらつき(誤差)の影響を除くために、同条 件で反復して行う • 無作為化(ランダム化) 局所管理化や反復でも制御できない可能性のある要因の影響 を取り除き、偏りを小さくするために条件を無作為化する 計測を行う地域、時間、順序の影響を取り除くために、ラン ダム化する 44
- 45. 分布が大事 • 生年月日が1998年以前 • 「平均値」世代 • 統計学の教育を受けていない • 「分布？なにそれ？」 • データ分析＝国際競争力→平均しか知らないから正しい分析 ができない→競争力ない • 生年月日が1998年4月1日以降 • 統計教育世代 … 2014年から高校で「データの分析」が入る • 箱ひげ図分かる • 分布分かる • 統計的検定分かる
- 46. 以下のグラフの平均値は同じ 1秒 2秒 3秒 4秒 5秒 6秒 7秒 46
- 47. 偏差 ～ 平均値との「距離」を見る 平均 パフォーマン ス 時 間 の 経 過 平均と実際の計測値との 差 1秒 2秒 3秒 4秒 5秒 6秒 7秒 8秒 47
- 48. 平均値と標準偏差 48
- 50. 正確度と精度 • 正確度 • その値が「真値」に近い値であるかを示す尺度。 • 系統誤差の小ささを指す。 • ある測定における測定値に、同じ手法を用いて測定する限り、 「真の値」に対して系統的にずれて測定されるような誤差 • 精度 • 複数回の観測値の間でのバラツキの小ささを示す尺度 • 偶然誤差の小ささを指す。 • 測定ごとにばらつく誤差
- 54. ボトルネックの判定
- 57. 設計 実装 テスト プ ロ フ ァ イ リ ン グ リリース 運用 Web パ フ ォ ー マ ン ス 管 理 フィードバック プロファイリングとパフォーマンス管理
- 58. プロファイリングと計測 • プロファイリング • 特定環境での調査・試験 • 本番運用して、全国に展開した場合に、そのプロファイ リングの結果どおりになるとは限らない • 必ずばらつく • 計測 • 本番運用におけるバラツキの観測 • 実際の品質計測
- 60. 分解で追求するボトルネック 表示速度 フロントエンド DOM 構造化 計算量 CSSOM マッチング処理 複雑度 JavaScript フレームワーク 計算量 依存関係 サードパーティ 計算量 依存関係 ネットワーク DNS SSL 通信品質 帯域 パケットロス ネットワーク距 離 バックエンド システムトポロ ジー Webサーバ プログラム 計算量 順列・並列処理 コンテキストス イッチ 割り込み ハードウェア構 成 Load Balancer DBサーバ テーブル構造 Index SQL文 計算量 ハードウェア構 成 APIサーバ 計算量 コンテキストス イッチ 割り込み ハードウェア構 成 「ファイルの容量主義」… ここだけで本当にいいの？
- 61. パフォーマンスチューニング…帰納的アプローチ • Webパフォーマンス計測でデータを得る • 層別分解 • ボトルネックのあたりをつける • プロファイリングを行い、ボトルネックの特定を行う • ボトルネックを解消の解決策を生み出す • 解決策の実装 • プロファイリングで効果を確認 • Webパフォーマンス計測で配信品質への効果を確認
- 62. パフォーマンス設計 … 演繹的アプローチ • 目標値を定める • 目標値を達成するためのBudgetingを行う • 計算量の算出 • 計算資源の設計 • 計算資源への分配 • 単体テストでのプロファイリング • 結合テストでのプロファイリング • 総合テストでのプロファイリング • 運用でのWebパフォーマンステスト
- 63. V&Vモデル(Verification& Validation) Verification(検証) … 設計どおりに実装されたかどうか Validation(妥当性確認) … 設計され実装されて実現した機能や性能は、本来意図された用 途や目的に適って妥当か？
- 66. ソフトウェアの欠陥のコスト
- 67. システム開発では人数は武器にならない • ソフトウェア開発 → 人間の考えた論理の記述 • 技術者の人数より、その組織にいるトップの技術者の レベルで決まる • 普通のコックを何人集めても、ミシュランの三ツ星を取れる レストランにはなれないのと同じ • システムの力＝企業の競争力 • どれだけ優秀な技術者を獲得できるかで、企業の競争力が決 まる時代 • 優秀な一握りの技術者を獲得できない場合には、外部に求め る • 外注する場合には、その外注先の技術者の力量で決まる
- 69. CDNを使う勘所 • 計算量を減らすために • 画像やCSS、JavaScriptをCDNから配信することで、その分、Web サーバ側のコンテキストスイッチや割り込み数が減る • SSLの処理をCDNに任せることで計算量を減らせる • Webサーバは、テニスと同じ。どれだけ高速に打ち返せるかが勝負。 • ネットワーク距離を縮めるために • ネットワーク距離が伸びるほどに、関与するネットワーク機器が増 える • ネットワーク機器が増えるほどに、ばらつきが合成される • 計算資源として活用する • Edge Computing … CDNを計算資源として利用する
- 70. 計算量が全てを決める • 動的処理は、オリジンサーバでやっても、CDNで やっても処理コストになる • その計算、毎回必要ですか？ • 画像の最適化 • ページ生成 • 1回の計算で済むものは、1回で済ませて使い回す
- 71. SSL/TLS
- 73. ファイルサイズの最適化
- 74. 高速化機能OFFの場合
- 75. 高速化機能ONの場合
- 76. Argo
- 77. Browser Insights
- 78. Cloudflareを使う時の注意点 • 現在、NTTドコモでDNSの名前解決が遅い • マッピングがまだ改良の余地がある • 例）大阪J:COMで、東京のデータセンターから配信され る どんなCDNであっても「Trust, but Verify」は大事
- 79. Spelldataは、高速化でお役立ちできます • Cloudflareの認定マネージド・サービスプロバイダーです！ (アジア、日本初) • 他のCDNからの移行、承けたまります • Spelldata経由でCloudflareをご契約頂くと、品質保証用として、Catchpointの 計測を無料でご提供します。 (トップページ、光回線のみ) • EdgeComputing、ガリガリいけます • Webパフォーマンスの高速化も承ります。 • 各ページを表示開始0.5秒、表示完了1秒、全体の98パーセンタイルで実現します。 • 結果を保証します。 • オリジンサーバの高速化のためのOracle Cloudへの移行も承ります