ネットワークスペシャリスト 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