CDNの比較ポイント

Posted on by 鍋島 公章
このエントリーをはてなブックマークに追加

今回は、Jストリームが考える国内向けCDNの比較ポイントを紹介します。

<記事をホワイトペーパーにまとめました、こちらからダウンロードできます>

重要度：高

  • 顧客コンソール
    • Webサイトに使用される技術も多岐にわたるようになり、CDNもそれに対応するために様々な機能が追加されています。そして、これらの機能を使いこなすには、それぞれのWebサイトにあったCDNの設定変更が必要です。これらの細かな設定を行うためには、ユーザ自身がCDN設定を変更できることが重要です。
    • また、キャンペーン実施時等において、配信状況に応じてCDN設定を変更したいというケースも存在します。この場合についても、ユーザ判断ですぐに設定を変更できるコンソールは重要です。
  • 設定反映時間
    • グローバルCDNサービスでは、顧客コンソールにより設定を変更しても、それが反映されるまでに30分以上かかるものがあります。これは、大量のサーバを運用しているCDNの弱点ともいえる点です。つまり、設定反映までの時間という点では、規模を国内に絞ったCDNの方が（サーバ台数が少ない分だけ）有利になります。
    • 設定反映時間は、サイト管理者の負荷（設定変更の度に30分待ちが発生）低減という意味だけでなく、キャンペーン実施時等における急な設定変更という意味でも重要です。
  • 国内配信拠点数
    • グローバルCDNサービスでは、日本国内に配信拠点を1箇所しか持っていない事業者もいくつかあります。グローバルな配信という意味では、これもCDNです。
    • しかし、この配信拠点に障害が発生した場合、海外から日本にコンテンツを配信することになり、配信品質が急激に低下します。また、配信拠点の障害（もしくはメンテナンス）はある程度の確率で発生するため、複数の配信拠点を日本国内に持っていることが重要になります。
  • 保持帯域
    • 通常のWebサイトの最大ピーク（必要帯域）は、TVで大きく取り上げられた場合になります。また、この時における、通常Webサイトのピーク目安は(ページサイズにより異なりますが）30Gbps～程度ですので、100Gbps程度の帯域を保持していることが必要となります。
  • 動画(HTTPストリーミング)対応
    • 動画配信（ストリーミング）は、HTTPベースのもの(MPEG-DASH等)が主流になりつつあります。そして、MPEG-DASH等においては、通常のHTTP用CDN配信サーバを使用可能です（MPEG-DASHでは、その規格策定において、通常のHTTPサーバで配信可能なことを大きな目標にしています）。
    • ただし、MPEG-DASHでは、その動画配信においてHTTP Range Request（ファイルの一部分だけを取得するHTTPリクエスト）が重要な役割を負っています。しかし、かなりの数のCDNサービスがRange Requestをサポートしておらず、MPEG-DASHを正常に配信できません。
  • SSL対応
    • CDN事業者は、以下の4種類のSSLサービスを提供可能です。それぞれ長所と短所がありますが、幅広いオプションを提供していることが重要です。
      • 専用IPアドレスによる顧客証明書
      • 専用IPアドレスによるCDN事業者マルチドメイン証明書
      • 専用IPアドレスによるCDN事業者ワイルドカードドメイン証明書
      • SNIによる顧客証明書
  • 動的ファイルのキャッシュ対応
    • 最近のWebサーバでは、パーソナライズやCMSによる管理のために、多くのHTMLファイルを動的に生成しています。しかし、従来のCDNではこれら動的ファイルをうまく処理できませんでした（キャッシュさせないという運用しかできませんでした）。
    • 動的ファイルについても、それを正規化する（特定のURLパラメータをキーとする）ことにより、キャッシュさせることができます。この機能を活用することにより、バックエンドデータベースの負荷を低減させることできます。
  • API
    • 最近、多くのWebサイトにおいてCMSが使用されています。ただし、CMSを使用した場合、簡便に記事の投稿管理ができる分、頻繁なファイル更新が発生し、有効にCDNを活用することが難しくなっています。
    • これを解決するために、CMS用CDN APIが登場しています。以下のようなAPIあります：
      • コンテンツプリフェッチ：記事を新規投稿する時に使用
      • キャッシュ削除：記事を更新する時に使用

重要度：低

  • アプリケーション高速化
    • 一般的には、（キャッシュできない）通信の高速化サービスの総称で、キャッシュサーバ間通信に特殊プロトコルを使用することにより高速化を行います。
    • これは、国際通信のような長距離通信について効果が見込めますが、国内においてはほとんど効果が無いと思われます。また、意図的に複数のキャッシュサーバを経由して通信を仲介するため、以下のような場合については、逆に遅くなります：
      • 仲介数増加による延滞＞特殊プロトコルの効果
      • キャッシュ間経路の遅延＞通常経路の遅延
    • また、日本国内においてキャッシュサーバの地理的分散が行われていない場合、このサービスは、国内向けとして提供できません。
  • WAF (Web Application Firewall)
    • WAFは、Webサーバのセキュリティ対策（アプリケーション層ファイアウォールとして攻撃トラフィックを遮断する）として広く使われいます。専用機器としてのWAFは、トラフィックのラーニング、異常検知、サイトに合わせたチューニング等の機能を駆使して攻撃を防御しています。一方、CDNのWAFサービスは、一般的に、専用機器に対して機能が劣ります。
    • また、専用機器版のWAFについても、最近は、安価なものやクラウドサービスとして提供されているものが出てきています。そのため、WAF導入にあたっては、必要とされる機能性と費用の考慮が必要であり、安易にCDN WAFに頼るべきでは無いと思われます。
  • FEO (Front End Optimization)
    • FEOは、Webページを高速にブラウザに表示させるためのページ作成技法で、広く使われています。FEOを自動的に行う（コンテンツを変換する）機器は、数年前までは専用機器としてマーケットに存在していました。しかし、自動変換の困難さから、FEO変換機能は、現在、負荷分散装置のオプションモジュールとして存在する程度であり、独立した機器としてはマーケットから消滅しました。
    • 一方、CDNのFEO機能については、多くの場合、無料で使用可能なApache等のFEOモジュール以上の機能を持っていません。また、CDN FEOは、共用化されたFEO機能となり、細かな設定ができないものも多いのが現状です。

パフォーマンス比較

マルチCDNをサービスしているCedexis社がCDNのパフォーマンスを調査しています。詳細については、Cedexis Radar詳細を参照ください。

比較サイト

いくつかのサイトでCDNの比較を行っており、その比較ポイントについて簡単に日本語化します：

  • CDNPlanet
    • Origin-Pull: リクエストベースによるキャッシュ生成(一般的なCDNの動作）か？
    • Push (upload to CDN servers) :CDN事業者によるオリジンサーバを提要するか？
    • Purge:コンテンツをキャッシュから削除できるか？
    • Purge All:コンテンツ削除にワイルドカードを使用できるか？
    • Gzip Resend from origin, or compress on edge：httpの圧縮(Deflate)について、オリジンサーバで圧縮されたレスポンスをキャッシュ可能か、もしくはCDNサーバで圧縮するか？
    • Persistent connections:パーシステントコネクションを使用できるか？
    • Honors all origin server headers:：CDNサーバは、オリジンサーバが設定したcacheヘッダに従ったキャッシュ処理を行うか？
    • Can override origin server headers:CDNサーバは、オリジンサーバが設定したcacheヘッダを無視し、管理者による上書き設定を有効化できるか？
    • Set caching headers for pushed files:プッシュしたファイルに対してcacheヘッダを付与できるか？
    • Custom CNAMEs:CNAMEのカスタマイズは可能か？
    • HTTPS:SSLをサポートするか？
    • Control Panel & statistics:顧客コンソールを提供するか？
    • Access Logs:生ログをサポートするか？
    • API:APIを提供するか？
    • Support:有人のサポートを提供するか？

 

 

このエントリーをはてなブックマークに追加