ITサービスマネージャ 2014年 午後1 問01
ITサービスの設計に関する次の記述を読んで、設問1～4に答えよ。
X社は、全国に家電量販店を20店舗展開している。各店舗の営業時間は9時から22時までで、休業日は月1回である。X社では、情報システム部が販売システムを運用し、販売業務を支援するITサービスとして提供している。
X社では業務拡大に伴い、販売システムを再構築することになった。再構築に当たっては、必要なアプリケーションの開発を行うとともに、インフラストラクチャを更新し、新規ITサービスを提供する計画である。現在、ITサービスマネージャのH氏が、新規ITサービスに関する設計を行っている。
〔新規ITサービスの概要〕
(1) 新規ITサービスの内容及びサービスレベル目標
新規ITサービスには、店舗で店員がPOSレジを用いて行う販売業務を支援する販売支援サービスと、店長が検索端末から行う販売分析業務を支援する情報検索サービスがある。これらのサービスを利用する店舗を統括している販売部から要求されているサービスレベル目標は、表1のとおりである。
(2) 再構築後の販売システムの構成及び処理概要
再構築後の販売システムの構成を図1に、処理概要と処理の流れを表2に示す。
販売実績レコードは、APサーバ②で毎日1時に起動されるバッチ処理によって、販売日・販売店舗・商品コード・会員番号ごとに販売数及び販売金額が集計され、販売情報集計レコードとして情報検索DB群に反映される。バッチ処理の処理時間は15分である。バッチ処理では、前日の開店から閉店までの販売実績レコードが処理される。
確認用POSレジ及び確認用検索端末（以下、これらを確認用端末という）は、店舗でインシデントが発生した場合、情報システム部がインシデントを再現して確認するための機器である。情報システム部は確認用端末を使用してインシデントの内容を確認した後、サービスレベル目標に従って販売部に障害発生連絡を行う。
〔サービスの可用性を考慮した構成検討〕
情報システム部サーバルームには機器メーカの保守員が常駐し、故障した機器を復旧させる。その際、必要となる部品はX社に常備されている。
H氏は、サービスレベル目標に従ってサービスの可用性を維持するために、機器が故障した場合に備えて、機器を冗長化する必要があるかどうかの検討を行った。機器を冗長化した場合、故障した機器は自動的に他の機器に切り替えられ、サービスを継続することができる。H氏は、複数の機器の故障が同時に発生しないことを前提に、検討結果を表3にまとめた。ここで、冗長化が必要な場合は“○”を、不要な場合は“×”を、当該サービス提供時に利用しない場合は“－”を記入した。
ルータ及びSWは、当該機器の復旧完了によってサービス回復となるが、Webサーバ及びAPサーバは、当該機器の復旧完了後にアプリケーションの動作確認のために15分必要である。
その後、販売部から、販売支援サービスに“お得意様割引機能”を追加したいという要求があり、情報システム部で対応することにした。この機能は、X社の会員に対する販売業務において、店員が販売支援サービスを使用する際、情報検索DB群を自動的に検索し、過去の一定期間における購入金額累計が一定金額以上に達している場合に割引を適用するというものである。検索の際には、APサーバ②のDB検索アプリケーションを使用する。この要求を受け、H氏は機器の冗長化の必要性について見直すことにした。
〔バックアップ方式の検討〕
H氏は、ストレージ機器の故障を想定し、情報検索DB群のバックアップ方式の検討に着手した。ストレージ機器が故障した場合には、機器の復旧に40分、リストア後の確認などの回復作業に20分掛かる。情報検索DB群には過去5年分の販売情報集計レコードが格納されており、新商品の販売開始、既存商品の販売終了によってレコード件数の変動はあるものの、データ量はほぼ一定である。
H氏は、表4に示す案1と案2のバックアップ方式案を策定した。
〔応答性能確保に向けた方策の検討〕
H氏の当初の想定では、各サーバはキャパシティに余裕があり、来店客数が想定どおりの場合は、“お得意様割引機能”を導入してもサービスレベル目標に定められた応答性能を実現できる見込みであった。しかし、再構築した販売システムの稼働開始後、来店客数の増加などによって、平常時のCPU使用率が当初の想定よりも上昇した場合、当日に実施が決定されるセールの開催で突発的に業務量が増加すると、APサーバ②のCPU使用率が安定稼働の基準値を超え、販売支援サービスの応答性能が急激に悪化することが予想された。そこでH氏は、APサーバ②のCPU能力を増強することにしたが、CPU能力の増強には数か月掛かる。
H氏は、APサーバ②のCPU能力が増強されるまでの間、販売支援サービスの応答性能悪化の兆候が見られる場合には、情報検索サービスの使用を中止するよう、各店舗に対して通知するという暫定対策を策定した。
後日、H氏が策定した暫定対策は、関係者の同意を得て実施されることになった。
設問1：
問題文を見る〔新規ITサービスの概要〕について、店舗でインシデントが発生したときに、情報システム部がインシデントを再現して確認する場合において、図1の販売システムの問題点を、構成上の観点から60字以内で述べよ。
模範解答
確認用端末がサーバとIP-VPNを介して接続されていないので、確認用端末でインシデントを再現できないおそれがある。
解説
解答の導き方
-
確認用端末の目的を確認します。本文には、確認用POSレジと確認用検索端末は「インシデントを再現して確認するための機器」とあります。したがって、確認用端末は、店舗でインシデントが起きたときの利用環境に近い構成で接続されている必要があります。
-
店舗の端末からサーバまでの経路を図1で確認します。店舗のPOSレジや検索端末は、店舗内のSWとルータを経由し、IP-VPNを通ってサーバルーム側のネットワークに接続されています。
-
一方、確認用端末はサーバルーム内にあり、図1ではサーバなどと同じサーバルーム側のSWに接続されています。店舗の端末が通るIP-VPNの経路は経由していません。
-
そのため、確認用端末からサービスに接続できたとしても、店舗からの通信経路とは異なります。通信経路に関係するインシデントは、店舗と同じ条件で再現できないおそれがあります。構成上の問題点として、確認用端末がサーバとIP-VPNを介して接続されていない点を指摘します。
誤りやすいポイント
- 確認用端末とサーバが同じSWに接続されていることだけを見て、店舗と同じ接続環境だと判断しないようにします。店舗からサーバまでの経路にはIP-VPNがあります。
- 「確認用端末からサーバに接続できない」と断定するのは適切ではありません。問題は接続そのものではなく、店舗とは異なる経路で接続しているため、インシデントを再現できないおそれがあることです。
- サーバやアプリケーションの台数ではなく、確認用端末と店舗端末のネットワーク経路の違いに着目します。
FAQ
Q: 確認用端末がサーバルーム内にあること自体が問題ですか？
A: 位置だけが問題なのではありません。店舗からはIP-VPNを経由しますが、確認用端末はその経路を通らないという接続構成の違いが問題です。
A: 位置だけが問題なのではありません。店舗からはIP-VPNを経由しますが、確認用端末はその経路を通らないという接続構成の違いが問題です。
Q: IP-VPNを経由しないと、どのようなインシデントを再現しにくくなりますか？
A: IP-VPNを含む通信経路に関係する問題です。店舗からの接続時にだけ発生する通信上の事象などは、確認用端末では同じ条件にならない可能性があります。
A: IP-VPNを含む通信経路に関係する問題です。店舗からの接続時にだけ発生する通信上の事象などは、確認用端末では同じ条件にならない可能性があります。
関連キーワード: IP-VPN、ネットワーク経路、接続構成、障害再現
設問2：
問題文を見る模範解答
a：○
b：×
解説
解答の導き方
表3では、機器を冗長化しない場合にサービス回復時間の目標を満たせるかどうかで判断します。機器を復旧させるだけでなく、サービスの回復までに必要な時間を比べることがポイントです。
まず、ルータ及びSWは、機器の復旧完了によってサービス回復となります。表3の復旧時間は20分なので、サービス回復時間の目標が「1時間以内」の販売支援サービス、「2時間以内」の情報検索サービスのどちらでも、冗長化しなくても目標を満たせます。
一方、Webサーバ及びAPサーバは、機器の復旧後にアプリケーションの動作確認が必要です。問題文には「当該機器の復旧完了後にアプリケーションの動作確認のために15分必要」とあります。したがって、APサーバのサービス回復までの時間は、復旧時間の50分に確認時間の15分を加えた65分です。
[a]は、販売支援サービスで使うAPサーバ①です。販売支援サービスの目標は「1時間以内」ですが、APサーバ①を冗長化しない場合、回復までに65分かかり、目標を超えます。そのため、APサーバ①は冗長化が必要です。
[b]は、情報検索サービスで使うAPサーバ②です。情報検索サービスの目標は「2時間以内」です。APサーバ②を冗長化しなくても、回復までの65分は目標の範囲内なので、冗長化は不要です。
なお、表3の検討結果の後に、お得意様割引機能の追加要求があり、APサーバ②の利用範囲を見直すことになっています。[b]は、表3に示された情報検索サービスについて判断する欄です。後からの機能追加に伴う再検討とは区別して考えます。
誤りやすいポイント
- APサーバの復旧時間を50分だけで判断しないことです。サービス回復には、復旧後のアプリケーション動作確認15分も必要です。
- 機器の復旧時間と、サービス回復時間の目標を混同しないことです。比べるのは、機器が直るまでの時間だけではなく、サービスが回復するまでの時間です。
- APサーバ①とAPサーバ②で同じ復旧時間でも、サービスごとに回復時間の目標が異なるため、冗長化の要否も異なります。
- 後から追加された機能の条件を、表3の空欄を埋める判断に混ぜないようにします。表3の検討結果と、その後の見直しは時系列を分けて読みます。
FAQ
Q: なぜAPサーバの復旧時間に15分を加えるのですか？
A: 問題文で、APサーバは機器の復旧後にアプリケーションの動作確認が必要とされているためです。サービスが回復するのは、その確認が終わった後です。
A: 問題文で、APサーバは機器の復旧後にアプリケーションの動作確認が必要とされているためです。サービスが回復するのは、その確認が終わった後です。
Q: APサーバ②の復旧時間はAPサーバ①と同じなのに、なぜ冗長化の要否が異なるのですか？
A: 販売支援サービスの目標は「1時間以内」、情報検索サービスの目標は「2時間以内」で、サービスごとの目標が異なるからです。
A: 販売支援サービスの目標は「1時間以内」、情報検索サービスの目標は「2時間以内」で、サービスごとの目標が異なるからです。
Q: お得意様割引機能の追加要求は、[b]の判断に影響しますか？
A: 表3の検討結果がまとめられた後の要求なので、[b]の判断とは分けます。追加後は、APサーバ②を利用する範囲が変わるため、冗長化の必要性を改めて検討します。
A: 表3の検討結果がまとめられた後の要求なので、[b]の判断とは分けます。追加後は、APサーバ②を利用する範囲が変わるため、冗長化の必要性を改めて検討します。
関連キーワード: 可用性、冗長化、サービス回復時間、障害復旧、フェイルオーバー
設問3：〔バックアップ方式の検討〕について、(1)、(2)に答えよ。
設問3（1）
問題文を見るH氏が策定した案1と案2のどちらを採用すべきか。答案用紙の案1・案2のいずれかを示せ。
なお、バッチ処理中、バックアップ・リストアの実施中及び回復作業中にストレージ機器の故障は発生しないものとする。
模範解答
案1
解説
解答の導き方
-
まず、バックアップ方式が満たすべき基準を確認します。情報検索サービスのサービス回復時間は、障害発生の検知からサービス回復まで「2時間以内」です。ストレージ機器が故障した場合、この時間内に機器の復旧、データのリストア、リストア後の確認などを終える必要があります。
-
ストレージ機器の復旧には40分、リストア後の確認などの回復作業には20分掛かります。したがって、両案とも、これらに加えてリストアに掛かる時間を見積もります。バックアップの取得時間ではなく、障害後のリストア時間を比較するのがポイントです。
-
案1では、最新のフルバックアップから復元します。リストアに掛かる時間は40分なので、障害発生からサービス回復までの合計は分です。「2時間以内」に収まります。
-
案2では、日曜日のフルバックアップに加えて、その後の月曜日から土曜日までの増分バックアップを順次復元する場合があります。最大で6日分の増分バックアップを復元するため、リストア時間は分です。これに機器の復旧40分と回復作業20分を加えると、合計は130分となり、「2時間以内」を満たしません。
-
以上から、サービス回復時間の目標を満たせる方式を選びます。
誤りやすいポイント
- バックアップの取得時間と、障害後のリストア時間を混同しないようにします。サービス回復時間の計算に加えるのは、障害後に必要な作業時間です。
- 案2のリストア時間を、フルバックアップの40分だけで計算してはいけません。フルバックアップの後に取得した増分バックアップも順次復元します。
- リストア後の確認などに掛かる20分を、計算から漏らさないようにします。
FAQ
Q: 案2で復元する増分バックアップは、なぜ6日分ですか？
A: 日曜日にフルバックアップを取得し、その後、月曜日から土曜日まで毎日増分バックアップを取得するためです。次の日曜日のフルバックアップより前に障害が発生すると、最大で6日分を復元します。
A: 日曜日にフルバックアップを取得し、その後、月曜日から土曜日まで毎日増分バックアップを取得するためです。次の日曜日のフルバックアップより前に障害が発生すると、最大で6日分を復元します。
Q: バックアップの取得時間は、なぜサービス回復時間に加えないのですか？
A: サービス回復時間は、障害発生の検知からサービス回復までの時間だからです。バックアップの取得時間は障害発生前の作業であり、障害後の復旧時間には加えません。
A: サービス回復時間は、障害発生の検知からサービス回復までの時間だからです。バックアップの取得時間は障害発生前の作業であり、障害後の復旧時間には加えません。
Q: 機器の復旧時間だけで、目標を満たすか判断できますか？
A: できません。機器の復旧に加えて、データのリストアと、リストア後の確認などの回復作業に掛かる時間も含めて判断します。
A: できません。機器の復旧に加えて、データのリストアと、リストア後の確認などの回復作業に掛かる時間も含めて判断します。
関連キーワード: フルバックアップ、増分バックアップ、リストア、サービス回復時間
設問3（2）
問題文を見る(1)の採用理由を、60字以内で具体的に述べよ。
模範解答
案1は、障害発生日時に関係なく、サービスレベル目標で定めているサービス回復時間内に回復できるから
解説
解答の導き方
まず、情報検索サービスに求められているサービス回復時間を確認します。表1では「2時間以内」と定められています。したがって、ストレージ機器の故障を検知してから、機器の復旧、データのリストア、回復作業を終えるまでの合計が、2時間以内に収まる必要があります。
ストレージ機器の復旧には40分、リストア後の確認などの回復作業には20分掛かります。このため、どちらの案でも、リストア時間に加えて合計60分を見込む必要があります。
案1は、毎日フルバックアップを取得し、最新のフルバックアップから復元します。リストアは40分なので、障害発生からサービス回復までの合計は、です。2時間の120分以内に収まり、障害発生日時にかかわらずサービス回復時間を満たせます。
案2は、日曜日のフルバックアップに加え、月曜日から土曜日までの増分バックアップを順次復元する方式です。最も時間が掛かる場合は、フルバックアップに加えて6日分の増分バックアップを復元します。リストア時間は、です。機器の復旧時間と回復作業時間も加えると、合計はとなり、2時間を超えます。
案2は障害発生日時によってはサービス回復時間内に収まりますが、いつ発生しても目標を満たせるとは限りません。そのため、採用するのは案1です。
誤りやすいポイント
- リストア時間だけを比べ、機器の復旧時間40分や回復作業時間20分を合計に含めないことです。
- 案2で復元する増分バックアップの数を、常に少ない数だと考えることです。最も時間が掛かる場合は、日曜日のフルバックアップの後に取得した6日分を復元します。
- 案2が一部の日程で2時間以内に回復できることを理由に、サービス回復時間を満たすと判断することです。障害発生日時にかかわらず目標を満たせるかがポイントです。
- バックアップの取得時間と、障害発生後のリストア時間を混同することです。この比較では、故障後の復旧・リストア・回復作業に掛かる時間を合計します。
FAQ
Q: 案2は、どの障害でも2時間を超えますか？
A: いいえ。復元する増分バックアップが少ない場合は2時間以内に収まることがあります。ただし、6日分を復元する場合は130分掛かるため、サービス回復時間を常に満たせるとはいえません。
A: いいえ。復元する増分バックアップが少ない場合は2時間以内に収まることがあります。ただし、6日分を復元する場合は130分掛かるため、サービス回復時間を常に満たせるとはいえません。
Q: なぜ機器の復旧時間も計算に含めるのですか？
A: サービス回復時間は、障害発生の検知からサービスの回復までの時間だからです。ストレージ機器の復旧が終わらなければ、リストアやその後の確認作業に進めません。
A: サービス回復時間は、障害発生の検知からサービスの回復までの時間だからです。ストレージ機器の復旧が終わらなければ、リストアやその後の確認作業に進めません。
Q: 増分バックアップの取得時間も合計に含めますか？
A: ここで比較するのは、障害発生後にサービスを回復するまでの時間です。そのため、障害後に行うリストア時間は含めますが、通常時のバックアップ取得時間は含めません。
A: ここで比較するのは、障害発生後にサービスを回復するまでの時間です。そのため、障害後に行うリストア時間は含めますが、通常時のバックアップ取得時間は含めません。
関連キーワード: フルバックアップ、増分バックアップ、リストア、サービス回復時間、バックアップ世代
設問4：〔応答性能確保に向けた方策の検討〕について、販売支援サービスの応答性能が悪化する前に暫定対策を実施できるように設計する。
設問4（1）
問題文を見るサービス運用段階でモニタリングする監視項目を、20字以内で述べよ。
模範解答
APサーバ②のCPU使用率
解説
解答の導き方
-
この設問では、販売支援サービスの応答性能が悪化する前に兆候を捉えるため、何を監視すべきかを考えます。
-
“お得意様割引機能”では、販売支援サービスの利用時に「APサーバ②のDB検索アプリケーション」を使って情報検索DB群を検索します。そのため、この機能による負荷はAPサーバ②に加わります。
-
本文では、平常時のCPU使用率が想定より上昇した状態で業務量が突発的に増えると、「APサーバ②のCPU使用率が安定稼働の基準値を超え」、販売支援サービスの応答性能が急激に悪化すると説明されています。つまり、応答性能悪化の前兆として確認すべきなのは、負荷の影響が表れるAPサーバ②のCPU使用率です。
誤りやすいポイント
- 販売支援サービスの応答時間を監視項目にすることです。応答時間は悪化そのものを示す指標になりやすいため、悪化前の兆候を捉えるという目的には、本文で原因として示されているCPU使用率が適しています。
- APサーバ①のCPU使用率を選ぶことです。“お得意様割引機能”でDB検索アプリケーションを使うのはAPサーバ②です。
- CPU使用率だけを挙げ、どの機器のものかを明示しないことです。負荷が問題となる対象を特定するため、APサーバ②まで示します。
FAQ
Q: CPU使用率が上がると、なぜ応答性能が悪化するのですか？
A: CPU処理能力に余裕がなくなると、処理の待ち時間が増え、要求への応答が遅くなるためです。
A: CPU処理能力に余裕がなくなると、処理の待ち時間が増え、要求への応答が遅くなるためです。
Q: なぜ販売支援サービスではなく、情報検索サービス側のサーバを監視するのですか？
A: “お得意様割引機能”の検索処理がAPサーバ②で行われ、その負荷が販売支援サービスの応答性能にも影響するためです。
A: “お得意様割引機能”の検索処理がAPサーバ②で行われ、その負荷が販売支援サービスの応答性能にも影響するためです。
Q: 監視項目と、暫定対策を実施する判断基準は同じですか？
A: 別のものです。監視項目は確認する指標であり、判断基準はその指標に設定するしきい値です。
A: 別のものです。監視項目は確認する指標であり、判断基準はその指標に設定するしきい値です。
関連キーワード: CPU使用率、性能監視、しきい値、キャパシティ管理、応答性能
設問4（2）
問題文を見る監視項目として、基準値とは別に新たにしきい値を設定し、暫定対策を実施することにした。暫定対策実施の判断方法について、しきい値も含めて60字以内で具体的に述べよ。
模範解答
基準値を超過する前に対策が実施できるようにしきい値を設定し、セール実施時に監視項目のしきい値超過の有無を判断する。
解説
解答の導き方
本文では、セールによって業務量が急増すると「APサーバ②のCPU使用率が安定稼働の基準値を超え」、販売支援サービスの応答性能が急激に悪化する可能性があると説明されています。したがって、監視する項目はAPサーバ②のCPU使用率です。
暫定対策は、販売支援サービスの応答性能が悪化する前に実施する必要があります。そのため、安定稼働の基準値を超えてから対策を始めるのでは遅くなります。基準値より手前で対策に移れるよう、別に設けるしきい値は、基準値を超過する前に判断できる値に設定します。
また、業務量が突発的に増える状況として本文に挙げられているのはセールの開催です。セール実施時にCPU使用率を確認し、しきい値を超えたかどうかを判断します。超過していれば、各店舗に「情報検索サービスの使用を中止する」よう通知する暫定対策につなげます。
誤りやすいポイント
- しきい値を安定稼働の基準値と同じにすると、基準値を超えてから対策することになり、応答性能悪化を防ぐのが遅れます。
- 応答性能の悪化そのものを待ってから対策するのではなく、その前兆となるAPサーバ②のCPU使用率を見て判断します。
- セール時に確認するのは、基準値を超えたかどうかだけではありません。基準値超過前に設定したしきい値を超えたかどうかを判断します。
FAQ
Q: なぜ監視項目を応答時間ではなくCPU使用率にするのですか？
A: 本文では、APサーバ②のCPU使用率が安定稼働の基準値を超えると、販売支援サービスの応答性能が急激に悪化するとされています。CPU使用率の上昇を捉えれば、性能悪化より前に対策できるためです。
A: 本文では、APサーバ②のCPU使用率が安定稼働の基準値を超えると、販売支援サービスの応答性能が急激に悪化するとされています。CPU使用率の上昇を捉えれば、性能悪化より前に対策できるためです。
Q: しきい値を超えたら、どのような対策につなげますか？
A: 各店舗に情報検索サービスの使用中止を通知し、APサーバ②の負荷を抑える暫定対策につなげます。
A: 各店舗に情報検索サービスの使用中止を通知し、APサーバ②の負荷を抑える暫定対策につなげます。
Q: いつ監視項目を確認すればよいですか？
A: 業務量が突発的に増える可能性があるセール実施時に確認します。
A: 業務量が突発的に増える可能性があるセール実施時に確認します。
関連キーワード: CPU使用率、性能監視、しきい値、キャパシティ管理
