画像配信基盤の内製化によるコスト削減について

こんにちは、Graciaのプロダクト部・エンジニアの今井です。

TANP(タンプ)では、ギフトECという性質上、商品やラッピングなどの画像を効果的に使用し、お客様に、より商品の魅力が伝わるようサービスの改善を日々進めております。その画像配信にコスト上の課題を抱え、CloudinaryからCloudFrontとLambda@Edgeを使用した方法に切り替えを行なったことについて書きたいと思います。

Cloudinaryの利用背景と移行への決断

TANP(タンプ)では、リクエストベースで画像をサイズ変換できる機能や管理画面の使いやすさ、導入の手軽さから、これまでCloudinaryを使用して画像配信を行なってきました。しかし、サービスの成長に伴い、利用料金が高額になっていくことが課題となっていました。Cloudinaryはクレジットと呼ばれる定額使用分を消費すると従量課金が発生し、特に繁忙期になると画像の配信量が増え、コストが爆発していました。

TANP(タンプ)を運用する中で、実際に必要としていた機能は画像のサイズ変換がほとんどであり、その他の機能はあまり使われていませんでした。また、CloudFrontとLambda@Edgeを利用したリクエストベースでの画像変換を行う方法に十分なメリットがあるという結論に至ったことから移行を決断しました。

具体的には

CDNの機能をCloudFrontに集約できる
- すでに別の用途でCloudFrontを利用しており、CDNの機能をCloudFrontに集約することでスケールメリットを発揮できる
- これによりAWSが提供しているCloudFront Security Savings Bundle(以下、CFSSB)やCloudFront Reserved Capacity(以下、CFRC)といったプランを有効に利用することができ、高い割引を受けることができるようになります。
AWS S3からの転送料金を抑えられる
- 商品画像のストレージとしてS3を利用しており、CloudFrontへのアウトバウンド通信に料金がかからないことや、Lambda関数の実行リージョンとS3バケットのリージョンが同一の場合はデータ転送が無料であることも後押しとなりました。
実装や導入のコストがあまりかからない
- 一般的な手法がAWSの公式で公開されており、実装のコストも高くなく、不確実性が抑えられていることもメリットとなりました。

移行に向けて

「相談と計画」~「実装」~「環境構築と切り替え」の流れで移行を進めました。

相談と計画

AWSの担当者にご相談しながら、移行を行いました。運用が本格化するまで、切り替えのアプローチやコスト試算、CloudFrontのプラン選択までサポートいただきました。

CloudFrontのプランについては、最終的にCFSSBの利用を開始することになりました。この決定に至った主な理由は以下のとおりです。

現在の配信規模だとCFRCとディスカウント率がそこまで変わらない
- 今後の配信量の変動によってはCFRCを再検討したいと思います。
購入月の1日まで遡って適用される
- 検証や段階的な切り替えで、CloudFrontの料金がすでに上がり始めていましたが、すでに課金が発生している部分についても、購入月の初日まで遡ってクレジットが適応されるメリットがあります。
WAFのクレジットも付帯する
- CFSSBの利用を開始すると契約金額の最大10%のクレジットが付与されます。すでにWAFを利用しており、一定のコストがかかっていたのでこれも決定の後押しとなりました。

実装

基本的な実装はAWSの公式ブログをもとに行いました。

aws.amazon.com

Lambda@EdgeはNode.jsかPythonのみの対応なので注意が必要です。

Node.jsとPythonそれぞれでプロトタイプを作成し、処理速度の計測を行いつつ、より起動時間を減らすことのできたNode.jsを最終的に選択しました。

基本的な実装は先ほどのブログに沿いながらも、以下の点を意識しながら実装を行いました。

アプリケーションの要件に合わせて、CloudFrontのキャッシュがより効きやすいように処理を調整する
コールドスタートにかかる時間を減らすために、Lambda関数のサイズを減らす

Lambda@Edgeには他にもいくつか注意点もあるのでこちらの記事が参考になりました。

aws.amazon.com

環境構築と切り替え

Lambdaの同時起動数など制限があるため、パフォーマンスのモニタリングを行いつつ段階的な切り替えを行いました。

具体的には「additional metrics」を有効にし、キャッシュヒット率とLambda@Edgeのエラー率を指標として切り替えを進めました。

途中、Lambda@Edgeのログ量が多く、CloudWatchのDataProcessing-Bytesへの課金が上昇傾向にありました。ログの出力を抑えつつ、保持期間も適正に見直しながらコストの調整を行いました。

またログについては、CloudWatch Logsのsubscription filtersを設定し、Datadogに転送することで監視に役立てています。

内製化したことの利点と成果

この画像配信基盤の切り替えにより、以下の利点や改善を行うことができました。

コスト削減
- 繁忙期においては月額で$1,000以上のコスト削減を達成することができました。
- CFSSBの月あたりのコミット量を正確に計算することで、より多くのコストメリットを得ることができます。クレジットを使い切れない月があっても年間を通してお得になるコミット量を計算していくのがポイントとなりました。
セキュリティ向上
- CloudFrontに乗り換えたことで、不正なアクセスが発生した場合も、WAFを使用したアクセスコントロールがしやすくなりました。また、CFSSBを申し込むとWAFのクレジットも付与されるのでおすすめです。
独自ドメイン
- これはついでに達成できたことではありますが、今後もサービスの成長に伴い、配信方法や使用技術を変更することも考えられます。すでにメールなどで送信した画像の表示を保ちつつ、今後はよりスムーズな移行ができるようになるかと思います。