◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください

【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました
生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!!
https://tech-lab.connpass.com/event/315703/

こんにちは。技術部の髙岡です。
以前、L7ロードバランサーのAzure Application Gatewayに関するブログを書きましたが、L4ロードバランサーのAzure Load Balancerを検証する機会がありました。
Azure Application Gatewayとの違いを意識して、Azure Load Balancerの挙動を検証してわかったことを説明します。

1 両者の比較
2 検証環境の構成と構築
3 ロードバランサーの本質的な機能の確認

両者の比較

比較項目	Azure Load Balancer	Azure Application Gateway
NAT	DNATのみ	SNATとDNAT
負荷分散、セッションアフィニティの元ネタ	既定では5種類のハッシュ・ソース IP ・接続元ポート・接続先 IP ・接続先ポート・プロトコル	cookie
SSLオフロード	不可能 ※L4なので	可能
ポータルGUIでの初期構築	可能	可能
仮想マシンの可用性セット	必要	不要
課金	無償版と有償版あり	有償版のみ

NATについての補足
Azure Load BalancerはDNATのみでSNATしないので、負荷分散対象の仮想マシンには、ソースIPがクライアントIPのままで接続します。したがって、Azureのセキュリティグループでインターネット側からHTTPやHTTPSの接続許可が必要です。
一方、Azure Application GatewayはSNATするので、インターネット側からの接続許可は不要です。

Azure Load Balancerが向いてるケース

無償がいい。
セッションアフィニティはバックエンドシステム側で行うため、ロードバランサー側では不要である。

Azure Application Gatewayが向いているケース

クライアントのソースIPが単一IPにNATされるので、複数クライアントからの接続でもソースIPがバックエンドのサーバからは単一のクライアントと見えてしまい、ソースIPでクライアントを識別することができない。したがって、負荷分散やセッションアフィニティは、ソースIPでなくcookieベースとする必要がある。
SSLオフロードが必要である。

検証環境の構成と構築

検証環境の構成図です。

Azure Load BalancerはSSLオフロードしないので、Azure Application Gatewayと異なり、ロードバランサーでの証明書の設定が不要です。
Azure Load Balancerはコマンドでも構築できますが、AzureポータルからGUIで作成することも可能です。Azure Application Gatewayの場合は作成コマンドが完了するまで20分程かかりましたが、Azure Load Balancerの場合は、GUIで作成ボタンを押してから作成完了するまで1分もかかりませんでした。

その他の細かい構築手順の説明は割愛します。マイクロソフトが公開している手順が参考になります。

https://docs.microsoft.com/ja-jp/azure/load-balancer/

Azure Load Balancerを構築する前に実施しておくべき作業を書いておきます。

- バックエンドのWebサーバにhttps接続環境作成

今回はApacheを導入しました。

- Webサーバ用の秘密鍵とサーバ証明書作成

今回はApacheを使うので、pem形式で作成しました。

構築に関する補足事項を書いておきます。

- DNSサーバにロードバランサーのCNAMEを登録する必要がある。

Azure Load Balancerのフロントエンド側には、Public IPが割り当てられています。
FQDNのホスト名は指定できるものの、FQDNのドメイン部分は修正することができません。IPアドレスもデフォルトでは可変です。

検証環境での例

IPアドレス：40.74.70.107
FQDN：lb-takaoka-pub.japanwest.cloudapp.azure.com

このFQDNは、ユーザに提供するURLとしては不適切なので、実運用を考慮すると、適切な名称を決めてDNSにCNAMEレコードを登録する必要があります。
今回の検証では、ユーザ向けのURLとして、

https://websvlb.siostest02.com/index.html

を使うことにしましたので、「lb-takaoka-pub.japanwest.cloudapp.azure.com」のCNAMEとして、「websvlb.siostest02.com」をDNSに登録しました

尚、Public IPを固定IPとして設定することもできます。
その場合は、DNSにCNAMEでなく、固定IPとFQDNをセットにしたAレコードを登録することによって、ユーザ向けのURLを構成することが可能です。

バックエンドの仮想マシンは可用性セットが必要
バックエンドの仮想マシンは可用性セットで構成されている必要があります。
尚、Azure Application Gatewayの場合は、可用性セットは不要です。

ロードバランサーの本質的な機能の確認

ロードバランサーの本質的な機能であるNATを、Azure Application Gatewayの検証時と同様にパケットキャプチャで確認してみました。

NATの確認
このようなフローでパケットが流れていくと想定しています。

戻りの経路（赤線）に着目してください。
Azure Application GatewayのようにSNATしないので、戻り時にはロードバランサーを経由しません。

クライアントとWebサーバ側でパケットキャプチャを取得してNATされているかを確認します。

クライアントからcurlコマンド実行
# curl --verbose https://websvlb.siostest02.com/index.html --cacert ./websvapgw.crt

websvlb01側に配置したhtmlコンテンツが表示されましたので、websvlb01側に振られたことがわかります。

クライアント側のパケットキャプチャ

Sourceが「192.168.10.154:40174（クライアント）」Destinationが「40.74.70.107:443（Load Balancerのフロントエンド側）」でパケットを送信し、戻りは逆であることがわかります。

websvlb01側のパケットキャプチャ
# tcpdump -nn port not 22 and not udp and port 443 and not host 168.63.129.16

Sourceが「126.235.235.217:46095」Destinationが「10.10.0.6:443（websvlb01）」で、ロードバランサーがDNATしたパケットをwebsvlb01が受信しており、戻りは逆であることがわかります。
※本当はSourceが「192.168.10.154:40174」である方が、NATがDNATのみでSNATされていないことがわかりやすいのですが、検証環境でクライアントがインターネットに出る前にSNATされてしまう環境なので、このIPでキャプチャされてしまいました。