maglev: a fast and reliable software network load balancer
TRANSCRIPT
CyberAgent, Inc. All Rights Reserved
Maglev:A Fast and Reliable SoftwareNetwork Load Balancerアドテクスタジオ Dynalyst 黒崎 優太
概要
● Maglevとは
● ロードバランサ 3方式
○ ふつうのやつ(?)○ DNS-RR○ DSR
● Maglevのアーキテクチャ
○ ECMP○ 分散 Connection Tracking○ DSR
GCPのロードバランサ● Compute Engine Load Balancing hits 1
million requests per second!○ https://cloudplatform.googleblog.com/2013_11_01_archive.html
● 1IPアドレス/ウォームアップなしでいきなり
100万RPSをさばける
○ グローバルな
■ 負荷分散
■ 障害耐性
○ ソフトウェアLB
余談: Facebook
● http://www.slideshare.net/pallotron/dhcp-at-facebook-evolution-of-an-infrastructure
● DNSのAレコードを複数登録しておく
○ RR = ラウンドロビン
DNS RR
example.com(198.51.100.1)
example.com(198.51.100.2)
example.com(198.51.100.3)
example.com(198.51.100.4)
Aレコードが複数あった場合に毎回違うものが帰ってくるのを利用
(AWSのELBは前述のLBとDNS RRの組み合わせ)
● Direct Server Returnの略
L2 DSR
198.51.100.10
198.51.100.11(lo: 198.51.100.10)
198.51.100.12(lo: 198.51.100.10)
198.51.100.13(lo: 198.51.100.10)
198.51.100.14(lo: 198.51.100.10)
s01
s02
s03
s04
198.51.100.10 にアクセス
L2 SW
● Direct Server Returnの略
L2 DSR
198.51.100.10
198.51.100.11(lo: 198.51.100.10)
198.51.100.12(lo: 198.51.100.10)
198.51.100.13(lo: 198.51.100.10)
198.51.100.14(lo: 198.51.100.10)
s01
s02
s03
s04
pc01
宛先MACアドレスをs02のものに書き換える
(送信元/宛先IPは書き換えない)
198.51.100.10 にアクセス
● Direct Server Returnの略
L2 DSR
198.51.100.10
198.51.100.11(lo: 198.51.100.10)
198.51.100.12(lo: 198.51.100.10)
198.51.100.13(lo: 198.51.100.10)
198.51.100.14(lo: 198.51.100.10)
s01
s02
s03
s04
198.51.100.10 にアクセス
宛先MACアドレスをs02のものに書き換える(宛先IPは書き換えない)
戻りパケットはLBを経由しない!
(DirectにReturnする!)
L3 DSR● 前述のDSRをL3で行う
● L2 DSRだと各ネットワークセグメントごとにLBを設置しなければならない
● →別セグメントにLBを設置!
○ このままだとパケットがセグメントを
またげないのでL3に対応する必要が…
L3 DSR
パケットをカプセリングする(トンネリング)
app-A
app-B
app-C
L2 SW
L2 SW
L2 SW
L2 SW
L3 SW
セグメントをまたぐ
IP TCP Data
IP TCP DataIP
先頭にIPヘッダを付加する(IPIPトンネルの例)
IP TCP Data
LBでIPヘッダを1つ足す
サーバでIPヘッダを1つ取る
L3 DSR
パケットをカプセリングする(トンネリング)
app-A
app-B
app-C
L2 SW
L2 SW
L2 SW
L2 SW
L3 SW
セグメントをまたぐ
戻りのパケットはカプセリング不要
パケットは吸い込むもの
● インターネット上では
トラフィックは吸い込まれる
○ 経路を広告すると、パケットが
送られてくる(吸い込まれるイメージ)○ 複数拠点で同じ経路を広告すれば、
近い方(コストが小さい方)に吸い込まれる
パケットは吸い込むもの
● 同じアドレスレンジを広報しても、 近い方に吸い込まれる(IP AnyCast)
日本リージョン アメリカリージョン
198.51.100.1/24 はこっちですよ♪
198.51.100.1/24 はこっちですよ♪
パケットは吸い込むもの
● リージョン丸ごと障害が起きても大丈夫
198.51.100.1/24 はこっちですよ♪
198.51.100.1/24 はこっちですよ♪
一番近いところへ日本リージョン アメリカリージョン
ECMP● Equal Cost Multi Path
○ コスト(前のスライドで言う距離)が同じだった時
の挙動
○ 等コストの場合はルータがロードバランシングす
る
○ (今回の場合)インターネット接続部分
だけでなく、自組織内でも行っている
Connection Trackingのしくみ
● 5-tuple○
● 5-tupleの組み合わせで転送先を固定する
● これでコネクションが維持される
● ここまでは普通
○ (前述の3種類のLBもやってる)● どうやってこれをスケールアウトさせるか
○ => 分散 Connection Trackingを実装したい!
● どのLBに通信が来ても同じ挙動をする必要
がある○ 独立してコネクション
管理するとダメ
スケールアウトさせるには
身に覚えのないコネクション
ECMP
クライアントは1コネクションしか張っていな
いので1台としか通信できない
コネクション確立済
● こうなってほしい○ 全台が同じ情報を持った状態
○ とはいえLB間でコネクションの情報を
リアルタイムに同期するのは難しい
スケールアウトさせるには
コネクション確立済
ECMPECMP
必ず1対1で通信が成立する状態!
Consistent Hashing
● http://www.slideshare.net/paulowniaceae/consistent-hash
Consistent Hashing● ハッシュ関数を使って適当にサーバと
クライアントを
振り分けます
○ 5-tupleを使うhash((srcIP, srcPort, dstIP, dstPort, proto))
● バックエンドの数が変わっても均一にしたい
Maglev Hashing (Consistent Hashingの応用)
● https://blog.acolyer.org/2016/03/21/maglev-a-fast-and-reliable-software-network-load-balancer/
offset = hash1(hostname) mod Mskip = hash2(hostname) mod (M-1) + 1
(M = 100より大きい素数)
// offset = 3, skip = 4のとき
B0 = [ 3, // (3 + 0 * 4) mod 7 0, // (3 + 1 * 4) mod 7 4, // (3 + 2 * 4) mod 7 1, // (3 + 3 * 4) mod 7 5, // (3 + 4 * 4) mod 7 2, // (3 + 5 * 4) mod 7 6, // (3 + 6 * 4) mod 7]
DSR
● 前述のL3 DSR○ GREでカプセリング
■ IPIPのようにヘッダを付加する方式
IP TCP Data
IP TCP DataIP
IP TCP Data
LBでIP + GREヘッダを1つ足す
サーバでIP + GREヘッダを1つ取る
GRE
Maglev論文のまとめ
● ECMP + 分散connection tracking + DSR○ => Fast and Reliable Software Network Load Balancer
● http://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/44824.pdf
疑問● GCPはHTTP ロードバランサ(L7)も
用意されてるがどんな仕組みなのか
● 1ノードあたりの性能高すぎない?
○ ショートパケットでも10Gbps出るらしい ■ ユーザ空間でパケットを処理
(Intel DPDK的な)してるらしい