osFoundry / Platform
公開アプリのレートリミット
公開アプリのIP単位・トークン単位の調整可能なレートリミット。突発アクセスにも耐えるデフォルト付き。
概要
osFoundryの公開アプリ向けレート制限は、一般公開するアプリの前段に調整可能なスロットルを置く仕組みです。制限は2つの軸を組み合わせて設定します。1つはIP単位で、単一のクライアントアドレスが一定時間内に送れるリクエスト数に上限を設けます。もう1つはトークン単位で、特定のアクセストークンやAPIキーに紐づく利用量に上限を設けます。IP単位の制限は1つの発信元からの大量アクセスを鈍らせ、トークン単位の制限は共有された、あるいは漏洩した認証情報がクォータを食い潰すのを防ぎます。osFoundryはBYOK（自前のキーを持ち込む方式）なので、公開アプリがモデルへ送り出すリクエストは最終的にあなたが所有するキーで課金されます。したがって上限のないエンドポイントは負荷の問題であるだけでなく、請求の問題でもあります。レート制限は、スパイクがプロバイダー請求の思わぬ膨張へ変わるのを食い止める境界線です。
osFoundry内では、この機能はアプリのパッケージ化や公開の仕組み一式とともに「Apps & Backend」レイヤーに置かれています。アプリを公開する時点で制限はすでに有効になっており、既定値は「アクセス殺到」に耐えられるよう選ばれています。リンクが広く共有され、想定を超える速さでトラフィックが押し寄せる、あの瞬間のことです。アプリが落ちたりキーを消耗したりする代わりに、余剰リクエストはエッジで拒否され、正当なトラフィックは流れ続けます。そこから先はすべての制限を調整できます。混雑が見込まれるアプリでは上限を引き上げ、実験的なものでは締め、認証情報ごとにトークン単位の制限を設ければ、利用者ごとに異なる予算を割り当てられます。
これが重要なのは、公開型のAIアプリが多くの静的サイトにはないコスト面を抱えているからです。共有されたURL1つ、スクレイパー1つ、暴走したクライアント1つが、数分で数千回のモデル呼び出しを生み出します。IP単位とトークン単位の制限は、予測可能な最悪ケースをもたらします。アプリが「ノー」と言い始めるまでに許す最大の支出と負荷を、あなた自身が決められるのです。osFoundryのローカルファーストで再販マージンのないモデルと組み合わせれば、キーもデータも、そしてそのキーが背後に控えるエンドポイントの露出まで、自分の手に残せます。
主な機能
- IP単位のリクエスト制限を設定し、単一のクライアントアドレスが一定時間内に公開アプリへ送れる量に上限を設ける
- トークン単位の制限を設定し、特定のアクセストークンやAPIキーに、発信元IPとは独立した専用の利用予算を割り当てる
- 既定値はアクセス殺到、つまり共有リンク経由の突発的なスパイクを、手動設定なしで吸収するよう調整済み
- 余剰リクエストをエッジで拒否し、大量アクセスがアプリの課金元であるBYOKプロバイダーキーを消耗させないようにする
- 実際のトラフィックが見えてきたら、アプリ単位でも認証情報単位でも、あらゆる上限を自在に引き上げ引き下げできる
活用例
- 個人開発者：公開したデモリンクが予想外に拡散しても、既定の制限のおかげでAPIキーを一晩で使い果たすことなくアプリが立ち続ける
- チームリード：パートナーごとに別々のアクセストークンを発行し、それぞれにトークン単位の予算を設定して、1つの連携が他を枯渇させないようにする
- 運用志向の開発者：実験的なエンドポイントのIP単位の制限を締め、本番へ昇格させる前に最悪ケースのコストと負荷を抑え込む
よくある質問
IP単位とトークン単位のレート制限は何が違いますか。
IP単位は単一のクライアントアドレスからのリクエストに上限を設け、1つの発信元からの大量アクセスを止めます。トークン単位は呼び出し元を問わず、特定のアクセストークンやAPIキーに紐づく利用量に上限を設け、共有・漏洩した認証情報を封じ込めます。両方を同時に使うこともできます。匿名の公開トラフィックにはIP単位を、名前のある利用者には専用予算を与えるためにトークン単位を、という使い分けです。
公開アプリに急にアクセスが集中したらどうなりますか。
公開アプリには、想定をはるかに超えてリンクが共有される「アクセス殺到」を捌けるよう選ばれた既定の制限が付いています。上限を超えたリクエストは素通しされず拒否されるので、スパイクがアプリの課金元であるプロバイダーキーを消耗させたり、アプリを落としたりすることはありません。混雑が見込まれるアプリでは制限を引き上げられます。
アプリを公開する前にレート制限を設定しておく必要がありますか。
いいえ。アプリを公開した時点で妥当な既定値がすでに効いているので、設定なしで保護されます。必要なときにはすべて調整可能で、IP単位の上限を上げ下げしたり、認証情報ごとにトークン単位の制限を設けたりできますが、安全な基準値は最初から有効です。