Linuxのcronジョブを「Amazonの方法」に変換する方法は？

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

問題：複数のウェブサーバーがあり、RSSフィードの作成、メールのトリガーなど、実際にはさまざまなことを行うために、cronジョブを実行する必要があります。ただし、cronジョブはデータベースに頻繁に書き込み、複数のマシンで実行すると結果が重複するため、1つのマシンでのみ実行する必要があります。

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

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

これまでの私の考え：

• 実行中のcronのみに専用のマシンを用意します。これはもう少し管理しやすくなりますが、それでも単一障害点であり、余分なインスタンスを使用していくらかのお金を浪費します。
• 一部のジョブはLinux cronからMySQLイベントに移動される可能性がありますが、アプリケーションロジックをデータベースレイヤーに配置したくないので、このアイデアの大ファンではありません。
• おそらく、すべてのマシンですべての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から欠落しており、プロセスをウォークスルーするチュートリアルがないようです。基本的に、私はまだアドバイスやヒントを探しています。

私は彼らにこの質問をするためにAmazonゴールドサポートにサインアップしました、これは彼らの返答でした：

トム

私は同僚の何人かを簡単に投票し、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-scalr-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.アマゾンウェブサービス

私はこのビデオがあなたの正確な質問に答えると思います-cronjobs aws way（スケーラブルでフォールトトレラント）：

Amazon Simple WorkflowでクラウドでCronを使用する

ビデオでは、cronジョブを実装する特定のユースケースを使用してSWFサービスについて説明しています。

crontabから直接アクセスする場合、ソリューションの相対的な複雑さを飲み込むのは難しい場合があります。最後に、余分な複雑さがあなたに何をもたらすかを理解するのに役立つ事例研究があります。ケーススタディを見て、スケーラビリティとフォールトトレランスの要件を検討して、既存のcrontabソリューションから移行する必要があるかどうかを判断することをお勧めします。

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つがこのタスクの実行を開始し、1つだけがそれを実行することを保証します。ワーカーの数は関係ありません（特に自動スケーリングを使用している場合）。

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

• Gearmanサーバーは、たとえばmemcachedやデータベースなどを使用して分散ストレージで構成しない限り、単一障害点です。
• 次に、複数のGearmanサーバーを使用して、cronjob経由でタスクを作成するサーバーを1つ選択する必要があるため、再び同じ問題に戻ります。ただし、Gearmanを使用してこの種の単一障害点に対処できる場合は、非常に優れたソリューションのように見えます。特に、そのための大きなインスタンスは必要ありません（この場合、マイクロインスタンスで十分です）。

AmazonはElastic Beanstalkの新機能をリリースしました。ドキュメントから：

AWS Elastic Beanstalkは
、コンテナ名に「v1.2.0」を含むソリューションスタックで事前定義された構成を実行している環境で、ワーカー環境層の定期的なタスクをサポートします。」

これで、cron.yamlスケジューリングタスクを構成するファイルを含む環境を作成できます。

version: 1
cron:
- name: "backup-job"          # required - unique across all entries in this file
  url: "/backup"              # required - does not need to be unique
  schedule: "0 */12 * * *"    # required - does not need to be unique
- name: "audit"
  url: "/audit"
   schedule: "0 23 * * *"

メッセージキュー（SQS）を介して自動スケーリングされた環境で1回だけ実行するという保険を想像します。cronデーモンがイベントをトリガーすると、その呼び出しはSQSキューに入れられ、キュー内のメッセージは1回だけ評価されます。ドキュメントには、SQSに処理するメッセージが多い場合、実行が遅延する可能性があると述べています。

私はこの質問に3回目に遭遇し、私はチップインするつもりだと思いました。このジレンマはしばらくの間ありました。AWSにはまだ機能がありません。

私たちの場合、可能な解決策を検討した後、2つの選択肢があると判断しました。

• 一度に1回だけ実行する必要があるジョブを実行するcronjobサーバーをセットアップし、それを自動スケーリングして、特定のCloudWatch統計が本来あるべきでない場合に置き換えられるようにします。cloud-initスクリプトを使用してcronjobsを実行します。もちろん、これにはダウンタイムが伴い、cronjobsが失われます（特定のタスクを毎分実行している場合など）。
• を使用するロジックをrcron使用します。もちろん、魔法は実際にはrcronそれ自体ではなく、障害のあるノード（keepalivedここではここで使用）を検出して別のノードをマスターに「アップグレード」するために使用するロジックにあります。

私たちは2番目のオプションを選択することにしました。これは、それが非常に高速であり、これらのcronjobsを実行するWebサーバーで（AWSが登場する以前の時代に）すでに経験があるためです。

もちろん、このソリューションは特に、タイミングが決定要因である従来の1ノードのcronjobアプローチを置き換えることを目的としています（たとえば、「ジョブAを毎日午前5時に実行したい」、または「ジョブBが欲しい」のような場合毎分1回実行します」）。cronjobsを使用してバッチ処理ロジックをトリガーする場合は、実際にを確認する必要がありますSQS。アクティブ/パッシブのジレンマはありません。つまり、単一のサーバーまたは従業員全体を使用してキューを処理できます。またSWF、従業員のスケーリングについても検討することをお勧めします（ただしauto scaling、ほとんどの場合、そのトリックを実行できる場合もあります）。

他のサードパーティに依存することは避けたいものでした。

2016年2月12日、AmazonはAWS Lambdaを使用したSSHジョブのスケジュールについてブログに投稿しました。これで問題は解決したと思います。

すでにRedisサービスが稼働している場合、これは優れたソリューションのように見えます。

https://github.com/kvz/cronlock

続きを読む：http : //kvz.io/blog/2012/12/31/lock-your-cronjobs/

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

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

FIFOの 1回だけの処理：メッセージは1回配信され、コンシューマーが処理して削除するまで使用可能です。重複はキューに導入されません。

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

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

なぜあなたは自分のものを作るのですか？クォーツのようなものを使用しないでください（クラスター化スケジューリングを使用）。ドキュメントを参照してください。

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

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

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

cron式がAmazonの方法で機能することを確認する1つの方法は、eventsコマンドを使用してそれを実行することです。例えば：

aws events put-rule --name "DailyLambdaFunction" --schedule-expression "<your_schedule_expression>

スケジュール式が無効な場合、これは失敗します。

その他のリソース：https : //docs.aws.amazon.com/cli/latest/reference/events/put-rule.html

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

CloudWatchイベントについて誰も言及していないので、それはAWSがcronジョブを実行する方法であると思います。Lambda関数、ECSタスクなど、多くのアクションを実行できます。