ITサービスマネージャ 2011年 午後1 問02

解答の導き方

誤りやすいポイント

• トランザクション数だけを比べると、携帯電話の処理に必要なCPU使用時間がPCより大きい点を反映できません。携帯電話の指標には、表3の「1.2」を掛けます。
• PC会員と携帯会員の指標を単純に足すだけでは、端末種類ごとのCPU負荷の違いが反映されません。
• 1年後の負荷比率を、現在のCPU負荷の「48」％に加えるのではなく、現在値に負荷の倍率を掛けます。
• Webサーバ1台当たりの使用率を求めるため、負荷分散が均等であることを踏まえて現在の1台当たりの測定値を基準にします。

FAQ

解答の導き方

• 座席マスタファイル：$200\text{ GB}\times 1.2=240\text{ GB}$
• 会員マスタファイル：$300\text{ GB}\times 1.4=420\text{ GB}$
• 座席予約ファイル：$700\text{ GB}\times 1.5=1,050\text{ GB}$

誤りやすいポイント

• 1年後のファイル使用量を求める際、増加後の倍率を使用量に掛けず、増加分だけを計算してしまうことがあります。
• 必要な総容量で割り出した台数と、増設する台数を混同しないようにします。必要な総台数は12台で、現在の10台との差が増設台数です。
• 11台では容量が$3,300\text{ GB}$で、使用率は$1,710÷3,300\approx 51.8\%$となり、しきい値を超えます。端数の台数は使えないため、必要台数は切り上げます。

FAQ

解答の導き方

誤りやすいポイント

• 予約状況表示プログラムの機能テストだけで十分だと考えることです。機能が正しく動くことと、他の処理と同時に動かしても応答性能に問題がないことは別の確認事項です。
• 性能テストでピーク時のトランザクションを再現していれば十分だと考えることです。実際の遅延には、CPU負荷の高いプログラムの実行が重なっていました。
• 本番環境と同じシステム構成でテストすれば、実際の負荷状況も再現できていると考えることです。構成が同じでも、同時に実行する処理が異なれば、性能への影響を確認できません。

FAQ

解答の導き方

1. まず、遅延の原因となる状況を確認します。本文では、応答遅延が起きたときに「トランザクションのピーク時間帯に、APサーバで予約状況表示プログラムが実行されていた」と分かっています。
2. 予約状況表示プログラムは、大量の座席予約データを参照するため「CPU負荷が高い」処理です。一方、ピーク時間帯は会員からのトランザクションも多く、APサーバの処理負荷が重なります。その結果、予約処理に使えるCPUが減り、応答が遅くなったと考えられます。
3. 再発を防ぐには、予約状況表示プログラムの負荷が、トランザクションのピーク時間帯に重ならないように運用する必要があります。プログラムは営業部が必要になるたびに起動するため、営業部と調整し、ピーク時間帯にかかる実行を禁止します。ピーク時間帯以外の実行まで禁止する必要はありません。

誤りやすいポイント

• 予約状況表示プログラムの実行を全面的に禁止することが対策だと考えてしまうこと。原因となるのはピーク時間帯との重複なので、その時間帯に限って実行を制限します。
• プログラムの処理時間が通常5分程度であることから、影響は小さいと判断すること。実行時間の長短ではなく、CPU負荷の高い処理がピーク時の予約処理と重なることが問題です。
• システム部だけで対策を決めること。営業部がプログラムを起動するため、実行を制限する時間帯について営業部との調整が必要です。

FAQ

解答の導き方

1. 現在のキャパシティ管理では、各サーバのCPU使用率・メモリ使用率や磁気ディスク使用率を管理しています。これらは、システムを構成するリソースにどれだけ負荷がかかっているかを示す指標です。
2. 一方、発生した問題は、携帯会員から「応答が遅い」という苦情が寄せられたことです。また、トランザクションのピーク時間帯に、CPU負荷の高い予約状況表示プログラムがAPサーバで実行されていました。問題として現れたのは、リソース使用率そのものではなく、利用者への応答の遅れです。
3. CPU使用率などのリソース指標だけでは、利用者が実際にどれだけ待たされているかを直接把握できません。そこで、利用者の要求から応答までにかかる時間を管理対象に加えます。追加すべき管理項目は「応答時間」です。

誤りやすいポイント

• CPU使用率を追加すればよいと考えることです。CPU使用率はすでに管理対象であり、今回追加するのは利用者へのサービス状況を直接表す項目です。
• 応答遅延の原因となったプログラム名を答えることです。問われているのは、原因ではなくキャパシティ管理に追加する項目です。
• トランザクション数や処理件数を答えることです。これらは負荷の大きさを表しますが、利用者が応答を待つ時間を直接示すものではありません。

FAQ

解答の導き方

1. 現在のキャパシティ管理では、「CPU使用率、メモリ使用率、磁気ディスク使用率」にしきい値を設定し、使用率を基にリソースの増設要否を判断しています。これはサーバやディスクの負荷を管理する方法です。
2. しかし、リソース使用率を測定するだけでは、利用者が実際に感じる応答の遅れを直接判定できません。実際に、CPU負荷の高い予約状況表示プログラムがピーク時間帯にAPサーバで実行され、応答遅延が発生していました。
3. したがって、応答遅延の予兆を検知するには、リソース使用率に加えて、サービスの応答時間そのものを管理する必要があります。応答時間にしきい値を設け、それを判定条件として使えば、遅延が問題になる前に検知し、是正処置につなげられます。

誤りやすいポイント

• CPU使用率などのしきい値を細かく設定すれば十分だと考えること。リソースの負荷と利用者が感じる応答時間は、同じ指標ではありません。
• 応答時間を測定するだけで、判定基準を設けないこと。問題の予兆を検知するには、しきい値を設定して測定結果と比較する必要があります。
• 発生後の苦情を受けて対応するだけでよいと考えること。設問では、問題発生の予兆を検知し、是正処置をとれるようにする方法が問われています。

FAQ