Amazon CloudFront 実践入門:概要、ディストリビューション作成、ログ出力設定まで
当エントリのテーマについてちょろっと作業する機会があったのと、ドキュメントに一部箇所のみ日本語化されているという状況でしたので作業がてら一連の内容をエントリとしてまとめてみました。CloudFrontの概要、ディストリビューションの作成、及びディストリビューションのログ設定が対象範囲となっています。作業記録・備忘録的なものですが何らかのご参考になれば幸いです。
イントロ
こちらについては以下のドキュメントが日本語訳されていますので割愛します。
CloudFrontのコンセプト
このセクションでは、CloudFrontの背後にある基本的な概念について説明します。
オブジェクト(Objects)
オブジェクトは、あなたがCloudFrontに届けて欲しいファイルです。オブジェクトは通常、Webページ、画像、及びメディアファイルが含まれていますが、HTTP経由又はAdobe RTMP(アドビシステムズ社のFlash Media Serverで使用されるプロトコル)のいずれかで提供する事が出来ます。
オリジンサーバー(Origin Server)
オリジンサーバーは、オリジナルとして定めたバージョンのファイルを保存する場所です。HTTP経由でコンテンツを提供している場合、オリジンサーバーは、Amazon S3のバケット又はHTTPサーバー、Webサーバーの何れかです。HTTPサーバーはAmazon EC2インスタンス上、またはあなたが管理しているサーバー上で実行する事が出来、これらのサーバーは、カスタムオリジンとして知られています。
RTMPを使用してメディアファイルを提供している場合、オリジンサーバーは常にAmazon S3のバケットです。
ディストリビューション(Distributions)
オリジンサーバーでオブジェクトを保存した後、オブジェクトがどこにあるかをCloudFrontに伝える役目を持つディストリビューションを作成します。ディストリビューションを作成すると、CloudFrontはあなたがオブジェクトを管理する為に使用する一意のドメイン名を提供します。例えば、d111111abcdef8.cloudfront.netのような情報です。
ここで、オリジナルの情報として/images/image.jpgという画像を含む、myawsbucketと呼ばれているバケットを持っていると仮定します。Amazon S3のバケットから直接画像を表示したい、Webページ上の画像を表示したいとなった場合、URLは以下の様になります。
http://myawsbucket.s3.amazonaws.com/images/image.jpg
もしCloudFrontから同様に参照したい場合は、以下のようになります。
http://d111111abcdef8.cloudfront.net/images/image.jpg
もし既にドメイン名(例: example.com)を持っている場合、CNAMEとしてドメイン名を10個まで指定する事が出来ます。もし別のドメイン名example.comを追加した場合、画像のリンクに以下のURLを使用する事が出来ます。
http://www.example.com/images/image.jpg
代替ドメイン名の詳細については、Using Alternate Domain Names (CNAMEs)をご参照ください。
作成可能なディストリビューションは以下の2タイプです。
- ダウンロードディストリビューション(download distribution):HTTPまたはHTTPSを使用してコンテンツを配信します。これを利用すると Amazon S3バケットとカスタムオリジンの組み合わせで最大10個まで、Webコンテントにアクセスする為のCloudFrontの設定が行えます。
- ストリーミングディストリビューション(streaming distribution):アドビシステムズ社のFlash Media Serverとリアルタイムメッセージングプロトコルを使用してデジタルメディアを提供しています。ストリーミング配信のための原点は、常に1つのAmazon S3バケットです。
エッジロケーション(Edge Locations)
エッジロケーションは、CloudFrontのキャッシュがあなたのオブジェクトをコピーする、地理的サイトです。エンドユーザーがオブジェクトに要求を行う際、CloudFrontはどのエッジロケーションが要求に応えるのに適している(近い)かを決定します。そのエッジロケーションは、オブジェクトが無い場合はオリジンサーバーからのコピーを取得し、エンドユーザーに要求を返し、そのエッジロケーションにキャッシュします。CloudFrontのエッジロケーションの位置については、以下をご参照ください。
有効期限切れ(Expiration)
デフォルトでは、オブジェクトはあるエッジロケーションで24時間経ったら期限切れとなります。オブジェクトの有効期限が切れた後、次にCloudForntはオブジェクトへの要求を受け取ると、その要求はアップロードされたバージョン(のオブジェクト)が利用可能かどうかを決定する為にオリジンに転送されます。オリジンサーバのオブジェクトを更新した場合、オリジンサーバーは更新されたバージョンを返します。CloudFrontはエンドユーザーにオブジェクトを返し、そのエッジロケーションにてキャッシュに変更されたバージョンを格納します。最小有効期限は0秒であり、これは最大有効期限の制限が無い状態です。有効期限切れの詳細については、 Specifying How Long Objects Stay in a CloudFront Edge Cache (Object Expiration)をご参照ください。
最終的な一貫性(Eventual Consistency)
ディストリビューションを作成、変更、または削除する時、CloudFrontデータベースにその変更を伝播させるのに時間が掛かります。配信に関する情報は最終的には一貫していますが、配信情報に関する即時要求を行っても、状況が変化していない可能性があります。通常数分以内に反映されますが、高システム負荷やネットワークの状況により、時間が伸びる場合もあります。
どのようにしてコンテンツを届けているのか
CloudFrontがどのようにコンテンツを提供しているか、についての概要は以下の通りです。Amazon S3のバケットから画像ファイルを配信するようにし、HTTPサーバからHTMLコンテンツを提供するダウンロード配信を使用していると仮定してみましょう。
CloudFrontエッジサーバの場所とIPアドレス範囲
バケット内部のオブジェクトはpublicにしておきましょう。こうする事で、CloudFrontのURLを知っている誰もがアクセス出来るようになります。オブジェクトをprivateな状態にしたい、またはアクセスするユーザの制御を行いたい場合はServing Private Content through CloudFrontをご参照ください。
コンテンツを配信するプロセス
- 世界中のエッジロケーションでCloudFrontが配布用にファイルを取得するオリジンサーバを設定。この例では:
- 画像ファイル用にS3バケットを作成し、ファイルを公に閲覧可能(Make Public)とする。
- HTMLコンテンツのHTTPサーバー設定を行う。
- オリジンサーバーにファイルをアップロード。
- CloudFrontのディストリビューションを作成。ディストリビューションでは、エンドユーザーがWebサイトやアプリケーションを介してファイルを要求した時、どのオリジンサーバからファイルを取得するかを指示します。ディストリビューションを作成したら、全ての要求をログに記録するかどうかや、ディストリビューション作成後即有効な状態としたいかどうかといった詳細について設定します。
- CloudFrontは、あなたがWebサイトやアプリケーションを開発するように、オブジェクトに使用するドメイン名を返します。例えば、もしCloudFrontがディストリビューションに対応するドメイン名としてd1234.cloudfront.netを返すなら、Amazon S3バケット(又はHTTPサーバーのルートディレクトリにある)image.jpgのURLはhttp://d1234.cloudfront.net/image.jpgとなるでしょう。また、自身の持つドメイン名を使用して、CloudFrontディストリビューションを構成する事が出来ます。その場合、URLはhttp://www.example.com/image.jpgのような内容となるかもしれません。
- CloudFrontは、そのエッジロケーション全てに対し、あなたのディストリビューションに関する情報を配信します。
- WebサイトやCloudFrontは、ステップ4で返されたドメイン名を使用するようにアプリケーションを開発したり、ディストリビューションを構成する方法に応じて、独自のドメイン名を使用します。必要に応じて、ファイルにヘッダを追加する為にオリジンサーバを構成する事が出来ます:ヘッダには、どの程度の期間、ファイルがCloudFrontのエッジロケーション内のキャッシュに残っていて欲しいかを指定します。デフォルトでは、各オブジェクトは24時間エッジロケーションに残っています。
- エンドユーザーは、Webサイトやアプリケーションを要求した画像ファイルやHTMLファイルにアクセスします。
- CloudFrontは、どのエッジロケーションがユーザーのリクエストに対してベストなレスポンスを返せるかを、レイテンシーの面で一般的に最も近いCloudFrontのエッジロケーションを決定します。この例では、その場所を『東京』としてみましょう。
- 東京のエッジロケーションで、CloudFrontはリクエストファイルに対するキャッシュをチェックします。ファイルがキャッシュにある場合、CloudFrontはエンドユーザーにそれらを返します。ファイルがキャッシュに無い場合は:
- a.CloudFrontはリクエストとディストリビューションの仕様を比較し、対応するファイルタイプに適用するオリジンサーバーへリクエストを転送します:画像ファイル用のS3バケットとHTMLファイル用のHTTPサーバへ。
- b.オリジンサーバーは、東京のCloudFrontエッジロケーションに戻ってファイルを送信します。
- c.オリジンサーバのファイルの最初のバイト情報が到達すると直ぐに、CloudFrontはエンドユーザーへのファイルの転送を開始します。CloudFrontは次回また東京で誰かがこのファイルをリクエストするような事があれば、ファイルをキャッシュに追加します。
- オブジェクトがエッジキャッシュの24時間内に存在、またはファイルヘッダーに指定がある期間中(Step6参照)、CloudFrontはエッジロケーションが最新バージョンであるかどうかを判断する為に、オブジェクトに対する次のリクエストをオリジンに転送します。最新である場合は、CloudFrontはそれらをエンドユーザーに配信します。そうでない場合、オリジンはCloudFrontの為に最新バージョンを配信し、エッジロケーションはキャッシュに最新バージョンを格納します。詳細については、Specifying How Long Objects Stay in a CloudFront Edge Cache (Object Expiration)をご参照ください。
CloudFrontエッジサーバーの場所とIPアドレス範囲
CloudFrontのエッジサーバの場所一覧については、The Amazon CloudFront Edge Networkをご参照ください。
CloudFrontnエッジサーバのIPアドレス範囲のリストについては、Amazon CloudFrontディスカッションフォーラムでのAmazon CloudFront Public IP Rangesをご参照ください。
CloudFrontに対する支払
CloudFrontは、あなたが任意の前払い料金を払う必要が無い、またはどれだけのコンテンツを持っているかという事にコミットしないように設計されています。以下の図とテーブルは、CloudFrontを利用する為の費用についてまとめたものです。
AWSからの毎月の請求書には、AWSサービスや機能で使用状況や利用料金額の情報を分離しています。その結果、情報として
- オブジェクトを格納しているAmazon S3に掛かる費用:(1) (オリジンサーバーとしてAmazon S3を使用している場合)
- バケットとエッジロケーション間のデータ転送費用:(2)
- CloudFrontからデータを提供するための費用:(3)
と分けて見ることが出来ます。
Amazon S3オリジンサーバでの保管 | バケットにオブジェクトを格納する為に、通常のAmazon S3ストレージ料金を支払います。 料金は、AWSステートメントのAmazon S3の部分に表示されます。 |
|
エッジロケーションにオブジェクトをコピー | Amazon S3のオリジンサーバーを使用する場合、通常のGETリクエストと転送の為の Amazon S3利用料金が発生します。エッジロケーションでそのオブジェクトに対する 需要がある場合のみ、CloudFrontのエッジロケーションにオブジェクトをコピーします。 データ転送料金はAWSステートメントのデータ転送部分(AWS Data Transfer portion)に 表示されます。 |
|
エッジロケーションからオブジェクトを提供 | リクエストと転送に対するCloudFrontの利用料金が発生します。 これは、対応するAmazon S3の料金よりも低くなっています。 CloudFrontの利用料金はAWSのCloudFrontの部分に表示されます。 詳細については、Amazon CloudFront Pricingをご参照ください。 |
注意:
HTTPSリクエストの場合は、別途追加料金が発生します。
詳細については、Amazon CloudFront Pricingをご参照ください。
CloudFront or Amazon S3?
CloudFrontとAmazon S3の両方がコンテンツを提供しています。コンテンツを提供する場合は全てCloudFrontを使うべきでしょうか。必ずしもそうではありません。それは特定のニーズに依存します。
Amazon S3はファイルのオリジナルであり決定的なバージョンを格納するように設計されています。これは、高い耐久性と費用対効果の高いアプリケーションストレージとデータ転送の為に最適化されます。
CloudFrontは、低レイテンシで最も人気のあるコンテンツを配信するように設計されています。耐久性のあるストレージの為に設計されてはいません。アクセス数の多いオブジェクトのコピーは、インターネット上のユーザーに近いエッジロケーションに格納されます。オブジェクトが頻繁にアクセスされていない場合には、エッジロケーションから削除される可能性があります。何回もアクセスを受けているオブジェクトの場合、CloudFrontで高速なダウンロードを提供しながら同時に配信のコストを下げる事が出来ます。
ファイルのそれぞれの要求の数が多いと予想される場合、CloudFrontはオブジェクトをユーザーの近いエッジロケーションから提供する為、単独でAmazon S3を使うよりも高いパフォーマンスを提供します。また、アクセス頻度の高いオブジェクトの配信でAmazon S3よりも費用対効果の高い選択肢を、CloudFrontに見つけるかも知れません。
クイックスタート(ダイジェスト)
これらの内容を受けて、実際にCloudFrontを利用してみましょう。詳細は下記ドキュメントで日本語展開されていますので、ここでは流れをざっと追う形で。
まず公開用にS3バケットを作成。
バケットにコンテンツをアップロード。今回はAWS iconを数点アップします。HTMLファイルもindex.htmlとして別途アップロード。
アップロードしたコンテンツをmake public。
アップロードした画像を表示するHTMLも用意しました。
<html> <head>AWS Database Services.(CloudFront Test)</head> <body> <p>AWS Database Services.</p> <ul> <li>DynamoDB</li> <li><img src="aws-db-dynamodb.png" /></li> <li>SimpleDB</li> <li><img src="aws-db-simpledb.png" /></li> <li>RDS</li> <li><img src="aws-db-rds.png" /></li> <li>ElastiCache</li> <li><img src="aws-db-elasticache.png" /></li> <li>Redshift</li> <li><img src="aws-db-redshift.png" /></li> </ul> </body> </html>
また、バケット自体のWebサイト設定を有効にします。
S3バケットに対してWebサイトとしてアクセス出来るか確認します。まずはindex.html。
次いで画像ファイル。
ここでCloudFrontに進む前に、CloudFrontログ出力の為のバケットを別途用意しておきたいと思います。設定に応じたパターンで計3つ用意しました。
CloudFrontの設定に進みます。メニューに進み、[Create Ditribution]押下。
Downloadを選択、次へ。
ディストリビューションを作成。以下のように3パターン、ログ出力の場所に関する内容をそれぞれ違えた形で計3つのディストリビューションを作成しました。以下は各バケット共通。
そして以下が3つのバケットでそれぞれ異なる内容。3つとも[Create Contribution]まで操作を進めてください。
ディストリビューション作成。deployedになるまで暫し掛かります。
deployedになりました。
ログファイルを出力させるために、作成した3つのディストリビューションに対して各々ブラウザアクセスを行います。ログが溜まれば良いので、今回はそれぞれに対してF5(command+R)でしばし攻撃しときましたw
しばし待ちます。今回試した限りでは、1時間半程?ログが出力されるのに掛かったようでした。1時間後は出来ておらず、2時間経って確認してみたら出来ていたので、ざっくりその辺りの範囲内かと。またこの辺は恐らく環境状況によっても違ってくるのでしょうね。
1つ目のディストリビューションログ。バケット配下に生成されています。
2つ目。こちらはディレクトリをイメージして設定しましたが、意図した通りになっています。
3つ目。こちらは2つ目のディレクトリ+ファイル名のプレフィックスを付けようと試してみましたがダメでした。フォルダとして認識?(管理コンソール上では)されているようです。
以上、CloufFrontのログ設定までのまとめでした。CloudFrontについては今後も適宜エントリを投下していければと思います。