113

良くも悪くも、LAMP Web アプリケーション全体を専用マシンからクラウド (Amazon EC2 マシン) に移行しました。これまでのところ順調に進んでいますが、cronの実行方法は最適ではありません。「Amazon 方式」を使用してクラウドで cron ジョブを最適に管理する方法について、Amazon 固有の質問があります。

問題: 複数の Web サーバーがあり、RSS フィードの作成、電子メールのトリガー、実際にはさまざまなことなど、バッチ ジョブのために cron を実行する必要があります。ただし、cron ジョブはデータベースに書き込むことが多いため、1 台のマシンでのみ実行する必要があり、複数のマシンで実行すると結果が複製されます。

これまでのところ、Web サーバーの 1 つを「マスター Web サーバー」として指定しました。これには、他の Web サーバーにはない「特別な」タスクがいくつかあります。クラウド コンピューティングのトレードオフは信頼性です。単一障害点になるため、「マスター Web サーバー」は必要ありません。マスター Web サーバーをクラスターから外さないことを忘れずに、それらをすべて同一にして、アップスケールおよびダウンスケールできるようにしたいと考えています。

アプリケーションを再設計して、Linux cron ジョブを単一障害点のない一時的な作業項目に変換するにはどうすればよいでしょうか?

これまでの私の考え：

  • cron の実行専用のマシンを用意します。これはもう少し管理しやすくなりますが、それでも単一障害点であり、余分なインスタンスを持つことでいくらかのお金を無駄にします.
  • 一部のジョブは、Linux cron からMySQL Eventsに移動できる可能性がありますが、アプリケーション ロジックをデータベース レイヤーに配置したくないので、私はこのアイデアの大ファンではありません。
  • おそらく、すべてのマシンですべてのcronを実行できますが、cronスクリプトを変更して、ロックメカニズムを実装する少しのロジックですべて開始し、1つのサーバーのみが実際にアクションを実行し、他のサーバーはスキップするようにします. 私はこのアイデアのファンではありません。バグが発生する可能性があるためです。また、独自のものを作成するよりも、Amazon のベスト プラクティスを使用することを好みます。
  • ジョブがどこかでスケジュールされ、キューに追加され、Web サーバーがそれぞれワーカーになり、「ねえ、これを取ります」と言うことができる状況を想像しています。Amazon Simple Workflow Serviceはまさにこの種のことのように聞こえますが、私は現在それについてあまり知りません。cron のような単純なものには、ちょっと重いように見えますか? それは適切なサービスですか、それともより適切な Amazon サービスはありますか?

更新:質問をして以来、 YouTube でAmazon Simple Workflow Serviceウェビナーを見て、34:40 に気づいた ( http://www.youtube.com/watch?v=lBUQiek8Jqk#t=34m40s )サンプル アプリケーションとして cron ジョブに言及しているスライド。ドキュメント ページ「Amazon SWF の AWS Flow Framework サンプル」で、Amazon は cron のサンプル コードがあると述べています。

... > Cron ジョブこのサンプルでは、​​実行時間の長いワークフローが定期的にアクティビティを実行します。実行を非常に長期間にわたって実行できるように、実行を新しい実行として継続する機能が実証されています。...

AWS SDK for Java ( http://aws.amazon.com/sdkforjava/ ) をダウンロードしましたが、いくつかの Java コード ( ) がフォルダーのばかげた層に埋もれていることを確認しました ( aws-java-sdk-1.3.6/samples/AwsFlowFramework/src/com/amazonaws/services/simpleworkflow/flow/examples/periodicworkflow)。

問題は、正直なところ、私のスキルセットで簡単に消化できるものではないため、これはあまり役に立たないことです. 同じサンプルが PHP SDK になく、プロセスを説明するチュートリアルもないようです。基本的に、私はまだアドバイスやヒントを探しています。

4

13 に答える 13

37

Amazon Gold サポートにサインアップして、この質問をしたところ、次のような回答がありました。

トム

私は何人かの同僚に簡単な調査を行ったところ、cron に空っぽの結果が表示されました。そこで、「分散 cron ジョブ ロック」を探したところ、Apache プロジェクトである Zookeeper への参照が見つかりました。

http://zookeeper.apache.org/doc/r3.2.2/recipes.html

http://highscalability.com/blog/2010/3/22/7-secrets-to-successfully-scaling-with-scar-on-amazon-by-se.html

また、TTL でロックを作成する方法として、memcached または同様のキャッシュ メカニズムを使用することへの言及も見ました。このようにしてフラグを設定し、TTL を 300 秒に設定すると、他の cron ワーカーはジョブを実行しなくなります。TTL の有効期限が切れると、ロックは自動的に解除されます。これは、昨日説明した SQS オプションと概念的に非常に似ています。

も参照してください。Google のぽっちゃり http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/chubby-osdi06.pdf

これが役立つかどうか教えてください。お気軽に質問してください。私たちのサービスが複雑で、初心者と経験豊富な開発者の両方にとって気が遠くなる可能性があることを十分に認識しています. アーキテクチャとベスト プラクティスのアドバイスを喜んで提供します。

よろしくお願いします、

Ronan G. アマゾン ウェブ サービス

于 2012-05-04T10:09:03.110 に答える
11

cron ジョブに SQS を使用する場合は注意してください。「1 つのマシンだけが 1 つのジョブしか認識しない」ことを保証するものではありません。「少なくとも1人」がメッセージを受け取ることを保証します。

から: http://aws.amazon.com/sqs/faqs/#How_many_times_will_I_receive_each_message

Q: 各メッセージは何回受信されますか?

Amazon SQS は、キュー内のすべてのメッセージを「少なくとも 1 回」配信するように設計されています。ほとんどの場合、各メッセージはアプリケーションに 1 回だけ配信されますが、メッセージを複数回処理してもエラーや矛盾が発生しないようにシステムを設計する必要があります。

これまでのところ、Gearman Job Server インスタンスがインストールされたインスタンスが 1 つあるソリューションについて考えることができます: http://gearman.org/。同じマシンで、cronjob タスクをバックグラウンドで実行するコマンドを生成する cron ジョブを構成します。次に、Web サーバー (ワーカー) の 1 つがこのタスクの実行を開始します。ワーカーの数は関係ありません (特に Auto Scaling を使用している場合)。

このソリューションの問題点は次のとおりです。

  • Gearman サーバーは、memcached や何らかのデータベースを使用するなど、分散ストレージで構成しない限り、単一障害点です。
  • 次に、複数の Gearman サーバーを使用して、cronjob を介してタスクを作成するサーバーを選択する必要があるため、再び同じ問題に戻ります。しかし、Gearman を使用してこの種の単一障害点に対処できる場合は、非常に優れたソリューションのように見えます。特に、そのために大きなインスタンスは必要ありません (この場合はマイクロ インスタンスで十分です)。
于 2012-08-03T10:14:14.477 に答える
4

「Amazon」の方法は分散することです。つまり、かさばる cron を多数の小さなジョブに分割し、適切なマシンに渡す必要があります。

タイプが FIFO に設定された SQS キューを使用して、それらを結合し、各ジョブが 1 台のマシンだけで実行されるようにします。また、マシンがスピンアップするまでキューがバッファリングされるため、障害も許容されます。

FIFO Exactly-Once Processing : メッセージは 1 回配信され、コンシューマーが処理して削除するまで利用可能です。重複はキューに入れられません。

また、これらの操作を「バッチ処理」する必要があるかどうかも検討してください。ある夜の更新が予想よりもかなり大きい場合はどうなりますか? 動的リソースを使用しても、十分な数のマシンがスピンアップするのを待って処理が遅れる可能性があります。代わりに、データを SDB に保存し、SQS を介してマシンに更新を通知し、その場で RSS フィードを作成します (キャッシュを使用)。

バッチ ジョブは、処理リソースが限られていて、「ライブ」サービスが優先されていた時代のものです。クラウドでは、これは当てはまりません。

于 2012-04-08T20:45:35.587 に答える
1

私たちがしていることは、ELB の背後にある Web アプリケーション クラスターの一部である特定のサーバーを 1 つ用意し、特定の DNS 名を割り当てて、その特定のサーバーでジョブを実行できるようにすることです。これには、そのジョブがそのサーバーの速度を低下させた場合、ELB がそのサーバーをクラスターから削除し、ジョブが終了して再び正常になると、それを返すという利点もあります。

チャンピオンのように機能します。

于 2014-06-24T15:04:48.130 に答える
1

Why would you build your own? Why not use something like Quartz (with Clustered Scheduling). See documentation.

http://quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigJDBCJobStoreClustering

于 2013-11-09T22:09:17.693 に答える
0

AWS 以外のサービスを使用したい場合は、Microsoft Azureをチェックしてみてください。Azure は優れたジョブ スケジューラを提供します。

于 2017-01-26T02:55:11.670 に答える