戦国IT - 情報処理技術者試験の過去問対策サイト
お知らせお問い合わせ料金プラン

応用情報技術者 2013年 春期 午後 問05

アプリケーションサーバの増設に関する次の記述を読んで、設問1～3に答えよ。

　M社は、コンピュータ関連製品の販売会社である。M社では、販売を支援する業務システムを稼働させている。業務システムは、アプリケーションサーバ（以下、APサーバという）、データベースサーバ（以下、DBサーバという）などから構成されている。現在の業務システムのネットワーク構成を、図1に示す。
応用情報技術者試験（平成25年度 午後 問05 図01）
〔障害の発生と対応〕 　業務システムに新機能を追加してから数日後、多くの社員から情報システム部に、業務システムの応答が遅くなり、業務に支障を来すというクレームが入った。クレームを受けた情報システム部では、N主任とJ君が対応した。 　J君がサーバの稼働状態を調査したところ、APサーバのCPU使用率が高い値を示していた。稼働中のプロセスをチェックした結果、新機能のプログラムが、設計時に予想した以上の負荷をCPUに与えていることが分かった。 　この状況について報告を受けたN主任は、APサーバの能力増強が必要と判断した。今後も、更なる新機能の追加による負荷の増大が予測できるため、N主任は、サーバロードバランサ（以下、SLBという）を用いてAPサーバを2台構成にする方法の検討を、J君に指示した。 　 〔SLBの機能〕 　J君は、まず、SLBの機能と使用方法を調査した。 　一般にSLBには、サーバへの処理要求の振分け機能、クライアントとサーバの間のセッション維持機能、サーバの稼働監視機能などがある。セッション維持の方式は、OSI基本参照モデルのレイヤを基準に、三つの方式に分類される。レイヤ3方式では送信元IPアドレスを基に、レイヤ4方式では送信元IPアドレスとポート番号を基に、レイヤ7方式ではクッキー又はURL情報に埋め込まれた a を基に、セッション維持が行われる。サーバの稼働監視については、レイヤ3では b パケットによる装置監視、レイヤ4では c 確立要求に対する応答を確認するサービス監視、レイヤ7ではアプリケーション監視が行われる。 　 〔SLBの導入構成 1〕 　今回は、導入が容易なレイヤ4方式を採用し、SLBをPCとサーバの間に設置する。APサーバは、1台増設してAPサーバ1とAPサーバ2の構成とする。 　SLBには、各自体のIPアドレスの他に、負荷分散対象の2台のAPサーバを代表する、仮想的な一つのIPアドレス（以下、VIPという）を設定する。PCがVIP宛てに処理要求を行うと、その処理要求は、SLBによって最適なサーバに転送される。その際、SLBは送信元IPアドレスの変換は行わない。 　SLB導入時の構成（構成案1）と、PCとAPサーバ1の間の通信の順序を図2に、その時のPCとAPサーバ1の間のフレーム内のアドレス情報を表1に示す。
応用情報技術者試験（平成25年度 午後 問05 図02）
応用情報技術者試験（平成25年度 午後 問05 表01）
　J君が構成案1の内容をN主任に報告したときの会話を、次に示す。 　 　J君：SLBを、図2の構成で導入します。その際、PCのアクセス先のAPサーバのIPアドレスをVIPに変更します。また、通信は、表1のようになります。 　N主任：よく調べたね。しかし、図2の構成では、大きな変更が必要になってしまう。現在の業務システムの、PC、APサーバ及びDBサーバのサブネットマスク値は、fとなっているから、これを、gに変更するとともに、(i)サーバのその他のネットワーク情報も変更することになる。 　J君：変更の少ない方法があるのでしょうか。 　N主任：SLBのソースNAT機能を使用する方法を調べてみなさい。 　 〔SLBの導入構成案2〕 　SLBには、PCから送信されたパケットをAPサーバに転送するとき、送信元IPアドレスを、SLB自体に設定されたIPアドレスに変更してサーバ宛てで送信する、ソースNAT機能がある。 　ソースNAT機能使用時の構成（構成案2）と、PCとAPサーバ1の間の通信の順序を図3に、その時のPCとAPサーバ1の間のフレーム内のアドレス情報を表2に示す。
応用情報技術者試験（平成25年度 午後 問05 図03）
応用情報技術者試験（平成25年度 午後 問05 表02）
　J君が構成案2の内容をN主任に報告したときの会話を、次に示す。 　 　J君：ソース NAT 機能を使用すると、図3の構成になります。その際、通信は、表2のようになります。この方式では、現在の構成を変更する必要がありません。 　N主任：そうだね。図3の構成では、APサーバとDBサーバのネットワークケーブルの接続変更が必要ないだけでなく、PC、APサーバ及びDBサーバのネットワーク情報の変更も必要ない。ただし、ソース NAT 機能を使うと、(ii)APサーバのログを基に APサーバの利用状況を調査するときに、制約が生まれる。しかし、運用管理に支障を来すわけではないので、図3の方法で進めてくれないか。 　N主任の指示を受け、J君は、APサーバの増設作業を開始した。

設問1：

本文中のa〜cに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群 　ア：ICMPエコー要求 　イ：ICMPリダイレクト 　ウ：TCPコネクション 　エ：アプリケーションセッション 　オ：シーケンス番号 　カ：セッションID

模範解答

a：カ b：ア c：ウ

解説

解答の論理構成

  1. レイヤ 7 のセッション維持
    • 引用: 「レイヤ7方式ではクッキー又はURL情報に埋め込まれた a を基に、セッション維持が行われる。」
    • Web 系ロードバランサでクッキーや URL に埋め込む識別子は一般に「セッションID」です。
    • よって a ＝ 「カ：セッションID」。
  2. レイヤ 3 の稼働監視
    • 引用: 「サーバの稼働監視については、レイヤ3では b パケットによる装置監視…」
    • L3 で到達性を確認する代表的な制御メッセージは ICMP Echo（ping）です。
    • よって b ＝ 「ア：ICMPエコー要求」。
  3. レイヤ 4 の稼働監視
    • 引用: 「レイヤ4では c 確立要求に対する応答を確認するサービス監視…」
    • L4 で「確立要求」とくれば TCP 3-way-handshake の SYN。
    • よって c ＝ 「ウ：TCPコネクション」。

誤りやすいポイント

  • 「シーケンス番号」を選ぶミス
    クッキーに格納されるのは個体識別用の ID であり、シーケンス番号はフロー制御用です。
  • ICMP リダイレクトとの混同
    ICMP リダイレクトは経路変更通知であって稼働監視ではありません。
  • “TCPポート監視”と早合点して UDP を想起
    設問は「確立要求」に言及しており、UDP はコネクションレスなので対象外です。

FAQ

Q: どうしてレイヤ 7 でわざわざ「セッションID」を埋め込むのですか？
A: HTTP はステートレスのため、どのリクエストがどのサーバに行ったかを ID でひも付けないと同一ユーザの連続処理を同じサーバへ導けません。
Q: ICMP エコー要求以外にも稼働監視で使えるプロトコルはありますか？
A: ありますが、問題文が「レイヤ3」を指定しているため IP 制御メッセージである ICMP が最適な答えになります。
Q: TCP コネクション監視はどの段階で失敗を検知しますか？
A: SYN 送信後に応答が返らない、または RST が戻ってきた段階で「サービス停止」と判断します。
関連キーワード: セッションID, ICMPエコー要求, TCP 3-way-handshake, ロードバランシング, 稼働監視

設問2：〔SLBの導入構成案1〕について、(1)〜(3)に答えよ。

（1）表1中のd、eに入れる適切なアドレスを、図2中の表記で答えよ。

模範解答

d：SLB1MAC e：172.16.0.50

解説

解答の論理構成

  1. フレーム②の通信方向を確認
    表1の注記より、②は「SLB → APサーバ1」の転送です。図2には、上位ネットワーク（172.16.1.0/24）側に
    ・SLB 上位インタフェース MAC：SLB1MAC
    ・APサーバ1 MAC：AP1MAC
    が示されています。したがって、送信元 MAC は SLB1MAC、宛先 MAC は AP1MAC となります。
  2. 送信元 IP アドレスの取り扱い
    問題文には「その際、SLBは送信元IPアドレスの変換は行わない。」と明記されています。よって、PC から来たパケットの送信元 IP（172.16.0.50）がそのまま用いられます。
  3. 以上より、表1の空欄に入る値は
    d：SLB1MAC（送信元 MAC）
    e：172.16.0.50（送信元 IP）

誤りやすいポイント

  • SLB が “VIP 宛て” の要求を受け付けるので、送信元 IP も SLB の IP に書き換わると誤解しやすい。レイヤ4方式では送信元 IP は保持されます。
  • SLB には上下 2 つの MAC アドレス（SLB0MAC / SLB1MAC）があるため、どちらが上位ネットワーク側かを取り違えやすい。
  • “MAC はレイヤ2、IP はレイヤ3” の基本を失念し、IP を MAC で、MAC を IP で答えてしまうミス。

FAQ

Q: VIP（172.16.0.100）は②のフレーム内に出てこないのですか？
A: VIP は PC ⇄ SLB 間（フレーム①・④）でのみ宛先 IP として使用され、SLB ⇄ AP サーバ間では実サーバの IP（172.16.1.1 など）に書き換えられます。
Q: 送信元 MAC も PC のまま残るケースはありますか？
A: いいえ。レイヤ2はホップごとに張り替わるため、SLB → AP サーバ1 のフレームでは必ず SLB の上位側 MAC（SLB1MAC）が送信元になります。
Q: ソース NAT を使う構成案2では送信元 IP はどうなりますか？
A: ソース NAT 機能を使うと、SLB が送信元 IP を自分の IP（172.16.0.101 など）に変換します。そのため表2の [i] には SLB の IP が入ります。
関連キーワード: レイヤ4負荷分散, セッション維持, NAT, MACアドレス, VLAN

設問2：〔SLBの導入構成案1〕について、(1)〜(3)に答えよ。

（2）本文中のf、gに入れるサブネットマスクの値を、10進表記で答えよ。

模範解答

f：255.255.0.0 g：255.255.255.0

解説

解答の論理構成

  1. 現在のネットワークが 1 つの論理セグメントであることの確認
    ・PC の IP アドレスは表1の①で “172.16.0.50”。
    ・APサーバ1 の IP アドレスは表1の②で “172.16.1.1”。
    ・これらが同一ブロードキャストドメインに収まっている現状を “現在の業務システムの、PC、APサーバ及びDBサーバのサブネットマスク値は、f” と記述している。
    ・“172.16.0.50” と “172.16.1.1” は同じ第2オクテット “16” を共有しているため、サブネットマスクのネットワーク部は16ビットと推定できる。
    ・16ビットマスクの 10 進表記は “255.255.0.0”。
    ⇒ よって f ＝ 255.255.0.0。
  2. 構成案1でネットワークを分割する必要性
    ・構成案1では “レイヤ4方式を採用し、SLBをPCとサーバの間に設置する” とある。
    ・図2の説明では下位ネットワークが “172.16.0.x”、上位ネットワークが “172.16.1.x” に分かれ、SLB がルータのように振る舞う二重セグメント構成になる。
    ・2 つの /24 に分割するには 24 ビットマスク（ネットワーク部 3 オクテット）が必要。
    ・24 ビットマスクの 10 進表記は “255.255.255.0”。
    ・そのため N 主任は “これを、g に変更” と指示している。
    ⇒ よって g ＝ 255.255.255.0。

誤りやすいポイント

  • “172.16.0.0/16” という表記だけを見落とし、デフォルトクラス B（255.255.0.0）を思い出せずに別の値を選んでしまう。
  • “172.16.0.x” と “172.16.1.x” が同一セグメントだと誤解し、「変更後も 255.255.0.0 のままでよい」と判断してしまう。
  • 24 ビットマスクの 10 進表記を “255.255.0.255” などと書き間違える。

FAQ

Q: 変更前のサブネットマスクが 255.255.0.0 である根拠は何ですか？
A: “172.16.0.50” と “172.16.1.1” が同じネットワークとして通信している状況は、少なくとも第3オクテットまでがホスト部でなければ実現しません。よってネットワーク部は 16 ビット、すなわち “255.255.0.0” です。
Q: /24 に切り分ける理由は SLB がルーティングを行うからですか？
A: はい。構成案1では SLB が 2 つのインタフェースで異なるネットワークに接続します。PC 側とサーバ側が別セグメントでなければ経路制御ができません。そのため /24 に分割します。
Q: ソースNAT機能を使えばサブネットマスクを変えずに済むのですか？
A: そのとおりです。構成案2では “PC、APサーバ及びDBサーバのネットワーク情報の変更も必要ない” と述べられており、既存の “255.255.0.0” のまま運用できます。
関連キーワード: サブネットマスク, CIDR, IPアドレス設計, NAT, ロードバランシング

設問2：〔SLBの導入構成案1〕について、(1)〜(3)に答えよ。

（3）本文中の下線(i)のネットワーク情報とは何か。適切な字句を答えよ。

模範解答

経路表（ルーティングテーブル）　又は　デフォルトゲートウェイ

解説

解答の論理構成

  • 【問題文】では、構成案1を導入するために「PC、APサーバ及びDBサーバのサブネットマスク値は、fとなっているから、これを、gに変更するとともに、(i)サーバのその他のネットワーク情報も変更することになる。」と述べています。
  • もともと 172.16.0.0/16 という“単一セグメント”で運用していた環境を、構成案1では 172.16.0.0/24 と 172.16.1.0/24 に“論理分割”します。
  • サブネットを分けると、各サーバから見て「自分のセグメント外」の宛先が生じるため、どのルータ（または L3 スイッチ）を経由するかを示す情報が不可欠になります。
  • その情報こそが
    ・経路の一覧を保持する「経路表（ルーティングテーブル）」
    ・もっとも基本的な経路情報である「デフォルトゲートウェイ」
    のいずれか（実質的には両者を指す同義語的表現）です。
  • したがって、下線部 (i) が指す「サーバのその他のネットワーク情報」は「経路表（ルーティングテーブル）　又は　デフォルトゲートウェイ」となります。

誤りやすいポイント

  • 「IPアドレスも変える」と早合点しやすい
    → 既に【問題文】で VIP の導入により IP 自体は維持できると示されている。
  • 「DNS設定」と答えてしまう
    → 内部環境で DNS を使っていない記述なので根拠がない。
  • NAT の有無と経路設定を混同
    → 構成案1は NAT を使わないため、経路制御が必須であることに注意。

FAQ

Q: なぜサブネットマスク変更だけでは通信できないのですか？
A: サブネットを分けると、異なるネットワーク間通信ではルータが必要になります。そのルータを示す経路情報（デフォルトゲートウェイなど）が無いとパケットの行き先が分からず通信できません。
Q: ルーティングテーブルとデフォルトゲートウェイはどう違いますか？
A: ルーティングテーブルは複数経路を持てる一覧表、デフォルトゲートウェイは「どの経路にも該当しなければここへ送る」という表の最終行に当たる 1 つの経路です。試験ではいずれも正答とされています。
Q: ソース NAT を使う構成案2では経路表の変更が不要になるのはなぜ？
A: SLB が送信元 IP を自分の IP に書き換えるため、APサーバから見れば“同一セグメント内の装置”との通信で完結し、外部経路を意識しなくて済むからです。
関連キーワード: サブネットマスク, ルーティングテーブル, デフォルトゲートウェイ, ネットワーク分割, NAT

設問3：〔SLBの導入構成案2〕について、(1)、(2)に答えよ。

（1）表2中のh、iに入れる適切なアドレスを、図3中の表記で答えよ。

模範解答

h：SLB0MAC i：172.16.0.101

解説

解答の論理構成

  1. 前提の確認
    問題文には次の記述があります。
    – 「ソースNAT機能を使用すると、図3の構成になります。」
    – 「ソースNAT機能使用時の…フレーム内のアドレス情報を表2に示す。」
    – 表2の②行は送信元欄が h／i、宛先欄が AP1MAC／172.16.1.1。
    ②行は「SLB が APサーバ1 にパケットを中継する場面」に対応します。
  2. ソース NAT が行う処理
    問題文より
    – 「送信元IPアドレスを、SLB自体に設定されたIPアドレスに変更してサーバ宛てで送信する」
    つまり②行の送信元は “SLB 自身” になります。
  3. 図3が示す SLB のアドレス
    図3 には、SLB の下位インタフェースとして
    VIP：172.16.0.100
    IP：172.16.0.101
    MAC：SLB0MAC
    が明記されています。
    VIP は仮想 IP であり送信元としては使われません。ソース NAT で使用するのは “SLB 自身の IP／MAC” です。
  4. h と i の決定
    よって②行の送信元
    – MAC アドレス → SLB0MAC
    – IP アドレス → 172.16.0.101
    となります。

誤りやすいポイント

  • VIP と SLB 自身の IP を混同する
    VIP（172.16.0.100）はクライアントの宛先であり、サーバへ転送する際の送信元には使いません。
  • 「送信元 IP だけ変わる」と思い込み MAC を元のまま書いてしまう
    OSI 第2層でも送信元が SLB になるので MAC も SLB0MAC へ変わります。
  • レイヤ4方式との混同
    構成案1では“送信元アドレスの変換は行わない”と書かれていますが、構成案2はソース NAT を使うので仕様が逆転します。

FAQ

Q: VIP があるのに、なぜソース NAT で別の IP（172.16.0.101）を使うのですか？
A: VIP はクライアントがアクセス先として認識する共通 IP です。ソース NAT では「負荷分散装置自身」を送信元に見せるため、物理インタフェースの IP を使います。
Q: APサーバ側ではクライアントの実 IP は分からなくなるのですか？
A: はい。ログには 172.16.0.101 が記録されるため、クライアント単位の解析は別途 SLB のログや統計情報を参照する必要があります。
Q: レイヤ7方式でもソース NAT は必要ですか？
A: レイヤ7方式は転送制御がアプリケーション層になりますが、送信元 IP を書き換えるかどうかは装置の設定に依存します。ソース NAT は任意機能として用意されていることが多いです。
関連キーワード: ソースNAT, VIP, MACアドレス, 負荷分散, セッション維持

設問3：〔SLBの導入構成案2〕について、(1)、(2)に答えよ。

（2）本文中の下線(ii)の制約とは何か。25字以内で述べよ。

模範解答

APサーバを使用したPCが特定できなくなる。

解説

解答の論理構成

  1. 問題文は、ソース NAT では「送信元IPアドレスを、SLB自体に設定されたIPアドレスに変更してサーバ宛てで送信する」と説明しています。
    引用：
    「SLBには、PCから送信されたパケットをAPサーバに転送するとき、送信元IPアドレスを、SLB自体に設定されたIPアドレスに変更してサーバ宛てで送信する、ソースNAT機能がある。」
  2. その結果、APサーバ側のアクセスログに残る送信元は PC ではなく SLB になります。
    つまり、ログを見てもどの PC からのアクセスなのか判断できません。
  3. 下線部(ii)は「APサーバのログを基に APサーバの利用状況を調査するときに、制約が生まれる」と述べています。
    制約の正体は、前項のとおり PC を識別できなくなることです。
  4. したがって解答は
    「APサーバを使用したPCが特定できなくなる。」
    となります。

誤りやすいポイント

  • 「VIP が残るので PC の情報は保持される」と誤解する
    → ソース NAT では送信元 IP が SLB に上書きされるため、VIP とは無関係です。
  • 「サーバ側でポート番号を見れば PC を区別できる」と考える
    → 送信元ポートは SLB が割り振ることが多く、PC と一意に対応しません。
  • 「レイヤ7のクッキー制御と同様にセッション情報が残る」と混同する
    → 本問はレイヤ4のソース NAT であり、アプリケーション層の付加情報は使いません。

FAQ

Q: SLB でセッション維持を行っていても、なぜ PC を特定できないのですか？
A: セッション維持は負荷分散先のサーバを固定する仕組みであり、送信元 IP を元に戻す機能ではありません。ログには変換後の SLB の IP が残ります。
Q: AP サーバ側で X-Forwarded-For などのヘッダを採れば解決できますか？
A: それはレイヤ7（HTTP）での対処です。本問はレイヤ4構成なので、そのままではヘッダが付与されません。別途 L7 プロキシやミドルウェアが必要です。
Q: ソース NAT を使わずにネットワーク情報変更も避ける方法はありますか？
A: ルーティングや VLAN 分割で物理的な経路を組み直す案はありますが、既存機器設定の変更が大きく、今回は採用していません。
関連キーワード: NAT, ロードバランサ, IPアドレス, アクセスログ, 送信元変換
戦国ITクイズ機能

\ せっかくなら /

応用情報技術者を
クイズ形式で学習しませんか？

クイズ画面へ遷移する→

すぐに利用可能！

©︎2026 情報処理技術者試験対策アプリ

このサイトについてプライバシーポリシー利用規約特商法表記開発者について