まとめ
この記事では、Amazon Lambda@edge と Amazon CloudFront を使用して、マルチリージョンの近隣アクセス アプリケーションを構築し、ユーザー エクスペリエンスを向上させる方法を紹介します。従来のマルチリージョン展開ソリューションとは異なり、このソリューションは Lambda@edge を使用して、オリジン リクエスト ステージでリクエストの特性を変更し、オリジン サイトのドメイン名を動的に変更して、近隣アクセスの目的を達成します。
シナリオ紹介
Web アプリケーションは西アメリカとシンガポールにデプロイされ、静的リソースは S3 を使用してデプロイされます。西アメリカとシンガポールのユーザーは、S3 を通じて写真/テキストなどの静的情報を読み取ります。S3 は現在シンガポールに導入されており、CF は静的リソースをキャッシュできますが、リソースの最初の読み込みやキャッシュの有効期限が切れると、西側のユーザーのアクセス時間が依然として長くなります。複数のリージョン ユーザーのアクセス エクスペリエンスを解決するソリューションを提供したいと考えています。
解決
S3 ストレージ バケットは、西アメリカとシンガポールの両方にデプロイできます。クライアントが CloudFront へのアクセスをリクエストしてからオリジン ソース サイトにアクセスするとき、Lambda@edge を使用して、オリジン リクエストの段階でリクエスト リクエストのドメインとホストを変更できます。機能は、近くのアクセスの目的を達成し、ユーザーエクスペリエンスを向上させるために、ソースサイトのドメイン名を動的に変更します。
建築計画
作業過程
事前作業
1. Lambda@edge に関連付けられたオリジナルリクエストを CloudFront の Behavior に設定し、リクエストがオリジナルリクエストを通過するときに Lambda@edge を通じて変更します。
2. 米国西部とシンガポールに S3 バケットを作成し、S3 をターゲットとして CloudFront にオリジンを作成します。
注(オプション) : S3 バケットに安全にアクセスする (パブリック アクセスを公開しない) ために、Cloudfront の OAC/OAI 認証方法を通じて S3 にアクセスできます。以下をサポートしているため、OAC (Origin Access Control) を使用することをお勧めします。
▪ Amazon Website Service リージョン内のすべての Amazon S3 バケット (2022 年 12 月以降に利用可能なオプトイン リージョンを含む)。
▪ Amazon S3 は、Amazon KMS (SSE-KMS) によるサーバー側の暗号化を使用します。
▪ Amazon S3 への動的リクエスト ( PUT および DELETE )。
OAC （オプション）の構成は以下のとおりです。
S3 ポリシーで OAC アクセスのみを構成する
{
"Version": "2012-10-17",
"Statement": {
"Sid": "AllowCloudFrontServicePrincipalReadOnly",
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::<S3 bucket name>/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::<AWS 账户 ID>:distribution/<CloudFront distribution ID>"
}
}
}
}左にスワイプするとさらに表示されます
CloudFront のオリジンで OAC を有効にする
[リクエストの署名] を選択すると、CloudFront は SigV4 を使用して、S3 に送信されるすべてのリクエストに署名します。これには、認証情報、日付、アクション、パラメーターなどが含まれます。これは認可ヘッドの形で S3 に送信され、情報を受け取った S3 はその情報を鍵で署名し、比較します。後処理リクエストを渡します。
最後に、オリジン グループを作成し、CloudFront の動作に関するオリジン設定をオリジン グループに変更します。
具体的なプロセス
1. クライアントは CloudFront にリクエストを送信します。
2. リクエストがキャッシュにミスすると、エッジロケーションで、CloudFront はオリジンリクエストで Lambda@edge を呼び出します。
3. Lambda@edge は現在のリージョンのコードを読み取り、us-west2 または ap-southeast-1 を識別し、コード内のプリセット マップを使用します。リージョンに対応する S3 アドレスを見つけます (注: Route53 の遅延戦略に基づいて最適な S3 バケットの場所を見つけることもできます。リファレンスにはこの方法へのリンクがあります)。
4. Lambda@edge はリクエストのドメイン名アドレスを変更し、リクエストは対応する S3 バケットにルーティングされます。
5. バケットから取得したオブジェクトをクライアントに返します。
Lambda@edge コードは次のとおりです。
import json
us_bucket = "amazon-cloudfront-secure-static-site-s3bucketroot-21aorhazvsj1.s3.amazonaws.com"
ap_bucket = "amazon-cloudfront-sin-s3root.s3.ap-southeast-1.amazonaws.com"
default_bucket = "amazon-cloudfront-secure-static-site-s3bucketroot-21aorhazvsj1.s3.amazonaws.com"
s3Mapping = {
"us-east-1": us_bucket,
"us-east-2": us_bucket,
"eu-central-1": us_bucket,
"eu-west-2": us_bucket,
"ap-southeast-1": ap_bucket
}
def lambda_handler(event, context):
request = event['Records'][0]['cf']['request']
defaultRequest = event['Records'][0]['cf']['request']
print(request['origin'])
print('req='+json.dumps(request))
try:
originKey = list(request['origin'].keys())[0]
if originKey != 's3'
return request
currentRegion = context.invoked_function_arn.split(':')[3]
print("aaa="+currentRegion)
domainName = s3Mapping.get(currentRegion, default_bucket)
request['origin']['s3']['domainName'] = domainName
request['headers']['host'] = [{'key': 'host', 'value': domainName}]
return request
except TypeError:
print('modify s3 domain failure')
return defaultRequest左にスワイプするとさらに表示されます
要約する
この記事では、Lambda@edge を使用してマルチリージョンの近隣アクセス アプリケーションを構築する方法について説明します。これにより、ソースに戻るレイテンシが削減され、パフォーマンスが向上します。CloudFront で複数のリージョンにオリジン サイトを設定し、Lambda@edge を使用してオリジン リクエストの段階でリクエストの特性を変更し、オリジン サイトのドメイン名を動的に変更することで、近隣アクセスの目的を達成できます。さらに、このスキームには次の利点もあります。
高可用性:オリジンサイトと CloudFront を複数のリージョンにデプロイすることで、特定のリージョンに問題が発生した場合でもアプリケーションに正常にアクセスできる高可用性を実現できます。
高パフォーマンス:静的リソースを複数のリージョンに分散し、最新のリソースをエッジ ノードにキャッシュし、次のリクエストでキャッシュから直接取得することで、ソースに戻る回数と遅延が削減され、パフォーマンスが向上します。
汎用性: S3 オリジン サイトの高速化に加えて、同様のソリューションを API ゲートウェイなどのサービスに適用して、リージョンを越えたアクセスを実現し、遅延を削減することもできます。
Lambda@edgeとCloudFrontを利用してマルチリージョン近傍アクセスアプリケーションを構築することで、ユーザーエクスペリエンスの向上、ソースへのバック遅延の削減、パフォーマンスの向上、高い可用性と汎用性を兼ね備えた、試す価値のあるソリューションです。
参考文献
OAC: Amazon CloudFront が Origin Access Control (OAC) を導入 | ネットワーキング
https://aws.amazon.com/cn/blogs/networking-and-content-delivery/amazon-cloudfront-introduces-origin-access-control-oac/
サインV4：
https://docs.aws.amazon.com/IAM/latest/UserGuide/signing-elements.html
Route53 の遅延ポリシーに基づいて API ゲートウェイを動的に変更します。
https://aws.amazon.com/cn/blogs/china/build-nft-offering-systems-with-cloud-native-components/
この記事の著者
ヤン・ジュン
Amazon クラウド テクノロジーのシニア ソリューション アーキテクト。Amazon Cloud Technologyに入社する前は、主にEコマースや小売関連のシステム開発に従事し、小売業界での豊富な経験とエンタープライズクラウドの実務経験を有しています。
夏寧
Amazon クラウド テクノロジー ソリューション アーキテクトは、かつて Hewlett-Packard Software および Acoustic Network に勤務しており、10 年以上のフロントエンドおよびバックエンドの開発経験があり、さまざまなソフトウェア プロジェクトの設計を主導してきました。モバイルインターネット、オーディオとビデオ、クラウドコンピューティング関連分野に精通しています。
聞いたので、下の 4 つのボタンをクリックしてください
バグに遭遇することはありません！
