1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
コンテナ·スナップショット
タイプアンロックステージ本番環境難易度中程度ジョブストリームを共有対象バックエンド開発者対象DevOps & インフラサービスパイプHoody の利点HTTP ネイティブHoody の利点コンテナ経済学
タイプアンロックステージ本番環境難易度中程度ジョブストリームを共有対象バックエンド開発者対象DevOps & インフラサービスパイプHoody の利点HTTP ネイティブHoody の利点コンテナ経済学
use-cases / move-200gb-between-clouds-with-two-curls / hero
PIPE · クラウド間マイグレーション
2 つの curl でクラウド間で 200GB を移動
フランクフルトの 200GB の Postgres バックアップ。シンガポールの新しいボックス。S3 のラウンドトリップをスキップ。1 つの curl が pg_dump を Hoody パイプ URL にパイプ; 反対側の 1 つの curl が直接 psql にストリーム。バイトは飛行中で、決して停止しない。
src.frankfurt:~
ソース · ライブ
eu-fra-1 · フランクフルト# stream the dump out$ pg_dump db | gzip \ | curl -T - https://pipe.../migration[INFO] Streaming to 1 receiver(s)...
pipe/migration
dst.singapore:~
宛先 · 準備完了
ap-sin-1 · シンガポール# pipe straight into psql$ curl https://pipe.../migration \ | gunzip | psql newdb[INFO] Transfer complete.
200GB · ホップゼロ · 保持ゼロ
use-cases / move-200gb-between-clouds-with-two-curls / mechanism
バケットではない。ルーターだ。
Hoody Pipe は HTTP サーバー上の名前付きパス。送信側がそこにストリームを PUT し、受信側が同じパスを GET し、サーバーは 2 つを継ぎ合わせる。ディスクには何も書かれない; パイプは設計上 0 バイトを保持する。
2 つの curl の間のバイト5 分 TTL · ストレージレイヤーなし
01 · 送信側
パスに PUT
ソースボックスから、pg_dump | gzip | curl -T - をパイプ URL に。PUT ボディは TCP のバックプレッシャーが許す限り高速にストリーミング。サーバーは同じパスに受信側が現れるまでコネクションを保持する。
PUT /api/v1/pipe/migration02 · ルーター
メモリ内でスプライス
受信側の GET が同じパスに到着すると、Hoody はアップロードのバイトをダウンロードのレスポンスに直接スプライスする。バッファなし、オンディスクのステージングなし、非同期コミットなし — 2 つの HTTP ソケット間の直接ストリームのみ。
ディスク 0 バイト03 · 受信側
ストリームとして GET
宛先ボックスから、curl がパスを GET し、レスポンスを gunzip | psql 経由でパイプ。受信側のストリームは送信側の最後のバイトが届いた瞬間に終わる。再試行なし、マニフェストなし、クリーンアップなし。
GET /api/v1/pipe/migrationコネクションの順序は問題ではない — 受信側は最初に curl して送信側が接続するまでブロックできる (またはその逆)、5 分のパイプ TTL まで。バックプレッシャーはエンドツーエンドで流れる: 遅い psql はソースの curl をスロットリングする。あふれるキューはない、なぜならキューがないから。
use-cases / move-200gb-between-clouds-with-two-curls / commands
実際の 2 つのコマンド
これらは擬似コードではない。2 つのサーバーで 2 つのターミナルを開き、それぞれ 1 つを実行し、200GB のバックアップが 1 つのクラウドを離れて別のクラウドに着地するのを見る。
frankfurt:~ · 送信側
PUT · 送信側フランクフルト → パイプ
# 1. Stream the live database to the pipe$pg_dump --format=custom mydb | gzip \ | curl -T - https://pipe.containers.hoody.com/api/v1/pipe/migration# 2. The server replies with status messages[INFO] Waiting for 1 receiver(s) to connect...[INFO] Streaming to 1 receiver(s)...[INFO] Upload complete.[INFO] Transfer complete.
singapore:~ · 受信側
GET · 受信側パイプ → シンガポール
# 1. Pipe straight into the new database$curl https://pipe.containers.hoody.com/api/v1/pipe/migration \ | gunzip | psql newdb# 2. Bytes hit psql as they leave FrankfurtCREATE TABLE okCOPY 4823918 okALTER TABLE ok
PUT (curl -T) は curl がストリームをアップロードしたい方法なので推奨される。POST も同じように動作 — 同じパス、同じステータスメッセージ。同じダンプを多くの受信側にファンアウトする必要がある場合は両側で ?n=N を使用。
use-cases / move-200gb-between-clouds-with-two-curls / spectator
進捗 · ?progress
誰でも見られるスペクテーター URL
3 台目のラップトップが ?progress 付きで同じパイプ URL を開き、毎秒バイト数、ETA、接続済み受信側のリアルタイム SSE フィードを取得する。観戦は受信側スロットを消費しない — 50 人のチームメイトが n の値を変更したり転送に干渉したりすることなくマイグレーションを観察できる。
- 受信側スロットなし
- 最大 50 観戦者
- 30 分リンガー
spectator.…hoody.com/migration?progress
SSE · text/event-streamストリーミング中
event: statedata: ["state":"streaming","receivers":1]event: progressdata: ["bytes":83_421_667_840, "speed":"412 MB/s", "eta":"4m 44s"]event: progressdata: ["bytes":118_295_117_824, "speed":"406 MB/s", "eta":"3m 21s"]↻ ライブ · 250ms スロットル
use-cases / move-200gb-between-clouds-with-two-curls / why
2 つの curl が 6 ステップに勝る理由
S3 のラウンドトリップはホワイトボード上ではシンプルに見える。本番では、すべて秒単位で課金される可動部品のスタック。パイプはスタック全体をトランスポート自体に折りたたむ。
3 番目のストレージレイヤーなし
S3、GCS、Azure Blob — ラウンドトリップは、バイトを置く場所が他になかったから存在しただけ。パイプはパスだ。プロビジョニングしたり、ライフサイクルルールを設定したり、後でスクラブしたりするバケットはない。
停止ではなく飛行に支払う
アップロードのエグレス、ダウンロードのエグレス — 2 倍。パイプではバイトはフランクフルトを離れ、1 ホップでシンガポールに到着する。明日削除するストレージにではなく、コネクションが開いていた秒に支払っている。
下まで全部 HTTP
あなたの監視はすでに HTTP を理解している。VPN、ファイアウォール、監査ログも。新しい IAM アイデンティティなし、新しい SDK なし、新しい失敗モードなし — curl コマンドだ。
次元S3 ラウンドトリップHOODY パイプ
- ステップ6 段階2 curl
- 使用ディスク200 GB0 バイト
- エグレス区間2 × 200 GB1 × 200 GB
- クリーンアップライフサイクルルールなし
速度はエンドツーエンドで遅い方のリンクで制限される (フランクフルトのエグレス、シンガポールのイングレス、TCP ウィンドウ)。Hoody のパイプは 0 バイトを保持する — サーバーサイドストレージはなく、バックプレッシャーは 2 つのエンドポイント間で直接流れる。
use-cases / move-200gb-between-clouds-with-two-curls / punchline
2 つのターミナル、1 つの URL、3 番目のストレージレイヤーなし。
マイグレーション全体は cat file | wc -l と同じ形をしている。2 つのパイプがたまたま異なるデータセンターに住んでいるという事実は、URL の実装の詳細だ。
- ホップゼロ
- 保持ゼロ
- 1 つの URL
use-cases / move-200gb-between-clouds-with-two-curls / replaces
これが置き換えるもの
ストリーミングする HTTP パスを誰も持っていなかったから存在するだけのもの。パイプはデータマイグレーションスタック全体を両側で 1 つの curl に折りたたむ。
- AWS S3 クロスリージョンコピー2 つのエグレス、1 つのバケット、ライフサイクルルール
- Dropbox 転送200 GB が 1 週間他人のディスクに座る
- Google Drive 受け渡しクォータの壁、共有リンク、手動クリーンアップ
- SSH 経由 rsyncランダムなクラウド間の SSH = 踏み台と鍵交換
- SCP + 再開1 プロセス、ファンアウトなし、不安定なリンクで壊れる
- サードパーティのデータマイグレーションツール余分なステップ付きの curl のためのベンダー全体
use-cases / move-200gb-between-clouds-with-two-curls / cta
バケットをスキップしよう。トランスポートは URL だ。
use-cases / move-200gb-between-clouds-with-two-curls / related
他のユースケースを読む
