1

高性能・低コスト・高拡張性のレイヤ7負荷分散ソフトウェアをOSSとして国内初の取り組み

～プロジェクトの概要と最新動向～

2009.7.1@OpenSource World 2009

竹林 信哉https://sourceforge.jp/projects/ultramonkey-l7/

2

Agenda

■UltraMonkey-L7 とは何か ロードバランサとは ソフトウェアとしてのロードバランサについて UltraMonkey-L7 とは コミュニティについて これまでの活動 開発ロードマップ

■ 高速化への取り組み

lockfree 型の開発 atomic 型の開発

■ おわりに

3

UltraMonkey-L7 とは何か

ロードバランサとは何かソフトウェアとしてのロードバランサのメリット

コミュニティ活動について

4

ロードバランサとは

■ロードバランシング（ Load Balancing ）・・・負荷分散 ひとつの仕事を複数のメンバで行うことで，効率化を図る 例： コールセンタ

➔ 代表番号で受け付け，各受付デスクへ転送する

ひとりで電話番

他が対応中の場合は待たされる

一人で全員の相手をする必要がある

実際のコールセンタ

すぐつながる

・・・・・・・・・

一人あたり対応する件数は少ない

代表番号

ロードバランサ（負荷分散装置）

03-1234-5678

03-1234-5678

#0001 #0002 #0099 #0100

5

ソフトウェアとしてのロードバランサのメリット

ロードバランサを独立して配置する例（従来型）

ロードバランサを HTTP サーバに含める例

■ハードウェアとしてのロードバランサは，「ネットワーク機器」として独立して配置する必要がある

■ソフトウェアロードバランサは，別筐体にすることなく HTTP サーバなどと同居させることができる

物理的な機器が減ることで，コスト削減につながる

ロードバランサが独立して設置されるこれが意外と高価

入り口は一カ所だが自分自身の筐体のサーバと

他方のサーバで処理する

6

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 による冗長化を検証済み

7

同居構成時のパフォーマンス

■ 下記の環境で計測したところ，転送レート※は 900Mbps を記録した 商用 LB アプライアンスに迫る性能

Client × 2 hp DL140G3(bnx2)

RHEL5.2 / JMeter 2.3.1

LB/HTTP Server × 2hp DL380G5(e1000) / hp DL360G5(e1000)

RHEL5.2 / Aapche 2.2.3

LB → クライアントの転送レート

900Mbps を達成

1000Base-T Ethernetrequests / responses flow

※ ここでは，データリンク層での転送レートとしている．

8

コミュニティについて

■ 公式サイト http://sourceforge.jp/projects/ultramonkey-l7/

■ コミュニティメンバ 総数 10 名

➔ コミッタは 5 名ほど，その他メンバはドキュメント整備や検証など➔ 一部のメンバは「超猿自転車部」に所属

■ メーリングリスト登録数（ 2009年 6月 17日時点，重複登録含む） ユーザグループ（ ultramonkey-l7-users ）

➔ 121 名

開発グループ（ ultramonkey-l7-develop ）➔ 47 名

■ 検証環境 hp社DL380 などエンタプライズ用途のマシンにて性能・機能検証を実施 10GbE （光ケーブル接続） 環境での検証も実施予定

9

2009200820072006

これまでの活動

■起源は， LVS (Linux Virtual Server) を利用した UltraMonkey-L4

■ IPA の「 2004年度下期オープンソースソフトウェア活用基盤整備事業」に採択され， NTT コムウェアの開発部隊で開発・ OSS として公開された

■2008年度以降，運営はコミュニティ主体にシフトされ，現在は外部からのパッチ受け入れなども積極的に行っている

2005

v.0.2.02005.10.21初版リリース

v.0.2.02005.10.21初版リリース

v.0.6.02007.5.15

接続クライアント数拡大

v.0.6.02007.5.15

接続クライアント数拡大

v.1.0.0-02007.10.22

スケジューラの拡充など

v.1.0.0-02007.10.22

スケジューラの拡充など

v.1.0.1-02008.1.8

sessionless 追加

v.1.0.1-02008.1.8

sessionless 追加

v.2.0.0-02008.6.3

epoll 実装

v.2.0.0-02008.6.3

epoll 実装

v.2.0.0-12008.8.14バグ修正

v.2.0.0-12008.8.14バグ修正

v.2.1.0-02008.12.17

sslproxy 実装

v.2.1.0-02008.12.17

sslproxy 実装

v.2.1.1-02009.1.27sslid 改善

v.2.1.1-02009.1.27sslid 改善

v.2.1.2-02009.3.10

ソース IP パーシステンス追加

v.2.1.2-02009.3.10

ソース IP パーシステンス追加

v.2.1.2-12009.4.14バグ修正

v.2.1.2-12009.4.14バグ修正

v.2.1.2-22009.5.19sslid 改善

v.2.1.2-22009.5.19sslid 改善

「機能」の実装 ・・・・・・・・・・・・・・・・・・・エンタプライズ用途， 「性能」の追求

10

今後の開発ロードマップ

■ 2009年度は，性能改善と基本的な機能の整備を行う

■ 2010年度以降，利便性を重視した活動に注力する予定

・性能の改善 ・マルチスレッド化

・機能の拡充 ・ IPv6 対応 ・ SNMP 対応 ・ GUI 作成

・性能の改善 ・マルチスレッド化

・機能の拡充 ・ IPv6 対応 ・ SNMP 対応 ・ GUI 作成

2009年度

・機能の拡充 ・対応プロトコルの強化 ・周辺ツールの拡充

・ユーザビリティの整備 ・構築ドキュメント類の拡充 ・周辺ツールの拡充

・ et.,al...

・機能の拡充 ・対応プロトコルの強化 ・周辺ツールの拡充

・ユーザビリティの整備 ・構築ドキュメント類の拡充 ・周辺ツールの拡充

・ et.,al...

2010年度以降

11

高速化に向けた取り組み

マルチスレッド実装に向けた工夫新しい型（ lockfree type,atomic type ）の開発

12

高速化に向けた取り組み (1) – lockfree 型の開発

■ たとえば， std::queue は遅くて使えない

マルチスレッド化するにあたり，スレッドプールの管理法として queue を使用する事になった

➔ accept したソケットをスレッドプールから dequeue したスレッドに渡し，バランシング処理を行う

➔ disconnect されたらスレッドプールに enqueue する

しかし， std::queue をただ使うだけでは具合が悪い

➔ atomic access＝資源のロックが必要- ロック解放待ちが発生する

- queue 全体を排他ロックする必要がある. dequeue している間は enqueue できない

. dequeue が起こるタイミングは分かるが， enqueue されるタイミング（ disconnect されるタイミング）は予測できない

. enqueue と dequeue のタイミングが重なると，待ちが発生する

13

高速化に向けた取り組み (1) – lockfree 型の開発 (Cont'd)

■ lockfree queue は，書き換えが必要な部分のみをロックする critical section に入ったときに排他ロックの対象となる範囲が狭い

std::queue の場合・・・ dequeue している間は enqueue できない

lockfree queue の場合・・・ dequeue している途中でも enqueue できる

node0head

node0head node1node1 node2node2 node3node3 node5

tailnode5

tail node6node6

node0head

node0head node1node1 node2node2 node3node3 node5

tailnode5

tail node6node6

書き換える対象が確定したときのみ，バスをロックする＝ dequeue しながら enqueue できる

Locked NodeLocked Node

Targeted NodeTargeted Node

14

高速化に向けた取り組み (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 100 threads 500 threadsatomic_queue 405647 5334341 16023805

std::queue +

mutex lock43306702 68673166 56372687

速度比 107倍 13倍 4倍単位： clokcs

15

高速化に向けた取り組み (2) – atomic 型の開発

■ 従来の mutex lock は無駄が多く，使えない 解放待ちのブロッキングによって全体の処理速度が下がる

■ そこで，独自の型（ atomic_t ）を定義した fetch_and_add 方式を採用 gcc 拡張の __sync_fetch_and_add()関数など

■ atomic_t を実装した結果，大幅な性能改善が認められた

50 threads 100 threads 500 threadsatomic_t 158945595 120109021 113173877

primitive type+

mutex lock1319899278 2076859681 2777438142

速度比 8倍 17倍 25倍単位： clokcs

16

おわりに

■ メンバ急募！！

開発メンバとして➔ ネットワークに詳しい方！➔ Linux kernel に詳しい方！！➔ gcc に詳しい方！！！

ユーザとして➔使ってみたい方！

- 初歩的な質問でも強力サポートいたします

➔積極的に要望を挙げていただける方！- いただいた要望は前向きに検討します

■ まずはユーザグループの ML に登録を！ http://sourceforge.jp/projects/ultramonkey-l7/lists/