ネットワークスペシャリスト 2012年 午後1 問01

解答の論理構成

1. アについて
   【問題文】「DNS-PからDNS-Sへア転送を行い、2台のDNSサーバ間でリソースレコードの同期を取っている。」
   ‐ プライマリとセカンダリ間で行う同期は DNS の“ゾーン転送”であり、この語を入れると文意が自然に成立します。
   ➜ ア＝「ゾーン」
2. イについて
   【問題文】「長期間又は復旧不能なサービス停止による利益損失を防ぐことを目的としたイの観点から、他のデータセンタにもサーバを設置し…」
   ‐ 災害・障害時にも業務を止めないという観点は“事業継続”です。ディザスタリカバリもその一環であるため整合します。
   ➜ イ＝「事業継続」
3. ウについて
   【問題文】「…FQDN に対応する IP アドレスを 10 個準備し、DNS-P の ウ レコードに登録する。」
   ‐ FQDN→IPv4 アドレスの対応を登録するレコードは DNS の“A レコード”です。
   ➜ ウ＝「A」
4. エについて
   【問題文】「DNS-P 又は DNS-S は、Webサイトのドメインの エ DNS サーバとして、DC-C と DC-D の SLB-M を応答する。」
   ‐ “権威 DNS サーバ”として応答する、と補えば SLB-M がドメインを正式に管理する役割を示せます。
   ➜ エ＝「権威」

誤りやすいポイント

• ゾーン転送を“ゾーン情報転送”や“データ転送”と書き換えてしまう。語句の改変は禁止です。
• 事業継続を“BCP”と略記してしまい空欄に収まらないケース。
• A レコードと CNAME レコードを混同する。FQDN→IP なら A レコードです。
• “権威 DNS”を“プライマリ DNS”と誤記し、セカンダリとの混同で減点される。

FAQ

解答の論理構成

1. 分散割合の設定
   【問題文】には、DNS ラウンドロビンで分散する割合を

   ・Webアクセスを処理する能力から、DC-C と DC-D に対する Webアクセスの分散割合は 7 対 3 とする.
   と明記しています。

2. IP アドレスの割当て
   同じ段落で、仮想サーバ用 IP アドレスを 10 個登録し、次のように振り分ける指示があります。

   ・仮想サーバの IP アドレスとして、10 個の IP アドレスのうちの 7 個を a の SLB に設定し、3 個を b の SLB に設定する.

3. 7 対 3 ＝ DC-C 対 DC-D
   分散割合「7 対 3」を実現するには「7 個」の IP を処理能力が大きいデータセンタ、すなわち「DC-C」に割り当て、「3 個」の IP を「DC-D」に割り当てるのが自然な帰結です。
4. 結論
   以上より、
   a ＝ 「DC-C」
   b ＝ 「DC-D」

誤りやすいポイント

• “分散割合”を「IP アドレス数」ではなく「セッション数」と混同し、あえて逆に割り振ってしまう。
• 「処理能力が大きい方＝IP アドレス数が少なくてもよい」と誤解し、7 個を DC-D に設定してしまう。
• DC-C と DC-D の表記を取り違え、「DC-C＝30,000 セッション/秒」と読み違える。

FAQ

・①Webサーバの負荷に応じた分散ができない
のとおりです。動的負荷分散が必要な場合は後半で採用された「SLB-M」による方式が有効です。

解答の論理構成

1. 【問題文】には「一方のデータセンタにアクセスできない場合、他方のデータセンタにWebアクセスを切り替える」とあります。この要件は障害時にもサービス継続を図るディザスタリカバリ方針を示しています。
2. DNS は名前解決の入口であり、プライマリが存在するデータセンタが停止すると、同センタ内にしか DNS サーバがない構成では名前解決自体ができなくなります。
3. そこで「DNS-S は、DC-D に置くこととする」という設計が採用されています。セカンダリ DNS を別サイトに配置することで、【問題文】の要件を DNS レベルで担保できます。
4. 以上を踏まえ、「DC-C に障害が発生しても、別サイトにある DNS-S が機能し続け、DC-D でサービスを提供できる」ことが設置目的となります。

誤りやすいポイント

• 「DNS-S を DC-D に置く」＝ロードバランス向上と勘違いし、冗長・継続性の観点を見落とす。
• プライマリ／セカンダリの概念を誤解し、「DNS-P が停止すると DNS-S は使えない」と思い込む。実際はゾーンデータが同期されているため名前解決は可能です。
• 名前解決ができても Web サーバ群が動かなければ意味がない、という発想から DNS-S の配置を軽視しがち。実際は入口が開かれなければ切替も機能しません。

FAQ

解答の論理構成

• 【問題文】には、DNS ラウンドロビン方式として
  「Webサイトの URL の FQDN に対応する IP アドレスを 10 個準備し、DNS-P の ウ レコードに登録する」と記載されています。
  これは DNS 応答を順番に並べ替えて返すだけの方式で、サーバの状態を考慮しません。
• 同じく【問題文】で指摘された下線①は
  「①Webサーバの負荷に応じた分散ができない。」
  という課題です。
• DNS ラウンドロビンは“名前解決要求数”をほぼ均等に振り分けるだけで、各要求に対し実際に発生する TCP セッション数や CPU／メモリ消費などの“負荷”はサーバごとに異なります。
• したがって、アクセス数が均等でも負荷は均等にならないため、下線①の理由は
  「Web アクセス数と Web サーバの負荷が比例しない」
  となります。

誤りやすいポイント

• DNS の TTL が長いとキャッシュが効き過ぎて分散どころか“偏り”が生じる点を忘れる。
• 「7 対 3 の IP 割当＝7 対 3 の負荷」と思い込み、CPU 使用率や同時接続数といった実負荷を無視してしまう。
• DNS ラウンドロビンを“リアルタイム負荷分散”と誤解し、監視機構が無いことを見落とす。

FAQ

解答の論理構成

1. 方式の前提
   • 分散方法として「DNS ラウンドロビン」を採用し、「Webサイトの URL の FQDN に対応する IP アドレスを 10 個準備し、DNS-P の ウ レコードに登録する。」とあります。ここで登録するのは A レコードです。
2. 指摘された問題点
   • 本文には「・②データセンタの故障時に、故障しているデータセンタへ Webアクセスが継続する。」と明記されています。
   • ラウンドロビンは単純に複数の A レコードを順番に返すため、片方のデータセンタがダウンしても、その IP アドレスがキャッシュ DNS などに残り続け、ブラウザは障害データセンタへ通信してしまいます。
3. 回避策の論理
   • DNS が障害センタの IP を返さなければアクセスは発生しません。
   • よって障害発生時には、DNS ゾーンから障害センタの IP を表す A レコードを削除し、健全センタの IP だけを返すようにします。
4. 解答
   • 以上より「故障したデータセンタの仮想サーバの IP アドレスの A レコードを削除する。」が正答となります。

誤りやすいポイント

• CNAME 変更と混同する
  A レコードで実装しているため、CNAME を書き換えても解決しません。
• TTL を短く設定すれば十分と誤解する
  TTL を短縮しても障害直後のアクセスは失敗します。確実に排除するならレコード削除が必要です。
• 片方のセンタ全体を別ゾーンにする案
  ゾーンを分割してもブラウザは両方問い合わせるため、障害側を返さない保証になりません。

FAQ

解答の論理構成

1. 現状の役割
   問題文では、J社のドメインを管理するサーバとして
   ――「DNS-P と DNS-S は、J社のドメインを管理する DNS サーバであり」
   と記載されています。したがって、FQDN「web.j-sha.example.com」も DNS-P が権限を持つゾーン内にあります。
2. 新方式で求められる変更点
   下線③の指示は
   ――「③DNS-P の設定を変更し、SLB-M を Webサイトのドメインの DNS サーバとして動作させる」
   です。ここで SLB-M を “DNS サーバとして動作” させるとは、実際には ゾーンの権限を移す ことを意味します。権限を持たないままでは名前解決要求を受け取っても応答できません。
3. DNS 権限委譲の仕組み
   上位ゾーン管理者が下位ゾーンの NS レコード を登録し、問い合わせを新サーバへ転送させる仕掛けが「権限委譲」です。SLB-M の機能説明にも
   ――「J 社のサブドメインである Webサイトのドメインを管理する DNS サーバとして機能し」
   とあり、委譲を受けることを前提にしています。
4. 導かれる設定内容
   以上より、DNS-P 側で行う作業は「web.j-sha.example.com の NS レコードを SLB-M（ns1.web.j-sha.example.com／ns2.web.j-sha.example.com）に設定する」、すなわち ドメインの権限を委譲 することになります。

誤りやすいポイント

• 「SLB-M をセカンダリに追加する」と誤解し、単なるゾーン転送設定を書いてしまう。下位ドメインの委譲とプライマリ／セカンダリ関係は別概念です。
• 新設する NS レコードを DNS-S にだけ登録すればよいと思い込み、上位ゾーン（DNS-P）への登録を忘れる。上位に NS がなければ委譲は完結しません。
• A レコードを増やすだけで負荷分散ができると考え、NS レコードの重要性を見落とす。

FAQ

解答の論理構成

1. まず問題文では、下線部④として「データセンタをまたがる SLB-M 間の通信による影響を懸念」したと述べています。ここで注目すべきキーワードは “SLB-M 間の通信” です。
2. SLB-M は「Webサーバの負荷情報とセッション情報を、SLB-M 間で共有する」装置であり、共有対象の情報はリアルタイムに近い頻度で更新されます。したがって、データセンタ間を流れる通信量が増える恐れがあります。
3. データセンタ間を結ぶのは一般にインターネット接続回線です。大量の同期トラフィックが流れると「インターネット接続回線」の利用帯域が大きくなり、帯域が“圧迫”されるという懸念が妥当です。
4. 回線帯域が圧迫されると、その同じ回線を通る利用者向けの Web ブラウザ通信も影響を受けます。帯域逼迫が引き起こす典型的な現象は「Web サーバへのアクセス遅延」であり、レスポンス低下を招きます。
5. よって、
   ・SLB-M間通信で懸念されるのは「インターネット接続回線の帯域圧迫」。
   ・その結果、Webブラウザ側で懸念されるのは「Web サーバへのアクセス遅延」。
   以上が模範解答と合致します。

誤りやすいポイント

• 「パケットロス」や「セッション切断」と答える例が多いですが、問題文は“影響”の性質を問うており、主原因は通信量増大による“帯域”の問題です。
• Web ブラウザ通信で発生するのは“遅延”であって“接続不能”と断定すると失点になります。サービスレベルの低下は容認と言及されていますが、完全停止までは想定していません。
• SLB-M の冗長性や DNS 応答時間に意識が向きすぎて、帯域という根本的リソースを見落としやすい点に注意が必要です。

FAQ

解答の論理構成

1. 根拠となる記述
   【問題文】には、SLB-M の機能として
   ・「Webサーバの負荷情報とセッション情報を収集する。」
   ・「共有した情報から、DC-C 又は DC-D のどちらに Webアクセスを振り分けるかを判断して、DNS への名前解決の要求に対し、最適な応答を返す。」
   とあります。さらに処理手順(4)で
   「SLB-M は、Webサーバの負荷情報とセッション情報を基に、Webブラウザに対して最適な IP アドレスを応答する。」
   と示されており、“負荷情報”が IP アドレス選択の判断材料になることが明記されています。
2. “負荷情報”の意味合い
   負荷情報とは、サーバが現在どれだけ忙しいか、あるいは通信がどれほど集中しているかを定量的に示す指標です。DNS レベルでアクセス先を選ぶ際には、短時間で取得でき、サーバ全体の混雑度を代表するメトリクスが適しています。
3. 具体例の選定
   ①「Web サーバの応答時間」はリクエストに対するレスポンス速度を直接表すため、最も単純かつ効果的な負荷指標です。
   ②「Web サーバのデータ通信量」はネットワーク I/O の混雑度を測れるため、帯域消費が多いときの迂回判断に有効です。
   以上の 2 つは、いずれもリアルタイムで取得しやすく、SLB-M が“最適な IP アドレス”を返す際の判断に直結します。

誤りやすいポイント

• CPU 使用率やメモリ使用率だけを挙げると、通信遅延や帯域逼迫を反映できない場合があります。応答時間や通信量のように“利用者体感”に近い値を含めることが重要です。
• 「セッション数」は負荷指標の一つですが、問題が求めているのは“Web サーバの負荷情報の具体例”です。セッション数は SLB で保持する情報なので、サーバ側負荷とは別に扱われる点に注意してください。
• DNS ラウンドロビン方式との混同により「IP アドレスの数」を挙げてしまう誤答が見られますが、これは負荷情報ではありません。

FAQ

解答の論理構成

1. 【問題文】の処理手順(6)には
   “SLBは、保持しているセッション情報を確認し、そのWebブラウザのセッション情報が既に存在する場合は、適切なWebサーバにWebブラウザを接続する。”
   とあります。
2. ここで言う“適切なWebサーバ”とは、すでに “そのWebブラウザのセッション情報” を保持しているサーバを指します。
3. なぜなら、HTTPセッションは一般にアプリケーションサーバ側で状態を保持しており、同一ブラウザが別サーバに振り分けられると状態不整合が発生してしまうからです（セッションアフィニティの要件）。
4. したがって SLB は負荷分散よりもセッション維持を優先し、“Webブラウザのセッションを維持しているWebサーバ” に接続させるのが正解となります。

誤りやすいポイント

• “負荷が低いWebサーバ” と勘違いしやすい。処理手順(7)は新規セッション時のルールであり、既存セッションには適用されません。
• “同一データセンタ内の任意サーバ” と答えるミス。セッション維持はデータセンタをまたいででも優先されます。
• “SLB-Mが選択したWebサーバ” と記述してしまう混同。あくまでステップ(6)は SLB の判断です。

FAQ