自由気ままに書いちゃおう

好きなことをつらつらと・・・

【Azure】AzureLoadBalancer(パブリック)の初歩的なことをまとめてみた

今回は、AzureLoadBalancer(パブリック)についてです。

■はじめに

本記事内の「LB」という単語は、「AzureLoadBalancer」のことです。
LBとAzureLoadBalancerという単語が混在していますが、どちらも同じことを意味しております。

■AzureLoadBalancerの種類とネットワーク構成について

AzureLoadBalancerには
「パブリック」
「内部」
という2つの種類が存在します。

f:id:guri2o1667:20220113142603p:plain


本記事は「パブリック」を選択した時の記事です。
そのため、インターネットからの接続を想定した構成となります。(詳細は後述)
「パブリック」と「内部」を利用したネットワーク構成は以下のようなものが一般的です。
※「パブリック」「内部」の両方を常に使わなくてはいけないわけではなく、必要に応じて片方だけを利用した構成ももちろん可能です。

f:id:guri2o1667:20220113143103p:plain

引用元:Azure Load Balancer のコンポーネント | Microsoft Docs


「内部」を選んだ時の記事は以下にあります。

www.guri2o1667.work

■AzureLoadBalancerのSKUについて

AzureLoadBalancerには
「Standard」
「Basic」
という2つのSKUが存在します。
Microsoftでは、Standardを推奨しております。

■用語:フロントエンドIPアドレスとパブリックIPアドレス

AzureLoadBalancer(パブリック)はインターネットから接続できるネットワーク構成となるため、AzureLoadBalancerにパブリックIPアドレスを割り当てる必要があります。
一方、AzureLoadBalancer(内部)の場合には、プライベートIPアドレスを割り当てます。

このように、AzureLoadBalancerに割り当てるIPアドレスのことを「フロントエンドIP」といいます。

設定画面は以下の通りです。

f:id:guri2o1667:20220113144628p:plain

フロントエンドIPにパブリックIPアドレス(PIP)を紐づける必要があります。
パブリックIPアドレスは事前に作成しておくこともできますし、
LBを設定する際にも下記の通り作成することができます。

f:id:guri2o1667:20220113144802p:plain

ただし、AzureLoadBalancer作成時にパブリックIPアドレスを新規作成する際は、SKUは自動的にAzureLoadBalancerのSKUと同じになります。
(というより、PIPのSKUとAzureLoadBalancerのSKUは揃える必要があります。)

Azure Load Balancer のコンポーネント | Microsoft Docs

■用語:バックエンドプール

LBが受信したトラフィックの転送先のことです。
バックエンドプールには、仮想マシン1台もしくは複数台(仮想マシンスケールセットを含む)を指定することができます。

設定画面は以下の通りです。

f:id:guri2o1667:20220113145007p:plain

■用語:正常性プローブ

バックエンドプール内のインスタンスの正常性を確認するためのルールのようなものです。

負荷分散規則(後述)で利用します。
もし、ルールから違反しているインスタンスがあった場合には、LBの受信トラフィックは異常インスタンスには転送されなくなります。

正常性プローブの設定画面は以下の通りです。

f:id:guri2o1667:20220113153447p:plain


プロトコルにTCP/HTTP/HTTPSが選択できます。
※HTTPSはStandardLoadBalancerのみで利用可能

f:id:guri2o1667:20220113153521p:plain

■用語:インバウンド規則

インバウンド規則とは、
LBに到達した受信トラフィックをどのようにバックエンドプールに転送するかのルールのことです。
例えば、
「LBが8080/tcpで受信したトラフィックを、バックエンドプールの80/tcpに転送する」
と言った感じになります。

このインバウンド規則ですが、2つ存在します。
① インバウンドNAT規則
② 負荷分散規則

①と②の違いや使い分けについては後述いたします。
今は、インバウンド規則には2種類あるんだなって思っていただければと。

■用語:① インバウンドNAT規則

設定画面は以下の通りです。

f:id:guri2o1667:20220113150049p:plain

設定画面を見るとイメージがつきやすいと思いますが、
「LBが8080/tcpで受信したトラフィックを、バックエンドプールの80/tcpに転送する」ような設定ができます。

注意点が2つあります。
1点目は「ポートマッピング」で「規定」を選んだ場合、LBが受信するポート番号と同じになります。
そのため、「LBが8080/tcpで受信したトラフィックを、バックエンドプールの8080/tcpに転送する」といった具合になります。
バックエンドプールの受信ポートを変更したい場合には「カスタム」を選択し、「ターゲットポート」にポート番号を入力します。

2点目は、LBの受信トラフィックは指定したターゲット仮想マシン(もしくは仮想マシンのNIC)に転送されます。

■用語:② 負荷分散規則

負荷分散規則の場合、
バックエンドプールに指定されたインスタンス全台がLBで受信したトラフィックの転送先対象です。
例えばバックエンドプールとしてサーバが3台(A、B、Cとする)あり、CだけはLBの受信トラフィック転送先から除外したい、のようなことはできません。
その場合には、最初からバックエンドプールにA、Bの2台だけを設定しておく必要があります。

負荷分散規則は複数の要素を組み合わせて構成されます。
負荷分散規則=フロントエンドIP+バックエンドプール+正常性プローブ
です。

f:id:guri2o1667:20220113161529p:plain

■負荷分散規則とインバウンドNAT規則の使い分けについて

負荷分散規則とインバウンドNAT規則の大きな違いは冗長性と負荷分散の有無です。

インバウンドNAT規則は特定の仮想マシンへのポート転送になるので、冗長性や負荷分散がそもそも存在しないです。
また、インバウンドNAT規則は言い換えるとポート転送なので、例えば「仮想マシンにパブリックIPアドレスが付与されていないけど、インターネットからRDP接続したい」ような場合には、「LBの受信トラフィックを仮想マシンの3389/tcpに転送」すればよいことになります。

尚、負荷分散規則で使っているルール(ポート)とインバウンドNAT規則で利用しているルール(ポート)はバッティングNGです。
※同じポートを利用しようとすると、そもそも警告が出るため設定すらできません。

■バックエンドプールのアクセス制御(NSG)について

説明しやすいようにここでは、バックエンドプールには1台の仮想マシンが指定されているものとします。
また、仮想マシンにはNSGが紐づいているとします。

仮想マシンのNSGには、仮想マシンで受け付けているポート番号に対して許可設定を明示的に行う必要があります。
例えば、
「LBが8080/tcpで受信したトラフィックを、バックエンドプールの80/tcpに転送する」
と言った場合には、
NSGの受信セキュリティ規則にて仮想マシンで80/tcpの通信を許可する必要があります。

この場合、受信セキュリティ規則の「ソース」はAzureLoadBalancerではなく、接続元のクライアントになります。
NSGの受信セキュリティ規則のデフォルトルールには「AllowAzureLoadBalancerInBound、優先度65001」がありますが、これは仮想マシンの受信ポートへの通信制御とは無関係のものです。


以上です。