応用情報技術者過去問題 令和5年春期 午後問10
⇄問題文と設問を画面2分割で開く⇱問題PDF問10 サービスマネジメント
クラウドサービスのサービス可用性管理に関する次の記述を読んで,設問に答えよ。
L社は,大手の自動車部品製造販売会社である。2023年4月現在,全国に八つの製造拠点をもち,L社の製造部は,昼勤と夜勤の2交替制で部品を製造している。L社の経理部は,基本的に昼勤で経理業務を行っている。L社のシステム部では,基幹系業務システムを,L社本社の設備を使って,オンプレミスで運用している。また,会計系業務システムは,2023年1月に,オンプレミスでの運用からクラウド事業者M社の提供するSaaS(以下,Sサービスという)に移行した。L社の現在の業務システムの概要を表1に示す。〔L社のITサービスの現状〕
システム部は,L社内の利用者を対象に,業務システムをITサービスとして提供し,サービス可用性やサービス継続性を管理している。
システム部では,ITILを参考にして,サービス可用性として異なる3種の特性及び指標を表2のとおり定めている。 基幹系業務のITサービスは,生産管理など事業が成功を収めるために不可欠な重要事業機能を支援しており,高可用性の確保が必要である。基幹系業務システムでは,L社本社建屋内にシステムを2系統用意してあり,本番系システムのサーバの故障や定期保守などの場合は,予備系のサーバに切り替えてITサービスの提供を継続できるシステム構成を採っている。また,ストレージに保存されているユーザーデータファイルがマルウェアによって破壊されるリスクに備え,定期的にユーザーデータファイルのフルバックアップを磁気テープに取得している。バックアップを取得する磁気テープは2組で,1組は本社建屋内に保存し,もう1組は災害に対する脆弱性を考える必要があるので,遠隔地に保管している。
〔Sサービスのサービス可用性〕
システム部のX氏は,会計系業務システムにSサービスを利用する検討を行った際,M社のサービスカタログを基にサービス可用性に関する調査を行い,その後,L社とM社との間でSLAに合意し,2023年1月からSサービスの利用を開始した。M社が案内しているSサービスのサービスカタログ(抜粋)を表3に,L社とM社との間で合意したSLAのサービスレベル目標を表4に示す。 2023年1月は,Sサービスでインシデントが発生してサービス停止した日が3日あったが,サービス停止の時間帯は3日とも表4のサービス時間の外だった。よって,表4のサービス稼働率は100%である。仮に,サービス停止の時間帯が3日とも表4のサービス時間の内の場合,サービス停止の月間合計時間がb分以下であれば,表4のサービス稼働率のサービスレベル目標を達成する。ここで,1月のL社の営業日の日数を30とする。
3月は,表4のサービス時間の内にSサービスでインシデントが発生した日が1日あった。復旧作業に時間が掛かったので,表4のサービス時間の内で90分間サービス停止した。3月のL社の営業日の日数を30とすると,サービス稼働率は99.75%となり,3月も表4のサービスレベル目標を達成した。しかし,このインシデントは月末繁忙期の日中に発生したので,L社の取引先への支払業務に支障を来した。
X氏は,サービス停止しないことはもちろんだが,サービス停止した場合に迅速に対応して回復させることも重要だと考えた。そこで,X氏はM社の責に帰するインシデントが発生してサービス停止したときの①サービスレベル項目を表4に追加できないか,M社と調整することにした。
また,今後,経理部では,勤務時間を製造部に合わせて,交替制で夜勤を行う勤務体制を採って経理業務を行うことで,業務のスピードアップを図ることを計画している。この場合,会計系業務システムのサービス時間を見直す必要がある。そこで,X氏は,表4のサービスレベル目標の見直しが必要と考え,表3のサービスカタログを念頭に,②経理部との調整を開始することにした。
〔基幹系業務システムのクラウドサービス移行〕
2023年1月に,L社はBCPの検討を開始し,システム部は地震が発生して基幹系業務システムが被災した場合でもサービスを継続できるようにする対策が必要になった。X氏が担当になって,クラウドサービスを利用してBCPを実現する検討を開始した。
X氏は,まずM社が提供するパブリッククラウドのIaaS(以下,Iサービスという)を調査した。Iサービスのサービスカタログでは,サービスレベル項目としてサービス時間及びサービス稼働率の二つが挙げられていて,サービスレベル目標は,それぞれ24時間365日及び月間目標値99.99%以上になっていた。Iサービスでは,物理サーバ,ストレージシステム,ネットワーク機器などのIT基盤のコンポーネント(以下,物理基盤という)は,それぞれが冗長化されて可用性の対策が採られている。また,ハイパーバイザー型の仮想化ソフト(以下,仮想化基盤という)を使って,1台の物理サーバで複数の仮想マシン環境を実現している。
次に,X氏は,Iサービスを利用した災害対策サービスについて,M社に確認した。災害対策サービスの概要は次のとおりである。
M社の説明を受け,X氏は次のように考えた。
さらに,上司はX氏に,M社に一任せずに,M社と協議して実質的な改善を継続していくことが重要だと話した。そこで,X氏は,サービス可用性管理として,サービスカタログに記載されているサービスレベル項目のほかに,④可用性に関するKPIを設定することにした。また,基幹系業務システムの災害対策を実現するに当たって,コストの予算化が必要になる。X氏は,災害時のサービス可用性確保の観点でサービス継続性を確保するコストは必要だが,コストの上昇を抑えるために災害時に基幹系業務システムを一部縮退できないか検討した。そして,事業の視点から捉えた機能ごとの⑤判断基準に基づいて継続する機能を決める必要があると考えた。
L社は,大手の自動車部品製造販売会社である。2023年4月現在,全国に八つの製造拠点をもち,L社の製造部は,昼勤と夜勤の2交替制で部品を製造している。L社の経理部は,基本的に昼勤で経理業務を行っている。L社のシステム部では,基幹系業務システムを,L社本社の設備を使って,オンプレミスで運用している。また,会計系業務システムは,2023年1月に,オンプレミスでの運用からクラウド事業者M社の提供するSaaS(以下,Sサービスという)に移行した。L社の現在の業務システムの概要を表1に示す。〔L社のITサービスの現状〕
システム部は,L社内の利用者を対象に,業務システムをITサービスとして提供し,サービス可用性やサービス継続性を管理している。
システム部では,ITILを参考にして,サービス可用性として異なる3種の特性及び指標を表2のとおり定めている。 基幹系業務のITサービスは,生産管理など事業が成功を収めるために不可欠な重要事業機能を支援しており,高可用性の確保が必要である。基幹系業務システムでは,L社本社建屋内にシステムを2系統用意してあり,本番系システムのサーバの故障や定期保守などの場合は,予備系のサーバに切り替えてITサービスの提供を継続できるシステム構成を採っている。また,ストレージに保存されているユーザーデータファイルがマルウェアによって破壊されるリスクに備え,定期的にユーザーデータファイルのフルバックアップを磁気テープに取得している。バックアップを取得する磁気テープは2組で,1組は本社建屋内に保存し,もう1組は災害に対する脆弱性を考える必要があるので,遠隔地に保管している。
〔Sサービスのサービス可用性〕
システム部のX氏は,会計系業務システムにSサービスを利用する検討を行った際,M社のサービスカタログを基にサービス可用性に関する調査を行い,その後,L社とM社との間でSLAに合意し,2023年1月からSサービスの利用を開始した。M社が案内しているSサービスのサービスカタログ(抜粋)を表3に,L社とM社との間で合意したSLAのサービスレベル目標を表4に示す。 2023年1月は,Sサービスでインシデントが発生してサービス停止した日が3日あったが,サービス停止の時間帯は3日とも表4のサービス時間の外だった。よって,表4のサービス稼働率は100%である。仮に,サービス停止の時間帯が3日とも表4のサービス時間の内の場合,サービス停止の月間合計時間がb分以下であれば,表4のサービス稼働率のサービスレベル目標を達成する。ここで,1月のL社の営業日の日数を30とする。
3月は,表4のサービス時間の内にSサービスでインシデントが発生した日が1日あった。復旧作業に時間が掛かったので,表4のサービス時間の内で90分間サービス停止した。3月のL社の営業日の日数を30とすると,サービス稼働率は99.75%となり,3月も表4のサービスレベル目標を達成した。しかし,このインシデントは月末繁忙期の日中に発生したので,L社の取引先への支払業務に支障を来した。
X氏は,サービス停止しないことはもちろんだが,サービス停止した場合に迅速に対応して回復させることも重要だと考えた。そこで,X氏はM社の責に帰するインシデントが発生してサービス停止したときの①サービスレベル項目を表4に追加できないか,M社と調整することにした。
また,今後,経理部では,勤務時間を製造部に合わせて,交替制で夜勤を行う勤務体制を採って経理業務を行うことで,業務のスピードアップを図ることを計画している。この場合,会計系業務システムのサービス時間を見直す必要がある。そこで,X氏は,表4のサービスレベル目標の見直しが必要と考え,表3のサービスカタログを念頭に,②経理部との調整を開始することにした。
〔基幹系業務システムのクラウドサービス移行〕
2023年1月に,L社はBCPの検討を開始し,システム部は地震が発生して基幹系業務システムが被災した場合でもサービスを継続できるようにする対策が必要になった。X氏が担当になって,クラウドサービスを利用してBCPを実現する検討を開始した。
X氏は,まずM社が提供するパブリッククラウドのIaaS(以下,Iサービスという)を調査した。Iサービスのサービスカタログでは,サービスレベル項目としてサービス時間及びサービス稼働率の二つが挙げられていて,サービスレベル目標は,それぞれ24時間365日及び月間目標値99.99%以上になっていた。Iサービスでは,物理サーバ,ストレージシステム,ネットワーク機器などのIT基盤のコンポーネント(以下,物理基盤という)は,それぞれが冗長化されて可用性の対策が採られている。また,ハイパーバイザー型の仮想化ソフト(以下,仮想化基盤という)を使って,1台の物理サーバで複数の仮想マシン環境を実現している。
次に,X氏は,Iサービスを利用した災害対策サービスについて,M社に確認した。災害対策サービスの概要は次のとおりである。
- M社のデータセンター(DC)は,同時に被災しないように東日本と西日本に一つずつある。通常時は,L社向けのIサービスは東日本のDCでサービスを運営する。東日本が被災して東日本のDCが使用できなくなった場合は,西日本のDCでIサービスが継続される。
- 西日本のDCのIサービスにもユーザーデータファイルを保存し,東日本のDCのIサービスのユーザーデータファイルと常時同期させる。東日本のDCの仮想マシン環境のシステムイメージは,システム変更の都度,西日本のDCにバックアップを保管しておく。
M社の説明を受け,X氏は次のように考えた。
- 地震や台風といった広範囲に影響を及ぼす自然災害に対して有効である。
- 災害対策だけでなく,物理サーバに機器障害が発生した場合でも業務を継続できる。
- 西日本のDCのIサービスのユーザーデータファイルは,東日本のDCのIサービスのユーザーデータファイルと常時同期しているので,現在行っているユーザーデータファイルのバックアップの遠隔地保管を廃止できる。
さらに,上司はX氏に,M社に一任せずに,M社と協議して実質的な改善を継続していくことが重要だと話した。そこで,X氏は,サービス可用性管理として,サービスカタログに記載されているサービスレベル項目のほかに,④可用性に関するKPIを設定することにした。また,基幹系業務システムの災害対策を実現するに当たって,コストの予算化が必要になる。X氏は,災害時のサービス可用性確保の観点でサービス継続性を確保するコストは必要だが,コストの上昇を抑えるために災害時に基幹系業務システムを一部縮退できないか検討した。そして,事業の視点から捉えた機能ごとの⑤判断基準に基づいて継続する機能を決める必要があると考えた。
設問1
〔L社のITサービスの現状〕について答えよ。
- 表2中のMTBF及びMTRSについて,適切なものを解答群の中から選び,記号で答えよ。
- 表2中のaに入れる適切な字句を,5字以内で答えよ。
解答群
- MTBFの値は大きい方が,MTRSの値は小さい方が望ましい。
- MTBFの値は大きい方が,MTRSの値も大きい方が望ましい。
- MTBFの値は小さい方が,MTRSの値は大きい方が望ましい。
- MTBFの値は小さい方が,MTRSの値も小さい方が望ましい。
解答入力欄
- a:
解答例・解答の要点
- ア
- a:信頼 (2文字)
解説
- MTBF(Mean Time Between Failure)は、システムの修復が完了し正常に稼働し始めてから、次回故障するまでの平均の時間、すなわち平均故障間隔を指します。より長い期間にわたり故障せずに連続で稼働できるシステムの方が優れているため、故障から故障までの期間は長いほど良いことになります。よって、MTBFは大きいほど望ましいと言えます。
なお、サービスマネジメントにおいては、システムダウンに至らないサービス品質の低下もインシデントと捉えるので、MTBFの代わりに平均サービス・インシデント間隔(MTBSI)という指標が使用されることもあります。
MTRS(Mean Time to Restore Service)は、サービスが停止したときに、サービスを復旧させるために要する平均の時間、すなわち平均サービス回復時間を指します。当然ながら、サービス停止している時間は短いほど良いので、MTRSは小さいほど望ましいと言えます。
したがって「ア」の記述が適切です。
∴ア:MTBFの値は大きい方が,MTRSの値は小さい方が望ましい。 - 〔aについて〕
空欄には、MTBFが評価指標となっている特性の名称が入ります。"a性"という語尾、表2の「ITサービスを中断なしに,合意された機能を実行できる能力」という説明、およびMTBFを指標としていることを総合すると、システムやサービスマネジメントについての一般的な知識より、信頼性が当てはまることがわかります。信頼性は、ITサービスまたは他の構成アイテムが中断なく、合意された機能をどれだけ長く実行できるかを示す指標であり、MTBFまたはMTBSIとして測定・評価されます。したがって空欄aには「信頼」が当てはまります。
∴a=信頼
設問2
〔Sサービスのサービス可用性〕について答えよ。
解答入力欄
- b:
解答例・解答の要点
- b:180
- サービス回復までの最大時間 (13文字)
- 計画停止時間を考慮して経理部の勤務時間を定めること (25文字)
解説
- 〔bについて〕
空欄を含む一文は「サービス停止の月間合計時間がb分以下であれば,表4のサービス稼働率のサービスレベル目標を達成する」となっているので、サービスレベル目標を達成するために許容される1月の最大サービス停止時間を計算することになります。分単位で答えることに注意が必要です。
ここで計算の前提となる各条件は次のとおりです。- 目標とするサービス稼働率は99.5%
- サービス稼働率の算出式は、サービス時間-サービス停止時間サービス時間×100
- サービス時間は、午前6時~翌日午前2時の1日20時間
- 1月のL社の営業日の日数は30日
600時間×0.5%=3時間=180分
したがって空欄bには「180」が当てはまります。
∴b=180
愚直に各値をサービス稼働率の算出式に当てはめて、
99.5 ≦ 600時間-サービス停止時間600時間×100
99.5×600÷100 ≦ 600-サービス停止時間
99.5×6 ≦ 600-サービス停止時間
597 ≦ 600-サービス停止時間
サービス停止時間 ≦ 3時間 = 180分
と計算することもできます。
【別解】
問題文中の「90分間サービス停止した。3月のL社の営業日の日数を30とすると,サービス稼働率は99.75%」に着目すると、同じ営業日数のときに90分間の停止で0.25%だけ稼働率が低下したことから、その2倍まで許容できることになるので「90分×2=180分」と導くことができます。 - 下線①を含む文は「X氏は,サービス停止しないことはもちろんだが,サービス停止した場合に迅速に対応して回復させることも重要だと考えた。そこで,X氏はM社の責に帰するインシデントが発生してサービス停止したときのサービスレベル項目を表4に追加できないか,M社と調整することにした」となっています。文脈より、追加されるサービスレベル項目はサービスが停止したときに、ダウン状態から迅速に回復させることを目的としていることがわかります。
表4を確認するとサービス稼働率についてはM社と合意している一方で、サービス停止した場合の回復時間についてはM社と合意していません。X氏はこの状況を鑑みて、サービス停止した場合にサービスを回復させる時間についても、SLAに含めるべきであると考えたと判断できます。したがって「サービス停止からサービス回復までの時間」「サービス停止からの復旧時間」などの解答が適切となります。
∴サービス回復までの最大時間 - 下線②を含む文は「今後,経理部では,勤務時間を製造部に合わせて,交替制で夜勤を行う勤務体制を採って経理業務を行う…。この場合,会計系業務システムのサービス時間を見直す必要がある。そこで,X氏は,…,経理部との調整を開始することにした」となっています。文脈より、調整事項とは経理部の勤務体制の変更と会計業務システムのサービス時間に関連する内容であるとわかります。
Sサービスのサービス時間について表3を確認すると、計画停止時間として毎月1回、午前2時から午前5時の間、サービス停止する旨が記載されています。計画停止でSサービスが停止すると、会計系業務システムも当然に使用できなくなり、夜勤中の経理部の業務に支障を来します。経理部が夜勤を行うことになった場合には、計画停止時間を避けて業務を行う必要があるため、その調整が経理部との間で必要となります。
∴計画停止時間を考慮して経理部の勤務時間を定めること
設問3
〔基幹系業務システムのクラウドサービス移行〕について答えよ。
解答群
- アプリケーションソフトウェア
- 仮想化基盤
- ゲストOS
- 物理基盤
- ミドルウェア
解答群
- M社が提供するサービスのサービス故障数
- M社起因のインシデントの問題を解決する変更の件数
- M社のDCで実施した災害を想定した復旧テストの回数
- M社のサービスデスクが回答した問合せ件数
- SLAのサービスレベル目標が達成できなかった原因のうち,ストレージ容量不足に起因する件数
解答入力欄
解答例・解答の要点
- イ,エ
- バックアップの遠隔地保管を廃止すること (19文字)
- ア
- 重要事業機能の支援度合い (12文字)
解説
- パブリッククラウドのIaaSである、Iサービスを提供するM社の管理範囲が問われています。IaaS(Infrastructure as a Service)は、CPU、メモリ、ストレージ、ネットワーク、電源などの基礎的なハードウェアリソースをサービスの形で提供するものです。サービス利用者は、提供されたインフラ機能の上に、OS、ミドルウェア、開発環境、システムやアプリケーションを含む任意のソフトウェアを用意し、実装し、稼働させることができます。
クラウドサービスでは、サービスとして提供される部分はサービス提供者側の管理に属し、利用者が独自に実装した部分はサービス利用者側の管理に属します。本文中の記述を読むと、Iサービスでは物理サーバ等の物理基盤が提供され、仮想化基盤を使って仮想マシン環境を実現しているとありますから、サービス提供者であるM社が構築して管理する対象は「イ:仮想化基盤」と「エ:物理基盤」であるとわかります。それ以外は、Iサービスの上にL社が構築する部分ですので、L社の管理する範囲となります。
∴イ,エ - 本文中にはX氏の考えた内容として3つが記載されています。1つ目の自然災害に対して有効という点は、東日本と西日本にDCがあることから適切、2つ目の物理サーバの機器障害でも業務を継続できるという点も、物理基盤が冗長化されていることから適切と言えます。したがって、指摘の対象となったのは、3つ目の現在実施しているバックアップの遠隔地への保管(以下、遠隔地保管)を廃止できるという考えであると見込みがつきます。
L社の現在のバックアップ状況は、定期的にユーザーデータファイルのフルバックアップを2組の磁気テープに取得し、1組を本社に、もう1組を遠隔地保管するというものです。遠隔地保管をやめるということは、L社側のバックアップは本社に保管されるものだけになるということです。
一方、Iサービスから提供される災害対策サービスについては、次のように説明されています。- 西日本のDCのIサービスにもユーザーデータファイルを保存し,東日本のDCのIサービスのユーザーデータファイルと常時同期させる
- 東日本のDCの仮想マシン環境のシステムイメージは,システム変更の都度,西日本のDCにバックアップを保管しておく
クラウドサービス利用の一般的なリスクマネジメントとして、サービス提供者がバックアップ機能を提供しない場合は、利用者側がバックアップ機能の導入に責任を負うことになります。特にハードウェアリソースの提供を主とするIaaSでは、バックアップ取得の責任は一般的には利用者側にあります。また、急なサービス停止や両DCのデータが同時に破損してしまう可能性もゼロではないので、備えとしてクラウドサービス上のデータのバックアップを取得しておくことは重要です。
Iサービス側で定期バックアップがされていない以上、クラウドに構築した基幹系業務システムのユーザーデータファイルをバックアップする責任はL社にあります。したがって、従前のとおり本社保管だけではなく、災害対策としての遠隔地保管を実施する必要があります。したがって、遠隔地保管を廃止というX氏の考えは見直すべきであると言えます。
∴バックアップの遠隔地保管を廃止すること - 可用性は、利用者が必要なときに必要なだけ利用できる度合いです。またKPI(Key Performance Indicator)は、目標達成のために行う活動の実施状況をモニタリングするための指標です。可用性の良しあしを左右するという視点から考えると、可用性に関してモニタリングすべきとして、サービスカタログで提示されている稼働率のほか、故障回数、MTBF、MTBSI、MTRSなどが考えられます。
したがって、可用性に関連するKPIとして適切なのは「ア:サービス故障数」となります。これは午前問題でも頻出の論点です(H29春55ほか)。- 正しい。可用性管理のKPIです。
- インシデント管理のKPIです。
- ITサービス継続性管理のKPIです。
- サービスデスクのKPIです。
- キャパシティ管理のKPIです。
- 下線⑤の判断基準とは、基幹系業務システムのうち、災害時に継続する機能と縮退する機能とを事業の視点から選択するための基準です。非常災害時には、平常時に実施している全ての事業・業務を継続することは困難となり、重要な事業に必要不可欠な業務から優先順位を付けて継続または早期復旧することが求められます。BCPの策定においては、事業影響度分析を行った結果を踏まえて、優先的に継続・復旧すべき重要業務を特定し、目標復旧時間や目標復旧レベルを決定します。かたや重要業務ではないと判断された業務は、重要業務の復旧にめどがついた段階で復旧時期を検討することになります。
基幹系業務システムの事業視点からの役割について確認すると、〔L社のITサービスの現状〕に「基幹系業務のITサービスは,生産管理など事業が成功を収めるために不可欠な重要事業機能を支援しており,高可用性の確保が必要である」と記述されています。重要事業機能の支援する機能については継続する必要があるので縮退の対象からは外し、その他の部分の縮退を考えることになります。つまり、縮退対象となるかどうかは、機能ごとに重要事業機能を支援する度合いによって決定されることになります。
∴重要事業機能の支援度合い