配信の最適化のテスト
概要
配信の最適化は、企業が Microsoft コンテンツをダウンロードするための帯域幅使用量を管理するのに役立つ強力で便利なツールです。 これは、多数のデバイス、さまざまなコンテンツ サイズなどの大規模な環境で使用するように設計されたソリューションです。配信の最適化は、現在サポートされているバージョンの Windows にネイティブであり、一般的な顧客環境を最大限に活用するための既定の構成を提供します。 配信の最適化は、さまざまな種類のコンテンツを配信するために使用されるため、Microsoft のお客様は環境に最適なダウンロード エクスペリエンスをお楽しみください。 配信の最適化には、次の 3 つのコンポーネントがあります。
- HTTP ダウンローダー。
- ピアツーピア (P2P) クラウド テクノロジ。
- Microsoft Connected Cache。
配信の最適化を使用する最も強力な利点の 1 つは、ユーザーが特定の環境のニーズを満たすために Microsoft コンテンツ配信でダイヤルできるようにする設定を微調整できることです。
結果の監視
配信の最適化は既定でオンになっているので、配信の最適化 PowerShell コマンドレットを使用して Windows の [配信の最適化] の [Windows 設定] を使用するか、Azure のビジネス レポートのWindows Updateを使用して値を監視できます。
お使いの環境で配信の最適化が機能しない場合は、問題の根本に到達するために調査することが重要です。 配信の最適化が適切に動作していることを確認するために、一般的なデバイスを簡単に評価するためのテスト環境を作成することをお勧めします。 まず、2 台のマシン間での配信の最適化の使用をテストするために、"シナリオ 1: 基本セットアップ" を作成する必要があります。 このシナリオは、環境内のノイズを排除して、配信の最適化がデバイスで動作することを妨げるものがないことを確認するように設計されています。 ベースラインを作成したら、テスト環境を拡張して、より高度なテストを行うことができます。
期待とGoals
この記事のテスト シナリオの焦点は、主に、P2P を使用したバイトの正常なダウンロードを中心とした配信最適化ポリシーのデモンストレーションに焦点を当てています。 具体的には、次の条件を使用して、ピアツーピアが期待どおりに動作していることを示す目標です。
- ピアは互いを見つけることができます (たとえば、同じ LAN/サブネット/グループで 、"ダウンロード モード" ポリシーに一致します)。
- ファイルは、"ダウンロード モード" ポリシー設定でダウンロードされます (DO クラウド、HTTP、およびローカル構成への接続を検証します)。
- P2P 経由で少なくとも一部のダウンロードが行われている (ピア間の接続を検証します)。
配信の最適化を使用して、ピアリング全体に影響を与えるいくつかの要素。 最も一般的で影響を与える環境要因を考慮する必要があります。
- キャッシュ内のファイルの数とデバイスの数は、全体的なピアリングに大きな影響を与えます。各クライアントから一度にピアリングに使用できるファイルの数が設定されているため、ピアリング デバイスが特定のファイルを提供していない可能性があります。
- ファイル サイズとインターネット接続の信頼性が重要です。 P2P を使用する最小ファイル サイズを決定するための配信の最適化設定があります。 さらに、インターネット接続は、配信最適化クライアントがクラウド サービス API 呼び出しを行い、ファイルのダウンロードを開始する前にメタデータ ファイルをダウンロードできるように、十分にオープンで信頼性が高い必要があります。
- 配信の最適化ポリシーが役割を果たすことができます。 一般に、配信の最適化の設定と既定の配信の最適化に関するリファレンスを理解することが重要です - Windows 展開 |Microsoft Docs..
配信の最適化はハイブリッド P2P プラットフォームです
複数のソース (HTTP とピア) から並列にダウンロードする配信の最適化のハイブリッド アプローチは、コンテンツを配信する最適なソースを常に評価する大規模な環境では特に重要です。 また、参加しているデバイス間でのコンテンツ キャッシュの分散は、より多くのピアが利用可能になると、配信の最適化で帯域幅の節約を見つける能力に貢献します。
ダウンロードが開始された時点で、配信最適化クライアントは HTTP ソースからのダウンロードとピアの検出を同時に開始します。 ファイルが小さい場合、ピアが使用可能であっても、ピアに接続する前に HTTP ソースからほとんどのバイトをダウンロードできます。 ファイルと品質の高い LAN ピアが大きい場合、HTTP 要求率は 0 に近くなりますが、HTTP からの最初の要求を行った後にのみ低下する可能性があります。
次のセクションでは、2 つのテスト シナリオによって、HTTP ピアとピアからのバイト数が異なる結果がどのように生成されるかを確認します。 これらのシナリオでは、コンテンツのダウンロード元となる最適な場所を継続的に評価する配信の最適化が示されます。
テスト シナリオ
シナリオ 1: 基本的なセットアップ
目標： 制御されたテスト環境で 2 台のマシンを使用して配信の最適化ピア ツー ピア テクノロジがどのように機能するかを示します。
予想される結果: マシン 1 はピアから 0 バイトをダウンロードし、マシン 2 はピアから 50 から 99% をダウンロードします。
テスト マシンのセットアップ
| セットアップ チェックリスト | 値/説明 |
|---|---|
| 使用されたマシンの数 | 2 |
| Virtual Machines/物理デバイス | 2 |
| Windows OS のバージョン | Windows 10 (21H2) と Windows 11 (21H2) |
| RAM | 8 GB |
| ディスク サイズ | 127 GB |
| ネットワーク | 同じネットワーク (企業ネットワークを代表するネットワーク) に接続されています。 |
| Windows 更新を一時停止する | これにより、テスト環境が制御され、テスト中に他のコンテンツが利用できなくなるため、テストの結果が変更される可能性があります。 問題が発生し、ピアリングが発生しない場合は、最初のマシンで 'Get-DeliveryOptimizationStatus' を使用して、接続されているピアのリアルタイム リストを返します。 |
| すべてのストア アプリが最新の状態であることを確認する | これにより、テスト中に新しい予期しない更新プログラムがダウンロードされるのを防ぐことができます。 |
| 配信の最適化 'ダウンロード モード' ポリシー | 2 (グループ)(各マシンに設定) |
| 配信の最適化 'GroupID' ポリシー | 各テスト マシンで 同じ 'GUID' を設定します。 GUID は必須の値であり、PowerShell '[guid]::NewGuid().' を使用して生成できます。 |
| Windows 11デバイスで必要なのは、配信の最適化 'ピアの選択を制限する' ポリシーのみを設定する | 0 NAT (各マシンに設定)。 Windows 11の既定の動作は、'2-Local Peer Discovery' に設定されています。 テスト目的で、これは NAT にスコープを設定する必要があります。 |
テスト手順
マシンごとに次の一連の手順が使用されます。
- PowerShell コンソールを "管理者" として開きます。
- DO キャッシュ 'Delete-DeliveryOptimizationCache' をクリアします。
- 'Get-DeliveryOptimizationStatus' を実行します。
- MS ストアを開き、"アスファルト凡例 9" を検索します。 [ 取得 ] を選択してコンテンツのダウンロードを開始します (コンテンツ サイズ: ~3.4 GB)。
マシン #1
- 'Test Instructions' を実行する
| Windows 10 | Windows 11 |
|---|---|
|
|
| 計測結果 | |
| コンテンツをダウンロードする最初のコンピューターにピアが見つかりませんでした。 'TotalBytesDownloaded' はファイル サイズと同じです。 状態はコンテンツを "キャッシュ" に設定して、将来のピアがコンテンツを使用できるようにします。 ダウンロードがフォアグラウンドで行われました。 DownloadMode が 'Group' に設定され、ピアが見つかりませんでした。 ウィンドウ 10 と Windows 11 デバイスの間に個別の観察は表示されません。 |
5 分待ちます。
コンピューター #2
- 'Test Instructions' を実行する
| Windows 10 | Windows 11 |
|---|---|
|
|
| 計測結果 | 計測結果 |
| コンテンツのピアが見つかり、合計バイトの 87% がピアから取得されました。 1 つのピアがコンテンツに対して検出されました。これは、ピアリング グループに 2 つのデバイスしかないと予想されます。 ダウンロード モードは "グループ" に設定されましたが、グループ モードには LAN デバイスとグループ デバイスの両方が含まれるため、検出された場合は配信の最適化によって LAN ピアが優先されます。 したがって、'BytesFromLanPeers' は、'BytesFromGroupPeers' が表示されないバイトを示します。 "DownloadDuration" は、マシン間でほぼ同じです。 |
コンテンツのピアが見つかり、合計バイトの 90% がピアから取得されました。 その他のすべてのポイントは、Windows 10結果と同じです。 |
シナリオ 2: 事前セットアップ
目標： 配信最適化ピア ツー ピア テクノロジが制御されていない環境でどのように機能し、3 台のマシンに拡張されるかを示します 。マシン 1 はピアから 0 バイトをダウンロードし、Machine 2 はピアを見つけ、ピアから 50 から 99% をダウンロードします。 マシン 3 は 2 つのピアを見つけ、ピアから 50 から 99% をダウンロードします。
テスト マシンのセットアップ
| セットアップ チェックリスト | 値/説明 |
|---|---|
| 使用されたマシンの数 | 3 |
| 仮想マシン | 3 |
| Windows OS のバージョン | Windows 10 (21H2) |
| RAM | 8 GB |
| ディスク サイズ | 127 GB |
| ネットワーク | 同じネットワーク (企業ネットワークを代表するネットワーク) に接続されています。 |
| 配信の最適化 'ダウンロード モード' ポリシー | 2 (グループ)(各マシンに設定) |
| 配信の最適化 'グループ ID' ポリシー | 各テスト マシンで 同じ 'GUID' を設定します。 GUID は必須の値であり、PowerShell '[guid]::NewGuid().] を使用して生成できます。(https://devblogs.microsoft.com/scripting/powertip-create-a-new-guid-by-using-powershell/)'。 |
| 配信の最適化 'http からのバックグラウンド ダウンロードの遅延' ポリシー | 60 (各マシンに設定) |
| 配信の最適化 'http Policy からのフォアグラウンド ダウンロードの遅延 | 60 (各マシンに設定) |
テスト手順
マシンごとに次の一連の手順が使用されます。
- DO キャッシュ 'Delete-DeliveryOptimizationCache' をクリアします。
- MS ストアを開き、"アスファルト凡例 9" を検索します。 [ 取得 ] を選択してコンテンツのダウンロードを開始します (コンテンツ サイズ: ~3.4 GB)。
- 管理者として PowerShell コンソールを開きます。 'Get-DeliveryOptimizationStatus' を実行します。
マシン #1:
- 'Test Instructions' を実行する
出力: Windows 10 (21H2)
計測結果
- デバイスのグループ内の最初のダウンロードでは、HTTP から送信されるすべてのバイト 'BytesFromHttp' が表示されます。
- ストア アプリはストア アプリ内のユーザーによって開始されるため、ストア アプリがデバイス上でダウンロードを実行し、フォアグラウンドで実行しているため、ダウンロードは "フォアグラウンド" になります。
- ピアが見つかりません。
5 分待ちます。
マシン #2:
- 'Test Instructions' を実行する
出力Windows 10 (21H2)
計測結果
- 'PercentPeerCaching' は 99.8% です
- まだ 'BytesFromHttp' ソースが使用されています
- 1 つのピアが見つかりました
- "BytesFromLanPeers" で示されているように、すべてのピアリングは LAN 上のデバイスから行われました
マシン #3:
- 'Test Instructions' を実行する
出力: Windows 10 (21H2)
計測結果
- 'PercentPeerCaching' は、マシン #2 とほぼ同じ 99.7% です。
- これで、2 つのピアが見つかりました。
- 'BytesFromHttp' の値で見られるように、HTTP ソースからまだダウンロードしています。
テスト グループ内のすべてのマシンのピア ソーシング監視
配信最適化テクノロジの分散特性は、各テスト マシンで 'Get-DeliveryOptimizationStatus' コマンドレットを再実行すると明らかです。 それぞれに、'BytesToLanPeers' フィールドに新しい値が設定されます。 このテストでは、使用可能なピアが増えるにつれて、バイトのダウンロード要求がピアリング グループ全体に分散され、ピアリング コンテンツのソースとして機能することを示します。 各ピアは、他方をサービスする役割を果たします。
出力： マシン 1
マシン 1 から提供される 'BytesToPeers' は '5704426044' です。 これは、グループ内の 2 つのピアによってダウンロードされた合計バイト数を表します。
出力： マシン 2
マシン 2 から提供される 'BytesToPeers' は '1899143740' です。 使用可能なバイトを持つピアがグループに 2 つある場合は、バイトの分布がマシン 1 またはマシン 2 のいずれかであることに注意してください。
出力： マシン 3
マシン 3 から提供される 'BytesToPeers' は '0' です。 これは、他のピアがこのピアからバイトをダウンロードしていないことを意味します。これは、グループ内の最後のマシンであるために予想されます。
まとめ
配信の最適化を使用すると、帯域幅を最適化するためにお客様の環境に大きな影響を与えることができます。 ピアツーピアテクノロジは、あらゆるorganizationに柔軟に対応できるように設計された多くの構成を提供します。 配信の最適化では、さまざまなソースにまたがる分散キャッシュを使用して、各デバイスで使用されるリソースを制限しながら、最適なダウンロード エクスペリエンスを確保します。
このドキュメントに記載されているテスト シナリオは、制御されたテスト環境を示すのに役立ち、更新によってピアリングの結果が中断されるのを防ぐことができます。 もう 1 つの実世界のケースでは、ピア間で使用できるコンテンツをコンテンツのソースとして使用する方法を示します。
テスト中に問題が見つかった場合、配信の最適化 PowerShell コマンドレット は、環境内で何が起こっているかを説明するのに役立つツールです。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示