Amazon EC2 + S3 + Python +スクレイピング-これを行う最も安価な方法は？
私はAmazonsAWS製品を利用しましたが、これを高レベルで説明してください-私が正しく考えている場合。
そのため、ローカルマシンにPythonスクレイピングスクリプトがほとんどありません。AWSを使用して、超高速のインターネット接続と低価格を実現したいと考えています。勝つ/勝つ！
EC2にcentOS/Ubuntuインスタンスをデプロイできることを理解しています。必要なPythonライブラリをインストールします。コストを節約するためにboto（Python）を使用してインスタンスを開始および停止します。これまでのところ正しい考えですか？（実行可能ですか？）
後で解析するためにHTMLファイルのフェッチ（スクレイピング）を開始するスクリプトをいくつかCRONします。したがって、これらのHTMLファイルはストレージ用にS3にコピーされます（または、MySQLで解析および保存する方法であるため、ローカルマシンにダンプしますか？）。
サービスについて数時間読んだりグーグルしたりして、自分の仮定とAWSに関する知識がほとんどないことに意味があるかどうかアドバイスしてください。
セットアップの基本的な前提は問題ないようですが、考慮したい項目がいくつかあります。
まず、EC2ネットワーク（およびI/O）の帯域幅はインスタンスタイプに依存します。 t1.microインスタンスの使用を希望している場合は、「超高速インターネット接続」を期待しないでください。m1.smallを使用しても、期待するパフォーマンスが得られない場合があります。また、EC2で使用される帯域幅（インスタンス時間だけでなく）に対して料金を支払うことにも注意してください。
最初のポイントに関しては、EC2インスタンスでPythonを設定するのに実際の問題はないはずです。ただし、インスタンスを調整することで潜在的な問題が発生します。たとえば、インスタンスが2つある場合実行中、タスクをそれらの間でどのように分割しますか？各インスタンスは他のインスタンスが何をしたかをどのように「認識」しますか（URLのリストを手動でパーティション化する予定はないと仮定します）。さらに、インスタンスを起動する場合は、 EC2インスタンスのうちの1つがそれを処理するか、ローカルマシンがそれを処理します（EC2インスタンスの1つである場合、どのインスタンスがタスクを担当するかをどのように決定しますか（つまり、「起動」タスクが実行されないようにするため）すべてのインスタンスごとに）、新しいインスタンスを含めるためにタスクをどのように再配布しますか？どのインスタンスを自動的に終了するかをどのように決定しますか？
間違いなく、上記のすべて（corosync/heartbeat、ペースメーカー、自動スケーリングなど）は可能ですが、最初は見落としがちです。とにかく、「ベストプライス」を探している場合は、（オンデマンドではなく）スポットインスタンスを使用することをお勧めしますが、それを機能させるには、かなり堅牢なアーキテクチャが必要です。 （スポット価格は大幅に変動することに注意してください-オンデマンド価格を超えることもあります。作業している時間スケールに応じて、低い上限スポット価格を設定するか、最適なアプローチを決定する必要があります（スポット/オンデマンド）定期的（時間単位）でコストを最小限に抑えます。）現時点では確認できませんが、最も簡単な（そして最も安価な）オプションはAWSの自動スケーリングかもしれません。 Cloudwatchアラームを設定する必要があり（ただし、Cloudwatchは10個の無料アラームを提供します）、自動スケーリング自体に関連するコストはありません（新しいインスタンスのコストとCloudwatchのコストを除く）。
あなたの取り組みの範囲が本当にわからないので、解析と処理にEC2を使用しないのはなぜかと疑問に思うかもしれません。特に、解析が複雑で、ページを処理するよりも速くフェッチでき、ページ数が多い場合（おそらく、そうでなければAWSをセットアップする作業を行わないでしょう）、次のようになります。 EC2のページを単純に処理し、すべてが完了したら、データベースのダンプをダウンロードする方が効率的です。おそらく、これは物事を少し単純化するかもしれません-1つのインスタンスでMySQLを実行し（データはEBSボリュームに保存されます）、各インスタンスはMySQLインスタンスに次のレコードセットを照会し（おそらくそれらを予約済みとしてマークします）、フェッチして処理します、データをMySQLに保存します。
EC2でMySQLを実行しない場合は、前述のようにHTMLファイルをS3に保存するか、EBSボリュームに保存することができます。 S3の利点は、ストレージを事前に割り当てる必要がないことです（特に、処理するデータのサイズがわからない場合に便利です）。PUT/ GETとストレージの料金を支払います。欠点は速度です-S3はファイルシステムとして使用することを意図しておらず、（ファイルシステムとしてマウントすることはできますが）個々のファイルをS3に保存することはかなり非効率的です（あなたが蓄積したいと思うように）いくつかのページとそれらはS3）にそれらをアップロードします。さらに、大量のファイル（数万）がある場合、すべてのファイル名などをフェッチする処理が遅くなる可能性があります。 EBSボリュームは、インスタンスに接続されたストレージとして使用することを目的としています-利点は速度にあります-転送速度と「ファイルシステム」があるという事実の両方（したがって、ファイルのリストなどの読み取りが高速です）-EBSボリュームはそれを超えて持続しますインスタンスの終了（デフォルトでは実行されない（ただし、実行可能）EBSルートボリュームを除く）。 EBSボリュームの欠点は、ストレージの量を事前に割り当てる必要があることです（オンザフライで変更することはできません）-そして、その量のストレージに対して支払います（すべてが使用されているかどうかに関係なく）。 I/O操作にも料金がかかります（また、EBSボリュームのパフォーマンスはネットワーク速度に依存するため、インスタンスが大きいほどEBSのパフォーマンスが向上します）。 EBSのもう1つの利点は、ファイルシステムであるため、ファイルをgzipするなどのタスクを非常に簡単に実行できることです（多くのhtmlページをダウンロードする場合は、後でS3の個々のファイルをフェッチしたくないと思います）。 ）。
私は実際には可能性について推測するつもりはありませんが（非常に大規模では、map-reduce/hadoopのようなものがこの種のタスクを管理するために使用されることを覚えておいてください）、パーティション分割のアプローチがある限りタスク（例：MySQLインスタンス）とインスタンスのスケーリングの管理（例：自動スケーリング）、あなたが持っているアイデアはうまくいくはずです。
SQSを介して別のインスタンスと対話できます。そのキューイングサービス。入力URLをSQSにキューイングできます。各インスタンスは、SQSから順番にURLを取得します。ただし、SQSは複数のインスタンスに同じ入力を提供しません。それがここでの主な利点です。