1.
ロードバランサ再入門
2017年2月17日
株式会社DMM.comラボ
高嶋隆一
第8回電力系NCC情報交換会
Version 02/19

2.
おっさんエンジニアがロードバランサについて改めて設
計・構築するに当たり、
 ロードバランサの基本
 最近の動向 (と言っても最新ではない)
について整理した情報を共有します。
新人教育にでも使って頂けるとうれしいです！
1
本資料の目的

3.
 ロードバランサの役割
 SLBとGSLB
 詳解SLB
 ロードバランサの機能
 L4とL7
 振分けアルゴリズム
 振分けトポロジ
 その他のロードバランサの機能
2
目次

4.
3
ロードバランサの役割

5.
4
用語
クライアント
Virtual IP Address (VIP)
ロードバランサ (LB)
通信の接続元。
Webコンテンツであればブラウザ。
クライアントから接続されるIPアドレス。
今回解説対象。
冗長化や負荷分散を行う。
ADC (Application Delivery Controller)ともいう。
リアルサーバ
実際に通信を処理するサーバ。
VMでもリアルサーバなので最近ややこしい。

6.
5
冗長化
1台のリアルサーバが故障しても、他の正常なリアルサーバによって
サービス継続を可能とする冗長化機能。
(ロードバランサ自体も1:1、N:1で冗長化が可能)
LB無し LB有り+複数のリアルサーバ

7.
6
負荷分散
1台のリアルサーバでは処理しきれない負荷を複数サーバに振分け、
スケールアウトさせる事により性能を上げる負荷分散機能。
LB無し LB有り+複数のリアルサーバ
… …
1台分の性能 N台分の性能
…

8.
7
SLBとGSLB

9.
8
サーバロードバランシング(SLB)
IPアドレスもしくはMACアドレスの書き換えにより、
TCP/UDPを始めとした同一IPアドレス(VIP)宛の通信を複数の
リアルサーバに振分ける技術。
通常LBといった場合はこちらを指すことがほとんど。
192.168.0.1 192.168.0.2 192.168.0.3
203.0.113.1
…
アドレス書き換え＆セッション振分け
クライアントはVIP:203.0.113.1
に通信を要求しているが実際には複数の
サーバに処理が振分けられている。

10.
9
グローバルサーバロードバランシング(GSLB)
LBが権威DNSサーバとなる。
1つのホスト名に対するAもしくはAAAAレコードを複数したアドレスのうち
いずれかを1つ返答し、異なるIPアドレスに負荷分散する技術。
権威DNSサーバとしての動作であり、TCP/UDP他の通信を直接
振分ける訳ではないことに注意。
GSLB
A/AAAA振分け
www.example.com=
192.0.2.1
198.51.100.1
203.0.113.1
192.0.2.1 198.51.100.1 203.0.113.1
今回は203.0.113.1が
DNS応答で得られたので
そこに接続
クライアント
リアルサーバ

11.
10
GSLBの動き キャッシュDNS
www.example.com
の権威DNSサーバ
=GSLB
www.example.com
のIPアドレスは？
2
www.example.com
のIPアドレスは？
4
www.example.com
の権威DNSを教える
3
複数あるAのうち
203.0.113.1を
Aとして返答
5
example.com
の権威DNSサーバ
クライアント
192.0.2.1 198.51.100.1 203.0.113.1
www.example.com
のリアルサーバ
www.example.com
のIPアドレスは？1
203.0.113.16
203.0.113.1に接続
7

12.
11
よくあるwebサービスのアーキテクチャ
www.example.com
の権威DNSサーバ
=GSLB
www.example.com
のSLB
www.example.com
の実サーバ
セッション振分けセッション振分けセッション振分け
example.com
の権威DNSサーバ
所謂普通の権威DNSサーバ。
GSLBを使うため、このケースでは
wwwのNSをGSLBに移譲
wwwの負荷分散、冗長を行う為、
A/AAAAに複数のレコードを登録
障害時に切り外す為、A/AAAA のTTL
が短いのは許してorz
NS移譲
A/AAAA振分け
GSLBとSLBを組み合わせた階層化ロードバランシング

13.
12
詳解SLB

14.
13
ロードバランサの基本機能
基本機能1.セッション振分け
基本機能2.アドレス変換
基本機能3.ヘルスチェックと切り離し
基本機能4.パーシステンス

15.
14
基本機能1.セッション振分け
192.168.0.1 192.168.0.2 192.168.0.3
VIP:203.0.113.1
振分け
リアルサーバ
SLB
クライアントはVIPに対して通信を行うが、SLBはそのセッションの
を特定の手順により複数のリアルサーバのうちの1台に振分けを行う。

16.
15
基本機能2.アドレス変換
192.168.0.1 192.168.0.2 192.168.0.3
VIP:203.0.113.1
アドレス書き換え
リアルサーバ
SLB
クライアントはVIPに対して通信を行うが、SLBはそのセッションの
宛先アドレスを書換えることによりリアルサーバへの振分けを行う。
宛先IPアドレス、MACアドレスのどちらかを書換える。
Src:192.0.2.1Dst:203.0.113.1
192.0.2.1
パケットヘッダ(IPアドレス書換えの場合)
Src:192.0.2.1Dst:192.168.0.3
Changed!

17.
16
基本機能3.ヘルスチェックと切り離し
192.168.0.1 192.168.0.2 192.168.0.3
VIP:203.0.113.1
リアルサーバ
SLB
LBはリアルサーバに対して、正常性の確認(ヘルスチェック)を
定期的に行い、異常が見つかったリアルサーバにはセッション
振分けを行いわないようにする
192.0.2.1
ヘルスチェック
ヘルスチェックが失敗した
192.168.0.3への振分けを停止

18.
17
代表的なヘルスチェックの種類
PINGによってリアルサーバの死活を監視するICMP
TCPのポートの状態を監視するL4
HTTP GET等、プロトコルレベルの死活監視を行うプロトコル監視
実際にアプリケーションレベルでの入力を行い、その
返答が正しいかの確認を行う
アプリケーション
監視

19.
18
基本機能4.パーシステンス
192.168.0.1 192.168.0.2 192.168.0.3
VIP:203.0.113.1
リアルサーバ
SLB
LBは振分けアルゴリズムに従い、セッション毎に各リアルサーバに振分けを行う。
動的コンテンツの処理等で、複数のセッションを張り、クライアントからのアプリ
ケーショントランザクションが終了する迄は特定のリアルサーバに振分けが必要な
場合がある。これを実現する機能をパーシステンスという。
192.0.2.2
Source IPアドレスベースでパーシステ
ンスを実現する例
セッションの順序によらず、同じIPアド
レスからの通信は同じリアルサーバに
割り振る
192.0.2.1 192.0.2.3
1 4 5 6 2 3

20.
19
代表的なパーシステンスの種類
Source IPアドレスもしくはSource IPアドレス+ポート
を識別に用いる手法
L3/L4
CookieをLBもしくはリアルサーバで挿入し、それを識
別に用いる手法Cookie
URIを動的に生成し、識別に用いる手法URI
TLS session ID, Jsession-ID等のプロトコルのIDを識
別に用いる手法、L3-L7のパラメータからハッシュを
生成する手法等がある
その他

21.
20
L4とL7
VIPに来た通信をどう区別して適切なリア
ルサーバ(群)に振分けるか
 L4LB
 L7LB
 ルールベース

22.
21
L4LB
該当VIP用リアルサーバ群
VIP: 203.0.113.0 TCP80
セッションを振分けるリアルサーバ群の選定を
IPアドレス+TCP/UDPポート
のみで識別する選択方法。基本的にはハードウェア処理の為、
パフォーマンスに優れる

23.
22
L7LB
example.com
VIP: 203.0.113.0 TCP80
セッションを振分けるリアルサーバ群の選定を
L4情報にに加え、HTTPヘッダ等のL7情報を解釈して識別する。
その為、一旦TCP他のプロトコルをLBが終端する必要がある。
CPU処理が入る為、L4LBより負荷が高い。
example.jp
同一IPアドレスをVIPとするexample.jpと
example.comをHTTP Hostヘッダを見て選
択する例(*)
(*)Hostヘッダ以外にもpath情報の他、
LBが解釈できるL7情報であれば
個別の振分けが可能
GET /hoge/fuga HTTP/1.1
Host: example.jp

24.
23
ルールベース
L3,L4,L7ヘッダ、場合によってはペイロードも含むパケットの
情報等を用いて条件分岐を行い、振分け先を選択する。
単純に振分け先を選択するだけではなく、他のアクションも可能。
多くは独自のプログラミング言語の態をとり、
ベンダによって実装が異なる。(F5 iRules, A10 aFleX等)

25.
24
振分けアルゴリズム
同一グループに属するリアルサーバ群
に対して、振分け先をどの様に決定する
か
 Round Robin
 Least Connection
 その他の振分けアルゴリズム
 Priority

26.
25
Round Robin
複数のリアルサーバから次のセッションをどこに振分けるかを
決める方式のひとつとしてRound Robin (RR)がある。
RRでは一定の順番でセッションを割り振っていく。
リアルサーバ群
1
1
２
２
３
３
４
４
５
５
A,B,C,A,B,C…
の順にセッションを振分けるケース
A B C

27.
26
Least Connection
複数のリアルサーバから次のセッションをどこに振分けるかを
決める方式のひとつとしてLeast Connectionがある。
Least Connectionでは同時接続数が最も少ないリアルサーバに振分
けを行う。
リアルサーバ群
最も同時接続数が少ないAに振分け
A B C
同時接続数 50 55 55

28.
27
その他の振分けアルゴリズム
サーバ毎に重み付けを行い、振分けるセッショ
ン数をリアルサーバによって変えるRound
Robin
左の例ではA,A,B,C,A,A,B,C…となる
Weighted RR
Weight 2 1 1::
A B C
ヘルスチェックによる遅延時間等をパラメータ
として最も負荷が低いと思われるサーバに振
分ける
左の例ではRTTが短いBが選択される
ヘルスチェックとの組合せ
RTT 5ms 3ms 5ms
A B C

29.
28
振分け【Priority】
厳密にはアルゴリズムではないが、複数のリアルサーバグループ
を使った振分けの仕組みとしてPriorityが存在する。
ヘルスチェックや同時接続数等の事前設定条件を満たす限り、
強制的にPriorityが高いリアルサーバグループに割り振られる。
Active/Standby構成やSorryページ等に使われる。
Priority 10
通常コンテンツを持つリアルサーバグルー
プが異常時にSorryページを持つグループ
へフェイルオーバする構成例。
Priorityを逆にすれば緊急メンテナンス時等
にも使えるPriority 5
通常
コンテンツ
Sorry
ページ

30.
29
振分けトポロジ
代表的なロードバランシングのトポロジと
その特徴
 インライン
 L2DSR
 L3DSR

31.
30
インライン
VIP: 203.0.113.0
宛先IPアドレスの書換えによりリアルサーバへの振分けを行う。
往復トラフィック双方がLBを経由する。
192.168.0.1 192.168.0.2 192.168.0.3
192.168.0.254
レスポンスリクエスト
198.51.100.1 Src:198.51.100.1
Dst:203.0.13.0
1
1
Src:198.51.100.1
Dst:192.168.0.3
NAT
Changed
2
2
Dst:198.51.100.1
Src:192.168.0.3
3
3
Dst:198.51.100.1
Src:203.0.113.0
NAT
Changed
4
4

32.
31
インライン
長所
往復のパケットが全てLBを経由する為、
◯ TCPセッションの状態監視、異常セッションの切断等、きめ細かな管理がLB
上で可能
特徴
 IPアドレスのNATを行っている為、往復の経路が一致する
短所
往復のパケットが全てLBを経由する為、
✖ 必要となる性能が高くなる。また、リクエスト、レスポンスでは通常後者の帯
域が大きい為、より広帯域なインタフェースが必要

33.
32
L2DSR (Direct Server Return)
192.0.2.10
MAC:B
192.0.2.11
MAC:C
192.0.2.254
MAC:Z
198.51.100.1
Loopback
192.0.2.1
VIP:192.0.2.1
MAC:A
Loopback
192.0.2.1
宛先MACアドレスの書換えによりリアルサーバへの振分けを行う。
リアルサーバはVIPをLoopbackアドレスとして設定し、それをSourceアドレ
スとしてレスポンスを行う。
レスポンスはLBを経由しない非対称な通信となる。
収容ルータ
LB
1 3
2
1 Src:198.51.100.1
Dst:192.0.2.1
DstMAC:A
レスポンスリクエスト
2 Src:198.51.100.1
Dst:192.0.2.1
DstMAC:B
Dst MAC
Translation
Changed
3 Dst:198.51.100.1
Src:192.0.2.1
DstMAC:Z
Loopback に 設 定 し
た VIP を Source と し
てレスポンス

34.
33
L2DSR
長所
レスポンスのトラフィックがLBを経由しない為、
◯ LB自体の負荷が低く、結果として多くのリクエスト処理が可能となる
◯ リクエストのみの処理の為、広帯域のインタフェースを必要としない
上記の観点から、1VIPのトランザクション数も多く、レスポンスのデータも大きな
コンテンツプロバイダ向き
特徴
 MACアドレスの変換でセッション振分けを行っており、レスポンスのトラフィッ
クはLBを経由しない
短所
✖ セッションのステータスを管理できず、細かな制御は不可
✖ TCPを終端しない為、L7LB不可
✖ サーバでDSRに特化した特殊設定が必要
✖ LB、リアルサーバ共に同一のL2セグメントに存在する必要がある

35.
34
インラインとL2DSRの比較
インライン L2DSR
リクエスト処理性能 △(*1) ◯
インタフェース
×
レスポンスに合わせた帯域
◯
リクエスト分だけの帯域
L7/TLS ◯
×
TCPを終端しない為、
L7/TLSの処理は不可
セッション制御 ◯
×
TCPを終端しない為、細かな
制御は不可
リアルサーバ設定
◯
特殊な設定は不要
×
DSR用の設定が必要(*2)
トポロジ
◯
特に制限なし
×
L2同一セグメントに制限
(*1)現在では性能がボトルネックになる事は少ないが、インタフェース速度からより上位のモデルが必要になる
(*2)LoopbackにVIPを設定する、LoopbackのARPは無視するといった追加設定が必要

36.
35
L3DSR
L2DSRは大規模な環境向けの技術でありながら、MACアドレス変換を用
いている為、同一のL2セグメント上にLBとリアルサーバを置く必要がある。
その為、下記の様な制約を持っている。
 大規模なL2ネットワークがデータセンタ上に必要
 事前に最大のリアルサーバの数を考慮したIPアドレス設計が必要
IPアドレス変換を用いたDSRを行ってL2の制約を外し、IPルーティングさ
えされていればDSRを利用可能とする技術がL3DSRである。

37.
36
L3DSR
192.0.2.0/24
… …
192.0.2.0/24
…
192.168.0.0/24
…
10.0.0.0/24
L2DSR L3DSR
リアルサーバを増やす
には大規模L2ネットワー
クを構築する必要がある
ルータで分割されたL3ネットワークを自由に
構成でき、セグメント追加も容易。

38.
37
L３DSRの方式
L2DSRでは通信を求められているVIPはIPヘッダの中にあったが、
L3DSRではIPアドレス変換を用いている為、どのVIP当ての通信かをLB
からリアルサーバへ通知する必要がある。
方式としては下記の2つがある。
LBとリアルサーバ間でトンネルを張り、利用するトン
ネルによってVIPを通知する方式
トンネル方式
LBとリアルサーバでVIPとDSCP bitの対応表を持ち、
DSCP bitによりVIPを通知する方式
DSCP方式

39.
38
L3DSR【DSCP方式】
198.51.100.1
VIP1:192.0.2.1
VIP2:192.0.2.2
IF:10.0.0.1
172.16.0.1
Lo1:192.0.2.1
Lo2:192.0.2.2
172.16.0.2 172.16.0.2
Lo1:192.0.2.1
Lo2:192.0.2.2
Lo1:192.0.2.1
Lo2:192.0.2.2
予め、DSCPとVIPの対応表をLBとリアルサーバで持っておき、
どのVIP向けの通信かを識別する
DSCP VIP
192.0.2.1
192.0.2.2
0x1
0x2
リクエストがあったVIPに応じた
DSCP bitを立ててリアルサーバ
に転送
DSCP bit に応じたVIPでクライアント
にレスポンス

40.
39
L3DSR【DSCP方式】
198.51.100.1
VIP1:192.0.2.1
VIP2:192.0.2.2
IF:10.0.0.1
172.16.0.1
Lo1:192.0.2.1
Lo2:192.0.2.2
172.16.0.2 172.16.0.2
Lo1:192.0.2.1
Lo2:192.0.2.2
Lo1:192.0.2.1
Lo2:192.0.2.2
DSCP VIP
192.0.2.1
192.0.2.2
0x1
0x2
Src:198.51.100.1
Dst:192.0.2.1
DSCP: 0x01
LBのVIP宛にリクエスト
Src:198.51.100.1
Dst:172.16.0.1
DSCP: 0x1
2
DSCPを立て、宛先をリアルサーバに書換えて転送Dst:192.0.2.1
DSCP: 0x0
Src:198.51.100.1
3
DSCPを見て、
対応するアドレス
に書き換え(*)、
処理プロセスに渡す
Src:192.0.2.1
Dst:198.51.100.1
DSCP: 0x0
4
VIPをSource IPアドレス
としたレスポンス
(*)LinuxであればiptablesのPREROUTING等を用いる

41.
40
L3DSR【トンネル方式】
198.51.100.1 VIP1:192.0.2.1
VIP2:192.0.2.2
IF:10.0.0.1
172.16.0.1
Lo1:192.0.2.1
Lo2:192.0.2.2
172.16.0.2 172.16.0.2
Lo1:192.0.2.1
Lo2:192.0.2.2
Lo1:192.0.2.1
Lo2:192.0.2.2
LBとリアルサーバでIP-in-IPやGRE等のトンネルを張っておき、
トンネルとVIPを対応付け、どのVIP向けの通信かを識別する。
トンネルヘッダ分パケット長が増える為、物理ネットワーク上で
MTUサイズの考慮が必要。(*)
トンネル VIP
192.0.2.1
192.0.2.2
黄
青
リクエストがあったVIPに応じたト
ンネルを使ってリアルサーバに転
送
トンネルに応じたVIPでクライアントに
レスポンス
(*)GREであれば1500+24=1524bytesのIP MTUが必要

42.
41
L3DSR【トンネル方式】
198.51.100.1
VIP1:192.0.2.1
VIP2:192.0.2.2
IF:10.0.0.1
172.16.0.1
Lo1:192.0.2.1
Lo2:192.0.2.2
172.16.0.2 172.16.0.2
Lo1:192.0.2.1
Lo2:192.0.2.2
Lo1:192.0.2.1
Lo2:192.0.2.2
Src:198.51.100.1
Dst:192.0.2.1
1
LBのVIP宛にリクエスト
Dst:192.0.2.1
Src:198.51.100.1
3
トンネルヘッダを
除去した後、
処理プロセスに渡す
Src:192.0.2.1
Dst:198.51.100.1
4
VIPをSource IPアドレス
としたレスポンス
VIPに対応する
トンネルヘッダを
付与し転送
Src:198.51.100.1
Dst:192.0.2.1
Src:10.0.0.1
Dst:172.16.0.1
Outer
黄
Inner
Tunnel
2
④リアルサーバの物理インタフェースはトンネルヘッダを考慮した
MTUサイズ(GREなら1524bytes)になっているが、クライアントに
返す時には1500bytesでレスポンスする必要がある。

43.
42
L2DSRとL3DSRの比較
L2DSR L3DSR(DSCP) L3DSR(トンネル)
リクエスト処理性能 ◯
インタフェース
◯
リクエスト分だけの帯域
L7/TLS
×
TCPを終端しない為、L7/TLSの処理は不可
セッション制御
×
TCPを終端しない為、細かな制御は不可
リアルサーバ設定
 Loopback
 ARP無返答
 Loopback
 DSCP
 Loopback
 トンネル
トポロジ
×
L2同一セグメントに
制限
◯
特に制限なし
その他
DSCP 6bits より多いVIP
は識別できない
物理ネットワーク、
リアルサーバのインタ
フェースそれぞれでMTU
の考慮が必要

44.
43
その他のロードバランサの機能
TLS終端
IPv4-IPv6プロトコル変換

45.
44
TLS終端(SSLオフロード)
192.168.0.1 192.168.0.2 192.168.0.3
VIP:203.0.113.1
LB
TLS終端をLBが行い、リアルサーバはHTTPの処理のみを行う。
 TLSの証明書管理の箇所が減る
 専用ハードウェアによるTLS処理
といった特長がある。
必然、TCPセッションを終端する為、L2DSR/L3DSRでは利用できない
192.0.2.2
SLBがTLSを終端し、
リアルサーバとの通信は
HTTPで行う
192.0.2.1 192.0.2.3
HTTPS通信
HTTP通信
リアルサーバ
証明書

46.
45
IPv4-IPv6 プロトコル変換
192.168.0.1 192.168.0.2 192.168.0.3
VIP:2001:2::1
LB
クライアント・VIPがIPv6、リアルサーバがIPv4というケースでLBがプロトコル変換を
行う事により通信を可能とする事ができる。
2001:db8::1
リアルサーバ
192.168.0.254

47.
46
IPv4-IPv6 プロトコル変換の留意点
Source IPアドレス
Destination だけではなく Source IPアドレスも書き換えられる為、リアルサーバ
から見るとLBからアクセスされている様にみえる
→ LBでX-Forwarded-ForやRFC7239等のヘッダを挿入する事によりリアル
サーバでも元々のSource IPアドレスを確認可能
MTUサイズとフラグメント
IPv4とIPv6では
 ヘッダサイズが異なる
 Path MTU Discoveryの方法が異なる
と言った差異がある。場合によっては送出MTUの調整などが必要となる。

48.
47
IPv4-IPv6 プロトコル変換
192.168.0.1 192.168.0.2
VIP:2001:2::1
LB
2001:db8::1
リアルサーバ
192.168.0.254
IPv4-IPv6プロトコル変換を実施し、RFC7239ヘッダを挿入する例
Src:2001:db8::1
Dst:2001:2::1
1
IPv6 VIPへアクセス
192.168.0.3
Src:192.168.0.254
Dst:192.168.0.1
Forwarded:
for=[2001:2::1];
by=[2001:db8::1];
proto=http;
host=example.com
2
IPv4へのプロトコル変換、
RFC7239ヘッダ挿入後、
IPv4のリアルサーバへ転送。
Dst:192.168.0.254
Src:192.168.0.1
3
IPv6 MTUサイズを考慮した
パケットサイズでIPv4で
LBにレスポンス
Dst:2001:db8::1
Src:2001:2::1
4IPv6へプロトコル変換し、
クライアントへレスポンス。

49.
 NANOG51:
L3DSR – Overcoming Layer 2 Limitations of Direct Server Return Load Balancing
• https://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf
 ENOG19: ロードバランサーと俺
• http://enog.jp/wp-content/uploads/2013/02/ENOG19-KonoKono.pdf
 The PROXY protocol Versions 1 & 2
• http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
 RFC7239 Forwarded HTTP Extension
• https://tools.ietf.org/html/rfc7239
48
参考資料
Special Thanks To:
 Kono Kono @ A10 Networks

50.
49
Thank you!