CDNを用いたWeb高速化とバックエンド技術の重要性 / cdn ec-site backend redbox

CDNで越境EC対策　バックエンドの対策はWeb高速化ですごく重要。

Transcript

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