コンテンツにスキップ
タイプアンロック
ステージフリート
難易度高度
ジョブマルチテナント SaaS
対象開発チーム
対象バックエンド開発者
サービスCron
サービスコンテナ
Hoody の利点コンテナ経済学
Hoody の利点HTTP ネイティブ
業界SaaS
タイプアンロック
ステージフリート
難易度高度
ジョブマルチテナント SaaS
対象開発チーム
対象バックエンド開発者
サービスCron
サービスコンテナ
Hoody の利点コンテナ経済学
Hoody の利点HTTP ネイティブ
業界SaaS
タイプアンロック
ステージフリート
難易度高度
ジョブマルチテナント SaaS
対象開発チーム
対象バックエンド開発者
サービスCron
サービスコンテナ
Hoody の利点コンテナ経済学
Hoody の利点HTTP ネイティブ
業界SaaS
タイプアンロック
ステージフリート
難易度高度
ジョブマルチテナント SaaS
対象開発チーム
対象バックエンド開発者
サービスCron
サービスコンテナ
Hoody の利点コンテナ経済学
Hoody の利点HTTP ネイティブ
業界SaaS
ユースケースに戻る
BYO cron / テナントごとのスケジュール

顧客に自分の cron スケジュールを持ち込んでもらう。

顧客が cron 表現を入力します。それを顧客のコンテナの crontab に POST します。フェアシェアする共有キューもなく、強制する最小間隔もなく、「ピーク時の月曜日になぜ自分のジョブが動かなかったのか」というサポートチケットもありません。

Cron API ドキュメントを読む

顧客があなたの UI に入力する。あなたが顧客のコンテナに POST する。

あなたの設定ページが入力フィールドをレンダリングします。テナントコンテナが Cron API を公開します。送信は 1 回の POST を転送します。グローバルスケジューラもなく、テナントごとのフィルタリングロジックもなく、「全顧客で最大 100 ジョブ」のキャップもありません。

your-backend → tenant-container
POST /users/root/entries
// フォーム送信は顧客の表現をそのまま中継します
POST https://acme-cron.hoody.com/users/root/entries
Content-Type: application/json

{
  "schedule": "0 9 * * 1-5",
  "command": "/jobs/sync_crm.sh",
  "comment": "Sync Salesforce contacts",
  "enabled": true
}
tenant-container → your-backend
201 Created
HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": "sch_8a3f1c",
  "schedule": "0 9 * * 1-5",
  "next_run": "2026-05-04T09:00:00Z",
  "enabled": true
}

// スケジュールはこのテナントの crontab にあり、それ以外の場所にはありません

Hoody Cron サービスは、マネージドエントリとユーザーごとの分離を持つ各テナントコンテナの中で動きます。スケジュールは、作業が動く場所に存在します。

BYO cron が共有スケジューラには不可能なものを提供する。

スケジュールが作業の隣に存在するとき、マルチテナントスケジューリングのルールは変わります。制約はローカル。影響範囲はローカル。機能はローカル。

共有キューなし

フェアキューイング税なし

奪い合うグローバルスレッドプールはありません。最も要求の厳しいテナントが毎分実行しても、静かなテナントを餓死させることはありません — 同じ crontab にいないからです。

セルフサービス

顧客がセルフサービス、あなたは検証しない

「あなたのティアで */1 * * * * は許可されているか?」のゲートキーパーをやめましょう。彼らのコンテナ、彼らの cron、彼らの CPU 請求書。サポート受信トレイは空になります。

コンテナバウンド

スケジュールはテナントとともに出荷される

テナントコンテナをスナップショットすれば、crontab もスナップショットされます。ロールバック、リストア、フォーク — スケジュールも一緒に動きます。同期する外部スケジューラ状態はありません。

共有マルチテナントスケジューラ vs コンテナバウンド cron。

違いは 3 つの場所に現れます: 顧客の体験、サポート負荷、エンジニアリングのサーフェス。

観点共有スケジューラBYO コンテナ cron
顧客が選べるもの
最小 5 分、平日のみ、同時実行不可ティアゲート、フェアシェアルール、ピーク時の延期
コンテナが処理できる任意の 5 フィールド cron 表現彼らが望むなら */1 * * * *。彼らの CPU が支払う
検証が行われる場所
あなたのコード、永続化前、グローバルキューモデルに対してregex + キャパシティチェック + ティアチェック + 重複チェック
コンテナの cron デーモンが表現をパース構文のみ。キャパシティはフリート全体ではなく 1 コンテナのもの
障害の影響範囲
1 つのテナントの遅いジョブが全員のキューを止めるノイジーネイバーインシデント、キュー深度のアラート
1 つのコンテナの cron が 1 つのテナントを遅らせるカーネルレベルの分離。フリートの残りは気づかない

この機能の共有スケジューラ版は注意書きの海です。BYO 版は 5 フィールドの入力ボックスです。

cron がテナントごとになると消えるもの。

グローバルキューを動かすのをやめた日に変わる 3 つの数字。それぞれが、もう書いたり運用したりする必要のない機能にマップされます。

  1. メンテナンスする検証ルール0

    ティアゲートの最小間隔も、テナントごとの最大ジョブ数も、フェアシェアのつまみもありません。コンテナが上限です。

  2. スケジュール作成あたりの POST1×

    顧客が入力し、あなたが転送し、コンテナがパースします。設定ページの送信はオーケストレーションではなく、単一の REST コールです。

  3. 顧客が所有するフィールド5

    分 · 時 · 日 · 月 · 曜日。さらにマクロ (@hourly、@daily)。あなたの DSL ではなく、標準 POSIX。

数値は BYO コンテナバウンドモデルを反映しています — 実際の cron エントリは、各コンテナの CPU と顧客のプランに応じてスケールします。

顧客の cron 表現は顧客のものであり、グローバルキューに対してあなたが検証するものではありません。

共有スケジューラBYO テナントごとの cron
変更前if (tier !== 'enterprise' && interval < 5min) reject()検証税: すべての顧客が最悪の顧客の分を支払った
変更後POST /users/root/entries → 201 Createdスケジュールは彼らのコンテナに存在する。彼らの CPU、彼らのルール
Cron API を見る

これが置き換えるもの。

BYO コンテナバウンド cron が静かに退役させるインフラストラクチャの要素。

  • 共有マルチテナントスケジューラフェアシェアするグローバルキューなし
  • テナントフィルタリング付き Quartzすべてのジョブ行に tenant_id カラムなし
  • カスタム cron-as-config UI顧客が入力し、コンテナがパースする
  • ベンダー管理 Airflow5 フィールド表現のための DAG サービスなし
  • スロットリング付き共有 Sidekiqテナント間のグローバルレートリミッターなし
  • テナントキュー付き BullMQ顧客ごとに世話をする Redis なし

他人のスケジュールのゲートキーパーをやめましょう。cron フィールドを彼らに渡し、作業を彼らのコンテナに渡してください。

ドキュメントを読む

他のユースケースを読む

夜間マイグレーションの直前にコンテナをスナップショット

02:55 UTC に発火する hoody-cron エントリが snapshots URL を curl し、アーティファクトに pre-migration-2026-05-04 という名前を付けます。5 分後にマイグレーションが実行されます。成功すればスナップショットは何もせずコストもかかりません。失敗した場合は、たった 1 つの PATCH で 30 秒以内に復元できます。

Cron·スナップショット

フリート規模で顧客ごとのサンドボックス

800 の顧客が 3 台のベアメタルサーバーに分散 — 定額の月額請求、顧客ごとのメーターなし。各テナントは独自のカーネル名前空間、ファイルシステム、URL を持つ本物のコンテナを取得します。ほとんどはほとんどの時間アイドル状態で、すでに支払っているサーバーに上乗せでかかる費用はゼロです。

コンテナ·スナップショット·Exec