Azure Content Delivery Network を使用した大容量ファイルのダウンロードの最適化
重要
Azure CDN Standard from Microsoft (クラシック) は、2027 年 9 月 30 日に廃止されます。 サービスの中断を回避するには、2027 年 9 月 30 日までに Azure Front Door の Standard または Premium レベルに Azure CDN Standard from Microsoft (クラシック) プロファイルを移行することが重要です。 詳細については、Azure CDN Standard from Microsoft (クラシック) の廃止に関するページを参照してください。
Azure CDN from Edgio は、2025 年 11 月 4 日に廃止される予定です。 サービスの中断を避けるには、この日付より前に Azure Front Door にワークロードを移行する必要があります。 詳細については、「Azure CDN from Edgio の廃止に関する FAQ」を参照してください。
インターネット経由で配信されるコンテンツのファイル サイズは、機能の強化、グラフィックスの向上、リッチ メディア コンテンツの普及により、常に拡大し続けています。 この拡大は、ブロードバンドの浸透、低価格ストレージ デバイスの大容量化、高解像度ビデオの広範な増加、インターネットに接続されるデバイス (IoT) などの多くの要因によってもたらされています。 このような大きなファイルの高速で効率的な配信メカニズムは、お客様がスムーズで楽しい経験をすることを可能にするために極めて重要です。
大容量ファイルの配信には、いくつかの課題があります。 まず、アプリケーションはすべてのデータを順番にダウンロードしない場合があるため、大きなファイルのダウンロードにかかる平均時間が長くなることがあります。 場合によっては、アプリケーションはファイルの先頭部分より先に最後の部分をダウンロードすることもあります。 少量のファイルのみを要求した場合や、ダウンロードを一時停止した場合は、ダウンロードが失敗します。 また、コンテンツ配信ネットワークが配信元サーバーからファイル全体を取得するまで、ダウンロードが遅延することもあります。
次に、コンテンツが表示されるまでの時間は、ユーザーのマシンとファイルの間の待ち時間によって決まります。 さらに、ネットワークの輻輳や容量の問題もスループットに影響します。 サーバーとユーザー間の距離が長くなるほど、品質低下を引き起こすパケット損失の可能性が高くなります。 スループットの制限とパケット損失の増加によって品質が低下すると、ファイル ダウンロードが完了するまでの待ち時間が長くなることがあります。
3 つ目に、大きなファイルの多くは完全には配信されません。 ユーザーは、ダウンロードを途中で取り消したり、長い MP4 ビデオの最初の数分のみ視聴したりすることがあります。 そのため、ソフトウェアやメディアを配信する企業は、要求された部分のファイルのみを配信したいと考えます。 要求された部分だけを効率的に配信できれば、配信元サーバーからのエグレス トラフィックが少なくなります。 さらに、効率的に配信できれば、配信元サーバーのメモリや I/O 負荷も軽減されます。
Azure Content Delivery Network from Microsoft を使用した大きなファイルの配信の最適化
Azure CDN Standard from Microsoft エンドポイントでは、ファイル サイズの制限なく、大きなファイルの配信を行うことができます。 大きなファイルを短時間で配信できるように、追加の機能が既定で有効になっています。
オブジェクト チャンク
Azure CDN Standard from Microsoft では、オブジェクト チャンクと呼ばれる方法が採用されています。 大きなファイルが要求されると、コンテンツ配信ネットワークは配信元からファイルを分割して取得します。 コンテンツ配信ネットワーク POP サーバーが完全なファイル要求またはバイト範囲を指定したファイル要求を受け取った後、コンテンツ配信ネットワーク エッジ サーバーは、8 MB のチャンク単位で配信元にファイルを要求します。
コンテンツ配信ネットワーク エッジに届いたチャンクはキャッシュされ、即座にユーザーに提供されます。 その後、コンテンツ配信ネットワークは並列処理で次のチャンクをプリフェッチします。 このプリフェッチにより、コンテンツはチャンク 1 つ分だけ常にユーザーより先行することになるため、待ち時間が短縮されます。 この処理は、ファイル全体がダウンロードされるか (要求があった場合)、すべてのバイト範囲が利用可能になるか (要求があった場合)、クライアントが接続を終了するまで続けられます。
バイト範囲の要求の詳細については、RFC 7233 をご覧ください。
コンテンツ配信ネットワークは、受信したチャンクをすべてキャッシュします。 ファイル全体をコンテンツ配信ネットワークのキャッシュに保存する必要はありません。 ファイルまたはバイト範囲に対する後続の要求に対しては、コンテンツ配信ネットワーク キャッシュの内容が提供されます。 すべてのチャンクがコンテンツ配信ネットワークにキャッシュされていない場合、プリフェッチを使用して配信元にチャンクが要求されます。 この最適化は、配信元サーバーのバイト範囲要求をサポートする機能に依存します。 配信元サーバーがバイト範囲要求をサポートしていない場合、8 MB を超えるサイズのデータをダウンロードする要求は失敗します。
大きなファイルの最適化の条件
最大ファイル サイズの上限はありません。
チャンク転送エンコードサポート
Microsoft コンテンツ配信ネットワークは転送エンコード応答をサポートしていますが、最大 8 MB のコンテンツ サイズまでしかサポートしません。 チャンク転送エンコード応答が 8 MB を超える場合、Microsoft コンテンツ配信ネットワークでは、最初の 8 MB のコンテンツのみキャッシュされて提供されます。
Azure Content Delivery Network from Edgio を使用した大きなファイルの配信の最適化
Azure CDN Standard from Edgio および Azure CDN Premium from Edgio エンドポイントでは、ファイル サイズの制限なく、大きなファイルの配信を行うことができます。 大きなファイルを短時間で配信できるように、さらに多くの機能が既定で有効になっています。
Complete Cache Fill (完全キャッシュ入力)
既定の Complete Cache Fill (完全キャッシュ入力) 機能では、最初の要求が破棄されたり失われたりしたときに、コンテンツ配信ネットワークがファイルをキャッシュにプルできます。
Complete Cache Fill は、サイズの大きな資産に対して最も有効的な手段です。 通常、ユーザーは大きな資産を最初から最後までダウンロードせず、 プログレッシブ ダウンロードを使用します。 既定の動作では、エッジ サーバーで配信元サーバーからの資産のバックグラウンド取得が開始されます。 その後、資産はエッジ サーバーのローカル キャッシュに入れられます。 完全なオブジェクトがキャッシュに入ると、エッジ サーバーは、コンテンツ配信ネットワークへのキャッシュ オブジェクトのバイト範囲要求を満たすことになります。
Azure CDN Premium from Edgio では、ルール エンジンを通じて既定の動作を無効化できます。
ピア キャッシュ入力のホットファイリング
既定のピア キャッシュ入力のホットファイリング機能には、独自の高度なアルゴリズムが採用されています。 帯域幅に基づいて追加のエッジ キャッシュ サーバーを使用し、要求メトリックを集計して、サイズが大きく、利用頻度の高いオブジェクトに対するクライアント要求を満たします。 この機能により、多数の追加要求がユーザーの配信元サーバーに送信される状況を防ぐことができます。
大きなファイルの最適化の条件
最適化の種類として一般的な Web 配信を使用すると、Azure CDN Standard from Edgio および Azure CDN Premium from Edgio の大きなファイルの最適化機能が既定で有効になります。 最大ファイル サイズの上限はありません。
その他の考慮事項
この最適化を利用する場合は次のような点も考慮する必要があります。
チャンクの処理では、配信元サーバーに対してその他の要求が生成されます。 ただし、配信元から配信されるデータの総量は小さくなります。 チャンク処理により、コンテンツ配信ネットワークでのキャッシュ特性が改善されます。
ファイルが分割されて配信されるため、配信元のメモリと I/O の負荷が軽減されます。
コンテンツ配信ネットワークでキャッシュされるチャンクの場合、コンテンツの有効期限が切れるか、キャッシュから削除されるまで、配信元への他の要求は発生しません。
ユーザーはコンテンツ配信ネットワークに対して範囲要求を行うことができ、それは通常のファイルと同様に扱われます。 最適化は、バイト範囲が 10 MB ～ 150 GB の有効なファイルの種類の場合にのみ適用されます。 要求されたファイルの平均サイズが 10 MB より小さい場合は、代わりに一般的な Web 配信を使用します。