varnishとCloudfront

最近、弊社ではcloudfrontとvarnishをどちらを使用すべきか色々実験をしています。
CloudfrontとVarnishどちらにも一長一短があり、アプリケーションの特性によって使える使えないがあります。

いきなり比較

では、ものすごく偏った見解の元に比較してみます。

 

Varnish Cloudfront
Cookieの扱い 正規表現でCookiを通すか通さないかを決定 正規表現は仕様できない、AllとNone、WhiteListという形でCookie情報を記載
URL毎の指定 1行にまとまった形で記載が可能。例えばURL1とURL2は同じ動きをさせる設定が1つで記載 Path Patternという形でそれぞれ記載していく。jpg、gifならば2つ記載
サーバへの負荷 Varnishサーバにアクセスが来るためキャッシュサーバの負荷は大きくなる AWS上でキャッシュするためサーバへの負荷は抑えられる
ヘッダーの取り扱い 各種リクエストヘッダーを付与したりすることが可能 ヘッダーをスルーさせるか、否かの設定が可能。リクエストヘッダーを付与することは出来ない
TTLの設定 varnish側やWEBサーバ側でCache-Controlなどで付与する Cloudfront側で設定が可能。ただしWEBサーバ側でCache-Controlがある場合は状況に応じて代わってくる

キャッシュのTTLをもう少し詳しく説明

CloudfrontでTTLを設定できますが、具体的にはCloudFront エッジキャッシュにオブジェクトを保持する時間の指定(有効期限切れ)に記載があります。
例えば
・TTLに136,800(2日)としてCache-Controlに3600(1時間)としていた場合は、Cache-Controlに3600が優先されます
・TTLに136,800(2日)としてCache-Controlに205200(3日)としていた場合は、Cache-Controlに205200(3日)が優先されます
ちょっと注意しなければいけないのが1番目の
・TTLに136,800(2日)としてCache-Controlに3600(1時間)としていた場合は、Cache-Controlに3600が優先されます
の部分になります。
オリジンが Cache-Control max-age を返し、CloudFront の Minimum TTL が設定されている場合には、CloudFront キャッシュにはどちらか大きい方の値の時間キャッシュされます。 しかし、クライアント側のブラウザでは、CloudFront に設定された Minimum TTL に関係無く、Cache-Control max-age に設定された値だけキャッシュ致します。

どちらがどう使えるか

単純な静的ページのキャッシュにはCloudfrontは大きな効力を発揮します。例えばそれが画像やストリーミングしかりです。
常に動的にページを生成するサイトで使うには十分な検証が必要となります。このページが動かないなどの障害が発生する恐れがあります。
画像やCSSだけをCloudfrontから出すという手段をとっている業者さんも多いようです。

そのあたりVarnishだと柔軟に設定が可能ですので静的ページ、動的ページどちらでも使用可能です。しかしながらサーバが高負荷になった際にはAutoScaling等で対応する必要があります。