ネットワークの負荷分散を手軽に - OSC2015 Hokkaido

ネットワークの負荷分散を手軽に！
2015.06.13 Shinya TAKEBAYASHI

商標について
▪ F5，F5 Networks，F5 のロゴ，および本文中に記載されている製品名は，米国および他
の国における F5 Networks, Inc の登録商標または商標です．
▪ Microsoft および Microsoft Azure は，米国 Microsoft Corporation の米国およびその他
の国における登録商標または商標です．
▪ CentOS の名称およびそのロゴは，CentOS ltd の登録商標または商標です．
▪ その他本文中に記載されている製品名および社名は，それぞれ各社の登録商標または商標
です．
▪ 本文中では ® および ™ の表記は省略しています．

本日のお話
▪ ネットワークの負荷とは何か
▪ 負荷を分散するとはどういうことか
▪ どのようにして負荷を分散するのか
▪ 負荷分散装置を作ってみる
【前提】
Ethernet / IPv4 / TCP での通信を前提にお話します．

自己紹介
▪ 竹林信哉
▪ UltraMonkey-L7 の開発者（元・プロジェクトマネージャ）
▪ 某 SIer にて，開発プロジェクトに対する Java の技術支援を行っている．
▪ 入社当初（10 年前）は CGL（Carrier Grade Linux）の開発に従事．
@chi9rin

ネットワークの負荷とは
▪ ネットワークの伝送路の混み具合
▪ たくさんのデータが流れる → 「負荷が高い」
流量が少ない
【負荷が低い】
流量が多い
【負荷が高い】
レスポンスが遅い
処理が追いつかない
【負荷が高い】

負荷が高くなる要因は様々
▪ アクセスするクライアントが多い
▪ 変なプロトコルを使っている
▪ 途中のネットワーク機器が遅い
▪ 途中のネットワーク機器が故障して
迂回させられている
▪ ネットワークが細い
▪ ホストの処理能力が低い
▪ ・・・
どれか一つのみが
原因であることは少ない．
一つの原因が不具合を招き，
それがさらに・・・というパタン．

負荷が高くなる要因は様々
▪ アクセスするクライアントが多い
▪ 変なプロトコルを使っている
▪ 途中のネットワーク機器が遅い
▪ 途中のネットワーク機器が故障して
迂回させられている
▪ ネットワークが細い
▪ ホストの処理能力が低い
▪ ・・・
自分で何とか出来る
分散すればいい
あきらめる

負荷を分散するとは？
▪ ネットワークが細い → アクセスラインを複数用意し，分散する
▪ Teaming（Bonding）の Link Aggregating
▪ CDN（ネットワーク的に近いところにアクセスさせる）
▪ ホストの処理能力が低い → 複数のホストで処理をする
▪ 同じ処理をするホストを複数並べ，リクエストごとに処理するホストを切り替える．
▪ 処理性能を上げるクラスタリングの一種．

つまり，こういうこと
流量が少ない
流量が少ない
LB
負荷分散装置で
複数ホストへ分散する
Teaming で帯域を
広げる

負荷分散のイメージ - ネットワークの負荷分散
▪ 複数の物理配線を用いて，伝送路の混雑を低減する
▪ 一般に NIC Teaming（Linux では Bonding）と呼ばれる
本ページは Link Aggregation（IEEE 802.3ad）の例
▪ 1000BASE-T を 3 本束ねて約 3Gbps のラインとして利用する，など
▪ 対応するネットワークスタック，スイッチが必要
まとめて一本に見せる

負荷分散のイメージ - ホストの負荷分散
▪ 負荷分散装置を利用し，通信パケットの振り分け，複数のホストで処理する
▪ クライアントは hoge.example.com に向かってアクセスするが，実際に到達するのは foo だったり
bar だったり．
▪ クライアントからはひとつのホストに見える（負荷分散されていることがわかりにくい）
http://hoge.example.com/
foo.example.com
bar.example.com
LB
hoge.example.com
まとめて一台に見せる

本日は「手軽に！」がお題．
NIC チーミングは手軽ではない（お金がかかる）ので，
簡単にできる「ホストの負荷分散」について話を進めます．

ホストの負荷分散に必要なもの
1. 負荷分散装置（下図 LB，ロードバランサ）
2. リクエストを処理するマシン
3. ネットワーク配線
foo.example.com
bar.example.com
LB
hoge.example.com
(1) 負荷分散装置
(2) 処理するマシン
(3) ネットワーク配線

ホストの負荷分散の仕組み（本例は NAT 構成※）
1. LB が代表して hoge.example.com 宛てのリクエストを受け付け，実際に処理するサーバ
（リアルサーバと呼ばれる）を決定，パケットを転送する．
2. リアルサーバがリクエストを処理し，レスポンスを作成する．
3. LB が代表してレスポンスをクライアントに返却する．
foo.example.com
bar.example.com
LB
hoge.example.com
(1) 代わりに受け取り
(2) 処理を割り振って
(3) 代わりに返す
※ NAT の他に有名どころとして DSR 構成がある．DSR については後述．

ホストの負荷分散をすると，全体の負荷が減る
流量が少ない
流量が少ない
LB
レスポンスが良い
さくさく返せる

• Layer 4 Load Balancing
• 適している通信： POP3，IMAP など
• 宛先 IP アドレスとポート番号までを見る．
• TCP セッションの中でアプリケーションセッションが
完結する処理に向いている．
• Layer 7 Load Balancing
• 適している通信： HTTP，FTP PASV など
• 通信される電文の中身まで見て，負荷分散する．
• たとえば，HTTP のリクエスト文字列など．
負荷分散の方式
▪ 大きく分けて二種類．何をもとに分散するかで選択．
Application
Presentation
Session
Transport
Network
Data Link
PHY
MAC Address …
1000BASE-T …
IP Address …
TCP / UDP Port …
TCP Context …
SSL Context …
Request URL …
Performance
Flexibility

すごい Layer 7 Load Balancing
▪ たとえば HTTP リクエストに応じて，処理をするサーバを分けることが可能．
▪ WebAPI を公開していたり，静的なファイルのみ別のサーバに保管してある場合などに便利．
▪ Cookie に入っている認証情報を使って HTTP セッションを維持する機能をもつ製品もある．
LB
v1.api.example.com
v2.api.example.com
http://api.example.com/api/v2/friends
api.example.com
/api/v1/* は v1.api.～へ
/api/v2/* は v2.api.～へ
/api/v1/friends
/api/v2/friends
http://api.example.com/api/v1/friends

すごい Layer 4 Load Balancing
▪ アクセス元 IP アドレスやポート番号をベースに負荷分散するのが主流．
アプリケーションで扱う電文やセッションは無視．機能面では L7 に見劣りするが・・・
▪ L4 LB では，DSR（Direct Server Return）方式が利用可能で，ネットワーク負荷の低
減が可能
▪ L7 の場合は IP パケットの解析が必要となるため，基本的には「クライアント - LB」「LB - リアルサー
バ」の 2 コネクションが必要で，しかも通信の行きと帰りが同じルートになる（NAT 以外は難しい）
そのため，LB がボトルネックになる可能性がある．

NAT の通信の流れ
LB
192.168.0.102
AA:BB:CC:DD:EE:02
192.168.0.1
AA:BB:CC:DD:EE:00
192.168.0.101
AA:BB:CC:DD:EE:01
192.168.100.1
EE:DD:CC:BB:AA:00
SW
192.168.0.1
AA:BB:CC:DD:EE:00
192.168.0.101
AA:BB:CC:DD:EE:01
192.168.0.1
AA:BB:CC:AA:BB:01
192.168. 0.1
AA:BB:CC:AA:BB:00
AA:BB:CC:AA:BB:00 / AA:BB:CC:AA:BB:01
宛先 IP アドレス
宛先 MAC アドレス
192.168.100.1
EE:DD:CC:BB:AA:00
192.168.100.1
AA:BB:CC:AA:BB:01
TCP コネクションは 2 つ（緑線，紫線）

DSR とは
▪ LB，リアルサーバともに同じサブネットに，同じ IP アドレスを持っている（！）
▪ LB は Ethernet フレームにある宛先 MAC アドレスをリアルサーバの MAC アドレスに付けかえ
て再度放流（！！）
▪ 指定された MAC アドレスをもつリアルサーバが放流されたパケットに食らいつき，レスポンスを
生成．（！！！）
▪ 帰りは通常のルーティングをして返す．．．
▪ TCP コネクションは，リアルサーバとクライアントの間で構築される
▪ LB は上り（クライアント→サーバ）パケットの MAC アドレスを付け替えて転送するだけ
Direct に Server と Client がセッションを構築し，レスポンスが Return される．

DSR の通信の流れ
LB
192.168.0.102
192.168.0.1
AA:BB:CC:DD:EE:02
192.168.0.1
AA:BB:CC:DD:EE:00
192.168.0.101
192.168.0.1
AA:BB:CC:DD:EE:01
192.168.100.1
EE:DD:CC:BB:AA:00
SW
192.168.0.1
AA:BB:CC:DD:EE:00
192.168.0.1
AA:BB:CC:DD:EE:01
192.168. 0.1
AA:BB:CC:AA:BB:00
AA:BB:CC:AA:BB:00 / AA:BB:CC:AA:BB:01
宛先 IP アドレス
宛先 MAC アドレス
TCP コネクションは 1 つ（緑線）
192.168.100.1
EE:DD:CC:BB:AA:00
192.168.100.1
AA:BB:CC:AA:BB:01

理屈は分かる．すごくいい．
でもお高いんでしょ？

いろいろな製品があります，OSS も．
▪ 有償プロダクト（アプライアンス含む）
▪ F5 Networks 「BIG-IP」【ハードウェア／ソフトウェア】
▪ FUJITSU 「IPCOM」【ハードウェア】
．．．
▪ オープンソースソフトウェアプロダクト※
▪ Apache mod_proxy_balancer
▪ nginx
▪ UltraMonkey
．．．
※ OSS は無料と言われますが，お金がかからないというだけ．使い捨てられるのは気持ちよくありません．
コミュニティへのフィードバックを是非お願いします．

でも難しいんでしょ？

LB を作ってみます
▪ 登壇者が UltraMonkey-L7 の開発者なので，今回は UltraMonkey-L7 を使います
▪ NAT 方式
▪ Round Robin 方式（全ての利用可能なリアルサーバに，一様に負荷を分散する）
▪ Microsoft Azure 上の仮想マシンに作ります
▪ 基本的な環境ができあがっている CentOS にセットアップします
▪ リアルサーバは設定済みです

作る環境
monkeydemo.cloudapp.net
loadbalancer
realserver1
realserver2

まとめ
▪ 負荷分散は簡単にできます
▪ ソフトウェアロードバランサのセットアップは簡単で，既存ネットワークの影響は大きくありません
▪ 用途に応じて，L4 または L7 を選ぶと良いです
▪ それぞれに特徴があり，また，既存のネットワーク構成によっては適用できる構成に制限が生じます

最後に
UltraMonkey-L7 の宣伝

UltraMonkey-L7 の宣伝
▪ Linux で動作するソフトウェアロードバランサ
▪ アクティブな開発者は 5 名ほど（すべて日本人）
▪ 某社の品質・性能試験をパスされたもののみリリースされる
▪ HA クラスタは Pacemaker を利用し，性能試験モデルは TPC-W
▪ 数千クライアントの同時接続を安定して高速に処理することを確認
▪ ソースコードのほか，バイナリとして X86 向けに RPM・DEB パッケージをリリース
▪ Raspberry Pi でも動きます（野良 make 必須）
▪ ユーザと開発者を随時募集中
http://osdn.jp/projects/ultramonkey-l7/

ネットワークの負荷分散を手軽に - OSC2015 Hokkaido

More Related Content

What's hot

Similar to ネットワークの負荷分散を手軽に - OSC2015 Hokkaido

ネットワークの負荷分散を手軽に - OSC2015 Hokkaido