カテゴリー「cdn」

ここ最近、インフラ寄りの話ばかりであるが、

GooglePlatformで使えるCloudCDNについて書いておく。

 

CloudCDNはawsのcloud frontなどとは違い、

ロードバランサーの一機能として利用できる。

特徴としては、

ロードバランサーと同一ドメインで利用できるところである。

イメージ的には以下のようになる(実際は違いますけど。。)

 


    user <--> load balancer <--> cloud cdn <--> vm instance 

 

この構成のよいところは、オリジンであるVMインスタンス(awsでいえばEC2)に置いてあるキャッシュさせたいコンテンツを、

ロードバランサーと同じドメインで取得できるところである。

そのため、VMインスタンスに画像等を丸々配備できるため、開発者がインフラを意識する必要がなくなるということだ。

 

これに対し、他CDNの場合、キャッシュさせたいコンテンツを他ドメインから取得させるよう、

HTMLをコーディングする必要がある。

しかし、CloudCDNなら、それを意識する必要はない。

これは開発者から見ると非常に大きな利点である。

(awsのcloud frontのL7機能でキャッシュの有無を調整することは可能だが、キャッシュさせないコンテンツでも瞬間的にはキャッシュされるので、

一意URLによるGETなどはあらかじめ注意して開発する必要がある)

 

ただし、HTTP/1.1の場合、同一ドメインから同時にアクセスできるURL数というのはブラウザで制御しているため、

実際には様々なドメインから取得させた方がユーザへの体感速度の向上が図れるのは周知の事実である。

(HTTP/2ではこの問題も多少はマシになるとは期待してますが、、)

 

ただ、CloudCDNの残念なところは、現状キャッシュされているものの情報や、ヒット率等の統計が取れないところである。

しかし、何度も書いたように、開発者(もっといえばコンテンツ開発者)にありがたいインフラ構成というのは、特筆すべき点かと思われる。

 

以上

投稿日時:2016年10月17日 00:54   カテゴリー:cdn, gcp   [コメントがあればどうぞ]

以前の記事で、CDNについて書いてみようかなということにしていたので、

次世代CDNとうたわれるfastlyについて書いてみる。

 

fastlyの最大の特徴は、

0.5秒で世界中のキャッシュを消す

というインスタントパージ機能である。

これはほんとにすごい。

他のCDNでは実現できていない高機能である。

 

実際にキャッシュが消えたかを確認するには、

キャッシュを消す前後で、以下APIをたたいてHASHを確認することができる。

https://docs.fastly.com/api/tools#content

実際にHASHは異なっていたし、キャッシュも消えていた。

 

もうひとつfastlyはすごいと思ったことがある。

それはキャッシュしなかった場合でも、

選択される回線の速度が非常に速い

実際にルータのホップ数などを見ても、とても少ない。(そのため、オリジンとfastly間の転送料金が高めだが)

 

広域にコンテンツを展開したいとき、

非常に有効なCDNだと思われる。

 

以上

投稿日時:2016年10月17日 00:26   カテゴリー:cdn   [コメントがあればどうぞ]

AWSのCDNであるCloudFrontを利用したので、

その特徴を記載しておく。

 

良い点
・L7レベルで動作
たとえば2つのオリジンを設定して、
パスパターンによって、振り分け先を変更できること。
静的コンテンツはS3に、動的コンテンツはELBに振るなどが可能。

・独自ドメインでのSSLが利用可能
S3では出来ない独自ドメインSSLが利用可能。

・AWS内のオリジンとは高速な通信
オリジンがELBの場合、ELB配下のインスタンスが巨大な画像等を返す場合、
通信が安定しているcloudfrontに返すほうが、インスタンスの負荷は下がる。

悪い点
・変更反映が遅い
15分くらいかかるのだろうか。

・キャッシュ削除が遅い
これも15分くらいかかっている感じがする。

・連続的にGETアクセスした場合にキャッシュさせたくなくてもキャッシュされる
例えば2つオリジンを設定して、片方を静的、もう片方を動的とする。
動的コンテンツ側に振られるURLに瞬間的に連続アクセスした場合、すべてのリクエストが動的コンテンツ側に来るわけではなく、
cloudfrontにキャッシュされてしまう。
後述するキャッシュのヒット条件にもよるが、
キャッシュさせないはずの動的コンテンツが、実際にはキャッシュからエンドユーザに返される可能性がある。
最も簡単・確実に回避するためには、URLに一意のクエリ文字列を付ければよい。(JSを使って、タイムスタンプ+ランダム文字列などを付与する)

・オリジンへ渡すヘッダー情報がキャッシュキーの種となる
オリジンへ渡すヘッダーとしては諸々設定が可能だが、
動的コンテンツをオリジンとする場合、user-agentなどを通ししまうと、
それがキャッシュキーの種となり、結果としてキャッシュヒット率が下がる。
この場合は、cloudfront独自の「IS_MOBILE」的なヘッダーを付けて、オリジン側で判定として使える。
逆に言うと、cloudfrontを使う場合、オリジンで「IS_MOBILE」などの判定処理を用意しておく必要がある。

 

CloudFrontは設定が細かく、結構難しい。

ただ、統計情報も充実しており、

なんといっても高負荷に強く、エッジロケーションも広いので、

上手く使えば非常に強力な製品だと感じた。

気を付けるべきは、動的コンテンツを背後に置く場合だろう。

キャッシュ条件、キャッシュ生存期間など、動的コンテンツ作成者側が意識しておくことで、

より有用なものとすることが出来ると思う。

 

最近は、CDNが多用されているので、

各CDNの特徴をよく確認し、十分に検証したうえで、

導入を検討するとよいと思う。

 

他のCDNについても、機会があれば書いてみようと思います。

 

以上

投稿日時:2016年08月13日 23:36   カテゴリー:aws, cdn   [コメントがあればどうぞ]