柔軟なキャッシュ運用で実現する 高速かつ安定した配信基盤
株式会社スペースマーケット / wado63
テックリード / フロントエンドエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
| 利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|---|
カスタムプラン | CDN, Image Optimizer | 11名〜50名 | 2018年8月 | C to C |
| 利用プラン | カスタムプラン |
|---|---|
| 利用機能 | CDN, Image Optimizer |
| ツールの利用規模 | 11名〜50名 |
| ツールの利用開始時期 | 2018年8月 |
| 事業形態 | C to C |
アーキテクチャ
.png?disposition=inline)
アーキテクチャの意図・工夫
ユーザーアップロード画像や JavaScript・CSS などの静的アセットは Fastly を経由させることでキャッシュが効き、S3 からの配信を最適化しています。また、アプリケーションの前段に Fastly を配置することで、ALB へ至る前に動的コンテンツのレスポンスもキャッシュ可能となり、Fastly の高速 Purge 機能を活かしてサービス要件に合わせた柔軟なキャッシュ制御を実現しています。
さらに、Fastly の VCLを用いることで、ユーザー属性に応じた制御や A/B テストなど、キャッシュを活かしながらもアプリケーションを支援する仕組みも組み込んでいます。
加えて、Fastly のログを Datadog に送信することで、CDN レイヤーのログとバックエンド(ALB や ECS)のログを突き合わせながら一元的に可視化でき、デバッグ効率と運用性を向上させています。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
画像配信における品質・安定性の問題
- Rails と ImageMagick を用いてスペース画像を自社で変換・配信する仕組みを運用していたが、変換処理の品質が安定せず、不具合が発生することが多かった。
- 特に ImageMagick 周りでのメモリリークの問題などにより、運用側での手作業による対処が必要な状況が続き、開発リソースを圧迫していた。
アクセス急増に対するインフラの脆弱性
- テレビ CM 放映などのタイミングでは、定常的に手動でスケール対応を行っており、アクセス急増に耐えられるインフラが必須だった。
- しかし当時の構成では、サーバーリソースを増強しても DB 負荷などシステム上のボトルネックが解消されず、一部でエラーが発生するケースもあり、安定したユーザー体験を提供できるとは言い切れない状況だった。
スケーラビリティと運用コストの限界
- 手動対応が必要な運用設計であったため、サービス成長に伴って工数が比例して増えていく構造になっていた。
- 大量アクセスに耐えるためにサーバーの増強を行うにもコストが大きく、効率的なスケールが難しい状態だった。
ページ表示速度による SEO・ユーザー体験の課題
- ランディングページの描画に必要な API のレスポンスが遅く、ページ表示速度が SEO とユーザー体験の両面で課題となっていた。また、この API を改善するには相応のチューニング工数が必要だった。一方で、ランディングページ自体は更新頻度が低いため、毎回リアルタイムで API に依存する必要はなく、より効率的な高速化手段の検討が求められていた。
どのような状態を目指していたか
高速で安定したコンテンツ配信基盤の実現
- CDN とイメージ最適化基盤を導入することで、ページ表示の高速化を達成し、ユーザー体験を改善したかった。
- 自前実装から脱却し、画像変換や配信を高品質かつ安定した外部サービスに任せることでトラブルを減らしたかった。
サービス拡大に耐えられるスケーラブルな基盤づくり
- アクセス増加やコンテンツ増加があっても、サーバー増設を最小限に抑えながら高パフォーマンスで動作する構成を求めていた。
- 長期的視点で「スペースシェアをあたりまえにする」ための成長に耐える柔軟かつ拡張性の高い基盤を整備することが目標だった。
ページ表示速度の最適化による SEO・ユーザー体験の向上
- ランディングページの表示速度を安定的に高速化し、SEO やユーザー体験の改善につなげることを目指していた。特に、更新頻度の低いページである特性を踏まえ、API の詳細なチューニングよりも、CDN キャッシュを活用して効率的かつ低コストに高速化を実現できる構成を理想としていた。
比較検討したサービス
- Amazon CloudFront
- Cloudinary
比較した軸
フルマネージドで運用できること
インフラ運用や最適化処理を自前で担わずに済むことを重視。
障害対応・メンテナンス負荷を大幅に減らせるフルマネージド型が必須条件だった。高速キャッシュ基盤を活かした安定した配信ができること
ユーザー増加時のレスポンス低下を防ぎつつ、 Fastly の 高度なキャッシュ制御(柔軟なTTL設定や条件分岐、即時パージ) によって コンテンツ配信が常に最適化されるかを検証ポイントとした。画像サイズ変換・最適化が可能であること
デバイスごとに最適なサイズへ自動変換できることを重視。
手動作業や自前実装から脱却し、品質と効率の両立を目指した。
選定理由
フルマネージドで運用コスト(人的工数)を大幅に削減できること
多少費用が上がっても、- 障害対応の削減
- 実装工数の圧縮
- 運用負荷ゼロに近い形
など、総合的に得られる価値が非常に大きかった。
アクセス急増(テレビCMなど)にも対応できるスケーラブルな基盤を構築できること
テレビなどの露出をきっかけにアクセスが急増するケースがあり、 トラフィック増加を前提とした基盤強化が必須だった。 その中で、少ないサーバー増設で高負荷に対応できる Fastly のアーキテクチャは非常に魅力的だった画像最適化機能が豊富で、自前運用から脱却できたこと
WebP 対応・自動リサイズ・高品質な最適化など、これまで自社で苦労していた領域を完全に任せられる機能性が魅力だった。
メモリリークなどの不具合対応から完全に解放される点も決め手になった。
導入の成果
画像配信の品質・安定性の問題は大幅に改善
自前の画像変換処理で頻発していた品質のばらつきやメモリリークなどの不具合が解消され、安定した画像最適化が実現した。キャッシュによるアクセス急増への耐性が向上
テレビCM放映によるトラフィック増加に対し、
少ないサーバー増設のみで 1.2〜1.5倍のアクセス増 に耐えられる構成を実現。
以前懸念されていたインフラ負荷やスケーラビリティの課題が解消された。
導入時の苦労・悩み
- Fastly 側の TLS オプション(Shared / Customer-Provided)の仕組みや契約内容と、実際に利用していた構成が噛み合っておらず、二重課金やどの証明書を使うべきかの整理に手間取りました。
- Fastly を配信経路に挟んだことで、キャッシュのヒット状況やリクエストの流れが追いづらくなり、挙動のデバッグに苦労しました。 さらに当初は開発環境側の Fastly 対応が整備されておらず、実際の動きを確認しにくかったことで、原因調査の難易度がより高くなっていました。
導入に向けた社内への説明
上長・チームへの説明
- まず、フルマネージド化により運用コスト(障害対応・画像最適化基盤の保守)が削減できる点を明確化し、技術的要件(WebP・画像変換対応、既存機能との互換性)を満たすことを確認した。
- 試算では現行より費用が増加する(例:月 +1〜2万円)ことを共有し、コスト増と運用負荷削減によるメリットをどう天秤にかけるかをチームで検討した。
- 最終的には、運用効率化・サービス高速化・画像最適化の一元化という中長期的なメリットがコスト増を上回ると判断し、Fastly の採用方針とした。
活用方法
よく使う機能
- Image Optimizerによる画像の最適化
- Surrogate Key、Soft Purgeを使ったキャッシュ管理
- VCLによるHeader、Cookie制御
ツールの良い点
- Soft Purge により、ユーザー体験を損なわずに安全なキャッシュ更新ができる。
- Surrogate Key を活用することで、大規模サービスでも柔軟かつ効率的なキャッシュ管理が可能。
- 画像変換 API がシンプルで扱いやすく、運用負荷を抑えながら最適な画像配信を実現できる。
ツールの課題点
- 高度な制御を行える反面、VCL を扱うためには一定の学習コストがかかり、導入初期は仕様理解やデバッグに時間を要する場面があった。
- 支払情報や利用状況に関して一時的に確認しづらい時期があり、サポートへ問い合わせて対応いただく場面があったため、運用上は適宜状況を確認しながら進める必要があると感じた。
ツールを検討されている方へ
- Terraform などの IaC で設定を管理しておくと、複雑になりがちな CDN や VCL の設定変更を履歴管理でき、環境間の差分やヒューマンエラーを防ぎやすくなる。運用の安定性が大きく向上するため、導入時から IaC 化を前提に設計しておくことを強くおすすめしたい。
今後の展望
今後は、Fastly の VCL を用いたエッジ側での振り分け機能を活用し、AWS 側のローリングデプロイから、より安全性の高い Blue-Green デプロイへ移行していきたいと考えています。VCL でオリジンの切り替え条件を柔軟に制御することで、ユーザー影響を最小化しながら段階的なリリースや切替が可能となり、デプロイの信頼性向上につながる見込みです。
株式会社スペースマーケット / wado63
テックリード / フロントエンドエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
よく見られているレビュー
株式会社スペースマーケット / wado63
テックリード / フロントエンドエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法

.png)
