はじめに

こんにちは！
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