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

解答の導き方

1. 表2では、リソース管理項目ごとに「基準値」と「警告値」が設定されています。警告値を超えると運用管理システムから警告が出され、基準値はリソース使用状況を管理する上限です。
2. 本文には「基準値を超えると、パフォーマンスが急激に悪化するおそれがある」とあります。つまり、基準値を超えてから対応を始めると、性能が大きく悪化している可能性があります。
3. そこで、警告値を基準値より低く設定しておけば、基準値に達する前に警告を受け取れます。その段階で対処できれば、性能が悪化する前に是正処置をとる時間を確保できます。

誤りやすいポイント

• 警告値を、パフォーマンスが悪化したことを示す基準値と混同しないようにします。警告値は、基準値に達する前に注意を促すための値です。
• 警告値が低い理由を「リソース使用率を低く保つため」とだけ説明すると、基準値より低く設定する意味が伝わりません。基準値に達する前に対処できる点が重要です。
• 警告が出た時点で必ず性能が悪化している、という意味ではありません。性能悪化を未然に防ぐための警告です。

FAQ

解答の導き方

1. まず、キャパシティ計画の方針では、サービス面について「サービスレベルの要求水準を達成しているかどうか」の記録・監視を行うとしています。つまり、リソースの使用状況だけでなく、利用者が受けるサービスの性能も確認する必要があります。
2. 販売管理システムでは、オンラインレスポンスについて「5秒以内の遵守率を1日当たり99％以上」という要求水準があります。遵守率は、オンライン業務終了後にログファイルを分析して確認しています。
3. 一方、運用管理システムが警告を出す条件は、Webサーバと業務サーバのCPU使用率、磁気ディスク使用率が、それぞれ設定された警告値を超えることです。監視対象はリソースの使用状況であり、オンラインレスポンスの遵守率そのものではありません。
4. そのため、リソースの使用率が警告値を超えていなくても、オンラインレスポンスの要求水準を満たせないことがあります。実際に遵守率が要求水準を下回っても警告が出なかったことから、サービスレベルの達成状況を監視できる仕組みになっていない点が考慮不足です。

誤りやすいポイント

• CPU使用率や磁気ディスク使用率を監視していることだけで、サービスレベルも監視できていると考えないようにします。リソースの使用状況と、利用者が受ける応答性能は別の指標です。
• オンライン業務終了後にログを分析していることと、要求水準を達成できない状況を監視して警告できることは同じではありません。
• 問題は警告値の大小ではなく、警告の監視対象がオンラインレスポンスの要求水準と結び付いていないことです。

FAQ

解答の導き方

1. 問われているのは、キャパシティ管理が変更管理とどのように連携するかです。本文では、変更管理との連携内容として「パフォーマンス改善の変更要求を提案する」とあります。これは、性能上の問題に対する変更を提案する側面を示しています。
2. しかし、変更を提案するだけでは、変更後に性能がどう変わるかは分かりません。変更によって処理量やリソースの使用状況が変わり、サービスの性能に影響する可能性があるため、実施前にその影響を確認する必要があります。
3. したがって、変更管理との連携としては、変更の計画段階でパフォーマンスへの影響を検証することが適切です。変更を実施した後に問題が起きてから調べるのではなく、計画段階で影響を評価する点がポイントです。

誤りやすいポイント

• 変更管理との連携を、性能改善の変更要求を提案することだけで終わらせないようにします。変更による性能への影響を事前に確認することも必要です。
• インシデント管理で行う「インシデント数の推移を捕捉すること」と混同しないようにします。ここでは、変更を計画する段階での影響検証が問われています。
• 実施後の性能監視ではなく、変更を実施する前の検証である点に注意します。

FAQ

• Q: なぜ変更の計画段階で検証するのですか？
  A: 変更によって性能が悪化するリスクを、実施前に把握して対処するためです。
• Q: 性能改善の変更要求を提案すれば、影響検証は不要ですか？
  A: 不要ではありません。改善を目的とした変更でも、実施による性能への影響を別途確認する必要があります。
• Q: 変更後に監視すれば十分ですか？
  A: 変更後の監視も重要ですが、変更の計画段階で影響を検証することで、問題の発生を未然に防ぎやすくなります。

解答の導き方

1. まず、設問は、オンライン業務中に一部のバッチ処理を実行する運用変更の前に、キャパシティ管理として何を確認すべきだったかを尋ねています。したがって、変更後に発生した障害への対処ではなく、変更前の性能検証で想定すべき条件を考えます。
2. 本文には、通常時は業務サーバAと業務サーバBの2台で運用し、「どちらか1台に障害が発生した場合には、もう1台の縮退構成で運用する」とあります。つまり、通常構成だけでなく、1台で処理する片寄せ運用も想定して性能を確認する必要があります。
3. 運用変更前の性能テストでは、「通常の本番構成でピーク時の性能テスト」を行い、オンライン業務中にバッチ処理を実行した場合の影響を確認しています。しかし、この検証では、片寄せ運用で同じ処理を行う条件までは確認できていません。通常構成で性能に問題がなくても、片寄せ運用では1台のサーバに処理が集中するため、結果が同じになるとは限りません。
4. 実際に業務サーバBが故障した後は、オンライン業務を処理している業務サーバAでバッチ処理を開始した直後にレスポンスが悪化しました。さらに、片寄せ運用時にはオンライン業務だけでメモリ使用量がほぼ限界に達し、バッチ処理の起動でページングが多発したと分かっています。このことから、ピーク時のオンライン業務とバッチ処理が重なる状況を、片寄せ運用でも検証すべきだったと判断できます。
5. したがって、確認すべきなのは、片寄せ運用の状態でオンライン業務中にバッチ処理を実行したとき、ピーク時の負荷でも性能を維持できるかどうかです。

誤りやすいポイント

• 通常構成で性能テストを実施済みであることだけを根拠に、事前確認は十分だったと考えることです。障害時の縮退構成は通常構成と負荷のかかり方が異なります。
• 「ピーク時の性能検証」だけを答え、片寄せ運用とオンライン業務中のバッチ処理という条件を落とすことです。検証条件を具体的に示す必要があります。
• バッチ処理を単独で実行する場合や、オンライン業務の負荷が低い場合のテストと取り違えることです。問題となるのは、ピーク時のオンライン業務とバッチ処理が重なる条件です。

FAQ

解答の導き方

1. まず、現在のリソース管理項目を確認します。本文では「Webサーバと業務サーバのCPU使用率及び磁気ディスク使用率」を把握するとあります。つまり、CPUと磁気ディスクは監視対象ですが、メモリの使用状況は管理項目に含まれていません。
2. 次に、オンラインレスポンスが悪化した原因を確認します。片寄せ運用時、業務サーバAではオンライン業務の処理中にメモリ使用量がほぼ限界に達しており、バッチ処理が起動するとページングが多発していました。したがって、性能悪化の原因はメモリ不足に関係しています。
3. キャパシティ管理では、リソースの使用状況を定常的に測定・監視します。今回の事象を日常の管理で把握できるように、CPU使用率や磁気ディスク使用率に加えて、サーバの実メモリ使用状況を管理項目にします。

誤りやすいポイント

• CPU使用率や磁気ディスク使用率を追加するのではありません。今回の性能悪化に直接関係したのは、メモリの使用状況です。
• 「ページング」はメモリ不足が性能に影響したことを示す現象です。問われているのは現象そのものではなく、日常的に管理するリソース項目です。
• オンラインレスポンスの遵守率だけを監視するのでは不十分です。応答性能の結果に加え、原因となるリソースの使用状況も把握する必要があります。

FAQ

解答の導き方

1. まず、暫定対応が何を避けるためのものかを確認します。業務サーバBに障害が起きて片寄せ運用になると、業務サーバAではオンライン業務だけでメモリ使用量がほぼ限界に達します。そこへバッチ処理が加わるとページングが多発し、オンラインレスポンスが悪化します。そのため暫定対応では、片寄せ運用中はオンライン業務中にバッチ処理を実行しないようにしています。
2. 次に、その対応を続けたときに生じるリスクを、運用変更の背景と照らして考えます。本文には、オンライン業務のサービス時間を延長した結果、バッチ業務の終了から翌日のオンライン業務開始までの空き時間が少ないとあります。また、バッチ業務でトラブルが起きると、翌日のオンライン業務開始が遅れるおそれも示されています。
3. つまり、暫定対応によってオンライン業務中のバッチ処理を避けても、バッチ業務そのものが不要になるわけではありません。限られた時間内にバッチ業務を終える必要があるため、そこでトラブルが発生すると、翌日のオンライン業務開始に間に合わない可能性があります。したがって、暫定対応を継続するリスクは、バッチ業務でのトラブル発生時にオンライン業務開始が遅れることです。

誤りやすいポイント

• ページングの多発は、暫定対応を設けた理由です。問われているのは、暫定対応を継続した場合に別途生じるリスクです。
• 「オンラインレスポンスが悪化する」と答えるだけでは、暫定対応を続けることで何が起きるのかを説明できていません。
• バッチ処理の実行を避けることと、バッチ業務をなくすことは異なります。限られた時間内にバッチ業務を終える必要がある点に注意してください。

FAQ

解答の導き方

1. キャパシティ計画では、ビジネス要件として表1の「ピーク時トランザクション数の予測（指標）」を使っています。したがって、今回の需要予測の変化が、ピーク時の処理量にどう影響するかを確認する必要があります。
2. 企画部門の予測には、キャンペーン期間中の業務量が「2割程度増加」することが織り込まれています。また、2010年度以降もキャンペーンを実施する計画です。このため、キャンペーンのない場合を前提とした現在の予測のままでは、ピーク時の需要を適切に見積もれない可能性があります。
3. ただし、業務量が増えるという情報だけでは、ピーク時のトランザクション数がどれだけ増えるかは確定できません。最新の販売計画からピーク時のトランザクション数を算出し、表1に示された現在の予測値と比較して、どの程度の差があるかを把握します。その差を明らかにすることで、キャパシティ計画の見直しが必要かどうかを判断できます。

誤りやすいポイント

• 「2割程度増加」を、そのまま年間を通じて一律に需要が増えると解釈しないようにします。増加が見込まれているのはキャンペーン期間中の業務量です。
• 業務量の増加を指摘するだけでは、現在のキャパシティ計画に対する影響を具体的に判断できません。ピーク時トランザクション数に換算して、既存の予測値と比較するところまで述べます。
• 需要の増加を受けて、すぐにリソースを増強すると答えるのは早計です。まず予測値との乖離を把握し、計画への影響を判断することが必要です。

FAQ

解答の導き方

1. キャパシティ計画の方針では、ビジネス要件を検討し、必要なリソースを適切なタイミングで実装するとしています。したがって、ビジネス側の計画に変化があれば、その変化をキャパシティ計画に反映する必要があります。
2. 今回、企画部門から得た最新の販売計画では、「キャンペーン期間中の業務量が2割程度増加」すると予測されています。これは、販売管理システムが処理すべき業務量の見込みが従来の予測から変わることを意味します。
3. さらに、販売キャンペーンは「今後3年間の需要予測」に含まれ、成功すれば「2010年度以降も6月と12月」に実施する計画です。一度限りの変動ではなく、今後のキャパシティにも関わる変更です。
4. そこで、キャンペーンを含む最新の需要予測を基に、既存のキャパシティ計画で必要な処理能力を確保できるか、リソースをいつ用意すべきかを再検討します。単にリソースを直ちに増やすのではなく、変化した需要予測を計画に反映することが求められます。

誤りやすいポイント

• 「業務量が2割程度増加」することだけから、リソースを直ちに2割増強すると決めつけないようにします。まず、需要予測をキャパシティ計画に反映し、必要なリソースと導入時期を検討します。
• 今回の12月のキャンペーンだけを対象にすると、今後も6月と12月に実施する計画を見落とします。将来の需要予測も考慮します。
• キャパシティ計画に既にある予測だけで十分と判断しないようにします。キャンペーンを含む最新の販売計画が示されたため、計画を見直す必要があります。

FAQ