大規模ImageOptimizer利用案件から学ぶ 安心安全のCDN移行 / Fastly yamagoya 2022

Fastly yamagoya 2022で話した、ImageOptimizerの利用案件
失敗だらけだったよ、ということをお伝えしたかったヤツ

Transcript

1. あああ 1 大規模ImageOptimizer利用案件から学ぶ 安心安全のCDN移行
2. PROFILE 2 Software Engineer / Ameba事業本部 技術責任者 岩永 翔 @kakerukaeru Webの新しい技術が好物です 水出しコーヒーも好きです Fastly C@EでサブResources含めたSXG配信の検証するぞ！ ってタスクを半年ほど寝かせてます。 そろそろするぞ・・・！ Fastly yamagoya 2022
3. Agenda 3 1　Amebaについて　 2　お引越しプロジェクト：推進編 3　お引越しプロジェクト：実装編 4　失敗の軌跡 Fastly yamagoya 2022
4. Ameba is ... 4 Fastly yamagoya 2022
5. 5 Fastly yamagoya 2022 Amebaについて https://speakerdeck.com/kakerukaeru/the-road-to-ameba-system-renovation?slide=5
6. 6 Fastly yamagoya 2022 Amebaについて https://speakerdeck.com/kakerukaeru/the-road-to-ameba-system-renovation?slide=5 UGCが多く、画像投稿数は累計100億枚 +
7. 7 Fastly yamagoya 2022 Amebaについて：CDN Ameba周辺ではCDNを大量に使っています 今回のお引越しで対象となったCDN利用シーンは以下 • 画像変換＆配信（今回メインで話すのはここ） • 静的リソース配信 • アプリ用BFF 対象のピーク帯MAX合計の規模感 30Gbps、100K rps、47 domain
8. 8 Fastly yamagoya 2022 Amebaについて：画像変換の歴史 Amebaと画像変換の歴史 200X ~ 独自実装の画像変換ｻｰﾊﾞｰ / 独自Query（一部仕様実現の為、現存） 201X ~ Akamai ImageManager / 独自Queryをマッピング 2022 ~ Fastly ImageOptimizer / 独自Queryをマッピング Client CDN w/変換 Origin 画像配信＆一部変換仕様
9. お引越しプロジェクト：推進編 9 Fastly yamagoya 2022
10. お引越しプロジェクト：推進編 > 事の発端 10 契約切り替えタイミングでの CDNの大規模お引越し... Fastly yamagoya 2022 ３ヶ月前の僕
11. お引越しプロジェクト：推進編 > 事の発端 11 ワンチャン、コストメリットあるな Fastly yamagoya 2022 思いついた
12. お引越しプロジェクト：推進編 > 事の発端 12 30Gbps、100K rps、47 domain を移行したい、２ヶ月で。 Fastly yamagoya 2022 Oh, Crazy... 思いついた僕 付き合ってくれた メンバー
13. お引越しプロジェクト：推進編 > 事の発端 13 とにかく時間がない 攻めながら、コスパよく行こう Fastly yamagoya 2022
14. お引越しプロジェクト：推進編 > おーばーびゅー 14 Fastly yamagoya 2022 基礎検証 • 画像変換の機能検証 • CDNの機能検証 ２人で検証を開始💪 ６人チームに進化✌ PoC実施 • PoC用config実装 • モニタリング整備 • CDN&Origin負荷対策 • 移行手法の確立 やるしかない！🔥 移行祭り • Fastly config実装 • DNS移行 3週間 2週間 3週間 Fastlyさんの サポート🤝
15. 15 Fastly yamagoya 2022 お引越しプロジェクト：推進編 > 基礎検証 観点 Fastly ImageOptimizerが 既存仕様を実現できるかの検証 やっていきかた • 画像変換クエリのマッピング • 画像変換クオリティのすり合わせ
16. 16 Fastly yamagoya 2022 お引越しプロジェクト：推進編 > 基礎検証 > 変換クエリ 変換マッピング • Ameba画像変換システムの独自クエリを、fastly.io で再現確認 ◦ 一部クエリは実際にconfigを作らないと確認できなかったが後述 • スプシに既存仕様クエリを書き出し、IOでの対応クエリを書き出す • 一つ一つ職人が心を込めて丁寧に、泥臭く。 • 変換要件を満たしているかは、目視とメタデータ確認でヨシ 独自クエリとFastly ImageOptimizerのクエリのマッピングシート
17. 17 Fastly yamagoya 2022 お引越しプロジェクト：推進編 > 基礎検証 > 変換クオリティ 変換クオリティ • デザイナーと実施 • 比較用全部入り画像を作成 • 変換前後での劣化を確認 比較情報 • Quality / dssim / bytes 攻められるギリギリを選択 最後は目視で確認、ヨシ Quality:85 を採用 Quality比較シート / dssim の数値のグラデがキレイでお気に入り デザイナー謹製変換劣化確認用全部入り画像。通称、ヤバい画像1.JPG ヤバい画像2.JPG
18. 18 Fastly yamagoya 2022 お引越しプロジェクト：推進編 > 基礎検証 > 変換クオリティ > デザイナーひとことメモ 様々な色の交わり方のしている画像を用意して境界線が視認 できるかどうかを判断してたり、色自体が変わってしまう ケースを確認したり、文字情報などの意味のある情報が意味 を理解できる程度に視認できるかを確認したりしてます
19. 19 Fastly yamagoya 2022 お引越しプロジェクト：推進編 > PoC実施 観点 本番移行を見据えた負荷対策と それに伴う移行計画の実現 やっていきかた • 一番デカいドメイン（20Gbps/20K IOrps）を１週間Fastlyに乗せる ◦ Cacheが温まっていないという前提の元。 • そのために必要な作業 ◦ CDN移行時のリクエスト流用調整の手法検証 ◦ PoC用Configの実装 ◦ Fastly上での負荷対策
20. 20 Fastly yamagoya 2022 お引越しプロジェクト：推進編 > PoC実施 > 移行手法の実現 移行手法 所感 ウェイトが低い時に 流量が5% ~ 10% 程度ブレる が、ほぼ期待通りの 流量調整が出来たので採用 AWS Route 53 Traffic Flowで実現 DNSベースの流量調整 TTLを短くし反映速度も調整 Traffic Flow UI / 99:1 の比重で返却内容を変えている / わかりやすいね
21. 21 Fastly yamagoya 2022 お引越しプロジェクト：推進編 > PoC実施 > Fastly Configの実装 PoC実装準備 実施順番 • Akamai config export to json • CDN仕様スプシ書き起こし ◦ 😚 Review • CDN振る舞いtest実装 / mocha,chai ◦ 😚 Review • terraform & vcl 書き起こし ◦ 😚 Review PoC後の47domain分の大量実装を見据えて、 書き起こしフローを展開出来るよう実施 CDN config 起こしシート / vcl or tf 移行？Review OK?などのチェック項目がある
22. 22 Fastly yamagoya 2022 お引越しプロジェクト：推進編 > PoC実施 > 結果 PoCの進捗 ので、本格移行にGO！ いろいろあったけど CHRは80%を維持 Origin Trafficも以前と遜色ないレベルにまで抑えられた 副次的なOriginコネクションの減少 / Edgeの作り方の思想の違いかな
23. 23 Fastly yamagoya 2022 お引越しプロジェクト：推進編 > 移行フェーズ プロジェクトマネジメント 移行元のconfigとDNSレコード単位で タスクを切り漏れなく実施 traffic flow 用のタイムラインも引き 丁寧に移行を実施 タイムラインシート / 各ドメインに対して荷重ルールをどのタイミングで何％変えるかなど、注意点などを記載 Asanaのタスクダッシュボード / ビジュアライズされてるとテンションが上がる
24. お引越しプロジェクト：実装編 24 Fastly yamagoya 2022
25. 25 Fastly yamagoya 2022 お引越しプロジェクト：実装編 どんな思想で実装したかの話します
26. 26 Fastly yamagoya 2022 お引越しプロジェクト：実装編 まずはOps
27. 27 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Ops > CI/CD CD GitHubActions + terraform module形式 vclは全環境共通 templatefileで一部書き換え env>service>...>main.tfで vcl用やdomain等の変数を渡す repo tree / serviceで使い回すためにmodule生成 , 証明書は共通なのでベタ書き
28. 28 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Ops > CI/CD deploy flow なんちゃって trunk based development 各module dirに変更がアレば 即座にprd未満に適用 prdへの適用は main branchへのmerge時のみ actions yml / 各サービス郡の設定に関するディレクトリ配下のファイルが 変更されたら即座に terraform apply が走る 一方、本番環境に限り、PR の reviewを通してmainにmergeされた時のみdeploy
29. 29 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Ops > CI/CD 画像変換のテスト Rustで実装 w/cucumber , BDD Fastly-IO-Infoに頼るとCDN依存のテストになり Akamai２Fastlyでテスト先が変わった時に結果を担保できない responseをdecodeして、 メタデータを読んで 期待通りか確認 test観点の一例 png or jpeg ?? aspect ratio ?? width, height OK?? feature file / 今までより幾分か仕様が分かりやすく見えるように。
30. 30 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Ops > CI/CD CDNレイヤーのテスト nodejs / mocha, chai で実装 テスト項目 • 各種Cache関連のヘッダー • 許可メソッド • 許可hostname • 許可クエリ • Expire, TTL, CacheKey • gzip/br圧縮確認 • etc. 構成はごく単純 / stg の test が通らないと本番の applyは出来ません
31. 31 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Ops > モニタリング > logs log Fastly -> Datadog logs の連携 logs経由での可視化 • Custom サブルーチンのcall回数 • Requestが流れた ◦ POP分布 ◦ hostname分布 流量調整をしないと課金死するので、 Fastly,Datadog両軸で絞っている 1/10,000 のレートでログを保持 Fastly2Datadogのlog量を 1/100 にサンプリングしています
32. 32 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Ops > モニタリング > Datadog Datadog origin / Fastly を一枚ッペらで見れるようDashboardを準備 Datadogのダッシュボード / 一覧で見れるとテンションが上がる
33. 33 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Ops > モニタリング > Datadog Datadog Fastlyへのdeploy eventを打っておくとグラフに表示出来て便利 本番deployのGitHub Actionsにsetを追加しています、git hash も登録すると何かと便利 / We did it !! ✌
34. 34 Fastly yamagoya 2022 お引越しプロジェクト：実装編 つづいてDev
35. 35 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 考えたことサマリ 実装前に考えたこと IO利用なので、Shieldingは必須要件。その上での、、 • Cache設計 ◦ Cache期間 / Cache更新 ◦ ネガティブCache ◦ CacheKey ◦ 実装方針 ※Shielding時の注意点含む • vcl実装方針 ◦ debug を見据えた打ち手 • IO用特別実装 • 負荷対策 > Shielding , Clustering
36. 36 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > Cacheのお気持ち > TTL Cache期間の考え方 CDNとclientで保持TTLは同一のものを採用 Amebaの画像コンテンツの特性上更新の可能性が著しく低く URLもimmutableなものが設定されているため （purgeして中身の差し替えを頻繁に伴うユースケースではない） Cacheの再検証をして欲しいタイミングが少ないので、その方針で行く Cacheの更新性が高く、 CDN purge連携が十分に行われている場合は Edge TTL > client TTL 方式を採用してもよいが、 今回は対象にならなさそう
37. 37 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > Cacheのお気持ち > 更新 Cache更新の考え方 基本的にCacheの再検証に関して、client がハンドリングする必要はない client観点で言えばerror Response の cache期間は十分に短く、 CDN観点で言えば origin error の場合に関して CDN 上で適切に負荷を考慮しCacheの再検証すれば良い stale-if-error： fastlyのみが知る、originが死んだ時を考慮。 clientTTLが短い場合はCDNTTLより長く設定 stale-while-revalidate： fastlyのみが知る、基本的にはTTL以下で運用する
38. 38 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > Cacheのお気持ち > CacheKey CacheKey（ ≒ vcl_hash） defaultの... vcl_hash = req.url + req.http.hostを採用 IO利用時には qs が vcl_hash に渡る前に消されてしまうので、 vcl_hash = req.url + req.url.qs を採用したほうがいいのでは？ となるかもしれないが、 IO利用時にはqsがセカンダリハッシュとして登録されるため不要 > The query string normalization described above happens prior to the vcl_hash subroutine and the IO query params are saved in a secondary hash to allow separation of the variants. ref ; https://developer.fastly.com/reference/io/#purging-images-from-the-fastly-cache
39. 39 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > Cacheのお気持ち > 具体ヘッダー つまりどういうことだ？ Cacheに関するお気持ちissueから転記、ドメインでTTLが変わる場合はvcl_hashにhostを入れています
40. 40 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > Cacheのお気持ち > 実装の注意点 実装方針 Shielding有効時は全てのPOPで同一 vcl が実行される また、タイミングによってFastly内でのTTLが２倍に設定されてしまう問題の解決のために Shield POPでのみ Object TTL、SC&CC Header を設定 Edge POPには SC header経由でTTLを伝え、Age分を減算したTTLを設定 > The HTTP Age header allows the backend to indicate that an object has already spent some time in a cache upstream before being served to Fastly. If the response includes an Age header with a positive value, that value will be subtracted from the response's main cache TTL. If the resulting TTL is negative, it is considered to be zero. If the TTL of a response is derived from an Expires header, any Age header also present on the response will not affect the TTL calculation. https://developer.fastly.com/learning/concepts/cache-freshness/#age Client Edge Shield CC header SC header
41. 41 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > Cacheのお気持ち > vclを見てみよう 実装はどうなる？ shieldPOP時（req.backend.is_origin）のみCacheに関する設定を実施 Cache-Controleはclientに渡す設定、Surrogate-ControleはEdge用の設定。各種TTLの設定はS-Cからsubfieldで取ってきて set
42. 42 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > debugは大事 debug用の仕込みの一例の紹介 複雑なvclになればなるほど処理を追うのが厳しくなる ので、trace用のdebug headerを追加する • x-vcl-router：built-in VCL subroutinesをどれだけまたいだか • x-custom-subroutine-route：Custom subroutinesをどれだけまたいだか • x-git-hash：どのversionのvclの挙動なのかの確認 • x-origin-status：fastly-io-errorとorigin statusのマッピング調査で利用 • x-io-token：Ameba独自画像変換クエリ毎のカスタムサブルーチンに設定したtoken • x-cache-key：自分たちが定義したCacheKeyのルール • x-forwarded-qs：IOにわたす前のqs ( Ameba独自画像変換クエリ ) • x-forwarded-io-qs：IOに渡すようにマッピングされたIOServer用クエリ
43. 43 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > debugは大事 debug用の仕込みの一例の紹介 複雑なvclになればなるほど処理を追うのが厳しくなる ので、trace用のdebug headerを追加する • x-vcl-router：built-in VCL subroutinesをどれだけまたいだか • x-custom-subroutine-route：Custom subroutinesをどれだけまたいだか • x-git-hash：どのversionのvclの挙動なのかの確認 • x-origin-status：fastly-io-errorとorigin statusのマッピング調査で利用 • x-io-token：Ameba独自画像変換クエリ毎のカスタムサブルーチンに設定したtoken • x-cache-key：自分たちが定義したCacheKeyのルール • x-forwarded-qs：IOにわたす前のqs ( Ameba独自画像変換クエリ ) • x-forwarded-io-qs：IOに渡すようにマッピングされたIOServer用クエリ built-in VCL subroutinesの先頭に記述 / restartを踏んだときの追跡とかも便利
44. 44 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > debugは大事 debug用の仕込みの一例の紹介 複雑なvclになればなるほど処理を追うのが厳しくなる ので、trace用のdebug headerを追加する • x-vcl-router：built-in VCL subroutinesをどれだけまたいだか • x-custom-subroutine-route：Custom subroutinesをどれだけまたいだか • x-git-hash：どのversionのvclの挙動なのかの確認 • x-origin-status：fastly-io-errorとorigin statusのマッピング調査で利用 • x-io-token：Ameba独自画像変換クエリ毎のカスタムサブルーチンに設定したtoken • x-cache-key：自分たちが定義したCacheKeyのルール • x-forwarded-qs：IOにわたす前のqs ( Ameba独自画像変換クエリ ) • x-forwarded-io-qs：IOに渡すようにマッピングされたIOServer用クエリ • Custom subroutinesの先頭に記述 / early returnでサブルーチンの踏み漏れの検知とか出来て便利
45. 45 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > debugは大事 debug用の仕込みの一例の紹介 複雑なvclになればなるほど処理を追うのが厳しくなる ので、trace用のdebug headerを追加する • x-vcl-router：built-in VCL subroutinesをどれだけまたいだか • x-custom-subroutine-route：Custom subroutinesをどれだけまたいだか • x-git-hash：どのversionのvclの挙動なのかの確認 • x-origin-status：fastly-io-errorとorigin statusのマッピング調査で利用 • x-io-token：Ameba独自画像変換クエリ毎のカスタムサブルーチンに設定したtoken • x-cache-key：自分たちが定義したCacheKeyのルール • x-forwarded-qs：IOにわたす前のqs ( Ameba独自画像変換クエリ ) • x-forwarded-io-qs：IOに渡すようにマッピングされたIOServer用クエリ debug header は deliver で全部詰めてる / git hash は deploy 時の GitHub Actions で vclを書き換えて適用してます
46. 46 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > debugは大事 debug用の仕込みの一例の紹介 複雑なvclになればなるほど処理を追うのが厳しくなる ので、trace用のdebug headerを追加する • x-vcl-router：built-in VCL subroutinesをどれだけまたいだか • x-custom-subroutine-route：Custom subroutinesをどれだけまたいだか • x-git-hash：どのversionのvclの挙動なのかの確認 • x-origin-status：fastly-io-errorとorigin statusのマッピング調査で利用 • x-io-token：Ameba独自画像変換クエリ毎のカスタムサブルーチンに設定したtoken • x-cache-key：自分たちが定義したCacheKeyのルール • x-forwarded-qs：IOにわたす前のqs ( Ameba独自画像変換クエリ ) • x-forwarded-io-qs：IOに渡すようにマッピングされたIOServer用クエリ origin ResponseでのIOの挙動を確認 / 調査 issue の軌跡から転記
47. 47 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > debugは大事 debug用の仕込みの一例の紹介 複雑なvclになればなるほど処理を追うのが厳しくなる ので、trace用のdebug headerを追加する • x-vcl-router：built-in VCL subroutinesをどれだけまたいだか • x-custom-subroutine-route：Custom subroutinesをどれだけまたいだか • x-git-hash：どのversionのvclの挙動なのかの確認 • x-origin-status：fastly-io-errorとorigin statusのマッピング調査で利用 • x-io-token：Ameba独自画像変換クエリ毎のカスタムサブルーチンに設定したtoken • x-cache-key：自分たちが定義したCacheKeyのルール • x-forwarded-qs：IOにわたす前のqs ( Ameba独自画像変換クエリ ) • x-forwarded-io-qs：IOに渡すようにマッピングされたIOServer用クエリ 変換クエリのCustomサブルーチンごとに token を設定 surrogate key に設定する事により、クエリルールが変わった場合に 対象画像を purge 出来るようにしている / IO のrestart実装の制約により一部クエリは surrogate key purge 出来ない、が後述
48. 48 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 一部特殊実装 restartを挟んだIO処理について IOには画像のメタデータを読んでから処理するということが出来ない > 元画像の長辺を指定したサイズでリサイズ > 元画像が5000px超えてたら強制的にリサイズ 例えば、こういう条件の処理はあるあるだけど出来ない が、IOを通過させるとFastly-IO-Info Headerを取得できる > ifsz=108501 idim=827x788 ifmt=jpeg ofsz=13066 odim=300x286 ofmt=jpeg ので、クエリのない状態で一度IOを通過させたあとにvcl_deliverで Fastly-IO-Info Headerを見て、IOのクエリへ書き換えて restartして vcl_recvへ戻して再びIOで処理する
49. 49 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 一部特殊実装 restartを挟んだIO処理の注意点 • restartを挟むと、 ◦ Shielding、Clustringが無効になるので有効化する ◦ Requestフローを理解したCHR向上の実装が必要 • 初回IO通過後は qsが消えているので、 ◦ デバッグで出したい場合は、変数に退避させてrestart後に読め るようにする必要がある
50. 50 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 一部特殊実装 restartを挟んだIO処理の注意点 • restartを挟むと、 ◦ Shielding、Clustringが無効になるので有効化する ◦ Requestフローを理解したCHR向上の実装が必要 • 初回IO通過後は qsが消えているので、 ◦ デバッグで出したい場合は、変数に退避させてrestart後に読め るようにする必要がある これらを意識した上でどう実装に落としたのかと 気になりポイントを喋る
51. 51 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 一部特殊実装 > 実装前のおさらい > クラスタリング クラスタリングとは • default有効 ◦ POP内のnodeをdelivery/fetch に分けキャシュ効率を上げる • delivery node でCacheすることもある • Shieldingとは別概念。restartで無効 オブジェクトごとに最適なnodeを選択して、CHRを上げられるようにする工夫がある > In order to improve the likelihood of finding a hit in the cache, objects are assigned to specific storage servers based on each server handling a portion of the possible address space for cache keys, a mechanism known as consistent hashing. After calculating the object's cache key, the delivery node will transfer the request to the server which owns the address space containing that cache key. This second server will be responsible for fetching the object from origin and storing it, and in performing this role, is known as the fetch node. ref ; https://developer.fastly.com/learning/vcl/clustering/
52. 52 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 一部特殊実装 > 実装前のおさらい > シールディング シールディングとは • 多段POP ◦ Edge POP / Shield POP と分けてCHR向上を狙う • すべてのPOPで同じvclが実行されるので、加味した実装が必要 • Clusteringとは別概念。restartで無効 多段POPでCHR向上だ、の図。ShieldPOPの選択はユーザーに委ねられる 特性上、EdgeとShield、それぞれで実行したい推奨処理がある。これを意識して実装しよう
53. 53 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 一部特殊実装 > 実装前のおさらい > Clustering & Shielding POPのリクエストの流れ / Clustering,Shielding 有効時 • かなり多段でRequestを流すので、それを意識した実装をしたい > If a service has shielding enabled, a request that is not satisfiable from cache will transit two POPs. With clustering also enabled (which is the case by default), the request may encounter a maximum of two POPs and four sites on it's way to origin, as illustrated below: ref; https://developer.fastly.com/learning/concepts/pop/
54. 54 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 一部特殊実装 > 実装前のおさらい > vcl lifecycle built-in VCL subroutinesのライフサイクル • 当たり前だけど重要な知識 何回も見直すことになる ◦ fetch nodeで実行されるサブルーチンもここに記載されている • クラスタリングのfetch node と、このfetchは違う概念 当たり前 https://developer.fastly.com/learning/vcl/using/#the-vcl-request-lifecycle
55. 55 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 一部特殊実装 > 実装前のおさらい > 概念をまとめると... Edge POP delivery node fetch node Shield POP delivery node fetch node vcl_recv vcl_hash vcl_recv vcl_hash vcl_miss vcl_miss vcl_log vcl_deliv vcl_fetch vcl_log vcl_deliv IO Server Origin client フローを理解しよう / 初回Requestで何もCacheHitしない場合 IO Server vcl_fetch
56. 56 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 一部特殊実装 > 実装概要 > restartを挟んだIO処理 client Edge POP Shield POP IO Server Origin Server 1）メタデータ準備フェーズ req.url : /yabai.jpeg?ameba=xxx 独自クエリパラメータを変数に退避。その後、変換対象画像をIOServerに食わせる fastly-io-infoが付与されて返ってくるので、以降、メタデータを読んだ処理が可能になる ついでに、変換なしのorigin画像CacheをShieldPOPのFetch nodeに詰めている。Cacheの有効活用 その後、Edge POP deliver node の vcl_deliver で 独自クエリパラメーターと画像メタデータを読んだ上で IO用のクエリへ組み替えて、restart 。後続フェーズへ渡す ２）単純変換フェーズ req.url : /yabai.jpeg?io-param=xxx restart後、Shielding、Clusteringが無効になっているので有効化する。Cache空間の有効活用 前段フェーズでIO用のクエリに組み替えられた上でRequestを渡されているので、通常フローで変換画像をリクエスト １回目、２回目共に、Edge Shield間を流れるRequestのqsに一貫性をもたせてCHRを上げたいという側面もある
57. Edge POP delivery node fetch node Shield POP delivery node fetch node vcl_recv vcl_hash vcl_recv vcl_hash vcl_miss vcl_miss vcl_fetch vcl_log vcl_deliv vcl_fetch vcl_log vcl_deliv IO Server Origin Edge POP delivery node fetch node Shield POP delivery node fetch node vcl_recv vcl_hash vcl_recv vcl_hash vcl_miss vcl_hit vcl_log vcl_deliv vcl_fetch vcl_log vcl_deliv お引越しプロジェクト：実装編 > Dev > 一部特殊実装 > 実装概要 > シーケンス書き起こし 1) /yabai?ameba=xxx 2) req : /yabai (empty io-param) 14) /yabai?io=xxx 5) req : /yabai (empty io-param) 3) req : /yabai?ameba=xxx 4) req : /yabai (empty io-param) 6) req : /yabai IO Server 7) req : /yabai 8) res 9) res 10) res : (Untransformed) 11) res : (Untransformed) 12) res : (Untransformed) 13) res : (Untransformed) restart & build io param @vcl_deliv IO Server IO Server 15) req : /yabai (with io-param) 16) req : /yabai?io=xxx 17) req : /yabai (with io-param) 18) req : /yabai (with io-param) 19) req : /yabai 20) res 21) tramsform image 22) res : (transformed) 23) res : (transformed) 24) res : (transformed) 25) res : (transformed)
58. 58 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 一部特殊実装 > 実装概要 > に至るまでの反省 この構成に至るまでの２大失敗 • restart , req.url 書き換えを EdgePOPに固定していない • restart後のClustering,Shieldingの有効化をしていない vcl_deliverに入ったら、qsの組み換えとrestartをするという実装 ShieldPOPでrestart、その後EdgePOPでもrestartする処理に。 無駄origin reqの増加📈 CHRの低下📉 更に、restart後のClustering,Shieldingも無効化されていた Fastly内のCache空間の有効活用も出来ず、 無駄origin reqの増加📈 CHRの低下📉 これにより引き起こされたコト
59. 59 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 一部特殊実装 > 実装の具体Code抜粋 特殊実装処理をEdgePOPに固定 Edge POPかどうかの判定を入れるだけ。Shielding有効時のvcldouble実行を意識した実装観点と少し近い。 ref ; https://developer.fastly.com/learning/concepts/shielding/#double-execution
60. 60 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 一部特殊実装 > 具体実装の抜粋 Shielding、Clusteringの有効化 Shielding再有効化のロジックはFastlyが自動生成する処理を参考に記載 Show VCL で処理が見れるのでマネジメントコンソールから見てみよう
61. 61 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > 一部特殊実装 > 具体実装の抜粋 Shielding、Clusteringの有効化 一行、シュッと 変更するだけなので便利 Clustering有効化の設定なのに、Fastly-Force-Shieldの設定値を触るのは直感的ではない...!!
62. 失敗の軌跡 62 Fastly yamagoya 2022
63. 63 Fastly yamagoya 2022 失敗の軌跡 > 移行計画 > おっちょこちょい PoC切り替え５時間前、IO有効化申請忘れに気付く 事前検証のsemiドメインに対し test等の確認をしまくっていた 同じvclが当たってるし良いだろ、 と思っていたら肝心のIOが無効 本番ドメインに testを回したら真っ赤 サポートがチョッパヤで切り替えに間に合いました。圧倒的感謝 朝３時台に気付く / 佳境っぷりがわかるスクショ
64. 64 Fastly yamagoya 2022 失敗の軌跡 > 移行計画 > おっちょこちょい PoC切り替え30分後ﾏﾃﾞ IOで変換せずOriginの変換ｻｰﾊﾞｰが活躍 事前検証のsemiドメインに対し test等の確認をしまくっていた 同じvclが当たってるし良いだろ、 と思っていたら肝心のIO有効 semi に限定されるvclの正規表現に。 Fastlyが変換しているというtestを追加しました。反省 Client CDN w/変換 Origin 画像配信＆一部変換仕様 🔥
65. 65 Fastly yamagoya 2022 失敗の軌跡 > 移行計画 > おっちょこちょい PoC中、攻めすぎて休日ピーク帯にCacheKeyを変える 時間がない!!と焦りすぎたのと、 自分を変に過信し、 CacheHit率向上の打ち手として、 休日の夜間に大胆にCacheKeyを変更。 8GbpsがOriginに落ちてきて死亡 CHRガク下がり、OriginReq爆上がり 最速でrevert PRして 5minで切り戻しました（アウト Cacheヒット率の変動が凄い / リリースの赤い棒がなんか悲しいですね
66. 66 Fastly yamagoya 2022 失敗の軌跡 > ImageOptimizer > png圧縮 png2pngの変換で圧縮が弱い https://note.jp/n/n516042eef752 もともと、png2jpegで変換を噛ましていたところが IO切り替え後の方にjpeg変換されず転送量が多くなってしまった。 LCPが超悪化！！コレはまずい！！ format=jpegを差し込んで 回避！！！むしろ早くなった！！ pngの事前パフォーマンス評価が 漏れてて反省 もともとjpeg変換してた、の図 / 変換対象のtest漏れの結果ですね、悲しい
67. 67 Fastly yamagoya 2022 失敗の軌跡 > ImageOptimizer > png圧縮・その２ png2jpegの変換でアルファチャンネルが欠落 （アルファチャンネルが欠落して） 透過画像が透過じゃなくなったんですが... という問い合わせが増加。 アルファチャンネルの有無でIOを 挟むという選択肢が取れないので、 format=webply で一律回避！！ デザイナーと再度Quality調整を行いつつ 今回もQuality：85で実施 ヤバい画像の png versionが爆誕 / file形式ごとにちゃんとQuality比較するべき
68. 68 Fastly yamagoya 2022 失敗の軌跡 > ImageOptimizer > warning fastly-io-warning: Failed to shrink image IOで指定してるQualityよりも 低い画像をIO通そうとすると出るエラー このwarningの中身...! は、documentには存在しない!! warningの中身読めば分かる けど、メモ https://developer.fastly.com/reference/http/http-headers/Fastly-IO-Warning/
69. 69 失敗の軌跡 > ImageOptimizer > スラッシュ問題 IO有効時、URLにスラッシュが複数含まれるとエラー 不正なURLのRequestがoriginに降りてくると適切なURLにリダイレクトしていた が、IOがoriginのリダイレクトに対応してなさそう 対策としてset req.url = regsuball(req.url, "/+", "/");を入れて回避 IO以外のAPI配信にも展開した所、クエリパラメータに含まれる http://までhttp:/になり大惨事(Bad Request祭) なんでも展開するのは辞めましょう （それはそう Fastly yamagoya 2022 double / のRequestに対して、IOで 500 error 返ってるの図
70. 70 Fastly yamagoya 2022 失敗の軌跡 > vcl > マクロ vcl内のマクロを意識して書こう #FASTLY ${built-in VCL subroutine name} ユーザーのCustom vclを元に、Fastly上にvclをgenerateする時に マクロの部分にFastlyがcodeを挿入する #FASTLY fetch auto gzip 有効の場合 Fastlyが bresp.http.Varyを 書き換えてくれるが、 その処理の場所を意識せずに、 unset bresp.http.Vary すると無駄 Fastly fetch begin 以降がFastlyによって挿入されている / コンソールの show vclで見てみよう
71. 71 失敗の軌跡 > vcl > deliver_stale SIEを有効にするにはreturn(deliver_stale)が必要 https://developer.fastly.com/solutions/tutorials/stale/#deal-with-origins-that-are-down Fastly yamagoya 2022 ドキュメントはちゃんと読もう
72. 72 失敗の軌跡 > vcl > Shield有効時のSWR Shield POPとして動作している場合はSWRを無効 fastly内で古いコンテンツが新規コンテンツとしてEdgePOPに キャッシュされる可能性を排除するために、Shield POP として動作 している場合は SWR を無効にする https://developer.fastly.com/learning/concepts/stale/#shielding-considerations Fastly yamagoya 2022
73. 73 失敗の軌跡 > vcl > early returnでのやらかし IOクエリの対象となった場合returnするようにしてい たが… 度重なる編集でreturnのスコープがずれてしまい一部のクエリを評 価後すべてreturn(lookup)になってしまった Akamaiのconfig評価(あと勝ち)と若干違うので注意したい debug用の router header で処理を追えるようにしないと まじでわけわからんくなる Fastly yamagoya 2022 これだけの差が、大量のバグに！！ガハハ！！
74. 移行後、gzipで配信してたのでPerformance劣化が起きて気付く。 LA Programに申し込み、圧縮対象のContentTypeを見直し 結果的に配信サイズの減少📉 74 失敗の軌跡 > brotli 圧縮の移行漏れ brotli圧縮の設定移行を忘れて配信サイズが📈 サポートに問い合わせればさっくり有効化可能 / 対象等の設定は gzip のモノがそのまま適用される。FastlyがやってくれるVary のAuto normlizeもbrに対応済み Fastly yamagoya 2022
75. 75 失敗?の軌跡 > Shield POPの選定 POPの選定手法が適当だった メトロポップを選定 NRTと弊社DCの接続性が良かった事も選定理由（サポートに助けていただきました） > Metro POPs have the largest cache capacity on the Fastly network and are therefore good choices for shield locations. ref ; https://developer.fastly.com/learning/concepts/pop/#metro-pops Fastly yamagoya 2022 documentには書いてないが、API経由で叩けばメトロであることが分かる
76. 76 失敗の軌跡 > 大量のやらかし 時間が足りない・・・！ 本当はあと２倍の量のやらかしがあります！！ どこでも絡んで下さい！！ 言いまくるので！！ Fastly yamagoya 2022
77. まとめ 77 Fastly yamagoya 2022
78. 78 Fastly yamagoya 2022 まとめ > Performanceの変化 よろこびの声 • Ω「 見直しの良い機会になった ◦ 転送サイズ半分、LCPも同等の改善 ◦ brotli圧縮対象範囲拡大、よりコスパの配信に。 • Ω「 狙ってたコストメリットも出た LCPが半額になりました / 画像サイズ爆下げ〜〜〜 speedcurvのメトリクスで見ても 切り替え前後では軒並みサイズ大幅減！やった〜〜 左が切り替え後 / 1s ちょっと早くなりましたね
79. 79 Fastly yamagoya 2022 まとめ > Fastlyを改めて触ってみて お気持ち • fastly.io/image.jpg , fiddle が用意されてるのはめっちゃ良い ◦ fiddleは特に PR Reviewの時に凄く使った ◦ 試し実装の固定URLが発行されるのが良い • Fastlyは自分で実装できる範囲が広い ◦ こまやかな挙動の変更が自由自在 ◦ その代わり、かなりドキュメントを読み込まないとキツイ ◦ ドキュメントは全部読もう。ドキュメントは全部読もう。ドキュメン • 分散システムのキャッシュ難しくない？ ◦ でも、そこが面白い。がんばります
80. お気持ち > 総集編 80 とっても楽しかったです Fastly yamagoya 2022
81. お気持ち > 総集編 81 楽しくWebしたい人、積極採用してます！ Fastly yamagoya 2022
82. お気持ち > 総集編 82 Fastly yamagoya 2022 https://about.ameba.jp/ameyoko/
83. 使わなかったスライド 83 Fastly yamagoya 2022
84. 84 Fastly yamagoya 2022 お引越しプロジェクト：実装編 > Dev > Cache設計 ここで、Shieldingとかについてのおさらい • Shielding ◦ 多段POP ◦ Edge POP , Shield POP , 同じvclが展開され実行される • Clustering ◦ Shieldingとは紐付かない概念 ◦ POP内のnodeをdelivery, fetchと分けStorage効率を上げる • ※ restartを挟むと ◦ Shielding、Clustering、共に無効になる