解説

• 〔aについて〕
  〔新システムの構成の検討〕に、「Webサーバの負荷を軽減するために専用の機器を導入する」とあります。また、表1のWebサーバの機能について「WebコンテンツをTLSによって暗号化する機能を兼ねているので，CPU負荷が高い」と記載されています。この2点より、Webサーバの負荷を軽減するための専用の機器とは、TLSの暗号化・復号機能を備えた機器であることがわかります。
  
  TLSアクセラレータは、TLS通信におけるパケットの暗号化／復号を高速に行う専用の機器で、Webサーバの処理負荷を軽減する目的で設置されます。図2「新システムの構成」にはTLSアクセラレータが存在しないため、aにはTLSアクセラレータが入ると判断できます。
  
  ∴a＝TLSアクセラレータ
  
  
• 〔bについて〕
  現状のAPの主な機能は次の4つです。
  • 利用者の認証
  • 電子書籍情報を検索する処理
  • 電子書籍データを変換する処理
  • ポイントを定期的に付与する処理
  新構成では、"利用者の認証"を認証AP、"変換"をフロントAP、"検索"と"ポイント付与"をバックAPがそれぞれ担います。
  
  認証APの説明を読むと「利用者の認証を行うWebAPIを提供する。WebAPIはフロントAP又はバックAPからWebサーバを介して呼び出される」と記載があります。したがって、フロントAPとバックAPは認証APのWebAPIを使用して、利用者の認証を行うとわかります。フロントAP及びバックAPの説明には利用者の認証に関する記述がないので、bには利用者の認証が入ると判断できます。
  
  ∴利用者の認証
  
  〔dについて〕
  現状のシステムで高いものは何なのかを探します。
  KVSは、現状のRDBの保持した情報のうち電子書籍の情報を保持するデータ管理システムです。表1の説明を読むと、現状のRDBは「CPU負荷は低いが，ディスク読込み負荷が常に高い」という問題があるとわかりますので、複数台のサーバで同じデータを分散して保持することによって分散できるものはディスクの読込み負荷であると判断できます。
  
  ∴ディスクの読込み負荷

解説

• 図1「現状のシステム構成」で関係するのは、Webサーバ2台、AP2台、RDB1台です。WebサーバとAPは、少なくとも1台が稼働していればシステム全体は稼働します。

  Webサーバ2台の並列構成の稼働率

  1－(1－w)²

  AP2台の並列構成の稼働率

  1－(1－a)²

  RDBの並列構成の稼働率

  r

  したがって、現状のシステム全体としての稼働率は、
  　(1－(1－w)²)(1－(1－a)²)r
  
  ∴エ：(1－(1－w)²)(1－(1－a)²)r
  
  
• 新システムでは、Webブラウザで利用する場合とスマホアプリを用いた場合では処理手順が異なります（下記の手順では利用者認証を省略しています）。
  
  [Webブラウザで利用する場合]
  1. Webサーバは、Webブラウザからの要求を受理する。
  2. Webサーバは、Webブラウザからの要求をフロントAPに引き渡す。
  3. フロントAPは、バックAPのWebAPIを呼び出す。
  4. バックAPは、KVSから検索結果又は書籍データを取得してフロントAPに返す。
  5. フロントAPは、Webブラウザの種類に応じたWebコンテンツを生成し、Webサーバに返す。
  6. Webサーバは、フロントAPから返されたWebコンテンツを結果としてWebブラウザに返す。
  [スマホアプリで利用する場合]
  1. Webサーバは、スマホアプリからの要求を受理する。
  2. Webサーバは、バックAPのWebAPIを呼び出す。
  3. バックAPは、KVSから検索結果又は書籍データを取得してWebサーバに返す。
  4. Webサーバは、バックAPから取得した検索結果又は書籍データを結果としてスマホアプリに返す。
  5. スマホアプリは、返されたデータを元にして画面を更新する。
  
  つまり、スマホアプリからの利用の場合はフロントAPを経由しません。よって、スマホアプリからの利用を考えたときに稼働率に関係するのは、Webサーバ2台、バックAP2台、KVS3台です。各機器は、先程と同様に少なくとも1台が稼働していればシステム全体は稼働します。

  Webサーバ2台の並列構成の稼働率

  1－(1－w)²

  バックAP2台の並列構成の稼働率

  1－(1－b)²

  KVS3台の並列構成の稼働率

  1－(1－k)³

  したがって、現状のシステム全体としての稼働率は、
  　(1－(1－w)²)(1－(1－b)²)(1－(1－k)³)
  
  ∴オ：(1－(1－w)²)(1－(1－b)²)(1－(1－k)³)

解説

• 設問には「システム全体へのリクエストは変わらないものとし」という条件があるので、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についてはスマホアプリの利用比率が増えるほどに処理量が減ります。よって、Webブラウザの利用からスマホアプリの利用に移行が進むと、フロントAPの台数を少なくすることが可能です。一方、バックAPについてはリクエストの分だけ処理を行わなくてはならないため台数は変わりません。
  
  ∴フロント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
  　変更＝バッチ処理とその他の処理が実行される機器を分ける