必需品
いくつかの専門的な情報源によると、適切に実装された分散レート リミッター (アトミック カウンティング、ローカル フォールバック キャッシュ) では、通常、リクエストあたりの追加時間は 1 ミリ秒未満です。 Aurabase ゲートウェイは、まさにこのパターンに従います。ローカルの DoS 対策用の governor クレート、インスタンス間の分散カウント用のアトミック Lua Redis スクリプト、Redis が使用できない場合のフォールバック moka キャッシュです。ブレーカー回路は、障害が発生した場合に認識される遅延を追加するのではなく、短縮します。つまり、完全なタイムアウトまでの待機時間を短縮します。 Aurabase のレイテンシの数値は現在まで公開されていません。その理由と、メカニズムが実際にどのように機能するかは次のとおりです。
アンチ DoS とアンチカスケード障害、2 つの異なる問題
レート制限は、正当かどうかにかかわらず、バックエンドを過剰なトラフィックから保護します。これは、「この呼び出し元には今このリクエストを送信する権利があるか?」という質問に答えます。サーキット ブレーカーは、既にダウンストリームのダウンストリーム サービスからバックエンドを保護します。「このサービスが応答しなくなったことはありますか? 試してみるべきですか?」という質問に応答します。 」。これらを混同すると、どちらか一方のサイズが小さくなってしまいます。
Aurabase ゲートウェイでは、どちらも同じミドルウェア スタック内にありますが、異なるフロアに存在します。IP レート制限は認証前に実行されます (純粋な DoS 対策で、未認証トラフィックに対して発行される課金 SQL クエリはありません)。一方、サーキット ブレーカーは内部サービスまたは LLM プロバイダーへの発信呼び出しを保護します。
コストは原則ではなく実装に完全に依存します
Tyk と APISIX エコシステム ガイドによると、Redis 上で適切に設計された分散カウント (アトミック操作、Lua スクリプト、ネイティブ TTL) では、通常 1 ～ 3 ミリ秒のレイテンシが追加され、最も最適化されたケースでは p99 の影響はミリ秒未満です。逆に、Zuplo は、集中型レート リミッターの配置が不適切な場合、各リクエストに数十ミリ秒が追加される可能性があることを文書化しています。この矛盾は、p99 に直接反映されています。
これらの範囲は、一般的な測定プロトコルからのものではなく、公開されている技術ガイド (Tyk、Zuplo、Apache APISIX エコシステム) からのものです。これらは、別のインフラストラクチャ上でそのまま再現されるべき数字ではなく、桁違いとアーキテクチャ原理 (同期的かつ集中化されたものではなく、アトミックでローカルなカウント) を示しています。
aura-gateway でレート制限が実際にどのように機能するか
Aurabase ゲートウェイは、ローカル フォールバック リミッターとして governor クレート (トークン バケット アルゴリズム) を使用し、Redis を介した分散カウントと組み合わせて、ゲートウェイの複数のインスタンス間で状態を共有します。分散カウントは、同時実行ウィンドウを導入する読み取りと書き込みの往復ではなく、Redis 側でアトミックに実行される Lua スクリプト (単一のネットワーク操作でのINCRBY + EXPIRE) を介して行われます。
Redis が使用できなくなった場合、ゲートウェイは、リクエストごとにリミッターが再作成されることを避けるために、キャッシュ moka (最大 1,000,000 エントリ、非アクティブ状態が 300 秒で期限切れ) を備えたローカル リミッター governorに自動的に切り替わります。このフォールバックは観察可能です。トグルごとに専用の Prometheus カウンターがインクリメントされるため、有効な制限が N インスタンス × 制限に再び達する時期がチームにわかります (そうでない場合は、インスタンス間分離のサイレントな低下が発生します)。
ゲートウェイは、IP による DoS 対策レート制限 (認証前) と、プロジェクト/API キー/ユーザー クォータによるレート制限 (認証後、JWT クレームが利用可能) を区別します。スタック内の 2 つの別個のミドルウェアであり、それぞれ独自の粒度を持ちます。
サーキットブレーカー: 3 つの状態、スライディング ウィンドウ
Aurabase ブレーカー回路 (aura_core::circuit_breaker、LLM プロバイダー間のフォールバック用にゲートウェイと aura-ai の間で共有) は、リセットされないカウンターではなく、スライディング タイム ウィンドウにわたる障害の数を使用して、3 つの古典的な状態 ( Closed、 Open、 HalfOpen) に従います。
本番環境で重要な実装の詳細: HalfOpen への切り替えでは、一度に 1 つのプローブ リクエストのみが許可されます (サンダーリング ハード対策)。このガードがなければ、すべての保留中のリクエストが再開したばかりのサービスに同時に殺到し、回避しようとしていた障害が即座に再現されてしまいます。
これらのミドルウェアがゲートウェイ内で実行される場所
Aurabase ゲートウェイミドルウェアスタックは、コードで確認された正確な順序に従います: リクエスト識別子 → アクセスログ → IP によるレート制限 → 認証 → アクター/クォータによるレート制限 → サーキットブレーカー → ターゲットサービスへのプロキシ。各ステージでは、ダウンストリームの処理コストが高くなる前に、不要なトラフィックをできるだけ早く拒否します。
Aurabase の数値がここで公開されない理由
実装はゲートウェイのソース コードで 1 行ずつ検証されます。しかし、この特定のインフラストラクチャ上で再現可能な測定プロトコルはまだ実行されて公開されていません。未測定の数値を公開することは、私たちが再現を拒否している出典のないマーケティング数値の間違いを繰り返すことになります。パフォーマンス数値を発表する前に必要なものについては、完全な ベンチマーク方法論 を参照してください。