Slide 1
Slide 1 text
CDNを⽤いた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
6
そもそもWeb⾼速化とは︖
Slide 7
Slide 7 text
Web⾼速化とは
7
Webサイトの表⽰速度を早くすること。
13 sec 3 sec
Slide 8
Slide 8 text
遅いWebサイト・速いWebサイトとは︖
8
遅いWeｂ 速いWeb .
Slide 9
Slide 9 text
Web⾼速化とは
9
Web表⽰速度のムラを無くすこと。
Slide 10
Slide 10 text
Web⾼速化とは
10
Web⾼速化の共通点
ユーザー体験を向上させること。
Slide 11
Slide 11 text
11
バックエンドの主な対策項⽬
Slide 12
Slide 12 text
バックエンド対策項⽬
12
クライアントが、画像などのコンテンツをダウンロードするまでの⼯程
バックエンドの最適化
ü ネットワーク速度
ü サーバースペック
ü プロトコル（HTTP2）
ü キャッシュ（CDN）
ü ミドルウェア最適化（Webサーバー・DB）
ü コンテンツ最適化（Gzip Brotli Webp）
Slide 13
Slide 13 text
バックエンド対策項⽬
13
üとりあえずパラメーターの値を増やす
1024 → 2048
Slide 14
Slide 14 text
バックエンド対策項⽬
14
üとりあえずサーバースペック上げる
Slide 15
Slide 15 text
バックエンド対策項⽬
15
üとりあえず⾊々インフラの仕組みを変更
Slide 16
Slide 16 text
Web⾼速化の種類
16
根拠がない変更はNG︕
逆に悪化することや
何かのタイミングで不具合を発⽣させる恐れがある。
Slide 17
Slide 17 text
17
Web⾼速化は調査からはじまる。
コレをしておけばOK︕という
おまじないは存在しない。
Donʼt guess, measure!
（推測するな、計測せよ︕）
Slide 18
Slide 18 text
18
適切なモニタリングと計測
Slide 19
Slide 19 text
Web表⽰速度の計測
19
Google Analyticsでどのページが遅いのかを確認
⾏動
↓
サイトの速度
↓
ページ速度
Slide 20
Slide 20 text
Web表⽰速度の計測
20
Chrome Developer Tool
Slide 21
Slide 21 text
Web表⽰速度の計測
21
Google製 昔からあるやつ。昨年Light Houseエンジンを搭載
Page Speed Insight（https://www.webpagetest.org）
Slide 22
Slide 22 text
Web表⽰速度の計測
22
Googleが中⼼となって開発しているオープンソースの合成モニタリングツール
WebPagetest（https://www.webpagetest.org）
・発⽣した通信処理の⼀覧
・ウォーターフォールチャート
・⼀定期間毎のスクリーンショット
・プライベートインスタンスの提供
・低速回線からのアクセス
・ブラウザやデバイス指定
・アクセス地域の指定
Slide 23
Slide 23 text
Web表⽰速度の計測
23
WebPagetest（https://www.webpagetest.org）
Slide 24
Slide 24 text
24
バックエンドの調査順序
Slide 25
Slide 25 text
25
1. サーバーのリソースが適切に利⽤されているか
2. 通信関連にボトルネックはないか
3. キャッシュを利⽤できているか
4. ミドルウェアの構成は正しいか
Slide 26
Slide 26 text
26
サーバーリソース 編
（CPU/MEMORY/DISK IO）
CPUは何パーセント消費しているのか︖ではない。
Slide 27
Slide 27 text
CPU編
27
• 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 28
Slide 28 text
28
サーバーリソース 編
（CPU/MEMORY/DISK IO）
メモリーの空き容量が⼗分かどうか︖ではない
Slide 29
Slide 29 text
Memory編
29
• 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 30
Slide 30 text
30
サーバーリソース 編
（CPU/MEMORY/DISK IO）
DISK IOはどのプロセスが占有しているか
Slide 31
Slide 31 text
DSIK IO編
31
• プロセス毎にDISKの読込み・書き込み状況が把握できる。dstat -ta --top-io-adv --top-bio-adv
• ⼤抵はMysqlが多く利⽤しているケースが多い。
• PHPが読み書きを多くしている場合は、バッチ処理やプラグインの処理で重くなっている可能性が⾼い。
プロセス毎のI/O
どのプロセスがDISK I/Oを利⽤しているかDSTATで確認。
ココ︕︕
Slide 32
Slide 32 text
32
通信・キャッシュ 編
（DNS/キャッシュ）
⾒落としがちなDNS応答速度
Slide 33
Slide 33 text
DNS編
33
DNSの速度と重要性
Webサイトを訪れるユーザーは、ドメインの名前解決をDNSサーバーで⾏う。
この名前解決が遅いケースがある。※無料DNSを利⽤している場合は注意
ドメイン名を解決
www.redbox.ne.jp
⑴
DNS
xxx.xxx.xxx.xxx
Slide 34
Slide 34 text
DNS編
34
DNSベンダーの速度計測サイト
https://www.dnsperf.com
Slide 35
Slide 35 text
35
通信・キャッシュ 編
（DNS/キャッシュ）
爆速を⼿に⼊れるためのキャッシュ
Slide 36
Slide 36 text
キャッシュ編
36
複数のキャッシュタイプ
クライアント
キャッシュ
Webサーバー
中間
キャッシュ
サーバーサイド
キャッシュ
ブラウザ内の
キャッシュ
CDNなどの
外部キャッシュ
APC
Memcached
Slide 37
Slide 37 text
キャッシュ編
37
中間キャッシュ
エッジサーバー
CDNでキャッシュ配信することによって、
ある程度安定したTTFBを維持・DBなどミドルウェアに影響されないレスポンスを提供。
Webサーバー
クライアント
キャッシュ
DNSを変更するだけでＯＫ︕
Slide 38
Slide 38 text
38
バックエンドの効果⽐率と重要性
Slide 39
Slide 39 text
バックエンドの効果⽐率
39
フロントエンド
6割
バックエンド
4割
フロントエンド対策の⽅が少し効果が⾼い
＞
Slide 40
Slide 40 text
バックエンドの効果⽐率
40
何故バックエンド対策が必要なのか︖
Why backend ?
Slide 41
Slide 41 text
41
近年Web⾼速化で求められる
２つのトレンド
Slide 42
Slide 42 text
求められるWeb⾼速化のトレンド
42
１︓越境ECとインバウンド
Slide 43
Slide 43 text
求められるWeb⾼速化のトレンド
43
国外のユーザーが⽇本のWebサイトを利⽤する場合
物理的な距離がありネットワーク的に遅延する。
アメリカ
物理的な距離 約１万キロ
ラウンドトリップタイム（RTT）
130MS前後
⽇本
国内に⽐べ約１０倍 以上
Slide 44
Slide 44 text
求められるWeb⾼速化のトレンド
44
ネットワーク遅延に⽐例して、
最⼤トラフィックが頭打ちになり
ダウンロード完了までの時間が⻑くなる。
RTT 100msec︓最⼤5.12Mbps
※1
※1 ウィンドウサイズが64Kバイトの場合
計算式︓スループット (bps) = TCP ウィンドウサイズ (KB) * 8 / RTT (S)
Slide 45
Slide 45 text
求められるWeb⾼速化のトレンド
45
２︓Crawlerフレンドリー
Slide 46
Slide 46 text
Webが表⽰されるまでのプロセスを把握する
46
クライアントからサーバーへ
HTMLをリクエスト
/index.html
Click!
サーバーからクライアントにHTMLを配信
初回HTMLのレスポンスが遅いと全て遅くなる。
Slide 47
Slide 47 text
Webが表⽰されるまでのプロセスを把握する
47
HTMLを⽣成するコストが⼀番時間がかかり、
Web表⽰速度の直結する。
Slide 48
Slide 48 text
求められるWeb⾼速化のトレンド
48
Question
クローラーはどこから訪れるのか︖
Slide 49
Slide 49 text
求められるWeb⾼速化のトレンド
49
Answer
⽇本国外（アメリカ）からやってくる。
国内のWebサイトも海外クローラー対策で
CDNを導⼊するケースが増えている。
Slide 50
Slide 50 text
求められるWeb⾼速化のトレンド
50
ü HTMLのダウンロード速度は、 100 〜 500 ミリ秒が理想
ü 1,000 ミリ秒を越えるとクローラーがクロールを諦めてしまう
可能性あり。※１
※１2018年9月7日 Google Webmaster Central office-hours hangout
クローラーに嫌われるとインデックスされず、
検索してもでてこない。
Slide 51
Slide 51 text
51
ネットワークの距離的な問題による
遅延を防⽌するために
CDNサービスが必要
Slide 52
Slide 52 text
52
CDNを活⽤したWeb⾼速化
Slide 53
Slide 53 text
ＣＤＮの仕組み
53
CDNは地理的にはなれた場所にエッジとよばれるサーバーを設置。
ユーザーのアクセス元を判別しネットワーク的に最も近い場所から
コンテンツを配信するしくみ。
多数のエッジサーバー
アメリカ
ヨーロッパ
アジア
Slide 54
Slide 54 text
ＣＤＮの仕組み
54
ネットワーク的な距離とは︖
⽬的のサーバーに到達するまでに経由するルーターの数（HOP数）が
少ない⽅がネットワーク的に距離が最短ということ。※１
東京リージョン
CDN
東京都内から
アクセス
CDNが誘導
上の経路がネットワーク的に最短・⾼速︕
ルーター
ルーター
ルーター ルーター
※１実際はHOP数以外にもレイテンシなど様々な内容が考慮される
Slide 55
Slide 55 text
ＣＤＮの開始⽅法
55
【DNSレコード】
www.redbox.ne.jp A 111.222.333.444
www.redbox.ne.jp
111.222.333.444
クライアントは
直接Webサーバーに
アクセス
CDN適⽤前
Webサーバー
Slide 56
Slide 56 text
ＣＤＮの開始⽅法
56
【DNSレコード】
www.redbox.ne.jp CNAME redbox.cdnw.net
CDNのサブドメインに
CNAMEレコード設定する
CDN経由で
Webサーバーにアクセス
CDN適⽤後 エッジサーバー
（CDN）
Webサーバー
Slide 57
Slide 57 text
ＣＤＮの仕組み
57
初回コンテンツ取得
サーバーへ
アクセスがこない
キャッシュ前
キャッシュ後
初回リクエスト
コンテンツをコピー
CDNにコピーされた
コンテンツを配信
コンテンツ
最適化
通信最適化
Slide 58
Slide 58 text
CDNの最適化
58
クライアントからWebサーバーまでの様々な通信を最適化し、
最初にGETされるHTMLコンテンツのダウンロード速度を加速させる。
1︓通信・プロトコルの最適化
Slide 59
Slide 59 text
通信・プロトコルの最適化
59
クライアントがサーバーと初めて通信をする時、3 way handshakeとい
う3回通信をおこなう決まり事を最適化する。
TCP通信処理は低速・不安定な回線ほど通信完了までのコストが多く発⽣。
KEEPALIVE / TCP FAST OPEN / TCP SLOW START
TCP通信の最適化
主な設定項⽬︓OS・カーネルのチューニング
通信︕
クライアント Webサーバー
Slide 60
Slide 60 text
通信・プロトコルの最適化
60
・HTTP/2・QUIC によるプロトコルベースの最適化
・HTTPSネゴシエーションの最適化
Cipher Suite / SSL Session Cache / OCSP STAPLING
プロトコルの最適化
主な設定項⽬︓ミドルウェア全般
SSL通信︕
クライアント
Webサーバー
Slide 61
Slide 61 text
CDNの最適化
61
Webページのコンテンツサイズを縮⼩することによって、
ダウンロード完了時間を短縮し⾼速化。
2︓コンテンツサイズの縮⼩
Slide 62
Slide 62 text
コンテンツサイズの縮⼩
62
CSS/JS/HTML Minify
画像サイズの縮⼩
HTMLやCSSはコンテンツのレンダリングスピードに⼤きく影響する要因の⼀つ。
コードをMinifyすることにより、コンテンツサイズの縮⼩をおこなう。
Webサイトのコンテンツサイズは6割以上が画像コンテンツ。
WebPフォーマット変換 / ロスレス圧縮 / リサイズ
Minifyとは、空⽩や改⾏など不要な⽂字を削除する作業。
各種ツールでオリジナルファイルを縮⼩。
Slide 63
Slide 63 text
コンテンツサイズの縮⼩
63
Brotli / Gzipでコンテンツ圧縮を⾏いクライアントへ転送するコン
テンツサイズを縮⼩する。※Brotliはクライアントが対応しているか
をサーバーサイドで判断し出⼒分けの必要あり。
コンテンツの圧縮
Gzip・Brotliで圧縮配信
Gzip Brotli
クライアント
Webサーバー
Slide 64
Slide 64 text
CDNの最適化
64
⼀定のWeb表⽰速度であること。
3︓表⽰速度の安定・最適化
Slide 65
Slide 65 text
表⽰速度の安定・最適化
65
キャッシュ・CDNの導⼊
エッジサーバー
VPSやクラウド上のWebサーバーは、回線やリソースが他社と共有のため、
時間帯によって、通信が安定しないことがある。
CDNでキャッシュ配信することによって、
ある程度安定したTTFBを維持・DBなどミドルウェアに影響されないレスポンスを提供。
Webサーバー
クライアント
キャッシュ
Slide 66
Slide 66 text
CDNの効果
66
共有回線・共有サーバーを利⽤している場合、時間帯によって、
サーバーリソース・回線の遅延が発⽣する可能性がある。
DBなどのミドルウェアに影響されないTTFBを維持し、
最短経路を通ってコンテンツを配信するため早い表⽰速度を保つ事ができる。
CDNで表⽰速度の安定化
最適化前 最適化後
Slide 67
Slide 67 text
CDNの効果
67
Slide 68
Slide 68 text
CDNの効果
68
CDNは、DNS変更だけで
⼿軽にWeb表⽰速度を向上させることが
できる
Slide 69
Slide 69 text
まとめ
69
まとめ
バックエンド⾼速化まとめ
ü Web⾼速化は正しい継続的な測定からスタートすること
ü 正しい理解の元、シンプルなバックエンドを構築
ü バックエンドのリソースは枯渇していないかではない
正しいリソースの使い⽅をしているのかどうか
ü CDNはコンテンツを加⼯することなく対策が可能
ü CDNは低スペックなWebサーバーも⾼スペックに変化させる
ü 国外からのアクセスを考慮するためにCDNを利⽤するケースが近年のトレンド
Slide 70
Slide 70 text
70
Web⾼速化 質疑応答
www.facebook.com/ogawaka
@ogawaka SNSでもフォロー
質問受付中︕
Slide 71
Slide 71 text
THANKS!