柔軟なキャッシュ運用で実現する 高速かつ安定した配信基盤

ツール導入前の課題

• 画像配信における品質・安定性の問題

  • 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 対応が整備されておらず、実際の動きを確認しにくかったことで、原因調査の難易度がより高くなっていました。

• Terraform などの IaC で設定を管理しておくと、複雑になりがちな CDN や VCL の設定変更を履歴管理でき、環境間の差分やヒューマンエラーを防ぎやすくなる。運用の安定性が大きく向上するため、導入時から IaC 化を前提に設計しておくことを強くおすすめしたい。

今後は、Fastly の VCL を用いたエッジ側での振り分け機能を活用し、AWS 側のローリングデプロイから、より安全性の高い Blue-Green デプロイへ移行していきたいと考えています。VCL でオリジンの切り替え条件を柔軟に制御することで、ユーザー影響を最小化しながら段階的なリリースや切替が可能となり、デプロイの信頼性向上につながる見込みです。