大きなファイルのダウンロードをスケーリングしますか？
現在、単一のApacheサーバーを介して大きな（1GB +）ファイルを配信していますが、Apacheサーバーは非常にディスクIOバウンドであり、拡張する必要があります。
私の最初のアイデアは、このApacheサーバーを単純に複製することでしたが、ファイルライブラリが大きすぎて、ApacheサーバーをN回水平方向にスケーリングすることはできません。
したがって、私の次のアイデアは、バックエンドに2つのApache（高可用性）を配置し、それぞれにライブラリ全体の個別のコピーを配置することでした。次に、「N」リバースプロキシを前面に配置します。「N」は、配信のニーズが大きくなるにつれて大きくなります。各リバースプロキシは非常にRAM重く、GBあたりのスピンドル数ができるだけ多くなります。バックエンドApacheサーバーはより「アーカイブ」であり、スピンドルからGBへの接続が少なくなります。
これは良いアーキテクチャですか？それを処理するためのより良い方法はありますか？
これは悪いアーキテクチャではありません（ squid は人気のあるリバースプロキシです）が、指数関数的成長が予想される場合は コンテンツ配信ネットワーク がより良い解決策になる可能性があります-コンテンツに対してのみ料金を支払います必要に応じて、帯域幅は即座にスケーリングされ（サーバーをスケールアウトする必要はありません）、ストリーミング転送はクライアントにできるだけ近いサーバーにジオロケーションされ、最大の転送速度が得られます。しかし、私は1GBのファイルでこれを試したことがなく、コストが法外に高くなる可能性があります。
この場合、トレントテクノロジーはp2p CDNと見なすことができます。そのため、 これらのプロバイダー の一部は、コンテンツのトレントシードとして適している可能性があります。これにより、総帯域幅コストが削減され、（場合によっては）速度が向上します。それはあなたのリーチャーに依存しています。
現在これを行っていない場合は、オプションでビットトレントを介してファイルを配信し、サーバーの負荷の一部をP2Pネットワークにプッシュすることを検討する価値があるかもしれません。
私の質問は、あなたがIOそもそもバインドされていることをどうやって知っているのですか？あなたのディスクがHTTP経由のダウンロードに追いつけないのは奇妙なことです（これがここにあると仮定して） HTTPSではありません）。
他の人が指摘しているように、ユーザーベースが大きい場合は、CDNソリューションが適用できるようです。負荷分散にはアカマイを使用しています。ここでは、これらのファイルをPI（パブリックインターネット）経由で提供しているのに対し、100Mbまたは1000Mbスイッチドネットワーク上でのみ内部的にホストされているソリューションを提供していると想定しています。
遅いダウンロードをディスクとして認識している可能性はありますかIO代わりにインターネット帯域幅の問題である可能性がありますか？（これもPI向けのサイトであると想定しています）。
ディスクを増やす方法はたくさんありますIO-SANまたはRAID;どちらもある程度のキャッシュを提供します。インターネットは考えられません）を使用できます。シングルの容量を超える接続SAN HBAまたはデュアルSAN HBA（チーム化）2Gb/s/hbaまたはキャッシュ付きRAID経由のローカルストレージで実行PCI-Eバスを介して接続されたバッキング。
Gig-Eに接続されたクライアントを同じ接続されたサーバーに話しているのですか？
ここでスケーリングしようとしているのはIOです。
Squidやvarnishなどのキャッシングプロキシを使用すると、アーカイブ内の使用頻度の低い/使用されていないファイルを複製せずに、キャッシュにデータを入力してスピンドルを増やすことができます。 CDNデバイスもこれを行います。これらのファイルはメディアですか？ CDNデバイスもストリーミングを行うことができます。
ユーザーはファイルのダウンロードに失敗し、ダウンロードを頻繁に再試行しますか？再試行率が高いと、IOのニーズが大幅に増加します。
ファイルのフェッチ方法を制御できますか？ダウンロードマネージャーは、各ファイルを別々のチャンクにフェッチできるため、時間の経過とともにリクエストを複数のアパッチに分割できます（ただし、並行してダウンロードしてインターネットパイプを飽和させることもできます）。
「経験」のリファレンスとして、私はすべてのデータをNAS（特にnetapp）に配置し、NFSでapachを使用してファイルを配信する環境にのみいました（ 1GBのファイルではなく、多くの小さなファイル）。また、ビデオをストリーミングするためのキャッシングプロキシとしてCDNを使用しました。
MogileFS を使用してファイルを冗長的に保存します（各ファイルを複数のサーバーに配置することによる冗長性とスケーラビリティ）が、速度と...まあ、より高いスケーラビリティのためにユーザーアクセスにCDNを経由させます。
小さいCDNであるPantherExpressを使用しています。価格も手頃で、機能セットも優れています。 Limelight NetworksとEdgeCastも、買い物をしているときに良い見積もりをくれました。
PantherExpressがそれらの機能に関する優れた技術文書を提供し、これらのすべての機能を1つの価格で入手できるのが好きでした。これには少し余分なお金がかかり、さらにいくらか余分なお金がかかります。
データはどのストレージシステムにありますか？そしてそれは分割できますか？
それぞれがデータのサブセットを持つ物理的に異なるSAN上にバックエンドサーバーを配置し、リバースプロキシフロントエンドマシンにサービスを提供すると、データが物理的に吐き出され、外部から論理的に同じアドレスになります。
Nginx は、 メモリ消費 および静的ファイルが sendfile（） を使用してカーネルにオフロードできるため、非常に優れています。 Lighttpd も確認する必要がありますが、安定性が低い（メモリ消費量が多い）と聞きましたが、使用していません。
フロントエンドサーバーは、パスまたはパターンによってバックエンドサーバー上のリクエストを分割でき（Nginxは優れた正規表現をサポートしています）、必要に応じて別のデータセンターにリダイレクトすることもできます。 DNSラウンドロビンも役立つ場合があります。
ゆっくり同期するデータセット間のフェイルセーフとして、Nginxを使用してプロキシをリバースプロキシすることに成功しました。ファイルをテストし、ファイルが存在しない場合は、http経由でバックエンドサーバーに問い合わせます。後でそれはフロントエンドマシンに同期され、正常に動作します。
何をするにしても、統計を全面的に監視するようにしてください。メモリ、io待機、帯域幅、遅延、平均要求時間など。何をしているのかを監視せずに、暗闇で撮影しています。
私が見た可能性のあるアーキテクチャの1つは、フロントエンドとしてnginxを使用し、複数のVarnishインスタンスによってサポートされています。そのアーチに第2レベルのプライマリワニスを追加することも検討されました（つまり、ワニスはメインワニスから引き出されます）。
それ以外は、他の人が言及しているように、CDNの使用を検討する必要があります。提供しているもの（メディア？）に応じて、BitGravityなどの大きなファイルの配信に重点を置いた特殊なCDNがいくつかあります。