応用情報技術者 2013年 春期 午後 問05
アプリケーションサーバの増設に関する次の記述を読んで、設問1～3に答えよ。
M社は、コンピュータ関連製品の販売会社である。M社では、販売を支援する業務システムを稼働させている。業務システムは、アプリケーションサーバ（以下、APサーバという）、データベースサーバ（以下、DBサーバという）などから構成されている。現在の業務システムのネットワーク構成を、図1に示す。
〔障害の発生と対応〕
業務システムに新機能を追加してから数日後、多くの社員から情報システム部に、業務システムの応答が遅くなり、業務に支障を来すというクレームが入った。クレームを受けた情報システム部では、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に示す。
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に示す。
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：ウ
解説
解答の論理構成
-
レイヤ7のセッション維持
- 引用: 「レイヤ7方式ではクッキー又はURL情報に埋め込まれた a を基に、セッション維持が行われる。」
- Web系ロードバランサでクッキーやURLに埋め込む識別子は一般に「セッションID」です。
- よって a ＝ 「カ：セッションID」。
-
レイヤ3の稼働監視
- 引用: 「サーバの稼働監視については、レイヤ3では b パケットによる装置監視…」
- L3で到達性を確認する代表的な制御メッセージはICMP Echo（ping）です。
- よって b ＝ 「ア：ICMPエコー要求」。
-
レイヤ4の稼働監視
- 引用: 「レイヤ4では c 確立要求に対する応答を確認するサービス監視…」
- L4で「確立要求」とくればTCP 3-way-handshakeのSYN。
- よって c ＝ 「ウ：TCPコネクション」。
誤りやすいポイント
- 「シーケンス番号」を選ぶミス
クッキーに格納されるのは個体識別用のIDであり、シーケンス番号はフロー制御用です。 - ICMPリダイレクトとの混同
ICMPリダイレクトは経路変更通知であって稼働監視ではありません。 - “TCPポート監視”と早合点してUDPを想起
設問は「確立要求」に言及しており、UDPはコネクションレスなので対象外です。
FAQ
Q: どうしてレイヤ7でわざわざ「セッションID」を埋め込むのですか？
A: HTTPはステートレスのため、どのリクエストがどのサーバに行ったかをIDでひも付けないと同一ユーザの連続処理を同じサーバへ導けません。
A: HTTPはステートレスのため、どのリクエストがどのサーバに行ったかをIDでひも付けないと同一ユーザの連続処理を同じサーバへ導けません。
Q: ICMPエコー要求以外にも稼働監視で使えるプロトコルはありますか？
A: ありますが、問題文が「レイヤ3」を指定しているためIP制御メッセージであるICMPが最適な答えになります。
A: ありますが、問題文が「レイヤ3」を指定しているためIP制御メッセージであるICMPが最適な答えになります。
Q: TCPコネクション監視はどの段階で失敗を検知しますか？
A: SYN送信後に応答が返らない、またはRSTが戻ってきた段階で「サービス停止」と判断します。
A: SYN送信後に応答が返らない、またはRSTが戻ってきた段階で「サービス停止」と判断します。
関連キーワード: セッションID, ICMPエコー要求, TCP 3-way-handshake, ロードバランシング, 稼働監視
設問2：〔SLBの導入構成案1〕について、(1)〜(3)に答えよ。
問題文を見る模範解答
d：SLB1MAC
e：172.16.0.50
解説
解答の論理構成
-
送信元IPアドレスの取り扱い
問題文には「その際、SLBは送信元IPアドレスの変換は行わない。」と明記されています。よって、PCから来たパケットの送信元IP（172.16.0.50）がそのまま用いられます。 -
以上より、表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など）に書き換えられます。
A: VIPはPC ⇄ SLB間（フレーム①・④）でのみ宛先IPとして使用され、SLB ⇄ APサーバ間では実サーバのIP（172.16.1.1など）に書き換えられます。
Q: 送信元MACもPCのまま残るケースはありますか？
A: いいえ。レイヤ2はホップごとに張り替わるため、SLB → APサーバ1のフレームでは必ずSLBの上位側MAC（SLB1MAC）が送信元になります。
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が入ります。
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つの論理セグメントであることの確認
・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。 -
構成案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” です。
A: “172.16.0.50” と “172.16.1.1” が同じネットワークとして通信している状況は、少なくとも第3オクテットまでがホスト部でなければ実現しません。よってネットワーク部は16ビット、すなわち “255.255.0.0” です。
Q: /24に切り分ける理由はSLBがルーティングを行うからですか？
A: はい。構成案1ではSLBが2つのインタフェースで異なるネットワークに接続します。PC側とサーバ側が別セグメントでなければ経路制御ができません。そのため /24に分割します。
A: はい。構成案1ではSLBが2つのインタフェースで異なるネットワークに接続します。PC側とサーバ側が別セグメントでなければ経路制御ができません。そのため /24に分割します。
Q: ソースNAT機能を使えばサブネットマスクを変えずに済むのですか？
A: そのとおりです。構成案2では “PC、APサーバ及びDBサーバのネットワーク情報の変更も必要ない” と述べられており、既存の “255.255.0.0” のまま運用できます。
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: サブネットを分けると、異なるネットワーク間通信ではルータが必要になります。そのルータを示す経路情報（デフォルトゲートウェイなど）が無いとパケットの行き先が分からず通信できません。
A: サブネットを分けると、異なるネットワーク間通信ではルータが必要になります。そのルータを示す経路情報（デフォルトゲートウェイなど）が無いとパケットの行き先が分からず通信できません。
Q: ルーティングテーブルとデフォルトゲートウェイはどう違いますか？
A: ルーティングテーブルは複数経路を持てる一覧表、デフォルトゲートウェイは「どの経路にも該当しなければここへ送る」という表の最終行に当たる1つの経路です。試験ではいずれも正答とされています。
A: ルーティングテーブルは複数経路を持てる一覧表、デフォルトゲートウェイは「どの経路にも該当しなければここへ送る」という表の最終行に当たる1つの経路です。試験ではいずれも正答とされています。
Q: ソースNATを使う構成案2では経路表の変更が不要になるのはなぜ？
A: SLBが送信元IPを自分のIPに書き換えるため、APサーバから見れば“同一セグメント内の装置”との通信で完結し、外部経路を意識しなくて済むからです。
A: SLBが送信元IPを自分のIPに書き換えるため、APサーバから見れば“同一セグメント内の装置”との通信で完結し、外部経路を意識しなくて済むからです。
関連キーワード: サブネットマスク, ルーティングテーブル, デフォルトゲートウェイ, ネットワーク分割, NAT
設問3：〔SLBの導入構成案2〕について、(1)、(2)に答えよ。
問題文を見る模範解答
h：SLB0MAC
i：172.16.0.101
解説
解答の論理構成
-
ソースNATが行う処理
問題文より
– 「送信元IPアドレスを、SLB自体に設定されたIPアドレスに変換してサーバ宛てに送信する」
つまり②行の送信元は “SLB自身” になります。 -
図3が示すSLBのアドレス
図3には、SLBの下位インタフェースとして
VIP：172.16.0.100
IP：172.16.0.101
MAC：SLB0MAC
が明記されています。
VIPは仮想IPであり送信元としては使われません。ソースNATで使用するのは “SLB自身のIP／MAC” です。 -
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を使います。
A: VIPはクライアントがアクセス先として認識する共通IPです。ソースNATでは「負荷分散装置自身」を送信元に見せるため、物理インタフェースのIPを使います。
Q: APサーバ側ではクライアントの実IPは分からなくなるのですか？
A: はい。ログには172.16.0.101が記録されるため、クライアント単位の解析は別途SLBのログや統計情報を参照する必要があります。
A: はい。ログには172.16.0.101が記録されるため、クライアント単位の解析は別途SLBのログや統計情報を参照する必要があります。
Q: レイヤ7方式でもソースNATは必要ですか？
A: レイヤ7方式は転送制御がアプリケーション層になりますが、送信元IPを書き換えるかどうかは装置の設定に依存します。ソースNATは任意機能として用意されていることが多いです。
A: レイヤ7方式は転送制御がアプリケーション層になりますが、送信元IPを書き換えるかどうかは装置の設定に依存します。ソースNATは任意機能として用意されていることが多いです。
関連キーワード: ソースNAT, VIP, MACアドレス, 負荷分散, セッション維持
設問3：〔SLBの導入構成案2〕について、(1)、(2)に答えよ。
問題文を見る（2）本文中の下線(ii)の制約とは何か。25字以内で述べよ。
模範解答
APサーバを使用したPCが特定できなくなる。
解説
解答の論理構成
-
問題文は、ソースNATでは「送信元IPアドレスを、SLB自体に設定されたIPアドレスに変換してサーバ宛てに送信する」と説明しています。
引用：
「SLBには、PCから送信されたパケットをAPサーバに転送するとき、送信元IPアドレスを、SLB自体に設定されたIPアドレスに変換してサーバ宛てに送信する、ソースNAT機能がある。」 -
その結果、APサーバ側のアクセスログに残る送信元はPCではなくSLBになります。
つまり、ログを見てもどのPCからのアクセスなのか判断できません。 -
下線部(ii)は「APサーバのログを基にAPサーバの利用状況を調査するときに、制約が生まれる」と述べています。
制約の正体は、前項のとおりPCを識別できなくなることです。 -
したがって解答は
「APサーバを使用したPCが特定できなくなる。」
となります。
誤りやすいポイント
- 「VIPが残るのでPCの情報は保持される」と誤解する
→ ソースNATでは送信元IPがSLBに上書きされるため、VIPとは無関係です。 - 「サーバ側でポート番号を見ればPCを区別できる」と考える
→ 送信元ポートはSLBが割り振ることが多く、PCと一意に対応しません。 - 「レイヤ7のクッキー制御と同様にセッション情報が残る」と混同する
→ 本問はレイヤ4のソースNATであり、アプリケーション層の付加情報は使いません。
FAQ
Q: SLBでセッション維持を行っていても、なぜPCを特定できないのですか？
A: セッション維持は負荷分散先のサーバを固定する仕組みであり、送信元IPを元に戻す機能ではありません。ログには変換後のSLBのIPが残ります。
A: セッション維持は負荷分散先のサーバを固定する仕組みであり、送信元IPを元に戻す機能ではありません。ログには変換後のSLBのIPが残ります。
Q: APサーバ側でX-Forwarded-Forなどのヘッダを採れば解決できますか？
A: それはレイヤ7（HTTP）での対処です。本問はレイヤ4構成なので、そのままではヘッダが付与されません。別途L7プロキシやミドルウェアが必要です。
A: それはレイヤ7（HTTP）での対処です。本問はレイヤ4構成なので、そのままではヘッダが付与されません。別途L7プロキシやミドルウェアが必要です。
Q: ソースNATを使わずにネットワーク情報変更も避ける方法はありますか？
A: ルーティングやVLAN分割で物理的な経路を組み直す案はありますが、既存機器設定の変更が大きく、今回は採用していません。
A: ルーティングやVLAN分割で物理的な経路を組み直す案はありますが、既存機器設定の変更が大きく、今回は採用していません。
関連キーワード: NAT, ロードバランサ, IPアドレス, アクセスログ, 送信元変換
