1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
コンテナ·スナップショット
タイプアンロックステージ本番環境難易度中程度ジョブコスト最適化対象開発チーム対象DevOps & インフラサービスコンテナサービススナップショットHoody の利点コンテナ経済学Hoody の利点スナップショット時間旅行
タイプアンロックステージ本番環境難易度中程度ジョブコスト最適化対象開発チーム対象DevOps & インフラサービスコンテナサービススナップショットHoody の利点コンテナ経済学Hoody の利点スナップショット時間旅行
use-cases / kill-the-staging-tax / hero
コンテナ · スナップショット · コスト
ステージングサーバー税を撲滅
ほとんどのチームは本番に支払い、それから本番らしき見た目のステージングスタックにもう一度支払います。Hoody ではステージングは本番コンテナのスナップショット — 必要なときに同じベアメタル上でブランチさせ、必要ないときはディスクへ凍結します。
billing.containers.hoody.com
https://billing.containers.hoody.com/staging-cost-audit監査 · 節約
以前 · 重複スタック以前支払っていたもの
- prod EC2 m5.large$70us-east-1 · 24×7$0.096/時 · × 730 時間
- staging EC2 m5.large$70us-east-1 · 24×7 アイドル$0.096/時 · × 730 時間
- RDS prod (db.t3.medium)$281Multi-AZ · 100 GB gp3$0.380/時 · × 730 時間
- RDS staging (db.t3.medium)$281本番からドリフト中$0.380/時 · × 730 時間
月間合計$702 / 月
以後 · 本番のスナップショット今支払う額
- prod コンテナ$49Hoody ベアメタル · 24×7$0.067/時
- staging-from-snapshot$0オンデマンドでブランチ · 約 12 時間/週差分のみ
- 2 台目のボックスなし · 2 台目の DB なし · ドリフトなし
月間合計$49 / 月
月間差分
−$65393% 節約
# 本番をスナップショットし、必要なときにそこからステージングをブランチcurl -X POST api/v1/containers/$PROD/snapshotscurl -X POST api/v1/containers/$PROD/copy -d '{"source_snapshot":"prod-baseline"}'
コピーオンライトベース共有 · 差分のみ支払い
ほとんどのチームがすでに持っているのに監査していない列の実測値
use-cases / kill-the-staging-tax / mechanism
3 つの呼び出し。1 つのスナップショット。重複スタックなし。
Hoody でスナップショットが安いのは、ストレージ層がコピーオンライトだからです。ベースイメージは参照され、コピーされません。ステージングは何かが分岐するまで本番のページを共有 — その後、差分だけが課金されます。
01
ステップ 01本番のスナップショットを取る
POST /containers/$PROD/snapshots にエイリアスを付けて送信。ベースイメージは参照されたまま、メタデータだけが新規。呼び出しは 1 秒以内にスナップショット名を返します。
02
ステップ 02そこからステージングをブランチ
POST /containers/$PROD/copy に source_snapshot=prod-baseline。新しいコンテナが同じハードウェア上で起動し、本番とページを共有します。書き込みは差分へ — ステージングは変更分のみ課金されます。
03
ステップ 03アイドル時に凍結
QA が完了したらステージングコンテナを停止。ディスクは保持され、RAM と CPU はゼロに。次のチケットが来たら 5〜15 秒で復元。各ブランチは既知の本番状態から始まるため、ドリフトは不可能です。
shell · Hoody Containers API に対して
POST · snapshot + copy# 1. 本番をスナップショット — 人間が見つけられるようエイリアスを付けるcurl -X POST https://api.hoody.com/api/v1/containers/$PROD/snapshots \ -H 'Authorization: Bearer $TOKEN' \ -d '{"alias":"prod-baseline","expiry":30}'# 2. その正確なスナップショットからステージングをブランチcurl -X POST https://api.hoody.com/api/v1/containers/$PROD/copy \ -d '{"target_project_id":"$STAGING","source_snapshot":"prod-baseline"}'→ 200 OK · ステージングコンテナが 5〜15 秒で起動、差分のみ支払い
スナップショットは日数の有効期限を持てて、クリーンアップは自動です。コピーは異なる target_project_id と target_server_id を選べるので、QA はレシピを変えずに別のリージョンやサブアカウントで動かせます。
use-cases / kill-the-staging-tax / powers
重複を捨てると解き放たれるもの
ステージングが並列レンタルではなくブランチになると、いくつもの繰り返される厄介事が消えます。請求書はその中でも最も目に見えるものに過ぎません。
予算
3 つではなく 1 つのスタック
本番、ステージング、QA は以前は別々に請求される 3 つのレンタルでした。今は必要なときに目覚める 1 つのコンテナと安価な 2 つのブランチです。限界環境はコピーではなく差分のコストです。
忠実度
ドリフトが不可能になる
各ステージングブランチは本物の本番スナップショットから始まります — 同じ OS イメージ、同じパッケージ、同じデータ形状、同じ環境変数。「ステージングでは動くが本番で壊れる」バグの分類は、構造によって閉じられます。
速度
数時間ではなく数秒で復元
PATCH でコンテナを古いスナップショットへ当てて不良デプロイをロールバック、または昨夜のバックアップから新鮮な QA コピーをブランチ。rsync も DB ダンプも 90 分のプロビジョニングジョブも不要 — スナップショット名 1 つです。
use-cases / kill-the-staging-tax / ledger
月次台帳、重複を取り除いた版
同じワークロード — 本番、ステージング、QA — を 2 通りで数えます。1 度は 3 つの完全レンタルとして、もう 1 度は 1 つのコンテナと 2 つのスナップショットブランチとして。
以前 · 重複スタック$702 / 月
EC2 m5.large 2 台が $0.096/時（730 時間）、加えて db.t3.medium Multi-AZ RDS 2 台が $0.380/時。ステージングは週の大半でアイドルだが、メーターは気にしない。
差分 · 支払われるもの差分のみ
ステージングは本番スナップショットからブランチ。共有ページは参照され、複製されない。QA 実行が実際に書き込んだバイトのみが課金され、通常 100 GB ではなく数百 MB。
以後 · 1 つのコンテナ$49 / 月
Hoody コンテナ 1 つが本番を 24×7 処理。ステージングと QA は仕事が必要なときにスナップショットから起き、必要ないときはディスクへ凍結。1 つの請求書、3 つの環境、ドリフトなし。
AWS 価格は 2026 年初頭の us-east-1 EC2 m5.large と RDS db.t3.medium Multi-AZ のパブリックオンデマンドレートを使用。Hoody コンテナ価格は説明用で、基盤サーバーに依存します（マーケットプレイス価格は月 $20 から）。スナップショットストレージは差分サイズで課金。表示数値は代表的な比較であり、見積もりではありません。
use-cases / kill-the-staging-tax / punchline
ステージングはかつて本番の重複でした。今は本番のスナップショットです。
以前 · 2 つのレンタル、1 つの目的本番をレンタル、ステージングをレンタル、手で同期EC2 が 2 台 · RDS が 2 台 · モニター 2 台 · 1 つはドリフトしたコピー
以後 · 1 つのコンテナ、多数のビュー$PROD をスナップショット → source_snapshot でコピーベース共有 · 差分のみブランチ · 構造的にドリフトフリー
use-cases / kill-the-staging-tax / replaces
これが置き換えるもの
チームがステージング税を払う標準的な方法。それぞれが、週の大半でアイドルか、必要なときには本番から離れている環境に対して請求します。
- AWS EC2 ステージング重複12 時間しか使わないのに月 730 時間請求される 2 台目の VM
- 並列 Heroku ステージング dynodyno + アドオンの請求、ほとんどの日でアイドル
- 環境層ごとの複数 VPS環境数に対して線形コスト — 3 ボックス、3 請求書
- カスタムドリフト検出ツールステージングと本番の差を見つけるためのツール
- 「ステージングは持たない」というリスク本番のブランチが高すぎたために出荷されてしまうバグ
- RDS ステージングレプリカ同期を保つ 2 台目のデータベース、24×7 でメーター稼働
use-cases / kill-the-staging-tax / cta
ドリフトする環境を借りるのはやめましょう。ドリフトできない環境をブランチしてください。
use-cases / kill-the-staging-tax / related
他のユースケースを読む
