LinuCレベル4 システムアーキテクト 性能・拡張性の設計 問22
性能・拡張性の設計／性能見積もりと評価Web→AP→DBの3層で構成するWebシステムで、エンドツーエンドのレスポンスタイム要件を1,000msと定めた。性能設計における考え方として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「性能・拡張性の設計」に対応。実際の試験問題ではありません）
- A1,000msの要件をWeb・AP・DBの各層とネットワーク遅延に割り振り、コンポーネントごとのレスポンスタイムバジェットを設けて測定基準と改善目標にする
- B各層はそれぞれ独立して1,000ms以内を目標にすればよく、合計がエンドツーエンドの要件を超えていても各層の測定結果を個別に評価する
- C各コンポーネントの処理時間は実装後の実測が唯一の根拠なので、設計段階では割り振りを行わず全体の1,000msだけを記録して問題発生後に調査する
- D3層なら各層に333msを均等配分するのが公平かつ最も合理的な割り振り方であり、各層の特性や呼び出し回数を考慮する必要はない
正解：A
解説
エンドツーエンドのレスポンスタイム要件を各コンポーネントに割り振るバジェット配分は、設計段階で性能問題を早期に発見するための重要な手法です。ネットワーク遅延・各層の処理時間を積み上げた合計がエンドツーエンドの要件に収まるよう各コンポーネントに目標を定めます。均等配分が適切とは限らず、1リクエストで何十回も往復するAP-DB間のDB処理など、コンポーネントの特性や呼び出し回数に応じた割り振りが必要です。コンポーネントごとの目標があることで、テスト時のボトルネック特定と改善対象の絞り込みも容易になります。
選択肢ごとの解説
- A正しい。エンドツーエンド要件を各コンポーネントへ割り振ったバジェットを設けることで、設計・測定・改善の基準を明確にできます。
- B誤り。各層の目標を独立して設けても、合計がエンドツーエンドの要件を超えれば利用者はSLAを満たせません。コンポーネントの合計が全体の要件に収まるよう割り振ります。
- C誤り。設計段階でバジェットを割り振らないと、どの層に問題があるか判断する基準がなく、実装後の問題発見が遅れます。
- D誤り。均等配分は合理的に見えますが、DBへの呼び出し回数が多い層や処理の重い層では均等配分が不適切になります。特性に応じた割り振りが必要です。