CloudFrontのオリジンフェッチは10秒以内のレスポンスを期待している

まずはCloudFrontのFAQページを見てほしい。ここではそれ以外のことを。

最近立て続けに複数のルートで聞かれたCloudFrontのオリジンフェッチ（オリジンサーバーからエッジロケーションへのデータ転送）の細かな点を折角なので書いておくことにする。

ミスした場合は3回リトライする。詳細は、AWS Developer Forums: Cloudfront timeout pulling contents? ...を読んでほしいが、まとめるとこんな具合。

• CloudFrontはオリジンサーバへのリクエストが無反応のときのために3回繰り返す。
• 二度目，三度目のオリジンフェッチのときはIPアドレスも引き直す。サーバがDNSラウンドロビンを使っているような場合に一台死んでてもこれでカバーする。
• オリジンサーバが何も返さないならば、CloudFrontも何も返さない。逆ににいえば、503などをオリジンサーバが返すならば、それはキャッシュされる。

レイテンシベースで誘導される。CloudFrontには世界で現在40箇所にエッジロケーションが存在する。日本では東京二箇所、大阪一箇所。場合によっては韓国ソウルやUSのエッジロケーションのほうが近いユーザもいるだろう。

キャッシュはエッジロケーション毎に共有される。エッジロケーションが違えばキャッシュは共有されない。厳密なことを言えば、エッジロケーション内で一定時間内にキャッシュが掘り起こせないときはオリジンフェッチを行う。一旦エッジロケーションにキャッシュされればほぼ待たされることなく共有される。

質問は随時。

cdn.debian.net と ftp.jp.debian.org の動作に問題があればgithubにおねがい します。

Debianにおけるパッケージ流通はaptが基本的なものになっている。いまどき完全なスタンドアローンで動作しているような例もすくないので、なにかしらaptの御世話になっていることは多いかと思う。

昔のaptの実装ではhttp redirectができないので、http redirectに頼らない誘導方法になっている（現在のaptの実装ではhttp redirectができるので、http.debian.netというサービスが誕生している）。

check_serverの実装自体はRails3.2です。

動作チェック、文句、要望について

• チェックサーバの動作は http://cdncheck1.araki.net/view/index で確認できます。
• https://github.com/armaniacs/CnameQRV4 で内容を見ることができるので、Issue管理もそちらでお願いします。
• サーバ追加してくれといった要望もそちらでおねがいします。

以下、内部の説明。

DNSサーバは dns.s.araki.net という名前で、dns_balanceが動作しています。

• どのDNSを使うかはレイテンシベースのルーティングで３リージョンから選択している。
• DNSであるdns_balanceは定期的にcheck_serverに対して最新のサーバ生死情報をELBのURL ( http://cdncheck1.araki.net/status/alive )に対してとりにいく。

• 入手はJSONが使われる。この取得のためのプログラムは gae-surrogate.rbという名前

チェックサーバは、

• チェック対象である世界中のDebianミラー200台をSQSに順次登録する。
• チェックサーバの動作は http://cdncheck1.araki.net/view/index で確認できる。

チェックするためのコードはcheck-receive-forward.rbというファイル。

• SQSからチェック対象ホストを1つ抜き出す。
• チェックは対象ホストの http://対象サーバのアドレス/debian/project/trace/ftp-master.debian.org を確認し、最終ミラー時刻が8日以内であることを確認する。不達であったり遅延が大きい場合には"alive=0"として登録される。
• チェック終了したらSQSから消す。
• チェック結果はSimpleDBに登録

地理情報の話やAS情報の話は又の機会に。

 

今日からサポートされたCloudFrontの動的URLサポートのこまかい話

CloudFrontがかなりパワフルになった。おねだんはそのままで!

どれだけかわったかと言えば、とりあえず前のことは忘れてもいい(覚えていたほうがもっといいが必須ではない)と思えてしまうほど。(大枠は、【AWS発表】Amazon CloudFrontが動的コンテンツをサポート あたりを読んでいただきたい)

これ↓が今日からのwebサイトの標準体だろう。



さて、ありがたいことに、動的URLといえばQuery Stringということで、すかさず質問をいただいたので。。

認識しません。というか、それはダサいアプリなどを考えるといれかえてはいけない！ RT @sato_shi: CloudFrontの動的URLサポートって、?a=x&b=y と ?b=y&a=x が同じだって認識してくれるのかな？ #jawsug

— ARAKI Yasuhiroさん (@ar1) 5月 14, 2012

というようなことを書いた。ついでなので細かなことを書いておこう。

Query Stringについて

• Query Stringはオプション機能として提供。有効にすると、Query Stringもすべて含んだfull URLがオリジンに送られる。
  • ロギング機能を有効にしていれば、Query Stringは記録される。
• Query Stringの順番、大文字小文字に注意
• Private Content機能を使うときにCloudFrontで予約しているQueryがあることに注意。
  • Expires, Policy, Signature, and Key-Pair-Id are reserved query parameters

複数のオリジンサーバのサポートについて

• S3 bucket, an ELB, an EC2 instance, a custom originなどなどを指定できる
• 10オリジンまで. それぞれ”Origin ID”が付与される