1.
組み込みスクリプト言語mrubyを利用した Webサーバの機能拡張支援機構松本 亮介 （京都大学 大学院情報学研究科）岡部 寿男 （京都大学 学術情報メディアセンター） 平成24年度第2回IOT研究会 2012/6/29

2.
今日の発表1. 背景2. Apacheモジュールと機能拡張3. mruby4. mod_mruby5. パフォーマンス評価6. まとめ See Also http://blog.matsumoto-r.jp 2012-06-15 (金) • mod_mruby、mod_lua、mod_perl、mod_rubyのアーキテクチャの 違いと性能 2012-05-28 (月) • mod_mrubyとApache（Nginx）の関係を図示してみた … 2 平成24年度第2回IOT研究会 2012/6/29

3.
1. 背景3 平成24年度第2回IOT研究会 2012/6/29

4.
Webサービスの高度化 様々なWebサービスが普及  クラウド・ソーシャルネットワーキングサービス  Webサーバの利用頻度の急激な増加  Webコンテンツのチューニングが非常に重要 セキュリティ、パフォーマンス、大規模、運用技術の問題  Webコンテンツの最適化だけでは対応困難  Webサーバソフトウェア自体の拡張で対応  ミドルウェアレイヤーでのセキュリティ担保  Webサーバのオートスケール  細やかなリソースチューニング 4 平成24年度第2回IOT研究会 2012/6/29

5.
Webサーバソフトウェアの拡張 拡張の敷居が高い（Apacheの場合）  C言語で実装（生産性が課題）  コンパイルや保守性の問題  Apacheの内部仕様の深い理解が必要 近年のニーズ C言語の高速性や軽量さ ⇒ スクリプトによる保守性や生産性 スクリプトによる機能拡張のインターフェイスを実装  Webサーバの内部機能拡張をスクリプトで実装可能  高速に動作する実装が必要 5 平成24年度第2回IOT研究会 2012/6/29

6.
本研究 新しいApacheの機能拡張支援機構 mod_mruby  mod_mrubyの特徴 1. 高速に動作 2. Apacheを停止する事なく内部処理を変更可能 3. Apacheの内部機能をRubyで記述可能  Apache内部の処理を外部のRubyスクリプトでコントロール  リバースプロキシや複雑なリダイレクトを柔軟に記述可能  組み込みスクリプト言語mrubyを採用  軽量、高速、C言語への組み込みが得意、移植性が高い  Rubyの記述で実装可能 本発表ではmod_mrubyの提案と高速性の評価 6 平成24年度第2回IOT研究会 2012/6/29

7.
2. Apacheモジュールとこれまでの機能拡張支援機構7 平成24年度第2回IOT研究会 2012/6/29

8.
Apacheモジュールとは Apacheモジュール  Apacheの内部機能を拡張するためのモジュール  Apacheのコアに必要な機能をモジュールで組み込む  C言語で実装するため高速かつ軽量に動作  生産性や保守性、即時性に問題 Apache module 1 Apache module 2 Apach Apach 処理の変更にはC言語のソー e e Apache module 3 Core API ス変更・コンパイル・組み込み・ ・ Apache再起動が必須 ・ ・ ・ Apache module n 8 平成24年度第2回IOT研究会 2012/6/29

9.
既存のスクリプトによる機能拡張支援 スクリプトで機能拡張を実現  mod_lua 、mod_perl、mod_ruby、mod_python… Apache module 1 Apache module 2 Apache module ・ n ・ ・Apach Apach e e Core API script 1 Apache起動中でも script 2 即時処理を変更可能 mod_** API * ・ ・ script n ・ ・

10.
既存スクリプトによる機能拡張支援 本研究 従来の機 mod_ mod_perl mod_lua mod_ 能拡張 ruby mruby 言語 C Perl Ruby Lua mruby初期化処理 ** 事前 事前 都度 事前 ライブラリ 読み込み ** 事前 事前 都度 事前 コンパイル 事前 都度 都度 都度 都度コードの変更 不可 可 可 可 可グローバル状態 共有 共有 共有 非共有 非共有 高速性と柔軟性と生産性を達成するアーキテクチャを目指す 10 平成24年度第2回IOT研究会 2012/6/29

11.
3. mruby11 平成24年度第2回IOT研究会 2012/6/29

12.
mrubyとは 近年の組み込みソフトウェア開発  C言語が主流 ⇒ 生産性向上が課題  短納期、高品質、大規模  本研究と問題意識が類似  組み込みスクリプトとしてはLuaが中心  WebサービスではRubyによる生産性向上が推進  組み込み系とWeb系技術者や研究者が協力  2010年度 経済産業省の地域イノベーション創出研究開発事業  「軽量Rubyを用いた組込みプラットフォームの研究・開発」採択 12 平成24年度第2回IOT研究会 2012/6/29

13.
mrubyとは C言語と連携が強力な組み込みスクリプト言語mruby 1. 高速に動作（スクリプト言語最速のLuaを参考） 2. Rubyの最小限の機能でメモリフットプリントが軽量 注目 3. Rubyによる記述で生産性が向上 4. ISOのC99で規定されたC言語で高い移植性 5. 内部構成がコンポーネント化 6. OSを必要とせず小規模な組み込みシステムで動作 特に注目した点  インタプリタを複数スクリプトで共有して切り替えて実行可能 13 平成24年度第2回IOT研究会 2012/6/29

14.
4. mod_mruby14 平成24年度第2回IOT研究会 2012/6/29

15.
mod_mrubyとは 特徴 1. 高速に動作 2. Apacheの内部処理をRubyの記述でコントロール 3. グローバル変数や関数の扱いをスクリプトで完結 4. Apacheの内部処理をリスタートする事なく変更可能 出来ることの例  オリジナルのリバースプロキシ（20行程度）  複雑な条件によるリダイレクト  サーバの負荷によって処理を変更  Apacheの内部情報を利用したアクセス制御 15 平成24年度第2回IOT研究会 2012/6/29

16.
高速性• 既存ではmod_luaが最も高速 – Luaはスクリプト言語で最速とされている – mod_luaのアーキテクチャは高速性を犠牲にしてい る • mod_perlやmod_rubyの問題を改善 – スクリプト実行毎にインタプリタをロード – グローバル変数や関数を複数スクリプトで干渉させない • それでもmod_perlやmod_rubyより高速 – Lua自体の高速処理の恩恵 – Apacheの内部制御を目的としているため低機能でも良い mod_mrubyでは高速性を生かしつつ 16 グローバル変数や関数の干渉問題を解決 平成24年度第2回IOT研究会 2012/6/29

17.
mod_luaのアーキテクチャ Luaスクリプトがフック ボトルネック 状態遷移保存領域（Lua_state）の確保 ライブラリ読み込み mod_lua Luaスクリプト読み込み アークテクチャ 構文木を解析 バイトコード生成 VM上で実行 17

18.
状態遷移保存領域に関するmrubyとLuaの違い• 状態遷移保存領域を複数のスクリプトで共有する場合 – Luaの場合 • 共有している他のスクリプトのfunctionを実行できる • Webコンテンツやモジュールスクリプトで関数が干渉 – mrubyの場合 • それぞれのバイトコードは状態遷移保存領域に保存 • C側でバイトコードにアクセスするメソッドやインターフェイス を定義しない限りはmruby側から通常干渉する事は無い 18 平成24年度第2回IOT研究会 2012/6/29

19.
mod_mrubyのアーキテクチャ mrubyスクリプトがフック 1サーバプロセス単位 1状態遷移保存領域 状態遷移保存領域 （mrb_state） とライブラリを共有 mod_mruby mrubyスクリプト読み込み アーキテクチャ 構文木を解析 バイトコード生成 VM上で実行 19

20.
mod_mrubyのアーキテクチャ• Apacheのサーバプロセスとmrubyの関係 – 子サーバプロセス単位でmrb_stateとVMを保持 – フックされたファイルをそれぞれバイトコードにコンパイルして保存親サーバプロセス バイトコード1 状態遷移保存領域A VM 子サーバプロセスA バイトコード2 A （mrb_state) ・ 拡張ライブラリ ・ ・ ・ バイトコード1 状態遷移保存領域B VM 子サーバプロセスB （mrb_state) バイトコード2 B ・ ・ ・ 拡張ライブラリ ・ ・ 20 ・ ・ ・

21.
5. パフォーマンス評価21 平成24年度第2回IOT研究会 2012/6/29

22.
実験• クライアントからWebサーバにアクセスして処理性能を評価 • 同一処理をApacheモジュール・mod_lua・mod_mrubyで実装して比較 • どのURLにアクセスしても“Hello World”出力する内部機能 • 同時接続数100総接続数10万アクセスで評価 • サーバプロセスの生成破棄が発生しないようにチューニング クライアント CPU Intel Core2Duo E8400 3.00GHz Memory 4GB NIC Realtek RTL8111/8168B 1Gbps OS CentOS 5.6 Webサーバ CPU Intel Xeon X5355 2.66GHz Memory 8GB NIC Broadcom BCM5708 1Gbps OS CentOS 5.6 Middle Ware Apache 2.2

23.
実験結果 mod_hell mod_ mod_ mod_perl mod_lua o ruby mruby （C言語） （本研究） 言語 C Perl ruby Lua mruby 初期化処理 ** 事前 事前 都度 事前 ライブラリ ** 事前 事前 都度 事前 読み込み コンパイル 事前 都度 都度 都度 都度 コードの変更 不可 可 可 可 可グローバル状態 共有 共有 共有 非共有 非共有 性能 9861.1 3346.3 4769. 5209.1 8225.7(Response/s ec) 7 8 04 1 8

24.
考察• mod_helloで処理した場合と比較 – mod_mrubyは83.4%の性能 – mod_luaは52.8%の性能 – mod_rubyは48.3%の性能 – mod_perlは33.9%の性能• mod_mrubyとmod_luaの差 – 状態遷移保存領域（mrb_state）とライブラリを共有したため – mod_mrubyで共有していない場合は30%程度の性能 • 言語としてはLuaの方がmrubyより高速だと推測 • ただし5月時点 • その後もmruby自体の改修は活発に進んでいる 24 平成24年度第2回IOT研究会 2012/6/29

25.
6. まとめ25 平成24年度第2回IOT研究会 2012/6/29

26.
まとめ mod_mrubyの提案と高速性の評価  高速性  C言語でモジュールを作った場合と比べて83.4%の性能  既存のスクリプト機能拡張支援よりも大幅に高速  インタプリタを複数スクリプトで共有  柔軟性  グローバル変数やFunctionも干渉しない  生産性  Rubyによる記述やApacheのリスタート不要 Apacheの内部処理拡張において 生産性と保守性を重視した場合の選択肢となりうる性能 26 平成24年度第2回IOT研究会 2012/6/29

27.
まとめ 今後の課題  メモリフットプリントの評価  フックフェーズや拡張ライブラリを随時実装  バイトコードのキャッシュ機構を実装  Riteバイナリでのモジュール組み込みに対応  Nginxにもngx_mrubyを実装  mrubyで複数のWebサーバソフトウェアの機能拡張を吸収 mruby script 1 Nginx Nginx ngx_mruby mruby script 2 Core API mruby API mruby script 3 for mruby scriptApach Apach Web ・ n mod_mrub ・ e e ・ y ・ Core API 27

28.
ご清聴ありがとうございました ご質問はブログ blog.matsumoto-r.jp または @matsumotory （twitter） へ28 平成24年度第2回IOT研究会 2012/6/29