応用情報技術者 2018年 秋期 午後 問05

解答の論理構成

1. 【問題文】に「LBは、各部署の PC から Webサーバに対するアクセスをラウンドロビン方式で Webサーバ1～3に分散して接続する。」とあります。したがって、アクセスは必ず LB を経由します。
2. さらに「例えば、Webサーバ 2 が選択された場合、LBはパケットの送信元のIPアドレスをa、送信先のIPアドレスをbに置き換えてパケットを送出する。」と明示されています。ここで行われるのは NAT（アドレス変換）です。
3. NAT では、Webサーバ側から見る送信元が LB になるように書き換えます。図1より LB の IP アドレスは「172.16.10.5」です。したがって a＝「172.16.10.5」となります。
4. 送信先は選択された Webサーバ 2 のアドレスに変更されます。同図より Webサーバ 2 の IP アドレスは「172.16.10.12」です。したがって b＝「172.16.10.12」となります。
5. まとめると、 a：172.16.10.5
   b：172.16.10.12

誤りやすいポイント

• Webサーバが“クライアント PC の IP アドレス”を直接受け取ると勘違いし、aを PC 側のアドレスと誤記する。NAT で送信元は LB に書き換えられる点を見落としやすいです。
• 図1の IP アドレスを読み違え、Webサーバ 1（172.16.10.11）や Webサーバ 3（172.16.10.13）を bにしてしまう。設問は「Webサーバ 2 が選択された場合」と限定しています。
• 「ヘルスチェック結果が良好なので LB はアドレスを書き換えない」と早合点する。ヘルスチェックの有無にかかわらず、負荷分散方式が NAT であれば常に書き換えは行われます。

FAQ

解答の論理構成

1. 【問題文】には、表1の項番3として
   「PCでcコマンドを用いた、社内DNSサーバの名前解決テストの結果は良好か。」
   と記載されています。
2. “名前解決テスト”と明示されていることから、cは DNS レコードを問い合わせるためのコマンドでなければなりません。
3. 一般的にクライアント PC から DNS 名の解決を確認する代表的なコマンドは
   ・「nslookup」
   ・「dig」
   の 2 つです。
4. いずれも DNS サーバへの直接問い合わせを行い、応答内容を表示して名前解決の可否を判定できます。
5. よって、c に入る適切な字句は「nslookup 又は dig」です。

誤りやすいポイント

• ping や traceroute は IP 到達性や経路状態の確認用であり、DNS 名の正引き・逆引きを直接確認するものではありません。
• “host” コマンドも名前解決に使えますが、試験で代表格として採り上げられるのは「nslookup」か「dig」です。
• DHCP 関連コマンド（ipconfig /renew など）と混同しがちですが、これは IP アドレスの再取得であり DNS とは別用途です。

FAQ

解答の論理構成

1. 項番4の確認結果
   • 【問題文】「Webブラウザにエラーが表示されたときのWebサーバとPC間におけるHTTP通信メッセージそのものが存在しなかった。」
   • HTTPリクエスト自体が Webサーバ側で処理されていないため、原因は Webサーバより“後段”にあると推定できます。
2. 項番6の確認結果
   • 【問題文】「WebサーバからDBサーバへのアクセスエラーメッセージ、及びTCPポートが確保できないという内容のエラーメッセージがあった。」
   • Webサーバは DB サーバと通信しようとして失敗していることが明示されています。
3. 上記 1・2 から導ける事象
   • PC→LB→Webサーバ間の通信は正常（項番1～3）。
   • Webサーバは PC からの要求を受け取るものの、DB サーバへ接続できず処理が完了しない。
   • その結果、HTTP応答がクライアントに返せず「タイムアウト」となる（下線①）。
4. よって下線①で問われる「具体的にどのような不具合か」は、
   • Webサーバが DB サーバへ接続する段階でエラーが発生している、という一点に集約されます。

誤りやすいポイント

• HTTPタイムアウトを「PC と Webサーバ間の通信障害」と短絡する
• 「TCPポートが確保できない」というログから LB や OS のポート枯渇と結び付け、DB との接続失敗を見落とす
• 「販売管理機能のバージョンアップ」を直接的なバグ要因と決めつけてネットワーク層の調査を省略する

FAQ

解答の論理構成

1. 問題文では、調査結果として「Webサーバ1～3で利用可能なTCPポートが一時的に枯渇する事象が発生」と明記されています。この時点で対策は“ポートを確保する”方向に向かうと分かります。
2. 具体的な改善策として、本文に「②Webサーバ1～3でのTCPコネクションが閉じるまでの猶予状態であるTIME_WAIT状態のタイムアウト値の短縮」とあります。
3. TIME_WAIT が長いままだと同一ポートを再利用できず、枯渇が続きます。タイムアウトを短縮すると同ポートが早くリサイクルされ、利用可能ポート数が増えます。
4. したがって、②の効果は「Webサーバ1〜3で再利用できる TCP ポート数を増やせること」と結論づけられ、模範解答と一致します。

誤りやすいポイント

• TIME_WAIT を「接続待ち」と誤解し、待ち時間を短くすると通信が不安定になると勘違いする。実際は“コネクション終了後の保護期間”であり、短縮しても通常の通信には影響しにくいです。
• 枯渇しているのはサーバ側ポートであり、クライアント（PC）側ポートではない点を見落とす。
• 「TCPポート数の増加」と「同時アクセス数の増加」を混同し、同時接続設定を変更しようとしてしまう。

FAQ

解答の論理構成

1. 問題文には、切分け作業の問題点として
   「③Webサーバ1～3やL3SW,LBのそれぞれに記録されたログメッセージの対応関係の特定を推測に頼らざるを得ず難しかった」
   とあります。複数機器のログ時刻がずれていると、同一事象を示すエントリを関連付けるのが困難になります。
2. この課題を解決するには、各機器のログに記録される“時刻”をそろえ、同一タイムスタンプを基準に突き合わせられるようにすることが有効です。
3. 解答群を見ると、時刻を同期する仕組みを提供するものは「ア：NTPによる時刻同期機能を導入する。」しかありません。NTP(Network Time Protocol)はネットワーク機器やサーバのシステムクロックを統一し、ログの時系列整合性を確保する典型的な手段です。
4. よって、適切な解決方法は「ア」となります。

誤りやすいポイント

• 「イ：ウイルス対策ソフト」はセキュリティ向上が目的であり、ログの時刻不一致を直接解決しない点を見落としやすいです。
• 「ウ：各機器で取得したログファイルを個々に確認する。」は現状と同じ手作業を続けるだけで、根本的解決策ではありません。
• 「エ：各機器のデバッグログも表示されるようにする。」はログ量を増やすだけで、時系列の整合性課題を悪化させる可能性があります。

FAQ

解答の論理構成

• 【問題文】の〔LBによる Webサーバの負荷分散の動作〕では、ロードバランサが実パケットを書き換えることが明示されています。
  引用：「LBは…パケットの送信元のIPアドレスをa、送信先のIPアドレスをbに置き換えてパケットを送出する。」
  ― ここで送信元 IP が置き換えられるため、Webサーバ側には元々の PC の IP ではなく LB の IP が記録されます。
• 本文中の下線④は「送信元のPCがすぐに特定できなかった」と述べています。なぜ特定できないのかを考えると、Webサーバに残るログに PC の IP が残らないことが直接原因です。
• したがって、解答は「送信元のIPアドレスはLBのものになるから」となります。

誤りやすいポイント

• ファイアウォールで NAT が行われていると誤解し、FW の IP が記録されると考えてしまう。実際に送信元を書き換えているのは LB です。
• ロギング設定が不十分で PC が特定できないと誤答するケース。設定以前に IP 変換という構造的理由があります。
• Syslog など集中管理で解決できると短絡的に判断し、根本原因（送信元 IP の書き換え）を見落とす。

FAQ