高性能・低コスト・高拡張性のレイヤ7負荷分散 ソフトウェアを

高性能・低コスト・高拡張性のレイヤ7負荷分散
ソフトウェアをOSSとして国内初の取り組み
~プロジェクトの概要と最新動向~
2009.7.1
@OpenSource World 2009
竹林 信哉
https://sourceforge.jp/projects/ultramonkey-l7/
1
Agenda
■ UltraMonkey-L7 とは何か






■
高速化への取り組み


■
ロードバランサとは
ソフトウェアとしてのロードバランサについて
UltraMonkey-L7 とは
コミュニティについて
これまでの活動
開発ロードマップ
lockfree 型の開発
atomic 型の開発
おわりに
2
UltraMonkey-L7 とは何か
ロードバランサとは何か
ソフトウェアとしてのロードバランサのメリット
コミュニティ活動について
3
ロードバランサとは
■ ロードバランシング( Load


Balancing )・・・負荷分散
ひとつの仕事を複数のメンバで行うことで,効率化を図る
例: コールセンタ
➔ 代表番号で受け付け,各受付デスクへ転送する
ひとりで電話番
実際のコールセンタ
すぐつながる
他が対応中の場合は
待たされる
03-1234-5678
代表番号
一人で全員の相手を
する必要がある
ロードバランサ
(負荷分散装置)
一人あたり対応する
件数は少ない
03-1234-5678
・・・・・・・・・
#0001
#0002
#0099
#0100
4
ソフトウェアとしてのロードバランサのメリット
■ ハードウェアとしてのロードバランサは,「ネットワーク機器」として独立して配置
する必要がある
■ ソフトウェアロードバランサは,別筐体にすることなく HTTP サーバなどと同居さ
せることができる

物理的な機器が減ることで,コスト削減につながる
ロードバランサを独立して配置する例
(従来型)
ロードバランサが
独立して設置される
これが意外と高価
ロードバランサを HTTP サーバに含める例
入り口は一カ所だが
自分自身の筐体のサーバと
他方のサーバで処理する
5
UltraMonkey-L7 とは
■ Layer-7 に対応したロードバランサ

通信内容に応じて振り分け先サーバを選択できる
例)
HTTP のリクエスト URL による振り分け先サーバの固定
➔ SSL 通信のセッション再利用
➔

プロプライエタリのプロトコルに対応するモジュールを自作することも可能
■ Linux


Kernel 2.6 以降のディストリビューションで動作
RHEL をはじめ, Debian GNU/Linux , OpenSuSE , Ubuntu で確認
IA サーバ( x86 , x86_64 ),玄箱( PowerPC ), PS3 ( Cell BE )でも動作
■ 冗長構成も構築可能


HA クラスタと組み合わせることで,耐障害性の高いロードバランサとなる
Heartbeat による冗長化を検証済み
6
同居構成時のパフォーマンス
■
下記の環境で計測したところ,転送レート※は 900Mbps を記録した

商用 LB アプライアンスに迫る性能
Client × 2
hp DL140G3(bnx2)
RHEL5.2 / JMeter 2.3.1
LB → クライアントの転送レート
900Mbps を達成
LB/HTTP Server × 2
hp DL380G5(e1000) / hp DL360G5(e1000)
RHEL5.2 / Aapche 2.2.3
1000Base-T Ethernet
requests / responses flow
※ ここでは,データリンク層での転送レートとしている.
7
コミュニティについて
■
公式サイト

http://sourceforge.jp/projects/ultramonkey-l7/
■
コミュニティメンバ

総数 10 名
➔ コミッタは 5 名ほど,その他メンバはドキュメント整備や検証など
➔
一部のメンバは「超猿自転車部」に所属
■
メーリングリスト登録数( 2009 年 6 月 17 日時点,重複登録含む)

ユーザグループ( ultramonkey-l7-users )
➔ 121 名

■
開発グループ( ultramonkey-l7-develop )
➔ 47 名
検証環境

hp 社 DL380 などエンタプライズ用途のマシンにて性能・機能検証を実施

10GbE (光ケーブル接続) 環境での検証も実施予定
8
これまでの活動
■ 起源は, LVS
(Linux Virtual Server) を利用した UltraMonkey-L4
■ IPA の「 2004 年度下期オープンソースソフトウェア活用基盤整備事業」に採択
され, NTT コムウェアの開発部隊で開発・ OSS として公開された
■ 2008 年度以降,運営はコミュニティ主体にシフトされ,現在は外部からのパッチ
受け入れなども積極的に行っている
2005
v.0.2.0
v.0.2.0
2005.10.21
2005.10.21
初版リリース
初版リリース
2006
2007
v.0.6.0
v.0.6.0
2007.5.15
2007.5.15
接続クライアント数拡大
接続クライアント数拡大
2008
v.1.0.1-0
v.1.0.1-0
2008.1.8
2008.1.8
sessionless
sessionless 追加
追加
v.1.0.0-0
v.1.0.0-0
2007.10.22
2007.10.22
スケジューラの拡充など
スケジューラの拡充など
v.2.0.0-0
v.2.0.0-0
2008.6.3
2008.6.3
epoll
epoll 実装
実装
v.2.0.0-1
v.2.0.0-1
2008.8.14
2008.8.14
バグ修正
バグ修正
2009
v.2.1.1-0
v.2.1.1-0
2009.1.27
2009.1.27
sslid
sslid 改善
改善
v.2.1.2-2
v.2.1.2-2
2009.5.19
2009.5.19
sslid
sslid 改善
改善
v.2.1.2-0
v.2.1.2-0
2009.3.10
2009.3.10
ソース
ソース IP
IP パーシステンス
パーシステンス
追加
追加
v.2.1.0-0
v.2.1.0-0
2008.12.17
2008.12.17
sslproxy
sslproxy 実装
実装
v.2.1.2-1
v.2.1.2-1
2009.4.14
2009.4.14
バグ修正
バグ修正
「機能」の実装 ・・・・・・・・・・・・・・・・・・・エンタプライズ用途, 「性能」の追求
9
今後の開発ロードマップ
■
2009 年度は,性能改善と基本的な機能の整備を行う
■
2010 年度以降,利便性を重視した活動に注力する予定
2009 年度
2010 年度以降
・性能の改善
・性能の改善
・マルチスレッド化
・マルチスレッド化
・機能の拡充
・機能の拡充
・対応プロトコルの強化
・対応プロトコルの強化
・周辺ツールの拡充
・周辺ツールの拡充
・機能の拡充
・機能の拡充
・・ IPv6
IPv6 対応
対応
・・ SNMP
SNMP 対応
対応
・・ GUI
GUI 作成
作成
・ユーザビリティの整備
・ユーザビリティの整備
・構築ドキュメント類の拡充
・構築ドキュメント類の拡充
・周辺ツールの拡充
・周辺ツールの拡充
・・ et.,al...
et.,al...
10
高速化に向けた取り組み
マルチスレッド実装に向けた工夫
新しい型( lockfree type,atomic type )の開発
11
高速化に向けた取り組み (1) – lockfree 型の開発
■
たとえば, std::queue は遅くて使えない

マルチスレッド化するにあたり,スレッドプールの管理法として queue を使用
する事になった
accept したソケットをスレッドプールから dequeue したスレッドに渡し,
バランシング処理を行う
➔ disconnect されたらスレッドプールに enqueue する
➔

しかし, std::queue をただ使うだけでは具合が悪い
➔
atomic access =資源のロックが必要
- ロック解放待ちが発生する
-
queue 全体を排他ロックする必要がある
. dequeue している間は enqueue できない
. dequeue が起こるタイミングは分かるが, enqueue されるタイ
ミング( disconnect されるタイミング)は予測できない
.
enqueue と dequeue のタイミングが重なると,待ちが発生する
12
高速化に向けた取り組み (1) – lockfree 型の開発 (Cont'd)
■
lockfree queue は,書き換えが必要な部分のみをロックする

critical section に入ったときに排他ロックの対象となる範囲が狭い
std::queue の場合・・・ dequeue している間は enqueue できない
node0
node0
head
head
node1
node1
node2
node2
node3
node3
node5
node5
tail
tail
node6
node6
node5
node5
tail
tail
node6
node6
lockfree queue の場合・・・ dequeue している途中でも enqueue できる
node0
node0
head
head
node1
node1
node2
node2
node3
node3
書き換える対象が確定したときのみ,バスをロックする
= dequeue しながら enqueue できる
Locked
LockedNode
Node
Targeted
TargetedNode
Node
13
高速化に向けた取り組み (1) – lockfree 型の開発 (Cont'd)
■
そこで,新しい型( lockfree_queue )を定義した

head と tail は別にロックできるようにした
➔ enqueue がぶつかった時, dequeue がぶつかった時のみブロックする

■
CAS ( Compare-And-Swap )命令を使用した
➔ TAS ( Test-And-Set )では不可能だった atomic 性を保証
➔ gcc 拡張の __sync_var_compare_and_swap() 関数
性能を計測したところ,大幅な性能改善が認められた
50 threads
atomic_queue
std::queue
+
mutex lock
速度比
100 threads
500 threads
405647
5334341
16023805
43306702
68673166
56372687
107 倍
13 倍
4倍
単位: clokcs
14
高速化に向けた取り組み (2) – atomic 型の開発
■
従来の mutex lock は無駄が多く,使えない

解放待ちのブロッキングによって全体の処理速度が下がる
■
そこで,独自の型( atomic_t )を定義した

fetch_and_add 方式を採用

gcc 拡張の __sync_fetch_and_add() 関数など
■
atomic_t を実装した結果,大幅な性能改善が認められた
50 threads
100 threads
500 threads
atomic_t
158945595
120109021
113173877
primitive type
+
mutex lock
1319899278
2076859681
2777438142
8倍
17 倍
25 倍
速度比
単位: clokcs
15
おわりに
■
メンバ急募!!


開発メンバとして
➔ ネットワークに詳しい方!
➔ Linux kernel に詳しい方!!
➔ gcc に詳しい方!!!
ユーザとして
➔ 使ってみたい方!
- 初歩的な質問でも強力サポートいたします
➔
■
積極的に要望を挙げていただける方!
- いただいた要望は前向きに検討します
まずはユーザグループの ML に登録を!

http://sourceforge.jp/projects/ultramonkey-l7/lists/
16