
1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
サービス A が出力をパスにパイプします。サービス B が同じパスから受け取ります。パイプは 2 つのコンテナの間でリアルタイムにバイトをルーティング。Redis なし、コンシューマーグループなし、面倒を見るブローカーデーモンなし。
中に POST。外に GET。その中は URL。
2 つの HTTP 動詞と 1 つのパス。どちらの側が先に接続しても構いません。パイプは相手を最大 5 分待ち、その後バイトを通します。キューも、オフセットも、グループもありません。
プロデューサーがオフライン? コンシューマーが GET して待ちます。コンシューマーがオフライン? プロデューサーが PUT して待ちます。パイプは相手が現れるまで最大 5 分間接続を保持します。
コンシューマーが遅いとき、カーネルがプロデューサーのストリームを遅らせます。監視するキューの深さも、調整するハイウォーターマークもありません。ソケットがバッファです。
正直なトレードオフ:何も永続化されません。永続的なキューイングが必要なら向いていません。コンテナ間の高速ファンアウトには、ブローカーがただ消えました。
# Container A — producer streams jobs to the pipe
service-a | curl -T - https://api.hoody.com/api/v1/pipe/jobs
# Container B — consumer reads from the same path
curl https://api.hoody.com/api/v1/pipe/jobs | service-b
# Either side can connect first.
# The pipe holds the connection up to 5 minutes
# until the counterpart arrives, then streams through.PUT (または POST) で送信。GET で受信。バイトはどこのディスクにも着地しません — プロデューサーからコンシューマーまでワイヤーを渡り、パイプが飛行中に転送します。
ロガーやメトリクスコレクターが同じイベントを必要とする場合は、?n を上げて curl を 1 つ加えるだけです。ブローカー設定も、コンシューマーグループも、ローテーションする認証シークレットもありません。新しいリーダーは単に存在するだけです。
1 人の遅いリーダーはプロデューサーにバックプレッシャーをかけますが、他のリーダーはブロックしません。1 つのパスにつき最大 256 リーダーまで。
ブローカーは 2 つのコンテナが直接話せなかったから存在していました。パイプがあれば話せます。ブローカーが追加した認証、クライアント、運用 — そのすべてが消えます。
デプロイ、監視、アップグレードするものはありません。パイプがプラットフォームで、URL が唯一の API です。
Hoody トークン 1 つを、プロジェクトごとにスコープ。ブローカーごとのユーザー名、パスワード、ACL ファイルはありません。
HTTP を話すものなら何でもプロデュースまたはコンシュームできます — bash、Python、Go、スマホ、ブラウザ。クライアントライブラリ不要。
メッセージは飛行中に存在し、静止状態にはなりません。埋まるディスクも、保管ポリシーも、キューに入ったデータについての GDPR の問いもありません。
最も遅いコンシューマーが遅れると、TCP がプロデューサーを減速させます。遅延ダッシュボードがないのは遅延がないから — あるのはストリームレートだけです。
プロデューサーとコンシューマーはお互いの IP を知りません。共有するのは URL だけ。配線を変えずにどちらかを別のホストに移せます。
ブローカーが URL。URL がブローカー。
中間レイヤーが消えます。資格情報、クライアント、ランブック付きのステートフルデーモンだったものが、いまやパスです。アーキテクチャ図のボックスが 1 つ減ります。
1 つの URL、1 つの curl、1 つの HTTP 動詞
1 つのコンテナが別のコンテナにバイトを渡す必要があるとき、チームが手を伸ばすインフラ群。どれもデーモン、設定、オンコールローテーションを足します。パイプはそのどれも要求しません。
2 つのコンテナの間で会話するために Redis を立てますか? それとも URL を共有しますか。