応用情報技術者過去問題 平成31年春期 午後問4
⇄問題文と設問を画面2分割で開く⇱問題PDF問4 システムアーキテクチャ
システム構成の見直しに関する次の記述を読んで，設問1～3に答えよ。
S社は，電子書籍をPCやタブレット，スマートフォンのWebブラウザで購読するサービスを提供している。利用者数の増加に伴うシステムの応答性能の低下や，近年のWebブラウザの機能の向上に対応するために，現状のシステム構成を見直すことになった。
〔現状のシステム構成と稼働状況〕
現状のシステム構成を図1に，各機器の機能と稼働状況を表1に示す。
〔新システムの構成の検討〕
現状のシステムへの負荷の問題を解消するために，次の方針に沿った新システムの構成を検討する。
〔新システムの構成の評価〕
新システムの構成の評価を行う。
S社は，電子書籍をPCやタブレット，スマートフォンのWebブラウザで購読するサービスを提供している。利用者数の増加に伴うシステムの応答性能の低下や，近年のWebブラウザの機能の向上に対応するために，現状のシステム構成を見直すことになった。
〔現状のシステム構成と稼働状況〕
現状のシステム構成を図1に，各機器の機能と稼働状況を表1に示す。
現状のシステムへの負荷の問題を解消するために，次の方針に沿った新システムの構成を検討する。
- 費用や変更容易性を考慮し，仮想環境上に新システムを構築する。
- WebサーバのCPU負荷を軽減するために専用の機器を導入する。
- Webブラウザよりも操作性に優れたスマートフォン用のアプリケーションプログラム(以下，スマホアプリという)を開発して，それにも対応するようにAP上の処理を見直す。
- 電子書籍データをRDB上に集中配置する方式から，KVS(Key-Value Store)を用いて複数のサーバに分散配置する方式に変更する。
新システムの構成の評価を行う。
- フロントAPとバックAPのスケーリング
スマホアプリの優位性から，利用者はWebブラウザの利用からスマホアプリの利用に移行していくことが予想される。この変化に応じて，①フロントAPとバックAPの台数を見直すことが可能である。
将来的には，Webブラウザの機能の向上に伴い，フロントAPで変換されたコンテンツを表示する方式から，Webブラウザ上で実行されるアプリケーションプログラムが処理する方式に変更することで，②スマホアプリと同様のデータ処理をWebブラウザだけで実現することができる。 - バックAPの課題
現状のシステムのAP上の問題が新システムの構成でも解消されておらず，バックAPへのリクエストに対する③応答待ちが極端に長くなってしまうおそれがある。
設問1
〔新システムの構成の検討〕について，(1)，(2)に答えよ。
- 図2中のaに入れる適切な字句を答えよ。
- 表2中のb，cに入れる適切な字句を答えよ。
解答入力欄
- a：
- b：
- c：
解答例・解答の要点
- a：TLSアクセラレータ
- b：利用者の認証
- c：ディスクの読込み負荷
解説
- 〔aについて〕
〔新システムの構成の検討〕に、「Webサーバの負荷を軽減するために専用の機器を導入する」とあります。また、表1のWebサーバの機能について「WebコンテンツをTLSによって暗号化する機能を兼ねているので，CPU負荷が高い」と記載されています。この2点より、Webサーバの負荷を軽減するための専用の機器とは、TLSの暗号化・復号機能を備えた機器であることがわかります。
TLSアクセラレータは、TLS通信におけるパケットの暗号化／復号を高速に行う専用の機器で、Webサーバの処理負荷を軽減する目的で設置されます。図2「新システムの構成」にはTLSアクセラレータが存在しないため、aにはTLSアクセラレータが入ると判断できます。
∴a＝TLSアクセラレータ - 〔bについて〕
現状のAPの主な機能は次の4つです。- 利用者の認証
- 電子書籍情報を検索する処理
- 電子書籍データを変換する処理
- ポイントを定期的に付与する処理
認証APの説明を読むと「利用者の認証を行うWebAPIを提供する。WebAPIはフロントAP又はバックAPからWebサーバを介して呼び出される」と記載があります。したがって、フロントAPとバックAPは認証APのWebAPIを使用して、利用者の認証を行うとわかります。フロントAP及びバックAPの説明には利用者の認証に関する記述がないので、bには利用者の認証が入ると判断できます。
∴利用者の認証
〔dについて〕
現状のシステムで高いものは何なのかを探します。
KVSは、現状のRDBの保持した情報のうち電子書籍の情報を保持するデータ管理システムです。表1の説明を読むと、現状のRDBは「CPU負荷は低いが，ディスク読込み負荷が常に高い」という問題があるとわかりますので、複数台のサーバで同じデータを分散して保持することによって分散できるものはディスクの読込み負荷であると判断できます。
∴ディスクの読込み負荷
設問2
システムの稼働率について，(1)，(2)に答えよ。
なお，各機器及びサービスの稼働率は次のとおりとして，図1と図2で同名のものは同じ稼働率，記載のないものは1とする。
Webサーバ＝w，AP＝a，フロントAP＝f，バックAP＝b，RDB＝r，KVS＝k
なお，各機器及びサービスの稼働率は次のとおりとして，図1と図2で同名のものは同じ稼働率，記載のないものは1とする。
Webサーバ＝w，AP＝a，フロントAP＝f，バックAP＝b，RDB＝r，KVS＝k
- 図1のシステム全体の稼働率を解答群の中から選び，記号で答えよ。
- 図2中のスマホアプリを用いた場合のシステムの稼働率を解答群の中から選び，記号で答えよ。
解答群
- w2a2r
- (1－w2)(1－a2)(1－r)
- (1－(1－w2))(1－(1－a2))r
- (1－(1－w)2)(1－(1－a)2)r
解答群
- w2b2k3
- w2f2b2k3
- (1－w2)(1－b2)(1－k3)
- (1－w2)(1－f2)(1－b2)(1－k3)
- (1－(1－w)2)(1－(1－b)2)(1－(1－k)3)
- (1－(1－w)2)(1－(1－f)2)(1－(1－b)2)(1－(1－k)3)
解答入力欄
解答例・解答の要点
- エ
- オ
解説
- 図1「現状のシステム構成」で関係するのは、Webサーバ2台、AP2台、RDB1台です。WebサーバとAPは、少なくとも1台が稼働していればシステム全体は稼働します。
- Webサーバ2台の並列構成の稼働率
- 1－(1－w)2
- AP2台の並列構成の稼働率
- 1－(1－a)2
- RDBの並列構成の稼働率
- r
(1－(1－w)2)(1－(1－a)2)r∴エ：(1－(1－w)2)(1－(1－a)2)r
- 新システムでは、Webブラウザで利用する場合とスマホアプリを用いた場合では処理手順が異なります（下記の手順では利用者認証を省略しています）。
[Webブラウザで利用する場合]- Webサーバは、Webブラウザからの要求を受理する。
- Webサーバは、Webブラウザからの要求をフロントAPに引き渡す。
- フロントAPは、バックAPのWebAPIを呼び出す。
- バックAPは、KVSから検索結果又は書籍データを取得してフロントAPに返す。
- フロントAPは、Webブラウザの種類に応じたWebコンテンツを生成し、Webサーバに返す。
- Webサーバは、フロントAPから返されたWebコンテンツを結果としてWebブラウザに返す。
- Webサーバは、スマホアプリからの要求を受理する。
- Webサーバは、バックAPのWebAPIを呼び出す。
- バックAPは、KVSから検索結果又は書籍データを取得してWebサーバに返す。
- Webサーバは、バックAPから取得した検索結果又は書籍データを結果としてスマホアプリに返す。
- スマホアプリは、返されたデータを元にして画面を更新する。
つまり、スマホアプリからの利用の場合はフロントAPを経由しません。よって、スマホアプリからの利用を考えたときに稼働率に関係するのは、Webサーバ2台、バックAP2台、KVS3台です。各機器は、先程と同様に少なくとも1台が稼働していればシステム全体は稼働します。- Webサーバ2台の並列構成の稼働率
- 1－(1－w)2
- バックAP2台の並列構成の稼働率
- 1－(1－b)2
- KVS3台の並列構成の稼働率
- 1－(1－k)3
(1－(1－w)2)(1－(1－b)2)(1－(1－k)3)∴オ：(1－(1－w)2)(1－(1－b)2)(1－(1－k)3)
設問3
〔新システムの構成の評価〕について，(1)～(3)に答えよ。
解答群
- 少なくなる
- 多くなる
- 変わらない
解答入力欄
- フロントAPの台数：
- バックAPの台数：
- 機器：
- 変更：
解答例・解答の要点
- フロントAPの台数：ア
- バックAPの台数：ウ
- バックAPから電子書籍データを取得しWebコンテンツに変換する処理 (33文字)
- 機器：バックAP
- 変更：バッチ処理とその他の処理が実行される機器を分ける (24文字)
解説
- 設問には「システム全体へのリクエストは変わらないものとし」という条件があるので、Webブラウザ経由とスマホアプリ経由の比率の変化による、フロントAPとバックAPの処理量の変化を考えることになります。
前述したように、Webブラウザを用いた場合とスマホアプリを用いた場合では処理手順が異なります。仮にWebサーバに100万回の要求があったとすると、現状の「Webブラウザ100％、スマホアプリ0％」のときと、スマホアプリへの移行が進んだ後を想定した「Webブラウザ50％、スマホアプリ50％」のときの各APの処理量は次のようになります。- Webブラウザ100％、スマホアプリ0％
- フロントAP：100万処理、バックAP：100万処理
- Webブラウザ50％、スマホアプリ50％
- フロントAP：50万処理、バックAP：100万処理
∴フロントAP＝ア：少なくなる
バックAP＝ウ：変わらない - スマホアプリを用いた場合は、フロントAPでの処理が行われません。つまり、フロントAPに相当する処理をスマホアプリ内で行っているということです。フロントAPの役割は、「バックAPから電子書籍データを取得し、Webブラウザの種類に応じたWebコンテンツに変換してWebサーバに返す」ことです。スマホアプリでは、自身のアプリに合ったコンテンツに変換すればよいので、Webブラウザの種類を考慮する必要はありません。また電子書籍データをWebサーバに返す必要もありません。よって、スマホアプリと同様のデータ処理とは、フロントAPのデータ処理から上記2つを除いた「バックAPから電子書籍データを取得しWebコンテンツに変換する処理」となります。
∴バックAPから電子書籍データを取得しWebコンテンツに変換する処理 - 下線③の問題とは、APのCPU使用率が高い時間帯にバッチ処理が行われると、リクエストに対する応答待ち時間が極端に長くなってしまうことです。新システムの構成では、バックAPが電子書籍の検索や取得の間に定期的なバッチ処理を行うことになっていますが、CPU使用率が高い時間帯では同じ問題が生じることが予想されます。
この問題への解決策としては、バックAPへのCPU資源割り当てを増やすことでバックAPのCPU使用率を下げること、または、バッチ処理の機能を別の機器(仮想マシン)に分離することが考えられます。バックAPへのCPU割当てを増やせば一時的には問題の発生を防げるかもしれませんが、根本的な解決にはなりません。設問では「回避」する策が問われているため、後者のバッチ処理を分離する策が適切となります。バッチ処理を別の仮想マシン上で処理するようにすれば、論理上は別の機器で処理することになるので、バックAPのCPU使用率に影響を与えることはなくなります。
なお、CPU利用率の高い時間帯にバッチ処理を避けるということも考えられますが、「定期的に利用者にポイントを付与する」という機能要件を満たさなくなるので適切ではありません。
※新システムの各機器は仮想環境上に作られた仮想マシンとして動作します。仮想化システムでは、各仮想マシンに割り当てるリソース量に上限値と下限値を設定できますし、新たな仮想マシンを定義するなどの変更も柔軟にできます。仮想化システムの基盤となる物理サーバは、現在のシステムの全機器を包含する能力を有し、将来の需要増にも対応できるようにある程度の余剰能力を有するものであると考えられます。
∴機器＝バックAP
変更＝バッチ処理とその他の処理が実行される機器を分ける
