Tweet
Tweet

Slide 1

Slide 1 text

CyberAgent, Inc. All Rights Reserved Maglev: A Fast and Reliable Software Network Load Balancer アドテクスタジオ Dynalyst 黒崎 優太

Slide 2

Slide 2 text

黒崎 優太 ● アドテクスタジオ Dynalyst エンジニア ● 2年目 ○ Scala, LXD ● 今日はGoogleの論文の紹介をします 査読に参加しました 自宅に設置しました

Slide 3

Slide 3 text

概要 ● Maglevとは ● ロードバランサ 3方式 ○ ふつうのやつ(?) ○ DNS-RR ○ DSR ● Maglevのアーキテクチャ ○ ECMP ○ 分散 Connection Tracking ○ DSR

Slide 4

Slide 4 text

Maglevとは

Slide 5

Slide 5 text

Maglevとは ● Googleの分散型L4ロードバランサ ○ GCPのロードバランサの元になっている ● 今日はタイトルになっているMaglevに関す る論文を解説します。

Slide 6

Slide 6 text

GCPのロードバランサ ● Compute Engine Load Balancing hits 1 million requests per second! ○ https://cloudplatform.googleblog.com/2013_11_01_archive.html ● 1IPアドレス/ウォームアップなしでいきなり 100万RPSをさばける ○ グローバルな ■ 負荷分散 ■ 障害耐性 ○ ソフトウェアLB

Slide 7

Slide 7 text

余談: Facebook ● http://www.slideshare.net/pallotron/dhcp-at-facebook-evolution-of-an-infrastructure

Slide 8

Slide 8 text

ロードバランサ3方式: ふつうのやつ

Slide 9

Slide 9 text

● 普通すぎて(?)なんと言えばよいのやら… ○ 一番わかりやすい例 ○ NAPTする ふつうのやつ

Slide 10

Slide 10 text

ロードバランサ3方式: DNS RR

Slide 11

Slide 11 text

● 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の 組み合わせ)

Slide 12

Slide 12 text

ロードバランサ3方式: DSR

Slide 13

Slide 13 text

● 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

Slide 14

Slide 14 text

● 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 に アクセス

Slide 15

Slide 15 text

● 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する！)

Slide 16

Slide 16 text

● 戻りトラフィックがどんなに大きくてもLBはリ クエストだけ転送すれば良いので ○ 転送負荷が非常に低くなる！ ○ 遅延も抑えられる！ ○ 送信元IPが書き換わらない！ L2 DSR のいいところ

Slide 17

Slide 17 text

L3 DSR ● 前述のDSRをL3で行う ● L2 DSRだと各ネットワークセグメントごとにLB を設置しなければならない ● →別セグメントにLBを設置！ ○ このままだとパケットがセグメントを またげないのでL3に対応する必要が…

Slide 18

Slide 18 text

L3 DSR このままだとセグメントを 超えられない app-A app-B app-C L2 SW L2 SW L2 SW L2 SW L3 SW セグメントをまたぐ必要性

Slide 19

Slide 19 text

L3 DSR パケットをカプセリングする (トンネリング) app-A app-B app-C L2 SW L2 SW L2 SW L2 SW L3 SW セグメントをまたぐ IP TCP Data IP TCP Data IP 先頭にIPヘッダを付加する(IPIPトンネルの例) IP TCP Data LBでIPヘッダを1つ足す サーバでIPヘッダを1つ取る

Slide 20

Slide 20 text

L3 DSR パケットをカプセリングする (トンネリング) app-A app-B app-C L2 SW L2 SW L2 SW L2 SW L3 SW セグメントをまたぐ 戻りのパケットはカプセリング不要

Slide 21

Slide 21 text

Maglevのアーキテクチャ: ECMP

Slide 22

Slide 22 text

パケットは吸い込むもの ● インターネット上では トラフィックは吸い込まれる ○ 経路を広告すると、パケットが 送られてくる(吸い込まれるイメージ) ○ 複数拠点で同じ経路を広告すれば、 近い方(コストが小さい方)に吸い込まれる

Slide 23

Slide 23 text

パケットは吸い込むもの ● 同じアドレスレンジを広報しても、 近い方に吸い込まれる(IP AnyCast) 日本リージョン アメリカリージョン 198.51.100.1/24 は こっちですよ♪ 198.51.100.1/24 は こっちですよ♪

Slide 24

Slide 24 text

パケットは吸い込むもの ● リージョン丸ごと障害が起きても大丈夫 198.51.100.1/24 は こっちですよ♪ 198.51.100.1/24 は こっちですよ♪ 一番近いところへ 日本リージョン アメリカリージョン

Slide 25

Slide 25 text

ECMP ● Equal Cost Multi Path ○ コスト(前のスライドで言う距離)が同じだった時 の挙動 ○ 等コストの場合はルータがロードバランシングす る ○ (今回の場合)インターネット接続部分 だけでなく、自組織内でも行っている

Slide 26

Slide 26 text

ECMP ● 同じ距離(コスト)のルータが複数あったら？ アメリカリージョン 198.51.100.1/24 は こっちですよ♪ 198.51.100.1/24 は こっちですよ♪ 日本リージョン

Slide 27

Slide 27 text

ECMP ● ロードバランスされる アメリカリージョン 198.51.100.1/24 は こっちですよ♪ 198.51.100.1/24 は こっちですよ♪ 日本リージョン

Slide 28

Slide 28 text

Maglevのアーキテクチャ: 分散 Connection Tracking

Slide 29

Slide 29 text

Connection Tracking ● これがないと通信が崩壊する

Slide 30

Slide 30 text

Connection Trackingがない時… TCPのコネクションを確立してみる SYN

Slide 31

Slide 31 text

Connection Trackingがない時… TCPのコネクションを確立してみる SYN SYN/ACK

Slide 32

Slide 32 text

TCPのコネクションを確立してみる Connection Trackingがない時… SYN SYN/ACK ACK 身に覚えのない ACK コネクション 確立不能

Slide 33

Slide 33 text

Connection Trackingがある時！ TCPのコネクションを確立してみる SYN

Slide 34

Slide 34 text

Connection Trackingがある時！ TCPのコネクションを確立してみる SYN SYN/ACK

Slide 35

Slide 35 text

Connection Trackingがある時！ TCPのコネクションを確立してみる SYN SYN/ACK ACK コネクション 確立成功！ connection tracking

Slide 36

Slide 36 text

Connection Trackingのしくみ ● 5-tuple ○ 　 ● 5-tupleの組み合わせで転送先を固定する ● これでコネクションが維持される ● ここまでは普通 ○ (前述の3種類のLBもやってる) ● どうやってこれをスケールアウトさせるか ○ => 分散 Connection Trackingを実装したい！

Slide 37

Slide 37 text

スケールアウトさせるには ● どのLBに通信が来ても同じ挙動をする必要 がある ECMP コネクション確立済

Slide 38

Slide 38 text

● どのLBに通信が来ても同じ挙動をする必要 がある ○ 独立してコネクション 管理するとダメ スケールアウトさせるには 身に覚えのない コネクション ECMP クライアントは 1コネクションしか張っていな いので 1台としか通信できない コネクション確立済

Slide 39

Slide 39 text

● こうなってほしい ○ 全台が同じ情報を持った状態 ○ とはいえLB間でコネクションの情報を リアルタイムに同期するのは難しい スケールアウトさせるには コネクション確立済 ECMP ECMP 必ず1対1で通信が 成立する状態！

Slide 40

Slide 40 text

Consistent Hashing ● http://www.slideshare.net/paulowniaceae/consistent-hash

Slide 41

Slide 41 text

Consistent Hashing ● 円を用意します ● ハッシュ関数を使って適当に サーバを置きます

Slide 42

Slide 42 text

Consistent Hashing ● ハッシュ関数を使って適当にサーバと クライアントを 振り分けます ○ 5-tupleを使う hash((srcIP, srcPort, dstIP, dstPort, proto))

Slide 43

Slide 43 text

Consistent Hashing ● 各サーバは時計回り方向のクライアントを 処理する

Slide 44

Slide 44 text

● 複数LBでも一意な転送ができる！ Consistent Hashing hash( ) hash( ) Maglev nodes

Slide 45

Slide 45 text

● スケールアウトしても担当が変わる サーバが最小限 Consistent Hashing ↑増えた hash( ) hash( ) Maglev nodes

Slide 46

Slide 46 text

● バックエンドの数が変わっても均一にしたい 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 ]

Slide 47

Slide 47 text

Maglevのアーキテクチャ: DSR

Slide 48

Slide 48 text

DSR ● 前述のL3 DSR ○ GREでカプセリング ■ IPIPのようにヘッダを付加する方式 IP TCP Data IP TCP Data IP IP TCP Data LBでIP + GREヘッダを1つ足す サーバでIP + GREヘッダを1つ取る GRE

Slide 49

Slide 49 text

Maglevとは

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

今日話さなかったこと

Slide 52

Slide 52 text

疑問 ● GCPはHTTP ロードバランサ(L7)も 用意されてるがどんな仕組みなのか ● 1ノードあたりの性能高すぎない？ ○ ショートパケットでも10Gbps出るらしい ■ ユーザ空間でパケットを処理 (Intel DPDK的な)してるらしい

Slide 53

Slide 53 text

ご清聴ありがとうございました