CloudFrontで利用できるエッジ関数とは
Norio Iki
はじめに
こんにちは！
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 |
| ネットワークアクセス | いいえ | はい |
| ファイルシステムへのアクセス | いいえ | はい |
| リクエスト本文へのアクセス | いいえ | はい |
| 位置情報とデバイスデータへのアクセス | はい | ビューワーリクエスト ： いいえ ビューワーレスポンス： はい オリジンリクエスト ： はい オリジンレスポンス： はい |
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)で一緒に働いていただけるメンバーを募集してます！
関連記事 | Related Posts
We are hiring!
【プロダクト開発バックエンドエンジニア】共通サービス開発G／東京・大阪
共通サービス開発グループについてWebサービスやモバイルアプリの開発において、必要となる共通機能＝会員プラットフォームや決済プラットフォームの開発を手がけるグループです。KINTOの名前が付くサービスやTFS関連のサービスをひとつのアカウントで利用できるよう、様々な共通機能を構築することを目的としています。
【フロントエンドエンジニア（コンテンツ開発）】新車サブスク開発G／東京・大阪
新車サブスク開発グループについてTOYOTAのクルマのサブスクリプションサービスである『 KINTO ONE 』のWebサイトの開発、運用をしています。業務内容トヨタグループの金融、モビリティサービスの内製開発組織である同社にて、自社サービスである、TOYOTAのクルマのサブスクリプションサービス『KINTO ONE』のWebサイトの開発、運用を行っていただきます。