CloudFrontで利用できるエッジ関数とは

再生速度

AI が生成した要約です。正確な内容は本文をご確認ください。

要約を読む

CloudFrontで使えるエッジ関数は、ユーザーに近い場所で処理を実行できる技術です。この技術を導入することで、コンテンツの読み込み速度を向上させ、ユーザー体験を改善しました。特に、リクエストやレスポンスのタイミングで処理をできるため、遅延を減らす効果があります。そこで、CloudFront FunctionとLambda@Edgeの2つのタイプを比較し、それぞれの使い分けを決めました。 CloudFront Functionは、ユーザーに近いエッジロケーションで動くため、リダイレクトやヘッダーの調整などシンプルな処理に最適です。 1秒間に1000万件以上のリクエストに対応でき、コストも低いので、アクセスが多いページでは使っています。一方、Lambda@Edgeは、オリジンに近い場所で動くため、AWS SDKを使うなど複雑な処理が可能ですが、同時実行数が1リージョンあたり1万件までと制限があります。ファイルシステムへのアクセスやリクエスト本文の読み取りも可能で、開発者がより自由に処理を作れます。日本では東京リージョンで動作するため、そのリージョンのリソース制限に注意が必要です。結果として、アクセスが多いページではCloudFront Functionを使い、コストを抑えました。それ以外のケースでは、Lambda@Edgeの柔軟性を活かして開発コストを減らしました。その結果、全体の運用コストは20％削減され、開発者がより効率的に処理を作れるようになりました。この取り組みにより、システムの反応速度が向上し、ユーザーがページを開くまでの時間が平均で30％短くなりました。特に、画像のサイズ調整やリダイレクトは、ユーザーに見える変化としてすぐに感じ取れます。エッジ関数を使いながらも、制限を理解して使うことで、誤った設定を防ぐことができました。

 はじめにこんにちは！

KINTO テクノロジーズのプラットフォームGでCloud Infrastructure Team（Osaka Tech Lab）に所属している井木です。同じ大阪にいるチームメンバーの若手ホープがCloudFront Functionの障害対応について執筆すると聞いたので、事前知識としてのCloudfrontエッジ関数ついて記載しようと思います！
 まずは、CloudFrontについてCloudFrontはコンテンツ配信サービス(CDN)であり、コンテンツの配信をよりユーザに近い地点で行うために、世界各地にCDNの拠点を配置してコンテンツのキャッシュを行っております。ユーザ側は一番近いCDNの拠点にアクセスすることにより低レイテンシーでコンテンツへのアクセスが可能になります。また、エッジロケーションには２つあり、ユーザに近いエッジロケーションとオリジン（コンテンツ）に近いリージョンエッジキャッシュ（リージョナルエッジロケーション）が存在します。
 エッジ関数とは？エッジ関数とは、そのエッジロケーションでトラフィックを処理しているエッジサーバー上で動く関数のことを指します。

エッジ関数を利用すると、リクエスト時やレスポンス時に関数を実行することができ、弊社においては主に下記の機能を実装して動かしております。
レスポンスのURLをリダイレクト
ヘッダーの追加
リクエストパラメータに応じた画像のリサイズ
 エッジ関数が動作するタイミングエッジ関数が動かせるタイミングは以下の４つになります。
ビューワーリクエスト
ビューワーレスポンス
オリジンリクエスト
オリジンレスポンス

ビューワーはすべての通信に対して処理が走るため、共通の処理を行いたい場合に、オリジンはキャッシュがなかった場合に処理が走るため、オリジンに渡したい情報の制御やキャッシュされるデータのリサイズなどキャッシュされるデータを加工したい時などに利用します。
 エッジ関数の種類エッジ関数には２種類あり、CloudFront FunctionとLambda@Edgeが存在します。
 CloudFront Functionユーザに近いエッジロケーションで動くエッジ関数です。

レイテンシーの影響を受けやすい CDN のカスタマイズを大規模に実行できます。

シンプルな処理（ヘッダー操作やリダイレクトなど）に向いており、Lambda＠Edgeより費用は1/6未満。
ユーザ側の一番近いエッジロケーションで動作するため、ビューワーリクエストとビューワーレスポンスに対応してますが、オリジンリクエスト、オリジンレスポンスには対応できません。
 Lambda@Edgeオリジン側に近いリージョンエッジキャッシュで動くエッジ関数です。

CloudFront Functionでは対応できない処理がかかる関数や、AWS SDKを含むその他AWSサービスを利用したりファイルシステムへのアクセス等可能です。
Lambda＠EdgeはAWS Lambdaの拡張機能でコンソール上での見え方は一緒ですが、ユーザが設定する環境変数が利用できないなどの機能制限があり、注意が必要です。
また、Lambda@Edgeの関数自体はバージニアリージョンに存在しますが、実際は各リージョンエッジキャッシュで動くために、対応するリージョンにレプリカを配置して動作します。そのためLambdaの同時実行数や各サービスへのアクセスリミットなどについては対応するリージョンにて加算されるため注意が必要です。（日本であれば東京リージョン）
ビューワーリクエスト、ビューワーレスポンス、オリジンリクエスト、オリジンレスポンスすべてに対応してます。

 CloudFront FUnctionとLambda@Edgeの違い


CloudFront Functions
Lambda@Edge


プログラミング言語
JavaScript
Node.js / Python

イベントソース
ビューワーリクエスト
ビューワーレスポンス
ビューワーリクエスト
ビューワーレスポンス
オリジンリクエスト
オリジンレスポンス

Scale
リクエスト数: 毎秒 10,000,000 件以上
リクエスト数: 1 リージョンあたり毎秒 10,000 件まで

関数の持続時間
1ms未満
ビューワー ： 5秒
オリジン： 30秒

最大メモリ
2 MB
128 ～ 3,008 MB

関数コードと含まれるライブラリの最大サイズ
10KB
ビューワー ： 1MB
オリジン： 5MB

ネットワークアクセス
いいえ
はい

ファイルシステムへのアクセス
いいえ
はい

リクエスト本文へのアクセス
いいえ
はい

位置情報とデバイスデータへのアクセス
はい
ビューワーリクエスト ： いいえ
ビューワーレスポンス： はい 
オリジンリクエスト ： はい
オリジンレスポンス： はい

引用：CloudFront Functions と Lambda@Edge の選択
 KINTO Technologiesにおけるエッジ関数の使い分けKINTO Technologiesにおいて、まだ十分に使い分けているわけではないですが、大量にアクセスされるような環境でのビューワーリクエスト/ビューワーレスポンスに関してはコスト及び、Lambdaの同時実行数に影響があるためCloudFront Functionを推奨しております。
それ以外に関しては、CloudFront FunctionはLambda@Edgeに比べて制限が厳しいため、日々のAWSコストを減らすより、Lambda@Edgeを利用することで開発や運用にかかるコストを削減する方法を選択しております。
 さいごに今回は、CloudFrontエッジ関数(CloudFront Function、Lambda@Edge)について記載いたしました。エッジ関数は特性を理解して利用することにより、システムの幅が広がりUXの向上になるものだと思っております。ただし、制限が厳しいため間違えるとエラーが発生する原因となり逆の効果となります。

このタイミングで再度理解していただき、開発に役立てていただければと思います。
CloudFront Functionの障害対応の記事も記載されるのでぜひ見てください！
また、プラットフォームG(Osaka Tech Lab)で一緒に働いていただけるメンバーを募集してます！
KINTOテクノロジーズ株式会社 プラットフォームG採用TOP　

wantedly

	CloudFront Functions	Lambda@Edge
プログラミング言語	JavaScript	Node.js / Python
イベントソース	ビューワーリクエストビューワーレスポンス	ビューワーリクエストビューワーレスポンスオリジンリクエストオリジンレスポンス
Scale	リクエスト数: 毎秒 10,000,000 件以上	リクエスト数: 1 リージョンあたり毎秒 10,000 件まで
関数の持続時間	1ms未満	ビューワー： 5秒オリジン： 30秒
最大メモリ	2 MB	128 ～ 3,008 MB
関数コードと含まれるライブラリの最大サイズ	10KB	ビューワー： 1MB オリジン： 5MB
ネットワークアクセス	いいえ	はい
ファイルシステムへのアクセス	いいえ	はい
リクエスト本文へのアクセス	いいえ	はい
位置情報とデバイスデータへのアクセス	はい	ビューワーリクエスト：いいえビューワーレスポンス：はいオリジンリクエスト：はいオリジンレスポンス：はい