【ネットワークスペシャリスト試験令和4年度春期午後2 問2 No.5】

ネットワークスペシャリスト試験令和4年度春期午後2 問2

【出典：ネットワークスペシャリスト試験令和4年度春期午後2 問2（一部、加工あり）】

[移行手順の検討]
Rさんは、コンテナ仮想化技術を利用したWebAPの移行手順を検討した。
2台のAPサーバで構成するAP0を、WebAPコンテナ（AP0a）とWebAPコンテナ（AP0b）へ移行することを例として、WebAPの移行途中の構成を図5に、WebAPの移行手順を表6に示す。

Rさんは表6のWebAPの移行手順をO課長に報告した。次は、WebAPの移行手順に関する、O課長とRさんの会話である。

O課長：今回の移行はAPサーバとWebAPコンテナを並行稼働させてDNSレコードの書換えによって切り替えるのだね。

Rさん：そうです。同じ動作をするので、DNSレコードの書換えが反映されるまでの並行稼働期間中、APサーバとWebAPコンテナ、どちらにアクセスが行われても問題ありません。

O課長：分かりました。並行稼働期間を短くするためにDNS切替えの事前準備は何があるかな。

Rさん：はい。⑪あらかじめ、DNSのTTLを短くしておく方が良いですね。

O課長：そうですね。移行手順に記載をお願いします。

Rさん：分かりました。

O課長：動作確認はどのようなことを行うか詳しく教えてください。

Rさん：はい。WebAPコンテナ2台で構成する場合は、⑫次の3パターンそれぞれでAPの動作確認を行います。一つ目は、全てのWebAPコンテナが正常に動作している場合、二つ目は、2台のうち1台目だけWebAPコンテナが停止している場合、最後は、2台目だけWebAPコンテナが停止している場合です。また、障害検知の結果から、正しく監視登録されたことの確認も行います。

O課長：分かりました。良さそうですね。

APを、仮想化技術を利用したコンテナサーバやホストサーバに移行することによって期待どおりにサーバの台数を減らせる目処が立ち、システム開発部では仮想化技術の導入プロジェクトを開始した。

下線⑨について、WebAPコンテナで動作するAPの動作確認を行うために必要になる、テスト用のPCの設定内容を、DNS切替えに着目して40字以内で述べよ。：APのFQDNとIPアドレスをPCのhostsファイルに記載する。

「⑨テスト用のPCを用いて動作確認を行う。」
DNS切替えに着目とあるように、表6の移行手順を見ると動作確認（項番4）の後にDNS切替え（項番5）が行われるため、テスト用PCからWebAPコンテナへアクセスするためのDNS（名前解決）について工夫が必要となるようです。
WebAPコンテナでの動作について確認するために、[コンテナ仮想化技術を利用したWebAPの構成]を参照すると、「WebAPコンテナには、APごとに一つのFQDNを割り当て、コンテンツDNSサーバに登録する。」「WebAPコンテナでは、APの可用性を確保するために、共用リバースプロキシを新たに構築して利用する。共用リバースプロキシは負荷分散機能をもつHTTPリバースプロキシとして動作し、クライアントからのHTTPリクエストを受け、④ヘッダフィールド情報からWebAPを識別し、WebAPが動作するWebAPコンテナへHTTPリクエストを振り分ける。」などとあります。
これらの記述から、クライアントからWebAPコンテナへのアクセスは、FQDNで共用リバースプロキシにHTTPリクエストを送信する動作となることが分かります。
通常であれば、クライアントから共用リバースプロキシへの通信は、DNSサーバで指定されたコンテンツDNSサーバの登録内容に従いますが、上記のとおり、まだDNS切替えが行われていないため、コンテンツDNSサーバは利用できません。
したがって、テスト用PCの内部で名前解決する仕組みとしてhostsファイルを利用します。
hostsファイルでAPのFQDNと共用リバースプロキシのIPアドレスを登録することで、テスト用PCから共用リバースプロキシへの通信が行え、（項番2で共用リバースプロキシの設定は完了しているため）WebAPコンテナへ通信を振り分けることができます。

下線⑩について、APサーバ停止前に確認する内容を40字以内で述べよ。：APサーバに対するPCからのアクセスがなくなっていることを確認する。

「⑩停止して問題ないことを確認した後にAPサーバを停止する。」
表6の移行手順の項番4までで、新しいWebAPコンテナでの稼働が問題ないことを確認できています。
あとは、PCからのアクセスをAPサーバからWebAPコンテナへ切り替えればいいでしょう。
項番5のDNS切替えで、PCからの名前解決要求にはWebAPコンテナが応答されることになりますが、PCで名前解決の情報を保持する時間を考慮する必要があります。
その後の記述に、「同じ動作をするので、DNSレコードの書換えが反映されるまでの並行稼働期間中、APサーバとWebAPコンテナ、どちらにアクセスが行われても問題ありません。」とあるように、新しいDNSレコードの書き換えが反映されるまでには、APサーバへのアクセスが残っています。
そこで、APサーバを停止する前に、実際にPCからのアクセスがなくなっていることを確認することが必要になります。

下線⑪について、TTLを短くすることによって何がどのように変化するか。40字以内で述べよ。：キャッシュDNSサーバのDNSキャッシュを保持する時間が短くなる。

「⑪あらかじめ、DNSのTTLを短くしておく方が良いですね。」
前の設問からの続きで、「並行稼働期間を短くするためにDNS切替えの事前準備は何があるかな。」、つまり、APサーバからWebAPコンテナへの移行が早く終わるためにTTLを短くするということです。
TTL（Time To Live）はDNSのレコード情報をキャッシュする時間のことで、キャッシュDNSサーバでレコード情報を取得してからTTLの時間は新たにコンテンツサーバに問い合わせを行いません。
逆に、TTLを短くすることで、キャッシュDNSサーバのDNSレコード情報を保持する時間が短くなり、コンテンツサーバの新しい情報をすぐに反映することができます。

下線⑫について、3パターンそれぞれでAPの動作確認を行う目的を二つ挙げ、それぞれ35字以内で述べよ。：WebAPコンテナ2台が正しく構築されたことを確認するため/共用リバースプロキシの設定が正しく行われたことを確認するため

「WebAPコンテナ2台で構成する場合は、⑫次の3パターンそれぞれでAPの動作確認を行います。」
まず、動作確認は表6の項番4であり、それまでの移行手順である項番1〜3の内容を確認するということです。
項番1（WebAPコンテナの構築）、項番2（共用リバースプロキシの設定）、項番3（WebAPコンテナ監視登録）とありますが、3パターンの記述の後に「また、障害検知の結果から、正しく監視登録されたことの確認も行います。」とあり、これは明らかに項番3の動作確認です。
したがって残りの項番1、項番2が3パターンで行う動作確認になります。
3パターンそれぞれでAPの動作確認を行う目的というと、少し構えてしまいますが、単純に回答すればいいのでしょう。