1. 質問
非同期の注文処理サービスが、ピストラフィック時に遅くなります。モニタリングでは、スループットが約 200 req/s で安定しており、エンドツーエンドの平均レイテンシは約 150 ms であることが示されています。リトル代数（Little's Law）を使用して処理中のリクエスト（in-flight requests）数を推定し、レイテンシ、スループット、キューの関係を説明したうえで、不安定なバックログを防ぐエンジニアリング上のアクションを提案してください。
2. 制約と前提条件の整理
- リトル代数は、安定したシステムにおける長期的な平均を表します：
L = λW（ここで L はシステム内の平均作業量、λ は平均スループット、W はシステム内の平均滞在時間）。 - 測定ウィンドウ、リクエストの境界、単位を明示してください。短時間のバーストや不安定なシステムを長期的な平均として扱うことはできません。
- サービス時間、キュー滞在時間、エンドツーエンドの滞在時間を区別してください。そうしないと、並行性やスレッドプールのサイジングが過小評価されます。
- 容量制限、タイムアウトポリシー、優先順位、ドロップ可能な作業を明確にしてください。
3. コアとなる導出
200 req/s に 0.15 s を掛けると、システム内には平均で L = 30 個のリクエストが存在することになります。これは最大 30 リクエストという意味でも、p99 の並行性でもなく、そのウィンドウにおける平均インベントリです。平均滞在時間が 2 倍になる一方でスループットが一定のままである場合、処理中の作業の平均も 2 倍になります。これは通常、キューの増大または依存関係の遅延を示しています。
4. リファレンス分析
lambda = 200 # requests / second
W = 0.150 # seconds / request
L = lambda * W # 30 requests in the system on average
if arrival_rate > sustainable_service_rate:
queue grows without a stable bound
apply_admission_control_or_scale_out()
capacity = concurrency_limit / target_latency作業がキューに入った時点、処理が開始された時点、および完了した時点を測定します。リトル代数は、おおよその容量上限を推定できます。たとえば、並行性制限が 100 で目標の平均滞在時間が 200 ms の場合、安定したスループットは約 500 req/s になります。テールレイテンシ、バースト、依存関係のジッターに備えてヘッドルームを確保してください。
5. 過負荷ケースとトレードオフ
到着率がサービス率を上回り続けると、キューが増大し、W が増加し、L が増加して、タイムアウトとリトライのフィードバックループが発生します。無制限のキューは障害の発生を遅らせるだけであり、作業が最終的に完了したときにはすでに無意味になっている可能性があります。有界キュー（bounded queues）、フェイルファスト動作、優先順位付け、ロードシェディング、バックプレッシャー、またはスケールアウトを使用してください。各ポリシーでは、どの作業がドロップされ、呼び出し元にどのように通知されるかを明示する必要があります。
6. 検証とオブザーバビリティ
- 時間ウィンドウごとに到着率、完了率、処理中の作業量、および平均と p95/p99 レイテンシを記録します。
L、λ、Wの 3 つの独立した測定値を相互検証し、単位やサンプリング境界のエラーを検出します。- 到着率を徐々に引き上げ、キュー長、タイムアウト率、回復時間を観察する制御された負荷テストを実行します。
- キューの深さ、滞留時間（age）、並行性、拒否率、リトライに対してアラートを設定し、スケーリングや負荷遮断の後にそれらがどれだけ迅速に低下するかを検証します。
7. よくある間違い
- 平均 L を厳密な並行性制限として扱い、バースト、テールレイテンシ、キューの分布を無視すること。
- エンドツーエンドの W の代わりにサービス時間を使用し、ネットワーク、ロック、依存関係の待機時間を見落とすこと。
- システムが安定する前の短いサンプルから長期的な容量を推測すること。
- プロデューサーを制限せずにコンシューマーのみをスケールさせ、共有依存関係やダウンストリームのキューを過負荷のままにすること。
8. 面接の評価ポイント
計算式へ正しく代入できているか
候補者が単位の一貫性を保ち、200 × 0.15 = 30 を計算し、これが制限値ではなく処理中作業の平均値であることを説明できているか。
時間の境界を定義できているか
候補者がキュー時間、サービス時間、エンドツーエンド時間を区別し、サンプリングウィンドウと安定性の仮定を明示できているか。
過負荷のフィードバックループを認識できているか
候補者が、到着率がサービス率を上回ることでキュー、レイテンシ、リトライ、並行性がどのように増幅されるかを説明し、有界な制御を提案できているか。
データに基づいて容量を検証できているか
候補者が単一の平均値を報告するのではなく、負荷テスト、p95/p99、キュー滞留時間、拒否率、回復時間を使用しているか。