企業内ストリーミングにおけるネットワーク構築

Microsoft Corporation

December 10, 2001
日本語版最終更新日 2002年1月22日

概要

はじめに

シナリオ

手動分散の仕組み
オンデマンドコンテンツ
ブロードキャストコンテンツ
キャッシングプロキシサーバーの仕組み

キャッシングプロキシソリューションの実装
参考資料

概要

エンタープライズにとって、メディアをストリーム配信する上で最も大きな問題となるのは、通常、社内ネットワークの帯域幅の管理方法の決定です。この資料では、ネットワークの規模や容量に関係なく、エンドユーザーにメディアをストリーム配信するためのソリューションについて説明します。多くの場合、その解決策は、より大きな帯域幅とコンテンツの集中化に対応したネットワークの再構築ではなく、既存のネットワークをそのまま維持し、エッジサービングと呼ばれるプロセスを使用してコンテンツをエンドユーザーの近くに移動します。

はじめに

どのような規模の企業でも、社内のコミュニケーション（社員への週間発表からトレーニングまで）を強化するために、デジタルメディアを使用しています。Microsoft® Windows Media™ テクノロジは、社内全体のデスクトップに音声と映像を配信する手段です。ダウンロード用にデジタルメディアコンテンツを設計するのは簡単です。しかし、Windows Mediaテクノロジには、ストリーム配信用のデジタルメディアも作成できるという利点があります。企業はコンテンツを、オンデマンドファイル（ユーザーが再生を制御する）として作成するか、あるいはブロードキャスト（コンテンツは通常ライブイベントで、配信元が再生を制御する）として作成できます。どちらの場合も、デジタルメディアコンテンツは通常、サーバー上で実行される Windows Media Services と同様に、中央からユーザーにストリーム配信されます。ユーザーが Windows Media Player を使用してサーバーに接続すると、オンデマンドまたはブロードキャストストリームが、社内ネットワークまたはインターネットを通じてそのサーバーからプレイヤーに配信されます。

この資料は、社内ネットワークを通じたメディアのストリーム配信の改善方法を探しているITの専門家やコンテンツ製作者向けに作成されています。数千に及ぶストリームを、エンタープライズのどの場所にいるエンドユーザーにも配信できるのが、理想的なストリーミングシステムです。たとえば、ダラス支社やアトランタ支社にいる社員が、CEO のブリーフィングを、シカゴの本社にいる社員と同時にライブで見ることができます。メディアのストリーム配信は、広範囲の相手との音声および映像による瞬時のコミュニケーションを約束します。しかし実際には、メディアのストリーム配信システムは、通常、理想に過ぎません。エンタープライズの規模に関係なく、実装の最も大きな障害となっているのは、通常ネットワークインフラです。

ストリーム配信の質は、ネットワークの品質と帯域幅に依存しています。次の図は、多くのエンタープライズのストリーミングネットワークの問題点を示しています。

この例では、シカゴの本社にある Web サーバーと Windows Media サーバーから、エンタープライズネットワークのすべてのセクタにコンテンツが配信されます。シカゴの高速のローカルエリアネットワーク（LAN）上にいるユーザーは、内部のサーバーやインターネットに迅速にアクセスできますが、残念ながら、ダラスやアトランタにいるユーザーは、比較的遅く、信頼性の低い、ISDN や DSL 接続を共有して、広域ネットワーク（WAN）を通じてアクセスしなければなりません。また、さらに小規模の支社にいるユーザーは、電話モデムから PPTP（Point-to-Point Tunneling Protocol）などの技術を使用して、インターネットを通じて接続する場合もあります。シカゴの LAN 上では 2 秒でブラウザに表示できる Web ページも、アトランタやボンベイでブラウザに表示するには、15 秒かかる場合があります。

低速のネットワーク接続では、Web ページなどの静的コンテンツがダウンロードされるまで待つのも不快に感じることがありますが、そのようなネットワークでストリームを再生するのは、困難あるいは不可能な場合すらあります。さらに、ネットワークのあらゆるセクタからストリーミングメディアに対する要求が殺到すると、すぐに帯域幅が消費され、サーバーは過負荷状態になり、すべてのユーザーの使用の快適さが低下します。

エンタープライズでストリーミングメディアを使用してコミュニケーションを行うことの価値に疑問を持つ人は少ないでしょう。CD-ROM、ビデオテープ、または衛星を使用した音声や映像の配信に比べ、ストリーム配信は、費用も格段に安く、リソースを消費しません。しかし、ネットワーク内に存在する低速で信頼性の低いWANや帯域幅の制限などの障害によって、エンタープライズはより効果の低いソリューションに依存しなければならない場合があります。デジタルメディアを効果的にストリーム配信するためには、インフラ全体を高帯域幅のネットワークにアップグレードするしか解決策がないとすれば、その費用だけでも受け入れ難いものになります。しかし、今日では、大規模で高価な、リソースを消費するアップグレードを行わなくても、エンタープライズの既存のネットワークを通じてオンデマンドおよびブロードキャストストリーミングメディアを配信するソリューションがあります。エッジサービングと呼ばれるこのソリューションでは、すべてのコンテンツを1か所の集中したポイントから高価な高帯域幅のネットワークを通じて配信するのではなく、エンタープライズ全体に複数のサーバーを分散させて設置し、エンドユーザーがいるネットワークの末端（エッジ）の近くにコンテンツを移動します。

この資料では、オンデマンドとブロードキャストの両方のストリーミングメディアコンテンツを分散させ、エッジの近くに移動する 2 つの方法について説明します。

シナリオ

デジタルメディアコンテンツをストリーム配信するためのネットワークインフラには、集中型ネットワークと分散型ネットワークの 2 つの設計方法があります。集中型のネットワークでは、ストリーミングメディアは 1 か所の単一のサーバー、あるいは負荷分散サーバーのグループから、ネットワーク上のすべてのクライアントに配信されます。このシステムを正常に稼動させるには、ストリームを受信するすべてのクライアントと中央のサーバーを結ぶ接続を良好に維持するための帯域幅と安定性がネットワーク全体に必要となります。集中型のネットワークは、管理は容易ですが、高帯域幅のインフラを維持するためには、多くの企業にとって受け入れ難い費用が必要となります。集中型のソリューションは、同時に配信されるストリームの数が少なく、ネットワークが単一の建物の中だけの場合に適しています。たとえば、予定されている最大使用率が、単一の 100 Mbps LAN を通じた 50 件の 100 Kbpsストリームの場合には、集中型のソリューションで問題ありません。同時使用率が最大のときでも5 Mbpsしか消費されないため、Windows Media Services を実行するための要件を満たしている最低限のサーバーでも、この負荷であれば容易に処理できます。

しかし、大規模な WAN を通じて数千のストリームを同時に配信しなければならない複数の LAN が、数百キロメートル以上離れた複数の場所に広がっているような大規模なエンタープライズでは、分散型の方が適しています。この方法では、たった 1 つの配信元のサーバーと、大規模で高速な、信頼性の高いネットワークインフラに依存するのではなく、エンドユーザーに近い、ネットワークのエッジに配置された複数のサーバーにコンテンツをコピーします。通常、エッジサーバーは、セグメント内のクライアントと高帯域幅で接続されている LAN セグメント内に配置されます。ネットワークを分散すると、ネットワーク内の単一のセクションに多数の同時ストリームの負荷が集中することはなくなり、複数のサーバーに負荷が分散されます。また、分散型のシステムには、非常に高い拡張性があります。たとえば、既存のネットワークにほとんど影響することなく、支社を追加できます。

このセクションでは、ストリーミングメディアコンテンツを分散するための 2 つのシナリオ（手動分散とキャッシングプロキシサーバー）について説明します。どちらの方法も、どのようなネットワークでも使用できますが、手動分散はストリーミングメディアの使用率が低～中程度のエンタープライズに適しています。ストリーミングメディアの使用率が中～高程度の場合は、キャッシングプロキシサーバーを使用すればネットワーク管理が非常に容易になります。

手動分散の仕組み

手動分散では、管理者がオンデマンドおよびブロードキャストコンテンツを、エンタープライズ全体に配置された複数の Windows Media サーバーからストリーム配信されるように構成します。

中央の配信元の Windows Media サーバーから、コンテンツはローカル LAN を通じて配信され、ブロードキャストストリームはリモートの Windows Media サーバーに分散されます。オンデマンドおよびブロードキャストコンテンツの構成とコピーは、管理者が管理します。

オンデマンドコンテンツ

サーバー管理者は、オンデマンドファイルとそのファイル構成を、配信元のサーバーからすべてのリモートサーバーにコピーします。管理者は、このコピープロセスを手動で実行するか、ファイル管理プログラムを使用して、定期的に、または新しいコンテンツの追加時にファイルをリモートサーバーにコピーできます。ファイルのストリーム配信を受けるには、ユーザーは最寄りのエッジサーバーに接続します。たとえば、ダラスのエンドユーザーには、ダラスの Windows Media サーバーからデジタルメディアコンテンツがストリーム配信されます。

当然のことながら、手動分散を行うには、エッジサーバーが配置されている LAN セグメントがそのセグメント内のクライアントと高帯域幅で接続されている必要があります。幸い、ほとんどのイーサネットベースの LAN には、十分に高い 10 Mbps または 100 Mbps の帯域幅があります。コンテンツをエンドユーザーの近くに移動すると、WAN を迂回できます。低速で、費用も高いことが多い WAN 接続に依存せずにストリーム配信を行うことで、組織全体のユーザーが同じコンテンツをそのストリームが消費する帯域幅を気にせずに見ることができ、エンタープライズは、高い費用をかけて WAN の帯域幅をアップグレードする必要がなくなります。ダラスとシカゴの間の WAN 接続がストリーム配信を処理するには遅すぎる場合でも、ダラスのエンドユーザーは、シカゴ本社のユーザーが見ているのと同じ100 Kbpsのオンデマンドファイルを見ることができます。

コピープロセスを自動化する場合、必要であれば、このプロセスを夜間に行うように構成できます。たとえば、火曜日の午後に作成された映像は、その夜コピーされ、水曜日の朝にはオンデマンドファイルとして会社全体のユーザーが再生できます。

ネットワーク上のどのクライアントでも、ファイルのパスは同じになります。変わるのは、サーバー名だけです。たとえば、シカゴの Windows Media サーバーとダラスの Windows Media サーバーの場合、ファイルの URL は次のようになります。

mms://WindowsMediaServerChicago/DailyReports/Tuesday.wmv

mms://WindowsMediaServerDallas/DailyReports/Tuesday.wmv

電子メールによる日報にそれぞれのロケーションの Windows Media メタファイルの URL を記載したり、もっと簡潔なソリューションを作成したりすることもできます。たとえば、電子メールにエンドユーザーのコンピュータに保存されている Cookie を使用するイントラネット Web サーバー上のアクティブサーバーページ（ASP）へのリンクを記載し、Windows Media メタファイル（http://go.microsoft.com/fwlink/?LinkId=880）とそのコンテンツの正しい URL を戻すようにすることができます。

オンデマンドコンテンツの手動分散の実装にかかるコストは、高帯域幅をサポートするようにネットワークインフラ全体をアップグレードすることに比べると、非常にわずかです。このソリューションは拡張性が高く、また、コンテンツがエンドユーザーの近くにあるため、単一のロケーションのホストにあるコンテンツを多くのロケーションの多くのユーザーが共有する場合より、エンドユーザー側の快適さが向上します。

手動分散の最も大きな欠点は、ファイルのコピーに一定の時間とリソースが必要になることです。コピープロセスを自動化する場合や、その会社のストリーミングデジタルメディアの使用率が比較的に低い場合には、この欠点は問題ではありません。しかし、ハードディスクの多くの記憶域を必要とする、数十万個のオンデマンドファイルのアーカイブを維持しなければならない場合には、手動分散は適していません。

もう一つの欠点は、遠隔地ごとに異なる URL をユーザーに通知しなければならない点です。リモートサーバーが 3～4 個の場合には問題ではありませんが、数百個のリモートサーバーを所有する大規模な組織には、透過的に URL のプロキシを行うソリューションが必要です。次のセクションで説明するキャッシングプロキシサーバーは、これらの欠点を両方とも解決します。キャッシングプロキシサーバーを使用すれば、透過的にファイルをキャッシングでき、手動でのコピーは必要ありません。また、キャッシングプロキシサーバーは透過型プロキシの役割を果たすため、すべてのエンドユーザーが同じ URL を使用でき、コンテンツは自動的にローカルキャッシュからストリーム配信されます。

ブロードキャストコンテンツ

Windows Media サーバーからのブロードキャスト接続の確立には、Windows Media Player を使用してエンドユーザーと直接接続する方法と、別の Windows Media サーバーと接続する方法の2つの方法があります。クライアントが別の Windows Media サーバーの場合には、ストリームは分散（distribute）されます。複数の Windows Media サーバーにブロードキャストコンテンツを分散することで、ネットワークの帯域幅やリソースをより効果的に使用し、サーバーの負荷を分散する、ストリーミングメディアネットワークアーキテクチャを作成できます。分散することを分割（split）するという場合もあります。

ブロードキャストコンテンツの手動分散では、サーバー管理者が直接、配信元の Windows Media サーバーとリモートサーバーを、分散用に構成します。ストリームは、配信元のサーバーからリモートサーバーに分散され、その後、リモートサーバーからそのローカル LAN セグメント内のクライアントに配信されます。配信元のサーバーとリモートサイトの間の単一の接続によって、多くのクライアントにストリームを配信できます。たとえば、ダラスの 50 のクライアントがブロードキャストに接続した場合、ダラスの Windows Media サーバーへの接続は 50 件になりますが、ダラスとシカゴの配信元サーバーの間の接続は1つだけです。ブロードキャストをストリーム配信するには、エンドユーザーは最寄りのエッジサーバーに接続します。詳しくは、『Serving for Windows Media Services: The Basics』およびWindows Media Services のヘルプを参照してください。

分散を行う最も簡単な方法は、リモートの Windows Media サーバーに、配信元サーバー上の発行ポイントを指示するブロードキャストユニキャスト発行ポイントを作成する方法です。たとえば、次の URL が、シカゴのサーバー上にあるデイリーライブレポートの URL を示しているとします。

mms://WindowsMediaServerChicago/DailyReport

リモートサーバーにシカゴの URL を指示する発行ポイントを作成すれば、他のサーバーにストリームを分散できます。リモートサーバー上の発行ポイントによって、配信元のサーバーとの間に分散用の接続が確立されます。リモートサーバー上の発行ポイントには、配信元のサーバーで使用されているのと同じ別名（この例では DailyReport）を指定できます。ダラスのエンドユーザーは、次の URL を使用して、分散されたレポートを受信します。

mms://WindowsMediaServerDallas/DailyReport

Windows Media Services を使用すれば、さまざまな方法でブロードキャスト分散システムを構成できます。ネットワーク全体で同じメソッドを使用することもできますし、複数のメソッドを組み合わせて使用することも可能です。

ユニキャストとマルチキャスト

ほとんどのストリーミングメディア接続はユニキャストです。ユニキャストは、クライアントサーバー接続で、クライアントは、他のクライアントからはアクセスされない固有のストリームを受信します。たとえば、1,000 のクライアントが 1 つのブロードキャストストリームをユニキャスト接続を通じて受信している場合、サーバー側には 1,000 の固有の接続が存在します。それぞれのクライアントが 100 Kbpsのブロードキャストストリームを受信している場合、すべてのクライアントとの接続をサポートするために必要な帯域幅の合計は、100 Kbps X 1000、つまり 100 Mbps となります。ブロードキャストを複数のリモートサーバーに分散すれば、ネットワークの負荷を大きく削減できます。負荷を小さくするもう1つの方法が、マルチキャスト接続の使用です。

マルチキャストは 1 対多の接続で、複数のクライアントがサーバーからの同じストリームにアクセスします。どのクライアントも同じストリームを受信するため、マルチキャストを使用すれば、ネットワークに必要な帯域幅を大きく減らすことができます。ブロードキャストに必要な帯域幅は、そのストリームに接続するエンドユーザーが 1 人でも千人でも変わりません。

マルチキャストを受信するには、クライアントはマルチキャスト対応のネットワークにアクセスする必要があります。これがマルチキャストの大きな欠点です。通常、エンタープライズのルーターやスイッチは、マルチキャストストリームには対応していません。しかし、Windows Media Services では、複数の分散方法を組み合わせて使用できるため、この問題の解決策は多数あります。次の図は、マルチキャストに対応している LAN セグメントでのマルチキャストの使用方法と、サーバー間の分散方法を示しています。

この例では、シカゴとダラスの LAN ではマルチキャストが使用されていますが、その 2 つのロケーションの間では、ストリームは分散ステーションを使用して分散されます。この分散方法では、ストリームがルーターやファイアウォールを通過できるプロトコルが使用されます。また、単純に、ブロードキャストユニキャスト発行ポイントを、マルチキャストの配信元として使用することもできます。たとえば、シカゴのネットワークがマルチキャストに対応していなかったとします。シカゴからはユニキャスト発行ポイントを通じてブロードキャストを配信できます。ダラス側では、マルチキャストの配信元をシカゴの発行ポイントと接続することによって、マルチキャスト接続を使用してブロードキャストを配信できます。ブロードキャスト用にネットワークを構成する方法は多数あります。分散ステーションのセットアップについての詳細は、Windows Media Services のオンラインヘルプを参照してください。

マルチキャスト配信に関するもう 1 つの問題は、接続が一方通行に限られているため、クライアントとサーバー間の通信が行えないことです。したがって、Windows Media Services を使用すれば接続のログをとる方法はありますが、クライアントとの接続を直接、リアルタイムで監視する方法はありません。また、マルチキャスト配信では、転送エラーを修正するフォームが使用されている場合でも、クライアント側がサーバー側に破損または欠けているデータの再送を要求する方法はありません。そのため、マルチキャスト接続は、すべてのトラフィックを処理するのに十分な帯域幅のある、安定したネットワークでのみ使用するようにしてください。

オンデマンドコンテンツをコピーする場合とは異なり、ブロードキャスト配信では、配信元のサーバーとの接続には、リアルタイムのストリームを処理できる安定性と帯域幅が必要です。つまり、コピー速度はネットワークの帯域幅に従って変えることができるため、100 Kbps のオンデマンドファイルを、56 Kbps の接続を使用して配信元のサーバーからリモートサーバーへコピーすることも可能です。しかし、ブロードキャスト接続はリアルタイムなので、ストリームのビットレートが 100 Kbps の場合には、リモートサーバーと配信元サーバーの間の接続は、100 Kbps 以上でなければなりません。この問題を解決するために、2つのストリーム（たとえば、シカゴの高帯域幅ネットワーク用と、遠隔地の低ビットレートストリーム用）をエンコードできます。ブロードキャスト配信が全く不可能な場合には、ブロードキャストをオンデマンドファイルにアーカイブしてから、遠隔地にコピーします。

大規模なネットワークにおけるコンテンツの分散には、すべてのコンテンツを中央でホスティングする場合に比べ、多くの利点があります。しかし、手動分散は、多数のストリーミングメディアを使用するエンタープライズにとっては不利な点もあります。ストリーミングメディアコンテンツの管理には、キャッシングプロキシサーバーを使用すると便利です。

キャッシングプロキシサーバーの仕組み

コンテンツを手動分散する代わりに、すべての遠隔地で Windows Media サーバーの代わりにキャッシングプロキシサーバーを使用することもできます。キャッシングプロキシサーバーを使用すると、管理者は、最小限の作業を行うだけで、自動的にオンデマンドコンテンツをコピーし、ブロードキャストストリームを分散できます。さらに、キャッシングプロキシサーバーを使用すると、URL 要求を透過的に転送できます。つまり、エンドユーザーが配信元サーバー上のコンテンツの URL を開くと、（そのコンテンツがローカルサーバー上に存在している場合は）キャッシングプロキシによって自動的かつ透過的にローカル側のコンテンツがストリーム配信されます。

次の Windows Media ソフトウェア製品ベンダ（http://go.microsoft.com/fwlink/?LinkId=2899 , 英語サイト）は、Windows Media Services をサポートするキャッシングプロキシサーバーを提供しています。

Microsoft ISA（Internet Security and Acceleration）Server（http://www.microsoft.com/JAPAN/isaserver/）は、Web ページなどの Web オブジェクトに対するエンタープライズ向けのファイアウォールおよびキャッシュサーバーです。現時点ではオンデマンドファイルのストリーム配信には対応していませんが、ISA サーバーでのライブストリームの分割が使用可能です。（http://go.microsoft.com/fwlink/?LinkId=2901 , 英語KB）また、ISA ではサードパーティ製のフィルタを使用できるため、開発者は Windows Media Services をサポートするキャッシュプラグインを作成できます。
InfoLibria （http://go.microsoft.com/fwlink/?LinkId=2903）。MediaMall および DynaCache は、デジタルメディアコンテンツを保存し、ストリーム配信します。Content Commander は、コンテンツ管理サブシステムで、コンテンツのコピー、事前配置、認証、追跡を制御します。
Network Appliance （http://go.microsoft.com/fwlink/?LinkId=2905）。コンテンツ配信アプライアンスのNetCacheファミリは、ネットワークのエッジにコンテンツを配信します。
Inktomi （http://go.microsoft.com/fwlink/?LinkId=2910）。統合された複数のエッジノードで構成されるContent Networking Solutionsは、さまざまなインターネットコンテンツをキャッシングおよび配信します。

どの製品にも、異なる機能があります。さまざまな機能があるため、このセクションでは、一般的なキャッシングプロキシと、Windows Media コンテンツのストリーム配信に適したキャッシングプロキシサーバーの概要について説明します。ご自分のニーズに最も適した製品と構成については、各ベンダにお問い合わせください。

キャッシングプロキシには、手動分散と同じような利点があります。

より効果的な帯域幅の利用。キャッシングプロキシを使用すると、コンテンツの配信が分散されるため、ネットワークの帯域幅の使用率に与える影響も分散されます。
待ち時間の短縮。キャッシングプロキシを使用すると、ネットワークトラフィックが減少し、サーバーとクライアントの距離が短くなるため、接続する際の待ち時間が短くなります。
エンドユーザー側の快適さの向上。キャッシングプロキシサーバーは、エンドユーザーに対するより高品質のストリームの配信に役立ちます。

さらに、理想的なキャッシングプロキシには、次のような利点があります。

キャッシング。オンデマンドコンテンツはキャッシングされるため、エンドユーザーは、配信元のサーバーからではなくローカル側からストリームを受信できます。手動分散と比較した場合のキャッシングの利点としては、コンテンツを自動的にキャッシングできるため、管理者が手動でコピーする必要はありません。
プロキシ。すべてのエンドユーザーが、配信元のサーバーにコンテンツを要求する場合と同じ URL を使用できます。キャッシングプロキシによって、コンテンツは自動的にローカルキャッシュから配信されます（ローカルキャッシュにそのコンテンツが存在する場合）。
容易な管理。多くの最高級のキャッシングプロキシソリューションには、ストリーミングコンテンツの自動的なキャッシングや分散だけでなく、中央からファイルを管理し、キャッシングプロキシネットワークを構成するシステムが備わっています。企業のネットワークにおいて特に重要なのは、コンテンツを事前に構成および配置する機能です。こうしたシステムを使用すれば、すべての遠隔地のオンデマンドおよびブロードキャスト機能を管理、構成できます。また、高い使用率が予想されるオンデマンドコンテンツを、キャッシングプロキシに事前配置またはプッシュすることも可能です。たとえば、全社的に重要な発表を、社員に対してオンデマンドで使用可能にする場合、管理者は、要求が多くなる前に、そのファイルをすべてのキャッシングプロキシに事前配置できます。

理想的なキャッシングプロキシソリューションには、これら3つの利点がすべて備わっています。理想的なソリューションの仕組みを理解するために、次のプロセスでは、エンドユーザーがコンテンツに接続し、ストリーム配信を受ける方法について説明します。

ダラスにいるエンドユーザーが、オンデマンドファイル Update.wmv を再生するとします。そのエンドユーザーは、Windows Media Player に URL（mms://ChicagoServer/Update.wmv）を入力するか、イントラネット Web ページ上にあるそのコンテンツへのリンクをクリックします。このURLが、シカゴの配信元のサーバーにある Update.wmv を要求している点に注意してください。要求が送信されると、次のプロセスが開始されます。

ダラスのキャッシングプロキシサーバーが、URL要求をインターセプトします。
このファイルがダラスで初めてアクセスされるファイルの場合は、ダラスのキャッシングプロキシサーバーからシカゴの配信元のサーバーに要求が送信されます。
シカゴのサーバーによって接続が確立され、ダラスのキャッシングプロキシサーバーへのファイルのストリーム配信が開始します。
ダラスのキャッシングプロキシサーバーは、ストリームをクライアントに転送します。また、そのストリームをキャッシュに保存します。

次にダラスのエンドユーザーが同じファイルを要求したときには、キャッシングプロキシサーバーによってそのファイルがキャッシュからストリーム配信されます。理想的なキャッシングプロキシでは透過的に作業が行われるため、エンドユーザーにはファイルがどちらのサーバーからストリーム配信されているのかわかりません。ただし、エンドユーザーは、ローカルキャッシュからストリーム配信されているときの方がストリームの品質が格段に良いことに気づくでしょう。

自社のネットワークに適したキャッシングプロキシソリューションを探す場合には、次の幾つかの基本的なポイントに注意してください。

明示的なプロキシと暗黙的なプロキシ
セキュリティ
その他の考慮事項

明示的なプロキシと暗黙的なプロキシ

プロキシサーバーは、Windows Media Player またはブラウザからサーバーへの接続を確立しようとする際の仲介役となります。クライアントとプロキシとの通信は、明示的または暗黙的です。

明示的な接続では、クライアントを特定のプロキシおよびポート番号を使用するように構成します。たとえば、次のダイアログボックスは、Windows Media Player を、ポート 80 の MyProxy を通じてのみ接続するように構成します。

Windows Media Player を暗黙的な接続用に構成するには、[プロキシサーバーを使わない（Do not use a proxy server）] を選択します。このような接続では、プロキシはクライアントからは見えません。コンテンツをストリーム配信するには、エンドユーザーがファイルに対する要求を行い、Windows Media Playerまたはブラウザによって接続が確立されます。この接続は、あたかも配信元のサーバーに接続しているように見えます。

このセクションの初めにリストアップしたキャッシングプロキシサーバーは、透過型のプロキシ用に構成できます。つまり、それらのキャッシングプロキシサーバーを使用すると、クライアントから暗黙的に接続できます。透過型のキャッシングプロキシを使用すると、Windows Media Player の構成が容易になります。また、透過型のキャッシングプロキシは、通常、ストリーミングメディアだけでなく、すべてのネットワークトラフィックを管理するハードウェアソリューションとして実装されます。透過型のキャッシングプロキシサーバーの欠点は、明示的なプロキシを使用するキャッシングプロキシソリューションよりも費用が高くなる場合が多いことです。

セキュリティ

Windows Media Services を使用すると、配信するコンテンツに対するアクセス制限を設定できます。通常、キャッシングプロキシサーバーには、セキュリティで保護されたコンテンツをキャッシュから再生する前に配信元のサーバーに問い合わせる方法がないため、セキュリティ制限のあるストリーミングコンテンツはキャッシングしません。キャッシングプロキシは、ソースからの認証要求の有無で、コンテンツをキャッシングするかどうかを決定します。Windows Media サーバー上のセキュリティで保護されたコンテンツにアクセスする場合には、さまざまな方法でクライアントからの認証要求を処理するようにプロキシサーバーを構成します。つぎのような３つの方法を含みます。

プロキシがクライアントを確認する。クライアントがコンテンツを要求すると、配信元のサーバー上のコンテンツがセキュリティ保護されているかどうかに関係なく、プロキシによるクライアントの確認が行われます。認証されると、そのクライアントからの要求が配信元のサーバーに渡されます。
プロキシがクライアントからの認証要求を伝達する。配信元のサーバーがクライアントからの要求を確認し、プロキシはその要求をクライアントに伝達します。
" プロキシが別のプロキシを確認する。複雑なネットワークで複数のプロキシが使用されている場合には、プロキシを、別のプロキシサーバーからの認証要求を処理できるように構成できます。たとえば、最初のプロキシが 2 番目のプロキシにコンテンツを要求すると、2番目のプロキシが最初のプロキシを確認します。認証された場合には、その要求は 2 番目のプロキシから配信元のサーバーに渡されます。

Microsoft Windows Media Rights Manager を使用して暗号化されたファイルは、キャッシングできますので注意してください。ファイルのエンコード時に行われる暗号化は、ファイルへのアクセスを制限するためにサーバーによって使用されるセキュリティとは全く別のものです。暗号化されたファイルは自由にコピーできます。また、希望に応じて、暗号化されたファイルにも、他の任意のファイルと同じようにアクセス制限を付けられます。

その他の考慮事項

本来、キャッシングプロキシは、Web オブジェクト（Web ページ、画像、スクリプトファイルなど）をキャッシングするために設計されました。これらのコンテンツは、1 度に完全にダウンロードされる別々のオブジェクトです。たとえば、エンドユーザーが Web ページを開くと、そのページとそれに関連付けられているファイルが、キャッシングプロキシとユーザーのインターネット一時ファイルキャッシュの両方に、即時にキャッシングされます。

ストリーミングメディアはこの設計に幾つかの挑戦をしています。Webオブジェクト（Web ページなど）が比較的小さいのに対して、ストリーミングファイルは通常かなり大きくなります。ストリーミングメディアファイルは、数メガバイト（MB）または数ギガバイト（GB）になることも珍しくありません。ストリーミングファイルは、ほとんどの Web オブジェクトより大きいだけでなく、1度に全部キャッシングされずに、そのデジタルメディアコンテンツが再生されるに連れてキャッシングされる場合があります。たとえば、10 分間のビデオファイルは、10 分間かけて表示され、キャッシングされます。

理想的なキャッシングプロキシサーバーは、ストリーミングメディアによるすべての挑戦にあらかじめ対処するように設計されています。ただし、キャッシングプロキシソリューションを購入する場合には、次の点に注意する必要があります。

ファイルのサイズとその処理。キャッシングプロキシコンピュータには、要求される可能性のある大量の大きなファイルを処理するために十分な仕様が必要です。ハードディスクにも、必要な数の同時ストリームを要求されているビットレートで処理するために十分な速度がなければなりません。また、キャッシングプロキシで Web オブジェクトも扱わなければならない場合は、その分の負荷にも確実に耐えられるようにする必要があります。
不完全なキャッシュ。高度なキャッシング技術の一つに、読み書きを同時に行える「read while write」という技術があります。キャッシングプロキシでは、読み取ったデータを、ハードディスクに書き込むのと同じようにクライアントに送信します。この技術は、完全にダウンロードした Web オブジェクトに適しています。しかし、ストリーミングメディアをキャッシングするときには、問題が生じる場合もあります。たとえば、エンドユーザーが 1 時間の長さのオンデマンドファイルを2分だけ再生したとします。次にエンドユーザーがそのコンテンツを要求すると、キャッシングプロキシによってキャッシングされたコンテンツがストリーム配信されるため、そのエンドユーザーは最初のユーザーが表示した 2 分間のみを受信することになります。また、あるエンドユーザーが、別のエンドユーザーによってすでにストリーミングが開始されたファイルのストリーミングを開始したとします。この場合、2 番目のユーザーは、現在キャッシング中のファイルをストリーミングすることになるのでしょうか。最初のエンドユーザーがストリーミングを中止するか、ファイルの別のポイントに移動した場合にはどうなるのでしょうか。その場合、キャッシングされるデータは不完全、または不連続になります。理想的なキャッシングプロキシサーバーでは、こうした問題を予想して、さまざまなキャッシング方法を使用します。エンドユーザーが初めて配信元のサーバーからコンテンツをストリーミングすると、キャッシングプロキシによって 2 つの独立した接続が確立されます。その1つはエンドユーザーのプレイヤーにストリーム配信する接続です。もう1つはキャッシュに配信する接続で、ファイルが終了するまで配信を継続します。この方法を使用すれば、エンドユーザーが停止、一時停止、またはコンテンツ内のシークを行った場合でも、キャッシング中のファイルには影響しません。
ブロードキャストのキャッシング。キャッシングプロキシサーバーでは、さまざまな理由でブロードキャストストリームはキャッシングされません。最も大きな理由は、連続的に再生されるブロードキャストストリーム（ラジオ放送など）のキャッシングには、莫大なハードディスクスペースが必要になることです。その代わりに、ブロードキャストストリームは、複数のクライアントのキャッシングプロキシに分散または分割されます。ブロードキャストを後でオンデマンドで再生できるようにしたい場合は、配信元の Windows Media サーバーまたは Windows Media Encoder を、ブロードキャスト中にアーカイブファイルを作成するように構成します。
複数ビットレートストリームのキャッシング。複数ビットレートのオンデマンドファイルまたはブロードキャストは、ビットレートの異なる複数のビデオストリームを使用してエンコードできます。クライアントが複数ビットレートでエンコードされたファイルを Windows Media サーバーからストリーミングすると、クライアントとサーバーの対話によって、現在の帯域幅に最も適したビットレートが選択され、そのストリームのみがクライアントに配信されます。帯域幅が変わると、Windows Media サーバーによって別のストリームに切り替えられるため、ユーザーは可能な範囲で最高の品質の映像を受信できます。透過型のキャッシングプロキシサーバーは、クライアントから要求された単一のストリームしかキャッシングしないため、複数ビットレートのファイルは正しくキャッシングできません。また、キャッシングプロキシでは、帯域幅が変わってもストリームを切り替えられません。この場合、複数ビットレートのオンデマンドファイルは事前配置するようにしてください。複数ビットレートのブロードキャストストリームを、配信元のサーバーから分散することは可能です。ただし、ストリームの分散に必要な帯域幅は、すべてのストリームの帯域幅の合計になります。たとえば、22 Kbpsと 100 Kbpsの複数ビットレートのブロードキャストストリームの分散には、この 2 つのビットレートの合計に音声ストリームのビットレートを加えた帯域幅が必要となります。十分な帯域幅がない場合は、ブロードキャストの分散に複数ビットレートストリームは使用しないでください。
コンテンツの新しさ。キャッシングプロキシソリューションには、キャッシングしたコンテンツの新しさを判別する機能が必要です。この機能は、ストリーミングメディアに固有のものではありません。優れた設計のキャッシングプロキシは、任意のファイルをキャッシングすると、アクセスしているファイルが現行のものであることを、さまざまな方法で確認します。キャッシングプロキシソリューションに投資する前に、そのソリューションが採用しているコンテンツの更新方法を理解し、その方法がご自分に適しているかどうかを判断するようにしてください。
ロギング。Windows Media Services には、クライアント側の完全な使用ログを作成する機能があります。ただし、正確なロギングを行うには、サーバー側が、そのサーバー上のコンテンツにアクセスするすべてのクライアントに接続する必要があります。配信元の Windows Media サーバーには、クライアントとキャッシングプロキシサーバーの接続のログをとる方法はありません。また、多数のキャッシングプロキシを使用する巨大なネットワークでは、数千に及ぶクライアント接続をカウントすることはできません。エンタープライズのシステムでは、クライアント接続の正確なログをとることは多くの場合重要ではありませんが、ロギングが重要な場合には、使用するキャッシングプロキシソリューションにロギングシステムが組み込まれていることを確認してください。幾つかのキャッシングプロキシソリューションには、ログデータを統合する機能があります。このようなシステムでは、それぞれのキャッシングプロキシサーバーから自動的にクライアント接続データが送信されます。それらのデータは統合されて配信元の Windows Media サーバーに送信され、配信元のサーバーのログファイルに反映されます。

使用するキャッシングプロキシソリューションが、自社のニーズに最適のものであることをベンダに確認してください。使用するソリューションに適切な強度と必要な機能および柔軟性があれば、キャッシングプロキシを使用することで、エンタープライズネットワーク全体に容易かつ楽にストリームを配信できます。

キャッシングプロキシソリューションの実装

キャッシングプロキシソリューションの実装方法は、使用する製品によって異なります。「キャッシングプロキシサーバーの仕組み」に記述したベンダは、既存のシステムにほとんど影響を与えずに追加できる、非常に優れたソリューションを提供しています。こうしたソリューションは、メーカーの指示に従って実装すれば、ダウンタイムをほとんどまたは全く必要とせず、最小限の構成作業を行うだけで実装できます。

わかりやすくするために、このトピックではInfoLibriaのソリューションを中心に説明します。説明する機能の多くは、他社のソリューションでも使用できます。また、他社のソリューションには、InfoLibria の製品にはない、非常に便利な機能が組み込まれている場合もあります。ここでの説明は、InfoLibria の製品を特に推奨するということではありませんので注意してください。ここで InfoLibria を取り上げるのは、一般的なキャッシングプロキシサーバーについての理解を促進するためです。

InfoLibria のソリューションを完全に実装するには、次の 3 つの製品を使用します。

DynaCache。HTTP（Hypertext Transfer Protocol）オブジェクトを保存および配信します。DynaCache サーバーは、オブジェクト（Web ページとそれに関連する画像など）のキャッシングに使用します。
MediaMall。オンデマンドおよびブロードキャストストリーミングメディアコンテンツを保存および配信します。
Content Commander。すべての MediaMall サーバーおよび DynaCache サーバーの構成と制御に使用される管理システムです。

その他のソリューションも、同様のシステム（複数のキャッシングプロキシサーバーと単一の管理プログラムまたはアプライアンス）を使用します。

前述のシナリオ例で説明すると、ダラス、アトランタ、ボンベイのネットワーク全体に戦略的に配置されたノードに、複数のMediaMall アプライアンスがインストールされ、構成されます。シカゴの本社には、単一の Content Commander がインストールされます。ストリーミングメディアネットワークの管理者は、Content Commander を使用して、すべての MediaMall アプライアンスを遠隔地から監視および構成します。プロキシノード間の接続は、グラフィカルインターフェースを使用して、容易にマッピングできます。通常、システムに MediaMall アプライアンスを追加するために必要な構成作業は、初期IPアドレスの設定のみです。その後は、そのアプライアンスに対してローカル側で定期的なメンテナンスを行う必要はありません。通常の構成作業はすべて Content Commander から実行できます。DynaCache アプライアンスは、イントラネット上のWebオブジェクトのキャッシングにも使用されます。

Content Commander は、オンデマンドファイルの事前配置や、ブロードキャストストリームの配信のセットアップにも使用されます。InfoLibria の製品では、ストリーミングコンテンツは「read while write」または 2 つの接続を使用する方法で自動的にキャッシングされません。不完全なキャッシングおよび複数ビットレートコンテンツのキャッシングの問題を解決するには、ファイルの明示的な事前配置またはコピーを行います。管理者は、次のような幾つかの方法で、コンテンツをキャッシングプロキシから移動します。

手動で。管理者は、Content Commander を使用して、ファイルを直接 MediaMall アプライアンスにコピーします。
時間を指定して。多数のファイルをコピーしなければならない場合には、管理者は、ファイルを自動的にまたは決められた時間（夜間など）にコピーするように、Content Commander を構成できます。
頻度に従って。ファイルが要求される頻度に従って、手動または自動でファイルを配置できます。管理者は、Content Commander を使用してカウンタを設定します。たとえば、カウンタを 5 に設定すると、6 以上カウントされたファイルをリストしたレポートが、Content Commander から管理者に送信されます。その後、管理者は、要求頻度の高いファイルを手動でコピーするか、カウント数が設定値を越えたファイルを自動的にコピーするように Content Commander を構成できます。

各 MediaMall アプライアンスには、オンデマンドおよびブロードバンドコンテンツをホスティングする Windows Media サーバーが組み込まれています。Content Commander は、ネットワーク管理およびコンテンツ管理アプライアンスとしての機能のほかに、ブロードキャストストリームの配信のセットアップにも使用されます。Content Commander は、配信元の Windows Media サーバーおよび各 MediaMall アプライアンスの管理に使用されます。

使用ログは、データ調整システムを使用して作成されます。Content Commander を使用すれば、定期的に使用状況のデータを送信するように、各 MediaMall および DynaCache アプライアンスを構成できます。Content Commander の分散データベースフロントエンドによって、すべてのデータがオンデマンドで完全なレポートに統合されます。

通常、システムの初期構成を行った後は、システムに新規のアプライアンスを追加するなどの変更が加えられない限り、それ以上の構成作業は必要ありません。管理者は、オンデマンドファイルの配置やブロードキャスト配信のセットアップを管理します。

管理者は、使用頻度の高いファイルをキャッシングプロキシに入れることができます。高い頻度で使用されると判断された新規ファイル（CEO のレポートなど）がある場合、管理者は、使用率が高いという予想に基づいて、そのファイルを事前配置できます。キャッシングプロキシは、高速 LAN セグメント内に配置されているため、エンドユーザーは高品質で高帯域幅のコンテンツを表示できます。帯域幅の使用は、単一のサーバーに集中するのではなく分散されます。

キャッシングプロキシは、透過型としても構成できます。つまり、すべてのエンドユーザーが同じ URL を使用してオンデマンドコンテンツにアクセスできます。Windows Media Player に対する明示的なプロキシの設定は必要ありません。たとえば、シカゴにある配信元のサーバー上のコンテンツの URL を使用すると、キャッシングプロキシによって自動的かつ透過的にローカルキャッシュからファイルが配信されます（ローカルキャッシュ内にそのファイルがある場合）。また、配信元のサーバー上のブロードキャストの URL を使用すると、MediaMall アプライアンスによって透過的にそのストリームがローカル側のブロードキャスト発行ポイントから配信されます。キャッシングプロキシシステムは、バックグラウンドでシームレスに動作して、エンドユーザーに高品質のコンテンツを配信し、WANの帯域幅の使用は最小限に抑えます。

参考資料

Microsoft Windows Media Services について、さらに詳しくは、Windows Media Services のヘルプを参照してください。