応用情報技術者 2012年 秋期 午後 問05
ロードバランサを用いた負荷分散に関する次の記述を読んで、設問1~5に答えよ。
C社は企業の健康保険組合向け旅行予約サイトを運営している。現在の旅行予約サイトの利用者数は、約20組合、約10万人であり、組合ごとの利用者数には20名から10,000名までばらつきがある。旅行予約サイトは、平日の昼食休憩時間(12:00~13:00)になるとアクセス数が急増する。利用者は、旅行予約サイトの会員企業にある自席のPC(以下、クライアントという)から所属企業のプロキシサーバ経由でC社の旅行予約サイトにアクセスする。
旅行予約サイトには、アクセス数の増大やシステム障害の発生によってWebページが表示できなくなる時間を、可能な限り短くすることが求められる。C社では、レスポンスタイムの改善と信頼性の向上を目的として、システムを再構築することにした。C社情報システム部門のD君が、システムの再構築を担当することになった。
〔再構築後のネットワーク構成〕
再構築後のシステムでは、レスポンスタイムの改善と信頼性の向上のために、DNSサーバ及びWebサーバの二重化を行う。図1に再構築後のネットワーク構成を示す。

クライアントからC社の旅行予約サイトにアクセスできるようにするために、図1中のネットワーク機器及びサーバに次の設定を行う。ロードバランサに振分け先のIPアドレスとしてaと bを登録し、DNSサーバ(プライマリ)にC社の旅行予約サイトの URL に対応するIPアドレスc をゾーン情報(DNSサーバに登録されたIPアドレスやホスト名などの情報)の一つとして登録する。また、①クライアントがどちらの DNSサーバにIPアドレスを問い合わせても同一の結果を返せるような設定を、DNSサーバ(セカンダリ)に行う。
〔ロードバランサを用いた負荷分散〕
ロードバランサを用いてWebサーバの負荷分散を行う場合、クライアントからの初回の HTTP 通信と 2 回目以降の HTTP 通信を同一のWebサーバへ振り分ける必要がある。ロードバランサには L4(Layer4)スイッチとして動作するものと、L7(Layer7)スイッチとして動作するものがあり、HTTP 通信の振分け方が異なる。D君はこれらの違いについて調査した。
(1)L4スイッチとして動作するロードバランサ
L4スイッチとして動作するロードバランサは、送言されてきたIPパケット内の送信元IPアドレスとポート番号を使って、振分け先のWebサーバを決定する。振分け先の決まったIPパケットは、NAPTによるIPアドレス変換が行われ、対象のWebサーバに転送される。プロキシサーバを経由したクライアントとWebサーバの間の通信について、TCPコネクション開始時におけるロードバランサの振る舞いを図2に示す。

クライアントからプロキシサーバ経由でC社の旅行予約サイトにアクセスする場合、ロードバランサは、初回のHTTP通信についてはラウンドロビンでWebサーバを決定し、2回目以降のHTTP通信については初回と同じWebサーバに振り分ける。ロードバランサからWebサーバ1に送信されるIPパケットは、送信元IPアドレスがa.b.c.111、宛先IPアドレスがfとなる。
D君は、②L4スイッチとして動作するロードバランサを用いた負荷分散では、大規模な組合からのアクセスが片方のWebサーバに集中し、Webサーバの負荷に偏りが生じるおそれがあると考え、L7スイッチとして動作するロードバランサを使用することにした。
(2)L7スイッチとして動作するロードバランサ
L7スイッチとして動作するロードバランサは、HTTPHeader内のクライアント識別情報であるgやURLを用いて、振分け先のWebサーバを決定する。振分け先が決まったら、ロードバランサがクライアントの代わりにWebサーバにアクセスし、HTMLコンテンツを取得してクライアントへ返信する。プロキシサーバを経由したクライアントとWebサーバの間の通信について、TCPコネクション開始時におけるロードバランサの振る舞いを図3に示す。

クライアントからプロキシサーバ経由でC社の旅行予約サイトにアクセスする場合、ロードバランサは、gやURLを用いて図3中の(4)の時点で振分け先のWebサーバを決定する。このような振る舞いによって、C社のような利用者特性をもつシステムの場合にも、クライアント単位で負荷を分散するので、Webサーバの負荷に偏りが生じることが少ない。
設問1:
本文中のa〜cに入れる適切なIPアドレスを、図1中のIPアドレスを用いて答えよ(aとbは順不同)。
模範解答
a:192.168.0.1
b:192.168.0.2
c:x.y.z.21
解説
解答の論理構成
-
ロードバランサが振り分け先として登録するのは Web サーバ 2 台のアドレス
- 【問題文】には「ロードバランサに振分け先のIPアドレスとしてaと bを登録」とあります。
- 図1には「Webサーバ1:192.168.0.1」「Webサーバ2:192.168.0.2」と記載されています。ロードバランサが内部ネットワーク側で参照できるのはこの 2 つなので、
- a=「192.168.0.1」
- b=「192.168.0.2」
-
DNS へ登録する IP アドレスはロードバランサのグローバル側アドレス
- 【問題文】には「DNS サーバ(プライマリ)にC 社の旅行予約サイトの URL に対応するIPアドレスc をゾーン情報…」とあり、外部からはロードバランサを経由して Web サーバに到達させます。
- 図1ではロードバランサの Internet 側インタフェースが「[x.y.z.21]」です。
- よって c=「x.y.z.21」。
以上より模範解答は
a:192.168.0.1/b:192.168.0.2/c:x.y.z.21 となります。
a:192.168.0.1/b:192.168.0.2/c:x.y.z.21 となります。
誤りやすいポイント
- 「192.168.1.」側の Web サーバを選んでしまう
図1に 2 系統のアドレス帯が描かれていますが、ロードバランサが接続しているのは「192.168.0.」の方です。 - DNS に内部アドレス「192.168.0.254」を登録してしまう
これはロードバランサの内部向けアドレスであり、インターネット側からは到達できません。 - Web サーバの順序を固定して a/b を答えようとする
問題文には「aとbは順不同」とあるので 2 つのアドレスさえ正しければ配点されます。
FAQ
Q: なぜロードバランサ自身の内部 IP ではなくグローバル IP を DNS に登録するのですか?
A: 外部ネットワーク(インターネット)から到達できるのは「[x.y.z.21]」のみで、内部アドレス「192.168.0.254」はプライベート空間なので到達できません。
A: 外部ネットワーク(インターネット)から到達できるのは「[x.y.z.21]」のみで、内部アドレス「192.168.0.254」はプライベート空間なので到達できません。
Q: Web サーバが増えた場合、DNS の設定も変更する必要がありますか?
A: いいえ。新しい Web サーバのアドレスをロードバランサに追加するだけで、DNS はロードバランサのアドレス「[x.y.z.21]」のままで構いません。
A: いいえ。新しい Web サーバのアドレスをロードバランサに追加するだけで、DNS はロードバランサのアドレス「[x.y.z.21]」のままで構いません。
Q: a と b の順序に採点上の意味はありますか?
A: 「aとbは順不同」と明示されているため、2 つのアドレスを正しく列挙すれば順序は問いません。
A: 「aとbは順不同」と明示されているため、2 つのアドレスを正しく列挙すれば順序は問いません。
関連キーワード: ロードバランシング、NAPT, プライベートIP, DNSレコード、IPアドレス変換
設問2:
DNSサーバ(プライマリ)のゾーン情報が変更になった場合でも、DNSサーバ(プライマリ)とDNSサーバ(セカンダリ)が同一の結果を返せるようにするためには、何をすればよいか。35字以内で述べよ。
模範解答
DNSサーバ(プライマリ)からゾーン情報を転送するように設定する。
解説
解答の論理構成
-
条件整理
- 設問は「DNSサーバ(プライマリ)のゾーン情報が変更になった場合でも、DNSサーバ(プライマリ)とDNSサーバ(セカンダリ)が同一の結果を返せるようにするためには、何をすればよいか」と問うています。
- 【問題文】には「①クライアントがどちらの DNS サーバにIPアドレスを問い合わせても同一の結果を返せるような設定を、DNS サーバ(セカンダリ)に行う」とあります。
-
必要なメカニズム
- DNS でプライマリ/セカンダリのデータ整合性を保つ方法は「ゾーン転送」です。
- ゾーン転送により、プライマリで変更されたレコードがセカンダリに複製されるため、両者は常に同一の回答を返せます。
-
解答の導出
- 従って、プライマリ側の変更を自動的にセカンダリへ反映させる設定、すなわち「DNSサーバ(プライマリ)からゾーン情報を転送するように設定」することが唯一の解決策となります。
誤りやすいポイント
- キャッシュ保持時間(TTL)を短くするだけでは、プライマリとセカンダリ間のデータ差異を解消できず不正解になります。
- ラウンドロビン設定やロードバランサ設定と混同し、DNS自体のデータ同期を忘れるケースがあります。
- セカンダリ側で手動編集を行うと、プライマリとデータが食い違う恐れがあるため「自動転送」が必須です。
FAQ
Q: ゾーン転送にはどのプロトコルが使われますか?
A: 一般に TCP 53 番ポートで行う AXFR(フル転送)や IXFR(差分転送)が用いられます。
A: 一般に TCP 53 番ポートで行う AXFR(フル転送)や IXFR(差分転送)が用いられます。
Q: プライマリが停止した場合、セカンダリは正しく応答できますか?
A: はい。セカンダリは直近の転送データを保持しているため、プライマリがダウンしていても問い合わせに応答できます。
A: はい。セカンダリは直近の転送データを保持しているため、プライマリがダウンしていても問い合わせに応答できます。
Q: セキュリティ上の注意点はありますか?
A: ゾーン転送を許可する IP アドレスをセカンダリのみに制限し、無用な情報漏えいを防ぐことが推奨されます。
A: ゾーン転送を許可する IP アドレスをセカンダリのみに制限し、無用な情報漏えいを防ぐことが推奨されます。
関連キーワード: DNS, ゾーン転送、セカンダリ、データ同期、AXFR
設問3:本文及び図中のd〜fについて、(1)、(2)に答えよ。
(1)図2及び図3に示した制御のための通信は、TCPのセッション確立のプロトコルである。d、eに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:ACK
イ:FIN
ウ:FIN+ACK
エ:HTTP
オ:PSH
カ:PST
キ:SYN
ク:SYN+ACK
模範解答
d:ク
e:ア
解説
解答の論理構成
- 問題文には「図2及び図3に示した制御のための通信は、TCPのセッション確立のプロトコルである。d、eに入れる適切な字句を解答群の中から選び、記号で答えよ。」とあります。
- TCP セッション確立は“三方向ハンドシェイク”で行います。
- クライアント → サーバへ SYN 送信
- サーバ → クライアントへ SYN と ACK を同時に送信
- クライアント → サーバへ ACK 送信
- 図2・図3では
- (2) ロードバランサからプロキシサーバ(クライアント)へ返す制御パケットが d、
- (3) プロキシサーバ(クライアント)からロードバランサへ送る制御パケットが e
に対応しています。
- 従って
- d には SYN+ACK が入る → 解答群「ク」
- e には ACK が入る → 解答群「ア」
誤りやすいポイント
- FIN/FIN+ACK は通信終了時の制御フラグであり、確立時には使いません。
- SYN と ACK が別々に来ると誤解し、2 番目のパケットを ACK としてしまうミス。
- PSH や HTTP などデータ転送関連のフラグ・キーワードを選んでしまう混同。
- 図の矢印方向だけを見て「送信者が変わるからフラグも変わるはず」と思い込み、順序を逆転させる失点。
FAQ
Q: SYN+ACK ではなく単独 SYN ⇒ ACK の二段階で返す実装もありますか?
A: TCP 仕様上は“一つのパケットに SYN と ACK を同時に立てる”のが正式なハンドシェイクで、多くの OS がこの形式を採用します。
A: TCP 仕様上は“一つのパケットに SYN と ACK を同時に立てる”のが正式なハンドシェイクで、多くの OS がこの形式を採用します。
Q: ACK の後すぐに HTTP GET が流れるのは問題ないのでしょうか?
A: 三方向ハンドシェイクが完了(ACK 受信)した時点でコネクションは確立済みなので、続けて HTTP GET を送ることができます。
A: 三方向ハンドシェイクが完了(ACK 受信)した時点でコネクションは確立済みなので、続けて HTTP GET を送ることができます。
Q: 負荷分散方式とハンドシェイクのフラグは関係しますか?
A: L4/L7 いずれのロードバランサでも三方向ハンドシェイク自体は同じです。違いは“どのタイミングで振分け先 Web サーバを決定するか”にあります。
A: L4/L7 いずれのロードバランサでも三方向ハンドシェイク自体は同じです。違いは“どのタイミングで振分け先 Web サーバを決定するか”にあります。
関連キーワード: TCPハンドシェイク、SYNフラグ、ACKフラグ、ロードバランサ、L7スイッチ
設問3:本文及び図中のd〜fについて、(1)、(2)に答えよ。
(2)fに入れる適切なIPアドレスを、図1中のIPアドレスを用いて答えよ。
模範解答
f:192.168.0.1
解説
解答の論理構成
-
手掛かりの抽出
- 本文に「ロードバランサからWebサーバ1に送信されるIPパケットは、送信元IPアドレスがa.b.c.111、宛先IPアドレスがfとなる。」とあります。
- ここで「宛先IPアドレス」は “ロードバランサが内部ネットワークへ振り分ける先” であり、Webサーバ1自身のアドレスに他なりません。
-
図1からの事実確認
- 図1では、Webサーバ1のIPアドレスが「192.168.0.1」と記載されています。
- このアドレスは内部ネットワーク(ロードバランサの内側)で用いられるプライベートIPであり、外部公開用のアドレスではありません。
-
結論導出
- 振分け先がWebサーバ1であること、そしてWebサーバ1のIPアドレスが「192.168.0.1」であることを突き合わせると、宛先IPアドレスfには「192.168.0.1」を入れるのが妥当です。
誤りやすいポイント
- 「送信元IPアドレスがa.b.c.111」と並んで書かれているため、同じくグローバルIPを当てはめてしまう誤答が多いです。あくまでロードバランサ内側の通信なのでプライベートIPを選びます。
- 図1にWebサーバが複数描かれていることから、Webサーバ2(192.168.0.2 など)と取り違えるケースがあります。設問では「Webサーバ1」に限定している点を見落とさないように注意しましょう。
- 「ロードバランサ=グローバルIPを扱う装置」と短絡的に考え、内部セグメントの存在を忘れると誤答に直結します。
FAQ
Q: ロードバランサがNAPTを行うのに、なぜ内部IPアドレスをそのまま宛先にするのですか?
A: NAPTでは、外部向けパケットの宛先を内部サーバのプライベートIPに書き換えて転送します。したがってロードバランサがWebサーバへ送る時点では、宛先は内部IP(ここでは192.168.0.1)になります。
A: NAPTでは、外部向けパケットの宛先を内部サーバのプライベートIPに書き換えて転送します。したがってロードバランサがWebサーバへ送る時点では、宛先は内部IP(ここでは192.168.0.1)になります。
Q: Webサーバ1とWebサーバ2のどちらに振り分けられるかは毎回変わるのでは?
A: 図2の説明にある通り「初回はラウンドロビン、2回目以降は同一サーバへ振り分け」となります。設問は “Webサーバ1に送信されるパケットの場合” を示しているため、Webサーバ1のアドレスを答えます。
A: 図2の説明にある通り「初回はラウンドロビン、2回目以降は同一サーバへ振り分け」となります。設問は “Webサーバ1に送信されるパケットの場合” を示しているため、Webサーバ1のアドレスを答えます。
Q: 図1に二つの内部セグメントが描かれているのはなぜですか?
A: 冗長化やセグメント分離のため複数ネットワークを用意し、ロードバランサが両方を収容しています。設問部分は192.168.0.x側のWebサーバ1が対象です。
A: 冗長化やセグメント分離のため複数ネットワークを用意し、ロードバランサが両方を収容しています。設問部分は192.168.0.x側のWebサーバ1が対象です。
関連キーワード: NAPT, プライベートIPアドレス、ロードバランシング、ラウンドロビン
設問4:
本文中の下線②について、大規模な組合からのアクセスが片方のWebサーバに集中し、Webサーバの負荷に偏りが生じるのはなぜか。35字以内で述べよ。
模範解答
プロキシサーバ経由の通信は送信元IPアドレスが同一となるから
解説
解答の論理構成
-
ロードバランサの判定条件
【問題文】には「L4スイッチとして動作するロードバランサは、送言されてきたIPパケット内の送信元IPアドレスとポート番号を使って、振分け先のWebサーバを決定する。」とあります。
── 送信元 IP が同じ通信は常に同一 Web サーバへ送られます。 -
プロキシ経由アクセスの特性
同じ企業の利用者は「クライアントから所属企業のプロキシサーバ経由」でアクセスします。したがって多数の端末でもロードバランサから見る送信元 IP は企業ごとに 1 つのプロキシ IP になります。 -
ラウンドロビンが働くのは初回のみ
初回はランダムでも「2回目以降のHTTP通信については初回と同じWebサーバに振り分ける」ため、一度決まれば以降は固定です。 -
大規模組合のアクセス集中
人数が「20名から10,000名までばらつきがある」ため、利用者が多い組合では大量リクエストが同一 IP で発生。ロードバランサは全てを同じ Web サーバに送り続けるため片寄りが生じます。 -
よって解答
以上から、偏りの原因は「プロキシサーバ経由の通信は送信元IPアドレスが同一となる」ことです。
誤りやすいポイント
- 「ラウンドロビンだから均等」と早合点し、2 回目以降の固定化を読み落とす。
- ポート番号まで見ている点を強調し過ぎ、IP が同じでもポートが異なれば分散されると誤解。ポート番号は同一セッション識別用でありサーバ選択キーは“IP+ポート”の組み合わせ最初の決定時のみ。
- L7 スイッチでも同じ問題が起こると思い込む。L7 は「HTTPHeader内のクライアント識別情報」で再判定するため緩和されます。
FAQ
Q: ポート番号が違えば別サーバへ行きませんか?
A: 初回に決まった組み合わせがキャッシュされるため、同一送信元 IP の後続通信は同じ Web サーバに留まります。
A: 初回に決まった組み合わせがキャッシュされるため、同一送信元 IP の後続通信は同じ Web サーバに留まります。
Q: L7 スイッチを使えば完全に均等化できますか?
A: 「HTTPHeader内のクライアント識別情報」を利用するため IP 固定の偏りは減りますが、Cookie の有無や URL パターンなどで再度偏る可能性は残ります。
A: 「HTTPHeader内のクライアント識別情報」を利用するため IP 固定の偏りは減りますが、Cookie の有無や URL パターンなどで再度偏る可能性は残ります。
Q: DNS ラウンドロビンで IP を複数返せば解決しますか?
A: DNS で分散してもプロキシがキャッシュし 1 つの宛先に固定されるケースが多く、本質的な解決にはロードバランサ側の工夫が必要です。
A: DNS で分散してもプロキシがキャッシュし 1 つの宛先に固定されるケースが多く、本質的な解決にはロードバランサ側の工夫が必要です。
関連キーワード: L4スイッチ、ロードバランシング、送信元IPアドレス、プロキシサーバ、セッション固定
設問5:
本文中のgに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:Cookie
イ:HTMLの要素
ウ:HTMLの要素
エ:宛先IPアドレス
オ:送信元IPアドレス
カ:送信元ポート番号
模範解答
g:ア
解説
解答の論理構成
- 問題文では、L7スイッチとして動作するロードバランサの説明として
「HTTPHeader内のクライアント識別情報であるgやURLを用いて、振分け先のWebサーバを決定する。」
と明記されています。 - HTTPヘッダに含まれ、クライアントを識別する代表的な情報は Cookie です。Cookie にはセッションIDなどが格納され、同一ユーザからの複数リクエストを識別できます。
- 解答群を照合すると、クライアント識別に利用できる選択肢は「ア:Cookie」のみであり、他の選択肢
・「エ:宛先IPアドレス」「オ:送信元IPアドレス」「カ:送信元ポート番号」…TCP/IPレイヤの情報であり HTTP ヘッダではありません。
・「イ:HTMLの<Body>要素」「ウ:HTMLの<Head>要素」…HTTPレスポンスの本文要素でありヘッダではありません。 - よって、g に入る適切な語は 「Cookie」と判断できます。
誤りやすいポイント
- 「宛先IPアドレス」「送信元IPアドレス」はパケット到達前に決定されるため L4 スイッチで用いられる情報と思い込み、HTTP レイヤのロードバランサでも使うと誤解する。
- 「送信元ポート番号」は NAT 透過や多重接続で変動するため、ユーザ識別に適さないことを見落とす。
- HTML 要素(<Head> や <Body>)は HTTP ヘッダの外に位置するためロードバランサが参照できない点を忘れる。
FAQ
Q: Cookie が無効なブラウザでも L7 スイッチによる負荷分散は可能ですか?
A: 可能ですが、その場合は URL 書き換えや URL パラメータにセッションIDを埋め込む方式など、別のクライアント識別手法を併用する必要があります。
A: 可能ですが、その場合は URL 書き換えや URL パラメータにセッションIDを埋め込む方式など、別のクライアント識別手法を併用する必要があります。
Q: L4 と L7 のロードバランサはどのように選択すればよいですか?
A: セッション維持をアプリケーションレイヤで柔軟に制御したい場合や、URL 単位の振分け、WAF 連携などが必要なら L7。高速な IP/ポート単位の負荷分散だけで良い場合は L4 が適しています。
A: セッション維持をアプリケーションレイヤで柔軟に制御したい場合や、URL 単位の振分け、WAF 連携などが必要なら L7。高速な IP/ポート単位の負荷分散だけで良い場合は L4 が適しています。
Q: Cookie 情報を使うとセキュリティ上の懸念はありますか?
A: セッション固定攻撃や盗聴によるセッションハイジャックを防ぐため、Secure 属性・HttpOnly 属性の付与、TLS 通信の使用、適切な失効管理が不可欠です。
A: セッション固定攻撃や盗聴によるセッションハイジャックを防ぐため、Secure 属性・HttpOnly 属性の付与、TLS 通信の使用、適切な失効管理が不可欠です。
関連キーワード: Cookie, HTTPヘッダ、L7ロードバランシング、セッション管理


