AP過去問 令和7年度春期 午後 問4 システムアーキテクチャ

AP 過去問題 午後に戻る。

AP過去問_令和7年度春期_午後_問3_プログラミングの同じ回の前の問題へ移動。

AP過去問_令和7年度春期_午後_問5_ネットワークの同じ回の次の問題へ移動。

AP過去問_令和6年度秋期_午後_問4_システムアーキテクチャの前の回の同じカテゴリの問題へ移動。

令和7年度春期 午後 問4 システムアーキテクチャ(AIプロンプト向け)

■ビルエネルギーマネジメントシステムの非機能要件に関する次の記述を読んで、設問に答えよ。

　E社は、オフィスビルのエネルギー使用量を一元管理するビルエネルギーマネジメントシステム(以下、BEMSという)を開発・運用している企業である。首都圏を中心に複数のオフィスビルを所有しているR社に対して、オンプレミス方式のBEMS(以下、オンプレ BEMSという)を運用してきた。最近、R社から❝複数のオフィスビルのオンプレBEMSを統合管理したい❞という要望があり、E社はクラウド方式のBEMS(以下、クラウドBEMSという)を提案することになった。

　オンプレBEMSは、BEMS サーバ、BEMSクライアント及びBEMSゲートウェイで構成され、E社はこれらの設置・運用を行っている。ビル管理員はBEMSクライアント上のWebブラウザを用いてBEMSサーバにアクセスし、BEMSゲートウェイを介して照明機器や空調機器などの制御対象機器の制御や監視を行う。オンプレBEMSは複数のR社オフィスビルに導入されている。

　オンプレBEMSを用いた既存システム(以下、既存システムという)の構成の一部を図1に示す。なお、図1の各R社オフィスビルでは、制御対象機器を接続するビル制御LANと、BEMSサーバやBEMSクライアントを接続するビル管理LANとが既設されており、二つのLANをBEMSゲートウェイで接続している。

　図1 既存システムの構成(一部) ここから

R社オフィスビル001、002、～XXXまでが存在する。

例えば、R社オフィスビル001のシステム構成を示す。

ビル管理LAN内のBEMSサーバはビル管理LAN内のL2SWと繋がっている。

ビル管理LAN内のBEMSクライアントはビル管理LAN内のL2SWと繋がっている。

ビル管理LAN内のL2SWはビル管理LANにもビル制御LANにも属さないBEMSゲートウェイと繋がっている。

ビル制御LAN内の制御対象機器はビル制御LAN内のL2SWに繋がっている。

ビル制御LAN内の制御対象機器は複数存在する。

ビル制御LAN内のL2SWはビル管理LANにもビル制御LANにも属さないBEMSゲートウェイと繋がっている。

ビル管理LANにもビル制御LANにも属さないBEMSゲートウェイはR社オフィスビル001内にある。

L2SWはレイヤー2スイッチのことである。

注記1 オンプレBEMSに関係する構成要素だけを記載している。

注記2 BEMSゲートウェイはBEMSサーバや制御対象機器が使用する通信プロトコルを変換する機能を有する。

　図1 既存システムの構成(一部) ここから

　E社は、R社のオフィスビルに設置している既存システムから、複数のオフィスビルを統合管理できるクラウドBEMSを用いた新システム(以下、新システムという)へ移行する方法を検討した。新システムでは、ビル管理員はR 社運用拠点のBEMSクライアントから、E社が別途サービスを提供しているIaaS型クラウドサービス(以下、E 社クラウド基盤サービスという)の仮想サーバ上に構築したBEMSサーバを操作し、ファイアウォール(以下、FWという)とBEMS ゲートウェイを介して制御対象機器の制御や監視を行う。E 社はBEMSサーバ、BEMSクライアント及びBEMSゲートウェイを設置・運用する。FW及びインターネット接続環境はR社が設置・運用する。新システムの構成案の一部を図2に示す。

　図2 新システムの構成案(一部) ここから

R社オフィスビル001、002、～XXXまでが存在する。

例えば、R社オフィスビル001のシステム構成を示す。

ビル管理LAN内のFWはビル管理LAN内のL2SWと繋がっている。

ビル管理LAN内のFWはインターネットと繋がっている。

ビル管理LAN内のL2SWはビル管理LANにもビル制御LANにも属さないBEMSゲートウェイと繋がっている。

ビル制御LAN内の制御対象機器はビル制御LAN内のL2SWに繋がっている。

ビル制御LAN内の制御対象機器は複数存在する。

ビル制御LAN内のL2SWはビル管理LANにもビル制御LANにも属さないBEMSゲートウェイと繋がっている。

ビル管理LANにもビル制御LANにも属さないBEMSゲートウェイはR社オフィスビル001内にある。

R社オフィスビル001内のシステム構成はここまで

E社クラウド基盤サービス内のBEMSサーバはインターネットに繋がっている。

R社運用拠点内のBEMSクライアントはインターネットに繋がっている。

L2SWはレイヤー2スイッチのことである。

注記1 オンプレBEMSに関係する構成要素だけを記載している。

注記2 ビル管理LANのL2SW、ビル制御LANのL2SW及び制御対象機器は既設のものである。

　図2 新システムの構成案(一部) ここから

〔品質要件の検討〕

　E社は、図2の構成案をR社に提案した。BEMSを新たなビルに導入する場合、既存システムでは、オフィスビルとにBEMSサーバ、BEMSクライアント及びBEMSゲートウェイを導入する必要があった。ー方、新システムでは、FW及びインターネット接続環境をR社が設置・運用することによって、E社がR社オフィスビルに[ ａ ]を設置することによってBEMSを導入できる。R社が要望した統合管理が実現でき、さらにBEMS導入が比較的容易になるとから、R社は新システムへの移行検討の具体化をE社に依頼した。

　E社の提案に対して、R社からの要望が出た。

・既存システムでは、BEMSサーバをメンテナンスする際に実施する計画停止の頻度が高く不便だったので、新システムでは計画停止の頻度を低くしてほしい。

・既存システムでは、BEMSサーバのハードウェア障害の発生頻度は低いものの、障害発生時のシステム停止時間が長く不便だったので，新システムではできるだけ短くしてほしい。

　E社では、R社からの要望を受けて、既存システム及び新システムの非機能要件を改めて確認し、新システムの構成案を一部見直すとともに、その優位な点を指標を用いて示すことにした。既存システム及び新システムの非機能要件の指標とその指標値のー部を表1に示す。

<div><div class="table-container"><div class="table-header"><span class="table-title">表1 既存システム及び新システムの非機能要件の指標とその指標値(一部)</span><span class="table-unit"></span></div>

<table border="0" style="border-collapse: collapse;border-style: solid">

<tr>

  <td align="center" rowspan="2" style="border: 2px solid; width: 5em;">項番</td>

  <td align="center" rowspan="2" style="border: 2px solid; width: 5em;">非機能要件の分類</td>

  <td align="center" rowspan="2" style="border: 2px solid; width: 5em;">非機能要件の指標</td>

  <td align="center" colspan="2" style="border: 2px solid;">指標値</td>

</tr>

<tr>

  <td align="center" style="border: 2px solid; width: 5em;">既存システム</td>

  <td align="center" style="border: 2px solid; width: 5em;">新システム</td>

</tr>

<tr>

  <td align="center" style="border: 2px solid;">1</td>

  <td align="center" style="border: 2px solid;">[ ｂ ]、[ ｃ ]</td>

  <td align="center" style="border: 2px solid;">BEMSサーバのメンテナンスに伴う計画停止の頻度</td>

  <td align="center" style="border: 2px solid;">年4回</td>

  <td align="center" style="border: 2px solid;">計画停止なし</td>

</tr>

<tr>

  <td align="center" style="border: 2px solid;">2</td>

  <td align="center" style="border: 2px solid;">[ ｃ ]</td>

  <td align="center" style="border: 2px solid;">BEMSサーバのハードウェア障害発生時の平均サービス回復時間</td>

  <td align="center" style="border: 2px solid;">48時間</td>

  <td align="center" style="border: 2px solid;">15分</td>

</tr>

</table>

</div>

</div>

　表1の項番1について、既存システムではBEMSサーバのメンテナンスのたびに計画停止が必要であった。新システムでは、E社クラウド基盤サービス上でBEMSサーバを仮想サーバとして構築できることを生かして、2台のBEMSサーバを[ ｄ ]構成にすれば、計画停止をなくすことができる。そこで、図2の構成案に対して、E社クラウド基盤サービス上で、BEMSサーバを1台追加する。

　表1の項番2について、既存システムのBEMSサーバのハードウェア障害発生時には、保守サービス会社への連絡、保守員の駆けつけ、障害箇所の確認、ハードウェア交換、バックアップからのデータ復旧、サービスの再開、という手順で回復していた。この手順のうち、BEMSサーバがオフィスビル内に設置されていることに起因して保守の駆けつけに要する時間が長かったが、新システムではBEMSサーバが配置されるE社クラウド基盤サービスの拠点に保守員が常駐するので、保守員の駆けつけに要する時間は大幅に短縮される。加えて、仮想サーバに障害が発生したときでも速やかにサービスを再開できるように、新システムではE社クラウド基盤サービスの[ ｅ ]機能を用して構成する。

〔クラウドサービス障害発生時のシステムへの影響〕

　新システムでは、仮想サーバでしたBEMSサーバのハードウェア障害発生時の平均サービス回復時間について大幅に短縮できることが確認できたが、E社クラウド基盤サービスに障害が発生した場合の、新システムに対する影響について、R社から説明を求められた。E社クラウド基盤サービスでは、仮想サーバを直接利用する顧客との契約時にサービスレベル合意書(以下、SLAという)を締結しているので、当該SLAの内容を引用して、どの程度の影響が新システムに及ぶかを説明することにした。E社クラウド基盤サービスのSLAの一部を図3に示す。

<div><div class="table-container"><div class="table-header"><span class="table-title">図2 E社クラウド基盤サービスのSLA(一部)</span><span class="table-unit"></span></div>

<table border="0" style="border-collapse: collapse;border-style: solid">

<tr>

  <td align="left" style="border: 2px solid;">■月間の仮想サーバのサービス稼働率(以下、月間サービス稼働率という): 99.95%以上</br> 　月間サービス稼働率は次の式で計算する。</br>

　月間サービス稼働率 = \frac{月間総[ ｆ ]予定時間 - 月間累積障害時間}{月間総[ ｆ ]予定時間}</td>

　ただし、仮想サーバは契約期間中、無停止で稼働することを前提とする。</br>

■月間累積障害時間の考え方</br>

　月間累積障害時間とは、次のいずれかの状態であったことをＥ社がホームページで報告した時間又は利用者が証明することができた時間について、1か月分累積した時間のことである。</br>

・仮想サーバに管理画面からアクセスできない状態</br>

・仮想サーバにインターネットから全くアクセスできない状態</br>

・仮想サーバに接続されているディスクに全くアクセスできない状態</br>

■減額対応</br>

　月間サービス稼働率が99.95%に満たなかった場合、SLAで示す稼働率を達成するための稼働時間よりも少なかった稼働時間に相当する利用料金を減額する。</tr>

</table>

</div>

</div>

　E社は新システムで重要な機能を担うBEMSサーバを例として取り上げ、そこで障害が発生した場合の影響について説明する資料を、追加で作成することにした。当該資料には、図3のE社クラウド基盤サービスのSLAの内容に加えて、月間サービス稼働率を満たした場合に月間累積障害時間が[ ｇ ]分以内になることや、<u>①月間サービス稼働率が99.5％になった場合に減額される金額</u>など、具体的な事例を記載することにした。また、当該資料にはBEMSサーバのハードウェア、ソフトウェア及びネットワークに発生する可能性がある障害の要因を示し、<u>②図3のE社クラウド基盤サービスのSLAで保証されない要因</u>について説明を加えることにした。

設問1　〔品質要件の検討〕について答えよ。

(1)　本文中の[ ａ ]に入れる適切な構成要素名を図2中から選び答えよ。

(2)　表1中の[ ｂ ]、[ ｃ ]に入れる適切な字句を解答群の中から選び、記号で答えよ。

解答群

ア　以降性

イ　運用・保守性

ウ　可用性

エ　性能・拡張性

(3)　本文中の[ ｄ ]、[ ｅ ]に入れる適切な字句を解答群の中から選び、記号で答えよ。

解答群

ア　CASB

イ　RAID5

ウ　VPN

エ　アクティブ-スタンバイ

オ　クライアントサーバ

カ　シンクライアント

キ　ピアツーピア

ク　ライブマイグレーション

設問2　〔クラウドサービス障害発生時の新システムへの影響〕について答えよ。

(1)　図3中の[ ｆ ]に入れる適切な字句を解答群の中から選び、記号で答えよ。

解答群

ア　稼働

イ　待機

ウ　超過

エ　停止

(2)　本文中の[ ｇ ]に入れる適切な月間累積障害時間を分単位で、小数第1位を四捨五入して整数で答えよ。ここで、1か月は30分間とする。

(3)　本文中の下線①の場合で、サーバの月間利用料金が20万円のときに減額される金額を円単位で、小数第1位を四捨五入して整数で答えよ。

(4)　本文中の下線②について、BEMSサーバに発生する可能性のある障害の要因のうち、E社クラウド基盤サービスのSLAで保証されないものを解答群の中から選び、記号で答えよ。

解答群

ア　CPUの障害

イ　ストレージの障害

ウ　ソフトウェアの障害

エ　ネットワークの障害

　

　

令和7年度春期 午後 問4 システムアーキテクチャ(問題原文)

■■ビルエネルギーマネジメントシステムの非機能要件に関する次の記述を読んで、設問に答えよ。

　E社は、オフィスビルのエネルギー使用量を一元管理するビルエネルギーマネジメントシステム(以下、BEMSという)を開発・運用している企業である。首都圏を中心に複数のオフィスビルを所有しているR社に対して、オンプレミス方式のBEMS(以下、オンプレ BEMSという)を運用してきた。最近、R社から❝複数のオフィスビルのオンプレBEMSを統合管理したい❞という要望があり、E社はクラウド方式のBEMS(以下、クラウドBEMSという)を提案することになった。

　オンプレBEMSは、BEMS サーバ、BEMSクライアント及びBEMSゲートウェイで構成され、E社はこれらの設置・運用を行っている。ビル管理員はBEMSクライアント上のWebブラウザを用いてBEMSサーバにアクセスし、BEMSゲートウェイを介して照明機器や空調機器などの制御対象機器の制御や監視を行う。オンプレBEMSは複数のR社オフィスビルに導入されている。

　オンプレBEMSを用いた既存システム(以下、既存システムという)の構成の一部を図1に示す。なお、図1の各R社オフィスビルでは、制御対象機器を接続するビル制御LANと、BEMSサーバやBEMSクライアントを接続するビル管理LANとが既設されており、二つのLANをBEMSゲートウェイで接続している。

　図1 既存システムの構成(一部) ここから

　E社は、R社のオフィスビルに設置している既存システムから、複数のオフィスビルを統合管理できるクラウドBEMSを用いた新システム(以下、新システムという)へ移行する方法を検討した。新システムでは、ビル管理員はR 社運用拠点のBEMSクライアントから、E社が別途サービスを提供しているIaaS型クラウドサービス(以下、E 社クラウド基盤サービスという)の仮想サーバ上に構築したBEMSサーバを操作し、ファイアウォール(以下、FWという)とBEMS ゲートウェイを介して制御対象機器の制御や監視を行う。E 社はBEMSサーバ、BEMSクライアント及びBEMSゲートウェイを設置・運用する。FW及びインターネット接続環境はR社が設置・運用する。新システムの構成案の一部を図2に示す。

　図2 新システムの構成案(一部) ここから

〔品質要件の検討〕

　E社は、図2の構成案をR社に提案した。BEMSを新たなビルに導入する場合、既存システムでは、オフィスビルとにBEMSサーバ、BEMSクライアント及びBEMSゲートウェイを導入する必要があった。ー方、新システムでは、FW及びインターネット接続環境をR社が設置・運用することによって、E社がR社オフィスビルに ａ を設置することによってBEMSを導入できる。R社が要望した統合管理が実現でき、さらにBEMS導入が比較的容易になるとから、R社は新システムへの移行検討の具体化をE社に依頼した。

　E社の提案に対して、R社からの要望が出た。

・既存システムでは、BEMSサーバをメンテナンスする際に実施する計画停止の頻度が高く不便だったので、新システムでは計画停止の頻度を低くしてほしい。

・既存システムでは、BEMSサーバのハードウェア障害の発生頻度は低いものの、障害発生時のシステム停止時間が長く不便だったので，新システムではできるだけ短くしてほしい。

　E社では、R社からの要望を受けて、既存システム及び新システムの非機能要件を改めて確認し、新システムの構成案を一部見直すとともに、その優位な点を指標を用いて示すことにした。既存システム及び新システムの非機能要件の指標とその指標値のー部を表1に示す。

表1 既存システム及び新システムの非機能要件の指標とその指標値(一部)

項番	非機能要件の分類	非機能要件の指標	指標値
			既存システム	新システム
1	ｂ 、ｃ	BEMSサーバのメンテナンスに伴う計画停止の頻度	年4回	計画停止なし
2	ｃ	BEMSサーバのハードウェア障害発生時の平均サービス回復時間	48時間	15分

　表1の項番1について、既存システムではBEMSサーバのメンテナンスのたびに計画停止が必要であった。新システムでは、E社クラウド基盤サービス上でBEMSサーバを仮想サーバとして構築できることを生かして、2台のBEMSサーバを ｄ 構成にすれば、計画停止をなくすことができる。そこで、図2の構成案に対して、E社クラウド基盤サービス上で、BEMSサーバを1台追加する。

　表1の項番2について、既存システムのBEMSサーバのハードウェア障害発生時には、保守サービス会社への連絡、保守員の駆けつけ、障害箇所の確認、ハードウェア交換、バックアップからのデータ復旧、サービスの再開、という手順で回復していた。この手順のうち、BEMSサーバがオフィスビル内に設置されていることに起因して保守の駆けつけに要する時間が長かったが、新システムではBEMSサーバが配置されるE社クラウド基盤サービスの拠点に保守員が常駐するので、保守員の駆けつけに要する時間は大幅に短縮される。加えて、仮想サーバに障害が発生したときでも速やかにサービスを再開できるように、新システムではE社クラウド基盤サービスの ｅ 機能を用して構成する。

〔クラウドサービス障害発生時のシステムへの影響〕

　新システムでは、仮想サーバでしたBEMSサーバのハードウェア障害発生時の平均サービス回復時間について大幅に短縮できることが確認できたが、E社クラウド基盤サービスに障害が発生した場合の、新システムに対する影響について、R社から説明を求められた。E社クラウド基盤サービスでは、仮想サーバを直接利用する顧客との契約時にサービスレベル合意書(以下、SLAという)を締結しているので、当該SLAの内容を引用して、どの程度の影響が新システムに及ぶかを説明することにした。E社クラウド基盤サービスのSLAの一部を図3に示す。

図2 E社クラウド基盤サービスのSLA(一部)

■月間の仮想サーバのサービス稼働率(以下、月間サービス稼働率という): 99.95%以上 　月間サービス稼働率は次の式で計算する。 $$\text{月間サービス稼働率} = \frac{\text{月間総} \ \fcolorbox{black}{#ffffff}{ f } \ \text{予定時間} - \text{月間累積障害時間}}{\text{月間総} \ \fcolorbox{black}{#ffffff}{ f } \ \text{予定時間}}$$ 　ただし、仮想サーバは契約期間中、無停止で稼働することを前提とする。 ■月間累積障害時間の考え方 　月間累積障害時間とは、次のいずれかの状態であったことをＥ社がホームページで報告した時間又は利用者が証明することができた時間について、1か月分累積した時間のことである。 ・仮想サーバに管理画面からアクセスできない状態 ・仮想サーバにインターネットから全くアクセスできない状態 ・仮想サーバに接続されているディスクに全くアクセスできない状態 ■減額対応 　月間サービス稼働率が99.95%に満たなかった場合、SLAで示す稼働率を達成するための稼働時間よりも少なかった稼働時間に相当する利用料金を減額する。

　E社は新システムで重要な機能を担うBEMSサーバを例として取り上げ、そこで障害が発生した場合の影響について説明する資料を、追加で作成することにした。当該資料には、図3のE社クラウド基盤サービスのSLAの内容に加えて、月間サービス稼働率を満たした場合に月間累積障害時間が ｇ 分以内になることや、①月間サービス稼働率が99.5％になった場合に減額される金額など、具体的な事例を記載することにした。また、当該資料にはBEMSサーバのハードウェア、ソフトウェア及びネットワークに発生する可能性がある障害の要因を示し、②図3のE社クラウド基盤サービスのSLAで保証されない要因について説明を加えることにした。

設問1　〔品質要件の検討〕について答えよ。

(1)　本文中の ａ に入れる適切な構成要素名を図2中から選び答えよ。

(2)　表1中の ｂ 、ｃ に入れる適切な字句を解答群の中から選び、記号で答えよ。

解答群

ア　移行性

イ　運用・保守性

ウ　可用性

エ　性能・拡張性

(3)　本文中の ｄ 、ｅ に入れる適切な字句を解答群の中から選び、記号で答えよ。

解答群

ア　CASB

イ　RAID5

ウ　VPN

エ　アクティブ-スタンバイ

オ　クライアントサーバ

カ　シンクライアント

キ　ピアツーピア

ク　ライブマイグレーション

設問2　〔クラウドサービス障害発生時の新システムへの影響〕について答えよ。

(1)　図3中の ｆ に入れる適切な字句を解答群の中から選び、記号で答えよ。

解答群

ア　稼働

イ　待機

ウ　超過

エ　停止

(2)　本文中の ｇ に入れる適切な月間累積障害時間を分単位で、小数第1位を四捨五入して整数で答えよ。ここで、1か月は30分間とする。

(3)　本文中の下線①の場合で、サーバの月間利用料金が20万円のときに減額される金額を円単位で、小数第1位を四捨五入して整数で答えよ。

(4)　本文中の下線②について、BEMSサーバに発生する可能性のある障害の要因のうち、E社クラウド基盤サービスのSLAで保証されないものを解答群の中から選び、記号で答えよ。

解答群

ア　CPUの障害

イ　ストレージの障害

ウ　ソフトウェアの障害

エ　ネットワークの障害

　

回答・解説

設問1

(1)

　E社がR社オフィスビルに ａ を設置することによってBEMSを導入できる。の穴埋めです。

　オンプレミスというのは自社運用という意味です。その自前のBEMSでは、BEMSサーバとBEMSクライアントとBEMSゲートウェイを設置する必要がありましたが、図2のクラウドBEMSではBEMSサーバをE社にBEMSクライアントをR社運用拠点に置いていますR社のオフィス側に以前としておいておく必要があって、それがあるとBEMSの運用が導入できると言っています。BEMSサーバとBEMSクライアントはR社に置いておく必要がはないので、必要なのはBEMSゲートウェイとなります。図2にも載っています。

したがって

ａ：ＢＥＭＳゲートウェイ

が答えです。

(2)

表1の非機能要件の分類のｂとｃの穴埋めです。ｃはBEMSサーバのメンテナンスに伴う計画停止の頻度と、ハードウェアの障害発生時の平均サービス回復時間の両方に関係する分類で、ｂはBEMSサーバのメンテナンスに伴う計画停止の頻度だけに関係する分類です。

　システムを別の場所へ移動する移行性の事や、性能を上げる性能・拡張性は関係ないので、残りの二つの選択肢で考えます。可用性はシステムがどれくらい使えるかに関係していますので、計画停止の頻度と障害発生の平均サービス回復時間の両方ともどれくらい使えるかという観点がある指標だと思います。保守性の指標は計画停止の頻度と強く関係しています。

　回復時間が短いということは、障害対応の手順が確立されていたり、迅速な復旧のための仕組み(例えば、冗長化、自動フェイルオーバー、バックアップからの高速リストアなど)が整っていることを示唆します。これらの仕組みや手順を構築・運用することは、保守活動の一部と言えるかもしれません。しかし、回復時間そのものは、保守作業の「しやすさ」や「効率性」を直接的に測るものではありません。

ケースA(回復時間が短いが保守性は低い): 非常に高度な専門知識を持つエンジニアが、複雑な手順と特殊なツールを駆使して、障害を迅速に回復させているとします。回復時間は短いですが、他の担当者には原因究明や復旧作業が難しく、属人化が進んでおり、長期的に見て保守が難しい状態です。これは「保守性が低い」と言えます。

ケースB(回復時間が長くても保守性は高い): 障害発生時の手順が明確に文書化され、標準化されたツールで誰でも比較的容易に原因を特定し、復旧作業が行えるとします。ただし、物理的な部品交換が必要な場合など、どうしても時間がかかってしまう要因があり、回復時間は長くなることがあります。これは「保守性が高い」と言えます。

このようなことがあるので、回復時間は保守性の指標だと言い切れるものではないのです。保守性の指標と回復時間の関係の認識がうまく理解できたなら答えはもう決まりでしょう。

したがって

ｂ：イ　運用・保守性

ｃ：ウ　可用性

が答えです。

(3)

2台のBEMSサーバを ｄ 構成にすれば、計画停止をなくすことができる。の穴埋めから考えましょう。

2台構成にして計画停止になくすような構成はアクティブ-スタンバイくらいしか選択肢にはないです。

ア CASB (Cloud Access Security Broker): クラウドサービスへのアクセスを監視・制御し、セキュリティポリシーを適用するための仕組みです。サーバの構成とは直接関係ありません。

イ RAID5 (Redundant Array of Independent Disks 5): 複数の物理ディスクを組み合わせて、冗長性を持たせ、耐障害性を向上させる技術です。サーバ内のストレージ構成に関するもので、サーバ自体の構成とは異なります。

ウ VPN (Virtual Private Network): インターネット上に仮想的な専用線を構築し、安全な通信を実現する技術です。サーバの構成とは関係ありません。

オ クライアントサーバ: ネットワーク上の役割分担の方式で、サービスを提供するサーバと、サービスを利用するクライアントに分かれます。サーバの台数構成とは直接関係ありません。

カ シンクライアント: 処理能力をサーバ側に集中させ、クライアント端末は必要最低限の機能のみを持つ構成です。サーバの台数構成とは関係ありません。

キ ピアツーピア: ネットワークに参加するコンピュータ同士が対等な関係で直接通信を行う構成です。サーバ・クライアントモデルとは異なります。

ク ライブマイグレーション: 稼働中の仮想マシンを停止させることなく、別の物理サーバへ移動させる技術です。障害発生時のダウンタイム削減に役立ちますが、直接的な冗長化構成を示すものではありません。

しかもエのアクティブ-スタンバイは2台構成にするものの中で、1台は主系統のシステムがとまるまではいつでも切り替わる準備をしながら待ち続ける二次系統を立ち上げておくことを意味しています。この選択は簡単ですね。

したがって

ｄ：エ　アクティブ-スタンバイ

が答えです。まぁライブマイグレーションは仮想サーバに引っ越しみたいなことなので、2台構成のひっかけとしては一番、引っ掛かりやすいかもしれませんが、正しく理解していれば、大丈夫だったかもしれません。

　ｅについては仮想サーバに障害が発生したときでも速やかにサービスを再開できるように、新システムではE社クラウド基盤サービスの ｅ 機能を用して構成する。の穴埋めです。

　仮想サーバというキーワードもありますので、これこそライブマイグレーションのことですね。

したがって

ｅ：ク　ライブマイグレーション

が答えです。

設問2

(1)

　稼働率の定義を知っていたら、答えられる問題です。

$$\text{稼働率} = \frac{\text{稼働時間} - \text{障害時間}}{\text{稼働時間}}$$

　です。

したがって

ｆ：ア　稼働

が答えです。

　これは楽な問題でしたね。サッっといけるね。

(2)

　月間累積障害時間を分単位で計算する問題です。計算問題ですね。平均月日数が載ってないので、もし管理人がこの問題をやっていたら、途方に暮れて、グレテタ。まぁ月30日でも31日でも、計算結果は変わらないし、しきつめれば400年平均の月平均日数を割り出してから計算したりもできるでしょう。計算結果は変わらない。ただし2月とか2月のうるう年とかで考えたら答えは変わってきますので、そこまでひねくれると×の領域に来ます。じゃ管理人は理系のガチガチの思考が好きなので400年平均の月平均日数を割り出してから計算しましょう。

400年間には、うるう年は100回ではなく、97回です（100で割り切れる年は平年ですが、400で割り切れる年はうるう年なので、3回減ります）。

$\text{うるう年の回数} = 400 \div 4 - 400 \div 100 + 400 \div 400 = 100 - 4 + 1 = 97 \text{[回]}$

$\text{400年間の総日数} = 365 \text{[日]} \times 400 + 97 \text{[日]} = 146097 \text{[日]}$

$\text{1年間の平均日数} = 146097 \text{[日]} \div 400 = 365.2425 \text{[日]}$

$$\require{enclose} \begin{array}{r} 365.2425 \\ 4 \enclose{longdiv}{1460.9700} \\ \underline{12\phantom{00.0000}} \\ 26\phantom{0.0000} \\ \underline{24\phantom{0.0000}} \\ 20\phantom{.0000} \\ \underline{20\phantom{.0000}} \\ 0.9\phantom{000} \\ \underline{8\phantom{000}} \\ 17\phantom{00} \\ \underline{16\phantom{00}} \\ 10\phantom{0} \\ \underline{8\phantom{0}} \\ 20 \\ \underline{20} \\ 0 \end{array}$$

$\text{1か月の平均日数} = 365.2425 \text{[日]} \div 12 ≒ 30.436875 \text{[日]}$

$\text{月間総稼働予定時間} = 30.436875 \text{[日]} \times 24 \text{[時間/日]} × 60 \text{[分/時間]} ≒ 43,829.25 \text{[分]}$

$\text{月間累積障害時間} = 43,829.25 \text{[分]} \times (1 - 0.9995)$

$\text{月間累積障害時間} = 43,829.25 \text{[分]} \times 0.0005$

$\text{月間累積障害時間} ≒ 21.9146 \text{[分]}$

なので、22分ですね。イカツイ、計算してしまいました。30日で計算した方が楽ですよ～。

したがって

ｇ：22

が答えです。

　

AP過去問_令和7年度春期_午後_問3_プログラミングの同じ回の前の問題へ移動。

AP過去問_令和7年度春期_午後_問5_ネットワークの同じ回の次の問題へ移動。

AP過去問_令和6年度秋期_午後_問4_システムアーキテクチャの前の回の同じカテゴリの問題へ移動。

AP 過去問題 午後に戻る。