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

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

bayashi
October 23, 2019
4.1k

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

bayashi

October 23, 2019
Tweet

Transcript

  1. Introduct ID: @bayashi_ok Company: Dip Corporation Join: 2016/09~ Position: Manager

    / SRE Interest: Engineering Manager, Log data analysis, Cache, Automation, etc...
  2. Agenda - DIPについて - DIPのCDNの歴史 - 改善までの道のり - 転送量・速度改善 -

    キャッシュポリシー改善 - Log Visualize 改善 - 今後の課題 - まとめ
  3. A ※1 B C 国内拠点の有無 ◯ ◯ ◯ ◯ deployやpurgeの速度

    ✕ △ ◯ ◯ 汎用的なキャッシュ設定 (UA単位など) ◯ △ ◯ ◯ コスト ◯ △ ✕ ◯ 移行時の比較観点(2017年時点 DIPサイト観点にて比較) 
 ※1 移行前に使用していた CDNサービス
  4. Fastly Image Optimizer を採用 - ブラウザを判別し、自動でWebP化 - URLにパラメータ(witdth、height)を付与し 画像表示サイズへ自動リサイズ -

    画像最適化用に新たにドメインを作り移行 - 無駄なSet-Cookieヘッダーの削除を行い、キャッシュ率を向上 画像最適化
  5. 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
  6. 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
  7. 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
  8. 連携1. 制作チームとのPurgeAPI連携 Tool Purge API Upload - php製の独自アップロードツールを使用 - 制作者がコンテンツをアップロードする際に自動的にURLを生

    成しPurgeする仕組みを導入 - 共通コンテンツはHash-key毎にPurgeを行えるようにした 2. Purge API 連携における有効期限の延長
  9. 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 連携における有効期限の延長
  10. 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
  11. 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
  12. Surrogate-Controlの検討 - 比較的新しいキャッシュ管理のためヘッダー - プロキシキャッシュのためのキャッシュポリシーを提供 - Cache-ControlやExpiresより優先して使用される - Surrogate-Control ヘッダーに長い

    max-age を設定することで、プロキシキャッ シュがブラウザからのトラフィックのほとんどを処理する - 同じようなものとしてCache-Control:s-maxage が存在。 - Surrogate-Controlとは
  13. 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 初回

  14. 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
  15. 304レスポンスの落とし穴 オリジンへの到達タイミング 経過時間 想定 結果 0s
 ◦ ◦ 61s
 -

    - 121s
 - - 181s
 ◦ ◦ 241s
 - ◦ 301s
 - ◦ 361s
 ◦ ◦ 例: Cache-Control: max-age=60 Surrogate-Control:max-age=180 で設定した場合
  16. - 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レスポンス時の対応策検討
  17. ログ整備 - Fastlyでとれる使えそうなログ - ファイル拡張子:%{req.url.ext}V - TLSバージョン:%{tls.client.protocol}V - HTTP/2かどうかのif文判定:%{if(fastly_info.is_h2,\"true\",\"false\")}V" -

    正規表現を使用して URLの第1クラスのみ取得: %{regsub(req.url.path,\"^/(.*?)/.*\",\"\\1\")}V" - 独自ヘッダー:%{req.http.x-robots}V - Backendヘルスチェックステータス: "%{backend.hoge_backendname.healthy}V" - Backend director時の振り分け先:%{req.http.origin-select}V
  18. 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にはならないので安 心