問題とスコープ
ゲートウェイは複数のAPIの前面に配置されます。トラフィックは1分間で20倍に増加する可能性がある一方、データベース、検索、サードパーティ依存関係の容量はそれぞれ異なります。リクエストの分類、アドミッション、キューイング、ロードシェディング、縮退レスポンス、復旧を設計してください。ビジネス認可、完全なWAF、故障した依存関係への容量追加は対象外です。
面接官が評価するポイント
レートリミットと過負荷保護の違いを明確に区別できるかです。レートリミットは通常、一定時間枠におけるアイデンティティごとのトラフィックを制限します。一方、アドミッションコントロールは、同時実行数、キュー滞留時間、コスト、依存関係の健全性に基づいて、処理が実際の計算リソースを消費してよいかを判断します。優れた回答では、何をドロップするか、その理由、低優先度処理のスタベーション（飢餓状態）をどう回避するか、そして復旧時にトラフィック急増をどう防ぐかを説明します。
明確化のための質問
- どのリクエストが重要で、どれが遅延、キャッシュ、または近似結果の返却を許容できますか？
- 保護の対象はゲートウェイ単体、特定の依存関係、特定のテナント、あるいはすべての境界ですか？
- 処理はどれくらいの時間待機可能であり、クライアントはリトライ、ポーリング、または空の結果の受け入れのどれを行うべきですか？
- テナント、リージョン、API、またはコストクラス間で容量を公平に分配する必要がありますか？
- どのステータスコード、ヘッダー、判定メトリクスを呼び出し元に公開しますか？
30秒の回答フレームワーク
「信頼できるルートのメタデータ、テナント、コストに基づいてリクエストを分類し、厳密な同時実行数およびバジェットのチェックを実行した上で、優先度とテナントごとに分割された有界キューに承認された処理を配置します。コントローラーは、処理中のリクエスト数、キュー滞留時間、エラー率、依存関係からのシグナルに基づいて目標同時実行数を調整します。過負荷時には、リトライ可能な処理や低価値の処理を優先して拒否し、重要リクエスト用の容量を確保します。キャッシュ可能または近似可能な操作は縮退パスを使用し、拒否時にはリトライタイミングを返します。復旧には段階的な引き上げ、リース、制御されたプローブを使用し、リトライによる二次過負荷を防ぎます。」
ステップバイステップの詳細設計
ゲートウェイはリクエストサイズ、タイムアウトバジェット、テナントクォータを検証し、リクエストを criticality、cost、retryability、dependency の各ラベルにマッピングします。信頼できるルート設定がラベルを提供し、クライアント自身が優先度を申告することはできません。ヘルスチェックおよび管理トラフィックは予約済みプールを使用し、データトラフィックがコントロールプレーンを枯渇させないようにします。
APIおよび依存関係ごとに、実行中上限、キュー上限、タイムアウトバジェットを維持します。セマフォまたはリースによって実リソースを保護し、過負荷を無限のバックログに隠蔽するのではなく、キューを有界にします。バジェットはアドミッション後にのみ消費し、キャンセルやタイムアウト時にはリースを解放します。ストリーミングリクエストには個別の接続バジェットとバイトバジェットを設け、1つの長いストリームが全スロットを占有しないようにします。
スケジューラーは優先度、テナントの重み、滞留時間に基づいて処理を選択します。重要処理には最小同時実行数が予約され、低優先度の処理はドロップまたは遅延される可能性がありますが、エイジングによりスタベーションを防ぎます。テナントのバーストが他テナントの予約分を借用することはできません。リージョン間では、脆弱なグローバル協調依存関係を追加する代わりに、許容誤差を持つローカルでの高速判断を採用します。
短い時間枠ごとに、コントローラーは目標同時実行数を調整します。p95レイテンシ、キュー滞留時間、またはダウンストリームエラーがしきい値を超えた場合は削減し、安定時は緩やかに増加させます。シグナルの平滑化とヒステリシスにより、しきい値付近での発振を防ぎます。クライアントのリトライは健全性シグナルではありません。リトライの増幅を追跡し、Retry-After、ジッター、リトライバジェットによって戻りトラフィックを制限します。
リクエストのセマンティクスに応じてシェディングを選択します。レコメンデーション、分析、プレビューはキャッシュや近似結果を返してもかまいません。書き込み、決済、権限変更は通常フェイルファストし、安全なリトライを要求します。縮退レスポンスには、完全なデータであると偽るのではなく、バージョン、タイムスタンプ、鮮度情報を含めます。ゲートウェイは、自身が理解していない再試行不可能な副作用を持つ処理をドロップしてはなりません。
依存関係のタイムアウトやエラーが発生した場合、分離プールによって接続数、同時実行数、リトライバジェットを制限し、サーキットブレーカーは制御されたプローブのみを許可します。キャッシュおよび静的レスポンスは分離されたプールを使用します。成功が確認されたら、徐々にトラフィックを引き上げます。アドミッション判定、ポリシーバージョン、拒否理由、キュー待機時間、依存関係シグナルを記録し、429 レスポンスが大量に発生しても原因診断が可能な状態を維持します。
アドミッション率、優先度・テナント別の拒否率、最長キュー滞留時間、実行中処理数、p95/p99レイテンシ、ダウンストリームエラー、リトライ増幅、縮退の鮮度、復旧のスロープを監視します。リソースバジェットと実際の接続数、スレッド数、データベース接続数、キュージョブを整合させます。トラフィック急増、低速な依存関係、誤ったポリシー設定、コントローラーの喪失、リージョン分断、リプレイスームを注入してテストします。
質の高い模範解答
「ゲートウェイにおいて、信頼できる重要度、コスト、リトライ可能性、依存関係のラベルを付与します。各APIおよび依存関係には有界の同時実行数、有界キュー、予約容量を持たせ、スケジューラーは優先度、テナントの重み、エイジングを利用します。コントローラーはp95レイテンシ、キュー滞留時間、ダウンストリームエラーからヒステリシスを用いて目標同時実行数を調整します。過負荷時には、低価値またはリトライ可能な処理を先に拒否して重要な書き込み用の容量を維持します。プレビューなどは鮮度情報付きでキャッシュデータを返却できます。
すべての拒否レスポンスには、固定の理由、Retry-After、リクエストIDを含めます。分離プール、リトライバジェット、制御されたプローブによりカスケード障害を防ぎ、復旧は段階的に行います。メトリクスでは公平性、リトライ増幅、鮮度、復旧スロープをカバーし、障害注入によってコントローラー喪失、リージョン分断、リプレイスームを検証します。この契約の本質は、過負荷時でもクリティカルパスのレイテンシを予測可能に保つことであり、すべてのリクエストを無限に待たせることではありません。」
よくある間違い
- 固定QPSリミッターのみを追加する → ボトルネックが接続数、CPU、または依存関係にある可能性がある → 同時実行数、キュー、健全性シグナルを組み合わせる。
- 無界キューを使用する → レイテンシが爆発し、容量不足が隠蔽されたままになる → キューを有界にして明示的に拒否する。
- すべてのリクエストを同等に扱う → 低価値の処理がクリティカルパスを圧迫する → セマンティックな容量を予約し、処理にエイジングを適用する。
- クライアントに優先度を自己申告させる → 攻撃者に保護を回避される → 信頼できるルートポリシーから分類する。
- 過負荷時にバジェットなしでリトライする → 増幅によって依存関係が完全にダウンする → バジェット、ジッター、
Retry-Afterを使用する。 - 鮮度情報なしで古いデータを返す → ユーザーが最新の真実と誤認する → バージョン、タイムスタンプ、ソースを含める。
- 全トラフィックを即座に解放する → リプレイスームが復旧処理を再び過負荷にする → 制御されたプローブで段階的に引き上げる。
- 厳密なグローバルカウンターを要求する → 保護パスに障害要因となる依存関係が増える → 許容誤差を持たせた高速なローカル判定を行う。
フォローアップの質問と回答
フォローアップ1: アドミッションコントロールはレートリミットとどう違いますか？
レートリミットは、一定時間枠におけるアイデンティティのトラフィックを制限します。アドミッションコントロールは、同時実行数、キュー待機、コスト、依存関係の健全性に基づいて、処理が実際のリソースを消費可能かを決定します。両者は共存可能ですが、固定QPS上限はリソースアドミッションではありません。
フォローアップ2: 低優先度のテナントが重要なテナントを圧迫するのをどう防ぎますか？
重要テナント専用のプールまたは最小クォータを予約し、共有容量は重み付けに基づいてスケジュールします。全テナントに最大バジェットを設定し、一時的な急増で予約分が無期限に占有されないようにします。
フォローアップ3: すべてをキューイングしないのはなぜですか？
ビジネス上の期限を過ぎると、待機は有用な処理ではなくタイムアウトとリトライを生み出すだけになります。有界キューにより過剰な需要を明示化し、呼び出し元に適切なフィードバックを返せます。
フォローアップ4: コントローラーを駆動するシグナルは何ですか？
最低限、p95/p99レイテンシ、実行中処理数、最長キュー滞留時間、依存関係エラー率、リソース使用率です。これらを平滑化してヒステリシスを設け、クライアントのリトライトラフィックを正常な需要と分離します。
フォローアップ5: 重要な書き込み処理を縮退させることはできますか？
永続化キューへの登録とそれに続く非同期完了をビジネスセマンティクスが許容する場合にのみ可能です。決済、権限、在庫管理などは偽の成功を返すことができません。安全に失敗させ、冪等性を持たせてリトライさせる必要があります。
フォローアップ6: 復旧によって再度の過負荷が発生しないことをどう検証しますか？
依存関係の復旧、バックログ、クライアントリトライを注入し、引き上げレート、予約、キュー滞留時間、エラーを観察します。最大増加率、クールダウン期間、手動一時停止スイッチを設けます。