コンテンツ配信ネットワーク

# コンテンツ配信ネットワーク ## 定義コンテンツ配信ネットワーク(Content Distribution Network, CDN)は、地理的に分散した「サロゲートサーバ(surrogate server)」の集合により、バックエンドサーバが保持するページを複製・キャッシュして配信するシステムである。CDNが解決しようとするのはWebページ取得における4つのボトルネック——(1) first mile(クライアントの下り帯域)、(2) last mile(サーバの上り帯域)、(3) サーバ自体の有限な計算資源、(4) peering point(ISP間の相互接続点の帯域制約)——のうち、first mile以外の3つである。サロゲートサーバはバックエンドサーバから静的コンテンツをプロアクティブに複製し、動的コンテンツ(スポーツのスコアやデータベースクエリの結果等)はバックエンドサーバへ問い合わせる。Akamaiは代表的な商用CDNの一つである。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.4.3) CDNを構成するもう一つの要素が「redirector」であり、クライアントのリクエストを最適なサロゲートサーバへ振り分ける。redirectorの目的は主に(a) クライアントごとの応答時間(response time)の最小化と、(b) システム全体としてのスループット最大化の2つであり、両者は完全には両立しない。redirectionの実装機構は大きく3種類ある。(1) DNSベースのリダイレクト(クライアントが`www.cnn.com`を解決する際に負荷の軽い/近いサーバのアドレスを返す。ラウンドロビンも可能。granularityはサイト単位に限られるが、埋め込みリンクのURL書き換えで個別オブジェクト単位のリダイレクトを補える)、(2) HTTPリダイレクト(サーバ自身が別サーバへ誘導するが、追加のラウンドトリップとサーバ負荷を招く)、(3) 近傍ノード(ローカルWebプロキシ等)によるリクエストの傍受。商用CDNはDNSベースのリダイレクトとURL書き換えを組み合わせ、地域レベルのDNSサーバがTTLを数十秒程度に短縮することで負荷変動に素早く追随する。(Source: ch.9 §9.4.3) redirectorの割り当てポリシーには、ラウンドロビン/ランダム(負荷分散には優れるが局所性を無視しキャッシュ効率を下げる)と、[[一貫性ハッシュ法]]によるURL/サーバのハッシュ値近接割り当て(局所性を保ちつつサーバ増減時の再配置を局所化する)がある。CARP(Cache Array Routing Protocol)は一貫性ハッシュ法をさらに拡張し、URLとサーバアドレスの組をハッシュしたスコアを降順に並べ、負荷が閾値未満の最上位サーバへ動的に割り当てることで、静的な最近傍割り当てとサーバ負荷分散を両立する。ネットワーク近接性は、応答時間を「負荷」の代理指標として使う方法と、候補サーバ集合を近傍のものに絞る方法の2通りで組み込める。(Source: ch.9 §9.4.3) ## 横断的知見 - **ch.9が抽象的に説明するDNSベースのredirectionは、2018年のMicrosoft Odinにおいて「LDNSのIPアドレスごとに各リージョンへの中央値レイテンシを計算しDNSマップを生成する」という具体的な計測パイプラインとして実装されている**: 本ページの定義は、DNSサーバが「負荷の軽い/近いサーバのアドレスを返す」という機能をブラックボックスとして説明するにとどまり、その入力データをどう集めるかには立ち入らない。[[CDN計測システム]]が扱うOdin([[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]])は、まさにこの「どのサーバを返すべきか」という判断のための実測レイテンシデータを、ファーストパーティアプリに埋め込んだ計測クライアントから収集し、LDNS(Local DNS)のIPアドレス単位でAzureリージョンごとの中央値レイテンシを計算してDNSマップを生成するパイプラインとして具体化する。ch.9が「地域レベルのDNSサーバがTTLを短く設定して負荷変動に追随する」と述べる部分についても、Odinは基準障害率0.1%からの変化(0.1%→0.2%)を検知するには700計測が必要という定量的な感度の限界を示しており、教科書が述べない「リダイレクト判断の入力データをどれだけの頻度・精度で更新できるか」という運用上の制約を補う。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.4.3, [[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]]) - **ch.9が挙げる「peering pointのボトルネック」というCDNの存在理由は、[[クラウドコンピューティング]]が記録する主要クラウド事業者のIXP近傍データセンター配置と同じ問題意識を共有するが、対処のレイヤーが異なる**: ch.9はCDNの動機の一つとして「ISP間のpeering pointは内部的には高帯域でも、相互のピアに高容量の接続を提供する動機に乏しい」ことを挙げ、サロゲートサーバを各バックボーンISP内に分散配置することでpeering pointの通過自体を避けようとする。[[クラウドコンピューティング]]concept が記録する[[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] Perspectiveの知見では、クラウド事業者が世界150以上のIXP近傍にデータセンターを配置し、拠点間を自前のプライベートバックボーンで接続することで、パブリックインターネット(とそのpeering point)を経由しない経路を確保している。両者はいずれも「peering pointの通過を避けて配置を最適化する」という同じ解法をとるが、CDNはコンテンツのキャッシュ配置(何をどこに置くか)によって、クラウド事業者のプライベートバックボーンは物理接続そのもの(どう繋ぐか)によって、この問題に対処している。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.4.3, [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] Perspective) - **ch.9が示す実務者の一次資料は、教科書(ch.9のSystems Approach)が動機として挙げる「peering pointのボトルネック」ではなく、契約帯域そのものの逼迫という、より直接的な理由でCDNを導入した実例である**: 本ページの定義は、CDN導入の動機を first mile/last mile/サーバの計算資源/peering pointという4つのボトルネックの整理として説明する(Systems Approach ch.9 §9.4.3)。これに対し『ウェブオペレーション』9章(2011年)が報告する dealnews.com の実例は、2006年のYahoo! 経由トラフィック急増で「データセンタの帯域幅は100Mbit/sだったが80Mbit/sまで上昇していた」という、契約帯域の上限に迫る具体的な逼迫を経験し、その解決策として画像・JavaScript・CSSをCDNへオフロードした。教科書がpeering pointという抽象的なインターネット構造上のボトルネックを動機として説明するのに対し、実務例は「自社が契約している帯域幅そのものが尽きかけた」という、より単純で具体的な動機を示しており、両者は同じCDN導入という結論に、抽象度の異なる理由付けから至っている。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.4.3, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 9 予期しないトラフィック急増への対応]] §9.6) - **ch.9(Systems Approach)がCDNの機構(redirection・キャッシュヘッダによる保持)を説明するのに対し、『ウェブオペレーション』9章はCDN導入後に運用者が直面する具体的な代償を報告する**: 『ウェブオペレーション』9章は、CDN導入の欠点として「データのコントロールを失う」ことを挙げる。CDNは期限が切れるまで新しいファイルを要求しないため、ファイルを変更したり同じ名前のファイルを再アップロードしたりできない。また、タイムアウトの時間を30分未満に短く設定すると、リクエストにばらつきが生じるという運用上の制約も報告する。本ページの定義部分はCDNが「バックエンドサーバが渡したキャッシュヘッダを見てコピーを保持する」という機構は説明するが、この保持期間の設定が短すぎた場合に何が起きるかという運用上の失敗モードには触れておらず、『ウェブオペレーション』9章の実務報告がこの欠落を補う。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.4.3, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 9 予期しないトラフィック急増への対応]] §9.6) ## 未解決の問い - CARPのようなハッシュベースのredirectionポリシーと、Odinのような実測レイテンシに基づくDNSマップ生成は、同一のCDNシステム内でどう組み合わされるべきか。ch.9はアルゴリズムを、Odinは計測パイプラインを独立に説明しており、両者を統合した設計は本wikiではまだ扱われていない。 - ch.9は「動的コンテンツはバックエンドサーバへ問い合わせる」と単純化するが、今日のCDNはエッジコンピューティング(サロゲートサーバ側での計算実行)を提供することが多い。この変化は本ページではまだ扱われていない。 - redirectorの応答時間最小化とスループット最大化のトレードオフは、ch.9では定性的に述べられるにとどまる。定量的な最適化(例えば混雑時のサーバ選択アルゴリズムの評価)を扱う文献の追加ingestが必要。 ## 関連 - ソース: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]](§9.4.3 CDNのメカニズムとポリシー) / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 9 予期しないトラフィック急増への対応]](§9.6 CDN導入の実務的な動機と代償) - 概念: [[CDN計測システム]](Odinによる実測ベースのDNSリダイレクション最適化) / [[一貫性ハッシュ法]](CARP・単純な一貫性ハッシュによるサーバ割り当て) / [[オーバーレイネットワーク]](隣接する概念だがredirectorによる間接転送を使う点で異なる) / [[エニキャストルーティング]] / [[クラウドコンピューティング]](peering point回避というIXP配置の問題意識の共有) ## 出典 - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 9: Applications, §9.4.3 Content Distribution Networks. https://book.systemsapproach.org/applications.html - [[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]](DNSリダイレクション最適化の実装、計測不感度の定量化) - ブライアン・ムーン, 「9章予期しないトラフィック急増への対応」, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, §9.6(CDN導入の実務的動機と、コンテンツ制御・タイムアウト設定という代償)。