1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
コンテナ·スナップショット
use-cases / recurring-webhook-replay / hero
CRON · FILES · EXEC
今朝の webhook を、明日の同じ時刻にリプレイ
本物の Stripe webhook を hoody-files の URL に 30 分間向けます。ディレクトリには 14 個の JSON ファイルが入ります。本番に届いたペイロードがバイト単位でそのまま揃っています。1 つの cron エントリが exec スクリプトを動かし、月曜から金曜の 9 時にステージングへ POST し直します。スケジュールは次の土曜日に失効し、自分で消えます。
files.containers.hoody.com · 2026-05-03
https://files.containers.hoody.com/webhooks/2026-05-03live · fs
/ webhooks / 2026-05-0314 ファイル · 33.6 KB
- stripe-08-04-11.json2.1 KB
- intercom-08-09-44.json1.4 KB
- stripe-08-12-02.json2.0 KB
- stripe-08-15-22.json2.3 KB
- intercom-08-19-01.json1.7 KB
- github-08-22-30.json4.8 KB
- stripe-08-25-17.json2.2 KB
- intercom-08-32-11.json1.5 KB
- github-08-37-49.json5.1 KB
- stripe-08-41-05.json2.0 KB
stripe-08-15-22.jsonプレビュー
{ "id": "evt_3OHk8ZJs2k9aXq1vQ", "type": "payment_intent.succeeded", "created": 1714723522, "data": { "object": { "id": "pi_3OHk8ZJs2k9aXq1v0K7rT4mB", "amount": 4900, "currency": "usd", "status": "succeeded" } } }
0 8-18 * * * bash /scripts/replay.sh /webhooks/2026-05-03次回リプレイまで 14m 22s
本物の webhook がキャプチャ · cron エントリ 1 つでリプレイ
use-cases / recurring-webhook-replay / pipeline
一度キャプチャし、ファイルとして保存し、スケジュールでリプレイ
全体の流れは URL が 3 つだけです。本番トラフィックがキャプチャ URL に到着します。ファイルは hoody-files に置かれます。cron がフォルダを巡回し、本文をステージングへ POST し直します。ブローカーもキューもリプレイサービスもありません。ディレクトリとスケジュールだけです。
PIPELINEブローカーなし · キューなし
01 · CAPTURE
本番 webhook が PUT になります
Stripe / Intercom / GitHub の webhook URL を hoody-files のパスに設定します。各イベントは PUT として届き、タイムスタンプを名前にした JSON ファイルとして保存されます。ディレクトリそのものが録画です。
02 · PERSIST
1 日 1 フォルダ、URL でアドレス可能
ファイルはディスクに永続化され、各ファイルに独自 URL が付きます。ブラウザでディレクトリを閲覧したり、API でリストしたり、curl でシェルアクセスできます。録画は cat、scp、バージョン管理できる事実です。
03 · REPLAY
1 つの cron エントリがフォルダを巡回
スケジュール 0 9 * * 1-5、コマンド bash /scripts/replay.sh /webhooks/2026-05-03 で管理 cron エントリを POST します。スクリプトはディレクトリを一覧し、各ファイルをタイムスタンプ順でステージングに POST し直します。
キャプチャとリプレイは、別の日に走る同じプロトコルです。バイトを記録した仕組みが、そのまま再生する仕組みになります。学ぶべき JSONL パーサーもサイドカーも録画フォーマットもありません。フォルダの中のファイルが、時系列順に並んでいるだけです。
use-cases / recurring-webhook-replay / mechanism
POST 2 つとフォルダ 1 つ
キャプチャは webhook イベントごとの PUT 1 回。リプレイは cron API への POST 1 回。Hoody Files が録画を保持し、Hoody Cron がスケジュールに沿って巡回し、hoody-exec が POST を行う bash スクリプトを実行します。3 つのサービス、間に貼り付けるグルーコードはありません。
stripe → hoody-files
PUT · capture# point your real webhook at hoody-files curl -X PUT \ https://files.containers.hoody.com/webhooks/2026-05-03/stripe-08-15-22.json \ --data-binary @- # 30 minutes later, the directory holds 14 files HTTP/1.1 201 Created webhooks/2026-05-03/stripe-08-15-22.json
リプレイをスケジュール
POST · cron entry# one cron entry replays the morning at 9am, mon-fri curl -X POST \ https://cron.containers.hoody.com/api/v1/cron/users/me/entries \ -d '["schedule":"0 9 * * 1-5","command":"bash /scripts/replay.sh /webhooks/2026-05-03","expires_at":"2026-05-10T09:00:00Z"]' HTTP/1.1 201 Created { "id":"f0a8", "schedule":"0 9 * * 1-5", "expires_at":"2026-05-10T09:00:00Z" }
キャプチャ側は金曜の朝に 1 度だけ動きます。リプレイ側は次の土曜まで毎平日動き続け、cron エントリの expires_at フィールドがスケジュールを削除します。webhook 設定に PUT URL を 1 つ書き、cron API に POST を 1 回投げる。それで負荷テストの全体です。
use-cases / recurring-webhook-replay / powers
負荷テスト用フィクスチャでは得られないもの
合成トラフィックは、リクエストがどう見えるかを想像したものです。キャプチャ済みトラフィックは、実際に届いたものです。同じフィールド名、同じエッジケース、同じ意外性です。
FIDELITY
想像ではなく、本物のペイロード形状
録画には Stripe が送ったままの JSON が記録されています。null になり得る各フィールド、想定外のイベント種別、忘れていた customer_id の形式まで含まれます。あなたのハンドラは、昨日失敗したのと同じペイロードに再び向き合えます。
TIMING
本番と同じ時間帯の負荷
cron 式 0 9 * * 1-5 は、本物のユーザーが実際にシステムを使う時間帯にリプレイを着地させます。テスト中のハンドラは、同じキャッシュ、同じ cron の隣人たち、同じ騒がしい DB を相手にした朝のラッシュを目にします。
REPEATABILITY
バグが消えるまで何度でもリプレイ
フォルダはイミュータブルで、cron は expires_at まで毎平日動きます。火曜の実行でハンドラがまだ落ちるなら、修正して水曜の実行に証明させます。入力は毎回同じ、変わるのはハンドラだけです。
use-cases / recurring-webhook-replay / capacity
スケジュールが約束するもの
数字は Hoody Cron の管理エントリ API と標準 cron 式仕様に基づきます。架空のベンチマークではありません。
- FIELDS PER ENTRY5
標準の 5 フィールド cron 式: 分、時、日、月、曜日。1985 年に使った構文が、2026 年も同じようにリプレイをスケジュールします。
- ENTRIES PER PAGE200
GET /users/[user]/entries は最大 200 件の管理エントリを 1 ページで返します。1 環境あたり 63 個のリプレイスケジュールでも余裕です。
- POST TO CREATE1
POST /users/me/entries 1 回で、スケジュール、コマンド、expires_at を指定して定期リプレイを作成できます。後で PATCH してミュート、DELETE で廃止、expires_at に任せれば自動廃止です。
Hoody Cron Managed Entries API の仕様: 標準 5 フィールド cron 式と @daily / @hourly マクロ、1 ページあたり最大 200 エントリのページネーション、expires_at はオプションで、期限を過ぎるとエントリを自動的に無効化します。
use-cases / recurring-webhook-replay / punchline
本番トラフィックを 1 度録画し、スケジュールでリプレイ。
キャプチャ · 金曜 08:00リプレイ · 月曜から金曜 09:00
WHAT THE OLD LOAD TEST LOOKED LIKEk6 スクリプト · faker · 想像のペイロード形状stripe が送るものに対するあなたの推測 · 四半期ごとに再推測
WHAT IT LOOKS LIKE NOWPUT files/webhooks/[day] · POST cron/entries 0 9 * * 1-5本番に届いた本物のバイト · 1 つのスケジュールでリプレイ
use-cases / recurring-webhook-replay / replaces
これが置き換えるもの
webhook トラフィックをリプレイするための定番ツール群、レコーダー、リプレイサービス、スケジュールモック。それぞれ SaaS、サイドカー、面倒を見るスクリプトのいずれかです。hoody-files + hoody-cron の組み合わせは、そのどれでもありません。
- ngrok webhook recordingディスクに書けば済むリクエストを記録するための SaaS プラン
- Hookdeck event replaysフォルダのファイルで済むことのための、イベントルーティングサービス
- カスタムリプレイスクリプト1 度書いてスケジュール方法を忘れる、つなぎ合わせのコード
- Postman scheduled mocks自分のステージングに HTTP を打ち込むためのモニターシート
- テスト環境のモックサーバー本物のバックエンドと並行して維持する第二のバックエンド
- 手動の webhook ファジング9 時にターミナルでペイロードを貼り付ける、あなた本人
use-cases / recurring-webhook-replay / cta
金曜のトラフィックをキャプチャ。来週のリプレイをスケジュール。実験が終わったら cron エントリ自身に失効させましょう。
use-cases / recurring-webhook-replay / related
他のユースケースを読む
