レガシーなサイトにFastlyを入れて改善した道のり.pdf

Transcript

1. レガシーなサイトに
 Fastlyを入れて
 改善した道のり
 Fastly Yamagoya Meetup 2019 October 23, 2019 Takazumi Okibayashi
2. Introduct ID: @bayashi_ok Company: Dip Corporation Join: 2016/09~ Position: Manager / SRE Interest: Engineering Manager, Log data analysis, Cache, Automation, etc...
3. 今回お話しする事 - ✕　 Fastly移行時のお話 - ◯　Fastly移行後、様々な改善をして嵌ったこと 取り組んだ後の効果についてのお話
4. Agenda - DIPについて - DIPのCDNの歴史 - 改善までの道のり - 転送量・速度改善 - キャッシュポリシー改善 - Log Visualize 改善 - 今後の課題 - まとめ
5. ~ About DIP ~ DIPについて
6. 人と企業を結ぶ日本最大級の求人情報サービスを展開 ・1997年設立。 ・『バイトル』をはじめ、アルバイト・派遣・正社員のお仕事情報、看護師 　の人材紹介サイトを運営。 ・従業員数 1,967名（2019年4月1日現在の正社員） 

7. テクノロジーの活用を通して企業・求職者双方により貢献を目指す 新たな挑戦としてAI・VR・Roboticsに注目しM&Aや出資も行なっている AI情報を集約した キュレーションサイト AI・人工知能ベンチャー
 支援制度 働き方の改革・効率化に
 貢献するスタートアップ
 企業の投資制度
 学生スタートアップ企業の
 育成投資制度

8. ~ DIP cache history ~ DIPのCDNの歴史
9. CDN deployment サイトのアクセス数増加に伴い、サーバへの負荷やトラフィック量 が多くなり、CDNを導入。
 〼 2014/10 バイトルにCDN導入 〼 2015/08 はたらこねっとにCDN導入
10. CDN migration 〼 2017/08 バイトルのCDN移行 〼 2017/10 はたらこねっとのCDN移行 国内HR業界では一番最初にFastlyを導入

11. CDN移行の背景
 - 外部影響による接続不良の発生 - CDN業者による設定ミス - キャッシュクリアまでの反映時間 - ログ解析の運用負荷増加 - 機能の拡張性・汎用性 - 以前Varnishを使っていたのVCLでの知見があった
12. A ※1 B C 国内拠点の有無 ◯ ◯ ◯ ◯ deployやpurgeの速度 ✕ △ ◯ ◯ 汎用的なキャッシュ設定 (UA単位など) ◯ △ ◯ ◯ コスト ◯ △ ✕ ◯ 移行時の比較観点(2017年時点　DIPサイト観点にて比較) 
 ※1 移行前に使用していた CDNサービス
13. 改善までの道のり ~ The road to improvement ~
14. 転送量・速度改善 ~ Improved transfer and speed ~
15. Fastly Image Optimizer を採用 - ブラウザを判別し、自動でWebP化 - URLにパラメータ（witdth、height）を付与し 画像表示サイズへ自動リサイズ - 画像最適化用に新たにドメインを作り移行 - 無駄なSet-Cookieヘッダーの削除を行い、キャッシュ率を向上 画像最適化
16. バイトル案件画像について - 求人案件検索時に表示される画像 - 画像サイズ制限はあるもののサイズの大きい画像が掲載されるこ とが多く、ユーザの通信量的にもサイズを抑えれないかが課題と なっていた - 現在では別途LazyLoadを取り入れ対応 Fastly Image Optimizer を採用
17. Fastly Image Optimizer を採用 - 通常 - URL: 800x600.jpg content-type: image/jpeg size: 67.5KB - Image Optimizer 適応後 - URL: 800x600.jpg?width=200&height=150&fit=bounds content-type: image/webp size: 7.9KB
18. 案件画像、転送量/月 約24%以上削減 (月2T～3TB)
19. キャッシュポリシー改善 ~ Improved cache policy ~
20. - サイトの更新頻度が高く キャッシュ時間が最小限 になっていた - 制作チームや、案件掲載のクライアントが 同名ファイルでの アップロードを繰り返すことが多かった これまでのキャッシュ設定
21. Googleが推奨する最善のキャッシュポリシー キャッシュポリシー 改善前 URL フィンガープリントやバージョニングなどの手法の使用 ✕ 最適なキャッシュ有効期限 (1週間~1年が有効) ✕ Cache-Controlによるキャッシュ ◯ サイトに最適なキャッシュ階層 △ Etagによるレスポンス検証 ✕ https://developers.google.com/speed/docs/insights/LeverageBrowserCaching?hl=ja https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=ja
22. キャッシュポリシーに合わせた仕組み作りを行う必要があった
23. Googleが推奨する最善のキャッシュポリシー キャッシュポリシー 改善前 ⇒ 改善後 URL Finger Print やバージョニングなどの手法の使用 ✕ ⇒ ◯ 最適なキャッシュ有効期限 (1週間~1年が有効) ✕ ⇒ ◯ Cache-Controlによるキャッシュ ◯ ⇒ ◎ サイトに最適なキャッシュ階層 △ △ Etagによるレスポンス検証 ✕ ✕ https://developers.google.com/speed/docs/insights/LeverageBrowserCaching?hl=ja https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=ja
24. キャッシュポリシー改善に向けて 1. リリース時のURL FingerPrint 付与 2. Purge API 連携における有効期限の延長 3. Surrogate-Controlの検討 ~ To improve cash policy ~
25. キャッシュポリシー改善に向けて 1. リリース時のURL FingerPrint 付与 2. Purge API 連携における有効期限の延長 3. Surrogate-Controlの検討 ~ To improve cash policy ~
26. 1.リリース時のURL Finger Print 付与 - Jenkinsで特定ファイルをリリースする際フィンガープリントに日付を 付与し、ユーザーが新しいレスポンスをダウンロードできるように実装 - リリース後、対象ファイルのキャッシュ時間を1年に延ばした 20190913T105251 /xxxx/top.css?style=20190913T105251
27. キャッシュポリシー改善に向けて 1. リリース時のURL FingerPrint 付与 2. Purge API 連携における有効期限の延長 3. Surrogate-Controlの検討 ~ To improve cash policy ~
28. 連携１. 制作チームとのPurgeAPI連携 Tool Purge API Upload - php製の独自アップロードツールを使用 - 制作者がコンテンツをアップロードする際に自動的にURLを生 成しPurgeする仕組みを導入 - 共通コンテンツはHash-key毎にPurgeを行えるようにした 2. Purge API 連携における有効期限の延長
29. フロントページ クライアント管理ページ - クライアントが画像のアップロードを行う際にもAPI連携を行い、 画像アップロード時にURLを生成しキャッシュクリアする仕組み を実装 Purge API Upload 反映 連携２.クライアント側とのPurge API連携 2. Purge API 連携における有効期限の延長
30. Cache-Control: max-ageの値を見直し - ディレクトリ階層ごとにキャッシュ時間の検討を行うために各担当者と話し合い フィンガープリントの手法や、 PurgeAPIの説明をしながらテストを行いリリース PC/SMT 使用用途 第1クラス （ディレクトリ） 画像/JS/CSS 有無 現キャッシュ 時間(PC) 現キャッシュ 時間(SMT) 担当 アップ方法 状態 変更後 キャッシュ時間 考察 備考 共通 バイトルについて about 画像/JS/CSS 3600/600/600 3600/600/600 ＊＊＊ CUT 完了 604800 ＊＊＊＊ 例： 2. Purge API 連携における有効期限の延長
31. - PurgeAPI連携を行い、Cache-Controlの時間を長くした結果、 キャッシュ率の増加には繋がったがBlink Cacheなどにキャッシュを保持されてしま い、同名ファイルで更新したコンテンツが一定期間変わらず制作チームからの問い合 わせが増えてしまった… Blink Cacheによる弊害
32. Blink Cache について - Chromium(Google Chrome)で使用されるレンダリングエンジンによるキャッシュ - 基本的にはmax-ageなどのキャッシュ制御に従うとされている - disk cacheやmemory cacheなどのキャッシュをもっており max-age値内はオリジンサーバにリクエストがとばなくなる https://stackoverflow.com/questions/52950068/what-does-blink-in-memory-cache-store (from disk cache) (from memory cache) Cache-Control: max-age=3600 経過時間：600s Cache-Control: max-age=3600 経過時間：0s GET /xxx.jpg 200 OK
33. Blink Cache について
34. memory cache と disk cache の違い - memory cache - メモリ（RAM）との間でリソースを保存およびロードを行う - 高速だが、永続的ではなく、ブラウザを閉じるまでコンテンツを利用可能 - memory cacheによって処理されるリクエストは、Service Workerで観察できない - disk cache - 永続的。キャッシュされたリソースは、ディスクに保存され、ディスクからロードされる - 削除するにはブラウザ内のキャッシュ削除等を行う必要が有る - disk cacheによって処理されるリクエストは、Service Workerを通過する memory cache Service worker Cache disk cache https://stackoverflow.com/questions/52950068/what-does-blink-in-memory-cache-store
35. Blink Cacheも考慮しキャッシュさせる必要があった

36. キャッシュポリシー改善に向けて 1. リリース時のURL FingerPrint 付与 2. Purge API 連携における有効期限の延長 3. Surrogate-Controlの検討 ~ To improve cash policy ~
37. Surrogate-Controlの検討 - 比較的新しいキャッシュ管理のためヘッダー - プロキシキャッシュのためのキャッシュポリシーを提供 - Cache-ControlやExpiresより優先して使用される - Surrogate-Control ヘッダーに長い max-age を設定することで、プロキシキャッ シュがブラウザからのトラフィックのほとんどを処理する - 同じようなものとしてCache-Control：s-maxage が存在。 - Surrogate-Controlとは
38. 304レスポンスの落とし穴 - オリジンサーバからのレスポンスが304の場合 Surrogate-ControlヘッダーがFastlyに返らず FastlyのttlがCache-Controlの値にうわがかれてしまっている場合があった
39. GET /xxx.jpg If-Modified-Since:date_X 200 OK Last-Modified: date_X Cache-Control: max-age=60 Surrogate-Control: max-age=180 Age: 0 Cache-Control: max-age=60 Surrogate-Control: max-age=180 200 OK Last-Modified: date_X Cache-Control: max-age=60 Surrogate-Control: max-age=180 304レスポンスの落とし穴 be.resp.ttl=180 初回

40. GET /xxx.jpg If-Modified-Since:date_X 304 Not Modified Last-Modified: date_X Cache-Control: max-age=60 Surrogate-Control: max-age=180 Age: 0 Cache-Control: max-age=60 Surrogate-Control: max-age=180 304 Not Modified Last-Modified: date_X Cache-Control: max-age=60 Surrogate-Control: max-age=180 304レスポンスの落とし穴 Surrogate-Contol秒数以降で304レスポンスになった場合
 be.resp.ttl=180 ↓ be.resp.ttl=60
41. 304レスポンスの落とし穴 オリジンへの到達タイミング 経過時間 想定 結果 0s
 ◦ ◦ 61s
 - - 121s
 - - 181s
 ◦ ◦ 241s
 - ◦ 301s
 - ◦ 361s
 ◦ ◦ 例： Cache-Control: max-age=60 Surrogate-Control:max-age=180 で設定した場合
42. - 原因 - オリジンサーバのミドルウェアとして Apacheを使用していたのだが ApacheがNot-Modified(304)を返す時 のレスポンスヘッダーに Surrogate-Controlが入っていなかった https://github.com/apache/httpd/blob/trunk/modules/http/http_filters.c 304レスポンスの落とし穴
43. - Apacheに304時もSurrogate-Controlを返すように変更してもらう - Apache/httpにpull requestを行なったがmergeされなかったため、Bug fix として報告予定 - Cache-Controlをユーザに返すときFastly上とユーザ上のCache-Controlを分ける - ApacheとFastly上で設定が散文されてしまうので見送り - Surrogate-ControlではなくCache-Control: s-maxage を使用 - 今回これを採用し実装 304レスポンス時の対応策検討
44. 案件画像キャッシュ率：約60%→ 約96%
45. Log Visualize 改善 ~ Improved Log Visualize ~
46. Fastly移行直後のログ設計 - ログは当初Apacheの「NCSA extended/combined ログ書式」にもとづいていた。 - Apacheログ形式をそのままFastlyで使えるので移行時は楽に移行できた
47. 改善後のログ設計 - ログフォーマットを解析しやすいようにjson形式に変更 - 長期ログ保管＆集計用としてGCS+BigQuery+DataStudioにもログを補完 - リアルタイム可視化と長期可視化で切り分け
48. ログ整備 - Fastlyでとれる使えそうなログ - ファイル拡張子：%{req.url.ext}V - TLSバージョン：%{tls.client.protocol}V - HTTP/2かどうかのif文判定：%{if(fastly_info.is_h2,\"true\",\"false\")}V" - 正規表現を使用して URLの第１クラスのみ取得： %{regsub(req.url.path,\"^/(.*?)/.*\",\"\\1\")}V" - 独自ヘッダー：%{req.http.x-robots}V - Backendヘルスチェックステータス： "%{backend.hoge_backendname.healthy}V" - Backend director時の振り分け先：%{req.http.origin-select}V
49. ~ Task ~ 今後の課題
50. Terraform化 resource "fastly_service_v1" "fastly_hoge" { name = "hogehoge terraform" default_ttl = "3600" force_destroy = true activate = false domain { name = "hogehoge.com" comment = "hogehoge.com" } backend { address = "127.0.0.1" name = "hoge" port = "443" use_ssl = "true" ssl_cert_hostname = "*.hogehoge.com" shield = "hnd-tokyo-jp" between_bytes_timeout = "20000" connect_timeout = "120000" first_byte_timeout = "600000" max_conn = "200" } request_setting { name = "default" force_ssl = true hash_keys = "req.url,req.http.host" xff = "append" timer_support = "" force_miss = "" } gzip { name = "file extensions and content types" extensions = ["css","js","html","eot","ico","otf","ttf","json","svg"] content_types = ["text/html","application/x-javascript","text/css","application/javascript","text/javascript","application/json","a pplication/vnd.ms-fontobject","application/x-font-opentype","application/x-font-truetype","application/x-font-t tf","application/xml","font/eot","font/opentype","font/otf","image/svg+xml","image/vnd.microsoft.icon","text/pl ain","text/xml"] } vcl { name = "hogehoge_vcl" content = "${file("${path.module}/main.vcl")}" main = true } } - TerraformがFastly Providerもサポートしている ためTerraformでの管理が可能 - AWSやGCPとは違い流すたびに Serviceが Cloneされ新しいVersionが作成される - 「activate = false」を付けておくとapplyしても新 しいCloneが作成されActiveにはならないので安 心
51. ~ Summary ~ まとめ
52. まとめ - レガシーなサイトにFastlyを入れて様々な改善をした話 - カスタマイズや外部連携が行いやすいので様々な用途に使用で きる - Surrogate-Controlを使用する際は、オリジンの304レスポンスが 返すヘッダー情報を把握しておく必要があった - キャッシュはブラウザ、CDN、サーバなど様々な種類があるので しっかりと検証していくことが大事 - サポートが手厚くかなり助かっている
53. Thanks!! We are Hiring !! https://www.dip-net.co.jp/recruit/top/