大規模 to C プロダクトにおける Fastly VCL サービスから Compute への安全な段階移行

Fastly Yamagoya Night / 2025-10-29
https://fastly-japan.connpass.com/event/372054/

Transcript

1. 大規模 to C プロダクトにおける Fastly VCL サービスから Compute への安全な段階移行 株式会社サイバーエージェント　 谷中一生 © 2025 WinTicket Inc.
2. 谷中一生, Kazuki Taninaka 株式会社サイバーエージェント
 2024年度新卒入社 WINTICKET Web版の開発エンジニア GitHub: kazukitaninaka X: @azoookid 自己紹介
3. なぜ WINTICKET Web は VCL から Compute へ移行したのか Compute への安全な移行 移行の際の苦労ポイント 移行で得た恩恵 アジェンダ
4. WINTICKET について 公営競技（競輪・オートレース）の業界 シェアNo.1のオンライン投票サービス ローンチ当初（2019年）より、CDN と して Fastly を使用 モバイルアプリ版、Web 版を提供 今回はWeb版のお話
5. サーバーサイドレンダリングを行う、Isomorphic な Webアプリケーション CDN キャッシュに大きく依存した設計 UIレンダリングによるオリジンサーバーへの負荷軽減 JS / 画像等、静的アセット配信の高速化 VCLを使用した、Edge でのロジック実行も行っている WINTICKET Web版について 約97%のキャッシュヒットレート
6. なぜ WINTICKET Web は VCL から Compute へ移行したのか
7. VCL のメンテナンス性に課題感があったから
8. （当たり前だが）VCL という設定言語、独自 ライフサイクルについて深く理解する必要が ある 一般的に Web フロントエンドエンジニア にとっては馴染みが薄い WINTICKET では Web 開発チームメンバーが CDN の管理も行う必要があるが、そのメンテ ナンスは一部メンバーに限られてしまう状態 課題感1: VCL への適切な理解が求められる点 https://www.fastly.com/documentation/guides/full-site-delivery/fastly-vcl/about-fastly-vcl/
9. VCL は基本的にはテストが難しい falco を使用したユニットテストの導入はしていたが... 一部リクエストの値のオーバーライドなどができない などの制約があった Subroutine 単位でのテストも可能だが、プログラミング 言語における関数のような単位でロジック分割は不可能 課題感2: テスタブルでない点
10. オリジンの分岐 Web アプリケーションサーバー 静的アセット配信サーバー 適切なキャッシュ分離を行うための、リクエスト ヘッダ、Varyヘッダの設定 e.g. Cookie をみて、ユーザーのログイン状態 を判定し、ログイン状態によるUIレンダリング のキャッシュ分離を行う 開発者用リソースへのアクセス制御 etc... 合計約500行 WINTICKET Web が VCL でやっていること
11. CDN ロジックが膨れすぎていないこのタイミングで Compute に移行することに
12. 公営競技投票というサービス特性上、大きなお金が動く 移行による事故は許されない
13. 段階的に移行をすることに
14. Compute への安全な段階移行
15. 安全な段階移行方法 Service Chaining x ページパスベースでの段階適用
16. 安全な段階移行方法 Service Chaining
17. Service Chaining https://www.fastly.com/documentation/guides/concepts/service-chaining/
18. Service Chaining 移行する上でこの手法を用いることにした
19. 安全な段階移行方法 ページパスベースでの段階適用
20. ページパスベースでの段階適用 ①特定のパス Compute においてロジック発火 & キャッシュ ②それ以外 これまで通り VCL サービスでのロジック発火 & キャッシュ →①に該当するページパスを徐々に増やしていく
21. ページパスベースでの段階適用 段階移行する上での全体アーキテクチャ
22. ページパスベースでの段階適用 パスベースで段階移行するための分岐点
23. ページパスベースでの段階適用 特定のパスでない→今まで通り
24. ページパスベースでの段階適用 特定のパスである→VCLでは何もせずService Chaining
25. ページパスベースでの段階適用 これをどう実現している？
26. VCL でのロジック実行 & キャッシュをさせないために Request settings, Cache settings において、 Condition に任意のページパスを指定 Action に Pass(do not cache) を指定 することで、VCLロジックを実行 & キャッシュを させないようにする https://www.fastly.com/documentation/ja/guides/full-site-delivery/ conditions/using-conditions/
27. VCL でのロジック実行 & キャッシュをさせないために 最終的に出力されるVCL
28. VCL でのロジック実行 & キャッシュをさせないために 既存VCLロジックに手を加えずに、Service Chainingさせられる 最終的に出力されるVCL
29. ページパスベースでの段階適用 徐々にComputeサービス経由のリクエストを増やしていく
30. ページパスベースでの段階適用の考慮ポイント ユーザー影響の少ないページから少しずつ 競輪の大きなレースが開催される日は避ける 全てのリクエストがComputeに流れるようになったら...
31. Compute への一本化 全てのパスがComputeに流れるようになったら、最後にVCLを廃止する VCLサービス (www.winticket.jp) Computeサービス (*.winticket.jp) Computeサービスは ワイルドカードドメインに ユーザー オリジンサーバー
32. Compute への一本化 全てのパスがComputeに流れるようになったら、最後にVCLを廃止する VCLサービス (www.winticket.jp) Computeサービス (*.winticket.jp) deactivate ユーザー オリジンサーバー
33. Compute への一本化 全てのパスがComputeに流れるようになったら、最後にVCLを廃止する VCLサービス (www.winticket.jp) Computeサービス (*.winticket.jp) deactivate ユーザー ワイルドカードドメインのため 自動で www.winticket.jp へのアクセスは Compute サービスへ向くように →ゼロダウンタイム移行が可能に オリジンサーバー
34. Compute への一本化 全てのパスがComputeに流れるようになったら、最後にVCLを廃止する VCLサービス (www.winticket.jp) Computeサービス (*.winticket.jp) deactivate ユーザー ワイルドカードドメインのため 自動で www.winticket.jp へのアクセスは Compute サービスへ向くように →ゼロダウンタイム移行が可能に オリジンサーバー 完全移行完了
35. 移行した際の苦労ポイント
36. 動的圧縮 vs 静的圧縮 Compute では動的圧縮のみサポートされている 動的圧縮は、圧縮結果がキャッシュされず、圧縮 率は静的圧縮に比べて下がる パフォーマンスの悪化に繋がる WINTICKET では静的アセットも含め、Fastly の圧縮 に依存していた 静的アセットはビルド時に圧縮、HTML のみ動的圧縮 を許容する形で対応 https://www.fastly.com/documentation/guides/concepts/compression/
37. 動的圧縮 vs 静的圧縮 Before(101kB) HTMLのサイズは少し増えてしまったが 手元における若干のユーザー体験の悪化 < Compute導入の恩恵 と判断 After(130kB)
38. Vary Header によるキャッシュ分離が効かない JS SDK において、HTTP Cache API を有効化 したとき、Edge 上で付与した Vary による キャッシュの分離が機能しない issue: https://github.com/fastly/js- compute-runtime/issues/1178 オリジンサーバーで必要なVaryをあらかじめ付与す ることで対応
39. 移行して得た恩恵
40. 移行して得た恩恵 CDN 設定・ロジックの見通し・メンテナンス性の向上 JavaScript(TypeScript) でのロジック記述ができる→チームとしてメンテしやすく 適切な粒度にロジック分割し、単体テストで挙動の担保ができる Hono（Web フレームワーク）を使用することで、宣言的に記述できる 環境ごとの値の分岐を Config Store に逃すことができる アクセスログに任意の情報を付与できるようになった e.g. ユーザーID
41. Thank you! 導入にあたって、澤田さんをはじめ多くのFastlyサポートの皆様にご支援いただきました。 ありがとうございました！