Amazon S3からCloudflare R2とWorkersへの移行で実現したコスト大幅削減
株式会社ファンコミュニケーションズ / teckl
テックリード / バックエンドエンジニア / 従業員規模: 301名〜500名
利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|---|
Enterprise | Workers, R2, CDN | 10名以下 | 2023年2月 | B to C |
アーキテクチャ
![アーキテクチャ図](https://cdn.findy-tools.io/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBYVE9IiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--7463517063da47c9ed13247a6a6a1006e544d70f/CleanShot%202024-06-19%20at%2022.43.08@2x.png?disposition=inline)
アーキテクチャの意図・工夫
Cloudflareの導入前、ユーザ単位で任意のドメイン・ディレクトリごとにパスワードを設定できる機能がありました。この機能は15年以上前から存在していましたが、実際の利用率を調査したところ、アクティブに利用しているユーザは非常に少ないことが判明しました。また、このパスワード認証基盤を維持するためのコストも相応にかかっていました。
導入前のAWS環境時代のアーキテクチャは以下の図の通りです。
![画像名称](https://findy-tools.io/public_images/review/before_aws_cloudfront_s3_ec2.png)
Workersであれば任意のロジックを実装可能ですが、ほとんど使われていない機能を再現するために複雑な実装とコストをかけるより、このCloudflare導入のタイミングで仕様を変更し、シンプルな構成にすることを決断しました。
ユーザへの仕様変更の告知と代替案の調整は多少困難でしたが、この仕様変更の決断により、最終的に非常にシンプルな構成に変えることができました。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
急速な円安の進行により、ドル払いのパブリッククラウド利用料が高騰し、コスト削減が急務となっていました。さまざまなコスト削減策を講じていたものの、円安の終息が見えない中で、抜本的なコスト最適化が必要でした。特に大きなコストがかかっていたのは、CDNのトラフィックとストレージでした。
将来的な円安の進行にも対応し、サービスを安定して継続するために、これまでとは異なるアプローチでのコスト削減方法を検討した結果、Cloudflare R2の発表を受け、導入の検討を開始しました。
比較検討したサービス
- Amazon CloudFront + S3 + EC2 + Nginx + ngx_mruby (移行前に利用)
- Akamai
- Fastly
- CDNetworks
- Google Cloud Storage(GCS)
- さくらのオブジェクトストレージ
- Wasabi
比較した軸
- コスト(エグレス/ストレージ)
- 安定性
- 保守性
- 学習コスト
- 移行コスト
- S3互換
- 単純な配信だけではなく、一定のロジックが実装可能なこと
選定理由
- S3互換のオブジェクトストレージであり、エグレス料金がかからないこと、ストレージ料金が安いこと
- Cloudflare Workersによって柔軟なルーティングやキャッシュの調整が可能であること
が決め手になりました。
導入の成果
コスト削減効果は当初の予想以上でした。
さらに、導入前の認証基盤を含む複雑な配信システムをシンプルに再構築したことで、システム全体の見通しが良くなり、従来の画像配信系サーバ管理から解放されました。キャッシュパージ処理なども再実装によりシンプル化できました。
キャッシュヒット率も導入前とほぼ同等のレベルで維持できています。
導入時の苦労・悩み
導入検討時点では他社事例がなく非常に情報が少なかったのと、またR2がGA直後であったため、実現可能なのかどうかの判断が難しいところがありました。
特に苦労したのがキャッシュの管理と移行手順、従来の挙動の再現です。
1. キャッシュ
Cloudflare では Workers を利用したキャッシュの実現方法が複数あり、 Fetch API, KV, Durable Objects, Cache API など、様々な選択肢がありました。
最適な方法やコストについてはドキュメントだけでは分かりにくく、Cloudflare Japanの方に相談しながら進めました。
2. 移行手順
S3からの移行に際し、コストを抑える方法の検討に苦労しました。
当初「R2 Super Slurper」というツールがありましたが、Beta版であったため難しいと判断し、最終的にrclone というオープンソースのコマンドラインツールを使用しました。
3. 従来の挙動の再現
元々はEC2上のNginxで画像配信を行っていたため、その挙動を再現する必要がありました。特定のファイルのみキャッシュさせない、ユーザ単位で任意のタイミングでキャッシュをパージするなどの機能を実装する必要がありました。初めてCloudflare Workersを使用するため、手探りでの実装となりましたが、移行前とほぼ同様の挙動を再現できました。
上記の詳細な内容については以下で公開しています。
導入に向けた社内への説明
上長・チームへの説明
急激な円安の影響によるクラウドコスト上昇の問題を抜本的に改善する必要があったため、上長と常に連携しながら導入を検討しました。
PoCの検証を進める中で、R2のコストを維持しつつ現行の配信機能を実現できることが確認できたため、他に選択肢はないと判断しました。社内に導入事例はなくチャレンジングで不安もありましたが、大幅なコスト削減が見込めることから、導入を推進しました。
活用方法
よく使う機能
- Cloudflare CDN
- Cloudflare Workers
- Cloudflare R2
- Cloudflare Cache API
- Cloudflare Logpush
ツールの良い点
R2
- エグレス料金が無料
- 安価なストレージコスト
- S3互換性
- シンプルな料金体系
CDN
- 安価で信頼性の高いネットワーク環境
- グローバルエッジサーバによるレイテンシの低減
- 強力なWAF機能(今回は画像配信のため未使用)
Wrangler
- シンプルで超高速なデプロイ
Workers
- JavaScript/TypeScript で挙動を拡張可能
- サーバレスによる従来のサーバ管理からの解放
ツールの課題点
- 柔軟にカスタマイズするにはインフラ以外の知識 (JavaScript/TypeScriptなど)が必要
- ローカル環境での開発が少々大変
- Logpushを利用するにはEnterpriseプランが必須
- S3からR2に移行した場合は現時点では使えない機能もある(バージョニングやストレージクラス、細かいアクセス制御など)
- ただし、ライフサイクルルールやバケット単位のアクセス制御など、導入後に次々と機能が追加されている
- 日々新機能が登場するため、ある程度のキャッチアップが必要
ツールを検討されている方へ
導入検討時、R2がGA直後ということもあり不安もありましたが、1年以上経過しても特に大きな問題は発生しておらず、非常に満足しています。
コスト削減という当初の最大の目的についても、非常に大きなインパクトがありました。従来の複雑な画像配信基盤をシンプルに再構築することができ、Cloudflareの導入は非常に良かったと感じています。
一方で、R2はS3と比較すると、現時点では細かい部分で実現が難しい機能もあります。また、JavaScriptやTypeScriptはインフラ専任の方にとっては苦手な場合もあるかもしれません。
弊社の場合は以前の画像配信の要件が少々複雑であったため、Workersの導入とカスタマイズが必須となりましたが、もしこのような要件が無く、シンプルな置き換えだけであればWorkers(JavaScriptやTypeScriptでの実装)も不要となり、非常にシンプルに導入できると思います。
要件に合致する場合、R2はコストパフォーマンスに優れ、開発体験も良好で非常に強力なツールだと思います。
株式会社ファンコミュニケーションズ / teckl
テックリード / バックエンドエンジニア / 従業員規模: 301名〜500名
SIerを経て2005年よりブログサービスを中心にしたWeb開発に携わる。バックエンド開発・レガシーなサービスのモダン化・クラウド移行・インフラ構築・保守・運用・コスト削減を中心に行っています。
よく見られているレビュー
株式会社ファンコミュニケーションズ / teckl
テックリード / バックエンドエンジニア / 従業員規模: 301名〜500名
SIerを経て2005年よりブログサービ...
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法