> [!abstract] 概要(abstract の日本語訳) > コンテンツ配信ネットワーク(CDN)は高性能インターネットサービスの配信に不可欠である。世界規模でのフロントエンド展開により、CDN はユーザーを最良のレイテンシと可用性を提供するフロントエンドに誘導できる。主要な課題はクライアントの異種接続性と、レイテンシ・可用性に影響するインターネットの動的性質にある。ユーザー・フロントエンド・外部ネットワーク間の性能に関する継続的な洞察がなければ、CDN は潜在的な性能を十全に発揮できない。われわれはOdin、Microsoftのファーストパーティおよびサードパーティ顧客向けインターネット計測プラットフォームを説明する。Odinは世界中のユーザーからの大規模計測に対するMicrosoftの大規模ユーザーベースと需要を処理するよう設計されている。OdinはMicrosoftのWebクライアントおよびシッククライアントアプリケーションの多様なスイートと統合されており、エンタープライズ顧客の規制・プライバシー上の懸念に配慮する。Odinは2年間運用されてきた。われわれはこの規模と複雑さを持つインターネット計測プラットフォームの初の詳細な研究を提示する。 ## 論文情報 - **タイトル**: Odin: Microsoft's Scalable Fault-Tolerant CDN Measurement System - **著者**: Matt Calder(Microsoft/USC)、Manuel Schröder(Microsoft)、Ryan Gao(Microsoft)、Ryan Stewart(Microsoft)、Jitendra Padhye(Microsoft)、Ratul Mahajan(Intentionet)、Ganesh Ananthanarayanan(Microsoft)、Ethan Katz-Bassett(Columbia University) - **媒体**: NSDI 2018(15th USENIX Symposium on Networked Systems Design and Implementation) - **発表**: 2018年4月9〜11日、ワシントン州レントン - **URL**: https://www.usenix.org/conference/nsdi18/presentation/calder ## 概要 Odinは、MicrosoftのファーストパーティCDN(Bing・Office・Xbox等、100+ PoP)とAzureのDNSリダイレクションCDNを支える大規模インターネット計測プラットフォームである。既存の計測手法(サードパーティ計測基盤・CDNインフラ発のレイヤー3計測・エンドユーザー発のレイヤー3計測・サーバー側計測)はいずれもMicrosoftのCDN運用要件を満たせなかった。Odinはユーザー側アプリケーション層計測とサードパーティCDNへのフォールバック機構を組み合わせることで、代表性・感度・耐障害性・運用適合性の4要件を同時に充足する。 ## 問題設定 CDNが高性能を実現するには、ユーザー・フロントエンド・外部ネットワーク間の性能を継続的に計測し、トラフィック制御・性能デバッグ・展開モデリングに活用する必要がある。課題は: - **クライアントの多様性**: Microsoftユーザーは数万のASに分散し、ISP・接続品質・企業ネットワーク制約が異なる - **インターネットの動的性質**: BGPルーティング変化・輻輳・障害が頻繁に発生する - **可用性の計測困難**: サーバー側計測では到達不能なクライアントの障害を検知できない - **規制・プライバシー制約**: エンタープライズ顧客はFISMA・SOC・ISO等のコンプライアンス要件を課す ## 提案手法 ### アーキテクチャ: Odinの全体像 **Figure 2: Odin アーキテクチャ全体図** ![[_attachments/nsdi18-calder/fig02-odin-architecture.png]] (Figure 2. Odinの計測プロセス。クライアントが設定をダウンロードし計測を実行しレポートをアップロードする。Microsoftネットワークに到達できない場合はサードパーティCDNにフォールバックする。Source: Adapted from Calder et al. 2018.) Odinは4ステップで動作する: 1. クライアントがオーケストレーションサービスから計測設定(JSON)をフェッチ 2. クライアントが設定に従い計測を実行(DNSリゾルーション + 小画像フェッチ) 3. クライアントが計測結果をレポートアップロードエンドポイントへ送信 4. リアルタイムパイプライン(アラート・ネットワーク診断)とオフラインパイプライン(メタデータ付与・ビッグデータ分析)で処理 バックアップパスとして、Microsoftネットワークが到達不能な場合はサードパーティCDNのオーケストレーションサービスにフォールバックし、プロキシ経由でレポートを転送する。 **Figure 1: CDN 一般アーキテクチャ** ![[_attachments/nsdi18-calder/fig01-cdn-architecture.png]] (Figure 1. 多くのCDNの高レベルアーキテクチャ。PoP・フロントエンド・バックボーン・クラウド/内部バックエンドの関係を示す。Source: Adapted from Calder et al. 2018.) ### クライアント計測の設計 **計測の3次元**: HTTP/HTTPS × 直接/DNSベース × ウォーム/コールド **Figure 3: 計測タイプ(直接計測 vs DNS ベース計測)** ![[_attachments/nsdi18-calder/fig03-measurement-types.png]] (Figure 3. Odinの2種類の計測タイプ。計測aはテストドメインを直接計測。計測bはOdinの権威DNSに問い合わせてエンドポイントを解決し、クライアントとLDNSの対応を取得する。Source: Adapted from Calder et al. 2018.) DNSベース計測では、クライアントがランダムID `$(RandID).contoso.com` をLDNS経由で解決する。権威DNSがエンドポイントを返しつつ `$(RandID)` を記録することで、クライアントとLDNSの対応関係を得る。この情報がエニキャストCDN・DNS転送CDNの双方でトラフィック管理に不可欠。 シッククライアント(Office等のデスクトップアプリ)はOdin SDK経由で計測し、低レベルのネットワークエラー(DNS解決失敗・TCP接続タイムアウト等)を区別できる。WebクライアントはJavaScriptで計測し、W3C Resource Timing API対応ブラウザではより精度の高い計測を利用する。 ### オーケストレーションサービス RESTful APIで各クライアントに計測設定JSONを配信する。設定は: - 計測対象エンドポイントリスト(重み付き)と計測数 - レポートアップロードエンドポイント(一次 + バックアップ) - クライアントの地理・AS・接続タイプに応じた動的カスタマイズ 複数の実験を並行実行でき、エンドポイントを計測数より多く指定することでA/Bテスト用の重み付きランダム選択が可能。 ### 耐障害性 **Figure 5: フォールトトレランス経路トポロジ** ![[_attachments/nsdi18-calder/fig05-fault-tolerance-topology.png]] (Figure 5. FE1が到達不能な場合のバックアップ経路トポロジ。クライアントはサードパーティISPのProxy 1またはProxy 2経由でデータセンターフロントエンドFEDCに到達できる。Source: Adapted from Calder et al. 2018.) 3種類の障害シナリオに対する耐障害性: - **相互接続障害**: PoP間の個別リンク障害。バックアップパスはProxy 1経由でデータセンターFEに到達 - **フロントエンド障害**: 特定FEのソフトウェア/ハードウェア障害。データセンターFEへフォールバック - **PoP障害**: PoP全体の障害(稀)。Proxy 2を使い障害PoP経由を回避(実験でPoP共有を3%未満に低減) ### 分析パイプライン - **オフラインパイプライン**: クライアントIPから地域・AS・接続タイプをエンリッチ。LDNS対応を付与。CDN運用の大多数のユースケースで使用 - **リアルタイムアラートパイプライン**: 5分窓でレポートエンドポイントが集計し、地域・ASN別に計測数・失敗率・レイテンシパーセンタイルをストリーミング配信 ## 新規性 | 手法 | 課題 | |------|------| | サードパーティ計測基盤(PlanetLab/RIPE Atlas/Dynatrace/Catchpoint) | Microsoftユーザーの45%以上をカバーできず、/24の12%でも1日10計測未満 | | CDNインフラ発レイヤー3計測(traceroute/ping) | 74%のプレフィックスで応答IPが見つからず、ICMP rate-limitingでアプリ性能を反映しない | | エンドユーザー発レイヤー3計測 | エンタープライズネットワークでICMPをブロックされ、JavaScriptからは実行不可 | | サーバー側計測(TCP/HTTP統計) | 到達不能クライアントの可用性障害を検知できず、外部ネットワーク計測でコンプライアンス上の問題 | Odinはユーザー側でアプリケーション層(HTTP/HTTPS)の計測を行い、上記すべての課題を解消する。特にファーストパーティCDNが自社クライアントから豊富な計測データを得られるという**ファーストパーティアドバンテージ**と、**外部ネットワーク経由のフォールトトレランス**が設計上の差別化点。 ## 実験設定 - **実運用環境**: 2年間にわたるMicrosoftの本番CDN環境 - **計測規模**: 約120エンドポイント、2018年1月に数日間で27億計測(フォールトトレランス評価) - **アプリケーション**: Enterprise1・Consumer1・Consumer2・General1の4種(匿名化) - **比較対象**: 地理情報データベースベースのDNSマップ、エニキャストのみ運用 - **評価期間**: Table 2(2017年5〜6月2ヶ月間)、Figure 10(2017年3〜7月5ヶ月間) ## 実験結果 ### CDN運用ユースケース **DNSリダイレクションマップの低遅延化**: Odinデータから生成したマップを2017年5月に本番適用。スペイン P75 30.68%・Italy 29.92%・Japan 28.14%・Australia 20.05%等、高トラフィック国の大半で P75・P95 ともに改善。Finland 1.56%・Brazil 0.68% のみ P75 でわずかな増加。地理情報マップとの比較では P95 で Odinが65%の時間帯に65ms良好。 **エニキャストパッチ**: エニキャストが60%を最適FEへ送信する一方、20%は最適より25ms以上悪いFEへ送信。Odinで検知しユニキャストパッチを適用、現在は多くの対象クライアントに適用済み(具体的数値は機密)。 **カバレッジ評価**: **Figure 11: アプリケーション別 AS・/24 カバレッジ** ![[_attachments/nsdi18-calder/fig11-coverage-results.png]] (Figure 11. 4アプリの AS と /24 カバレッジ比率。4アプリ合計で AS の98%・/24の85%をカバー。アプリ間の /24 ペアワイズ重複は平均42%にとどまり各アプリが独自のユーザー多様性を提供する。Source: Adapted from Calder et al. 2018.) - 4アプリ合計: AS の98%・/24 の85%をカバー(要件の「/24 で90%・高収益プレフィックスの99%」に近い) - 高収益(エンタープライズリバースプロキシ): 95%、中収益(コンシューマメール等): 91%、低収益: 90% - アプリ間ペアワイズ重複は約42%で、各アプリが独自のユーザー多様性を提供 **フォールトトレランスの実証**: 27億計測のうち約50%がサードパーティプロキシ経由でも同一FEに転送され、フロントエンド障害で消失するリスク。2プロキシをE/W Coast に設置したPoP障害実験ではPoP共有を3%未満に低減(本番スケール展開は将来課題)。 **バックアップパスの利用パターン**: Figure 9: 深夜帯にバックアップ利用率が増加(昼間:高品質企業ブロードバンド、深夜:低品質家庭用ブロードバンドが主体)。Brazil はピーク時にドイツの3〜4倍のバックアップ率。 ### 地域エニキャストの性能影響 P50での劣化は約2%、P75は約3%で5ヶ月間安定。P90・P99は5月以降上昇傾向があり、静的リージョン設定が高パーセンタイルで経時劣化する可能性を示す。 ## 考察 - DNSリダイレクションの運用実態として: (1) ユーザー接続のメトリクス計測が単一の主要入力として十分であり多種計測の複雑な組み合わせは不要、(2) LDNSの地理的・ネットワーク位置は良好なリダイレクションの品質に影響しない、(3) EDNS Client Subnet(ECS)は大手パブリックリゾルバ以外でほぼ採用されていない - エニキャストの弱点(循環ルーティング・遠隔FEへの送信)はBGPの性能盲目性に起因し、DNS転送との複合で補完可能 - PoP障害へのフォールトトレランスは現プロトタイプでは限定的。地理的に分散したプロキシを増やす必要がある ## 強み / 弱点・課題 **強み**: - ファーストパーティアプリへの計測クライアント埋め込みによる代表性の高いカバレッジ - アプリケーション層(HTTPS)計測でエンタープライズネットワーク制約を回避 - サードパーティCDNフォールバックによる耐障害性(計測の最も価値あるケースを保全) - 多実験並行実行と実験設計の柔軟性 **弱点・課題**: - PoP障害への完全なフォールトトレランスは将来課題 - WebクライアントはJavaScriptの制約で低レベルエラーを区別できない - 計測は能動的であり、エンドユーザー体験に影響を与えないよう計測レートを管理する必要がある - 高収益プレフィックスの99%カバレッジを論文内では達成報告していない