LinuCレベル4 システムアーキテクト 性能・拡張性の設計 問27
性能・拡張性の設計／性能の拡張外部決済APIへの同時接続数が増え、外部API側のレート制限に頻繁に抵触するようになった。内部のアプリサーバーは水平スケールしており、台数が増えるほど同時接続数も比例して増える。この問題を設計で解決する方針として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「性能・拡張性の設計」に対応。実際の試験問題ではありません）
- Aアプリサーバーをさらにスケールアウトして処理スループットを上げ、外部APIの呼び出しを個々のサーバーで分散させる
- B外部APIへの呼び出しをメッセージキュー経由の非同期処理に変え、ワーカーの台数を固定して同時接続数を外部APIのレート制限以内に抑える
- CアプリサーバーのCPUコア数を増やすスケールアップを行い、1台あたりの処理スレッド数を増やすことで外部APIの応答待ちを短縮する
- D外部APIのベンダーにレート枠の拡張を申請し、現在の制限を超えた同時接続数を許可してもらう
正解：B
解説
アプリサーバーの台数増加と外部APIへの同時接続数が比例する構成では、スケールアウトを続けるほど問題が悪化します。外部APIへの呼び出しをメッセージキュー経由に変えてワーカー台数（共有資源へのアクセス数）を固定することで、アプリサーバーの台数にかかわらず外部APIへの同時接続数をレート制限以内に抑えられます。スケールアップも外部APIへの同時接続数の問題の根本解決にはなりません。ベンダーへの申請は設計上の解決ではなく、レート制限が再び引き上げられない保証もありません。
選択肢ごとの解説
- A誤り。スケールアウトすると外部APIへの同時接続数がさらに増え、問題が悪化します。
- B正しい。メッセージキューを介してワーカー数を固定することで、アプリサーバーの台数にかかわらず外部APIへの同時接続数を一定に抑えられます。これは共有資源（外部API）へのアクセスを制限する設計です。
- C誤り。スケールアップは1台の処理能力を上げますが、アプリサーバー台数が同じなら外部APIへの同時接続数は変わらず、問題の根本解決にはなりません。
- D誤り。ベンダーへの申請は設計上の解決策ではなく、レート制限が恒久的に引き上げられる保証もありません。