各 SchedulerX アプリケーションは、デフォルトで最大 1,000 個のジョブをサポートしています。ワークロードで、それぞれ独自のトリガー時間を持つ数万個の個別にスケジュールされた定期ジョブが必要な場合、この制限によりデプロイメントがブロックされます。SchedulerX は、オートスケーリングと共有コンテナプールを提供し、エージェントに過負荷をかけることなく 1,000 個のジョブ制限を解除します。
個別の定期ジョブが必要な場合
SchedulerX の各定期ジョブは、独自のスケジュールで実行されます。MapReduce 分散ジョブは、MapReduce ジョブ内のすべてのタスクが同時に実行されるため、個別の定期ジョブを置き換えることはできません。次のシナリオでは、通常、10,000 ～ 100,000 個以上のスタンドアロンジョブが必要です。
| シナリオ | 個別のジョブが必要な理由 | スケール |
|---|---|---|
| IoT デバイス制御 | 各 IoT (Internet of Things) スイッチは、異なる時間にデバイスのオン/オフを切り替えます。スイッチごとに 1 つのスタンドアロンジョブが必要です。 | 10,000 ～ 100,000 個以上のジョブ |
| アラートルール評価 | モニタリングシステムは、1 分に 1 回アラートルールを評価します。複雑なルールは時間がかかり、次のトリガーサイクルをブロックする可能性があります。ルールごとに 1 つのスタンドアロンジョブを使用すると、処理の遅いルールが他のルールを遅延させるのを防ぎます。 | 10,000 ～ 100,000 個以上のジョブ |
| エンタープライズスケジューリングプラットフォーム | チームは SchedulerX 上に内部スケジューリングプラットフォームを構築し、ジョブ作成用の PoP API を公開します。採用が増えるにつれて、総ジョブ数は 100,000 個を超えます。 | 100,000 個以上のジョブ |
オートスケーリングと共有コンテナプールの仕組み
高いジョブ数をサポートするために、2 つのメカニズムが連携して機能します。
オートスケーリング -- アプリケーションのジョブ数が上限の 1,000 個に達すると、SchedulerX は自動的にサブアプリケーションを作成します。これにより、ジョブは複数の論理アプリケーションに分散され、一元的に管理されます。サブアプリケーションを手動で管理する必要はありません。
共有コンテナプール -- デフォルトでは、各ジョブトリガーは実行のために独自のコンテナプールを割り当てます。10,000 個以上のジョブでは、これによりエージェントのメモリと CPU が急速に枯渇し、エージェントが応答不能になります。共有コンテナプールを有効にすると、すべてのジョブが単一のコンテナプールを共有できるため、ジョブ数に関係なくリソース使用量が有界に保たれます。
Without shared pool (default): With shared pool:
Job 1 trigger → Container pool 1 Job 1 trigger ─┐
Job 2 trigger → Container pool 2 Job 2 trigger ──┤
Job 3 trigger → Container pool 3 Job 3 trigger ──┼→ Shared container pool (size: 128)
... ... ... │
Job N trigger → Container pool N Job N trigger ─┘
→ Agent memory exhausted → Bounded resource usageオートスケーリングと共有コンテナプールの有効化
この手順では、例として Spring Boot アプリケーションを使用します。他のアプリケーションタイプについては、[クイックスタート] > SchedulerX にエージェントを接続する をご参照ください。
ステップ 1: オートスケーリングのリクエスト
自動スケーリングはセルフサービスではありません。アプリケーションで有効にするには、SchedulerX テクニカルサポートにお問い合わせください。
オートスケーリングが有効になると、アプリケーションのジョブ数が 1,000 個に達するたびに、SchedulerX はサブアプリケーションを作成します。
ステップ 2: エージェントバージョンの確認
ご利用の pom.xml ファイルを開き、SchedulerX エージェントの依存関係バージョンが 1.2.1 以降であることを確認します。
1.2.1 より前のエージェントバージョンは、共有コンテナプールをサポートしていません。バージョンが古い場合は、続行する前に依存関係宣言のバージョン番号を更新してください。
ステップ 3: 共有コンテナプールの有効化
次のプロパティを Spring Boot 設定ファイル (例: application.properties) に追加します。
# Enable the shared container pool so all jobs reuse a single pool
spring.schedulerx2.shareContainerPool=true
# Set the size of the container pool
spring.schedulerx2.sharePoolSize=128| プロパティ | 説明 |
|---|---|
spring.schedulerx2.shareContainerPool | true に設定すると、すべてのジョブが独自のプールを作成する代わりに、1 つのコンテナプールを共有します。 |
spring.schedulerx2.sharePoolSize | 共有コンテナプールのサイズを指定します。例の値は 128 です。 |
共有コンテナプールが有効になっていない場合、各ジョブトリガーは独自のコンテナプールを作成します。10,000 個以上のジョブでは、これによりエージェントのメモリと CPU が急速に枯渇し、エージェントが応答不能になります。
本番環境でのベストプラクティス
プールサイズの調整
設定例に示すように、プールサイズを 128 から開始し、エージェントの CPU とメモリ使用量を監視します。ジョブの特性とリソース消費量に基づいて調整してください。
ジョブスケジュールの分散
トリガー時間が同じ秒に集中しないようにしてください。数千個のジョブが同じ CRON 式 (例: 毎分 0 秒の 0 * * * * ?) を共有すると、すべて同時に起動し、エージェントにバースト負荷がかかります。
CRON 式を異なる秒に分散します。
# Instead of all jobs at second 0:
0 * * * * ? # All 10,000 jobs fire at :00
# Spread across 60 seconds:
0 * * * * ? # Jobs 1-167 fire at :00
1 * * * * ? # Jobs 168-334 fire at :01
2 * * * * ? # Jobs 335-501 fire at :02
...
59 * * * * ? # Jobs 9834-10000 fire at :59これにより、負荷が時間的に均等に分散され、エージェントのピーク時の同時負荷が軽減されます。
サブアプリケーション作成の監視
ジョブ数が増加したときにサブアプリケーションが期待どおりに作成されていることを確認するために、SchedulerX コンソールを定期的に確認してください。
ジョブ実行失敗の処理
ジョブ数が多い場合、個々のジョブの失敗は予期されます。リトライが重複する副作用を生じさせないように、ジョブを冪等に設計してください。処理の遅いジョブが共有コンテナプールをブロックしないように、適切なタイムアウト値を設定してください。
クォータと制限
| 項目 | 値 | 備考 |
|---|---|---|
| アプリケーションあたりのジョブ数 (オートスケーリング前) | 1,000 | この制限を超えるにはオートスケーリングを使用します |
| 共有コンテナプールの最小エージェントバージョン | 1.2.1 | 以前のバージョンはこの機能をサポートしていません |
| 共有コンテナプールサイズ (設定例) | 128 | sharePoolSize プロパティで設定可能 |
オートスケーリングを有効にし、合計ジョブ数を 1,000 超に増やすには、SchedulerX テクニカルサポートにお問い合わせください。