第 13 章 仮想ネットワークを実装および管理する（15〜20%）
名前解決と負荷分散
この章で学ぶこと
- Azure DNS を構成する
- 内部またはパブリックのロード バランサーを構成する
- 負荷分散のトラブルシューティングを行う
この章に出てくる用語
- Azure DNS
- ドメイン名と IP アドレスの対応表（DNS ゾーン）を預かるサービス。
www.contoso.comのような名前を引いたときに、どの IP を返すかを管理する。ドメインを購入する機能ではない点に注意。ドメインは登録事業者から取得し、その名前解決を Azure に任せる、という関係になる。 - Azure Load Balancer
- 複数のサーバーに通信を振り分けて、負荷を分散し、落ちたサーバーを自動で外す装置。 OSI の第 4 層（TCP / UDP）で動くので、判断に使えるのは IP アドレスとポートだけ。URL の中身を見て振り分けたい場合は、第 7 層の Application Gateway が担当する。
Azure DNS には用途の違う 2 種類のゾーンがある。
試験では
Azure DNS はドメインを購入する機能ではない。ドメインは登録事業者（レジストラ）から取得し、その NS レコードを Azure のネームサーバーに向けることで Azure DNS がホストする。「Azure DNS でドメインを買う」という選択肢は誤り。
プライベートゾーンと仮想ネットワークリンク
プライベートゾーンは仮想ネットワークリンクで VNet に紐付けて使う。リンクには「解決のみ」と「自動登録あり」があり、自動登録を有効にすると、その VNet の VM が自動的に A レコードとして登録される。
試験では
自動登録が有効なリンクは、1 つのゾーンにつき VNet 1 つまで。複数の VNet から同じゾーンを引きたい場合、自動登録を付けられるのは 1 つだけで、残りは解決のみのリンクになる。
レコードの制約
試験では
CNAME はゾーン頂点（apex。contoso.com そのもの）に作れない。これは Azure の制限ではなく DNS の仕様。頂点に Azure リソースを割り当てたいときはエイリアスレコードを使う。
エイリアスレコードは、パブリック IP、Traffic Manager、CDN などのAzure リソースを直接指すレコードだ。リソースが削除されると解決も自動的に止まるため、存在しない IP を指し続けるダングリング DNSを防げる。
補足
逆引き（PTR レコード）も Azure DNS でホストできる。IPv4 は in-addr.arpa、IPv6 は ip6.arpa の逆引きゾーンに置く。Azure のパブリック IP の逆引きは、パブリック IP リソースの「逆引き FQDN」の設定で行う。
# パブリックゾーンを作る （PowerShell: New-AzDnsZone）
az network dns zone create -g rg -n contoso.com
# プライベートゾーンを作る
az network private-dns zone create -g rg \
-n privatelink.blob.core.windows.net
# 自動登録ありでリンクする
az network private-dns link vnet create -g rg \
-z <ゾーン> -n link1 -v vnet1 \
--registration-enabled trueOSI 第 4 層（TCP / UDP）で負荷分散するサービスだ。IP アドレスとポートで振り分ける。
試験では
Basic SKU のロードバランサーは 2025 年 9 月 30 日に廃止済み。 現行は Standard。そして Standard LB には Standard パブリック IP が必要で、Basic と Standard を混在させることはできない。
試験では
URL のパスやホスト名で振り分けることはできない。 それは第 7 層の Application Gateway の仕事。「/images は別のサーバー群へ」という要件が出たらロードバランサーでは解けない。
パブリックと内部
| 種類 | フロントエンド | こう聞かれたら選ぶ |
|---|---|---|
| パブリックロードバランサー | パブリック IP | インターネットからの受信を分散する |
| 内部ロードバランサー（ILB） | プライベート IP | 社内アプリの三層構成で Web 層から App 層へ分散する |
4 つの構成要素
| 要素 | 役割 |
|---|---|
| フロントエンド IP 構成 | ロードバランサーが受け付ける IP アドレス |
| バックエンドプール | 振り分け先の VM / VMSS の集まり（IP ベースと NIC ベースが選べる） |
| 負荷分散規則 | フロントエンドのポートをバックエンドのポートへ対応付ける |
| 正常性プローブ | バックエンドが応答するかを定期的に確認する（TCP / HTTP / HTTPS） |
試験では
「なぜか 1 台だけトラフィックが来ない」→ まず正常性プローブを疑う。プローブが失敗しているインスタンスにはトラフィックが送られない。プローブのポートが閉じている、NSG で AzureLoadBalancer を拒否している、アプリが応答していない、といった原因を順に見る。
負荷分散規則とインバウンド NAT 規則
試験では
インバウンド NAT 規則は負荷分散ではなく 1 対 1 の転送。「バックエンドの個別の VM に RDP / SSH したい」という要件はこれで満たす。負荷分散規則では特定の 1 台を指定できない。
そのほかの設定
- セッション永続化（分散モード） ―― 既定は 5 タプルのハッシュ。「同じクライアントを同じサーバーに固定したい」なら送信元 IP ベースに変更する
- HA ポート ―― すべてのポートを一括で負荷分散する規則。NVA の冗長化に使う。Standard の内部ロードバランサー限定
- 送信規則 ―― Standard ロードバランサーで送信 NAT を明示的に構成する
補足
Standard Load Balancer の SLA は 99.99%。可用性ゾーンにも対応していて、ゾーン冗長にもゾーン指定にもできる。また既定でセキュリティ保護されており、NSG で許可しない限り受信は閉じている。
# ロードバランサーを作る （PowerShell: New-AzLoadBalancer）
az network lb create -g rg -n lb1 --sku Standard \
--public-ip-address pip1
# 正常性プローブを作る
az network lb probe create -g rg --lb-name lb1 \
-n probe-http --protocol Http \
--port 80 --path /health
# 負荷分散規則を作る
az network lb rule create -g rg --lb-name lb1 \
-n rule-http --protocol Tcp \
--frontend-port 80 --backend-port 80 \
--probe-name probe-httpこの章のまとめ
- Azure DNS でドメインを購入できるか
- プライベートゾーンを VNet に紐付ける設定
- 自動登録が有効なリンクを張れる VNet の数
- ゾーン頂点に CNAME を作れるか
- ダングリング DNS を防ぐレコード
- Basic ロードバランサーの廃止日