代表的な面接トピック

システムデザイン面接:グローバルなクォータポリシーのコントロールプレーンをどのように設計するか?

システム設計難しい
Offer.cc 編集チーム公開日 更新日

質問

マルチリージョンAPIプラットフォームにおいて、プロダクトチームがテナント、アプリケーション、およびエンドポイントごとのクォータを定義し、それをすべてのゲートウェイインスタンスで強制できるようにします。ポリシーのバージョン管理、配信、整合性、バースト、縮退動作、HTTPレスポンスヘッダー、および監査可能性を網羅したクォータコントロールプレーンおよびデータプレーンを設計してください。

プロンプトとコンテキスト

このプラットフォームには、複数リージョンにまたがる数百のゲートウェイインスタンスが存在します。プロダクトチームは、テナント、アプリケーション、エンドポイント、プランごとに、1秒あたりのリクエスト数(RPS)、同時実行数、日次クォータを設定し、変更を数分以内に反映させる必要があります。1つのテナントが共有キャパシティを枯渇させてはなりませんが、クォータサービスの一時的な障害時でもコアAPIは利用可能であり続ける必要があります。

この面接では、コントロールプレーンとデータプレーンの分離、カウントモデル、配信の整合性、リージョン間のトレードオフ、および障害時の動作が評価されます。Envoyはローカルレート制限とグローバルレート制限を区別し、RFC 9331はHTTP RateLimitフィールドを定義しています。プロトコル、プロダクトポリシー、およびランタイムの判定を関連付けて説明してください。

面接官が評価するポイント

ポリシーの形式、バージョン管理と承認、記述子(descriptor)キー、トークンバケットまたはスライディングウィンドウ、ホットテナント、リージョン間カウント、設定配信、キャッシング、フェイルオープン対フェイルクローズ、クォータヘッダー、監査、およびコストをカバーします。

確認すべき明確化のための質問

  • クォータはハードリミット、ソフトアラート、またはその両方ですか?また、トラフィックのバーストや将来のキャパシティの前借りは許可されますか?
  • どのディメンションがグローバルな精度を必要とし、どれが有界なリージョン近似を許容しますか?
  • 伝播およびロールバックの目標時間はどれくらいですか?また、ポリシーが古い(stale)と見なされるまでにゲートウェイが切断状態でいられる時間はどれくらいですか?
  • 制限超過のレスポンスには、リトライのタイミング、残りのクォータ、および課金イベントを開示する必要がありますか?
  • レートリミッターの障害中にも継続して稼働しなければならないコアエンドポイントはどれですか?

30秒の簡潔な回答

「コントロールプレーンは承認・バージョン管理されたポリシーを保存し、それらをゲートウェイの記述子にコンパイルして差分を配信します。データプレーンはローカルで高速な判定を行い、グローバルな精度が必要なディメンションのみが共有リミッターを呼び出します。トークンバケットがバーストを吸収し、カウンターはテナントおよびエンドポイントごとに分離されます。ポリシーにはTTL、チェックサム、ロールバックバージョンが含まれます。エンドポイントのリスクに応じてフェイルオープンまたはフェイルクローズを選択し、標準のRateLimit情報を返して判定理由を監査します。」

ステップごとの詳細解説

ステップ1:ポリシーとリリースワークフローの定義

ポリシーには、テナント、アプリケーション、エンドポイント、ウィンドウ、レート、キャパシティ、同時実行数、日次クォータ、リージョンスコープ、および優先度が含まれます。ゲートウェイは任意のプロダクトフィールドを解釈すべきではなく、コントロールプレーンがそれらを安定した記述子にコンパイルします。

text
policy v42:
  subject: tenant:acme / app:billing
  route: POST /invoices
  rate: 200 requests/second
  burst: 400
  scope: global

リリースには、承認、静的競合チェック、トラフィックシミュレーション、および署名付きバージョンが必要です。作成者、理由、予想される影響、およびロールバックポインタを保持し、監査済みのバージョンを上書きしてはなりません。

ステップ2:カウント方式とシャーディングの選択

短時間のバーストにはゲートウェイ上のローカルなトークンバケットを使用します。共有リミッターは記述子ごとにグローバルディメンションをカウントできます。日次クォータには、明示的なウィンドウ境界とクロックソースを備えたアトミックウィンドウカウンターまたはシャーディングされたクォータを使用します。

1つのホットキーがボトルネックにならないよう、テナント、アプリケーション、エンドポイントごとにシャーディングします。ホットテナントには、階層型トークン、事前割り当てキャパシティ、または専用シャードを提供し、一時的な超過や最終課金の処理を明示的に行います。

ステップ3:整合性を担保したポリシーの配信

バージョンとチェックサムを付与してコンパイルされたポリシーをゲートウェイにストリーミング配信します。単調増加する有効な署名付きバージョンのみを受け入れ、起動時には最新の有効なスナップショットをロードします。更新を受信できない場合、TTL経過後にゲートウェイは古い(stale)状態としてマークされ、アラートを発行します。

リージョン内でのローカル配信を優先します。リージョン間のポリシーはグローバルバージョンと明示的な有効化時刻を使用します。ロールバックは別のバージョンとして扱い、履歴を書き換えることはありません。ゲートウェイは確認応答後にバージョンのカバレッジをレポートします。

ステップ4:整合性、バースト、および公平性の処理

グローバルで厳密なカウントは、ネットワークレイテンシと共有状態のコストを増加させます。厳密な調整は高リスクまたは契約上のディメンションに限定し、その他は許容可能な誤差モデルを適用します。バーストキャパシティはバックエンドの同時実行数と一致させます。ゲートウェイのバケットだけを増やすと、バックエンドサービスが過負荷になる可能性があります。

テナントの公平性によって、共有接続プールを保護する必要があります。クォータの判定を同時実行バルクヘッド、キューの長さ、および優先度と結合します。トラフィックが拒否されたのかキューイングされたのか、およびその理由を記録し、顧客が単一の数値以上の診断を行えるようにします。

ステップ5:障害と縮退動作の定義

リミッターに到達できない場合、低リスクの読み取り専用エンドポイントは最新のローカルスナップショットを使用して有界なフェイルオープンを適用できます。書き込み、課金、およびコストの高いエンドポイントはフェイルクローズまたはより厳格なローカル上限を使用します。縮退した判定にはすべて有効期限を設け、復旧後に概算カウントを照合またはマークします。

ゲートウェイの再起動、クロックドリフト、重複メッセージ、および配信の中断をテストします。破損したスナップショットは拒否し、最新の有効なバージョンを保持します。空の設定が決して無制限のクォータを意味してはなりません。

ステップ6:プロトコル、監査、およびオブザーバビリティ

制限超過レスポンスでは安定した429セマンティクスを返し、RFC 9331に従って解釈可能な制限、残り、およびリセット情報を開示します。正確な数値を公開すべきでないテナントには、段階的なメッセージを使用します。内部的には、ポリシーバージョン、記述子、リージョン、カウンターソース、縮退状態、およびリクエストトレースを記録します。

バージョンカバレッジ、判定レイテンシ、拒否率、ホットキー、カウント誤差、縮退時間、およびロールバックを監視します。シャドウモードで新しいポリシーを評価し、リリース前に拒否率の変化を比較します。

強力な模範解答

承認されたポリシーをバージョン管理された記述子にコンパイルし、コントロールプレーンから差分を配信します。ゲートウェイは低レイテンシのためにローカルのトークンバケットを使用し、グローバルな精度が必要なディメンションに対してのみ共有サービスを呼び出します。ポリシーには署名、TTL、チェックサム、ロールバックバージョンが含まれ、テナント、アプリケーション、エンドポイント、リージョンごとに分離されます。エンドポイントのリスクに応じて縮退し、安定した429およびRateLimit情報を返し、バージョン、カウンターソース、および近似状態を記録します。

よくある間違い

  • すべてのリクエストを中央カウンターに送信する → レイテンシと障害ドメインが増大する → ローカルで判定し、リスクに応じてグローバルに調整する。
  • 設定を上書きする → 監査やロールバックが不可能になる → 承認、署名、および単調増加するバージョンを使用する。
  • バーストや同時実行数を考慮せずにレートを設定する → バックエンドが依然として過負荷になる → トークン、バルクヘッド、およびキューを組み合わせる。
  • 常にフェイルオープンにする → 書き込みや課金が無制限になる → エンドポイントのリスクに応じて縮退する。
  • 曖昧なエラーを返す → 顧客がトラフィックを調整できない → 安定したステータス、リセットのタイミング、および監査可能な理由を提供する。

フォローアップの質問と回答

フォローアップ1:なぜすべての場所で強整合性を要求しないのですか?

強整合性には共有状態とネットワークラウンドトリップが必要であり、可用性を低下させコストを増加させます。契約上またはセキュリティ上重要なディメンションにのみ限定し、それ以外では許容可能な誤差モデルを公開します。

フォローアップ2:リージョン間のバーストをどのように処理しますか?

グローバルな上限の下でリージョントークンを事前割り当てします。高価値のトラフィックは一時的に前借りできますが、1つのリージョンが独占できないように、前借りしたキャパシティと返済または課金のルールを記録します。

フォローアップ3:伝播遅延は誰が管理・責任を持ちますか?

ゲートウェイは最後の有効なバージョンを保持し、自身を古い(stale)状態としてマークする一方、コントロールプレーンはカバレッジを追跡します。TTL経過後は、エンドポイントのリスクに応じて制限を厳格化または一時停止します。暗黙のうちに無制限にしてはなりません。

フォローアップ4:新しいポリシーが顧客に悪影響を与えないことをどのように証明しますか?

シャドウ評価と履歴データの再生を実行し、拒否率、レイテンシ、テナント分布を比較して、自動化されたゲートを設定します。その後、ワンクリックでロールバックできるバージョンを用意して狭い範囲でカナリアリリースを行います。

公開情報ソース

関連する質問

関連面接ツール

システム設計の回答には「回答する」を使用

まず要件を明確にし、スケール、アーキテクチャ、コンポーネント選定、トレードオフの順に進めます。

ツールを見る