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

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

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

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

Yoichiro Takehora

November 19, 2020
Tweet

More Decks by Yoichiro Takehora

Other Decks in Technology

Transcript

  1. • 経歴 - VMware 日本人初認定トレーナー - Akamai 技術コンサルタント - Verizon

    Businessの首席コンサルタント - Keynote Systems 日本代表 - Catchpoint Systems 日本代表 • 所属 - 日本技術者教育認定機構 広報・普及委員会 - 日本統計学会 - 情報処理学会 - 日本科学技術連盟 - Association for Computing Machinery - Computer Measurement Group - International Association for Information and Data Quality 竹洞 陽一郎 略歴 2
  2. パフォーマンスエンジニアリング パフォーマンスエンジニアリングは、システム開発のライフサイクルの中で、パフォーマンスに対する非機能的な要件(スループッ ト、レイテンシ、メモリ使用量など)を確実に満たすために適用される技術を網羅しています。 システム・エンジニアリングの中のシステム・パフォーマンス・エンジニアリング、ソフトウェア・エンジニアリングの中のソフト ウェア・パフォーマンス・エンジニアリングまたはアプリケーション・パフォーマンス・エンジニアリングとも呼ばれることがあり ます。 アプリケーションの成功とビジネスの成功との関連性が、特にモバイル分野で認識されるようになるにつれ、アプリケーション・パ フォーマンス・エンジニ アリングは、ソフトウェア開発のライフサイクルの中で、予防的かつ完全な役割を担うようになりました。 そのため、この用語は一般的に、非機能的な要件を効果的にテストし、サービスレベルを確実に遵守し、デプロイ前にアプリケー

    ションのパフォーマンスを最適化するために必要なプロセス、人材、および技術を説明するために使用されています。 パフォーマンスエンジニアリングという用語は、ソフトウェアとそれをサポートするインフラストラクチャだけでなく、それ以上の ものを含んでいるため、パフォーマンスエンジニアリングという用語は、マクロな視点から見ることが望ましいです。 非機能要件への準拠は、本番システムを監視することで、デプロイ後にも検証されます。 これはITサービス管理の一部です。(ITILも参照すること) パフォーマンス・エンジニアリングは、多くの大企業において、システム・エンジニアリングとは別個の、しかし並行して行われて いるタスクを持つ別個の規律となっています。 これは、複数の組織単位からの人々が関与し、普及していますが、主に情報技術の組織内で行われています。 Performance Engineering ― Wikipedia https://en.wikipedia.org/wiki/Performance_engineering
  3. 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
  4. 指標値の関係 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
  5. 押さえるべき指標は3つで十分 • Response Time • Webページの設計図であるHTMLが届くまでの時間 • Render Start •

    表示開始時間 • 表示開始時間が高速であれば、他の細かな指標は、些末 • Document Complete(Load) • ≒表示完了時間 • 文書処理が終わった時間 • 実装によっては、Render Startと前後する
  6. 各計測の補完関係 計測種別 長所 短所 サーバサイド計測 (Server-side Monitoring) インターネットの影響を受けていな いWebサーバ本来の表示速度を計測 できる。

    サードパーティーコンテンツ、イン ターネットの通信状況の影響が見ら れない。 合成計測(Synthetic Monitoring) インターネットの影響を受けた、 ISP毎の表示速度を計測できる。 実験計画法に基づいた計測により、 問題点を特定する事が可能。 計測対象ページ以外については、 データが得られない。 リアルユーザ計測 (Real User Monitoring) エンドユーザが体験している表示速 度を取得することが可能。 エラー率が分からないので可用性分 析には使えない。 エラーになったユーザのデータは取 得出来ない。 実験に介入できていないので、因果 関係の証明はできない。 表示速度に関わる変数が非常に多く、 それらの数値が得られないため、品 質管理では使えない。 34
  7. Synthetic Monitoringの始まり • Keynote Systems • 1995年創業、世界で初めてWebパフォーマンス計測の サービスを開始 • ユーザが実際に体験しているWebパフォーマンス

    のデータを収集したいが、Webブラウザでエンド ユーザが体験している表示速度を取得することは できなかった • そこで、Synthetic Dataを取得する事に
  8. Real User Monitoringとは • W3C Web Performance Working Groupが2011年 に創設される

    • Navigation Timingという指標が制定され、その指 標の計測がWebブラウザ内に実装されるように • 一般的には、Navigation Timing APIをJavaScript で叩いて、値を得る • アクセスした全ユーザのWebパフォーマンスの値 の取得が可能に
  9. なぜSynthetic Monitoringが必要なのか? • Synthetic Monitoringは、因果関係を証明する「実験データ」を提供す る • 統計学品質管理の基礎となるデータの取得方法に準拠 • 実験計画法(フィッシャー三原則)

    • 「変数を止める」事ができるので、重要な変動要因の影響を明確にできる • バックエンド処理 • ネットワーク • フロントエンド処理 • Real User Monitoringは、「観察データ」であり、因果関係を証明でき ない 41
  10. 証拠のレベル レベル データの取り方 証拠の種別 1++ 実験 質の高いメタ・アナリシス、ランダム化比較試験(RCT)のシステマチック・レビュー、偏りのリ スクが非常に低いランダム化比較試験 1+ 実験

    良く実施されたメタ・アナリシス、ランダム化比較のシステマチック・レビュー、偏りのリスク が低いランダム化比較試験 1- 実験 メタ・アナリシス、ランダム化比較試験のシステマチック・レビュー、偏りのリスクが高いラン ダム化比較試験 2++ 観察 質の高いケース・コントロールやコホート研究のシステマチックレビュー。交絡因子や偏りのリ スクが非常に低く、関係が因果である確率が高い、質の高いケース・コントロールやコホート研 究 2+ 観察 良く実施された、交絡因子や偏りのリスクが低く、関係が因果である確率がほどほどのケース・ コントロールやコホート研究 2- 観察 交絡因子や偏りのリスクが高く、関係が因果ではない確率がかなり高いケース・コントロールや コホート研究 3 実験でも観察でもない 分析的な研究ではないもの。例えば、事例報告、事例集 4 実験でも観察でもない 専門家の意見 Depression(俯角) ― National Guideline Clearinghouse (米国 保険社会福祉省運営機関)
  11. 実験計画法 • フィッシャーの三原則 • 局所管理化 影響を調べる要因以外の全ての要因を可能な限り一定にする • 反復 実験ごとの偶然のばらつき(誤差)の影響を除くために、同条 件で反復して行う

    • 無作為化(ランダム化) 局所管理化や反復でも制御できない可能性のある要因の影響 を取り除き、偏りを小さくするために条件を無作為化する 計測を行う地域、時間、順序の影響を取り除くために、ラン ダム化する 44
  12. 分布が大事 • 生年月日が1998年以前 • 「平均値」世代 • 統計学の教育を受けていない • 「分布?なにそれ?」 •

    データ分析=国際競争力→平均しか知らないから正しい分析 ができない→競争力ない • 生年月日が1998年4月1日以降 • 統計教育世代 … 2014年から高校で「データの分析」が入る • 箱ひげ図分かる • 分布分かる • 統計的検定分かる
  13. 偏差 ~ 平均値との「距離」を見る 平均 パフォーマン ス 時 間 の 経

    過 平均と実際の計測値との 差 1秒 2秒 3秒 4秒 5秒 6秒 7秒 8秒 47
  14. Webパフォーマンスの「真値」とは? • RUMの値が「真値」なのか? web server エンドユーザ NTT KDDI エンドユーザ 1次ISP

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

    Synthetic Monitoringの値 RUMの値 確率的に推測でき る 割り算で 劣化率が測れる 変数を分解できないの でたどり着けない
  16. 設計 実装 テスト プ ロ フ ァ イ リ ン

    グ リリース 運用 Web パ フ ォ ー マ ン ス 管 理 フィードバック プロファイリングとパフォーマンス管理
  17. 分解で追求するボトルネック 表示速度 フロントエンド DOM 構造化 計算量 CSSOM マッチング処理 複雑度 JavaScript

    フレームワーク 計算量 依存関係 サードパーティ 計算量 依存関係 ネットワーク DNS SSL 通信品質 帯域 パケットロス ネットワーク距 離 バックエンド システムトポロ ジー Webサーバ プログラム 計算量 順列・並列処理 コンテキストス イッチ 割り込み ハードウェア構 成 Load Balancer DBサーバ テーブル構造 Index SQL文 計算量 ハードウェア構 成 APIサーバ 計算量 コンテキストス イッチ 割り込み ハードウェア構 成 「ファイルの容量主義」… ここだけで本当にいいの?
  18. パフォーマンスチューニング…帰納的アプローチ • Webパフォーマンス計測でデータを得る • 層別分解 • ボトルネックのあたりをつける • プロファイリングを行い、ボトルネックの特定を行う •

    ボトルネックを解消の解決策を生み出す • 解決策の実装 • プロファイリングで効果を確認 • Webパフォーマンス計測で配信品質への効果を確認
  19. パフォーマンス設計 … 演繹的アプローチ • 目標値を定める • 目標値を達成するためのBudgetingを行う • 計算量の算出 •

    計算資源の設計 • 計算資源への分配 • 単体テストでのプロファイリング • 結合テストでのプロファイリング • 総合テストでのプロファイリング • 運用でのWebパフォーマンステスト
  20. システム開発では人数は武器にならない • ソフトウェア開発 → 人間の考えた論理の記述 • 技術者の人数より、その組織にいるトップの技術者の レベルで決まる • 普通のコックを何人集めても、ミシュランの三ツ星を取れる

    レストランにはなれないのと同じ • システムの力=企業の競争力 • どれだけ優秀な技術者を獲得できるかで、企業の競争力が決 まる時代 • 優秀な一握りの技術者を獲得できない場合には、外部に求め る • 外注する場合には、その外注先の技術者の力量で決まる
  21. CDNを使う勘所 • 計算量を減らすために • 画像やCSS、JavaScriptをCDNから配信することで、その分、Web サーバ側のコンテキストスイッチや割り込み数が減る • SSLの処理をCDNに任せることで計算量を減らせる • Webサーバは、テニスと同じ。どれだけ高速に打ち返せるかが勝負。

    • ネットワーク距離を縮めるために • ネットワーク距離が伸びるほどに、関与するネットワーク機器が増 える • ネットワーク機器が増えるほどに、ばらつきが合成される • 計算資源として活用する • Edge Computing … CDNを計算資源として利用する
  22. Spelldataは、高速化でお役立ちできます • Cloudflareの認定マネージド・サービスプロバイダーです! (アジア、日本初) • 他のCDNからの移行、承けたまります • Spelldata経由でCloudflareをご契約頂くと、品質保証用として、Catchpointの 計測を無料でご提供します。 (トップページ、光回線のみ)

    • EdgeComputing、ガリガリいけます • Webパフォーマンスの高速化も承ります。 • 各ページを表示開始0.5秒、表示完了1秒、全体の98パーセンタイルで実現します。 • 結果を保証します。 • オリジンサーバの高速化のためのOracle Cloudへの移行も承ります