Webサーバの高集積マルチテナント
アーキテクチャに関する研究
松本の研究を通じて高集積ホスティングに関する技術と最新動向を学ぶ
ペパボ研究所 主席研究員/チーフエンジニア 松本亮介
2018年3月27日 小山さんへの高集積ホスティングに関する講義

本発表の目的
•松本の研究を通じて汎用的なホスティング技術を学ぶ
•関連研究や基礎概念、サービスのモデルを知る
•高集積ホスティング技術の最新動向を知る

目次（1）
1. 研究の目的と位置づけ
2. 基本概念と関連研究
3. 高集積Webホスティング基盤のセキュリティと運用技術を考慮
したアクセス制御アーキテクチャ
4. スレッド単位で高速に権限分離を行うWebサーバのアクセス制
御アーキテクチャ
3

目次（2）
5. スクリプト言語で高速かつ軽量に拡張可能なWebサーバの機能
拡張支援アーキテクチャ
6. リクエスト単位でコンピュータリソースを分離するリソース制
御アーキテクチャ
7. まとめ
4

第1章
研究の目的と位置づけ

研究の背景
•クラウドや各種Webサービスの普及と個人の利用
•Webサービスの低価格化と品質の競争
•運用技術の研究とシステムの安定化が課題
•Webサーバの高集積マルチテナント方式に注目
•セキュリティとホストの収容効率向上が重要
6

研究の目的
•高集積マルチテナント方式の課題を整理・解決
•特にテナント内のコンテンツを事業者が管理できない場合
1. 高集積マルチテナント間での権限分離の課題解決
2. 高集積マルチテナント方式の機能拡張の課題解決
3. 高集積マルチテナント間でのリソース分離の課題解決
7

研究の位置づけ
•Webサーバの高集積マルチテナント方式においてコンテン
ツが制御出来ない場合の複数の課題を整理して解決
•高集積マルチテナント方式のWebホスティングに着目
•体系的にマルチテナント方式の従来手法の課題を整理
•性能・セキュリティ・リソース制御・運用技術の観点で解決
•OSSとして運用に耐えうる実装を行い幅広く利用して頂く
8

関連論文
•博士論文
•Webサーバの高集積マルチテナントアーキテクチャに関する研究
• https://repository.kulib.kyoto-u.ac.jp/dspace/handle/2433/225954
•サーベイ論文
•Webサーバの高集積マルチテナントアーキテクチャと運用技術
• http://search.ieice.org/bin/summary.php?id=j101-b_1_16&category=-&lang=J&year=2018&abst=

第2章
基本概念と関連研究

高集積マルチテナント方式の課題を整理
2.1 基本概念
2.2 運用技術とセキュリティと性能の課題
2.3 Webサーバ機能拡張の課題
2.4 Webサーバのリソース制御の課題
11

2.1 基本概念

マルチテナント方式

Webサーバのマルチテナント方式
•単一のサーバに複数のユーザ環境を構築する方式
•運用コストと収容（ハードウェア）コストを低減可能
•Webコンテンツを管理可能な場合は採用しやすい
•事業者がコンテンツを管理できない場合運用が困難
- 高集積化に伴うホスト間のリソース競合や性能の課題
14

Webコンテンツの管理とマルチテナント
•Webコンテンツを事業者が管理できる場合
- Webコンテンツからリソースや権限の分離を想定可能
•Webコンテンツを事業者が管理できない場合
- あらゆるコンテンツが動くため収容設計・運用が困難
- 脆弱なコンテンツがある前提でリソース・権限分離が必要
15

Webホスティングサービス

Webホスティングサービスの特徴
•事業者はお客様のWebコンテンツを制御できない
•ミドルウェア・OSで制御する必要がある
•できるだけ平等にユーザ体験を提供すべき
•共有の場合はリソース制御やセキュリティが重要
•性能と収容数をいかにバランスをとるかも重要
17

個人向けのWebサービスの増加と低価格化
•学生や主婦といった個人が趣味で使う用途の増加
•ハードウェアへのホスト収容率の最大化が重要
•セキュリティを担保しつつ性能とハードウェアリソー
ス効率を最大化するためにソフトウェア技術を活用
➜ 本研究の面白いところ
18

マルチテナント方式のアーキテクチャ

マルチテナント方式のアーキテクチャ概要
1. 高集積マルチテナント方式Webサーバのアーキテクチャ
2. 動的コンテンツの実行方式

高集積マルチテナント方式の
Webサーバのアーキテクチャ

プロセス数と収容ホスト数が重要
•プロセス数がホスト数に依存しない構成
•複数サイト共有のWebサーバプロセスがリクエスト
されたホスト名から動的にコンテンツを検出して処理
する方式が高集積マルチテナントには必要
- 例：ApacheのVirtualHost機能
22

Webサーバの基本的なモデル
UNIX系OSの場合事前にリクエストを受ける
Parent httpd process
(owner: root)
プロセスを複数fork()してプールしておく
（これら全てを含めて「単一のサーバプロセス」と定義）
リクエスト
Child httpd process
(owner: apache)
レスポンス
リクエスト
Child httpd process
Client
(owner: apache)
レスポンス
リクエスト
Child httpd process
(owner: apache)
レスポンス
23

高集積のためのアーキテクチャ
高集積が要求される場合の
マルチテナントの別アプローチ
マルチテナント（本研究）
ユーザB
httpd
効率良く残リソースを使える
ユーザC
httpd
ユーザA
ユーザB
httpd
ユーザA
ユーザC
起動に必要
起動に必要
起動に必要
起動に必要なリソース
なリソース
なリソース
なリソース
httpd
24

動的コンテンツの実行方式

動的コンテンツの実行方式
1. CGI（Common Gateway Interface）実行方式
2. DSO（Dynamic Shared Object）実行方式
26

CGI実行方式
Parent httpd process
リクエスト毎にプロセスの生成・破棄と
(owner: root)
比較的大きなバイナリ（PHPだとphp.cgiバイナリ）の
execve()が必要
Child httpd process
fork()
(owner: apache)
execve()
CGI process
php.cgi index.php
terminate process
CGI process
27

DSO実行方式
Parent httpd process
(owner: root)
Child httpd process
parse + run
(owner: apache)
index.php
サーバプロセスにインタプリタをライブラリ
として直接組み込んでおく
28

動的コンテンツの実行方式
•CGI実行方式
-インタプリタの複数バージョンを実行できる
•DSO実行方式
-性能は高いが基本的には単一のWebサーバにインタ
プリタを複数バージョン持てない
29

高集積マルチテナント方式の課題
•高集積を実現するApacheのVirtualHost機能のような
アーキテクチャはリソース効率が良いが複数課題が残る
1. 運用技術とセキュリティと性能の課題 ➜ 2.2
2. Webサーバの機能拡張と課題 ➜ 2.3
3. Webサーバのリソース制御と課題 ➜ 2.4

2.2 運用技術とセキュリティと性能の課題

運用技術と性能の課題
•ホスト単位に設定を追加して管理・制御する運用
•ホストの静的設定によるメモリと読込み負荷増大
- ページテーブルエントリ(PTE)の肥大化によりfork()の実
行処理が非常に遅い
- プロセスのリロードも長時間かかる場合も有り
32

セキュリティと性能の課題
•CGI方式のアクセス制御による静的設定の強制
-ホスト単位で静的にオーナ名を設定する必要有り
-ホスト数に依存した設定数とメモリ使用量の増加
•従来のDSOのアクセス制御ではCGI方式以下の性能
•ホストの上位ディレクトリのシステム領域の閲覧
33

Parent httpd process
※ CGI + 従来のアクセス制御手法
(owner: root)
Child httpd process
fork()
(owner: apache)
execve() suexec-program(setuid-root)
CGI process
(owner: root)
静的に設定されたuidを元にsetuid() setgid()
CGI process
execve()
php.cgi index.php
(owner: user1)
(owner: user1)
terminate process
CGI process
リクエスト毎にCGI用プロセスの
(owner: user1)
生成破棄が必要

※ DSO + 従来のアクセス制御手法
Parent httpd process
(owner: root)
Child httpd process
(owner: root)
setuid() setgid()
parse, run
Child httpd process
index.php
(owner: user1)
(owner: user1)
terminate process
Child httpd process
リクエスト毎に子httpdプロセスの生成破棄が必要
(owner: user1)

提案手法

運用技術とセキュリティを解決
•2つのアクセス制御アーキテクチャを提案
•CGI方式でセキュリティと運用技術を両立するアク
セス制御アーキテクチャ ➜ 3章
•DSO方式でセキュリティと性能を両立するアクセス
制御アーキテクチャ ➜ 4章
37

2.3 Webサーバの機能拡張と課題

Webサービスの安定性向上の課題
•セキュリティやリソース管理の重要性の高まり
•サービスの運用・管理コストの低減が必要
•サービス形態によってWebサーバの最適化が必要
•Webサーバの拡張機能の必要性が増加
39

Webサーバの機能拡張が重要
•レスポンス生成処理前後に処理を差し込む
•Webコンテンツに依存しない効率の良いアクセス制
御やリソース分離を実現可能
•Webサービスの運用・管理を効率化可能
•Webサーバの設定だけでは解決できない課題の増加
40

従来のWebサーバの機能拡張手法
•C言語による実装が定番
-高速かつ省メモリ 保守性や生産性が低い
•スクリプト言語による実装
-保守性や生産性が高い 低性能・安全性の問題
41

提案手法

スクリプトで高速かつ安全に拡張可能
•Webサーバプロセスへのインタプリタ組み込みを最適化
•高集積マルチテナント方式では運用保守を考慮した機能
拡張アーキテクチャが重要である
•性能面と安全性を両立したアーキテクチャの設計と生
産性を高める実装 ➜ 5章
43

2.4 Webサーバのリソース制御と課題

従来のWebサーバのリソース制御
•ハードウェアリソースや同時接続数などを単純な閾値
処理で制限
•閾値を超えるとリクエスト処理を強制切断・拒否
•リクエストを受けるか受けないかの単純な制御
45

従来のリソース制御の課題
1. サーバの負荷を低減することを重視するあまりユーザ
体験を大きく損なっている
2. 最大同時接続数以下でも一つのリクエストで大量にリ
ソースを使用するコンテンツを考慮できていない
3. 制限の粒度が荒くホスト間のリソース競合により快適
に使えるユーザと使えないユーザの差が大きい
46

提案手法

リクエスト単位でリソースを分離
•リクエストの中断ではなく継続的に処理する手法
•リクエスト単位でリクエストの属性に基いてリソース制御
•管理者が複雑な設定をプログラマブルに表現可能
•特定のコンピュータリソース範囲内で処理するアーキテ
クチャ ➜ 6章
48

第3章
高集積Webホスティング基盤のセキュリティ
と運用技術を考慮したアクセス制御アーキテクチャ

3章の課題のまとめ
•動的コンテンツはCGI方式を使う必要がある
-複数バージョンのインタプリタを扱いたい
-DSO方式のアクセス制御はCGI程度の性能になる
•静的設定の増加によるメモリ使用量の増大
•システム領域の閲覧不可のための設定コストが高い
50

運用面とセキュリティを両立する提案手法
•リクエストされたファイルから動的にownerを取得
- 設定をホストの数に合わせて増やす必要がない
- ホストの収容数に依存してメモリ使用量が増大しない
- PTEが肥大化せずfork()の実行処理が遅くならない
•ファイルのownerによる権限分離の際にファイルシステムを
合わせて隔離
51

Parent httpd process
※DSO + 従来のアクセス制御手法
(owner: root)
Child httpd process
(owner: root)
setuid() setgid()
parse, run
Child httpd process
index.php
(owner: user1)
(owner: user1)
terminate process
Child httpd process
リクエスト毎の子httpdプロセスの生成破棄が必要
(owner: user1)

Parent httpd process
(owner: root)
※CGI + 従来のアクセス制御手法
Child httpd process
fork()
(owner: apache)
execve() suexec-program(setuid-root)
CGI process
(owner: root)
静的に設定されたuidを元にsetuid() setgid()
CGI process
execve()
php.cgi index.php
(owner: user1)
(owner: user1)
terminate process
CGI process
リクエスト毎にCGI用プロセスの
(owner: user1)
生成破棄が必要
53

Parent httpd process
(owner: root)
※CGI + 提案するアーキテクチャ
Child httpd process
fork()
(owner: apache)
execve() suexec-program(setuid-root)
CGI process
(owner: root)
chroot() + リクエストファイルからuid取得後
setuid() setgid()
CGI process
execve()
php.cgi index.php
(owner: user1)
(owner: user1)
terminate process
CGI process
(owner: user1)
chroot Environment
54

性能評価
•Apache httpdに対して提案アーキテクチャを実装
•同時接続数を変化させながら秒間のレスポンス数を計測
•PHPで文字列を出力するだけのCGIプログラムを利用
•従来手法と提案手法の性能を評価
55

実験環境
56

57

３章まとめ
•運用技術とセキュリティを考慮したCGIの新しいアーキテクチャを提案
•従来のアーキテクチャと同等の性能でよりセキュアで扱いやすい仕様
- 高集積時においても設定数に応じたメモリ増加が生じないため実運用
上は高速に動作可能
- chrootするためのユーザ環境の構築は別途ユーザ毎に必要
•高集積マルチテナントのテナント数増加を考慮したアーキテクチャ
58

第4章
スレッド単位で高速に権限分離を行う
Webサーバのアクセス制御アーキテクチャ

4章の課題のまとめ
•3章のアクセス制御アーキテクチャは運用性に着目
-CGIの利点（複数バージョンの提供）を考慮
•DSO版の性能を活かすアクセス制御手法が無い
•実行方式やインタプリタが独自にアクセス制御手法を
実装しており煩雑
60

高集積マルチテナントとCGI・DSOの性能
•性能面においてCGIは本来適していない
- 収容数が増えるとプロセスのメモリ使用量が増えfork()の効率低下
- そもそもリクエスト単位でfork()するので遅い
•DSOは本来fork()を実行しないため高速に動作するが
- 従来のDSOのアクセス制御はリクエスト毎にfork()を実行する
61

Parent httpd process
※DSO + 従来のアクセス制御手法
(owner: root)
Child httpd process
(owner: root)
setuid() setgid()
parse, run
Child httpd process
index.php
(owner: user1)
(owner: user1)
terminate process
Child httpd process
リクエスト毎の子httpdプロセスの生成破棄が必要
(owner: user1)
62

提案するアクセス制御アーキテクチャ
•DSO方式の性能を活かすアーキテクチャ
•動的コンテンツ実行直前にオーナ変更の特権のみを与
えた制御用のスレッドを作成
•オーナを変更したスレッド上でコンテンツを処理
•コンテンツ実行後はスレッドのみを削除
63

LinuxスレッドとLinux Capabilities
•Linux Kernel2.2以降の独自のセキュリティモデル
•root特権を細分化してスレッド単位で付与可能
•オーナーの変更・well-known portのlisten等約40個
•Linux前提であれば提案手法が実現可能
64

Parent httpd process
※ DSO + 提案するアクセス制御アーキテクチャ
(owner: root)
prctl() setuid setgid caps
Child httpd process
(owner: apache)
create thread, set caps
thread
(owner: apache)
setuid() setgid()…, unset caps
thread
parse, run
index.php
(owner: user1)
(owner: user1)
destroy thread
thread
(owner: user1)
65

Parent httpd process
※ CGI + 提案するアクセス制御アーキテクチャ
(owner: root)
prctl() setuid setgid caps
Child httpd process
(owner: apache)
create thread, set caps
thread
(owner: apache)
setuid() setgid()…, unset caps
execve()
fork()
thread
CGI process
php.cgi index.php
(owner: user1)
(owner: user1)
(owner: user1)
destroy thread
terminate process
CGI process
thread
(owner: user1)
(owner: user1)
66

Webサーバモデルと制御用スレッドの考察
•1リクエスト1プロセス占有するサーバモデル前提
•DSOはスレッドの有無に関わらずサーバプロセスに
組み込まれたインタプリタが直接プログラムを実行
•スレッドを一時的に作ることによるセキュリティレベ
ルの低下は生じない

LinuxでApacheモジュールとして実装
•mod_process_securityモジュール
•設定は以下のようにシンプル
68

性能評価
•Apache httpdに対して提案アーキテクチャを実装
•秒間のリクエスト数を変化させレスポンス数を計測
•phpinfo()を出力するだけの簡単なプログラムを用意
•従来手法と提案手法の性能を評価
69

実験環境
70

DSO実行方式のアクセス制御性能比較
• 秒間リクエスト数を増加させながら秒
間レスポンス数を計測
• 緑の従来のアクセス制御はほとんど性
能がでていない
• 赤の提案するアクセス制御はアクセス
制御無しの場合と比べてもほとんどオー
バーヘッドは無し
青：アクセス制御無し
赤：提案するアクセス制御
緑：従来のアクセス制御
71

CGI実行方式のアクセス制御性能比較
•
秒間リクエスト数を増加させながら秒間レ
スポンス数を計測
•
CGIのアクセス制御の有無に関わらずCGI
の実行方式のオーバーヘッドが大きいため、
アクセス制御によるオーバーヘッドは無い
•
3章のCGIのアクセス制御はsuexecと同
等の性能であることが3章で実験済み
青：アクセス制御無し
赤：従来のアクセス制御
緑：提案するアクセス制御
72

参考：システムコールの数を比較
•phpinfo()へのアクセスをstraceから解析
•CGI ＋ suEXEC: 3377回
•mod_php + mod_process_security: 155回
•オーバーヘッドになってるシステムコール
•clone() open() close() execve() などsuEXEC関連
※1 strace -c -f -p PID
※2 cat cgi.log ¦ grep -v epoll_wait ¦ grep -v futex ¦ perl -ane '/<([\d\.]+)>/; print $_ if $1 > 0.00005;'
73

参考：導入前後のCPU使用量比較
一日のアクセス数はどちらのサーバも約1000万（サービス全体では数十億）
CGI＋suEXEC
DSO＋mod_process_security
■ idle ■ user ■ system
74

4章まとめ
•高集積マルチテナント方式における性能を考慮したア
クセス制御アーキテクチャの提案
•DSO実行方式のアクセス制御として大幅に性能改善
•提案手法はCGI実行方式にも適用可能
75

3章のCGIのアクセス制御との違い
•4章のアクセス制御は安全にchrootできない
•スレッド上でchrootすると同一プロセス上に属する
全てのスレッドがchrootされる
•スレッドを生成したプロセス自体もchrootされるた
め場合によっては意図しない動作をする可能性がある

CGI方式のアクセス制御の使い分け
•chrootによる隔離まで行いたい場合 ➜ 3章
•同一のアクセス制御で統一的に分離したい場合 ➜ 4章
•性能は同程度

第5章
スクリプト言語で高速かつ軽量に拡張可能な
Webサーバの機能拡張支援アーキテクチャ

5章の課題のまとめ
•Webサーバの機能拡張において性能を考慮した場合
はC言語による実装が定番
•従来のWebサーバのスクリプト言語による拡張は性
能面と安全性に課題
•サーバプロセスへのインタプリタ組み込みのアーキテ
クチャの提案が重要
79

従来のスクリプトによる機能拡張方式（１）
•インタプリタ共有方式（mod_perl、mod_ruby）
- サーバプロセス起動時に単一のインタプリタ確保
- リクエスト処理時に複数のスクリプトでインタプリタ共有
- グローバルの状態も共有
-高機能かつ規模の大きいインタプリタに最適
80

従来のスクリプトによる機能拡張方式（２）
•複数インタプリタ方式（mod_lua）
- スクリプト実行（リクエスト処理）単位でインタプリタ確保
- グローバルな状態は独立で安全
- インタプリタが確保する状態も都度開放して省メモリ
-低機能で高速・省メモリな組み込みスクリプト言語などに最適
81

従来手法の課題
•インタプリタ共有方式の課題
- グローバル状態が複数スクリプトで干渉
- 実行時のバイトコード増加によるメモリの増加
•複数インタプリタ方式の課題
- リクエスト毎のインタプリタ確保・開放のコストが高い
82

•


•

•


VM



83

提案するアーキテクチャ
•性能が要求される箇所はインタプリタ共有
•性能が要求されない箇所は個別にインタプリタ確保
•メモリ増加の原因であるバイトコードのみを開放
•安全性の面でグローバルの状態のみを開放可能
•バイトコードキャッシュによる高速化も可能
84

親サーバプロセス
スクリプト
起動時処理用インタプリタ
子サーバプロセスA
スクリプト
リクエスト処理用インタプリタ
スクリプト
スクリプト
リクエスト以外の処理用インタプリタ
スクリプト
・
性能が要求されるフック
・
はインタプリタを共有
・

85

• サーバプロセス起動時にインタプ
リクエスト毎にサーバプロセスがスクリプトをフック
リタを確保
インタプリタと
ライブラリを共有
• リクエスト処理時にインタプリタ
スクリプト読み込み
を共有してスクリプトをコンパイル
してから実行
構文木解析
バイトコード生成
排他処理
マルチスレッドWeb
サーバアーキテクチャ
VM上で実行
に対応
バイトコード、グローバル変数・クラス、例外フラグを開放
86

• バイトコードキャッシュによってサー
リクエスト毎にサーバプロセスがスクリプトをフック
バプロセス起動後にコード変更が必
インタプリタと
要ない場合は高速化
ライブラリを共有
• サーバ起動時にコンパイルしてバイ
スクリプト読み込み
トコードテーブルに保存しておき、
リクエスト時に取得して実行
構文木解析
バイトコード
バイトコード生成
テーブル
VM上で実行
グローバル変数・クラス、例外フラグを開放
87

アーキテクチャの実装
•Apacheモジュールのmod_mrubyとして実装
•nginxモジュールのngx_mrubyとしても実装
•mrubyという軽量Rubyインタプリタを利用
•RubyでWebサーバの振る舞いを拡張可能
•適材適所として従来のC言語の実装と共存可能
88

mod_mrubyの機能拡張の概要図
89

mod_mruby設定例
# Normal hook
<Location /mruby-test>
mrubyHandlerMiddle /path/to/test.rb
</Location>
# ByteCode Caching at Start up
<Location /mruby-test-cache>
mrubyHandlerMiddle /path/to/test.rb cache
</Location>
90

mod_mruby設定例
# Normal hook
<Location /mruby-test>
mrubyHandlerMiddle /path/to/test.rb
</Location>
# ByteCode Caching at Start up
<Location /mruby-test-cache>
mrubyHandlerMiddle /path/to/test.rb cache
</Location>
91

ngx_mrubyのインライン設定例
# Inline code hook
location /mruby-hello {
mruby_content_handler_code ‘
r = Nginx::Request.new
c = Nginx::Connection.new
r.content_type = “text/plain”
Nginx.echo “Hello #{c.remote_ip} World”
‘;
}
92

mod_mrubyでのReverse Proxy
# mrubyTranslateNameFirst “/path/to/proxy.rb”
backends = [
"http://192.168.0.101:8888/",
"http://192.168.0.102:8888/",
"http://192.168.0.103:8888/",
]
r = Apache::Request.new
backend = backends[rand(backends.length)]
r.reverse_proxy backend + r.unparsed_uri
93

ngx_mrubyでのReverse Proxy
# location /proxy {
# mruby_set $backend "/path/to/proxy.rb";
# proxy_pass http://$backend;
# }
backends = [
"http://192.168.0.101:8888/",
"http://192.168.0.102:8888/",
"http://192.168.0.103:8888/",
]
backends[rand(backends.length)]
94

mod_mrubyのBasicAuth with Redis
# <Location /basic/>
# AuthType basic
# AuthName "Message for clients"
# AuthBasicProvider mruby
# mrubyAuthnCheckPassword /path/to/authn_basic.rb
# require valid-user
# </Location>
anp = Apache::AuthnProvider.new
redis = Redis.new "127.0.0.1”, 6379
if redis.get(anp.user) == anp.password
Apache.return Apache::AuthnProvider::AUTH_GRANTED
else
Apache.return Apache::AuthnProvider::AUTH_DENIED
end
95

異なるWebサーバの統一的拡張記述
Ruby script 1
Nginx
Nginx
Core
API
ngx_mruby
Ruby script 2
Ruby script 3
Apache Apache
Ruby
・
DSL
・
Core
API
mod_mruby
・
for Web
・

Ruby script n
Apache Apache
Traffic
Traffic
Server
Server
ts_mruby
Core
API
ref: https://github.com/syucream/ts_mruby
96

統一的記述例
# Output Hello World
Server = get_server_calss
Server.rputs "Hello #{Server.module_name}/
#{Server.module_version} world!"
# mod_mruby => "Hello mod_mruby/1.9.3 world!"
# ngx_mruby => "Hello ngx_mruby/1.3.2 world!"
# ts_mruby => "Hello ts_mruby/0.0.1 world!"
97

実験
•性能評価
- Hello World出力の単純なプログラム（インタプリタの性能で
はなく組み込みアーキテクチャの性能を最大化するため）
- 従来・提案手法で実行し秒間のレスポンス数を計測
- 同時接続数100・総接続数10万
98

実験環境
99

従来手法との性能比較
従来の機能拡
mod_mruby
mod_perl
mod_ruby
mod_lua
mod_mruby
張
キャッシュ
言語
C
Perl
Ruby
Lua
mruby
mruby
インタプリタ
**
事前
都度
事前
事前
初期化処理
ライブラリ
**
事前
都度
事前
事前
読み込み
コンパイル
事前
都度
都度
都度
事前
コードの変更
不可
可
可
可
不可
グローバル状態
共有
共有
非共有
非共有
非共有
性能
9861.17
3346.38
4769.04
5209.11
9021.54
9752.37
Response/sec
100

世界中のWebフレームワークの速度を競うコンテストC、C++、Java、Go等の中
Rubyで頑張っている14位
ref: https://www.techempower.com/benchmarks/
101

言語をRubyに限定した結果
圧倒的1位
ref: https://www.techempower
102 .com/benchmarks/

5章のまとめ
•スクリプト言語で高速かつ安全に動作するWebサーバ機能拡
張支援アーキテクチャを提案
•従来研究よりも高速でWebサーバ活用ケースではC言語での実
装に
色ないアーキテクチャを実現
•広く使われているWebサーバソフトウェアのモジュールとして
実装しオープンソースソフトウェアとして公開
103

5章の今後の課題
•グローバル変数領域の自動開放機能
•現在は手動開放であるが特定のグローバル変数以外
は自動で開放できる処理（設定で切り替え可能）を
追加予定

第6章
リクエスト単位でコンピュータリソースを
分離するWebサーバの
リソース制御アーキテクチャ

6章の課題のまとめ
1. サーバの負荷を低減することを重視するあまりユーザ
体験を大きく損なっている
2. 最大同時接続数以下でも一つのリクエストで大量にリ
ソースを使用するコンテンツを考慮できていない
3. 制限の粒度が荒くホスト間のリソース競合により快適
に使えるユーザと使えないユーザの差が大きい
106

実現したいリソース制御（１）
マルチテナント方式のサーバ全体のCPUリソースが
迫した状態において、
使用できるCPUリソースは30%に制限されるが、利用できるクライアント数は3倍
従来手法
提案手法
アクセス不可
アクセス可！
アクセス可
より粒度の
Webサーバ
細かい制限
Webサーバ
CPU100％使用する
CPU30％使用する
3つのプログラムを処理
9つのプログラムを処理
107

実現したいリソース制御（２）
•リクエストに含まれる様々な属性を元に制御したい
-高集積マルチテナント方式ではリクエストの属性で
ホストを区別しプロセスを共有するため
-リクエスト単位でのリソース分離が必要
•複雑な設定をプログラマブルに記述可能にしたい
108

提案するリソース制御アーキテクチャ
•OSのプロセスリソース分離技術をWebサーバのリク
エスト単位で活用し制御
•5章の機能拡張支援機構mod_mrubyを応用
-プログラマブルでオーバーヘッド少ない支援機構で
リクエスト単位にリソースを制御可能
109

Linux独自のリソース制御cgroup
•プロセス単位でCPU・メモリ・I/O等を制御
-Linux Kernel 2.6.24以降の機能
-特定のプロセスは1コアCPU30%まで割当など
-CPU30%を割り当てたリソースグループを作成
-グループに参加しているプロセスでリソース分配
110

リクエスト単位でのリソース制御
リクエスト
cgroupアタッチ
レスポンス生成の処理の間のみ
Webサーバ
クライアント
プロセスを特定のcgroupにアタッチ
プロセス
（CPU30%など）
cgroupデタッチ
レスポンス
111

mod_mrubyとcgroupの実装
Apache Process
• 各機能は単体で動作可能（疎結合）
• mod_mrubyはApacheをmrubyで制御
mod_mruby
• mruby-cgroupはlibcgroupをmrubyで制御
• mruby + mruby-cgroup
mruby
• RubyやCコード内でリソースを制御可能
(libmruby.a)
• このループはCPU20%で
• この書き出しはDISK書込1MB/secで
mruby-cgroup
libcgroup
Linux cgroups
112

Apacheとmod_mrubyによる実装概要
113

リソース制御の設定例
r = Apache::Request.new
if r.filename == “/path/to/cpu.cgi”
cpu = Cgroup::CPU.new “cpu_group”
# CPU 10

cpu.cfs_quota_us = 10000
cpu.create
厳密には100ms中10msのCPU使用時間を
cpu.attach
quotaとしてスケジュールする設定
end
114

リソース制御の設定例
r = Apache::Request.new
if r.hostname == “example.com”
cpu = Cgroup::CPU.new “cpu_group”
# CPU 10

cpu.cfs_quota_us = 10000
cpu.create
cpu.attach
end
115

リソース制御の設定例
r = Apache::Request.new
if r.user== “matsumotory”
cpu = Cgroup::CPU.new “cpu_group”
# CPU 10

cpu.cfs_quota_us = 10000
cpu.create
cpu.attach
end
116

リソース制御の設定例
r = Apache::Request.new
if r.method== “POST”
cpu = Cgroup::CPU.new “cpu_group”
# CPU 10

cpu.cfs_quota_us = 10000
cpu.create
cpu.attach
end
117

リソース制御の設定例
r = Apache::Request.new
if r.finfo.user == 500
cpu = Cgroup::CPU.new “cpu_group”
# CPU 10

cpu.cfs_quota_us = 10000
cpu.create
cpu.attach
end
118

リソース制御の設定例
r = Apache::Request.new
if r.finfo.group == 300
cpu = Cgroup::CPU.new “cpu_group”
# CPU 10

cpu.cfs_quota_us = 10000
cpu.create
cpu.attach
end
119

リソース制御の設定例
r = Apache::Request.new
if r.finfo.size > 3000
cpu = Cgroup::CPU.new “cpu_group”
# CPU 10

cpu.cfs_quota_us = 10000
cpu.create
cpu.attach
end
120

リソース制御の設定例
if resource.most_heavy_hosts.include? r.hostname
# 1
100
1
c = Cgroup::CPU.new "httpd-static-limited"
c.cfs_quota_us = 100000
Apache::Resource.attach_cgroup c, "httpd-static-limited"
elsif resource.heavy_hosts.include? r.hostname
#
CPU
25%
24
6
# httpd
100
(
)
c = Cgroup::CPU.new "httpd-limited"
c.shares = 25
Apache::Resource.attach_cgroup c, "httpd-limited"
else
#
CPU
75%
24
18
# httpd-limited
100
(
)
c = Cgroup::CPU.new "httpd"
c.shares = 75
Apache::Resource.attach_cgroup c, "httpd"
end
121

精度とオーバーヘッドの評価
•リソース制御導入によるオーバーヘッド評価
•リソース制御の精度評価
122

実験環境
123

オーバーヘッドの評価
•Hello WorldするだけのHTMLファイル
•リソース制御導入し制限をしない場合のオーバーヘッド
•同時接続数100・総接続数100万リクエスト
-未導入時：32915.46 response/sec
- 導入時：32322.07 response/sec
124

リソース制御の精度評価
•CPU100%使用するCGIへリクエスト
•CPU50%にリソース制御
•CGIのCPU使用時間を変更して精度を比較
•性能制御率を定義：
•レスポンス時間（制限無し）/ レスポンス時間（制限有り）
•性能制御率が50%に近ければ正しく制御されている
125

126

6章のまとめ
•リクエスト単位でコンピュータリソースを分離
•マルチテナント方式のようにリクエストでテナントを特
定し処理するプロセスは共有するアーキテクチャに有用
•高集積マルチテナント方式において従来研究よりも粒度
の細かいリソース制限を適用できる
127

第7章
まとめ

まとめ
•Webサーバの高集積マルチテナント方式に関する研究
- 3章でセキュリティと運用面を両立したアクセス制御の研究
- 4章で性能とセキュリティを両立したアクセス制御の研究
- 5章でWebサーバ機能拡張支援機構の研究
- 6章でWebサーバのリソース制御の研究
129

貢献
•Webサーバの高集積マルチテナント方式の基本概念と課題
を体系的に整理しアーキテクチャを提案して解決
- セキュリティ・性能・リソース制御・運用技術の観点
•特にWebホスティングサービスを対象にアーキテクチャの
実装を行ってOSSとして公開しサービスへ反映・改善
- Linuxを活用した各種Webサービスの高度化に寄与
130

OSSとして公開
•第4章 mod_process_security
•第5章 mod_mruby ngx_mrubyと各種mrubyモジュール
•第6章 mruby-cgroup
•世界中から各種事例を連絡頂いております
131

今後の展望
•テナント単位でサーバプロセスを起動させつつ高集積
も両立するアーキテクチャの設計と実装
•リクエスト処理時のみプロセスがMortalに起動する
•恒常性のあるWebサービス基盤の実現
•メールのようなその他のプロトコルに応用可能

本論文に含まれる発表文献
博士学位論文
1 松本 亮介, Webサーバの高集積マルチテナントアーキテクチャに関する研究, 2017年度 京都大
学大学院情報学研究科 博士論文学位審査公聴会 2017年5月京都大学博士(情報学)学位取得, 2017
年.
133

本論文に含まれる発表文献
論文誌論文
1 松本 亮介, 栗林 健太郎, 岡部 寿男, リクエスト単位で仮想的にハードウェアリソースを分離す
るWebサーバのリソース制御アーキテクチャ, 情報処理学会論文誌, Vol.59, No.3, pp.1016-1025,
Mar 2018.
2 松本 亮介, 栗林 健太郎, 岡部寿男, Webサーバの高集積マルチテナントアーキテクチャと運用技
術, 電子情報通信学会論文誌, Vol.J101-B, No.1, pp.16-30, Jan 2018.
134

本論文に含まれる発表文献
論文誌論文
3 松本 亮介, 岡部 寿男, mod_mruby: スクリプト言語で高速かつ省メモリに拡張可能なWebサー
バの機能拡張支援機構, 情報処理学会論文誌，Vol.55, No.11, pp.2451-2460, Nov 2014.
4 松本 亮介, 岡部寿男,スレッド単位で権限分離を行うWebサーバのアクセス制御アーキテク
チャ,電子情報通信学会論文誌 Vol.J96-B, No.10, pp.1122-1130, Oct 2013.
5 松本 亮介, 川原将司, 松岡輝夫, 大規模共有型Webバーチャルホスティング基盤のセキュリティ
と運用技術の改善, 情報処理学会論文誌, Vol.54, No.3, pp.1077-1086, Mar 2013.
135

本論文に含まれる発表文献
国際会議発表（査読付き）
1 Ryosuke Matsumoto, Yasuo Okabe, Access Control Architecture Separating Privilege by a
Thread on a Web Server, The 12th IEEE/IPSJ International Symposium on Applications and the
Internet (SAINT2012), pp.178-183, July 2012.
136