応用情報技術者 2014年 春期 午後 問04
Webシステムの機能向上に関する次の記述を読んで、設問1〜4に答えよ。
医薬品商社であるX社は、顧客に医薬品の最新情報を提供することを目的として、Webサイトを開設している。図1に現在のWebサイトのシステム構成を示す。


〔現在のシステム構成及びアクセス件数〕
・Webサーバは、クライアントからのアクセスとその検索要求に応じて、社内ネットワークのDBサーバ上のデータベースを検索し、必要な医薬品の情報をクライアントに返す。
・検索の多くは、医薬品の名称や記号から、その成分や効能を調べる内容である。
・Webサーバは、DBサーバで管理されている医薬品や成分、効能を表すコードを、顧客が理解しやすいように、図やグラフに変換して表示する。DBサーバの検索処理時間は、Webサーバの表示処理時間に比べて極めて短い。
・Webサイトの通常のアクセス件数は、平均毎秒16件である。ただし、特定病院の流行などによって急増し、通常の100倍以上のアクセスが発生する場合がある。
〔医薬品共同Webサイトの構築〕
X社は、他の医薬品商社と連携して医薬品の情報を提供することになり、各社のWebサイトをX社のWebサイトに統合し、医薬品共同Webサイト(以下、共同サイトという)として運営することになった。共同サイトの要件は、次のとおりである。
・アクセス件数を、X社単独時の4倍と想定する。
・アクセス時の応答時間は、ネットワークの伝送時間を除き、65ミリ秒以下とする。
・アクセス急増時には「アクセスが集中しておりますので、後ほど閲覧してください。」と表示する。
・24時間連続稼働を実現する。
〔共同サイトのシステム構成案〕
X社システム部のY部長は、部内のWeb担当者Z君に共同サイトの構成案作成を指示し、後日Z君から図2に示す構成案が提出された。

・Webサーバは、現在と同じ処理能力の機器を利用し、共同サイトの要件を満たすために必要な台数を設置する。
・負荷分散装置が、インターネットからのアクセス要求を監視し、各Webサーバの状況に基づいて、いずれかのWebサーバに振り分ける。
・2台のDBサーバは、クラスタ構成とする。
〔現在のWebサイトの処理能力〕
Z君は、共同サイトの構成案を決定するために、現在のWebサイトの処理能力や稼働率の調査を開始した。現在のWebサイトでは、ネットワークの伝送時間を除くと、1件当たりのアクセス処理時間は、平均50ミリ秒である。
さらに、現在のWebサイトの処理能力を数値化して評価するために、アクセスに対するサイトの応答時間を、窓口が一つのM/M/1待ち行列モデルを適用し、計算することにした。待ち行列モデルの適用については、平均到着率を単位時間当たりのアクセス件数に、平均サービス時間をアクセス処理時間に読み替える。利用率はアクセス件数とアクセス処理時間を乗じた値となる。Z君は、現在のシステムの利用率、待ち時間、応答時間は、それぞれ0.8、200ミリ秒、250ミリ秒であると計算した。
〔共同サイトの処理能力〕
Z君は、共同サイトのシステム処理能力を数値化して評価することにした。そこで、複数窓口の待ち行列モデルである M/M/s 待ち行列モデルを適用して、共同サイトの利用率と応答時間を計算し、設置が必要なWebサーバの台数を決定することにした。
M/M/s 待ち行列モデルの利用率と待ち時間比率の関係〔図3〕と次の式を利用して、必要なサーバ台数を求めることができる。
・利用率=アクセス件数×アクセス処理時間/サーバ台数
・待ち時間比率=待ち時間/アクセス処理時間
・応答時間=待ち時間+アクセス処理時間

〔処理能力の計算〕
(1) M/M/s待ち行列モデルでの計算方法を確認する。現在のシステム構成及びアクセス件数のままで、Webサーバを1台追加したとすると、次のように計算できる。
・利用率はaとなるので、図3のサーバ台数が2(n=2)の曲線と利用率との交点から待ち時間比率が分かる。
・アクセス処理時間が50ミリ秒であることから、待ち時間はおおよそbミリ秒で、応答時間はcミリ秒である。
(2) 次に、共同サイトに必要なサーバ台数を決定する。
・サーバ台数を n とすると、利用率は、d で計算できる。サーバ台数が 2, 3, 4, 5, 6, … のときの利用率をあらかじめ計算しておく。
・応答時間は共同サイトの要件に従うので、待ち時間は e ミリ秒以下になり、これらによって待ち時間比率の目標値が分かる。
Z 君は、以上の結果を Y 部長に報告した。
〔共同サイトのシステム構成の見直し〕
Y 部長は、共同サイトの構成案と必要サーバ台数の報告内容を確認した後、構成案にアクセス急増時の対応が必要と判断し、Z 君に修正案の作成を指示した。
Z 君は、負荷分散装置に、振分け先の全てのサーバが稼働しても処理が不能と判断した場合、振分けを中止し、全てのアクセスを特定の 1 台のサーバに接続させる機能があることを確認した。Z 君は、この機能を利用することによって、構成案に①アクセス急増時専用の対策用サーバを追加し、アクセス急増時には全てのアクセスをこのサーバに接続することにした。Z 君は修正案を作成し、Y 部長に提出した。
設問1:
現在のWebサイトの稼働率と、Webサーバの台数をnとしたときの共同サイトの構成案の稼働率を、それぞれ解答群の中から選び、記号で答えよ。
なお、FW及び各サーバの稼働率をpとし、L2SW、負荷分散装置及び他のネットワーク機器の稼働率は1とする。
解答群
ア:
イ:
ウ:
エ:
オ:
カ:
模範解答
現在のWebサイト:ア
共同サイト:オ
解説
解答の論理構成
-
稼働率の与件
【問題文】には「FW及び各サーバの稼働率をpとし、L2SW、負荷分散装置及び他のネットワーク機器の稼働率は1とする。」とあります。したがって計算に登場する機器は
• FW
• Webサーバ群
• DBサーバ群
の三種類だけです。 -
現在のWebサイト
図1では FW―Webサーバ―DBサーバ が直列で接続されています。直列構成の稼働率は個々の稼働率の積なので解答群「ア:」と一致します。 -
共同サイト(Webサーバ台数を n とする)
a. FW は 1 台のみ:稼働率
b. Web サーバは n 台が並列:少なくとも 1 台動けば良いのでc. DB サーバは 2 台クラスタ:こちらも並列とみなしd. 全体は直列結合解答群「オ:」と一致します。
誤りやすいポイント
- L2SW と負荷分散装置を稼働率計算に含めてしまう。与件で「稼働率は1」と指示されています。
- DB サーバ 2 台を直列と誤解し にしてしまう。問題文に「クラスタ構成」とあり少なくとも 1 台動作でサービス継続と判断するのが適切です。
- Web サーバ台数 n を掛け算で とするミス。並列冗長の可用性は です。
FAQ
Q: Web サーバが 1 台でも動けばサービス提供可能と判断して良い根拠は?
A: 図2では負荷分散装置が各 Web サーバへ振分ける構成であり、並列冗長とみなせるためです。「いずれかのWebサーバに振り分ける」と明記されています。
A: 図2では負荷分散装置が各 Web サーバへ振分ける構成であり、並列冗長とみなせるためです。「いずれかのWebサーバに振り分ける」と明記されています。
Q: DB サーバを 2 台にした場合、稼働率は で固定ですか?
A: 設問条件に「2台のDBサーバは、クラスタ構成とする」とあるため本問題では固定です。台数が替われば の形になります。
A: 設問条件に「2台のDBサーバは、クラスタ構成とする」とあるため本問題では固定です。台数が替われば の形になります。
Q: FW が 1 台故障するとサービスが全停止するのですか?
A: はい。図2に FW は 1 台しか描かれておらず、冗長化の記述も無いので単一故障点 (SPOF) となります。そのため稼働率はそのまま です。
A: はい。図2に FW は 1 台しか描かれておらず、冗長化の記述も無いので単一故障点 (SPOF) となります。そのため稼働率はそのまま です。
関連キーワード: システム可用性, 並列冗長, 直列システム, 稼働率計算, 信頼度ブロック図
設問2:〔処理能力の計算〕について答えよ。
(1)本文中のa〜eに入れる適切な数式又は数値を答えよ。
模範解答
a:0.4
b:10
c:60
d:3.2/n
e:15
解説
解答の論理構成
-
現行システムの指標整理
- 平常時の到着率は「平均毎秒16件」
- サービス時間は「1件当たりのアクセス処理時間は、平均50ミリ秒」
- M/M/sモデルの公式は「利用率=アクセス件数×アクセス処理時間/サーバ台数」
以上は全て【問題文】からの引用です。
-
[a] 利用率(Webサーバを1台増設し2台運用)
- よって [a] は 0.4 になります。
-
図3から待ち時間比率を読み取る
- サーバ台数2の曲線と利用率0.4の交点は待ち時間比率≒0.2 です。
- 待ち時間=待ち時間比率×アクセス処理時間
- 以上より [b] は 10 ミリ秒です。
-
応答時間算出
- 応答時間=待ち時間+アクセス処理時間
- したがって [c] は 60 ミリ秒です。
- 応答時間=待ち時間+アクセス処理時間
-
共同サイトの到着率
- 要件より「アクセス件数を、X社単独時の4倍と想定する」 →
- これを式に適用すると
- ゆえに [d] は です。
-
目標待ち時間
- 要件「アクセス時の応答時間は、ネットワークの伝送時間を除き、65ミリ秒以下」
- サービス時間50ミリ秒を差し引くと
- よって待ち時間の上限 [e] は 15 ミリ秒です。
誤りやすいポイント
- 利用率計算でサーバ台数を割り忘れて 0.8 としてしまう。
- 待ち時間比率を直接ミリ秒と勘違いし、50ms をかけずにそのまま答案に書く。
- 応答時間要件を 65ms と読むだけでサービス時間 50ms を控除し忘れ、[e] に 65ms を入れてしまう。
- 共同サイトの利用率式で到着率を 16 ではなく 64 に更新し忘れる。
FAQ
Q: 図3の読み取りが難しいのですが、目安はどう把握すればよいですか?
A: 曲線は右肩上がりです。利用率0.4 付近では n=2 の曲線が待ち時間比率約0.2 に位置しているため、0.2 を採用します。細かい値は要求されず、グラフから読み取れる概算で十分です。
A: 曲線は右肩上がりです。利用率0.4 付近では n=2 の曲線が待ち時間比率約0.2 に位置しているため、0.2 を採用します。細かい値は要求されず、グラフから読み取れる概算で十分です。
Q: サービス時間が短くなるとサーバ台数決定にどう影響しますか?
A: サービス時間が短いほど利用率 が下がるため、必要サーバ台数 も少なくて済みます。式 から明確です。
A: サービス時間が短いほど利用率 が下がるため、必要サーバ台数 も少なくて済みます。式 から明確です。
Q: アクセス急増時の対策サーバは待ち行列モデルに入れますか?
A: 通常運用の性能評価には含めません。急増時は負荷分散装置が全リクエストを対策サーバに迂回させる設計なので、別枠で考えます。
A: 通常運用の性能評価には含めません。急増時は負荷分散装置が全リクエストを対策サーバに迂回させる設計なので、別枠で考えます。
関連キーワード: M/M/1, M/M/s, 利用率, 待ち時間比率, 応答時間
設問2:〔処理能力の計算〕について答えよ。
(2)図3を利用して、共同サイトの要件を満たすために必要なWebサーバの最少台数を答えよ。
模範解答
5
解説
解答の論理構成
-
到着率を算出
【問題文】には「通常のアクセス件数は、平均毎秒16件」であり、共同サイトでは「アクセス件数を、X社単独時の4倍と想定する。」とあります。
よって平均到着率 -
サービス時間(アクセス処理時間)の確認
「1件当たりのアクセス処理時間は、平均50ミリ秒である。」ので -
応答時間の要件から許容待ち時間を求める
共同サイトでは「アクセス時の応答時間は、ネットワークの伝送時間を除き、65ミリ秒以下とする。」と指定されています。
したがって待ち時間の上限待ち時間比率は -
利用率を式で表す
提示された式「利用率=アクセス件数×アクセス処理時間/サーバ台数」に到着率とサービス時間を代入すると -
図3で待ち時間比率≤0.3になる最小の n を探索
• n=4 のとき 。図3の「サーバ台数が4(n=4)の曲線」と利用率 0.8 の交点は待ち時間比率が約 0.45 で 0.3 を上回ります。
• n=5 のとき 。図3の「サーバ台数が5(n=5)の曲線」と利用率 0.64 の交点は待ち時間比率が約 0.2 となり、0.3 を下回ります。よって要件を最初に満たす最少台数は 5 台です。
誤りやすいポイント
- ミリ秒と秒の単位換算を忘れて を 320 などと誤計算する。
- 応答時間の 65ミリ秒をそのまま待ち時間だと誤解し、許容待ち時間を大きく取り過ぎる。
- 図3で違うサーバ台数の曲線を読んだり、対数目盛を線形と勘違いして待ち時間比率を読み誤る。
- 利用率の式()に n を掛ける位置を逆にして ρ>1 と判定してしまう。
FAQ
Q: 共同サイトでもアクセス処理時間は「50ミリ秒」で固定と考えて良いのですか?
A: はい。【問題文】でサービス能力は「現在と同じ処理能力の機器を利用」すると明記されており、処理時間が変わらない前提で計算します。
A: はい。【問題文】でサービス能力は「現在と同じ処理能力の機器を利用」すると明記されており、処理時間が変わらない前提で計算します。
Q: 図3の値は正確に読めなくても台数を決められますか?
A: おおまかな位置が分かれば十分です。n=4 では明らかに 0.3 を超え、n=5 では下回るため、最少台数を 5 と断定できます。
A: おおまかな位置が分かれば十分です。n=4 では明らかに 0.3 を超え、n=5 では下回るため、最少台数を 5 と断定できます。
Q: アクセス急増時の対策用サーバ(①)は計算に入れなくてよいのですか?
A: 計算対象は通常時の処理能力であり、「アクセス急増時専用の対策用サーバ」は別途フェイルセーフ目的で追加されるため、本設問には影響しません。
A: 計算対象は通常時の処理能力であり、「アクセス急増時専用の対策用サーバ」は別途フェイルセーフ目的で追加されるため、本設問には影響しません。
関連キーワード: M/M/s待ち行列, 利用率, 待ち時間比率, サービス時間, 負荷分散
設問3:
〔共同サイトのシステム構成の見直し〕について、本文中の下線の対策用サーバの主な役割を15字以内で述べよ。
模範解答
サーバの状況を案内する。
解説
解答の論理構成
- 要件の再確認
【問題文】には共同サイトの要件として
「アクセス急増時には『アクセスが集中しておりますので、後ほど閲覧してください。』と表示する。」
と明記されています。 - Z君の修正案の内容
同じく【問題文】では、負荷分散装置の機能を利用し
「①アクセス急増時専用の対策用サーバを追加し、アクセス急増時には全てのアクセスをこのサーバに接続する」
と記載されています。 - 対策用サーバに求められる動き
急増時に送られてくるトラフィックを処理できない状況をユーザに告知し、再アクセスを促すことが目的です。 - したがって本サーバは業務処理を担うのではなく、“現在の稼働状況をユーザへ知らせる”役割に限定されます。
- 以上を踏まえると、主な役割は「サーバの状況を案内する。」となります。
誤りやすいポイント
- 「急増時専用」とあるため、通常処理のスケールアウト用と混同しやすい
- 負荷分散装置が振分けを“中止”すると明記されている点を見落とし、対策用サーバにも通常の業務ロジックが必要と考えてしまう
- 表示文面が要件にあることから「メッセージ表示サーバ」など具体的過ぎる表現を書き、設問の抽象度と合わなくなる
FAQ
Q: 対策用サーバは実運用データベースに接続しますか?
A: 接続しません。目的は「アクセスが集中しております…」の告知だけなので、DB接続は不要です。
A: 接続しません。目的は「アクセスが集中しております…」の告知だけなので、DB接続は不要です。
Q: 負荷分散装置が自動で告知ページを返すのでは駄目なのですか?
A: 今回は装置が“振分けを中止”し“1 台のサーバに接続”する機能を使うと明記されているため、告知ページはサーバ側で提供します。
A: 今回は装置が“振分けを中止”し“1 台のサーバに接続”する機能を使うと明記されているため、告知ページはサーバ側で提供します。
Q: 追加サーバは冗長化が必要ですか?
A: 告知専用で処理負荷が小さいため必須ではありませんが、可用性を高めたい場合は冗長化します。
A: 告知専用で処理負荷が小さいため必須ではありませんが、可用性を高めたい場合は冗長化します。
関連キーワード: 負荷分散, 待ち行列モデル, 利用率, アクセス集中
設問4:
負荷分散装置が備える機能のうち、〔医薬品共同Webサイトの構築〕に挙げた要件を満たすのに直接的に寄与するものを、解答群の中から二つ選び、記号で答えよ。
解答群
ア:アクセス処理を停止しないでWebサーバの増設、保守、修理を可能にする機能
イ:関連のあるアクセスを同じWebサーバに振り分ける機能
ウ:クライアントからのアクセスを接続回数が最も少ないWebサーバに振り分ける機能
エ:故障しているWebサーバを振り分けの対象から除外する機能
模範解答
ア、エ
解説
解答の論理構成
- 共同サイトの要件には、
・「アクセス件数を、X社単独時の4倍と想定する。」
・「アクセス時の応答時間は、ネットワークの伝送時間を除き、65ミリ秒以下とする。」
・「アクセス急増時には『アクセスが集中しておりますので、後ほど閲覧してください。』と表示する。」
・「24時間連続稼働を実現する。」
が明記されています。 - このうち負荷分散装置によって 直接 実現・支援できるのは「24時間連続稼働」です。長時間サービスを止めないためには、
「アクセス処理を停止しないでWebサーバの増設、保守、修理を可能にする機能」(解答群 ア)
「故障しているWebサーバを振り分けの対象から除外する機能」(解答群 エ)
が不可欠です。これらは、稼働中のサーバへ順次トラフィックを流し替えるホットスワップと、ヘルスチェックによる自動切り離しでダウンタイムを防止します。 - 「アクセス急増時に特定サーバへ全アクセスを接続させる」機能は本文後半の①で紹介されていますが、解答群に該当項目がなく直接マッピングできません。
- 「関連のあるアクセスを同じWebサーバに振り分ける機能」(イ)はセッション維持(スティッキネス)の話で、応答時間や連続稼働とは必須の因果関係がありません。
- 「クライアントからのアクセスを接続回数が最も少ないWebサーバに振り分ける機能」(ウ)はロードバランシング方式の一つにすぎず、要件達成に“直接的”と限定された本設問では優先度が下がります。
以上より、要件を直接満たす負荷分散装置の機能は
ア と エ となります。
ア と エ となります。
誤りやすいポイント
- 「負荷分散=レスポンス改善」と短絡し、接続回数が最少のサーバへ振る機能(ウ)を選びがち。設問は“24時間連続稼働”という可用性にフォーカスしています。
- セッション維持(イ)はショッピングサイトなどで重要ですが、本問の医薬品情報検索では必須要件として明示されていません。
- 共同サイト要件と構成案後半の①を混同し、「アクセス急増時専用の対策用サーバ」=イと誤解するケース。
FAQ
Q: なぜ「クライアントからのアクセスを接続回数が最も少ないWebサーバに振り分ける機能」は選ばれないのですか?
A: 負荷分散方式の違いは主に性能最適化ですが、設問は「24時間連続稼働」という可用性要件を“直接”満たす機能を問うています。接続回数基準のアルゴリズムがなくても稼働を継続する仕組みは構築できます。
A: 負荷分散方式の違いは主に性能最適化ですが、設問は「24時間連続稼働」という可用性要件を“直接”満たす機能を問うています。接続回数基準のアルゴリズムがなくても稼働を継続する仕組みは構築できます。
Q: 「関連のあるアクセスを同じWebサーバに振り分ける機能」が必要になる場面は?
A: ショッピングカートやログインセッションを維持するサービスです。同一ユーザが複数回アクセスするたびに別サーバへ移動すると状態管理が煩雑化するため、スティッキネスが重要になります。
A: ショッピングカートやログインセッションを維持するサービスです。同一ユーザが複数回アクセスするたびに別サーバへ移動すると状態管理が煩雑化するため、スティッキネスが重要になります。
Q: 故障サーバを除外するだけで本当に24時間連続稼働が実現できますか?
A: 冗長なWebサーバ群と、DBサーバのクラスタ構成、ネットワークや電源の二重化を併用して初めて24時間稼働の信頼性が高まります。負荷分散装置の除外機能はその中核要素の一つです。
A: 冗長なWebサーバ群と、DBサーバのクラスタ構成、ネットワークや電源の二重化を併用して初めて24時間稼働の信頼性が高まります。負荷分散装置の除外機能はその中核要素の一つです。
関連キーワード: 負荷分散, 高可用性, 冗長化, 待ち行列モデル, ロードバランサ


