Cloudflareを活用したWebパフォーマンスチューニング

Webパフォーマンスチューニングは、統計的品質管理の手法を用いる事が大事です。高速化をしたつもりでも、それが全体の配信において、どの程度達成できているのかを確認しなければ、気づかない内にエンドユーザに遅延を体験させてしまう事になります。Webパフォーマンスチューニングは、速くすることに意義があるのではなく、遅い体験をさせないことに意義があるのです。Webパフォーマンスの計測についておさらいしつつ、CDNを使う意義と、Cloudflareでの設定の勘所を解説しました。

Transcript

1. Cloudflareを活用した Webパフォーマンスチューニング 2020年11月19日 株式会社Spelldata 代表取締役社長 竹洞 陽一郎
2. • 経歴 - VMware 日本人初認定トレーナー - Akamai 技術コンサルタント - Verizon Businessの首席コンサルタント - Keynote Systems 日本代表 - Catchpoint Systems 日本代表 • 所属 - 日本技術者教育認定機構 広報・普及委員会 - 日本統計学会 - 情報処理学会 - 日本科学技術連盟 - Association for Computing Machinery - Computer Measurement Group - International Association for Information and Data Quality 竹洞 陽一郎 略歴 2
3. Webパフォーマンスとは? 非機能要求の「性能」「可用性」要件
4. Webパフォーマンスとは? Webパフォーマンスとは、WebページがユーザのWebブラウ ザにダウンロードされて表示される速度のことを指します。 WPO(Web Performance Optimization)は、Webパフォーマ ンスの向上に関する知識の分野です。 Web Performance ― Wikipedia https://en.wikipedia.org/wiki/Web_performance Webパフォーマンスは、パフォーマンスエンジニアリングに 属する
5. パフォーマンスエンジニアリング パフォーマンスエンジニアリングは、システム開発のライフサイクルの中で、パフォーマンスに対する非機能的な要件（スループッ ト、レイテンシ、メモリ使用量など）を確実に満たすために適用される技術を網羅しています。 システム・エンジニアリングの中のシステム・パフォーマンス・エンジニアリング、ソフトウェア・エンジニアリングの中のソフト ウェア・パフォーマンス・エンジニアリングまたはアプリケーション・パフォーマンス・エンジニアリングとも呼ばれることがあり ます。 アプリケーションの成功とビジネスの成功との関連性が、特にモバイル分野で認識されるようになるにつれ、アプリケーション・パ フォーマンス・エンジニ アリングは、ソフトウェア開発のライフサイクルの中で、予防的かつ完全な役割を担うようになりました。 そのため、この用語は一般的に、非機能的な要件を効果的にテストし、サービスレベルを確実に遵守し、デプロイ前にアプリケー ションのパフォーマンスを最適化するために必要なプロセス、人材、および技術を説明するために使用されています。 パフォーマンスエンジニアリングという用語は、ソフトウェアとそれをサポートするインフラストラクチャだけでなく、それ以上の ものを含んでいるため、パフォーマンスエンジニアリングという用語は、マクロな視点から見ることが望ましいです。 非機能要件への準拠は、本番システムを監視することで、デプロイ後にも検証されます。 これはITサービス管理の一部です。（ITILも参照すること） パフォーマンス・エンジニアリングは、多くの大企業において、システム・エンジニアリングとは別個の、しかし並行して行われて いるタスクを持つ別個の規律となっています。 これは、複数の組織単位からの人々が関与し、普及していますが、主に情報技術の組織内で行われています。 Performance Engineering ― Wikipedia https://en.wikipedia.org/wiki/Performance_engineering
6. パフォーマンスチューニングの本質 • 計算量を減らす • 計算資源を活用する • 計算の複雑さを単純化する
7. 「富嶽」は、ファイル容量を減らして世界1位になりましたか？
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と前後する
11. 高速だと、細かい指標はあまり意味がない
12. Lighthouseによる評価
13. 東京、大阪、福岡の各ISPでの計測(1週間)
14. Google PageSpeed Insightsだと…
15. Google PageSpeed Insightsの問題点 • 計測マシンが遅い • 負荷が高いので、数値のバラツキが負荷に左右さ れて大きく発生する • モバイルの計測の設定が古い • 下り1.6Mbps • レイテンシ100ms • CPU性能悪い
16. Google PageSpeed Insightsの性能
17. Google PageSpeed Insightsのネットワーク
18. 統計的品質管理による パフォーマンス管理 真に事業に結果をもたらすために
19. 表示完了1秒を目標とした 高速化サービスを提供している他社の事例 一見すると、非常によく高速化できているように見える
20. 24時間の散布図
21. 1週間の散布図
22. 1ヶ月の散布図
23. この高速化に代金を支払いますか？
24. 品質管理が無かった戦前の日本
25. 統計的品質管理を最初に導入したアメリカ軍
26. 表示完了1秒以内は、全体の何%で達成？
27. 変曲点 … グラフのカーブの角度が変わる点
28. ISPで層別分解
29. Trust, but verify 「信頼するが、検証する」は、 韻を踏んだロシア語のことわざ である。 このフレーズは、ロナルド・ レーガン大統領がソ連との核軍 縮協議の文脈で何度か使用した 際に、英語で国際的に知られる ようになった。 Wikipedia https://en.wikipedia.org/wiki/T rust,_but_verify
30. 統計的品質管理は 市場競争における重要な鍵
31. Webサイトパフォーマンスの計測・監視手法 Last Mile First Mile Middle Mile web server エンドユーザ NTT KDDI エンドユーザ １次ISP RUM Synthetic Server side Last Mile
32. 品質管理の原則 • コントロールできるところに集中する。コントロールでき ないところのデータを取っても無駄になる。 web server エンドユーザ NTT KDDI エンドユーザ １次ISP コントロール可能な範疇 コントロール大 コントロール小 コントロール不可能な範疇
33. 「美しい人はより美しく、そうでない方はそれなりに」
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. ムリンズは、生成データを「ビジ ネスプロセスを実行するために専門家によって持続的に保存され使用さ れる情報」と定義している。 ― 科学技術用語辞典(マグローヒル)
37. Synthetic Monitoringとは • 直接、エンドユーザの体験しているWebパフォー マンスのデータを得られないので、1ユーザとして 能動的にWebページにアクセスして、データを生 成する＝合成する
38. Real User Monitoringとは • W3C Web Performance Working Groupが2011年 に創設される • Navigation Timingという指標が制定され、その指 標の計測がWebブラウザ内に実装されるように • 一般的には、Navigation Timing APIをJavaScript で叩いて、値を得る • アクセスした全ユーザのWebパフォーマンスの値 の取得が可能に
39. Real User Monitoringがあれば、 Synthetic Monitoringは要らない？
40. 研究デザインの分類 因果関係を証明できる のは実験データのみ
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
49. 統計的品質管理で重要な概念 • 正確度と精度 • 標本の大きさ • 代表性
50. 正確度と精度 • 正確度 • その値が「真値」に近い値であるかを示す尺度。 • 系統誤差の小ささを指す。 • ある測定における測定値に、同じ手法を用いて測定する限り、 「真の値」に対して系統的にずれて測定されるような誤差 • 精度 • 複数回の観測値の間でのバラツキの小ささを示す尺度 • 偶然誤差の小ささを指す。 • 測定ごとにばらつく誤差
51. 正確度と精度 低い 低い 正確度 高い 精度 高い 真値～ 神様だけが 知っている値
52. Webパフォーマンスの「真値」とは？ • RUMの値が「真値」なのか？ web server エンドユーザ NTT KDDI エンドユーザ １次ISP コントロール可能な範疇 コントロール大 コントロール小 コントロール不可能な範疇 表示完了1秒 表示完了1.2秒 表示完了1.5秒
53. 正確度と精度 低い 低い 正確度 高い 精度 高い 真値～ 神様だけが 知っている値 Synthetic Monitoringの値 RUMの値 確率的に推測でき る 割り算で 劣化率が測れる 変数を分解できないの でたどり着けない
54. ボトルネックの判定
55. トヨタの自動車の作り方 開発 •企画 •デザイン •設計 •試作・評価 生産技術 •生産性検討 •工程計画→設備検 討→設備調達 •設備トライ→品質 確認→量産化 生産 •プレス •溶接 •塗装 •組立 •検査
56. 検査だけが品質管理ではない 1か月 検査 (無料) 6か月 検査 (無料) 1年 検査 3年 検査 品質フィードバック
57. 設計 実装 テスト プ ロ フ ァ イ リ ン グ リリース 運用 Web パ フ ォ ー マ ン ス 管 理 フィードバック プロファイリングとパフォーマンス管理
58. プロファイリングと計測 • プロファイリング • 特定環境での調査・試験 • 本番運用して、全国に展開した場合に、そのプロファイ リングの結果どおりになるとは限らない • 必ずばらつく • 計測 • 本番運用におけるバラツキの観測 • 実際の品質計測
59. プロファイリングとは ソフトウェアエンジニアリングにおいて、プロファイリングとは、動的 プログラム解析の一種で、例えばプログラムの空間(メモリ)とか計算時間、 特定の命令の使用、関数呼び出しの頻度と時間経過を計測する。 通常、プロファイリングの情報は、プログラムの最適化の助けとなるた めに提供される。 プロファイリングは、プログラムのソースコードや実行可能バイナリの どちらかをプロファイラー(もしくはコードプロファイラー)と呼ばれる ツールで計測することで成される。 プロファイラーは、イベントベース、統計的、計測、シミュレーション 手法など、多数の異なるテクニックが使われる。 Profiling (computer programming) ― Wikipedia
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(妥当性確認) … 設計され実装されて実現した機能や性能は、本来意図された用 途や目的に適って妥当か？
64. VモデルからWモデルへ 非機能要求ガイド (経済産業省 ソフトウェア開発力強化推進タスクフォース 要求工学・設計開発技術研究部会) より引用
65. 問題の修正を後回しにするほどに費用が嵩む
66. ソフトウェアの欠陥のコスト
67. システム開発では人数は武器にならない • ソフトウェア開発 → 人間の考えた論理の記述 • 技術者の人数より、その組織にいるトップの技術者の レベルで決まる • 普通のコックを何人集めても、ミシュランの三ツ星を取れる レストランにはなれないのと同じ • システムの力＝企業の競争力 • どれだけ優秀な技術者を獲得できるかで、企業の競争力が決 まる時代 • 優秀な一握りの技術者を獲得できない場合には、外部に求め る • 外注する場合には、その外注先の技術者の力量で決まる
68. Cloudflareの機能設定の勘所
69. CDNを使う勘所 • 計算量を減らすために • 画像やCSS、JavaScriptをCDNから配信することで、その分、Web サーバ側のコンテキストスイッチや割り込み数が減る • SSLの処理をCDNに任せることで計算量を減らせる • Webサーバは、テニスと同じ。どれだけ高速に打ち返せるかが勝負。 • ネットワーク距離を縮めるために • ネットワーク距離が伸びるほどに、関与するネットワーク機器が増 える • ネットワーク機器が増えるほどに、ばらつきが合成される • 計算資源として活用する • Edge Computing … CDNを計算資源として利用する
70. 計算量が全てを決める • 動的処理は、オリジンサーバでやっても、CDNで やっても処理コストになる • その計算、毎回必要ですか？ • 画像の最適化 • ページ生成 • 1回の計算で済むものは、1回で済ませて使い回す
71. SSL/TLS
72. 他社のSSL証明書を入れるとOCSPで遅延
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への移行も承ります