AWSサービスを使用して長時間実行するタスクをスケジュールする

Question

私のアプリケーションはAWSサービスに大きく依存しており、私はそれらに基づいて最適なソリューションを探しています。 Webアプリケーションはスケジュールされたジョブをトリガします（無限に繰り返されると仮定します）。実行するには一定量のリソースが必要です。タスクのシングルランは通常最大1分かかります。

現在のアイデアは、SQS経由でジョブを渡し、キューサイズに応じてEC2インスタンスでワーカーを生成することです。 （この部分は多かれ少なかれ分かります） しかし、私は実際に特定の間隔でジョブをトリガするための適切な解決策を見つけるのに苦労しています。我々は10000のジョブを扱っていると仮定します。だから、スケジューラが10k cronジョブを実行するには（ジョブそのものはシンプルで、SQSを介してジョブの説明を渡すだけです）、同時にクレイジーなアイデアのように思えます。実際の質問は、スケジューラ自体をオートスケールする方法です（スケジューラが再起動されるシナリオ、新しいインスタンスが作成されるなど）。 スケジューラがアプリとして冗長であり、AWSラムダ機能（またはスケジューリングを提供する他のサービス）に依存することが賢明ですか？ラムダ関数を使用する際の問題は一定の制限であり、単一機能で提供される128MBのメモリは実際には多すぎます（20MBはそれ以上のものです）

また、ワーカー自身も一定の時間待ってジョブをもう一度トリガするスケジューラ周波数が1時間の場合のは、言ってみましょう：

1. Scheduler sends job to worker 1 
2. Worker 1 performs the job and after one hour sends it back to Scheduler 
3. Scheduler sends the job again 

ここしかしその労働者の可能性が、私はこれだろう軽量スケジューラを達成しようとしています

ボトムラインでスケーリングを取得されますされている問題。自動スケーリングを必要とせず、ジョブ記述を送信する唯一の目的のハブとして機能します。サービスの再起動時には抑制されるべきではありません。

Answer 1

ラムダはこれに最適です。短期間のプロセスが多い（約1分）、ラムダは短いプロセス（最近5分まで）です。 CPU速度がRAMに直線的に結合されていることを知ることは非常に重要です。 1GBのラムダ関数はt2.microのインスタンスに相当し、正しく呼び出すと1.5GBのRAMは1.5倍のCPU速度を意味します。これらの機能のコストは非常に低く、これを実行するだけです。 128MBのRAMはマイクロインスタンスの1/8のCPU速度を持っているので、実際にそれらを使用することはお勧めしません。

キューイングのメカニズムとして、S3を使用することができます（その通りです）。バケットを作成し、オブジェクトが作成されたときにラムダワーカーをトリガーさせます。ジョブをスケジュールする場合は、ファイルをバケット内に配置します。ラムダはそれをすぐに開始して処理します。

ここでいくつかの制限を尊重する必要があります。この方法で同時に100人の作業者（アクティブなラムダインスタンスの総量）しか持てませんが、AWSにこれを増やすよう依頼することができます。

• 0.005 1000年あたりのPUTリクエストなので、万のジョブ要求につき$ 5（これはSQSよりも高価である）：次のように

  コストがあります。

• ラムダ・ランタイム。通常のt2マイクロCPUの速度（1GB RAM）を仮定すると、これはジョブごとに$ 0.0001（60秒、最初の300.000秒はフリー= 5000ジョブ）です。
• ラムダ要求。百万回のトリガーあたり$ 0.20

この設定では、サーバーは一切必要ありません。これはダウンできません（AWS自体が行う場合のみ）。