応用情報技術者 2019年 春期 午後 問04
システム構成の見直しに関する次の記述を読んで、設問1〜3に答えよ。
S社は、電子書籍をPCやタブレット、スマートフォンのWebブラウザで購読するサービスを提供している。利用者数の増加に伴うシステムの応答性能の低下や、近年のWebブラウザの機能の向上に対応するために、現状のシステム構成を見直すことになった。
〔現状のシステム構成と稼働状況〕
現状のシステム構成を図1に、各機器の機能と稼働状況を表1に示す。

〔新システムの構成の検討〕
現状のシステムへの負荷の問題を解消するために、次の方針に沿った新システムの構成を検討する。
・費用や変更容易性を考慮し、仮想環境上に新システムを構築する。
・WebサーバのCPU負荷を軽減するために専用の機器を導入する。
・Webブラウザよりも操作性に優れたスマートフォン用のアプリケーションプログラム(以下、スマホアプリという)を開発して、それにも対応するようにAP上の処理を見直す。
・電子書籍データをRDB上に集中配置する方式から、KVS(Key-Value Store)を用いて複数のサーバに分散配置する方式に変更する。
新システムの構成を図2に、各機器の機能を表2に示す。
↩設問1(1) ↩設問2(1) ↩設問2(2)
↩設問1(1) ↩設問2(1) ↩設問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)に答えよ。
問題文を見る模範解答
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コンテンツに変換する処理
解説
解答の導き方
回答(要旨): バックAPから電子書籍データを取得しWebコンテンツに変換する処理
- 下線②は「スマホアプリと同様のデータ処理」を指します。まずスマホアプリがどのようにデータを扱うかを表2で確認します。表2に「KVSから電子書籍情報の検索や電子書籍データの取得を行うWebAPIを提供する。WebAPIはフロントAP又はスマホアプリからWebサーバを介して呼び出される。」とあるので、スマホアプリはWebサーバ経由でバックAPのWebAPIを呼び出し、電子書籍データを取得する処理を行うことが分かります。
- 次にフロントAPの役割を表2で確認します。表2に「バックAPから電子書籍データを取得し、Webブラウザの種類に応じたWebコンテンツとして変換してWebサーバに返す。」とあります。ここからAP側の「データ処理」は(1)バックAPからの取得と(2)表示用への変換、という二つの要素で成り立っていると読み取れます。
- 以上を合わせると、本文の「スマホアプリと同様のデータ処理」とは、バックAPから電子書籍データを取得して表示可能な形(Webコンテンツ)に変換する処理を指すと結論できます。したがって解答は「バックAPから電子書籍データを取得しWebコンテンツに変換する処理」です。
誤りやすいポイント
- スマホアプリ側の処理を「認証処理」や「利用者へのポイント付与(バッチ処理)」と混同する。表2にバッチ処理は別項目で記載されているため注意。
- スマホアプリがKVSやバックAPを直接呼び出すと誤解する。表2に「WebAPIはフロントAP又はスマホアプリからWebサーバを介して呼び出される」とあるので、スマホアプリはWebサーバ経由でWebAPIを利用する。
- フロントAPとバックAPの責務を取り違える。バックAPはKVSからの検索・取得を行うWebAPIを提供し、フロントAPは取得したデータをWebコンテンツに変換して返す役割である。
FAQ
Q: 下線②はバッチ処理も含みますか?
A: いいえ。表2ではバックAPが「利用者にポイントを定期的に付与するバッチ処理も行う」と明記していますが、下線②が指すのは電子書籍データの取得と表示用変換の処理です。
A: いいえ。表2ではバックAPが「利用者にポイントを定期的に付与するバッチ処理も行う」と明記していますが、下線②が指すのは電子書籍データの取得と表示用変換の処理です。
Q: スマホアプリはKVSへ直接アクセスしますか?
A: いいえ。表2に「WebAPIはフロントAP又はスマホアプリからWebサーバを介して呼び出される」とあるように、スマホアプリはWebサーバ経由でバックAPのWebAPIを呼び出してKVSのデータを取得します。
A: いいえ。表2に「WebAPIはフロントAP又はスマホアプリからWebサーバを介して呼び出される」とあるように、スマホアプリはWebサーバ経由でバックAPのWebAPIを呼び出してKVSのデータを取得します。
Q: 将来「Webブラウザだけで実現」する場合、処理はどう変わりますか?
A: フロントAPで行っていた「Webコンテンツへの変換」をブラウザ側(クライアントサイド処理)に移し、ブラウザがバックAPのWebAPIを介して電子書籍データを取得して表示・処理する形に変わります。
A: フロントAPで行っていた「Webコンテンツへの変換」をブラウザ側(クライアントサイド処理)に移し、ブラウザがバックAPのWebAPIを介して電子書籍データを取得して表示・処理する形に変わります。
関連キーワード: WebAPI、KVS、クライアントサイド処理、コンテンツ変換、負荷分散
設問3:〔新システムの構成の評価〕について、(1)〜(3)に答えよ。
問題文を見る模範解答
機器:バック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





