WordPressとWeb高速化バックエンド編 CDNの仕組み / wordpress backend web site speed trick cdn

by katsuhisa ogawa

Slide 1

Slide 1 text

WordPressの Web高速化術（バックエンド編）バックエンド Web高速化道玄坂 WordPress Meetup #4 〜Web表示高速化〜

Slide 2

Slide 2 text

About me 2 ABOUT ME JOB ：合同会社レッドボックス CEO Name：小川かつひさ (KATSUHISA OGAWA） Like ：キャッシュ・負荷分散・Web高速化 https://www.facebook.com/ogawaka https://blog.redbox.ne.jp @ogawaka キャッシュ屋で検索

Slide 3

Slide 3 text

執筆・査読 3 ABOUT ME Software Design 2018年6月号特集 CDN［超］活用ガイド高速配信の舞台裏「現場のプロから学ぶ SEO技術バイブル」 Web高速化セクション査読

Slide 4

Slide 4 text

Web高速化大会優勝（WordPress） 4 ABOUT ME 第3回CMSプロレスウェブページ速度改善「最速王者決定戦」優勝 concrete5, MovableTypeが並ぶ中、唯一WordPressで挑んで優勝！

Slide 5

Slide 5 text

2018 Word CampTokyo 5 ABOUT ME 2018 WordCamp Tokyo スタッフ 2018 WordCampTokyo Web高速化について登壇

Slide 6

Slide 6 text

Today’s AGENDA 6 ✓ お題：バックエンドの高速化 ✓ ターゲット：ミドルウェアやサーバーを操作できること ✓ ゴール：コストを抑えたユーザー体験の向上

Slide 7

Slide 7 text

7 そもそもWeb高速化とは？

Slide 8

Slide 8 text

Web高速化とは 8 Webサイトの表示速度を早くすること。 13 sec 3 sec

Slide 9

Slide 9 text

遅いWebサイト・速いWebサイトとは？ 9 遅いWeｂ速いWeb .

Slide 10

Slide 10 text

Web高速化とは 10 Web表示速度のムラを無くすこと。

Slide 11

Slide 11 text

Web高速化とは 11 Web高速化の共通点ユーザー体験を向上させること。

Slide 12

Slide 12 text

12 Web高速化の項目

Slide 13

Slide 13 text

Web高速化でおこなう対策項目 13 Web高速化対策する項目が山のようにある

Slide 14

Slide 14 text

Web高速化の種類 14 ✓ コンテンツ最適化（画像圧縮・Minify） ✓ レンダリング処理最適化 ✓ スクリプト処理最適化 ✓ ネットワーク速度 ✓ サーバースペック ✓ プロトコル（HTTP2） ✓ キャッシュ（CDN） ✓ ミドルウェア最適化（Webサーバー・DB） ✓ コンテンツ圧縮（Gzip Brotli）

Slide 15

Slide 15 text

Web高速化の主な2つの対策項目 15 1：バックエンド 2：フロントエンドコンテンツがダウンロードされた後の工程コンテンツがダウンロードされるまでの工程今回はこちらのお話

Slide 16

Slide 16 text

16 バックエンドの主な対策項目

Slide 17

Slide 17 text

バックエンド対策項目 17 クライアントが、画像などのコンテンツをダウンロードするまでの工程バックエンドの最適化 ✓ ネットワーク速度 ✓ サーバースペック ✓ プロトコル（HTTP2） ✓ キャッシュ（CDN） ✓ ミドルウェア最適化（Webサーバー・DB） ✓ コンテンツ最適化（Gzip Brotli Webp）

Slide 18

Slide 18 text

バックエンド対策項目 18 ✓とりあえずパラメーターの値を増やす 1024 → 2048

Slide 19

Slide 19 text

バックエンド対策項目 19 ✓とりあえずサーバースペック上げる

Slide 20

Slide 20 text

バックエンド対策項目 20 ✓とりあえず高速化関連プラグインを導入

Slide 21

Slide 21 text

バックエンド対策項目 21 ✓とりあえず色々インフラの仕組みを変更

Slide 22

Slide 22 text

Web高速化の種類 22 根拠がない変更はNG！逆に悪化することや何かのタイミングで不具合を発生させる恐れがある。

Slide 23

Slide 23 text

23 Web高速化は調査からはじまる。コレをしておけばOK！というおまじないは存在しない。 Don’t guess, measure! （推測するな、計測せよ！）

Slide 24

Slide 24 text

24 適切なモニタリングと計測

Slide 25

Slide 25 text

Web表示速度の計測 25 Google Analyticsでどのページが遅いのかを確認行動 ↓ サイトの速度 ↓ ページ速度

Slide 26

Slide 26 text

Web表示速度の計測 26 Chrome Developer Tool

Slide 27

Slide 27 text

Web表示速度の計測 27 Google製昔からあるやつ。昨年Light Houseエンジンを搭載 Page Speed Insight（https://www.webpagetest.org）

Slide 28

Slide 28 text

Web表示速度の計測 28 Googleが中心となって開発しているオープンソースの合成モニタリングツール WebPagetest（https://www.webpagetest.org）・発生した通信処理の一覧・ウォーターフォールチャート・一定期間毎のスクリーンショット・プライベートインスタンスの提供・低速回線からのアクセス・ブラウザやデバイス指定・アクセス地域の指定

Slide 29

Slide 29 text

Web表示速度の計測 29 WebPagetest（https://www.webpagetest.org）

Slide 30

Slide 30 text

どちらが問題なのか 30 問題はフロントエンドか、それともバックエンドか

Slide 31

Slide 31 text

フロントエンドかバックエンドか 31 TTFB （Time To First Byte）が、300ms以上 OR NOT？ ※Googleが200ms以下を推奨しているためこの数値を目標とすること。 TTFBの値平常時と遅いときの速度差平常時との表示速度が1.5倍以上の差 OR NOT? いずれかが該当するならばバックエンド側を疑うべき。 ※アクセス元ロケーションデバイス等は同一とする

Slide 32

Slide 32 text

32 バックエンドの調査順序

Slide 33

Slide 33 text

33 1. サーバーのリソースが適切に利用されているか 2. 通信関連にボトルネックはないか 3. キャッシュを利用できているか 4. ミドルウェアの構成は正しいか

Slide 34

Slide 34 text

34 サーバーリソース編（CPU/MEMORY/DISK IO） CPUは何パーセント消費しているのか？ではない。

Slide 35

Slide 35 text

CPU編 35 • USRが高くSYSが低いのがLinuxでは一般的。 • SYSがUSRより高いまたは同等の場合は、OSに起因する潜在的な問題の可能性が高い • IOWAITだけが高い場合はDISKの読み書き速度に問題がある可能性が高い %usr %nice %sys %iowait %irq %soft %steal %guest CPUコア毎に何パーセント使っているのか（マルチコアの場合） CPUのどの項目が利用されているか Core1 98％ Core2 5％ CPU(２Core) 片側だけしか使われていない可能性あり！

Slide 36

Slide 36 text

36 サーバーリソース編（CPU/MEMORY/DISK IO）メモリーの空き容量が十分かどうか？ではない

Slide 37

Slide 37 text

Memory編 37 • SLABキャッシュが増加している場合、PHP-FPMのチューニングが必要 • SWAPを利用している場合、Memoryが足りない可能性あり ※CentOSなどの標準カーネルは、メモリーが足りていても少しだけSWAPをつかう闇仕様 MemTotal: 1012060 kB MemFree: 154340 kB Buffers: 99096 kB Cached: 323236 kB SwapCached: 0 kB Dirty: 0 kB Shmem: 600 kB Slab: 69348 kB Hugepagesize: 2048 kB メモリー使用率の種類どのメモリー空間を利用しているのか

Slide 38

Slide 38 text

38 サーバーリソース編（CPU/MEMORY/DISK IO） DISK IOはどのプロセスが占有しているか

Slide 39

Slide 39 text

DSIK IO編 39 • プロセス毎にDISKの読込み・書き込み状況が把握できる。dstat -ta --top-io-adv --top-bio-adv • 大抵はMysqlが多く利用しているケースが多い。 • PHPが読み書きを多くしている場合は、バッチ処理やプラグインの処理で重くなっている可能性が高い。プロセス毎のI/O どのプロセスがDISK I/Oを利用しているかDSTATで確認。ココ！！

Slide 40

Slide 40 text

40 通信・キャッシュ編（DNS/キャッシュ）見落としがちなDNS応答速度

Slide 41

Slide 41 text

DNS編 41 DNSの速度と重要性 Webサイトを訪れるユーザーは、ドメインの名前解決をDNSサーバーで行う。この名前解決が遅いケースがある。※無料DNSを利用している場合は注意ドメイン名を解決 www.redbox.ne.jp ⑴ DNS xxx.xxx.xxx.xxx

Slide 42

Slide 42 text

DNS編 42 DNSベンダーの速度計測サイト https://www.dnsperf.com WordPress.comが4位！

Slide 43

Slide 43 text

43 通信・キャッシュ編（DNS/キャッシュ）爆速を手に入れるためのキャッシュ

Slide 44

Slide 44 text

キャッシュ編 44 複数のキャッシュタイプクライアントキャッシュ Webサーバー中間キャッシュサーバーサイドキャッシュブラウザ内のキャッシュ CDNなどの外部キャッシュ APC Memcached

Slide 45

Slide 45 text

キャッシュ編 45 クライアントキャッシュクライアントキャッシュブラウザ内のキャッシュブラウザやアプリ内でキャッシュさせる手法。 ETAGやCache-Controlヘッダーをコンテンツのレスポンス時に追加する。 • NginxやApacheなどサーバー側 • .htaccess • PHPプログラム

Slide 46

Slide 46 text

キャッシュ編 46 サーバーサイドキャッシュ APCやMemcachedでシステム側のリソース負荷を削減 Webサーバーサーバーサイドキャッシュ APC Memcached WordPressのプラグイン Memcached Redux（リダックス） WP Memcached Manager

Slide 47

Slide 47 text

キャッシュ編 47 中間キャッシュエッジサーバー CDNでキャッシュ配信することによって、ある程度安定したTTFBを維持・DBなどミドルウェアに影響されないレスポンスを提供。 Webサーバークライアントキャッシュ DNSを変更するだけでＯＫ！

Slide 48

Slide 48 text

48 ミドルウェア構成編（Webサーバー/データベース）パラメーターの意味をしっかり理解すること

Slide 49

Slide 49 text

ミドルウェア構成編 49 Core数＝Workerかどうか Nginxの場合、Core数に応じたWorkerを立ち上げているか Core1 Core２ Worker1 worker_processes auto; Core1 Core２ Worker1 Worker2 リクエストを処理するWorkerが足りないリクエストを処理するWorkerを増やす

Slide 50

Slide 50 text

ミドルウェア構成編 50 WorkerとCoreは1対1かどうか Workerがそれぞれのコアを参照するようにしているか Core1 Core２ Worker1 Worker2 worker_cpu_affinity auto; Core1 Core２ Worker1 Worker2

Slide 51

Slide 51 text

51 ミドルウェア構成編（Webサーバー/データベース）正しいチューニング・スローログの出力

Slide 52

Slide 52 text

ミドルウェア構成編 52 データベースの基本Mysql Tunerでスキャンまずはパラメーター。しっかりメモリーを利用できているかなど基本が重要 https://github.com/rackerhacker/MySQLTuner-perl

Slide 53

Slide 53 text

ミドルウェア構成編 53 MySQLTuner実行結果

Slide 54

Slide 54 text

ミドルウェア構成編 54 スロークエリーログの出力スロークエリーログとは、SQLの実行にかかった時間のしきい値超えを保存する仕組み my.cnf [mysqld] slow_query_log=1 long_query_time=1 log_queries_not_using_indexes=1

Slide 55

Slide 55 text

55 バックエンドの効果比率と重要性

Slide 56

Slide 56 text

バックエンドの効果比率 56 フロントエンド 6割バックエンド 4割フロントエンド対策の方が少し効果が高い＞

Slide 57

Slide 57 text

バックエンドの効果比率 57 フロントだけ対策すればいいわけではない。 Why backend ?

Slide 58

Slide 58 text

58 近年Web高速化で求められること

Slide 59

Slide 59 text

早くみせるフロントトリック 59 ブラウザーでWebサイトを表示した際、スクロールせずに最初に見える範囲（ファーストビュー）を早くする。ココ！！

Slide 60

Slide 60 text

求められるWeb高速化のトレンド 60 Crawlerフレンドリーであること

Slide 61

Slide 61 text

Webが表示されるまでのプロセスを把握する 61 クライアントからサーバーへ HTMLをリクエスト /index.html Click! ⑴

Slide 62

Slide 62 text

Webが表示されるまでのプロセスを把握する 62 DBからHTMLコンテンツを生成サーバーからクライアントにHTMLを配信 ⑵ ⑶

Slide 63

Slide 63 text

Webが表示されるまでのプロセスを把握する 63 ブラウザがHTMLコードを解析 HTML内に記載されたJS/CSS/画像をサーバーへリクエスト ⑷ ⑸

Slide 64

Slide 64 text

Webが表示されるまでのプロセスを把握する 64 サーバーからクライアントにファイル配信ブラウザレンダリング処理開始 ⑹ ⑺

Slide 65

Slide 65 text

Webが表示されるまでのプロセスを把握する 65 Webサイトが表示！！ ⑻

Slide 66

Slide 66 text

Webが表示されるまでのプロセスを把握する 66 HTMLを生成するコストが一番時間がかかり、 Web表示速度の直結する。

Slide 67

Slide 67 text

Webが表示されるまでのプロセスを把握する 67 クライアントからサーバーへ HTMLをリクエスト /index.html Click! サーバーからクライアントにHTMLを配信初回HTMLのレスポンスが遅いと全て遅くなる。

Slide 68

Slide 68 text

求められるWeb高速化のトレンド 68 Question クローラーはどこから訪れるのか？

Slide 69

Slide 69 text

求められるWeb高速化のトレンド 69 Answer 日本国外（アメリカ）からやってくる。国内のWebサイトも海外クローラー対策で CDNを導入するケースが増えている。

Slide 70

Slide 70 text

求められるWeb高速化のトレンド 70 ✓ HTMLのダウンロード速度は、 100 〜 500 ミリ秒が理想 ✓ 1,000 ミリ秒を越えるとクローラーがクロールを諦めてしまう可能性あり。※１ ※１2018年9月7日 Google Webmaster Central office-hours hangout クローラーに嫌われるとインデックスされず、検索してもでてこない。

Slide 71

Slide 71 text

バックエンドの効果比率 71 バックエンドは全ての土台バックエンドが遅い＝全てが遅くなる

Slide 72

Slide 72 text

72 CDNを活用した Web高速化

Slide 73

Slide 73 text

ＣＤＮの仕組み 73 CDNは地理的にはなれた場所にエッジとよばれるサーバーを設置。ユーザーのアクセス元を判別しネットワーク的に最も近い場所からコンテンツを配信するしくみ。多数のエッジサーバー

Slide 74

Slide 74 text

ＣＤＮの仕組み 74 ネットワーク的な距離とは？目的のサーバーに到達するまでに経由するルーターの数（HOP数）が少ない方がネットワーク的に距離が最短ということ。※１東京リージョン CDN 東京都内からアクセス CDNが誘導上の経路がネットワーク的に最短・高速！ルータールータールータールーター ※１実際はHOP数以外にもレイテンシなど様々な内容が考慮される

Slide 75

Slide 75 text

ＣＤＮの開始方法 75 【DNSレコード】 www.redbox.ne.jp A 111.222.333.444 www.redbox.ne.jp 111.222.333.444 クライアントは直接Webサーバーにアクセス CDN適用前 Webサーバー

Slide 76

Slide 76 text

ＣＤＮの開始方法 76 【DNSレコード】 www.redbox.ne.jp CNAME redbox.cdnw.net CDNのサブドメインに CNAMEレコード設定する CDN経由で Webサーバーにアクセス CDN適用後エッジサーバー（CDN） Webサーバー

Slide 77

Slide 77 text

ＣＤＮの仕組み 77 初回コンテンツ取得サーバーへアクセスがこないキャッシュ前キャッシュ後初回リクエストコンテンツをコピー CDNにコピーされたコンテンツを配信コンテンツ最適化通信最適化

Slide 78

Slide 78 text

CDNの効果 78 共有回線・共有サーバーを利用している場合、時間帯によって、サーバーリソース・回線の遅延が発生する可能性がある。 DBなどのミドルウェアに影響されないTTFBを維持し、最短経路を通ってコンテンツを配信するため早い表示速度を保つ事ができる。 CDNで表示速度の安定化最適化前最適化後

Slide 79

Slide 79 text

CDNの効果 79

Slide 80

Slide 80 text

CDNの効果 80 CDNは、DNS変更だけで手軽にWeb表示速度を向上させることができる

Slide 81

Slide 81 text

まとめ 81 まとめバックエンド高速化まとめ ✓ Web高速化は正しい継続的な測定からスタートすること ✓ 正しい理解の元、シンプルなバックエンドを構築 ✓ バックエンドのリソースは枯渇していないかではない正しいリソースの使い方をしているのかどうか ✓ バックエンドはコンテンツを無加工で対策することができる。 ✓ CDNはコンテンツを加工することなく対策が可能 ✓ CDNは低スペックなWebサーバーも高スペックに変化させる ✓ クローラー対策でCDNを利用するケースが近年のトレンド

Slide 82

Slide 82 text

82 Web高速化質疑応答 www.facebook.com/ogawaka @ogawaka SNSでもフォロー質問受付中！

Slide 83

Slide 83 text

THANKS!