ITサービスマネージャ 2010年 午後1 問02
可用性管理に関する次の記述を読んで、設問1〜4に答えよ。
C社は、全国に約100か所のホテルを運営する大規模ホテルチェーンである。ホテルの宿泊予約の受付は、表1に示す三つの方式で行っている。C社では今後、代理店手数料の掛からない予約方式1の取扱比率を拡大していく方針である。
〔宿泊予約システムの構成〕
全ホテルの宿泊予約は、C社データセンタに設置された宿泊予約システムで集中管理されている。宿泊予約システムの構成を図1に示す。ファイアウォール（以下、FWという）及び負荷分散装置（以下、LBという）は、二重化されている。
〔予約方式1の処理概要〕
C社Webサイトの利用者からの要求は、LBでWebサーバに振り分けられ、APサーバで処理される。APサーバで空室の検索処理や予約処理を行い、DBサーバの客室在庫データを参照し、更新する。
LBは、利用者からの要求を2台のWebサーバに均等に振り分けるとともに、Webサーバの稼働状態を5分間隔で監視し、正常と判断したWebサーバに要求を割り当てる。LBは設定を変更することで、特定のWebサーバへの処理割当てを一時的に取りやめることができる。同様にWebサーバに振り分けられた要求は、各Webサーバの設定に従って、APサーバ1又はAPサーバ2に割り当てられる。この設定はオンライン中でも変更できる。Webサーバ1、Webサーバ2のリソースには十分な余裕があり、1台のサーバで障害が発生した場合はほかの1台で処理できるように設計されている。また、APサーバ1、APサーバ2もWebサーバ1、Webサーバ2と同様に設計されている。予約方式1では、利用者が予約を取るまでに、予約処理のほかに空室の検索処理や料金参照処理が多数要求されるので、DBサーバの処理負荷が高い。
〔予約方式2、予約方式3の処理概要〕
旅行代理店システム、ホテル予約サイトシステムと接続し、それぞれのシステムから、確保している客室在庫に関する予約・変更・取消し情報を受信する。これらの情報は、APサーバ3だけで処理されている。APサーバ3のリソース増強が必要となった場合は、表2に示す増強方式が選択可能である。現在、C社では、内蔵ディスクや電源などのサーバを構成するハードウェアの二重化を行ってサーバの信頼性を高めていることから、増強方式1を採用している。
なお、予約方式2、予約方式3による予約処理では、予約方式1と異なり、DBサーバの処理負荷は低い。
〔宿泊予約システムの運用〕
宿泊予約システムの運用は、システム運用部が24時間体制で行っている。宿泊予約サービス提供に当たって、システム運用部では、予約方式1について、サービスの可用性及びサービスの回復時間の観点で表3に示すサービスレベルの管理項目を設定し、運用している。システム運用部では、C社宿泊予約サービスを管轄している営業部に対して、サービスレベルの達成状況を月次レポートにまとめて報告している。
C社では、宿泊予約システムの定期メンテナンスのために、毎月1日の午前2時から午前4時までの間はサービス停止時間とし、機能増強や定例の修正プログラム（以下、パッチという）の適用、DBサーバのデータのフルバックアップなどの計画的な保守作業を行う時間としている。データのフルバックアップ作業には1時間が必要である。C社では、機能増強などを行うためにDBサーバの変更が必要な場合は、変更作業中に発生する障害に備えて、データのフルバックアップを取得してから変更作業を行うルールになっている。
また、定期メンテナンスの終了後は、C社Webサイトから疑似的に空室検索や予約を行うツールを使用して、予約方式1で予約処理が正常に行われていること、及び、応答時間に問題がないことを確認している。
〔システム障害の発生と復旧〕
ある日、監視装置がWebサーバ1の障害を検知した。ほかのサーバは正常に稼働していた。システム運用部のH氏は、障害が拡大することによるサービスへの影響に配慮して、直ちに対処する必要があると判断した。LBが導入されていることから、Webサーバ2だけでサービスを継続できると判断し、予約方式1での予約処理に影響を与えないように、あらかじめ準備された図2に示す手順書に従って復旧作業を行った。
〔パッチの適用〕
ある日、サーバの基本ソフトウェアを提供しているベンダから連絡があり、Webサーバを除く全サーバに対して、定期メンテナンスを待たずに緊急でパッチを適用する必要が生じた。システム運用部では、サービスレベルを維持するために、可用性を極力落とさずにパッチの適用を行う必要があった。
H氏は、パッチの適用と宿泊予約システムの正常稼働の確認に必要な時間を検討した結果、毎月1日のサービス停止時間に行っている定例のパッチの適用は、通常30分程度で完了していることから、サーバ1台当たりのパッチ適用に必要な時間は今回も30分と想定し、緊急のパッチ適用に必要な時間を試験環境で検証した。その結果、緊急のパッチは定例のパッチよりも大幅な変更が必要になることから、サーバ1台当たりの緊急のパッチ適用に必要な時間は50分であることが分かった。また、最大5台までのサーバに並行してパッチの適用が可能であった。システム運用部は、緊急のパッチを適用する臨時の保守時間帯を、サービスの利用が少なくなる午前2時から午前3時までの1時間とした。
〔予約方式1での販売拡大〕
営業部ではC社の方針に沿って、予約方式1の取扱比率を拡大するために、来月から、予約方式1で予約した場合には特別割引を行うという内容のバナー広告を出すことになった。バナー広告によって、予約方式1による予約件数が大幅に増加することが見込まれた。営業部では、予約件数の増加に備えて、表3に示すサービスレベルの管理項目に新たな項目を追加するように、システム運用部に要請した。
システム運用部では、予約方式1による予約件数の増加に合わせて、予約方式1の利用者が快適に空室検索や予約を行えるように、システムの構成、運用方式の見直しを行った。
設問1：
問題文を見る〔予約方式2、予約方式3の処理概要〕について、APサーバ3の更なる増強が必要となった場合、表2の増強方式のうち、可用性の観点から優れている方式は増強方式1、増強方式2のいずれか。答案用紙の“増強方式1・増強方式2”のいずれかの文字を示せ。また、その理由を30字以内で述べよ。
なお、調達リードタイムや管理コスト、サーバ以外の機器の稼働率は考慮しなくてよい。
模範解答
方式：増強方式2
理由：サービス全体を停止させずにサーバの増強が可能だから
解説
解答の導き方
-
問われているのは、APサーバ3の処理能力をさらに増強するとき、どちらの方式がサービスの可用性を保ちやすいかです。調達リードタイムや管理コストなどは考慮しないため、増強作業中にサービスを継続できるかに注目します。
-
本文では、旅行代理店システムやホテル予約サイトシステムから受信した情報は「APサーバ3だけで処理されている」とあります。つまり、予約方式2、予約方式3の処理を担うサーバはAPサーバ3です。このサーバを増強作業のために利用できなくなると、処理に影響が及ぶ可能性があります。
-
増強方式1は、既存のサーバに「CPUやメモリなど」のハードウェアを追加する方式です。APサーバ3自体に手を加えるため、増強作業中にそのサーバを使えなくなると、予約方式2、予約方式3の処理を継続しにくくなります。サーバのハードウェアを二重化して信頼性を高めても、増強作業中のサービス停止を避けられるとは限りません。
-
一方、増強方式2は、専用のLBで複数台のサーバに処理を分散し、必要に応じて新しいサーバを追加する方式です。既存のサーバを稼働させながら別のサーバを追加できるため、サービス全体を停止させずに増強しやすい方式です。
-
したがって、可用性の観点では、増強方式2が優れています。
誤りやすいポイント
- 現在、増強方式1を採用している理由として、サーバのハードウェアを二重化している点だけを見て、増強方式1のほうが可用性も高いと判断しないようにします。ハードウェアの故障への備えと、増強作業中にサービスを継続できるかは別の観点です。
- サーバの信頼性ではなく、増強作業中も予約処理を続けられるかが判断基準です。
- APサーバ3は予約方式2、予約方式3の処理を担います。予約方式1の処理を担当するサーバとの役割を混同しないようにします。
- 設問では調達リードタイムや管理コストなどを考慮しないため、方式の導入や運用にかかる負担を比較の理由にしないようにします。
FAQ
Q: サーバのハードウェアを二重化していれば、増強方式1でもサービスを止めずに増強できますか。
A: ハードウェアの二重化は、部品の故障に備えて信頼性を高めるためのものです。既存のAPサーバ3にハードウェアを追加する作業中も、サービスを継続できることを示すものではありません。
A: ハードウェアの二重化は、部品の故障に備えて信頼性を高めるためのものです。既存のAPサーバ3にハードウェアを追加する作業中も、サービスを継続できることを示すものではありません。
Q: 増強方式2で可用性が高まるのは、LBがあるからですか。
A: LBに加えて、複数台のサーバに処理を分散でき、新しいサーバを別途追加できる点が理由です。既存サーバの処理を続けながら増強しやすくなります。
A: LBに加えて、複数台のサーバに処理を分散でき、新しいサーバを別途追加できる点が理由です。既存サーバの処理を続けながら増強しやすくなります。
Q: 増強方式1と増強方式2は、一般にどのような増強方法と呼ばれますか。
A: 既存サーバのCPUやメモリなどを追加する方法はスケールアップ、サーバを追加する方法はスケールアウトと呼ばれます。
A: 既存サーバのCPUやメモリなどを追加する方法はスケールアップ、サーバを追加する方法はスケールアウトと呼ばれます。
関連キーワード: 可用性、負荷分散、スケールアップ、スケールアウト、ハードウェア冗長化
設問2：
問題文を見る〔システム障害の発生と復旧〕で、Webサーバ障害時の復旧手順として、図2のaに入れる作業内容を、40字以内で述べよ。
模範解答
a：LB（負荷分散装置）の設定を変更して当該Webサーバへの処理割当てを取りやめる。
解説
解答の導き方
-
図1では、C社Webサイト利用者からの要求は、LBを経由してWebサーバに振り分けられます。したがって、障害が発生したWebサーバに要求が割り当てられ続けると、予約方式1の利用者に影響するおそれがあります。
-
本文には、LBは「設定を変更することで、特定のWebサーバへの処理割当てを一時的に取りやめることができる」とあります。また、Webサーバ1台で障害が発生しても、もう1台で処理できるように設計されています。今回はほかのサーバが正常なので、障害が発生したWebサーバへの割当てを止めれば、正常なWebサーバでサービスを継続できます。
-
図2の手順では、障害状況の確認と再起動より前に、障害のあるWebサーバへ要求が振り分けられないようにする必要があります。そのため、最初の作業はLBの設定を変更し、当該Webサーバへの処理割当てを取りやめることです。
誤りやすいポイント
- 最初に障害状況の確認や再起動を行うと、作業中も障害のあるWebサーバに要求が割り当てられる可能性があります。まず処理の割当てを止めてから、調査や再起動に進みます。
- 障害のあるWebサーバを停止することだけを答えるのは不十分です。設問が問うているのは、LBを使ってそのWebサーバへの処理割当てを止める作業です。
- LBはWebサーバの稼働状態を監視していますが、本文では監視間隔が5分間隔とされています。直ちに対処する場面なので、自動監視に任せるのではなく、設定変更で割当てを止める点が重要です。
FAQ
Q: なぜ障害状況の確認より先に、LBの設定を変更するのですか？
A: 障害のあるWebサーバに新たな要求が割り当てられるのを防ぎ、利用者への影響を抑えるためです。
A: 障害のあるWebサーバに新たな要求が割り当てられるのを防ぎ、利用者への影響を抑えるためです。
Q: 障害のあるWebサーバへの割当てを止めても、サービスを続けられるのはなぜですか？
A: 本文では、Webサーバ1台で障害が発生した場合、もう1台で処理できるように設計されていると説明されています。
A: 本文では、Webサーバ1台で障害が発生した場合、もう1台で処理できるように設計されていると説明されています。
Q: 再起動は最初の作業として適切ですか？
A: いいえ。再起動の前に割当てを止め、障害のあるWebサーバが利用者の要求を受けない状態にします。
A: いいえ。再起動の前に割当てを止め、障害のあるWebサーバが利用者の要求を受けない状態にします。
関連キーワード: 負荷分散、障害隔離、冗長化、可用性管理
設問3：〔パッチの適用〕について、(1)、(2)に答えよ。
設問3（1）
問題文を見る夜間作業での作業リスクを減らし、可用性を低下させないためにできるパッチの適用方法を、50字以内で述べよ。
模範解答
APサーバ1とAPサーバ2は昼間の時間帯にサービスを停止させずに1台ずつパッチを適用する。
解説
解答の導き方
この設問では、夜間作業のリスクを減らしながら、パッチ適用中もサービスを利用できる方法を考えます。
本文では、APサーバ1、APサーバ2について「Webサーバ1、Webサーバ2と同様に設計」とあります。Webサーバは、1台に障害が発生しても、もう1台で処理できるだけのリソースを備えています。したがって、APサーバ1とAPサーバ2も、片方をパッチ適用のために処理から外している間、もう片方でサービスを継続できると考えられます。
また、APサーバへの処理の割当て設定はオンライン中に変更できます。そのため、対象のAPサーバに処理を割り当てない状態にしてパッチを適用し、処理に戻してからもう一方に適用すれば、サービスを停止する必要がありません。
夜間作業のリスクを減らすには、この作業を夜間にまとめて行うのではなく、昼間に行います。つまり、APサーバ1とAPサーバ2に対し、昼間にサービスを継続したまま、1台ずつパッチを適用する方法になります。
誤りやすいポイント
- APサーバ1とAPサーバ2に同時にパッチを適用すると、両方が処理できなくなり、サービスを継続できないおそれがあります。
- 「可用性を低下させない」は、全サーバへのパッチ適用中に常に同じ構成で稼働させるという意味ではありません。冗長化されたAPサーバを順番に処理から外すことがポイントです。
- APサーバ1、APサーバ2と同じ方法を、ほかのサーバにも適用できるとは限りません。本文で片方の停止中も処理を継続できると判断できるのは、この2台です。
FAQ
Q: なぜ昼間に適用するのですか？
A: 夜間に行う作業を減らし、夜間作業に伴うリスクを抑えるためです。
A: 夜間に行う作業を減らし、夜間作業に伴うリスクを抑えるためです。
Q: パッチ適用中にサービスを止めなくてよいのはなぜですか？
A: 2台のうち1台ずつ処理から外せば、もう1台で処理を継続できる設計だからです。
A: 2台のうち1台ずつ処理から外せば、もう1台で処理を継続できる設計だからです。
関連キーワード: 可用性、冗長化、フェイルオーバー、段階的更新、オンライン保守
設問3（2）
問題文を見るシステム運用部が設定した臨時の保守時間帯では、実施上の問題がある。問題点を50字以内で述べよ。
模範解答
パッチ適用前にデータのバックアップを取る必要があるので、臨時の保守時間帯では作業が完了しない。
解説
解答の導き方
この設問では、臨時の保守時間帯の中でパッチ適用を完了できない理由を考えます。
まず、パッチの適用対象は「Webサーバを除く全サーバ」です。したがって、宿泊予約システムを構成するDBサーバも対象に含まれます。
次に、本文には「DBサーバの変更が必要な場合は、データのフルバックアップを取得してから変更作業を行う」とあります。今回、DBサーバにもパッチを適用するため、その前にフルバックアップが必要です。フルバックアップには1時間かかります。
一方、臨時の保守時間帯は午前2時から午前3時までの1時間です。つまり、保守時間帯の全てをバックアップに使ってしまい、DBサーバのパッチ適用を始められません。さらに、パッチ適用にはサーバ1台当たり50分かかります。最大5台まで並行して適用できても、バックアップが終わる前にDBサーバのパッチ適用を始めることはできないため、この時間帯では作業を完了できません。
誤りやすいポイント
- パッチ適用が1台当たり50分なので、1時間の保守時間帯に収まると考えてしまうことです。DBサーバのパッチ適用前に必要なバックアップ時間も考慮します。
- 最大5台まで並行してパッチを適用できることを、バックアップも含めて全作業を短縮できる条件だと捉えることです。DBサーバのパッチ適用には、バックアップ完了後という順序があります。
- 「Webサーバを除く全サーバ」にDBサーバが含まれることを見落とすことです。
FAQ
Q: 最大5台まで並行してパッチを適用できるなら、作業時間を短縮できませんか？
A: 他のサーバへのパッチ適用は並行できますが、DBサーバのパッチ適用はバックアップの完了後でなければ始められません。その順序のため、1時間の保守時間帯では完了できません。
A: 他のサーバへのパッチ適用は並行できますが、DBサーバのパッチ適用はバックアップの完了後でなければ始められません。その順序のため、1時間の保守時間帯では完了できません。
Q: なぜパッチ適用前にフルバックアップが必要なのですか？
A: 本文では、DBサーバの変更作業中に障害が発生した場合に備え、変更前にフルバックアップを取得するルールになっています。
A: 本文では、DBサーバの変更作業中に障害が発生した場合に備え、変更前にフルバックアップを取得するルールになっています。
関連キーワード: フルバックアップ、パッチ適用、保守時間帯、並行処理
設問4：〔予約方式1での販売拡大〕について、(1)、(2)に答えよ。
設問4（1）
問題文を見る予約件数の増加に伴い、DBサーバの処理性能の確認が必要となる。その理由を、40字以内で述べよ。
模範解答
空室の検索処理や料金参照処理の増加による負荷増加が見込まれるから
解説
解答の導き方
-
予約方式1では、利用者の要求がAPサーバで処理され、空室の検索や予約の際にDBサーバの客室在庫データを参照・更新します。そのため、予約方式1の利用増加は、DBサーバの処理に関係します。
-
予約方式1については、予約処理だけでなく「空室の検索処理や料金参照処理が多数要求される」ため、DBサーバの処理負荷が高いと説明されています。つまり、予約件数が増えると、予約の登録だけでなく、予約に先立つ検索や料金確認の要求も増えると考えられます。
-
予約方式2、予約方式3ではDBサーバの処理負荷が低い一方、今回拡大する予約方式1では検索や料金参照による負荷がもともと大きいとされています。したがって、予約件数の増加に伴ってDBサーバへの負荷がさらに高まる可能性があり、処理性能を確認する必要があります。
誤りやすいポイント
- 予約件数の増加を、予約データの登録処理だけの増加と捉えないようにします。空室検索や料金参照もDBサーバへの要求です。
- 予約方式2、予約方式3ではDBサーバの負荷が低いという記述を、予約方式1にも当てはめないようにします。
- 予約件数が増えてもWebサーバやAPサーバだけを確認すればよい、と考えないようにします。本文では、予約方式1の検索や料金参照によってDBサーバの負荷が高いことが示されています。
FAQ
Q: DBサーバは予約の確定時だけ使われるのですか？
A: いいえ。本文では、空室検索や料金参照でも客室在庫データを参照するとされています。予約確定前の利用者の操作も、DBサーバの負荷に関わります。
A: いいえ。本文では、空室検索や料金参照でも客室在庫データを参照するとされています。予約確定前の利用者の操作も、DBサーバの負荷に関わります。
Q: なぜ予約方式2、予約方式3との違いが重要なのですか？
A: 本文では、予約方式2、予約方式3の予約処理はDBサーバの処理負荷が低いとされています。負荷増加を考える際は、予約方式1の処理特性に基づいて判断する必要があります。
A: 本文では、予約方式2、予約方式3の予約処理はDBサーバの処理負荷が低いとされています。負荷増加を考える際は、予約方式1の処理特性に基づいて判断する必要があります。
関連キーワード: データベース負荷、処理性能、空室検索、料金参照、予約処理
設問4（2）
問題文を見る営業部からの要請に伴い、システム運用部が月次レポートに追加すべき項目を20字以内で述べよ。
模範解答
サービス利用者から見た応答時間
解説
解答の導き方
-
表3にある現在の管理項目を確認します。予約方式1では、「月間平均稼働率」と「障害を検知してから障害が回復するまでの時間」を管理しています。これらは、サービスがどの程度利用可能だったか、障害からどれだけ早く復旧したかを示す項目です。
-
しかし、サービスが稼働していて障害からも復旧していても、空室検索や予約画面の応答が遅ければ、利用者は快適にサービスを利用できません。稼働率や回復時間だけでは、利用中の応答の速さを把握できないのです。
-
本文では、バナー広告によって予約方式1の予約件数が大幅に増えると見込まれ、利用者が快適に空室検索や予約を行えるように見直すとしています。また、予約方式1では空室検索や料金参照の要求が多く、DBサーバの処理負荷が高いと説明されています。利用者の増加によって応答が遅くなる可能性があるため、利用者が実際に感じる応答の速さを月次レポートで把握する必要があります。
-
したがって、追加すべき項目は、システム内部の稼働状況だけでなく、利用者の視点でサービスの応答時間を評価するものです。
誤りやすいポイント
- 稼働率を追加項目にする誤りです。稼働率はサービスが利用可能だった割合を示しますが、利用中の応答の速さまでは示しません。
- 障害の検知から復旧までの時間を追加する誤りです。これは障害時の回復状況を測る項目であり、通常利用時の快適さを測るものではありません。
- DBサーバの処理負荷など、システム内部の指標をそのまま答える誤りです。設問で求められているのは、利用者がサービスを利用したときの応答に関する項目です。
- 予約件数そのものを追加する誤りです。件数は需要の変化を示しますが、利用者が快適に操作できているかは直接示しません。
FAQ
Q: 稼働率が目標を満たしていれば、応答時間の管理は不要ですか？
A: 不要ではありません。サービスが稼働していても、応答が遅ければ利用者にとって快適なサービスとはいえません。
A: 不要ではありません。サービスが稼働していても、応答が遅ければ利用者にとって快適なサービスとはいえません。
Q: サーバの処理時間ではなく、利用者から見た応答時間を管理するのはなぜですか？
A: 利用者が体験する応答には、サーバ処理だけでなく、通信や画面表示なども影響するためです。利用者視点の指標でサービス品質を確認できます。
A: 利用者が体験する応答には、サーバ処理だけでなく、通信や画面表示なども影響するためです。利用者視点の指標でサービス品質を確認できます。
Q: 月次レポートに応答時間を加える目的は何ですか？
A: 予約件数の増加に伴って応答が遅くなっていないかを、営業部にも分かる形で継続的に確認するためです。
A: 予約件数の増加に伴って応答が遅くなっていないかを、営業部にも分かる形で継続的に確認するためです。
関連キーワード: サービスレベル管理、可用性、応答時間、利用者満足度
