Amazon Web Services ブログ
Amazon CloudFront & Lambda@Edge で画像をリサイズする
多くの画像に対してリサイズを行ったり、新しいデザインレイアウトにウォーターマークを付与したり、ブラウザのサポートのためにフォーマットの最適化を行ったことはありませんか?
画像毎に事前処理を行う必要なく、必要に応じてその場ですぐに画像を自動生成できないかとおもったことはありませんか? Lambda@Edge はそれらを可能にし、ユーザーの利便性を向上させ、帯域使用量を削減します。
Lambda@Edge の準備:
AWS Lambda はサーバーのプロビジョニングや管理の必要なしにコードを実行できます。
そして利用量に応じて支払いを行います 。 つまりコードが実行されていないときは無料です! Lambda は自動スケーリングするとともに耐障害性を兼ね備えています。 Lambda@Edge はビューワー (※訳注: クライアント) に近い複数の AWS ロケーションでコードを実行することで、 Lambda の利点をエッジに拡張します。
Amazon CloudFront ディストリビューションのキャッシュ動作毎に、次の CloudFront イベントの 1 つ以上が発生した時に Lambda 関数を実行させる最大 4 つのトリガーを追加できます:
- CloudFront ビューワーリクエスト – CloudFront がビューワーからリクエストを受け取った後、リクエストされたオブジェクトがエッジキャッシュにあるかどうかを確認する前に関数が実行されます。
- CloudFront オリジンリクエスト – CloudFront がリクエストをオリジンに転送する場合にのみ関数が実行されます。リクエストされたオブジェクトがエッジキャッシュにある場合は実行されません。
- CloudFront オリジンレスポンス – CloudFront がオリジンからのレスポンスを受け取った後、レスポンス内のオブジェクトをキャッシュする前に関数が実行されます。
- CloudFront ビューワーレスポンス – リクエストされたオブジェクトがビューワーに返される前に関数が実行されます。オブジェクトがすでにエッジキャッシュに存在するかどうかに関係なく関数が実行されます。
これらのトリガーの詳細については、 開発者ガイド をご確認ください。
基本的なユースケースを示すために、次の 4 つを例にして説明します。
- クエリパラメータでサイズを指定して画像をその場でリサイズする。
- ビューワーに応じて、最適化した画像フォーマットを提供する。例えば、 Chrome/Android ブラウザーには WebP 、その他のブラウザーには JPEG を提供する。
- 画像サイズのホワイトリストを定義して、生成および提供を許可する。
- 要求された画像サイズ/フォーマットが存在しない場合のみ、リサイズ操作を実行する。
ビューワーはムンバイ (※訳注: インド) にいて、オリジンが ‘us-east-1’ (AWS の バージニア北部リージョン) にあると仮定しましょう。 URL の構造は https://static.mydomain.com/images/image.jpg?d=100×100 で、オリジナルの高解像度画像は ‘/images’ 以下に存在し、クエリパラメータ ‘d’ は要求した画像サイズ (幅x高さ) を指定します。
リサイズした画像をその場で提供するために、 Labmda@Edge をどのように使用するかを見てみましょう。
下の図は、画像生成ワークフローのアーキテクチャです。ビューワーは Lambda@Edge ビューワーリクエスト関数とオリジンレスポンス関数が関連付けられた CloudFront ディストリビューションを介して画像をリクエストします。これらの関数は適切なオリジン URL (キャッシュキーとして利用される) を生成し、画像生成に適切なロジックを実行します。最後に、新しく生成された画像が提供され、次のリクエストのためにキャッシュされます。
このために、以下の2つのコンポーネントを利用します:
- CloudFront ディストリビューションに関連付けられた 2 つの Lambda@Edge トリガー、すなわちビューワーリクエストとオリジンレスポンス。
- オリジンとして使用する Amazon S3。
ステップ 1 から 5 で何が起こるのかを確認しましょう。
- ステップ 1: リクエストされた画像 URI は、 Lambda@Edge のビューワーリクエスト関数で操作され、適切なサイズとフォーマットになります。これは、リクエストがキャッシュにヒットする前に発生します。下記のコードスニペット 1 を参照してください。
- ステップ 2: CloudFront はオリジンから画像オブジェクトを読み取ります。
- ステップ 3: 必要な画像がすでに S3 バケットに存在する場合、またはステップ 5 で生成され保存されていた場合、 CloudFront はビューワーに画像オブジェクトを返します。この時、画像がキャッシュされます。
- ステップ 4: キャッシュされた画像オブジェクトがビューワーに返されます。
- ステップ 5: リサイズ操作はオリジンに画像が存在しない場合にのみ実行されます。 S3 バケット (オリジン) にネットワーク呼び出しが行われ、オリジナル画像を取得しリサイズを行います。生成された画像は CloudFront に送信する前に S3 バケットに永続化されます。
注: ステップ 2,3 および 5 はキャッシュのオブジェクトが古い場合、もしくは存在しない場合のみ実行されます。画像のような静的リソースは、キャッシュヒット率を改善するために、できるだけ長い Time to Live (TTL) を持つ必要があります。
Lambda@Edge 関数を深掘りする:
-
Viewer-Request 関数
コードスニペット 1 – リクエスト URI を操作する
コードスニペット 1 の説明:
上記のコードでは、ビューワーの ‘Accept’ ヘッダーに基いて異なる画像フォーマットを提供するために、入力された URI を操作します。また、入力されたサイズをホワイトリストと照合し、最も近い許容サイズに変換します。そのため、標準でないサイズ (例: 105wx100h) のリクエストが来た場合でも、ホワイトリストのサイズ (100wx100h) を提供するすることができます。この仕組みにより、どの画像サイズが生成されキャッシュされるかをより詳細に制御でき、キャッシュヒット率を更に改善しレイテンシを低減することができます。さらに、悪意のあるユーザーが多くの不要な画像サイズを生成することを防ぐことができます。最終的に変更された URI は、これらがすべて反映されています。
例えば、入力された URI パターンが ‘pathPrefix/image-name?d=widthxheight’ の場合、変換された URI パターンは ‘pathPrefix/widthxheight/<requiredFormat>/image-name’ となります。 <requiredFormat> はリクエストの ‘Accept’ ヘッダーに基いて webp か jpg になります。
-
Origin-Response 関数
コードスニペット 2 – 画像オブジェクトが存在するかを確認し、必要に応じて画像リサイズを実行する
コードスニペット 2 の説明:
この関数は CloudFront がオリジンからレスポンスを受け取った後、キャッシュに保存する前に実行されます。この関数では、以下のステップの順に実行されます。
- オリジンレスポンスのステータスコードをチェックして、 Amazon S3 バケットに画像オブジェクトが存在するかを確認します。
- 画像オブジェクトが存在する場合は、そのまま CloudFront のレスポンスサイクルを続行します。
- 画像オブジェクトが S3 バケットに存在しない場合は、オリジナル画像を取得してリサイズ操作を行いバッファに入力、リサイズ画像に正しいプレフィックスとメタデータを付与して S3 バケットに永続化します。
- 画像のリサイズが行われた場合は、メモリ内のリサイズ画像を元にバイナリレスポンスを生成し、適切なステータスコードとヘッダーを返します。
注: S3 バケットと Lambda 関数を実行する Edge ロケーションが異なるリージョンの場合、Amazon S3 から Lambda 関数へのリージョン間データ送信(アウト)料金が発生しますのでご注意ください。これらの費用は画像生成毎に1回発生します。
Amazon CloudFront ディストリビューション内でこれらのイベントトリガーを設定する方法については、こちらの ブログ を参照してください。
生成された画像は S3 バケットに保存され、以下のようにコンソールに表示されます。
コンテンツ管理システムから適切な URL を呼び出すことで、必要な画像フォーマットとサイズを事前に生成することも可能です。さらに、適切なウォーターマークを付与するようにコードを拡張することもできます。
設定ステップを一つずつ説明します:
Step 1: デプロイパッケージの作成
画像リサイズ関数は ‘libvips’ ネイティブ拡張を必要とする ‘Sharp’ モジュールを使用します。 Lambda 関数のコードは Lambda 実行環境で動作するように依存関係を含んだ状態でビルドおよびパッケージ化されている必要があります。これらを実現する方法のひとつが、あなたの環境に ‘docker’ をインストールしてから、 Docker コンテナを使ってパッケージをローカルにビルドすることです。
プロジェクトのディレクトリ構造は、以下を想定しています。
– <your-project>
— dist/
— lambda/viewer-request-function
— lambda/origin-response-function
— Dockerfile
コードスニペット (1 および 2) はそれぞれのディレクトリ内に配置します。 デプロイパッケージを作成する方法については、 デプロイパッケージの作成 (Node.js) を参照してください。
Dockerfile:
プロジェクトのルートディレクトリにて、次のコードを実行します:
- Dockerfile は Amazon Linux をダウンロードし、 Node.js 6.10 と依存関係をインストールするように設定されています。
また、 Amazon Linux AMI を使用して t2.micro インスタンスをセットアップし、依存関係をインストールすることもできます。
- 上記のコードスニペット 2 で使用している BUCKET 変数 の AWS アカウント ID を更新します。 AWS CloudFormation テンプレートは、 ‘image-resize-${AWS::AccountId}-us-east-1’ のパターンで S3 バケットを作成します。例えば、あなたの AWS アカウント ID が 123456789012 の場合、 BUCKET 変数は ‘image-resize-123456789012-us-east-1’ に更新します。既に同名の S3 バケットが存在する場合はこの変数を適切な値に変更し、 CloudFront ディストリビューションのオリジン設定を同じものにしてください。
- ‘sharp’ および ‘querystring’ モジュールの依存関係をインストールし、 ‘Origin-Response’ 関数をコンパイルします。
- ‘querystring’ モジュールの依存関係をインストールし、 ‘Viewer-Request’ 関数をコンパイルします。
- ‘Origin-Response’ 関数をパッケージングします。
- ‘Viewer-Request’ 関数をパッケージングします。
- AWS コンソールから、デプロイするファイルを格納する S3 バケットを us-east-1 リージョンに作成し、上記のステップで作成した zip ファイルをアップロードします。これらのファイルはデプロイ時に CloudFormation テンプレートから参照されます。
Step 2: Lambda@Edge 関数をデプロイする
AWS コンソールを us-east-1 リージョンに切り替えて、 下記の CloudFormation テンプレートを使用して Lambda@Edge 関数をデプロイします。テンプレート内の <code-bucket> をデプロイするファイルを格納した S3 バケット名に更新します。
CloudFormation テンプレート:
この CloudFormation テンプレートは以下を作成します:
- ビューワーリクエスト Lambda 関数
- オリジンレスポンス Lambda 関数
- 両方の関数に必要な実行ロールを作成し関連付け
- 命名規則 ‘image-resize-${AWS::AccountId}-${AWS::Region}’ を持つ S3 バケットを作成し、下記で説明するバケットポリシーを適用
このポリシーは以下を許可します:
- CloudFront がオブジェクトを取得する。
- Lambda 関数がオリジナル画像を読み取り、 S3 バケットにリサイズ画像を書き込む。
- CloudFront ディストリビューション
- S3 オリジンを持ち、特定のクエリパラメータを許可する。 ( このケースでは画像サイズを指定する ‘d’)
- デフォルト動作のオリジンレスポンスとビューワーリクエストのトリガーとして Lambda@Edge 関数 のバージョン番号を関連付けする。
ソリューションのテスト:
- 作成したオリジン S3 バケットに高解像度の画像ファイル (image.jpg とします) を ‘images’ ディレクトリにアップロードします。
- お気に入りのブラウザで以下の URL を開きます。
https://{cloudfront-domain}/images/image.jpg?d=100x100
URLの説明
- cloudfront-domain – 上記の CloudFormation テンプレートを使用して作成された CloudFront ディストリビューションのドメイン名 (※訳注: CloudFormation テンプレートから作成したスタックの出力: MyDistribution キーの値に ディストリビューション ID が表示されています。 CloudFront コンソールからディストリビューション ID を元にドメイン名を確認してください。)
- 100×100 – 画像サイズの幅と高さ、クエリパラメータの ‘d’ の値を 200×200 や 300×300 に変更することでサイズを変えられます。
指定したサイズにリサイズされた画像が表示されます。
トラブルシューティング:
トリガーを作成すると、 Lambda 関数がトリガーされるたびに Lambda は自動的に Amazon CloudWatch Logs にログを送信し始めます。 Node.js の console.log() 関数を使用してデバッグログを追加し、問題のトレースとトラブルシューティングを行うこともできます。 Lambda 関数のロギングの追加については、 Lambda 開発者ガイドの ログ作成 (Node.js) をご確認ください。
Lambda は関数が実行される場所に最も近い AWS リージョンに CloudWatch Logs のログストリームを作成します。各ログストリームの命名規則は ‘/aws/lambda/us-east-1.function-name’ です。 function-name は CloudFormation テンプレートをデプロイした時に作成された関数の論理名となります。
さらに、 CloudWatch メトリックスにて、関数の呼び出し, 所要時間, エラー, スロットリングの詳細に関連する全てのメトリックスを確認することができます。 CloudWatch Logs およびメトリックスの詳細については、 開発者ガイド をご確認ください。
まとめ:
その場ですぐに画像をリサイズするために、Lambda@Edge を使用する主な利点は以下の2つです:
- 画像を前処理する必要が無くなるため、ストレージ, 帯域, 計算コストを削減できます。これは、 A/B テストを行ったり、新しいデザインレイアウトにすばやく移行したい場合に便利です。
- ホスト型のサーバーからサーバーレスアーキテクチャに画像リサイズ処理をオフロードすることで、インフラストラクチャをよりシンプルにすることができます。
Amazon CloudFront や AWS Lambda@Edge を初めてお使いの場合は、サービスを開始する方法の詳細について Amazon CloudFront の開始方法 や AWS Lambda@Edge 開発者ガイド を参照することをおすすめします。
原文: Resizing Images with Amazon CloudFront & Lambda@Edge | AWS CDN Blog
(翻訳: SA 藤原)