はじめまして。株式会社CAMに出向し、バックエンド開発を担当しているムウ・コジマです。普段はCore Unitに所属し、サービス開発基盤の開発・改善を行っています。
はじめに
みなさんのプロジェクトでは、どのような画像配信の仕組みを構築していますか？ 自前で構築する場合もあれば、SaaSを導入する場合もあり、ビジネス要件に応じて適切な手法を選択されているかと思います。本記事では、CAM内で採用している画像配信基盤の仕組みを紹介します。今回は題材として、社内で開発・運用している「新R25 Media」を取り上げ、説明していきます。
画像配信基盤
概要
結論として、Dynamic Image Transformation for Amazon CloudFront（旧 Serverless Image Handler） を利用して画像配信基盤を構築しています。ただし、この名称のAWSコンポーネントが単体で存在するわけではありません。これは、AWS Lambda上で画像を加工するためのコードと、その実行に必要な複数のAWSコンポーネントを組み合わせた、以下のようなソリューション全体を指します。
※ v7系のテンプレートには 2 種類のアーキテクチャパターンが用意されていますが、本記事では筆者がリプレイスを行ったS3 Object Lambda パターン について説明します。こちらの方が新しいアーキテクチャです。なお、従来のデフォルトのアーキテクチャでは、最大6MBまでのサイズしか扱えません。これはLambdaの同時実行時のペイロード制限 (6MB) によるものです。
※ ⑤AWS Secrets Managerや⑥ Amazon Rekognition はオプションです。
新R25 Media に限らず、CAM の複数のサービスがこの画像配信基盤を利用しています。
配信の流れ
新R25 Mediaにおけるリクエストの流れを説明します。
- サービスからサムネイル画像などのリクエストを送信
CloudFrontでリクエストを受け付ける（※ DNSの詳細は省略）CloudFront Functionでリクエストの正規化を行なう（※ クエリの正規化や許可されていないパラメーターの削除等）CloudFrontにリクエスト画像のキャッシュがあれば、この時点でレスポンスを返却し、キャッシュがなければS3へリクエストをフォワードS3へのGETリクエストのイベントフックでLambda (S3 Object Lambda)がトリガーされるNode.js製の画像加工ライブラリsharpがリサイズや圧縮などの処理を行う- ログ用の
S3バケットにログが記録される（※ 配布テンプレートにより、自動でバケットが作成される） CloudFront Functionで、S3から返されるメタ情報を適切なレスポンスヘ ッダーに変換- 変換後のデータを
CloudFrontでキャッシュし、クライアントへレスポンスを返却
主に使用している機能
※ 旧 Serverless Image Handler v4 系から利用しており、当時からのURL ベースの thumbor インターフェイスを引き続き使用しています。
リサイズ
通常の例:
https://xxxxxxxxxx/xxx.jpg
リサイズの例:
https://xxxxxxxxxx/100x100/xxx.jpg
圧縮
指定フォーマットの例:
https://xxxxxxxxxx/filters:format(webp)/xxx.jpg
| JPG | WebP | AVAF |
|---|---|---|
| 21KB | 12.3KB | 10.1KB |
画像取得時にパラメータを明示的に指定しなくても、AUTO_WEBP 設定を有効にすることで、Accept ヘッダーに指定された MIME タイプが含まれていれば、Lambda が自動で圧縮し、返却する機能を活用しています。
品質
画像のクオリティを調整できます。以下の例では、オリジナル画像の 80% の品質で取得しています。
クオリティ調整の例:
https://xxxxxxxxxx/filters:quality(80)/xxx.jpg
特徴
筆者の視点からDynamic Image Transformation for Amazon CloudFront のメリット・デメリットを整理します。
メリット
- 管理コスト削減：
AWS Lambdaを利用して画像を加工するため、管理コストを抑えることができます。- インフラ運用不要： サーバーレス環境のため、インフラ運用が不要。※ ただし、Node.js のランタイムのバージョンアップなど、最低限の運用は発生します。
- コスト最適化： リクエストベースの課金モデルのため、処理が発生しない時間帯は利用料金がかかりません。
- 高可用性： AWSのSLAや、
Lambdaの同時実行数などの各種制限の範囲内で高可用性が確保されています。 - 簡単な導入&柔軟なカスタマイズ：
- 導入の容易さ： AWS ソリューションとして提供されているため、自前でゼロから構築するよりも容易に導入可能です。また、AWS をインフラとしてすでに利用している場合、新たに画像配信のSaaS ソリューションを契約する必要がない点もメリットとなります。
- カスタマイズ性の高さ：
CloudFormationテンプレートを変更することで、ビジネス要件に応じた調整ができます。※ 場合によってはLambdaの実行コードを修正して独自仕様を実装する事も可能です。
デメリット
- 学習コスト: 画像最適化用のSaaSと比較すると、AWS に慣れている場合は短期間で習得できますが、完全初心者にとっては学習コストがやや高くなります。
Lambda、CloudFront、S3などの基本的な AWS サービスの知識に加え、画像加工ライブラリsharp.jsの理解も多少必要になります。 - オーバーカスタマイズによる保守性の低下: ビジネス要件に応じて
Lambdaの実行コードを修正しカスタマイズした場合（例: ウォーターマークの追加）、Dynamic Image Transformation for Amazon CloudFront のバージョンアップに追従しづらくなる可能性があります。
コスト試算
最後にコストについて説明します。公式の 実装ガイド に記載されている概算は、以下のとおりです（2025年3月現在）。
※ 選択するアーキテクチャやオプションによっては、一部のコストが不要になるため、概算として参考にしてください。例えば、Signed URL を使用しない場合、Secrets Manager のコストは発生しません。
※ バージニア北部リージョン
| AWSサービス | 100,000新規画像(CloudFrontでのキャッシュなし) | 1,000,000新規画像(CloudFrontでのキャッシュなし) | 1,000,000キャッシュ画像(CloudFrontでのキャッシュあり) |
|---|---|---|---|
| Amazon S3 Object Lambda(データ取得) | $0.03 | $0.25 | $0 |
| AWS Lambda（画像変換） | $0.60 | $6.03 | $0 |
| Amazon CloudFront（配信） | $0.42 | $4.25 | $4.25 |
| AWS Secrets Manager(署名付きURL) | $0.90 | $5.40 | $0.40 |
| Amazon CloudWatch Dashboard(モニタリング) | $3.00 | $3.00 | $3.00 |
| Amazon CloudWatch Logs(ログ) | $0.03 | $0.33 | $0.00 |
| 月額合計 | $4.98 | $19.26 | $7.65 |
まとめ
簡単にではありますが、CAM で採用した画像配信の仕組みについて解説しました。画像配信基盤の構築には様々な選択肢があるため、要件に応じて適切な方法を選択するのが重要だと考えています。Dynamic Image Transformation for Amazon CloudFront は、メジャーアップデートによりアーキテクチャや内部の画像加工ライブラリが変更される可能性があるため、今後もこれに対応しながら運用を続けていく予定です。