aws-recipe-user 大柳です。
CloudFrontの機能改善が先日発表されたので検証してみます。
CloudFrontとは
CloudFrontはAWSの提供するCDN(Content Delivery Network)のサービスです。
コンテンツのキャッシュは世界各地にあるエッジロケーションに保存されます。ユーザは一番近くのエッジロケーションにあるコンテンツにアクセスすることで、応答時間を短くしたり、配信元サーバの負荷や転送量を削減することができます。
3/30に発表されたFast Invalidations
CloudFront上のキャッシュはデフォルトでは24時間で期限切れとなり、オリジナルコンテンツを再度取得しに行きます。
データの更新が頻繁にある場合には、CloudFrontのInvalidation機能を使用することで、オブジェクトが期限切れになる前にCloudFrontキャッシュからオブジェクトを削除できます。
これまではキャッシュ削除には数分かかりましたが、3月30日にグローバル全体のエッジロケーションで１分以内にキャッシュ削除が可能になったと発表されました。
AWS Developer Forums: Announcing Fast Invalidations
https://forums.aws.amazon.com/ann.jspa?annID=4521
記事を要約すると
・5秒でエッジサーバの90％でオブジェクトの無効化が完了
・1分以内にすべてのエッジサーバーでオブジェクトの無効化が完了
・追加料金なしで利用可能
ということで、ユーザは追加コストを気にすることなく、この機能改善を利用可能です。
今回記事ではオブジェクトの無効化がどのくらいの時間で反映されるか実際に検証してみました。
結論としては、世界各地のエッジロケーションに1秒から6秒でキャッシュが反映されることが確認できました。
では、検証方法と詳細な検証結果について説明していきます。
検証方法
このような検証環境を構築しました。
オリジナルのコンテンツは東京リージョンのEC2上にWebサーバを構築してアクセスできるようにしました。
このWebサーバに対してCloudFrontでコンテンツをキャッシュするようにしています。
また世界各地のエッジロケーションへのアクセスを検証するために、海外リージョンにEC2を構築しました。
世界各地にばらけるように北米、南米、ヨーロッパ、東南アジア、オセアニアの以下のリージョンを選びました。
・米国東部 (バージニア北部)
・米国西部 (北カリフォルニア)
・EU (アイルランド)
・アジアパシフィック (シンガポール)
・アジアパシフィック (シドニー)
・南米 (サンパウロ)
これらの海外リージョンのEC2から、東京リージョンのWebサーバのコンテンツ及びエッジロケーションに対して1秒おきにアクセスして、時刻とコンテンツ内容を出力させます。
コマンドはdateとcurlを組み合わせた以下のようなものです。
|
1 2 3 |
while sleep 1; do echo -n `date -u +"%Y/%m/%d %H:%M:%S,"` && \ echo -n `curl -s http://xxx.xxx.xxx.xxx/hello.html` && echo -n "," && \ echo `curl -s http://xxxxxxxxxxxxx.cloudfront.net/hello.html` ; done; |
このコマンドを世界各国のリージョンに立てたEC2から実行しながら、オリジナルコンテンツを更新し、オブジェクトの無効化を行います。
そして各リージョンで出力されるメッセージからWebサーバに直接アクセスした場合とCloudFrontにアクセスした場合のコンテンツ反映の時間差を確認することで検証を行います。
オブジェクトの無効化
CloudFrontのマネジメントコンソールかCLIコマンドで無効化できます。
マネジメントコンソールからは適用したいDistributionを選択して、[Create Invalidation]をクリックすると実行できます。
今回はCLIコマンドで無効化を行います。
–distribution-idにディストリビューションIDを、–pathsに無効化するパスを指定します。
また、create-invalidationはプレビューバージョンのため事前にオプションの追加も必要です。
|
1 2 3 |
#create-invalidationはプレビューバージョンのため事前にオプションを追加 aws configure set preview.cloudfront true aws cloudfront create-invalidation --distribution-id <ディストリビューションID> --paths /hello.html |
コンテンツの入れ替えとCreate Invalidationを同時に実行するために、以下のようにコマンド化しました。
|
1 2 3 4 5 6 7 8 9 |
#コンテンツをbye.html(中身はBye!）に更新 echo `date -u +"%Y/%m/%d %H:%M:%S"` && \ sudo cp bye.html hello.html && \ aws cloudfront create-invalidation --distribution-id <ディストリビューションID> --paths /hello.html #コンテンツをhello_origin.html(中身はHello!）に更新 echo `date -u +"%Y/%m/%d %H:%M:%S"` && \ sudo cp hello_origin.html hello.html && \ aws cloudfront create-invalidation --distribution-id <ディストリビューションID> --paths /hello.html |
このコマンドを使ってHello!→Bye!→Hello!→Bye!→Hello!と５回コンテンツの更新を行いながら、各地のリージョンでコンテンツの内容がどう変わるかを見ていきます。
検証結果
各リージョンごとのWebサーバに直接アクセスした場合とCloudFrontにアクセスした場合のコンテンツ反映の時間差、その最小/最大/平均値をまとめたのが以下の表になります。参考に各海外リージョンから東京リージョンのWebサーバに直接アクセスした場合のping応答時間も載せておきます。
各リージョンともCloudFront経由でも最低2秒以内に反映、遅くとも6秒後には反映がされています。AWS仕様通りの性能が出ていることが確認できました。
まとめ
キャッシュ利用のタイムアウト値はHTTPヘッダやブラウザ設定にも左右されるため注意が必要ですが、CloudFront単体ではほぼリアルタイムにコンテンツがリフレッシュされることが確認できました。
コマンドを打ったその瞬間に世界中の73ヶ所のエッジロケーションの状態が同期されて、新しいコンテンツを返す動きをしてくれるということでAWSの技術力、サービスレベルの高さ再認識した検証結果でした。
今回はごく小さい１つのオブジェクトだけをリフレッシュ対象にしましたが、キャッシュするオブジェクトの件数やファイルサイズによっては結果が変わる可能性もあるので後日検証したいと思います。
2017/4/6追記
エッジロケーションの数は2017/4/6現在50ではなく73か所とのこと、指摘を受けたので修正しました。
@kuwa_twさん、ありがとうございます。
https://twitter.com/kuwa_tw/status/849939873305841664
