典型の痛み
一 RPS だけ絞り同時セッションを放置し FD 枯渇。二 ノード各々が並列を決め合計が天井突破。三 無制限リトライで自己増幅。対策はクラス別予算の文書化と LB 背後レプリカの同一リミッタです。
ゲートウェイ限流：五ステップ
- パスを
interactive／ci_ingest／internal_workerに分けroute_class化。 - IP・API キー・OAuth・
tenant_idなど安定キーでテナント分離。 - トークンバケツで到着、セマフォで同時実行を二系統で持つ。
- 入場はキューより厳しめ。再試行はキュー側ポリシーと矛盾させない。
- 先に計数のみのダークラン、次週から拒否。Cron と予熱はジッターでずらす。
トークンバケツと接続・セッション
| 種別 | 用途 | 目安 |
|---|---|---|
| テナント桶 | Webhook・ポーリング | 補充五〜二十毎秒、バースト三十〜六十 |
| グローバル桶 | 共有上流 API | クォータ控除後の補充率 |
| セッション | 長寿命エージェント | ノード二〜八、合計≤ゲートウェイ天井 |
| TCP 上限 | FD 防壁 | ulimit 余白付きハードキャップ |
CI・通知並行とヘルス連動
Actions の concurrency・マトリクス・コネクタ再試行・多ボットをゲートウェイ予算表に載せ、メッセージは第二の桶で数える。ヘルス劣化時は新規のみ 503 と Retry-After、進行中ドレイン。CPU 高止まりなら補充率を一時的に下げ、LB プローブと信号を揃える。
失敗観測：ログ項目
拒否は JSON 一行で統一。mesh_node_id gateway_instance_id route_class limit_name client_id http_status retry_after_ms 任意 queue_depth_hint。429 偏りは設定、503 急増は容量。トレースでエッジ拒否とワーカ超時を切り分ける。
FAQ
Q 制限はリバプロか OpenClaw か
A 手前は TLS と粗い枠、本体はセッションとツール。Retry 方針を二層で文書化。
Q 多ノードで群れを防ぐ
A 同一設定のレプリカか Redis 中央クォータ。Cron と CI にジッター、ワーカ合計≤予算。
Q 429 と 503
A 定常超過は 429、依存・ヘルス不良は 503。同じフィールドでアラート分岐。
MeshMac · ゲートウェイ運用
限流を決めたら、ノードを足しても秩序を保つ
共有ゲートウェイの設計が固まったら、MeshMac で Mac プールを広げつつ同じパターンを繰り返し検証するのが安全です。料金はログイン不要で 購入・プラン（goumai） から比較でき、接続と運用の細部は ヘルプセンター、OpenClaw 連載は 特集ページ、関連記事は ブログ一覧 をご利用ください。