
コンテンツ配信ネットワーク(CDN)またはコンテンツ配信ネットワークは、プロキシサーバーとそれに対応するデータセンターの地理的に分散されたネットワークです。CDNは、エンドユーザーに対する地理的な分散によって高い可用性とパフォーマンス(「スピード」)を提供し、インターネットが重要なメディアになりつつあった1990年代後半に、インターネットのパフォーマンスのボトルネックを緩和するために登場しました[ 1 ] [ 2 ]。それ以来、CDNは、テキスト、グラフィック、スクリプト、ダウンロード可能なオブジェクト(メディアファイル、ソフトウェア、ドキュメント)、アプリケーション(eコマース、ポータル)、ライブストリーミングメディア、オンデマンドストリーミングメディア、ソーシャルメディアサービスなど、インターネットコンテンツの大部分を提供するように成長しました。[ 3 ]
CDNはインターネットエコシステムにおける一つのレイヤーです。メディア企業やeコマース事業者などのコンテンツ所有者は、コンテンツをエンドユーザーに配信するためにCDN事業者に料金を支払います。一方、CDN事業者は、自社のデータセンターにサーバーを設置してもらうために、インターネットサービスプロバイダー(ISP)、通信事業者、ネットワーク事業者に料金を支払います。
CDNは、ビデオストリーミング、ソフトウェアダウンロード、Webおよびモバイルコンテンツの高速化、ライセンス型/マネージドCDN、透過型キャッシング、CDNパフォーマンス測定サービス、ロードバランシング、マルチCDN切り替えと分析、クラウドインテリジェンスなど、さまざまな種類のコンテンツ配信サービスを包括する用語です。CDNベンダーは、セキュリティ、 DDoS攻撃対策、Webアプリケーションファイアウォール(WAF)、WAN最適化といった他の業界にも進出する可能性があります。
コンテンツ配信サービスプロバイダーには、Akamai Technologies、Cloudflare、Amazon CloudFront、Qwilt(Cisco)、 Fastly、CDN77、BunnyCDN、EdgeNext、およびGoogle Cloud CDNが含まれます。
CDNノードは通常、複数の場所に展開され、多くの場合、複数のインターネットバックボーンを経由します。利点としては、帯域幅コストの削減、ページ読み込み時間の短縮、コンテンツのグローバルな可用性の向上などが挙げられます。CDNを構成するノードとサーバーの数は、アーキテクチャによって異なり、数千のノードと数万のサーバーを多数のリモートPoP(接続拠点)に配置するものもあります。また、グローバルネットワークを構築し、地理的に少数のPoPを持つものもあります。[ 4 ]
コンテンツへのリクエストは、通常、何らかの点で最適なノードにアルゴリズムによって振り分けられます。パフォーマンスを最適化する場合、ユーザーにコンテンツを提供するのに最適な場所が選択されます。これは、リクエスト元のクライアントまでのホップ数が最も少ない場所、またはリクエストにかかる時間が最短の場所、あるいはサーバーのパフォーマンスが最も高い場所を選択することで測定され、ローカルネットワーク全体での配信を最適化します。コストを最適化する場合は、代わりに最も安価な場所が選択されます。最適なシナリオでは、これら2つの目標は一致する傾向があり、ネットワークのエッジでエンドユーザーに近いエッジサーバーは、パフォーマンスとコストの両面で優位性を持つ可能性があります。
ほとんどのCDNプロバイダーは、米国、アジア太平洋、国際、グローバルなど、希望するカバレッジに応じて、定義されたさまざまなPoPセットを介してサービスを提供します。これらのPoPセットは、エンドユーザーに最も近いCDNアセットのエッジとなるため、「エッジ」、「エッジノード」、「エッジサーバー」、「エッジネットワーク」などと呼ばれます。[ 5 ]
CDNの概念:
CDNプロバイダーは、ネットワークを使用するコンテンツプロバイダーが支払う直接料金、または顧客のブラウザオリジン内でスクリプトが顧客のウェブサイトに読み込まれる際に収集されるユーザー分析および追跡データから利益を得ています。そのため、これらのサービスは行動ターゲティングを目的とした潜在的なプライバシー侵害として指摘されており[ 6 ]、リソースの単一オリジン配信とキャッシュを復元するためのソリューションが作成されています[ 7 ] 。
特に、CDNを使用するウェブサイトは、EUの一般データ保護規則(GDPR)に違反する可能性があります。例えば、2021年にドイツの裁判所は、ユーザーのIPアドレスがCDNに送信され、GDPRに違反するとして、大学のウェブサイトでのCDNの使用を禁止しました。[ 8 ]
JavaScript を提供する CDN も、それらを使用するページに悪意のあるコンテンツを挿入する手段として標的にされてきました。これに対応して、Web サイトの作成者が参照するハッシュによってコンテンツが既知かつ制限されたスクリプトをページが読み込むことを保証するために、サブリソース整合性メカニズムが作成されました。 [ 9 ]
インターネットはエンドツーエンドの原則に基づいて設計されました。[ 10 ] この原則により、コアネットワークは比較的シンプルに保たれ、インテリジェンスは可能な限りネットワークのエンドポイント、つまりホストとクライアントに移されます。その結果、コアネットワークはデータパケットを転送することだけに特化、最適化、簡素化されています。
コンテンツ配信ネットワークは、コンテンツ配信を最適化するために設計された技術を用いて、さまざまなインテリジェントアプリケーションを配信することで、トランスポートネットワークを拡張します。結果として得られる緊密に統合されたオーバーレイは、Webキャッシング、サーバー負荷分散、リクエストルーティング、およびコンテンツサービスを使用します。[ 11 ]
Webキャッシュは、要求されたコンテンツに対する需要が最も高いサーバーに人気のあるコンテンツを保存します。これらの共有ネットワーク機器は、帯域幅の要件を削減し、サーバーの負荷を軽減し、キャッシュに保存されたコンテンツに対するクライアントの応答時間を改善します。Webキャッシュは、ユーザーからの要求に基づいて(プルキャッシング)、またはコンテンツサーバーから配信されるプリロードされたコンテンツに基づいて(プッシュキャッシング)構築されます。[ 12 ]
サーバー負荷分散は、サービスベース(グローバル負荷分散)またはハードウェアベース(レイヤー4~7スイッチ、Webスイッチ、コンテンツスイッチ、マルチレイヤースイッチとも呼ばれる)など、1つ以上の手法を使用して、複数のサーバーまたはWebキャッシュ間でトラフィックを分散します。ここでは、スイッチに単一の仮想IPアドレスが割り当てられます。スイッチに到着したトラフィックは、スイッチに接続されている実際のWebサーバーのいずれかに転送されます。この方式の利点は、負荷分散、総容量の増加、スケーラビリティの向上、および障害が発生したWebサーバーの負荷を再分散し、サーバーの健全性チェックを提供することによる信頼性の向上です。
レイヤー4~7スイッチを使用することで、ネットワーク内の複数のサーバーまたは複数のWebキャッシュ間で負荷分散を行うコンテンツクラスタまたはサービスノードを形成できます。
リクエストルーティングは、クライアントのリクエストを、そのリクエストを最も適切に処理できるコンテンツソースにルーティングします。これには、クライアントに最も近いサービスノード、または最も容量の大きいサービスノードにクライアントのリクエストをルーティングすることが含まれます。リクエストのルーティングには、さまざまなアルゴリズムが使用されます。これには、グローバルサーバー負荷分散、DNS ベースのリクエストルーティング、動的メタファイル生成、HTML 書き換え[ 13 ] 、およびエニーキャスト[ 14 ]が含まれます。近接性(最も近いサービスノードを選択すること)は、リアクティブプロービング、プロアクティブプロービング、接続監視などのさまざまな手法を使用して推定されます[ 11 ] 。
CDNは、手動によるアセットコピー、アクティブなWebキャッシュ、グローバルなハードウェアロードバランサーなど、さまざまなコンテンツ配信方法を使用します。
コンテンツ ネットワーク全体に分散されたさまざまなコンテンツ サービスへのアクセスを提供するように設計されたプロトコル スイートがいくつかあります。インターネット コンテンツ アダプテーション プロトコル(ICAP) は、アプリケーション サーバーを接続するためのオープン スタンダードを提供するために 1990 年代後半に開発されました[ 15 ] [ 16 ]。より最近定義された堅牢なソリューションは、Open Pluggable Edge Services (OPES) プロトコルによって提供されます。[ 17 ]このアーキテクチャは、OPES プロセッサ自体に存在したり、コールアウト サーバーでリモートで実行したりできる OPES サービス アプリケーションを定義します。Edge Side Includesまたは ESI は、エッジ レベルの動的な Web コンテンツをアセンブリするための小さなマークアップ言語です。Web サイトが生成されたコンテンツを持つことはかなり一般的です。これは、カタログやフォーラムなどの変化するコンテンツ、またはパーソナライゼーションが原因である可能性があります。これは、キャッシュ システムにとって問題となります。この問題を克服するために、企業グループが ESI を作成しました。
ピアツーピア(P2P)コンテンツ配信ネットワークでは、クライアントはリソースを提供するだけでなく、それらを使用します。つまり、クライアント/サーバーシステムとは異なり、コンテンツ中心のネットワークは、より多くのユーザーがコンテンツにアクセスし始めると、実際にパフォーマンスが向上します (特に、ユーザーが共有する必要があるBitTorrentなどのプロトコルの場合)。この特性は、P2P ネットワークを使用する主な利点の 1 つです。なぜなら、元のコンテンツ配信者にとってセットアップと運用コストが非常に小さくなるからです。[ 18 ] [ 19 ]
P2Pネットワークへの参加を促すために、Web3やブロックチェーン技術を利用できる。参加ノードは、その参加の見返りとして暗号トークンを受け取る。
コンテンツ所有者が商用 CDN サービスのオプションやコストに満足できない場合は、独自の CDN を作成できます。これはプライベート CDN と呼ばれます。プライベート CDN は、所有者のみにコンテンツを提供する PoP (Points of Presence) で構成されます。これらの PoP は、キャッシュ サーバー[ 20 ] 、リバース プロキシ、またはアプリケーション デリバリー コントローラー[ 21 ]のいずれかになります。2 つのキャッシュ サーバーというシンプルなものから[ 20 ]ペタバイトのコンテンツを配信できるほど大規模なものまであります[ 22 ] 。プライベート CDN が企業ネットワーク内に展開される場合、エンタープライズ CDN またはeCDNとも呼ばれます。
大規模なコンテンツ配信ネットワークでは、キャッシュの場所にコンテンツのコピーを配信するために、独自のプライベートネットワークを構築して設定することもあります。[ 23 ] [ 24 ]このようなプライベートネットワークは通常、プライベートネットワークの容量が不足している場合や、容量低下につながる障害が発生した場合のバックアップオプションとして、パブリックネットワークと併用されます。同じコンテンツを多くの場所に配信する必要があるため、帯域幅の消費を削減するためにさまざまなマルチキャスト技術が使用されることがあります。プライベートネットワークでは、ネットワーク負荷状況に応じてマルチキャストツリーを選択して、利用可能なネットワーク容量をより効率的に利用することも提案されています。[ 25 ] [ 26 ]
ストリーミングビデオトラフィックの急速な増加[ 27 ]により、ブロードバンドプロバイダー[ 28 ]は、この需要を満たし、十分な品質のエクスペリエンスを提供することで加入者を維持するために、多額の設備投資を必要とした。
この問題に対処するため、通信サービスプロバイダーは、ネットワーク基幹への負荷を軽減し、インフラ投資を削減する手段として、独自のコンテンツ配信ネットワークを立ち上げ始めている。
通信事業者のCDNは、動画コンテンツの伝送に利用するネットワークを自社で所有しているため、従来のCDNよりも優位性があります。ラストマイルを自社で管理し、ネットワークの奥深くにコンテンツをキャッシュできるため、エンドユーザーにより近い場所にコンテンツを配信できます。このディープキャッシュにより、動画データが一般的なインターネット上を移動する距離が最小限に抑えられ、より迅速かつ確実に配信されます。
通信事業者のCDNは、従来のCDNが通信事業者から帯域幅をリースし、通信事業者のマージンを自社のコストモデルに組み込む必要があるため、コスト面で有利な点も備えています。さらに、通信事業者は独自のコンテンツ配信インフラストラクチャを運用することで、リソースの利用状況をより適切に管理できます。CDNが行うコンテンツ管理操作は通常、通信事業者と連携またはビジネス関係にある通信事業者のネットワーク(トポロジー、利用状況など)に関する情報がない(または非常に限られた情報しかない)状態で実行されます。これは、通信事業者にとって、これらの操作が自社のリソース利用状況に与える影響に対して、行動範囲が限られているため、多くの課題となります。
対照的に、通信事業者CDNの導入により、通信事業者は独自のコンテンツ管理運用を実施できるようになり、[ 29 ] [ 30 ]これにより、リソースの利用をより適切に制御できるようになり、エンドユーザーにより良い品質のサービスとエクスペリエンスを提供できるようになります。
2011年6月、StreamingMedia.comは、TSPグループがネットワークを相互接続し、世界中に広範なPoPを持つAkamaiやLimelight Networksのような大規模な従来型CDNとより直接的に競合するために、Operator Carrier Exchange(OCX) [ 31 ]を設立したと報じた。このようにして、通信事業者はフェデレーションCDNサービスを構築しており、このフェデレーションの集約されたオーディエンスにコンテンツを配信したいコンテンツプロバイダーにとって、より魅力的なものとなっている。
近い将来、他の通信事業者CDN連合が設立される可能性が高い。これらの連合は、新たに加盟する通信事業者がネットワークプレゼンスとインターネット加入者基盤を既存の連合にもたらすことで成長していくだろう。
Streaming Video Technology AllianceによるOpen Caching仕様は、コンテンツプロバイダーが複数のCDNを使用して一貫した方法でコンテンツを配信できるようにする一連のAPIを定義しており、これらのAPIを通じて各CDNプロバイダーを同じように認識できるようになっています。
複数のCDNサービスを組み合わせることで、コンテンツプロバイダーは単一のCDNサービスに依存することなく、特にライブイベント中のピーク時の視聴者数の増加に対応できます。リストの中から特定のCDNにトラフィックを割り当てる方法はいくつかあり、クライアント側でのCDN選択、サーバー側(コンテンツプロバイダーのオリジンサーバー)、またはクラウド側(コンテンツのオリジンサーバーと視聴者の間)での選択が可能です。CDNの選択基準としては、パフォーマンス、可用性、コストなどが挙げられます。

従来、CDN はクライアントの再帰 DNS リゾルバの IP を使ってクライアントの地理的位置を特定してきました。これは多くの状況で適切なアプローチですが、クライアントが遠く離れた非ローカルの再帰 DNS リゾルバを使用している場合、クライアントのパフォーマンスが低下します。たとえば、クライアントがシンガポールのパブリック DNS リゾルバを使用している場合、CDN はインドのクライアントからのリクエストをシンガポールのエッジ サーバーにルーティングし、そのクライアントのパフォーマンスを低下させる可能性があります。実際、最近の研究[ 32 ]では、パブリック DNS リゾルバが広く使用されている多くの国で、クライアントと再帰 DNS リゾルバ間の距離の中央値が 1,000 マイルにも達することが示されています。2011 年 8 月、Google が主導する主要なインターネット サービス プロバイダーのグローバル コンソーシアムは、DNS 解決応答を正確にローカライズすることを目的とした edns-client-subnet IETFインターネット ドラフト[ 33 ]の公式実装を発表しました。この取り組みには、 Google Public DNS [ 34 ]などの限られた数の主要な DNS サービス プロバイダーと CDN サービス プロバイダーも参加しています。edns-client-subnet EDNS0 オプションを使用すると、CDN は DNS リクエストを解決する際に、要求元のクライアントのサブネットの IP アドレスを利用できるようになります。エンド ユーザー マッピング[ 32 ]と呼ばれるこのアプローチは CDN に採用されており、パブリック DNS やその他の非ローカル リゾルバを使用するクライアントの往復遅延を大幅に削減し、パフォーマンスを向上させることが示されています。ただし、EDNS0 の使用には、再帰リゾルバでのキャッシュ解決の有効性が低下し[ 32 ] 、 DNS 解決トラフィックの総量が増加し[ 32 ]、クライアントのサブネットを公開するというプライバシー上の懸念が生じるという欠点もあります。
仮想化技術は、コンテンツ プロバイダーのコストを削減し、同時に弾力性を高め、サービス遅延を減らすことを目的として、仮想 CDN (vCDN) (ソフトウェア定義 CDN または sd-CDN とも呼ばれる) を展開するために使用されています。vCDN では、仮想キャッシュがプロバイダーの地理的範囲全体に分散された物理サーバーに動的に (仮想マシンまたはコンテナとして) 展開されるため、パフォーマンス、信頼性、可用性などの従来の CDN の制限を回避することが可能です。仮想キャッシュの配置はコンテンツ タイプとサーバーまたはエンド ユーザーの地理的位置の両方に基づいているため、vCDN はサービス配信とネットワークの混雑に大きな影響を与えます。[ 35 ] [ 36 ] [ 37 ] [ 38 ]
パフォーマンスを向上させるために、サーバーからクライアントへの配信には、 WebRTCやWebSocketなどのHTTP以外の代替プロトコルを使用できます。
2017年、GoogleのAddy Osmaniは、レスポンシブWebデザインのパラダイム(特に<picture>要素)と自然に統合できるソフトウェアソリューションをImage CDNと呼ぶようになった。[ 39 ]この表現は、ブラウザまたはサーバー側のロジックによって決定される、リクエスト元のブラウザの特性に応じて、同じ画像の複数のバージョンをHTTP経由で配信できるWebアーキテクチャの機能を指していた。Googleのビジョンでは、Image CDNの目的は、ダウンロード速度を維持しながら高品質の画像(または、より正確には、人間の目で高品質と認識される画像)を配信し、優れたユーザーエクスペリエンス(UX)に貢献することであった。
おそらく、Image CDNという用語は元々は誤称であったと言えるでしょう。なぜなら、当時、Cloudinaryも Imgix (Addy Osmani による 2017 年のガイドで Google が例として挙げているもの) も、古典的な意味での CDN ではなかったからです。 [ 39 ]しかしその後まもなく、開発者がさまざまな戦略に従ってグラフィック アセットの異なるバージョンを配信できるソリューションを複数の企業が提供し始めました。これらのソリューションの多くは、Akamai、CloudFront、Fastly、Edgecast、Cloudflareなどの従来の CDN の上に構築されていました。同時に、すでに画像マルチ配信サービスを提供していた他のソリューションも、CDN 機能をネイティブに提供する (ImageEngine) [ 40 ]か、既存の CDN のいずれかと統合する (Cloudinary/Akamai、Imgix/Fastly) ことで、Image CDN の定義に加わりました。
画像CDNとは何かについて普遍的に合意された定義を提供することは不可能かもしれませんが、一般的に言えば、画像CDNは次の3つのコンポーネントをサポートします。[ 41 ]
次の表は、この分野における主要なソフトウェアCDNの現状をまとめたものです。[ 42 ]