Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
CyberAgent, Inc. All Rights Reserved
Maglev:
A Fast and Reliable
Software
Network Load
Balancer
アドテクスタジオ Dynalyst 黒崎 優太
黒崎 優太
● アドテクスタジオ Dynalyst エンジニア
● 2年目
○ Scala, LXD
● 今日はGoogleの論文の紹介をします
査読に参加しました 自宅に設置しました
概要
● Maglevとは
● ロードバランサ 3方式
○ ふつうのやつ(?)
○ DNS-RR
○ DSR
● Maglevのアーキテクチャ
○ ECMP
○ 分散 Connection Tracking
○ DSR
Maglevとは
Maglevとは
● Googleの分散型L4ロードバランサ
○ GCPのロードバランサの元になっている
● 今日はタイトルになっているMaglevに関す
る論文を解説します。
GCPのロードバランサ
● Compute Engine Load Balancing hits 1
million requests per second!
○ https://cloudplatform.googleblog.com/201...
余談: Facebook
● http://www.slideshare.net/pallotron/dhcp-at-facebook-evolution-of-an-infrastructure
ロードバランサ3方式:
ふつうのやつ
● 普通すぎて(?)なんと言えばよいのやら…
○ 一番わかりやすい例
○ NAPTする
ふつうのやつ
ロードバランサ3方式:
DNS RR
● DNSのAレコードを複数登録しておく
○ RR = ラウンドロビン
DNS RR
example.com
(198.51.100.1)
example.com
(198.51.100.2)
example.com
(198.51.100.3...
ロードバランサ3方式:
DSR
● 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.1...
● 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.1...
● 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.1...
● 戻りトラフィックがどんなに大きくてもLBはリ
クエストだけ転送すれば良いので
○ 転送負荷が非常に低くなる!
○ 遅延も抑えられる!
○ 送信元IPが書き換わらない!
L2 DSR のいいところ
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
セグメントをまたぐ必要性
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ヘッダ...
L3 DSR
パケットをカプセリングする
(トンネリング)
app-A
app-B
app-C
L2 SW
L2 SW
L2 SW
L2 SW
L3 SW
セグメントをまたぐ
戻りのパケットはカプセリング不要
Maglevのアーキテクチャ:
ECMP
パケットは吸い込むもの
● インターネット上では
トラフィックは吸い込まれる
○ 経路を広告すると、パケットが
送られてくる(吸い込まれるイメージ)
○ 複数拠点で同じ経路を広告すれば、
近い方(コストが小さい方)に吸い込まれる
パケットは吸い込むもの
● 同じアドレスレンジを広報しても、 
近い方に吸い込まれる(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
○ コスト(前のスライドで言う距離)が同じだった時
の挙動
○ 等コストの場合はルータがロードバランシングす
る
○ (今回の場合)インターネット接続部分
だけでなく、自組織内でも行って...
ECMP
●  同じ距離(コスト)のルータが複数あったら?
アメリカリージョン
198.51.100.1/24 は
こっちですよ♪
198.51.100.1/24 は
こっちですよ♪
日本リージョン
ECMP
●  ロードバランスされる
アメリカリージョン
198.51.100.1/24 は
こっちですよ♪
198.51.100.1/24 は
こっちですよ♪
日本リージョン
Maglevのアーキテクチャ:
分散 Connection Tracking
Connection Tracking
● これがないと通信が崩壊する
Connection Trackingがない時…
TCPのコネクションを確立してみる
SYN
Connection Trackingがない時…
TCPのコネクションを確立してみる
SYN
SYN/ACK
TCPのコネクションを確立してみる
Connection Trackingがない時…
SYN
SYN/ACK
ACK 身に覚えのない
ACK
コネクション
確立不能
Connection Trackingがある時!
TCPのコネクションを確立してみる
SYN
Connection Trackingがある時!
TCPのコネクションを確立してみる
SYN
SYN/ACK
Connection Trackingがある時!
TCPのコネクションを確立してみる
SYN
SYN/ACK
ACK
コネクション
確立成功!
connection
tracking
Connection Trackingのしくみ
● 5-tuple
○  
● 5-tupleの組み合わせで転送先を固定する
● これでコネクションが維持される
● ここまでは普通
○ (前述の3種類のLBもやってる)
● どうやってこれをスケ...
スケールアウトさせるには
● どのLBに通信が来ても同じ挙動をする必要
がある
ECMP
コネクション確立済
● どのLBに通信が来ても同じ挙動をする必要
がある
○ 独立してコネクション
管理するとダメ
スケールアウトさせるには
身に覚えのない
コネクション
ECMP
クライアントは
1コネクションしか張っていな
いので
1台としか通信できない
コネ...
● こうなってほしい
○ 全台が同じ情報を持った状態
○ とはいえLB間でコネクションの情報を
リアルタイムに同期するのは難しい
スケールアウトさせるには
コネクション確立済
ECMPECMP
必ず1対1で通信が
成立する状態!
Consistent Hashing
● http://www.slideshare.net/paulowniaceae/consistent-hash
Consistent Hashing
● 円を用意します
● ハッシュ関数を使って適当に
サーバを置きます
Consistent Hashing
● ハッシュ関数を使って適当にサーバと
クライアントを
振り分けます
○ 5-tupleを使う hash((srcIP, srcPort, dstIP, dstPort, proto))
Consistent Hashing
● 各サーバは時計回り方向のクライアントを
処理する
● 複数LBでも一意な転送ができる!
Consistent Hashing
hash( )
hash( )
Maglev nodes
● スケールアウトしても担当が変わる
サーバが最小限
Consistent Hashing
↑増えた
hash( )
hash( )
Maglev nodes
● バックエンドの数が変わっても均一にしたい
Maglev Hashing (Consistent Hashingの応用)
● https://blog.acolyer.org/2016/03/21/maglev-a-fast-and-reli...
Maglevのアーキテクチャ:
DSR
DSR
● 前述のL3 DSR
○ GREでカプセリング
■ IPIPのようにヘッダを付加する方式
IP TCP Data
IP TCP DataIP
IP TCP Data
LBでIP + GREヘッダを1つ足す
サーバでIP + GREヘッ...
Maglevとは
Maglev論文のまとめ
● ECMP + 分散connection tracking + DSR
○ => Fast and Reliable Software Network Load Balancer
● http://static.go...
今日話さなかったこと
疑問
● GCPはHTTP ロードバランサ(L7)も
用意されてるがどんな仕組みなのか
● 1ノードあたりの性能高すぎない?
○ ショートパケットでも10Gbps出るらしい 
■ ユーザ空間でパケットを処理
(Intel DPDK的な)してるら...
ご清聴ありがとうございました
Upcoming SlideShare
Loading in …5
×

Maglev: A Fast and Reliable Software Network Load Balancer

GoogleのMaglevというロードバランサの論文の紹介です。

Maglev: A Fast and Reliable Software Network Load Balancer

  1. 1. CyberAgent, Inc. All Rights Reserved Maglev: A Fast and Reliable Software Network Load Balancer アドテクスタジオ Dynalyst 黒崎 優太
  2. 2. 黒崎 優太 ● アドテクスタジオ Dynalyst エンジニア ● 2年目 ○ Scala, LXD ● 今日はGoogleの論文の紹介をします 査読に参加しました 自宅に設置しました
  3. 3. 概要 ● Maglevとは ● ロードバランサ 3方式 ○ ふつうのやつ(?) ○ DNS-RR ○ DSR ● Maglevのアーキテクチャ ○ ECMP ○ 分散 Connection Tracking ○ DSR
  4. 4. Maglevとは
  5. 5. Maglevとは ● Googleの分散型L4ロードバランサ ○ GCPのロードバランサの元になっている ● 今日はタイトルになっているMaglevに関す る論文を解説します。
  6. 6. GCPのロードバランサ ● Compute Engine Load Balancing hits 1 million requests per second! ○ https://cloudplatform.googleblog.com/2013_11_01_archive.html ● 1IPアドレス/ウォームアップなしでいきなり 100万RPSをさばける ○ グローバルな ■ 負荷分散 ■ 障害耐性 ○ ソフトウェアLB
  7. 7. 余談: Facebook ● http://www.slideshare.net/pallotron/dhcp-at-facebook-evolution-of-an-infrastructure
  8. 8. ロードバランサ3方式: ふつうのやつ
  9. 9. ● 普通すぎて(?)なんと言えばよいのやら… ○ 一番わかりやすい例 ○ NAPTする ふつうのやつ
  10. 10. ロードバランサ3方式: DNS RR
  11. 11. ● 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の 組み合わせ)
  12. 12. ロードバランサ3方式: DSR
  13. 13. ● 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
  14. 14. ● 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 に アクセス
  15. 15. ● 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する!)
  16. 16. ● 戻りトラフィックがどんなに大きくてもLBはリ クエストだけ転送すれば良いので ○ 転送負荷が非常に低くなる! ○ 遅延も抑えられる! ○ 送信元IPが書き換わらない! L2 DSR のいいところ
  17. 17. L3 DSR ● 前述のDSRをL3で行う ● L2 DSRだと各ネットワークセグメントごとにLB を設置しなければならない ● →別セグメントにLBを設置! ○ このままだとパケットがセグメントを またげないのでL3に対応する必要が…
  18. 18. L3 DSR このままだとセグメントを 超えられない app-A app-B app-C L2 SW L2 SW L2 SW L2 SW L3 SW セグメントをまたぐ必要性
  19. 19. 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つ取る
  20. 20. L3 DSR パケットをカプセリングする (トンネリング) app-A app-B app-C L2 SW L2 SW L2 SW L2 SW L3 SW セグメントをまたぐ 戻りのパケットはカプセリング不要
  21. 21. Maglevのアーキテクチャ: ECMP
  22. 22. パケットは吸い込むもの ● インターネット上では トラフィックは吸い込まれる ○ 経路を広告すると、パケットが 送られてくる(吸い込まれるイメージ) ○ 複数拠点で同じ経路を広告すれば、 近い方(コストが小さい方)に吸い込まれる
  23. 23. パケットは吸い込むもの ● 同じアドレスレンジを広報しても、  近い方に吸い込まれる(IP AnyCast) 日本リージョン アメリカリージョン 198.51.100.1/24 は こっちですよ♪ 198.51.100.1/24 は こっちですよ♪
  24. 24. パケットは吸い込むもの ● リージョン丸ごと障害が起きても大丈夫 198.51.100.1/24 は こっちですよ♪ 198.51.100.1/24 は こっちですよ♪ 一番近いところへ 日本リージョン アメリカリージョン
  25. 25. ECMP ● Equal Cost Multi Path ○ コスト(前のスライドで言う距離)が同じだった時 の挙動 ○ 等コストの場合はルータがロードバランシングす る ○ (今回の場合)インターネット接続部分 だけでなく、自組織内でも行っている
  26. 26. ECMP ●  同じ距離(コスト)のルータが複数あったら? アメリカリージョン 198.51.100.1/24 は こっちですよ♪ 198.51.100.1/24 は こっちですよ♪ 日本リージョン
  27. 27. ECMP ●  ロードバランスされる アメリカリージョン 198.51.100.1/24 は こっちですよ♪ 198.51.100.1/24 は こっちですよ♪ 日本リージョン
  28. 28. Maglevのアーキテクチャ: 分散 Connection Tracking
  29. 29. Connection Tracking ● これがないと通信が崩壊する
  30. 30. Connection Trackingがない時… TCPのコネクションを確立してみる SYN
  31. 31. Connection Trackingがない時… TCPのコネクションを確立してみる SYN SYN/ACK
  32. 32. TCPのコネクションを確立してみる Connection Trackingがない時… SYN SYN/ACK ACK 身に覚えのない ACK コネクション 確立不能
  33. 33. Connection Trackingがある時! TCPのコネクションを確立してみる SYN
  34. 34. Connection Trackingがある時! TCPのコネクションを確立してみる SYN SYN/ACK
  35. 35. Connection Trackingがある時! TCPのコネクションを確立してみる SYN SYN/ACK ACK コネクション 確立成功! connection tracking
  36. 36. Connection Trackingのしくみ ● 5-tuple ○   ● 5-tupleの組み合わせで転送先を固定する ● これでコネクションが維持される ● ここまでは普通 ○ (前述の3種類のLBもやってる) ● どうやってこれをスケールアウトさせるか ○ => 分散 Connection Trackingを実装したい!
  37. 37. スケールアウトさせるには ● どのLBに通信が来ても同じ挙動をする必要 がある ECMP コネクション確立済
  38. 38. ● どのLBに通信が来ても同じ挙動をする必要 がある ○ 独立してコネクション 管理するとダメ スケールアウトさせるには 身に覚えのない コネクション ECMP クライアントは 1コネクションしか張っていな いので 1台としか通信できない コネクション確立済
  39. 39. ● こうなってほしい ○ 全台が同じ情報を持った状態 ○ とはいえLB間でコネクションの情報を リアルタイムに同期するのは難しい スケールアウトさせるには コネクション確立済 ECMPECMP 必ず1対1で通信が 成立する状態!
  40. 40. Consistent Hashing ● http://www.slideshare.net/paulowniaceae/consistent-hash
  41. 41. Consistent Hashing ● 円を用意します ● ハッシュ関数を使って適当に サーバを置きます
  42. 42. Consistent Hashing ● ハッシュ関数を使って適当にサーバと クライアントを 振り分けます ○ 5-tupleを使う hash((srcIP, srcPort, dstIP, dstPort, proto))
  43. 43. Consistent Hashing ● 各サーバは時計回り方向のクライアントを 処理する
  44. 44. ● 複数LBでも一意な転送ができる! Consistent Hashing hash( ) hash( ) Maglev nodes
  45. 45. ● スケールアウトしても担当が変わる サーバが最小限 Consistent Hashing ↑増えた hash( ) hash( ) Maglev nodes
  46. 46. ● バックエンドの数が変わっても均一にしたい Maglev Hashing (Consistent Hashingの応用) ● https://blog.acolyer.org/2016/03/21/maglev-a-fast-and-reliable-software-network-load-balancer/ offset = hash1(hostname) mod M skip = 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 ]
  47. 47. Maglevのアーキテクチャ: DSR
  48. 48. DSR ● 前述のL3 DSR ○ GREでカプセリング ■ IPIPのようにヘッダを付加する方式 IP TCP Data IP TCP DataIP IP TCP Data LBでIP + GREヘッダを1つ足す サーバでIP + GREヘッダを1つ取る GRE
  49. 49. Maglevとは
  50. 50. 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
  51. 51. 今日話さなかったこと
  52. 52. 疑問 ● GCPはHTTP ロードバランサ(L7)も 用意されてるがどんな仕組みなのか ● 1ノードあたりの性能高すぎない? ○ ショートパケットでも10Gbps出るらしい  ■ ユーザ空間でパケットを処理 (Intel DPDK的な)してるらしい
  53. 53. ご清聴ありがとうございました

×