はじめに
みんな大好きCloudFrontですが、本格的なCDNが手軽に使える分、けっこう落とし穴があります。そこで、個人的にはまったポイントを書いてみました。
ここがつらい
Originに転送できないリクエストヘッダーがある
http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/forward-custom-headers.html#forward-custom-headers-blacklist
Cache-ControlやContent-Lengthが転送できないのは、CloudFrontがリクエストボディを書き換えるから、Originに転送する意味がないためだろう。If-*関連のヘッダーが転送されないのはちょっと不便、、
Rangeヘッダーを書き換える
Rangeヘッダを付けずにCloudFrontへmp4動画をリクエストすると、OriginへのアクセスにRangeヘッダが追加されている。たぶんファイルサイズの大きいファイルへアクセスがあると、Originから部分ダウンロードを試みるのだろう。
また、RangeヘッダーをつけてCloudFrontへアクセスしたときも、Rangeヘッダが書き換えられる。
http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/RangeGETs.html
パフォーマンスを最適化するために、CloudFront は、Range GET でクライアントから要求された範囲よりも大きい範囲を要求する場合があります
Rangeヘッダーをチェックしてごにょごにょしているプログラムを扱っているときは、注意。
APIでinvalidationを投げるとき、ユニークなトークンを送る必要がある
例えばrubyのaws gemを使うと、caller_referenceにユニークな文字列を入れる必要がある。caller_referenceが空だったり、以前のinvaidationとcaller_referenceが被っていたりすると、invalidationは発行されない。なぜinvalidationが動かないのかわからず、はまったことが。。
rubyのコード例:
cloudfront = Aws::CloudFront::Client.new
cloudfront.create_invalidation(
distribution_id: "YOUR_DESTRIBUTION_ID",
invalidation_batch: {
paths: {
quantity: 1,
items: ["/*"]
},
caller_reference: Time.now.to_i.to_s # 現在時刻を入れる
}
)
反映が遅い
一般的なCDNと同じく、CloudFrontサーバー同士はP2Pで通信する仕組みのはず。ブロードキャストのような通信方法に比べて、すべてのサーバーに変更が行き渡るまでに時間がかかる。少し設定を変更するたびに20分ぐらい待たないといけないのはやはり辛い、、
URLからファイル名を省略できない
Default Root Objectにファイル名を設定できるが、ルートパスにのみ適用される。(例えばDefault Root Objectにindex.htmlを設定したとき、/のパスで/index.htmlにアクセスできるが、/sub/のようなパスで/sub/index.htmlにアクセスはできない。)特に他のサーバーからCloudFrontに移行するときは、ファイル名が省略されたURLがないか確認する必要がある。
終わりに
つらさが伝わるといいなあ・・・