ゲートウェイと負荷・予算制御

まず図全体の流れを見て、細部は「原寸で読む」を開いて確認してください。原寸の図は横にスクロールできます。正常な流れの次に、失敗時の分岐を追いましょう。

入口を集める目的

ゲートウェイは通信の入口に立ち、認証の確認、宛先選択、負荷制限などの共通処理を行います。APIゲートウェイはアプリケーションAPIへの入口、AIゲートウェイはモデル事業者への呼び出しをまとめる役割として考えるとよいでしょう。この章ではその責務を分けて説明するが、製品名だけで機能が決まるわけではありません。以下は仮想チャットの設計であり、Kumyuの実装説明ではありません。

入口が一つでも、全世界の複数サーバーが同じカウンタを見ているとは限りません。Envoy Gatewayのグローバルレート制限は、複数インスタンスをまたぐ制御の構成例を示します。各サーバーで毎秒100件を許可すると、10台では合計毎秒1,000件まで通り得ます。何の範囲を制限するのかが先に必要です。

全体図：三つの制限を独立させる

原寸で読む（横にスクロール）

図1。矢印はリクエストの経路です。各判定は異なる資源を保護し、認証済みテナントの識別子を共有します。

毎秒10件しか来なくても、一件が30秒かかれば約300件が実行中になり得ます。逆に同時実行だけ絞っても、短い呼び出しを大量に通して予算を使い切ることがあります。IPだけでは共有ネットワークの利用者をまとめて制限してしまうため、認証済みテナント枠と利用者枠を基本にし、IP枠は補助にする設計を検討します。

分散トークンバケットと予算予約

原寸で読む（横にスクロール）

図2。モデル呼び出し前に上限を予約します。呼び出し完了後、実消費量との差分だけを一度返します。

トークンバケットは容量B、補充速度r、現在量tを持ちます。ここでのトークンは受付許可の単位であり、LLMの文字列トークンとは別物です。経過時間Δに対して t = min(B, t + r × Δ) と補充し、必要量以上なら減算して通します。Redisの教材は共有状態とLuaによる原子的な処理を扱います。本設計でも、読み取りと減算を別々にせず、一つの処理で行います。不変条件は「残量が負にならない」「容量を超えて補充しない」「同じ受付を二度減算しない」です。

{
  "requestId": "req-example-9",
  "tenantId": "tenant-from-session",
  "reservation": {"tokens": 3000, "state": "reserved"},
  "maxOutputTokens": 1000,
  "deadlineMs": 8000,
  "attemptLimit": 2
}

これは未実行の設計例です。入力2,000、最大出力1,000なら3,000を予約し、生成にも最大出力を設定します。実績が2,400なら600を一度だけ返します。再試行・別モデルへの切り替えでも各試行分の上限を予約し、一つの予約で無制限に呼び出しません。時間切れで実績不明なら全額を即返却しません。予約の状態を reserved → reconciled または reserved → pending_reconciliation として永続化し、照会・監査で収束させます。同時実行枠には期限付きリースと更新を使い、期限切れ後も旧実行が動く場合の超過を防ぐ停止・照合が必要になります。

障害：再試行も新たな負荷になる

原寸で読む（横にスクロール）

図3。待機してから再試行する場合も、元の締切と回数上限を引き継ぎます。別モデルへの切り替えも消費を生みます。

HTTP 429の仕様では、リクエスト過多を表し、Retry-Afterを付けられます。利用側はその待機指示を尊重し、指数バックオフとランダムな揺らぎを組み合わせます。ただし、待機後に締切を超えるなら再試行しません。利用枠の回復と関係のない権限エラーは、待っても解決しません。

入口、アプリ、モデル接続の各層で総試行回数が2回なら、元の一件が最大8回に膨らみ得ます。再試行の責任を一か所に集め、総試行回数を伝えます。外部送信のような非冪等操作では、タイムアウトは「未実行」を意味しません。同じ操作IDで結果を照会し、二重送信を防ぎます。モデルを切り替えても、すでに走ったツールの副作用は消えません。

共有制限サービスが止まった際、無制限に通すと下流を倒し得ます。厳格な予算枠は受付を停止し、短い読み取り処理だけ別の小さなローカル枠に収めるなど、故障時方針を明文化します。別枠を設けるなら通常の全体上限を保証できなくなる条件も示します。

仮の数値で容量を考える

バケット容量20、毎秒5補充、初期残量20とします。同時に30件来れば、原子的な判定で20件だけ通し10件を拒否します。2秒後には最大10件分が戻ります。これは境界条件の演習であり、製品の設定値ではありません。

同時実行上限が8なら、受付レートに余裕があっても9件目を待たせるか拒否します。待機列を無限に伸ばさず、例えば待機上限16件と締切8秒を独立に設定します。予算残量が12,000トークンで一件3,000を予約するなら、同時に予約できるのは4件までです。レート、実行枠、予算のうち最も厳しい制約が今回の受付数を決めます。

演習：生成中に利用者が切断したら

3,000トークンを予約した直後にブラウザーが切断しました。すぐ全額を返してよいでしょうか。

解答例。 返しません。モデル側が生成を続けている可能性があります。中止要求を送り、利用実績と完了状態を確認して精算します。確認できなければ未確定予約として保持し、期限と照合手順で収束させます。続けてRAGを読むと、検索・再順位付け・生成のどこへ予算を配分するかを考えられます。

学習と設計検討のための概念的な構成例です。稼働中のKumyuの実装を表す図ではありません。

← 全章の一覧へ