動的な画像操作、ストレージ、およびコンテンツ配信についてよく読んでいます。私が勤務している会社では、すでにサービスの一部に AWS を使用しています。
私が取り組んでいるアプリケーションは、ドキュメント画像を S3 バケット (これに限定されません) に保存しており、オンデマンドで表示する必要があります。
このアプリケーションの最初のバージョンでは、画像をローカルに保存し、同じサーバー上でオンデマンドで画像操作を実行しました。
現在、ドキュメントのストレージが増加し、多くの画像が保存されています。これはすべて Web アプリケーションを介して行われます。これは、1 人のユーザーが 100 枚以上の画像をアップロードする可能性があることを意味し、サーバーはそれらをできるだけ速く処理する必要があります。
そのため、画像は EC2 インスタンスにアップロードされ、内部で S3 バケットにストリーミングされます。これが、最初に元の画像を保存する方法であり、アップロード プロセスを高速化するためのサムネイルはここにはありません。
次に、別のユーザーがこの画像をプレビューしたり、元のサイズで表示したりする場合があります。これが動的にサイズを変更する必要がある理由です。サイズ変更後に画像キャッシュ用に Cloudfront を実装します。ここで問題が発生します。
ワークフローは次のようになります。
1. User Request CDN image
2.a Cloudfront Serves the cached image
2.b Cloudfront request the image to a custom origin if its not cached
3. The origin server query S3 for the image
4.a If the image size exists on S3
5. Return the image to Cloudfront, Cache and return to user
4.b If the image size does not exists on S3
5. Generate a image size from the original S3 image
6. Save the new size to S3
7. Return the new size to Cloudfront, Cache and return to user
カスタムオリジンは不足している画像サイズを作成して S3 に保存します。Cloudfront はキャッシュされた画像を使用するか、この新しい画像サイズを現在存在する S3 にリクエストできます。
すでに多くのドキュメントを読んでいるので、これは可能だと思いますが、以前にこれを作成した人のドキュメントはまだ見つかりません。
これは画像操作を処理する良い方法のように見えますか?これを行う方法に関するドキュメントを見た人はいますか?
私は PHP 開発者ですが、画像サーバーでのパフォーマンスを優先して、PHP 以外のソリューションを実装できるかもしれません。