初めに
Azureが扱っているロードバランサーは以下の2種類があります。
- Azure Load Balancer：レイヤー4(OSI)ロードバランサー
- Application Gateway：レイヤー7(OSI)ロードバランサー
今回はAzure Load Balancerについて、紹介しようと思います。
Azure Load Balancerとは
Azure Load Balancerは、複数の仮想マシン間でトラフィックを分散するために使用できるサービスです。
Azure Load Balancerを使用すると、複数の仮想マシンまたは他のサービスにユーザー要求(リクエスト)を分散できます。
仮想サーバーに障害が発生した場合には、ロードバランサーによってトラフィックが自動的にルーティングされるため、回復性も向上します。Document
上記公式ドキュメントの内容から、Azure Load Balancerは以下ことができます。
- アクセスのトラフィックの負荷分散
- 障害発生時、トラフィックの自動ルーティング(リクエストを障害していないサーバーにルーティングする)
可用性セットと可用性ゾーン
Azure Load Balancerの特徴をご紹介する前に、まずAzureの高可用性を実現するための概念をご紹介しようと思います。
Azureの障害分離のレベルは以下の3種類があります。
- 可用性セット
- 可用性ゾーン
- リージョン
リージョンはリソースが作成される地域のことで、例えば日本を例とすると、東日本と西日本のリージョンがあります。
Azureリソースはどのリージョンに作成するかは指定可能です。
リージョンの障害対応は主に大規模の災害で、リージョン全体が機能しなくなる時に考える必要があります。いわゆる「災害対策」です。
災害対策はロードバランサーとは関係薄いので、リージョンの紹介はこのぐらいにしておきます。
可用性セットとは
可用性セットは、デプロイされる仮想マシン リソースを相互に分離するために使う論理的なグループです。Azureでは、可用性セット内に配置された仮想マシンは、複数の物理サーバー、コンピューティング ラック、ストレージ ユニット、およびネットワーク スイッチで実行されることが保証されます。Document
公式ドキュメントで書いた内容は少し複雑に見えるので、簡単に説明すると：
- Azureの仮想マシンはマイクロソフトのデータセンターにある物理のサーバー上で動いています。
- 物理のサーバー(とサーバラックなどの物理機械)が障害した場合、その物理のサーバ上の仮想マシンも障害になってしまいます。
- 同じ可用性セットにある仮想マシンは、違う物理サーバーやラックに関連する一連の物理環境(障害ドメイン)に配置するようになる
- 違う物理サーバー(またはラック)に配置されると理解してもいいです。
公式ドキュメントの図に合わせて理解していただければと思います。
可用性ゾーンとは
可用性ゾーンにより、独立した電源、冷却手段、ネットワークを備えた1つまたは複数のデータセンターのグループが提供されます。可用性ゾーン内の仮想マシンは、同じリージョン内の異なる物理的な場所に配置されます。Document
Azureのリージョン内には複数のデータセンターがあります。
可用性ゾーンはそのうちの一つのデータセンター施設だと理解して頂ければ問題ありません。
※ 現時点すべての仮想マシンサイズやリージョンが、可用性ゾーンを対応している訳ではないので、利用する前に確認したほうが無難です。
ここも公式ドキュメントの図をお借りします。イメージがしやすいと思います。
Azure Load Balancerの機能
さて、概念の紹介は終わったので、Azure Load Balancerの機能を説明していきます。
Azure Load Balancerは以下の2種類のskuがあります。
- Basic
- Standard
Basicは以下の機能が使用できます。
- ポート フォワーディング：ポートの転送(8080ポートで通信を受けて、ロードバランサー後ろの仮想マシンに80ポートで送信するとか)
- 自動再構成：
- 正常性プローブ：死活監視
- 送信元ネットワーク アドレス変換(SNAT)による送信接続
- 公開ロード バランサーでの Azure Log Analytics による診断
※ Basicは可用性セットでのみ使用可能
StandardはBasicの機能以外、下記の機能も使えます。
- HTTPS 正常性プローブ(Httpsリクエストで正常性を確認する)
- 可用性ゾーン
- 多次元メトリックに関する Azure Monitor による診断
- 高可用性 (HA) ポート
- アウトバウンド規則
- 保証されたSLA(2台以上の仮想マシンの場合は99.99%)
内部ロードバランサーと外部ロードバランサー
Azureロードバランサーと紐づくIPアドレスの種類によって、以下に分類できます。
- 内部ロードバランサー：ロードバランサーはプライベートIPアドレス使用する
- インターネットからアクセスできない
- 仮想ネットワークに属す(プライベートIP使用しているため)
- 外部ロードバランサー：ロードバランサーはパブリックIPアドレスを使用する
- インターネットからのアクセスが可能
- AzureパブリックIPの作成が必要
分散モード
Azure Load Balancerは分散モードの指定が可能です。
分散モードとは、ロードバランサーがトラフィックをどう分散するかのことです。
分散モードは以下の種類があります。
- 5タプル ハッシュ(デフォルト、セッション永続化:なし)
- 接続元IPアフィニティ(セッション永続化)
5タプル ハッシュ
5タプル ハッシュ(five-tuple hash)は、Load Balancer の既定の分散モードです。
この分散モードでは、ネットワーク トラフィックが複数の仮想マシン インスタンス間で均等に分散されます。
仕組みとしては、以下の5つの情報が同じ場合(hash値が同じ)、同じ仮想マシン インスタンスに振り分けされます。
- ソース IP
- ソース ポート
- 宛先 IP
- 宛先ポート
- プロトコルの種類
※ 基本的に、ソースポート(クライアントのランダムポート)はセッションごとに異なるため、セッションごとに違う値になります。
参考イメージ図(公式)：
接続元 IP アフィニティ
この分散モードは、「セッション アフィニティ」または「クライアントIPアフィニティ」とも呼ばれます。
この分散モードでは、2 タプル (ソースIP と接続先IP) または 3タプル (ソースIP、接続先IP、プロトコル)のハッシュを使用して、使用可能な仮想マシンにトラフィックをマップします。
その結果、同じクライアントからのアクセスは、ロード バランサーの背後にある同じ仮想マシンに、常に確実に送信されます。
この分散モードは、ステートフルなシステムによく使用されます。
ここで、例で説明します。
ロードバランサーでトラフィックを2台のWEBサーバ(AとB)に分散しているとします。WEBサーバはログイン状態を保持可能です。
同じクライアントから、このシステムにアクセスし、最初はAサーバにアクセスし、ログインしたとします。
ログインして、ブラウザをリフレッシュすると、Bサーバに割り振られたら(5タプル ハッシュの場合)、未ログインの状態になってしまいます(Bサーバはまだログインの状態になっていない)。
※ログイン状態がステートフルと言えます。
このようなことを防ぐために、セッション アフィニティが使用されます。
参考イメージ図(公式)：
クライアントIPアフィニティの設定が必須なユースケース
- 「リモート デスクトップ ゲートウェイ」の先頭にあるAzure Load Balancer
- メディアのアップロードするサービスの先頭にあるAzure Load Balancer
- TCPでセッション開始し、UDPでファイルを転送するため、セッションもプロトコルも違う
- 5タプル ハッシュにすると、TCP 接続と UDP 接続がロード バランサーによって異なる接続先 IP アドレスに送信される可能性があり、アップロードが正常に完了できない
※ リモート デスクトップ ゲートウェイは、インターネット上のクライアントからプライベート ネットワーク上のリモート デスクトップ サーバーに対して、ファイアウォール経由でリモート デスクトップ プロトコル (RDP) 接続が行えるようにするために使用できる Windows サービスです。
Azure Load Balancerの作成
上記内容で、Azure Load Balancerを構築するための知識は備わっているかと思います。
実際の構築手順は公式ドキュメント に丁寧に書かれていますので、参考していただければと思います。
ざっと以下のような流れになります。
- Azure Load Balancerの作成
- ロードバランサーのバックエンド プールの作成
- バックエンド プール：ロードバランサー背後に配置する仮想マシン群
- 正常性プローブの作成
- ロード バランサー規則の作成
その他の機能
【2021/03/26追記】
高可用性(HA) ポート
高可用性(HA) ポートとは、負荷分散規則の一種であり、内部 Standard Load Balancer の すべてのポートに到着する すべてのフローの負荷分散を簡単に行う方法を提供
構成方法：フロントエンド ポートとバックエンド ポートを 0 に、プロトコルを すべて に設定すると構成される
-
前提条件
- 内部(internal) Load balancer のみ利用可能
- Standard SKU が必要
- 5 タプル接続 に基づく
-
使用シナリオ
- 仮想ネットワーク内のネットワーク仮想アプライアンス (NVA) の高可用性と拡張性するための負荷分散
- 多数のポートの負荷分散が必要なアプリケーション
仮想ネットワーク内のネットワーク仮想アプライアンス (NVA) シナリオの構成例(公式資料図)
最後に
今回はAzureのレイヤー4(OSI)の負荷分散サービス Azure Load Balancerについてご紹介しました。
主に負荷分散と回復性のために使用されますが、多くのシステムとしては大事な役割を担っています。
次回は同じAzureの負荷分散サービスのもう一つ、レイヤー7(OSI)の負荷分散サービス Application Gatewayについてご紹介する予定です。
両方の特徴を把握した上で、システムにどの負荷分散サービスを使ったほうがいいかを判断できるようにしましょう。
ここまで読んで頂いて、お疲れ様でした。
コメント