CDN は、地理的に分散した多数のサーバーから構成されるシステムで、デジタルコンテンツを配信するための高いパフォーマンスと可用性を備えています。CDN の基本的な考え方は、なるべくエンドユーザーに近いところにコンテンツを置くということです。
デジタルコンテンツ (Web アプリケーション、Web オブジェクト、ファイル、ダウンロード可能なメディア及びストリーミングメディア) を少数のサーバーに置いておく (図１の「CDN 導入なし」) のではなく、世界中に分散して配置した多数のサーバーにコンテンツをキャッシュしておく (図１の「CDN 導入後」) のです。エンドユーザーは必要なコンテンツをオリジンサーバーまで遡って取得するのではなく、最寄りの CDN エッジサーバーから取得できるため、高いパフォーマンスと低いレイテンシーを実現できます。これは同時にオリジンサーバーに負荷が集中して過負荷になることを防ぎ、コンテンツをより多くの視聴者に配信することにつながります。
ユーザーからのデジタルコンテンツへの要求は増え続けており、それは CDN へのニーズにも直結しています。例えば、多くのＥコマース取引、ネット経由で配信されるソフトウェア、オンラインで視聴されるビデオなどが CDN を介して配信されています。Cisco によると、2020 年までにインターネット上のビデオトラフィックの 73% が、CDN を経由することになるだろうということです。*9
ユーザーのデジタルコンテンツへの要求だけでなく、パフォーマンスへの期待も高まっています。ユーザーはどこに居ても、どのデバイスからでも、高品質なデジタルエクスペリエンスを得ることを望んでいます。単一障害点を排し、少しでもパフォーマンスを上げる必要があります。これらの背景から、耐障害性と負荷分散のために、多くの組織がマルチ CDN の採用を始めています。
マルチ CDN 環境を構築する目的は、２つ以上の CDN に負荷を分散させることです。マルチ CDN を使うと、ユーザーからのリクエストをビジネスニーズに応じて最適な CDN に誘導することができます。
例えば図２において、CDN のベンダーＡはユーザー１、および２に対して高品質なサービスを提供できますが、ユーザー３に対してはベンダーＣのほうが良いエクスペリエンスを提供できているとします。マルチ CDN 環境では、ユーザー１および２からのリクエストはベンダーＡに、ユーザー３からのリクエストはベンダーC にリダイレクトするといったことが可能になります。
CDN の選択は手動で行うか、DNS のような技術を使って自動化するか、あるいはサードパーティのトラフィックディレクターを使うことになります。どの技術を使うかにもよりますが、最適な CDN を選択するためには、可用性、地理的な配置、トラフィックのタイプ、容量、コスト、パフォーマンスあるいはそれらの組み合わせなど、多くの条件を考慮しなければなりません。
一般に、ビジネスにおいてマルチ CDN を採用することは、高い可用性、より良いパフォーマンス、容量の増加、強固なセキュリティの面からもメリットが大きいと考えられます。
世界規模でスポーツイベントを配信することは、非常に緊張感のある作業です。何百万人ものファンが見守る中で、少しでも中断が発生したら大変です。そのために、ある組織はビデオ配信のワークフローのすべてのステップに冗長性を組み込みました。
コンテンツ配信も例外ではありません。ビデオコンテンツをエンコードした後、３つの異なる CDN に送ります。何れかの CDNが問題を起こした場合には、トラフィックを動的に他の CDN に振り向け、顧客のデジタルエクスペリエンスを高いままに維持することが可能です。
サービスの停止が世界に大きな影響を与えるほどでは無いとしても、ビジネスにとっては深刻な影響を及ぼす場合があるでしょう。ビジネスにとってインターネットの果たす役割は日毎に高まっており、たった数分のダウンが売り上げに影響し、顧客との関係に悪影響を与えます。マルチ CDN を導入することで、単一障害点のリスクを低減することが可能です。
ある世界的セキュリティソフトウェアベンダーは、自社のソフトウェアアップデートをできる限り早く配布する必要に迫られていました。配信が遅れるとそれだけ新たな脅威に対する脆弱性が増し、システムをソフトウェアバグのリスクに晒したり、売り上げに直結する機能にアクセスできなくなったり、新規のソリューションを展開できなくなったりします。これは、売り上げに直結する問題です。ソフトウェアをできる限り迅速に配信するために、このベンダーは複数の CDN の様々なパフォーマンスを計測し、より高速な CDN を複数社選択しました。これにより、彼らの顧客に対して最高のエクスペリエンスを提供できたのです。
配信するものがオンラインビデオであれ、Web コンテンツであれ、あるいはインターネット経由のソフトウェアであれ、配信のパフォーマンスが悪ければ、ユーザーの不満は増大し、それはサイトからの離脱に繋がり、ブランドに悪影響を与えます。
1社の CDN があらゆるトラフィックタイプ/あらゆる地域で、常に最高のパフォーマンスを出すことは困難なケースも見受けられます。複数の CDN プロバイダを使ってインテリジェントにコンテンツ配信を分配することで、特定のプロバイダ、特定のトラフィックタイプ、特定の地域に紐付いた問題の発生を緩和することができます。
ある組織は、世界最大のテクノロジー企業の一つとして自社で CDN を運用しています。しかし、大きな配信イベントがあると、手持ちの容量だけでは足りなくなることがありました。また、地域によっては容量が限られており、追加の容量を確保する必要に迫られることもあります。これらのケースで、マルチ CDN アプローチによって過剰なトラフィックを他の CDN に分配することが可能になりました。すべてのプロセスはユーザーに対してシームレスであり、非常に高いレベルのユーザーエクスペリエンスを提供できます。
CDN のキャパシティには限りがあります。各 CDN ベンダーは、以前よりも多くのコンテンツを、以前よりも多様なデバイスに、以前よりも広範な地域へ向けて、非常に高い品質で配信することに努めています。このことは、既に過負荷状態にあるインフラにさらなるストレスをかけているとも言えます。大規模なコンテンツ配信イベントの際には、特定の CDN や特定の地域で通信の遅延が起こる可能性があります。そのような時でも、マルチ CDN を使えば、通信負荷を複数の CDN に分散することで、ボトルネックを緩和することが可能になります。
また、キャパシティには種類があるということも知っておく必要があります。特定のサービス毎にキャパシティの制限があるのです。例えば、最近ではセキュリティ意識の高まりによって暗号化の要求が高まっていますが (現代のWebサイトの 45% 以上が既に暗号化通信に対応済みです*10)、ある CDN で全体のキャパシティに余裕があったとしても、SSL*11 のキャパシティには制限が課される場合もあるのです。
世界的に、インターネットセキュリティへの関心が高まっています。Ponemon Instituteによると、データセンター停止の原因として最も急激に増えているのはサイバー犯罪だということです。*12 万一 CDN に障害が発生した場合、ユーザーがお客様のデジタルコンテンツにアクセスすることができなくなったり、エクスペリエンスを損なったりすることになりかねません。マルチCDN により、攻撃を受けた場合でも障害のある CDN をバイパスすることができ、被害を最小限に抑える方式をとることが可能です。
マルチ CDN には様々な場面でメリットがあることは明らかですが、どのようにしてマルチ CDN を構築すべきなのでしょうか?
また、構築に当たってはどのような点に注意して、自社のアプリケーションに最適な方法を選ぶべきでしょうか?
DNS (Domain Name System) は、インターネット上の名前管理システムです。インターネット上の特定の情報を見たいとき、私達は Web ブラウザーにドメイン名を含む URL を入力して、情報の場所を指定します。
例えば、http://www.example.com/index.html という URL には、example.com というドメイン名が含まれています。これは人間が覚えるには便利ですが、インターネットを支えているネットワーク機器はこの名前を理解できません。名前では無く、IPアドレス (機器ごとに設定されるユニークな数値を使った識別子) を使っているのです。この、ドメイン名から IP アドレスへの変換を DNS が行っています。DNS は CDN の運用にとって基本的なものであり、マルチ CDN 環境で異なる CDN を切り替えるための最も一般的な手法の一つです。
マルチ CDN の構築において最も基本的な手法は、DNS エントリを修正することです。この手法は、アクティブ/スタンバイ構成において利用可能です。例えば図３では、CDN B が停止した場合に DNS エントリを修正してすべてのリクエストを CDN Aにリダイレクトします。この手法を使うと、異なる CDN 毎に異なるホスト名をマッピングすることで、異なるポリシーを適用する事ができます。例えば、CDN Aで はWebサイトのトラフィック (www.example.com) を扱い、CDN B ではオンラインビデオを配信する (http://www.example.com/) といった運用が可能になります。
この手法における明らかなデメリットは、変更を手作業で行うため、CDN 間のトラフィックのリルートに時間がかかるということです。商用のマネージド DNS ソリューションを使うと、自動的にリルートしてくれます。
ラウンドロビン方式によるロードバランスにおいては、リクエストは CDN 間で動的かつ順番に割り振られます。例えば、２つの CDN によるマルチ CDN 構成の場合、最初のユーザーリクエストは CDN 1 に、次のリクエストは CDN 2 に、さらにその次はCDN 1 に、といった具合です。通常 DNS はユーザーリクエストを次の空いている CDN に振り向けるために使われます。ラウンドロビンによるロードバランスは導入が比較的容易ですが、全ての CDN を等価に扱うため、地域毎の状況やその他のネットワーク環境を考慮することはできません。
レシオ (比率) ロードバランスとも呼ばれる重み付けラウンドロビン方式は、CDN に優先度を付け、それに応じて重みをつける方法です。この場合、あらかじめ設定した比率によって DNS がトラフィックの配分を決定します。例えば図４では、CDN A がトラフィック全体の 3/4 を受け持ち、残りの 1/4 を CDN B に振り向けます。
重みや比率は、お客様のビジネスにとっての優先度 (コストやパフォーマンス、ISP との接続性など) に応じて決めることができます。ラウンドロビンよりもきめ細かい制御が可能ですが、地域毎の状況やネットワーク環境などは考慮できません。
ジオロケーションを使う場合、トラフィックはエンドユーザーの所在地によって適切な CDN に振り分けられます。これにより、トラフィックがどこから発信されたかによって特定の CDN が選択されます。例えば図５では、北アメリカからのトラフィックは CDN A に、欧州およびアジアからのリクエストは CDN B に振り向ける、といった具合です。ロケーションは国、州または行政区などに設定できます。
ジオロケーションは強力な分散手法ですが、ネットワーク環境を考慮することはできません。例えば、特定の地域で人気が高い CDN の場合、通信量が多い時間帯は最良のパフォーマンスを発揮できないケースも見られます。
パフォーマンスベースのロードバランスであれば、その時点でのネットワーク環境を考慮して理論上最高のパフォーマンスを達成することができます。このアプローチでは、ネットワーク環境を測定し、負荷分散処理時にその結果を活用します。導入するCDN 切り替えソリューションにもよりますが、CDN 選択の際には様々なパフォーマンス指標が比較されます。例えば、レスポンスタイム、スループット、リバッファリングレシオ、ビットレートやその他の様々な指標です。このタイプのソリューションを検討する場合、お客様のビジネスにとって最も重要な指標は何かを十分に理解し、それをどのように計測すべきかを熟慮すべきです。
マルチ CDN でのパフォーマンスベースのロードバランスは、ビデオプレイヤーなどのクライアントアプリケーションと組み合わせた場合、さらに高度な制御が可能です。ビデオストリーミングの場合、ビデオプレイヤーに特定のクライアント機能を持たせることができます。これらの機能を使ってビデオサーバーからクライアントにビデオ/オーディオチャンクの場所を示す URL を含むマニフェストファイルを送り*13、マルチ CDN の中でどの品質レベルを採用するかを選択します。
多くのプレイヤーがネットワーク状況 (バッファリングや利用可能な帯域など) を監視して、どの品質のビデオをダウンロードするかを決定し、同じ情報を使って、あらかじめ決められた基準に従って最適な CDN を選択します。
マルチ CDN は多くのメリットを持っていますが、万人向けのソリューションではありません。自社のビジネスにとってマルチCDN が最適かどうかを考えるために、以下の点を確認する必要があります。
確認すべき点
|
|
| 自社のビジネスにとって、ネットワーク停止がもたらす影響はどのようなものでしょうか?
|
数分間のダウンタイムなら許容できますか? あるいは、数時間では? もし自社のビジネスがほんの少しの停止も受け入れられないのであれば、マルチ CDN は有効と言えます。 |
| 自社のデジタルコンテンツは、どれだけのトラフィックを生み出しますか?
|
回線容量の上限まで使い切ってしまっている、あるいはトラフィック急増時に溢れた分を他の CDN に振り向けることで問題を軽減できますか? トラフィックが多いほど、マルチ CDN の効果は大きくなります。 |
| 自社のコンテンツ配信は、どれくらいのパフォーマンスを必要としていますか?
|
ビデオストリーミングなど、いくつかのアプリケーションにとってはパフォーマンスは非常に重要ですが、ソフトウェアパッチのダウンロードなどにとってはそれほどでもありません。パフォーマンスが重要なケースでは、マルチ CDN のメリットが大きいと考えられます。
|
| 自社のWebサイトの視聴者数はどれくらいで、どこからアクセスしてきますか?
|
視聴者が多数で、なおかつ世界中に分散している場合、マルチ CDN の効果が見込めます。 |
| コンテンツは、どのように保存されていますか?
|
デジタルコンテンツは、CDN 内に保存されていますか? それともCDN 外でしょうか?CDN 内での保存はパフォーマンスとコストの両面でメリットがありますが、マルチCDN を使う場合には CDN 間でのレプリケートが発生します。 もしくは、他の CDN からのオリジンへのアクセスを許可する CDN を選択しなければなりません。 |
| 複数の CDN 間でトラフィックを切り替えるために、どのような手法を使いますか?
|
前述したように様々な手法がありますが、どのやり方がビジネスにとって有効でしょうか? 手動での DNS 切り替えをしている時間がありますか? パフォーマンスを最適化することができますか? |
| ビジネスにとって、最も重要なパフォーマンス指標は何でしょうか?
|
パフォーマンスベースのソリューションを検討している場合、リバッファリングレシオ、ビットレート、可用性、スループット、レスポンスタイムなど、お客様固有のコンテンツ配信アプリケーションにとって最も重要な指標をクリアしていますか? |
| CDN をいくつ使いますか?
|
CDN をいくつも追加していくと、効果が薄れるポイントがあります。CDN の数が増えると、管理の複雑さが増すからです。各 CDN には独自の UI があり、API があり、課金方法があり、機能があります。社内の開発・運用チームは、これらの違いを理解して管理する必要があります。 |
お客様のコンテンツ配信環境に CDN、あるいは複数の CDN を追加することが妥当だと思われる場合、次の疑問は、どのCDN ベンダーをパートナーとして選べば良いか、ということでしょう。以下に考慮すべきポイントを挙げます:
• カバーする地域
CDN 選択の際に考えるべき重要なポイントは、「自社のユーザーはどこにいるのか?」ということです。ユーザーが所在する地域を漏れなくカバーできる CDN を探さなければなりません。全世界レベルでの配信を考えている場合には、将来の拡張性も重要になります。例えばインドのような新興国からのトラフィックが将来急増することが見込まれる場合、契約の見直しや CDN の移行を考えなくても済むようにしておく必要があるでしょう。
• パフォーマンス指標
パフォーマンスは、コンテンツの配信環境やワークロードによっても変わるため、比較の難しい項目です。パフォーマンスについての重要なポイントは、配信しているコンテンツのタイプと、ユーザーのカスタマーエクスペリエンスにとって最も重要なパフォーマンス指標は何か、ということです。ビデオ配信に関する指標であれば、リバッファリングレート、ビットレート、スタートアップタイムなどが含まれるでしょう。ソフトウェアのダウンロードであれば、スループット、エラーレート、ダウンロード完了率などが重要になります。Web サイトなら、最初のデータ取得までの時間、あるいはページロード時間が最も重要でしょう。CDN によっては、特定の指標に強く、他はそうでもない場合もありますので注意が必要です。
• パフォーマンス測定
異なる CDN ベンダーの間でどのようにしてパフォーマンスを比較し評価するのかについても考えなければなりません。商用のパフォーマンス監視ツールもいくつかありますが、多くの場合、結果を鵜呑みにはできません。なぜなら、これらの測定はシミュレーションがベースになっているか、実際には使われることの無い現実離れしたデータセットを使って推定されたもので、実際の負荷状況を反映したものでは無いからです。一番良い方法は、実際のデータを使い、お客様にとって最も重要な地域でトライアルを行うか、プルーフオブコンセプト (PoC) によって複数の CDN を比較することです。
• サービス&サポート
時には問題も起こります。そういった時に、高品質なサポートを受けられれば、事態は一変するものです。カスタマーサポートに直接アクセスできることがどれだけ重要なことか、考えてみて下さい。そのサポートには、営業時間外でもアクセスできますか? 該当の地域で、どのようなサポートが提供されていますか? サポートは無償で提供されているか、それとも追加コストが必要ですか? ライブイベントを行おうとしているとき、CDN パートナーにはどれだけの経験があり、イベント前・イベント中に一緒に立ち会ってくれますか? 他の CDN からの移行時に助けてくれますか?
• CDN ストレージ
コンテンツオリジンを CDN にオフロードしたいという要望はありますか? ある場合、CDN ストレージあるいは中間層のキャッシュソリューションのパフォーマンスはどれくらい重要でしょうか? その CDN ストレージは、マルチ CDN 環境をサポートしていますか? もしそうなら、その CDN はマルチ CDN 環境の中でどのように動作しますか?
• 統合サービス
異なる CDN には、異なる機能があります。これらの機能のうち、コンテンツ配信ニーズにとって最も重要なものはどれで、それらが CDN 自体と密接に統合されているかどうかを考えなければなりません。
パージ：迅速なパージへの要求はどれくらいあるでしょうか? パージとは、古くなったコンテンツを CDN 上から削除する作業です。いくつくらいのオブジェクトをパージする必要がありますか? パージされたかどうかを確認できることの重要性はありますか?
セキュリティ：コンテンツ配信において、セキュリティの重要性はいかほどでしょうか? DoS (Denial of Service: サービス妨害) 攻撃、あるいは Web アプリケーションを狙った攻撃を防ぐ必要はありますか? トラフィックのほとんどが既に暗号化されているか、あるいは将来暗号化する予定はありますか? 地域、IP アドレス、あるいは URL によってコンテンツへのアクセスを制限する必要はありますか?
ビデオ：ビデオ配信を行っている場合、トランスコード/トランスマックス/翻訳機能は必要ですか?
管理とレポート：自社のコンテンツを配備して管理することができるユーザーインターフェース、もしくはポータルが必要ですか? システムと CDN を密に統合するために、API を使った開発を行う必要はありますか?
デジタルコンテンツの配信を最適化するために必要な、リアルタイムの統計情報はどのようなものですか?
ライムライト・ネットワークスは、世界的にみても主要な CDN のひとつです。ライムライトのプライベートネットワークはコンテンツ配信専用に設計・構築されており、世界のどこへでも、どのようなデバイスへでも、高い品質でデジタルコンテンツを配信でき、安全に管理することができます。ライムライトの従業員は誰もが、お客様とエンドユーザーのためにより良いエクスペリエンスを提供することを第一に目指しています。
お客様がマルチ CDN 戦略を採用する際のパートナーとして、ライムライトが最適である理由をいくつかご紹介します:
視聴者に高品質なデジタルエクスペリエンスを提供することは、かつてよりも重要になっています。多くの場合、コンテンツデリバリーをただひとつの CDN に頼るのは、ビジネスに求められる柔軟性を阻害し、ユーザーに最高のエクスペリエンスを提供できなくなるかもしれないというリスクが生じることもあります。
マルチ CDN 戦略は、視聴者が期待しているエクスペリエンスを提供する上で、一定のレベルの保証と品質を確保するのに役立ちます。しかしマルチ CDN の構築は、単純に CDN を選んでスイッチを入れれば良いというものではありません。それは、デジタルコンテンツのトラフィック、視聴者のニーズ、社内IT組織の体制、CDN パートナーの選択などを理解した上でなければならないのです。
ライムライト・ネットワークスは、これまでに世界最大のブランドを含む多くの組織をサポートし、効果的なマルチ CDN を構築してきました。現在の環境にライムライト CDN を追加することで、どのような効果・メリットがあるのかを確かめるために、是非ライムライト・ネットワークスまで一度お問い合わせ下さい。
1 “Cost of Data Center Outages”, Ponemon Institute, January 2016 (http://www.ponemon.org/blog/2016-cost-of-data-center-outages)
2 2013 年の Amazon の停止は、１分あたり $66,000 以上の損害を与えたと見積もられている (http://www.forbes.com/sites/kellyclay/2013/08/19/
amazon-com-goes-down-loses-66240-per-minute/#44858cd43c2a)
3 http://www.informationweek.com/cloud/infrastructure-as-a-service/amazon-disruption-produces-cloud-outage-spiral/d/
d-id/1322279
4 http://www.businessinsider.com/google-apologizes-for-cloud-outage-2016-4
5 http://appleinsider.com/articles/16/06/02/apples-app-stores-apple-tv-itunes-other-services-hit-with-downtime
6 http://www.businessinsider.com/microsoft-has-a-9-day-long-office-365-outage-2016-1
7 出典: The State of Online Video, Limelight, 2016 (http://img03.en25.com/Web/LLNW/%7Bc02f1632-f615-471f-a79e-354d5cc0244f%7D_2016State
ofOnlineVideo.pdf)
8 出典: The State of the User Experience, Limelight, 2016 (http://img03.en25.com/Web/LLNW/%7B70a00140-3e71-4850-9ab4-69ee4672df9c%7D_
StateoftheUserExperience.pdf)
9 Cisco Visual Networking Index:Forecast and Methodology, 2015-2020 (http://www.cisco.com/c/en/us/solutions/collateral/
service-provider/visual-networking-index-vni/complete-white-paper-c11-481360.html)
10 https://www.nsslabs.com/blog/analyst-insights/ssl-is-everywhere-are-you-ready-for-it/
11 SSL は、ブラウザーと Web サーバーの間の通信を暗号化するための技術
12 “Cost of Data Center Outages”, Ponemon Institute, January 201 6 (http://www.ponemon.org/blog/2016-cost-of-data-center-outages)
13 DASH や HLS のような動的ストリーミングプロトコルは、ビデオを「チャンク」と呼ばれる小さな断片に分割し、ビデオクライアントは HTTP を使ってチャンクをリクエストする
