応用情報技術者 2019年 春期 午後 問04
システム構成の見直しに関する次の記述を読んで、設問1〜3に答えよ。
S社は、電子書籍を PCやタブレット、スマートフォンの Webブラウザで閲読するサービスを提供している。利用者数の増加に伴うシステムの応答性能の低下や、近年の Webブラウザの機能の向上に対応するために、現状のシステム構成を見直すことになった。
〔現状のシステム構成と稼働状況〕
現状のシステム構成を図1に、各機器の機能と稼働状況を表1に示す。
〔新システムの構成の検討〕
現状のシステムへの負荷の問題を解消するために、次の方針に沿った新システムの構成を検討する。
・費用や変更容易性を考慮し、仮想環境上に新システムを構築する。
・Webサーバの CPU 負荷を軽減するために専用の機器を導入する。
・Webブラウザよりも操作性に優れたスマートフォン用のアプリケーションプログラム（以下、スマホアプリという）を開発して、それにも対応するように AP 上の処理を見直す。
・電子書籍データを RDB 上に集中配置する方式から、KVS（Key-Value Store）を用いて複数のサーバに分散配置する方式に変更する。
新システムの構成を図2に、各機器の機能を表2に示す。
〔新システムの構成の評価〕
新システムの構成の評価を行う。
・フロント AP とバック AP のスケーリング
スマホアプリの優位性から、利用者は Webブラウザの利用からスマホアプリの利用に移行していくことが予想される。この変化に応じて、①フロント AP とバック AP の台数を見直すことが可能である。
将来的には、Webブラウザの機能の向上に伴い、フロント AP で変換されたコンテンツを表示する方式から、Webブラウザ上で実行されるアプリケーションプログラムが処理する方式に変更することで、②スマホアプリと同様のデータ処理を Webブラウザだけで実現することができる。
・バック AP の課題
現状のシステムの AP 上の問題が新システムの構成でも解消されておらず、バック AP へのリクエストに対する ③応答待ちが極端に長くなってしまうおそれがある。
設問1：〔新システムの構成の検討〕について、(1)、(2)に答えよ。
（1）図2中のaに入れる適切な字句を答えよ。
模範解答
a：TLSアクセラレータ
解説
解答の論理構成
- 現状分析
表1には「Webコンテンツを TLS によって暗号化する機能を兼ねているので、CPU負荷が高い。」とあり、暗号化処理が Web サーバのボトルネックであることが示されています。 - 改善方針
新システムの方針として「・Webサーバの CPU 負荷を軽減するために専用の機器を導入する。」と明記されています。 - 専用機器の機能
Web サーバから暗号化処理だけを切り離して別装置で行えば、CPU 使用率を大きく下げられます。この役割を担う代表的な機器が「TLSアクセラレータ」（SSLアクセラレータとも呼ばれる）です。 - 図2における配置
暗号化／復号はロードバランサ直後でまとめて処理すると効率的なため、a の位置に TLSアクセラレータが配置されるのが妥当です。 - 結論
以上より、図2中の a に入る語は「TLSアクセラレータ」となります。
誤りやすいポイント
- WAF（Web Application Firewall）と混同する
WAF はアプリケーション層の攻撃検知が目的で、暗号化オフロードの効果は限定的です。 - ロードバランサそのものと誤認する
「CPU 負荷を軽減する専用機器」という文脈は暗号化処理のオフロードを示しており、負荷分散機能とは別の装置です。 - キャッシュサーバと回答する
キャッシュは通信量削減が主目的で、CPU 負荷の要因である TLS 処理には直接関与しません。
FAQ
Q: TLSアクセラレータは必ずハードウェアで実装するのですか？
A: 専用ハードウェアが最も高性能ですが、ソフトウェア型や仮想アプライアンス型でも暗号化をオフロードできます。
A: 専用ハードウェアが最も高性能ですが、ソフトウェア型や仮想アプライアンス型でも暗号化をオフロードできます。
Q: TLSアクセラレータを入れるとセキュリティは落ちませんか？
A: 証明書と秘密鍵を安全に保管する必要がありますが、適切に管理すれば暗号強度は変わりません。むしろサーバ負荷低減で最新アルゴリズムを適用しやすくなります。
A: 証明書と秘密鍵を安全に保管する必要がありますが、適切に管理すれば暗号強度は変わりません。むしろサーバ負荷低減で最新アルゴリズムを適用しやすくなります。
Q: LB と TLSアクセラレータを同一機器に統合しても良いですか？
A: 可能です。ただし負荷見積りや冗長化方式が変わるため、性能評価を再度行うことが推奨されます。
A: 可能です。ただし負荷見積りや冗長化方式が変わるため、性能評価を再度行うことが推奨されます。
関連キーワード: 暗号化処理オフロード, SSL/TLS, 負荷分散, アプリケーションサーバ, キーバリューストア
設問1：〔新システムの構成の検討〕について、(1)、(2)に答えよ。
（2）表2中のb、cに入れる適切な字句を答えよ。
模範解答
b：利用者の認証
c：ディスクの読込み負荷
解説
解答の論理構成
-
[b] に入る処理の特定
- 表2の冒頭に「"認証AP" は、"利用者の認証を行うWebAPIを提供する"」と明記されています。
- さらに同じ表で、"フロントAP" と "バックAP" の説明はいずれも「bを行い」と始まり、直後に「WebAPIを提供する認証AP」の呼出しフローが書かれています。
- したがって両 AP が共通して実施する処理は "利用者の認証" であると導けます。
-
[c] に入る負荷種別の特定
- 現状システムを示す表1には、"RDB" について「"ディスクの読み込み負荷が常に高い"」と記述されています。
- 新システムでは "KVS" を複数台で冗長配置し、「現状のシステムで高かったcを分散する」と説明されています。
- 高かった負荷とは前述の RDB の課題そのものですから、[c] には「ディスクの読み込み負荷」が当てはまります。
以上より
b：利用者の認証
c：ディスクの読み込み負荷
b：利用者の認証
c：ディスクの読み込み負荷
誤りやすいポイント
- 認証と認可の混同
「利用者の認可」や「アクセス権確認」と書くと失点します。表2で明確に「利用者の認証」と書かれている点を確認しましょう。 - CPU 負荷とディスク I/O 負荷の取り違え
RDB のボトルネックは CPU ではなく「ディスクの読み込み負荷」です。表1の文言を必ず引用して判断します。 - 表記ゆれ
「読み込み」と「読込み」を混在させると減点対象になる場合があります。問題文では「読み込み」を使用しているので統一が必要です。
FAQ
Q: 認証APを経由せずにフロントAP・バックAPが直接 DB を参照するケースはありますか？
A: 本問題の前提ではありません。利用者認証は必ず認証APが提供する WebAPI で実施すると明記されています。
A: 本問題の前提ではありません。利用者認証は必ず認証APが提供する WebAPI で実施すると明記されています。
Q: KVS はなぜディスク I/O を抑制できるのですか？
A: データを複数ノードに複製し、リードリクエストを分散できるためです。アクセスが集中しても各ノードのディスク読み込みが平準化されます。
A: データを複数ノードに複製し、リードリクエストを分散できるためです。アクセスが集中しても各ノードのディスク読み込みが平準化されます。
Q: スマホアプリに移行するとフロントAPが不要になりますか？
A: 利用者動向によっては台数縮小が可能ですが、Webブラウザ利用が残る限り完全な廃止は想定されていません。
A: 利用者動向によっては台数縮小が可能ですが、Webブラウザ利用が残る限り完全な廃止は想定されていません。
関連キーワード: 認証, ディスクI/O, ロードバランシング, KVS, 分散処理
設問2：システムの稼働率について、(1)、(2)に答えよ。 なお、各機器及びサービスの稼働率は次のとおりとして、図1と図2で同名のものは同じ稼働率、記載のないものは1とする。 Webサーバ＝w、AP＝a、フロントAP＝f、バックAP＝b、RDB＝r、KVS＝k
（1）図1のシステム全体の稼働率を解答群の中から選び、記号で答えよ。
解答群
ア：
イ：
ウ：
エ：
模範解答
エ
解説
解答の論理構成
- 稼働率の対象装置
【小問説明】に「Webサーバ＝w、AP＝a、…RDB＝r」とあります。図1では
・「Webサーバ」が上下に2台
・「AP」が上下に2台
・「RDB」が1台
で構成されています。 - 並列（冗長）部分の稼働率
- 2台の同種装置を並列に置くと、少なくとも1台が稼働していれば系は動くので
が基本形です。 - よって
・Webサーバ部：
・AP部：
- 2台の同種装置を並列に置くと、少なくとも1台が稼働していれば系は動くので
- 直列（直結）部分の稼働率
直列接続は“全部動いて初めてサービス可”なので、個々の稼働率を乗算します。図1では
「Webサーバ部」→「AP部」→「RDB」と直列に並ぶため
- 解答群との照合
解答群「エ：」が一致するため、正解は【エ】です。
誤りやすいポイント
- 2台構成＝“2台とも必要”と勘違いする
冗長化の目的は可用性向上です。少なくとも1台でサービス継続できるので加法ではなく を用います。 - ロードバランサやファイアウォールを計算に入れてしまう
【小問説明】に「記載のないものは1」とあるので稼働率1（影響なし）です。 - RDB を並列と誤認
図1では1台のみ。並列化されていないため稼働率はそのまま です。
FAQ
Q: 式を展開・簡約してから選択肢と比べても良いですか？
A: もちろん構いませんが、本問では未展開の形がそのまま選択肢「エ」にあるため、展開せずに比較した方が早いです。
A: もちろん構いませんが、本問では未展開の形がそのまま選択肢「エ」にあるため、展開せずに比較した方が早いです。
Q: 以外の公式を覚えるコツは？
A: “失敗確率を除外する”と覚えると便利です。成功＝1、失敗＝。n台並列なら失敗は 、成功はその補集合となります。
A: “失敗確率を除外する”と覚えると便利です。成功＝1、失敗＝。n台並列なら失敗は 、成功はその補集合となります。
Q: 異なる装置が直列か並列か判断できません。
A: 「どれか1台が止まってもサービスが続く」→並列、「どれか1台が止まるとサービス停止」→直列、と覚えて図で追跡すると整理しやすいです。
A: 「どれか1台が止まってもサービスが続く」→並列、「どれか1台が止まるとサービス停止」→直列、と覚えて図で追跡すると整理しやすいです。
関連キーワード: 稼働率, 冗長構成, 並列システム, 直列システム, 可用性
設問2：システムの稼働率について、(1)、(2)に答えよ。 なお、各機器及びサービスの稼働率は次のとおりとして、図1と図2で同名のものは同じ稼働率、記載のないものは1とする。 Webサーバ＝w、AP＝a、フロントAP＝f、バックAP＝b、RDB＝r、KVS＝k
（2）図2中のスマホアプリを用いた場合のシステムの稼働率を解答群の中から選び、記号で答えよ。
解答群
ア：
イ：
ウ：
エ：
オ：
カ：
模範解答
オ
解説
解答の論理構成
-
スマホアプリ利用時の経路を特定
表2の説明には、バックAPについて「“WebAPIはフロントAP又はスマホアプリからWebサーバを介して呼び出される。”」とあります。したがってスマホアプリ経由では、
スマホアプリ → Webサーバ → バックAP → KVS
の順にサービスが連携し、フロントAPやRDBは経路に含まれません。 -
使用する稼働率記号を確認
小問冒頭で「“Webサーバ＝w、AP＝a、フロントAP＝f、バックAP＝b、RDB＝r、KVS＝k”」と定義されています。今回の経路で使うのは w、b、k の3種類です。 -
冗長台数を把握
図2には
・Webサーバが2台
・バックAPが2台
・KVSが3台
と描かれており、いずれも負荷分散器の背後に並列配置されています。並列冗長は「少なくとも1台稼働していればサービス継続」という考え方なので、各グループの稼働率は
・Webサーバ群
・バックAP群
・KVS群 -
直列結合によるトータル稼働率
経路上の要素は直列に連なっているため、システム全体の稼働率は各グループ稼働率の積になります。
-
解答群の照合
上式と完全一致するのは「オ：」です。
誤りやすいポイント
- フロントAPを経路に含めてしまう
表2の「フロントAP」は“Webブラウザの種類に応じたWebコンテンツとして変換”を担当し、スマホアプリ経由では呼び出されません。ここを誤ると選択肢「カ」を選びがちです。 - 「2台ある＝稼働率×2」と誤解
並列冗長の稼働率は ではなく です。直列・並列の違いを混同すると「ア」や「イ」に誘導されます。 - KVSの台数を見落とす
図2には3台あるため指数は3、2と数え間違うとどの選択肢にも合致しなくなります。
FAQ
Q: 片系停止でも処理できる理由はどこから読み取れますか？
A: 図2で同種サーバがロードバランサ経由で並列接続されていること、表2に単一障害点を示す記述がないことから「少なくとも1台稼働でOK」と判断できます。
A: 図2で同種サーバがロードバランサ経由で並列接続されていること、表2に単一障害点を示す記述がないことから「少なくとも1台稼働でOK」と判断できます。
Q: スマホアプリ経路でもAP（a）は不要なのですか？
A: 現状システムの「AP＝a」は図2で“バックAP”と“フロントAP”に機能分割されており、スマホアプリはバックAPのみを利用します。よって記号 a は登場しません。
A: 現状システムの「AP＝a」は図2で“バックAP”と“フロントAP”に機能分割されており、スマホアプリはバックAPのみを利用します。よって記号 a は登場しません。
Q: の展開形 を使っても良いですか？
A: 試験ではどちらでも正解ですが、解答群が冪指数形式なので展開せずにそのまま示す方が照合しやすく安全です。
A: 試験ではどちらでも正解ですが、解答群が冪指数形式なので展開せずにそのまま示す方が照合しやすく安全です。
関連キーワード: 稼働率, 冗長構成, 直列システム, 並列システム
設問3：〔新システムの構成の評価〕について、(1)〜(3)に答えよ。
（1）本文中の下線①にあるフロントAPとバックAPの台数はそれぞれどのように変化するか。解答群の中から選び、記号で答えよ。ただし、システム全体へのリクエスト数は変わらないものとし、機器の台数は必要かつ最も少ない台数にすること。
解答群
ア：少なくなる
イ：多くなる
ウ：変わらない
模範解答
フロントAPの台数：ア
バックAPの台数：ウ
解説
解答の論理構成
-
スマートフォン利用への移行
- 問題文には「“スマホアプリの優位性から、利用者は Webブラウザの利用からスマホアプリの利用に移行していく”」と明記されています。
- つまり、同じ総リクエスト数のうちブラウザ経由が減り、スマホアプリ経由が増える構図になります。
-
各 AP が処理する経路の違い
- フロント AP について「“フロントAP…バックAPから電子書籍データを取得し、Webブラウザの種類に応じたWebコンテンツとして変換してWebサーバに返す。”」とあります。
- バック AP については「“バックAP…WebAPIはフロントAP又はスマホアプリからWebサーバを介して呼び出される。”」とあります。
- したがって
• フロント AP：Webブラウザからのリクエストしか受け付けない
• バック AP：Webブラウザ（＝フロント AP 経由）とスマホアプリの双方から呼び出される
-
リクエスト配分の変化と台数の検討条件
- 設問条件で「“システム全体へのリクエスト数は変わらない”」「“機器の台数は必要かつ最も少ない台数”」と指示されています。
- ブラウザ→フロント AP→バック AP の経路が減少するため、フロント AP がさばくリクエスト量は確実に減少します。必要能力を満たす最小構成を考えると、台数は「少なくなる」が適切です。
- 一方バック AP は、(減るブラウザ分) + (増えるスマホアプリ分) で総量が変わらないので、処理負荷はおおむね現状維持です。従って台数は「変わらない」と判断します。
-
結論
- フロント AP：ア「少なくなる」
- バック AP：ウ「変わらない」
誤りやすいポイント
- スマホアプリでもフロント AP を通ると勘違いし、バック AP の負荷が減ると誤答する。
- 「利用者数がスマホ側に移行する＝総リクエスト数も減る」と短絡的に考え、両 AP を減らすと判断してしまう。
- 「スマホアプリは軽量だからバック AP の負荷も軽くなる」と思い込み、台数を少なくすると処理遅延リスクを見落とす。
FAQ
Q: スマホアプリが直接 KVS にアクセスしないのはなぜですか？
A: データアクセス制御やポイント付与バッチなどの共通業務ロジックを集約し、安全性と再利用性を高めるためにバック AP が一元的に WebAPI を提供しています。
A: データアクセス制御やポイント付与バッチなどの共通業務ロジックを集約し、安全性と再利用性を高めるためにバック AP が一元的に WebAPI を提供しています。
Q: フロント AP をゼロ台にできないのでしょうか？
A: ブラウザ経由の利用が完全になくなるわけではなく、さらに将来「Webブラウザ上で実行されるアプリケーションプログラム」へ段階的に移行する際の橋渡しも必要なので、最小構成としては残す必要があります。
A: ブラウザ経由の利用が完全になくなるわけではなく、さらに将来「Webブラウザ上で実行されるアプリケーションプログラム」へ段階的に移行する際の橋渡しも必要なので、最小構成としては残す必要があります。
Q: バック AP がボトルネックになる懸念はどう対処しますか？
A: スマホアプリ比率が高まりバック AP の CPU 使用率が上昇する場合、水平スケールアウトやバッチ処理の実行タイミング見直し、あるいは KVS へのキャッシュポリシ最適化が考えられます。
A: スマホアプリ比率が高まりバック AP の CPU 使用率が上昇する場合、水平スケールアウトやバッチ処理の実行タイミング見直し、あるいは KVS へのキャッシュポリシ最適化が考えられます。
関連キーワード: 水平スケーリング, WebAPI, 負荷分散, キーバリューストア
設問3：〔新システムの構成の評価〕について、(1)〜(3)に答えよ。
（2）本文中の下線②とはどのような処理か。40字以内で述べよ。
模範解答
バックAPから電子書籍データを取得しWebコンテンツに変換する処理
解説
解答の論理構成
-
下線部の所在
評価段落には「“②スマホアプリと同様のデータ処理”を Webブラウザだけで実現」とあります。
ここで問われるのは“スマホアプリと同様”すなわち、スマホアプリ側が担っている処理内容の特定です。 -
スマホアプリの処理内容を把握
表2で「バックAP」は「KVSから電子書籍情報の検索や電子書籍データの取得を行うWebAPI」を提供すると示されています。スマホアプリはこの WebAPI を直接呼び出して電子書籍データを受け取り、端末上で閲覧画面を生成します。したがってスマホアプリの基本処理は
・バックAPからデータを取得
・取得したデータを端末側で表示用に整形
の二点です。 -
Webブラウザが将来担当する処理を特定
表2の「フロントAP」には「バックAPから電子書籍データを取得し、Webブラウザの種類に応じたWebコンテンツとして変換してWebサーバに返す」とあります。
将来はフロントAPを介さず、Webブラウザ自身がこの変換機能を担うと書かれているので、下線②はフロントAPが現在行っている上記二点をブラウザ側へ移すことを指します。 -
以上より
「バックAPから電子書籍データを取得しWebコンテンツに変換する処理」とまとめられます。
誤りやすいポイント
- 「認証処理」と混同しやすい
認証は「認証AP」が担当であり、②とは無関係です。 - 「KVSアクセスまでブラウザが行う」と誤解する
依然として KVS との直接通信はバックAPが担います。 - 「変換」の主体をフロントAPのままにしてしまう
問題文は“Webブラウザ…が処理する方式に変更”と明示しているため、主体はブラウザです。
FAQ
Q: ブラウザが変換処理を担う場合、フロントAPは不要になるのですか？
A: 変換目的でのフロントAPは不要になりますが、負荷分散や認証連携など別用途で残る可能性はあります。
A: 変換目的でのフロントAPは不要になりますが、負荷分散や認証連携など別用途で残る可能性はあります。
Q: スマホアプリとブラウザでは取得するデータ形式が異なるのですか？
A: 取得元は共通のバックAPなので基本フォーマットは同じです。違いは端末側での表示用変換ロジックにあります。
A: 取得元は共通のバックAPなので基本フォーマットは同じです。違いは端末側での表示用変換ロジックにあります。
Q: ブラウザでの変換処理はどの技術で実現することが一般的ですか？
A: JavaScript や WebAssembly などクライアントサイドスクリプトが用いられます。
A: JavaScript や WebAssembly などクライアントサイドスクリプトが用いられます。
関連キーワード: WebAPI, クライアントサイド変換, 分散ストレージ, 負荷分散, スケーリング
設問3：〔新システムの構成の評価〕について、(1)〜(3)に答えよ。
（3）本文中の下線③の問題を回避するためには、表2中の機器の機能に変更を加える必要がある。対象となる機器を表2から選び、加える変更について、30字以内で述べよ。
模範解答
機器：バックAP
変更：バッチ処理とその他の処理が実行される機器を分ける。
解説
解答の論理構成
- 下線③の原因
表1で現状の AP について「CPU使用率が80％を超える状態が続くことがあり、その時間帯にバッチ処理が実行されると、Webブラウザからのリクエストに対する応答待ちが極端に長くなってしまう」と指摘されています。 - 新システムでも同じ役割が残存
表2の「バックAP」には「利用者にポイントを定期的に付与するバッチ処理も行う」とあり、アクセス集中時にオンライン処理とバッチ処理が同居する構造が温存されています。 - 評価部分の懸念
「バック AP へのリクエストに対する③応答待ちが極端に長くなってしまうおそれ」が残ると記述されています。 - 問題の本質
オンライン処理（WebAPI 提供）とバッチ処理を同一機器で実行することが輻輳の原因です。よって両者を物理的・論理的に分割する設計変更が必要になります。 - 解答
機器：バックAP
変更：バッチ処理とその他の処理が実行される機器を分ける。
誤りやすいポイント
- 「認証AP」や「フロントAP」を選択してしまい、バッチ処理の所在を見落とす。
- KVS の負荷分散を取り違え、ストレージ側に対策を求める。
- バックAP を選んでも、具体的な変更内容を「増設する」「高性能化する」とだけ記述し、処理分離の観点が欠落する。
FAQ
Q: バッチ処理を分離する具体的な方法は何がありますか？
A: 専用のバッチサーバを追加して夜間にのみ稼働させる、またはコンテナ技術でリソース制限を設けたジョブ専用ノードを用意する方法があります。
A: 専用のバッチサーバを追加して夜間にのみ稼働させる、またはコンテナ技術でリソース制限を設けたジョブ専用ノードを用意する方法があります。
Q: KVS を導入してもバックAPの遅延は残るのですか？
A: KVS は「現状のシステムで高かったディスクの読み込み負荷を分散する」ための対策であり、CPU競合を招くバッチ処理とオンライン処理の同居問題は別に対策が必要です。
A: KVS は「現状のシステムで高かったディスクの読み込み負荷を分散する」ための対策であり、CPU競合を招くバッチ処理とオンライン処理の同居問題は別に対策が必要です。
Q: スケールアウトでバックAPを増やせば解決しませんか？
A: バッチ処理は長時間 CPU を占有するため、台数を増やしても同一ノードに同時実行されれば遅延が発生します。根本的には処理の分離が有効です。
A: バッチ処理は長時間 CPU を占有するため、台数を増やしても同一ノードに同時実行されれば遅延が発生します。根本的には処理の分離が有効です。
関連キーワード: バッチ処理, リソース競合, スケールアウト, 負荷分散, WebAPI
