ダウンロード時間(したがって帯域幅の使用量)が制限要因であるという仮定に基づいて、次のことを提案します。
まず、m1.largeインスタンスを選択します。I / Oパフォーマンス(帯域幅を含む)の3つの「レベル」のうち、m1.largeおよびm1.xlargeインスタンスはどちらも「高い」I / Oパフォーマンスを提供します。タスクはCPUバウンドではないため、これらの中で最も安価なものをお勧めします。
次に、インスタンスはどのサイトでもページを提供できるよりもはるかに速くダウンロードできます-特定のインスタンスで一度に1つのページをダウンロードせずに、タスクを同時に実行します-少なくとも20ページを同時に実行できるはずです(ただし、 、おそらく50〜100は問題なく実行できると思います)。(コメントからフォーラムからダウンロードする例を見てみましょう。これは、サーバーの生成に時間がかかる動的ページであり、他のユーザーがそのサイトの帯域幅を使用しているなどです)。インスタンスの帯域幅の制限に達するまで、並行性を増やし続けます。(もちろん、同じサイトに対して複数の同時リクエストを行わないでください)。
パフォーマンスを最大化しようとしている場合は、地理的に適切なゾーンでインスタンスを起動してレイテンシを最小限に抑えることを検討できます(ただし、すべてのURLを地理的に特定する必要があるため、実用的ではない場合があります)。
注意すべき点の1つは、インスタンスの帯域幅が可変であることです。場合によっては、より高いパフォーマンスが得られ、別の場合にはより低いパフォーマンスが得られます。小さいインスタンスでは、物理リンクがより多くのサーバーで共有され、それらのいずれかが使用可能な帯域幅を減少させる可能性があるため、パフォーマンスの変動はより大きくなります。EC2ネットワーク(同じアベイラビリティーゾーン)内のm1.largeインスタンス間では、理論上のギガビットスループットに近いはずです。
一般に、AWSでは、複数の小さなインスタンスではなく、大きなインスタンスを使用する方が効率的です(フェイルオーバーなど、複数のインスタンスが必要な場合を除いて)。
私はあなたの設定が何を必要とするのかわかりませんが、以前にこれを試みたとき(100万から200万のリンク、定期的に更新)、私のアプローチは、リンクが見つかったときに新しいリンクを追加し、プロセスを分岐するリンクのデータベースを維持することでしたページをこすって、解析します。URLが(ランダムに)取得され、データベースで進行中とマークされます。スクリプトはページをダウンロードし、成功した場合は、URLをデータベースにダウンロード済みとしてマークし、ページを解析した別のスクリプトにコンテンツを送信します。新しいリンク見つかったときにデータベースに追加されました。ここでのデータベースの利点は一元化でした。複数のスクリプトがデータベースに同時にクエリを実行でき、(トランザクションがアトミックである限り)各ページが一度だけダウンロードされることが保証されます。
いくつかの追加の注意点-一度に実行できるオンデマンドインスタンスの数には制限があります(20と思います)-これらの制限を超える予定がある場合は、AWSにアカウントの増加をリクエストする必要があります制限。スポットインスタンスを実行し、スポット価格が低いときに数値をスケールアップする方がはるかに経済的です(多分、すべてを整理しておくための1つのオンデマンドインスタンスと、残りのスポットインスタンス)。
時間の方がコストよりも優先度が高い場合、クラスターコンピューティングインスタンスは10 Gbpsの帯域幅を提供し、ダウンロード帯域幅が最大になります。
まとめ:(多くの小さなインスタンスの代わりに)いくつかの大きなインスタンスを試して、各インスタンスで複数の同時ダウンロードを実行します。帯域幅が制限されている場合はインスタンスを追加し、CPU /メモリが制限されている場合は大きなインスタンスに移動します。