高性能・低コスト・高拡張性のレイヤ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
© Copyright 2025 Paperzz
