cdn.debian.netの中身と開発計画を大統一Debian勉強会でしゃべってきた

cdn.debian.netの中身をきちんと説明したことがなかったのでやってみたのだが、５分では短かすぎた。

cdn.debian.net 開発計画 from yasuhiro araki

• 多くの人に興味をもってもらえそうなことを前に持ってきたのはいい（たぶん）
• 開発協力者に対してちゃんと説明しなければならない後半が飛ばしまくりになった。

今日はcdn.debian.netのRuby2.0対応をしていて微妙に時間をつかった。しかも途中。。

via http://arakinotes.blogspot.com/2013/06/cdndebiannetdebian.html

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

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

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

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

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

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

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

質問は随時。

via http://arakinotes.blogspot.com/2013/05/cloudfront10.html