v2026.3.x の背景（流式と多チャネル）
最小再現：六ステップ
- 手順 1. ステージングでゲートウェイを v2026.3.x に上げ
doctorとストリーム有効化を通す（ノード 1 台から）。 - 手順 2.
interactive_stream／ci_ingest／outbound_notifyに分けroute_classを構造化ログへ固定。 - 手順 3. テナント別・グローバル別の同時ストリーム上限を文書化し、ノード並行×台数 ≤ グローバル になるようセマフォを絞る。
- 手順 4. 背圧三段：①p95 遅延でクライアント間隔拡大 ②キュー水位で
429＋Retry-After③劣化で503。混同しない。 - 手順 5. 出站は
429・一時5xxのみ指数バックオフ。400／401はループ禁止。provider_run_id・mesh_node_idを必須ログ化。 - 手順 6.
incident_key（例hash(limit_name, upstream_host)）と 5〜15 分窓で再試行イベントをマージし、Pager／IM は 1 本に。
負荷はダミーテナントで、ストリーム本数を二倍刻みに上げ最初の拒否点だけ記録。
意思決定表（並行・背圧・アラート）
| 観点 | 症状 | 推奨 |
|---|---|---|
| 並行 | 遅いが落ちない | グローバル同時本数を先に下げ台数合算で追従。LB はレプリカ同設定。 |
| 背圧① | 間隔だけ伸びる | クライアント間隔のみ。HTTP 化しない。 |
| 背圧② | 定常レート超過 | 429＋短い Retry-After。CI concurrency を予算内へ。 |
| 障害 | DNS／TLS／5xx | 503、新規ストリーム抑制。完走優先は Runbook で固定。 |
| アラート | チャネル数ぶん鳴る | incident_key＋窓で 1 本化。生ログは IM に流さない。 |
調参の観測ポイント
同一パネルに route_class・mesh_node_id・active_streams・outbound_queue_depth・retry_after_ms・limit_name を載せ、429 と 503 の比率を分離アラート。頭打ちは 同時ストリーム×平均持続秒 で見積もる。
FAQ
- ノードを増やすと遅くなった
- 並行の積が増えただけのことが多い。キュー深さを見てセマフォを下げてから戻す。
- 統合アラートが遅い？
- 初回即時、同一キーの 2 回目以降だけ窓マージ。
503は別ルートで即時。 - Teams と Slack 同時出站は？
- 可能だが再試行が二倍。ゲートウェイ→単一通知バス→フォワードが簡潔。
まとめ・プラン／ノード選定（ログイン不要）
流式オン後は同時ストリームと出站キューが支配項。クラス分け・上限・429／503 分離・incident_key を入れてから本番切替。購入でプランと並行想定を確認し、長セッションは台数より接続予算の大きい階層を。ヘルプ・ホーム・ブログ・OpenClaw 特集 はログイン不要。