応用情報技術者 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スイッチとして動作するロードバランサは、HTTP Header内のクライアント識別情報であるgやURLを用いて、振分け先のWebサーバを決定する。振分け先が決まったら、ロードバランサがクライアントの代わりにWebサーバにアクセスし、HTMLコンテンツを取得してクライアントへ返信する。プロキシサーバを経由したクライアントとWebサーバの間の通信について、TCPコネクション開始時におけるロードバランサの振る舞いを図3に示す。
クライアントからプロキシサーバ経由でC社の旅行予約サイトにアクセスする場合、ロードバランサは、gやURLを用いて図3中の(4)の時点で振分け先のWebサーバを決定する。このような振る舞いによって、C社のような利用者特性をもつシステムの場合にも、クライアント単位で負荷を分散するので、Webサーバの負荷に偏りが生じることが少ない。
設問1:
問題文を見る模範解答
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)に答えよ。
問題文を見る解答群
ア:ACK
イ:FIN
ウ:FIN+ACK
エ:HTTP
オ:PSH
カ:RST
キ: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は「HTTP Header内のクライアント識別情報」で再判定するため緩和されます。
FAQ
Q: ポート番号が違えば別サーバへ行きませんか?
A: 初回に決まった組み合わせがキャッシュされるため、同一送信元IPの後続通信は同じWebサーバに留まります。
A: 初回に決まった組み合わせがキャッシュされるため、同一送信元IPの後続通信は同じWebサーバに留まります。
Q: L7スイッチを使えば完全に均等化できますか?
A: 「HTTP Header内のクライアント識別情報」を利用するためIP固定の偏りは減りますが、Cookieの有無やURLパターンなどで再度偏る可能性は残ります。
A: 「HTTP Header内のクライアント識別情報」を利用するためIP固定の偏りは減りますが、Cookieの有無やURLパターンなどで再度偏る可能性は残ります。
Q: DNSラウンドロビンでIPを複数返せば解決しますか?
A: DNSで分散してもプロキシがキャッシュし1つの宛先に固定されるケースが多く、本質的な解決にはロードバランサ側の工夫が必要です。
A: DNSで分散してもプロキシがキャッシュし1つの宛先に固定されるケースが多く、本質的な解決にはロードバランサ側の工夫が必要です。
関連キーワード: L4スイッチ、ロードバランシング、送信元IPアドレス、プロキシサーバ、セッション固定
設問5:
問題文を見る本文中のgに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:Cookie
イ:HTMLの<Body>要素
ウ:HTMLの<Head>要素
エ:宛先IPアドレス
オ:送信元IPアドレス
カ:送信元ポート番号
模範解答
g:ア
解説
解答の論理構成
- 問題文では、L7スイッチとして動作するロードバランサの説明として
「HTTP Header内のクライアント識別情報である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ロードバランシング、セッション管理






