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

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

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

Cron API ドキュメントを読む
use-cases / byo-cron-per-tenant / mechanism

顧客があなたの 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 サービスは、マネージドエントリとユーザーごとの分離を持つ各テナントコンテナの中で動きます。スケジュールは、作業が動く場所に存在します。

use-cases / byo-cron-per-tenant / powers

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

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

共有キューなし

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

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

セルフサービス

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

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

コンテナバウンド

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

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

use-cases / byo-cron-per-tenant / compare

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

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

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

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

use-cases / byo-cron-per-tenant / support

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

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

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

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

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

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

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

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

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

use-cases / byo-cron-per-tenant / punchline

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

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

これが置き換えるもの。

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

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

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

ドキュメントを読む
use-cases / byo-cron-per-tenant / related

他のユースケースを読む

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

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

Cron·スナップショット

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

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

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