応用情報技術者 2015年 秋期 午後 問10

解答の論理構成

1. 【問題文】には
   「図2の日別のリソース使用率は、該当日の時間帯ごとのリソース使用率の平均値」
   とある。図2だけでは“平均的”な負荷しか分かりません。
2. 一方で
   「図3の時間別のリソース使用率は、時間帯ごとのリソース使用率のピーク値」
   と明記されており、ここで初めて“最大”負荷が把握できます。
3. 仮想サーバを配置する際は、リソースが不足すると「業務システムが稼働できなくなる」と【問題文】で注意されています。したがってピーク時でも不足しない値を見積もる必要があり、そのためには図3が不可欠です。
4. 以上より、「リソース使用率の最大値を把握する必要があるから」と結論づけられます。

誤りやすいポイント

• 平均値とピーク値の違いを読み飛ばし、図2だけで判断してしまう。
• ピークが一日のどの時間帯かまで見る必要があると誤解し、設問意図から逸脱する。
• 「最大値」ではなく「変動」や「傾向」と答えてしまい、的を外す。

FAQ

解答の論理構成

• 問題文は在庫管理システムについて「年間を通じて業務ピーク月である6月の処理量が他の月と比べて多くなる傾向がある。」と明記しています。
• 図2（先月＝9月の月間平均）と図3（先月の業務ピーク日）は直近データのみを示しており、最大負荷が想定される “業務ピーク月” に関する情報が欠けています。
• システム規模見積りでは年間で最も大きい負荷を基準にしなければ、リソース不足による業務停止リスクが残存します。
• よって追加で確認すべき指標は「業務ピーク月」、具体的には「6月」のリソース使用率となり、模範解答は「業務ピーク月のリソース使用率」又は「6月のリソース使用率」となります。

誤りやすいポイント

• 直近の9月データだけで判断し、年間最大ピーク（6月）を見落とす。
• 図3の“1日”を年間ピークと誤解し、月次ピークを無視する。
• CPU・メモリ・ストレージの個別傾向に気を取られ、最重要である“時期”の視点を抜かす。

FAQ

解答の論理構成

• 【問題文】には、在庫管理システムの仮想サーバについて
  「VM11,12の配置先を物理サーバSVO2とし」とあります。
  すなわち SV02 に新たに2台の仮想サーバを載せる計画です。
• 【表2　見積もったリソース値】より、両サーバは
  「VM11 … メモリ容量（Gバイト）12」「VM12 … メモリ容量（Gバイト）12」。
  合計 24 Gバイト のメモリを追加割当てする必要があります。
• 一方、【表1仮想サーバのリソースの割当て】で SV02 の既存メモリ割当ては
  「VM05 8」「VM06 20」「VM07 16」で、合計 44 Gバイト。
• 【問題文】には「物理サーバSV01～03が割当て可能な最大のリソース値は … メモリ容量が64Gバイト」とあります。
• したがって、追加後のメモリ総量は
  44 G + 24 G = 68 Gバイト ＞ 64 Gバイト。
  上限を超えるため、SV02では必要なメモリを割当てられないという不備が生じます。

誤りやすいポイント

• vCPUは余裕があるためメモリ不足に気付きにくい。
• 【表1】のメモリ合計「44」を見落とし、個々の値を足し忘れる。
• 「共用ストレージが不足」と早合点し、メモリ上限64 Gを確認しない。

FAQ

解答の導き方

1. 現状の各物理サーバの割当状況を読み取る
   表1の合計行に「SV01はvCPU 8、メモリ28、SV02はvCPU 4、メモリ44、SV03はvCPU 3、メモリ8」とあることを確認します。
2. 物理サーバの最大値から空きリソースを算出する
   物理サーバの最大は「vCPU数が8、メモリ容量が64Gバイト」とあるので、サーバごとに空きを計算します。計算は次のとおりです。
   • SV01：vCPU空き $=8-8=0$、メモリ 空き $=64-28=36$ Gバイト
   • SV02：vCPU空き $=8-4=4$、メモリ 空き $=64-44=20$ Gバイト
   • SV03：vCPU空き $=8-3=5$、メモリ 空き $=64-8=56$ Gバイト
3. 移行対象の仮想サーバの要求値を確認する
   表2で「VM11はvCPU 1、メモリ12、共用ストレージ300」、「VM12はvCPU 1、メモリ12」とあります。各VMの必要値は「vCPU 1、メモリ12」で同じです（VM11は追加で共用ストレージ300を要求）。
4. サーバごとに配置可否を判定する（障害時は考慮しない）
   • SV01：vCPU空きが $0$ なので、vCPU要求1を満たせません。したがってSV01にはVM11もVM12も配置できません。
   • SV02：vCPU空き $=4$ でvCPUの面ではVMを2台分受けられますが、メモリ空き $=20$ GバイトのためVM2台分のメモリ合計 $12+12=24$ Gバイトは収容できません。よってSV02には「1台まで」配置可能で、2台同居は不可です。
   • SV03：vCPU空き $=5$、メモリ空き $=56$ Gバイトで、VM2台分（合計vCPU $=2$, メモリ $=24$ Gバイト）を十分に収容できます。したがってSV03にはVMを1台でも2台でも置けます。
   以上から、各VMの配置候補はSV02またはSV03（SV01は除外）であり、両方をSV02に置く組合せだけが不可となります。全候補を列挙すると（SV02/SV03の組合せのうち）有効なものは次の3通りです。
   • VM11：SV02、VM12：SV03
   • VM11：SV03、VM12：SV02
   • VM11：SV03、VM12：SV03
5. 共用ストレージの確認（補助）
   表1の共用ストレージ割当て合計は「1,400」 Gバイトで、VM11が「300」 Gバイトを要求します。追加しても $1,400+300=1,700$ Gバイトで、共有容量「3Tバイト」と比較して問題ありません（共用ストレージは配置先に依存しないため配置の可否判定には影響しません）。
6. 表3（完成）
   | 仮想サーバ | 案1 | 案2 | 案3 | 案4 | 案5 | |---|---:|---:|---:|---:|---:| | VM11 | SV02 | SV03 | SV03 | ／ | ／ | | VM12 | SV03 | SV02 | SV03 | ／ | ／ |

誤りやすいポイント

• 表1・表2の数値の読み間違い：表1の合計行や表2の「メモリ12」を誤って別の値（例：8）と記入すると判定が変わりやすいです。数値は原表を確実に読み取ってください。
• vCPUの余裕だけで判断するミス：SV02はvCPUに余裕があるため一見VM2台を置けそうに見えますが、メモリが不足しているため不可です。必ずvCPUとメモリの両方を満たすかを確認してください。
• SV01を見落としての配置：SV01は既にvCPUが満杯（空き $=0$）なので、ここに置けないことを見落としがちです。
• 共用ストレージの誤認：共用ストレージは物理サーバ個別の容量制約とは異なり、全体容量での管理です。配置先判定では通常影響しませんが、全体容量不足がないかは確認しておきます。
• 問題文の条件（障害時を考慮しない）を誤って適用するミス：設問で「障害時のことは考慮しない」とある場合、フェイルオーバー先の空き状況を前提に配置可否を判断してはなりません。

FAQ

解答の論理構成

1. 現行環境の制約
   • 問題文には「物理サーバ SV01～03 が割当て可能な最大のリソース値は、それぞれ vCPU数が8、メモリ容量が64Gバイト である。このサーバ仮想環境では、最大のリソース値を超えた割当てはできない。」とあります。
   • さらに「物理サーバに障害が発生した場合…別の物理サーバへ移動…必要なvCPU数及びメモリ容量が割当てできない場合には、移動は行われない。」とも記述されています。
     ⇒ 物理サーバ側に“空き”がなければ、フェイルオーバー時に仮想サーバを受け入れられません。
2. 変動負荷への対応
   • 「各業務システム…仮想サーバに割り当てたリソース値は…最小値であり…」とあるとおり、実運用では業務量や障害時に追加リソースが必要になるケースがあります。
   • したがって「仮想サーバへ割り当てたリソース値を業務量に応じて迅速に増やすためには、稼働する物理サーバのリソース値にある程度の余裕をもたせておく必要がある。」という解答群イは、そのまま上記要件への対応策を述べており適切です。
3. 利用効率の最適化
   • vCPU・メモリのいずれかだけが先に上限へ達すると、もう一方の空きが残っていても新規割当てや移動ができなくなります（リソースホールの発生）。
   • よって「物理サーバのリソースの利用効率を高めるためには、仮想サーバの配置先はメモリとvCPUのリソース値の空き割合が偏らないように考慮する必要がある。」という解答群オが最も妥当です。
4. 他選択肢の妥当性確認
   • ア：リソース値はピークや障害時に変動するため「常に同じ値」とは言えず不適。
   • ウ：SV01への優先配置を示す根拠はなく、均等化には個々の空き状況を見て割り当てるべきで不適。
   • エ：問題文で「最大のリソース値を超えた割当てはできない。」と明示されており、メモリも例外ではないため不適。

誤りやすいポイント

• 「最小値＝固定値」と早合点し、ピーク時のリソース増加や障害移動を忘れる。
• 片方のリソース（vCPUかメモリ）のみを指標にして配置を決め、リソースホールを見落とす。
• 図1の現状配分を見て「SV01が空いているから優先」と短絡的に判断し、長期的なバランスを無視する。
• オーバーコミット可能と誤解し「メモリは上限を超えても大丈夫」と考えてしまう。

FAQ

解答の論理構成

• 物理サーバ障害時の自動移動機能は〈“移動しようとした先の物理サーバで必要なvCPU数及びメモリ容量が割当てできない場合には、移動は行われない。”〉とあり、リソース上限に達すると一部仮想サーバが移動できません。
• そのためG部長は〈“当面の対応として、移動させる仮想サーバについて、③業務特性に応じた制限を加える必要がある”〉と指示しました。
• 業務特性の中で最も明確な軸は可用性要求です。本文には〈“稼働停止が許されない業務上の重要性が高いシステム（販売管理及び生産管理）と、それ以外の数日間程度の停止であれば許されるシステムがある”〉と記述されています。
• よって、障害時に優先して移動させるのは停止が許されない“業務上の重要性が高いシステム”であり、それ以外は制限対象とする方針が妥当です。
• 以上から制限内容は「業務上の重要性の高さ」に基づくものとなります。

誤りやすいポイント

• 「リソース量が大きい仮想サーバを制限する」と勘違いし、可用性ではなくサイズで優先度を決めてしまう。
• 高可用性要件を「販売管理」「生産管理」だけに固定してしまい、“今後追加される重要業務”への適用を忘れる。
• 制限＝「移動禁止」と早合点し、実際には“優先度を付けて移動を制御する”ことを見落とす。

FAQ