CyberAgent, Inc. All Rights Reserved

Maglev:A Fast and Reliable SoftwareNetwork 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/2013_11_01_archive.html

● 1IPアドレス/ウォームアップなしでいきなり

100万RPSをさばける

○ グローバルな

■ 負荷分散

■ 障害耐性

○ ソフトウェアLB

余談: 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)

example.com(198.51.100.4)

Aレコードが複数あった場合に毎回違うものが帰ってくるのを利用

(AWSのELBは前述のLBとDNS RRの組み合わせ)

ロードバランサ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.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する！)

● 戻りトラフィックがどんなに大きくても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ヘッダを付加する(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

セグメントをまたぐ

戻りのパケットはカプセリング不要

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

コネクション確立成功！

connectiontracking

Connection Trackingのしくみ

● 5-tuple○ 　

● 5-tupleの組み合わせで転送先を固定する

● これでコネクションが維持される

● ここまでは普通

○ (前述の3種類のLBもやってる)● どうやってこれをスケールアウトさせるか

○ => 分散 Connection Trackingを実装したい！

スケールアウトさせるには

● どの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-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]

Maglevのアーキテクチャ:DSR

DSR

● 前述のL3 DSR○ GREでカプセリング

■ IPIPのようにヘッダを付加する方式

IP TCP Data

IP TCP DataIP

IP TCP Data

LBでIP + GREヘッダを1つ足す

サーバでIP + GREヘッダを1つ取る

GRE

Maglevとは

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的な)してるらしい

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