Load Balancer - 負荷分散手法を比較してみよう
こんにちは。
先日 AZ-104 に合格したのですが、勉強をしている中でいくつか調べてみたいことが出たので調べてまとめてみようという趣旨の記事です。
今回は Azure Load Balancer がどのように負荷を分散しているのか、そしてその特性についていろいろ調べてみました。
Azure Load Balancer って?
そもそも Azure Load Balancer はどういうものなのか、 Microsoft Docs を確認してみます。
Azure Load Balancer は、受信ネットワーク トラフィックをバックエンド仮想マシン (VM) または仮想マシン スケール セット (VMSS) に分散するクラウド サービスです。
引用: https://learn.microsoft.com/ja-jp/azure/load-balancer/load-balancer-overview
なるほど。ざっくりいうと、レイヤー 4 ではたらくもので、任意のポート番号とプロトコル (TCP または UDP) を振り分けの条件に使用していくつかの VM に負荷を分散してくれるサービスです。
この負荷分散で使われるアルゴリズムは、字面そのまま「負荷分散アルゴリズム」と呼ばれ、以下のようなものになっています。
既定では、Azure Load Balancer は 5 タプル ハッシュを使用します。
5 タプルには次が含まれます。
- ソース IP アドレス
- ソース ポート
- 宛先 IP アドレス
- 宛先ポート
- 使用可能なサーバーにフローをマップするための IP プロトコル番号
引用: https://learn.microsoft.com/ja-jp/azure/load-balancer/concepts
このように、5 つの要素を組み合わせてどのマシンに分散させるかを決めているんですね。IP アドレスを動的に割り当てていると、新しいセッションが開始されたときにソース ポートが変化するために分散先が変わってしまう場合があります。そのため、必要に応じてセッション永続化の設定を使用します。
参考: https://learn.microsoft.com/ja-jp/azure/well-architected/service-guides/azure-load-balancer?toc=%2Fazure%2Fload-balancer%2Ftoc.json
また、ラウンド ロビン方式を採用するには Application Gateway や Azure Front Door を用いる必要があります。
5 タプル ハッシュ?ラウンド ロビン方式?いろいろな負荷分散方法がありそう🤨 むむむ...
整理のため、それぞれどういった手法でどういった特徴があるのかを比較してみましょう!今回は、ぴったりの論文を見つけたので読んでまとめてみました。
今回読む論文
今回はこちらの論文を読んでいきます。
Mukesh Kumar Dangi, Manju Mandot (2024). Performance Analysis of Load Balancing
Techniques in Cloud Computing Environment: A Focus on Azure. Library Progress International, 44(3), 23043-23048.
この論文は、以下の 4 つの ロード バランシング 方式を比較しています。それぞれ、簡単に言うと次のようなアルゴリズムです。
- Round Robin: 順番に各サーバーへリクエストを割り当てる方式
- Least Connections: 現在の接続数が最も少ないサーバーにリクエストを割り当てる方式
- IP Hash: クライアントのIPアドレスを元にハッシュ値を計算し、特定のサーバーに割り当てる方式
- Adaptive Load Balancing: リアルタイムのサーバー状況(CPU使用率、メモリ、応答時間など)を考慮して、最適なサーバーにリクエストを割り当てる方式
研究の目的
主な目的は2つです。
- 4手法それぞれのパフォーマンスを以下の指標で評価する
- 応答時間:サーバーやシステムがリクエストに対して応答するまでの時間
- スループット:一定時間内に処理できるデータ量やリクエスト数
- 稼働時間:システムやサーバーが停止せずに稼働している時間の割合
- サーバー使用率:サーバーのリソース(CPU、メモリなど)がどれだけ使用されているかの指標
- 異なるトラフィック条件下でパフォーマンスを分析する
実験設定
環境・分析手法
| クラウド インフラ | Azure 上に建てられた VM |
| ロード バランサーの構成 | Azure Load Balancer と Application Gateway を用いてそれぞれの手法を実装 (HTTP/S トラフィック) |
| トラフィック シミュレーション ツール | Apache JMeter, Locust |
| モニタリング ツール | Azure Monitor を用いてリアルタイムでパフォーマンスを測る |
| テスト後の分析 | データを集計・分析し、平均値・中央値・標準偏差などを算出する |
テストシナリオ
- Constant Load: 通常の使用を模して、リクエストを安定的に送る
- Spike Load: システムの応答性を測るために、トラフィックを増加させる (例: 200 % 増)
- Variable Load: ピーク時間帯における典型的なユーザー行動を模して、リクエスト率を変動させる
各手法の詳細
| 手法 | 特徴 | 長所 | 短所 |
|---|---|---|---|
| Round Robin | 同等の機能を備えたサーバーに対し有効 | ✅実装・設定がシンプル ✅リクエストが均等に分散できる |
🔺サーバーの性能にばらつきがある場合に性能が落ちる可能性がある |
| Least Connections | ワークロードが大きく異なるときに有効 | ✅現在のサーバー負荷に基づいてリソース使用を最適化できる ✅パフォーマンスのボトルネック発生の可能性を低減できる |
🔺サーバー接続を継続的に監視しなければならず、実装が複雑になる可能性がある |
| IP Hash | セッション状態を維持する際に有効 | ✅ユーザー セッションの一貫性を保証し、体験向上が可能 ✅リピーター ユーザーの遅延を最小限に抑えられる |
🔺多くのユーザーが同じIPアドレスを共有する場合、負荷分散が不均一になる可能性がある |
| Adaptive Load Balancing | トラフィック パターンが変化する場合に有効 | ✅実際の需要に基づいてリソースを効果的に割り当てられる ✅トラフィック変動時のシステム レジリエンスが向上 |
🔺継続的なパフォーマンス監視が必要であるため、実装がより複雑 |
実験結果

(注意: おそらく、3列目は "IP Hash (%)" → "Uptime (%)" の間違いだと思われる)
- 応答時間:Adaptive Load Balancing は一貫して最低応答時間を達成し、負荷がピークの時にも優れたユーザー体験を提供できた
- スループット:Least Connections と Adaptive Load Balancing が良いスループットを示し、スケーラビリティが優れているとわかった
- 稼働時間:Adaptive Load Balancing が最も良いサービス可用性を提供し、トラフィックが急増した時のダウンタイムを大幅に削減できた
- サーバー利用率:Adaptive Load Balancing は個々のサーバーに負荷をかけすぎることなく高い利用率を達成し、リソース使用の最適化を実現できた
考察
1つの手法が普遍的に優れているわけではなく、性能はワークロード特性に大きく依存する。
Adaptive Load Balancing にはリアルタイム応答性があるため、特に動的な条件下で最も効率的な手法であると考えられる。このことはシステム性能とユーザー満足度の両方の向上に寄与しうる。
以上のことから、負荷分散手法を選択する際にはまずアプリケーション要件を考慮する必要がある。例えば、予測可能なトラフィックを持つアプリケーションは Round Robin のような単純な手法で十分である一方、負荷が変動するアプリケーションには Adaptive Load Balancing が適していると考えられる。
まとめ
今回は、負荷分散の手法について論文を読みつつ比較を行いました。
Azure Load Balancer が 5 タプル ハッシュを採用しているのはフローの一貫性を担保するためだと考えられそうです。
クライアント IP アドレスだけではなく、そのほかに 4 つの要素も組み合わせているのは IP Hash の弱点である「ユーザーの IP アドレスが偏った際に負荷分散が不均一になる」という部分を軽減させるため???
なぜこの手法なのか、について具体的な記述は見つけられなかったので、また時間があるときに探してみたいと思います☕
読んでいただいてありがとうございました。
Discussion