LinuCレベル4 システムアーキテクト 可用性の設計 問12
可用性の設計／負荷分散と障害の局所化多数の取引先に公開しているAPIで、ある取引先のプログラムの不具合により短時間に大量のリクエストが送られ、他の取引先への応答まで大きく遅れた。今後、一部の取引先から過剰なリクエストが来ても他の取引先への影響を抑えたい。ただし、通常の利用量の範囲にある取引先は制限したくない。設計として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「可用性の設計」に対応。実際の試験問題ではありません）
- AAPIサーバーが外部のサービスを呼び出す箇所にサーキットブレーカーを入れ、呼び出し先の失敗が続いたら呼び出しを遮断する
- BAPI全体で単位時間あたりの受付件数に上限を設け、上限を超えたリクエストは取引先を区別せずにすべて拒否する
- C取引先ごとに単位時間あたりの受付件数に上限を設け、超えた分はHTTP 429で拒否して再試行までの待ち時間を伝える
- D負荷に応じてAPIサーバーの台数を自動で増やし、どの取引先からのリクエストも制限せずにすべて受け付けて処理する
正解：C
解説
特定の利用者からの過剰な要求がシステム全体に波及するのを防ぐには、利用者（APIキーなど）ごとに受付量の上限を設けるスロットリングが有効です。上限を超えた要求は429 Too Many Requestsで早期に拒否し、Retry-Afterヘッダなどで再試行までの時間を伝えると、クライアント側も適切に間隔を空けられます。全体で一律に制限すると、過剰な取引先の要求が上限枠を使い切り、正常な取引先まで拒否されてしまいます。サーキットブレーカーは呼び出し先の障害から呼び出し元を守る仕組みで、入ってくる要求の制御には使いません。
選択肢ごとの解説
- A誤り。サーキットブレーカーは下流のサービスの障害が呼び出し元に波及するのを防ぐもので、特定の取引先からの過剰な流入は抑えられません。
- B誤り。全体の上限だけでは過剰な取引先の要求が枠を占有し、通常の利用量の取引先まで拒否されるため、要件を満たしません。
- C正しい。取引先ごとに上限を設けることで、過剰な取引先だけを制限し、他の取引先の処理能力を守れます。
- D誤り。台数を増やしても過剰な要求が増えた資源を使い続けるうえ、費用もかさみ、特定の取引先の影響を切り離すことにはなりません。