4 ～ 5 個の Amazon-EC2 インスタンスで実行される Python で記述された Web スクレーパー (コマンドライン スクリプト) があります。
私がしていることは、これらの python スクリプトのコピーをこれらの EC2 サーバーに配置して実行することです。
そのため、次にプログラムを変更するときは、すべてのコピーに対してそれを行う必要があります。
したがって、冗長性、管理、および監視の問題を見ることができます。
したがって、冗長性を減らし、管理を容易にするために、コードを別のサーバーに配置して、そこから他の EC2 サーバーで実行し、これらの python プログラムを監視し、Django/Web インターフェイスを介して作成されたログを監視したいと考えています。このサーバー。
対処している問題が少なくとも 2 つあります。
そして、それぞれに異なるソリューションが必要です。
一般に、この種の割り当てにはタスク キューを使用することをお勧めします ( Amazon EC2 で実行されているCeleryを試してみましたが、非常に満足しています)。
タスク キューの利点の 1 つは、タスクを実際に実行するワーカーからタスクの定義を抽象化することです。したがって、タスクをキューに送信すると、可変数のワーカー (複数のワーカーを持つサーバー) がそれらのタスクを一度に 1 つずつ要求して処理します。アイドル状態の場合、各ワーカーはキューに接続し、何らかの作業を要求します。それ（タスク）を受け取ると、処理を開始します。その後、結果を送り返したり、別のタスクを要求したりします。
これは、多くのワーカーが時間の経過とともに変化する可能性があり、処理するタスクがなくなるまで自動的にキューからタスクを処理することを意味します。これの使用例は、コストを大幅に削減する Amazon のスポット インスタンスを使用することです。タスクをキューに送信し、X スポット リクエストを作成して、サーバーがタスクを処理していることを確認するだけです。価格が入札額を上回ったために、いつでもサーバーのアップダウンを気にする必要はありません。いいですね。
現在、これは暗黙的に監視を処理します。セロリにはキューと処理を監視するためのツールがあるため、django-celeryを使用して django と統合することもできます。
複数のサーバーへのコードの展開に関しては、Celery はそれをサポートしていません。この背後にある理由は、さまざまな性質のものです。たとえば、このディスカッションを参照してください。それらの1つは、実装が難しいということかもしれません。
なくても生活は可能だと思いますが、どうしても気になるなら比較的簡単なDIYの解決策があると思います。コードを VCS の下に置き ( Gitをお勧めします)、定期的に更新を確認してください。更新がある場合は、ワーカーを強制終了する bash スクリプトを実行し、すべての更新を行い、ワーカーを再起動して、より多くのタスクを処理できるようにします。障害を処理する Celerys の能力を考えると、これは問題なく機能するはずです。