Web サーバの高集積マルチテナントアーキテクチャと運用技術 *

(1)

Web サーバの高集積マルチテナントアーキテクチャと運用技術 _*

松本亮介

^†^a)

栗林健太郎

^††

岡部寿男

^†††

Highly Integrated Multi-Tenant Architecture of Web Servers and Operation Technology

^∗

Ryosuke MATSUMOTO

^†a)

, Kentaro KURIBAYASHI

^††

, and Yasuo OKABE

^†††

あらまし Webサービスのハードウェアコストや運用管理コストを低減するために採用される高集積マルチテナントアーキテクチャは，複数のユーザを同居させる特性上，ユーザ単位でセキュリティを担保するために，適切な権限分離を行う必要がある．そして，ホストに配置されるWebコンテンツを事業者が管理できないことを前提に，コンテンツに依存することなく基盤技術でセキュリティと性能を両立させるアーキテクチャが必要である．これまでに，実用上十分なセキュリティを担保しつつハードウェアの性能とリソース効率を最大化するための手法が数多く提案されてきた．また，マルチテナントアーキテクチャでは，ホスト間で権限分離だけでなく適切なリソース分離が行われる必要がある．リソース分離が不十分な場合，収容するホスト数が増えるにつれ，管理者により高負荷の原因となっているホストを特定し対処する作業の必要が生じ，運用管理コストが逆に増大してしまう．そのような運用上の問題の生じないリソース分離が可能なマルチテナントアーキテクチャの必要性も高まっている．更に，高集積マルチテナントアーキテクチャ採用時に，セキュリティを担保し，リソース分離を適切に行いながら，付随して生じる運用・保守に関するコストを低減させるためには，いかに運用技術を改善していくかが重要である．本論文では，Webサーバの高集積マルチテナントアーキテクチャにおいて，Webコンテンツをサービス事業者が管理できないことを前提に，高い性能とリソース効率を維持しつつハードウェアや運用管理コストを低減させるためのアーキテクチャについて，これまでの研究を概観するとともに，著者らによる最新の研究成果について紹介する．

キーワード Webサーバ，運用技術，マルチテナント，セキュリティ，リソース管理

1.

^{まえがき}

Web

サービスの普及とスマートフォンのように手軽に

Web

サービスを利用できる個人端末の爆発的普及により，安定した

Web

サービスを構築するための基盤技術とシステム運用技術が注目されている

[1]

．

Web

サーバ上に複数のホストを高集積に同居させることを目的とした高集積マルチテナントアーキテクチャ

[2]

†GMOペパボ株式会社ペパボ研究所，福岡市

Pepabo Research and Development Institute, GMO Pepabo, Inc., Tenjin, Chuo-ku, Fukuoka-shi, 810–0001 Japan

††GMOペパボ株式会社ペパボ研究所，東京都

Pepabo Research and Development Institute, GMO Pepabo, Inc., Shibuya-ku, Tokyo, 150–8512 Japan

†††京都大学学術情報メディアセンター，京都市

Academic Center for Computing and Media Studies, Kyoto University, Kyoto-shi, 606–8501 Japan

a) E-mail: [email protected]

*本論文は，システム開発・ソフトウェア開発論文である．

DOI:10.14923/transcomj.2017IAI0002

は，大幅にハードウェアコストを低減するだけでなく，

負荷分散や可用性を担保できる構成をとることで運用コストも低減できる．特に，マルチテナントアーキテクチャを採用した代表的な

Web

サービスである

Web

ホスティングサービスは，高集積化とそれによる低価格化が進んでいる．

Web

ホスティングサービスは，各ユーザ領域に利用者が任意の

Web

コンテンツを置くことを許すため，管理者は

Web

コンテンツに依存しない

OS

やミドルウェアといった基盤技術のみで，マルチテナント環境におけるセキュリティや安定性を担保しなければならない

[3]

．

高集積マルチテナントアーキテクチャを採用することで，サーバプロセスの設定を収容ホスト数の増加に伴って変更することなく高集積に収容できる．そのため，同一設定のまま新しいサーバを増やすといったようなスケールアウト型の負荷分散

[4]

も可能となりハードウェアのコストを効率良く利用できる．しかし，

(2)

そのようなシステムの信頼性を高め，安定的にサービスを提供するためには，セキュリティ，リソース分離，

及び，運用技術の改善が重要である．

Web

サーバにおける高集積マルチテナントアーキテクチャのアプローチは，

1

台のサーバに数万以上のホストの収容を目指しながらも，収容するホスト数に依存して，リソース使用量や設定変更に伴う再起動が極端に増加しないようにすることである．また，

Web

ホスティングサービスの場合，サービス利用者が各ホストに自由に

Web

コンテンツを配置できる．そのため，ホストに対するアクセスは事前に予測できず，特定のホストにアクセス集中し，サーバが高負荷状態になることもある．このような課題を解決するためには，

HTTP

リクエストのあったホスト名に従って，ホストごとにサーバプロセス群を待機させるのではなく，単一のサーバプロセス群を事前に待機させて，複数のホストに対するリクエストを処理する必要がある．ただし，実際にサーバプロセスの処理を行うプロセスは，

ホスト数には依存しないものの，

Web

サーバの実装によっては常に数十から数百プロセスが待機している．

この構成により，収容ホスト数が増加してもホスト数に依存して待機しておくプロセス群を増やす必要がなく，リソース効率が良い．

CGI [5]

のように，リクエスト単位でプロセスを複製するような処理であっても，

待機プロセスの数以上に増加することはないため，リソース使用量は待機プロセス数に依存し，極端に増加しない．また，複数のホストを単一のサーバプロセス群で処理するため，同一の設定のまま

Web

サーバを複数台に増やすことも可能となり，スケールアウト型の負荷分散も可能となる．

そのため，ホストのセキュリティをプロセスの機能を利用して

HTTP

リクエスト単位で担保しながら，

性能を最大化する必要がある．同様に，複数のホストのリソースが共有されるため，いかにホスト間で生じるリソース競合を低減させるかも課題である．また，

セキュリティやリソース管理について，いかに人の手を介さずに

Web

サーバの機能として実現し運用コストを減らせるかが，高集積マルチテナントアーキテクチャを採用したシステムの運用・保守にかかるコストを低減させるために重要である．

本論文では，大規模

Web

ホスティング基盤を実現するにあたり，

Apache

の

VirtualHost [6]

のような汎用性のある高集積マルチテナントアーキテクチャを採用することで生じる，セキュリティや性能上，運用上

の課題及びリソース分離についての関連研究を，

Web

サーバのアーキテクチャに基づいて

[7]

体系的にまとめる．本論文は，第一著者（松本）の学位論文

[8]

をもとにして書いている．

以下，

2.

では

Web

サーバのアーキテクチャや

Web

ホスティングシステムの構成について整理し，

3.

ではマルチテナントアーキテクチャのリソース分離，

4.

では仮想ホスト方式における権限分離，

5.

^{では高集積マ} ルチテナントアーキテクチャに伴う運用技術の課題とこれまでの研究についてそれぞれ整理する．

6.

で関連研究の総括をする．

2. Web

^サーバと

Web

^{ホスティングシス} テム

2. 1 Web

ホスティングシステム

Web

ホスティングサービスとは，複数のホストでサーバのリソースを共有し，それぞれの管理者のドメインに対して

HTTP

サーバ機能を提供するサービスである．

Web

ホスティングサービス

[1]

において，ド

メイン名

(FQDN)

によって識別され，対応するコン

テンツを配信する機能をホストと呼ぶ．

サービス提供側が

Web

ホスティングシステムを構築する手法は，主に以下の

4

種類に分類される．

（

1

）

Xen

や

VMware

等の仮想マシンでホストを分ける手法

[9], [10]

（

2

）

FreeBSD jail

や

LXC

，

OpenVZ

等のコンテナ型仮想化のようにファイルシステムや名前空間を操作するシステムコールによって

OS

上に複数の仮想的な隔離環境を用意しホストを分ける手法

[11], [12]

（

3

）

IP

アドレスやポート単位で

Web

コンテンツが配置された複数のホストを分離し各ホストに個別のプロセスを用意して起動させる手法

（

4

）単一のサーバプロセス群で複数のホストを仮想ホスト方式により扱う手法

サーバの運用面やセキュリティを重視した場合は，

手法

(1) (2) (3)

等の，管理者それぞれに対して，個別のサーバプロセスや仮想マシンを割り当てる構成がとられてきた．例えば，

OS

のシステム領域に近い環境を，特定のディレクトリ配下に作り，

IP

アドレスを

1

台のサーバに複数設定した上で，リクエストを受けた

IP

アドレスに応じてそのディレクトリ内へ

chroot()

システムコールによりルートディレクトリを移動する．

更に，

unshare()

システムコールによって，プロセス

ID

やネットワーク名前空間を隔離し，そのようなコ

(3)

図1 chroot()システムコール等を活用したホスト分離 Fig. 1 Privilege separation each hosts using chroot().

ンテナ型の仮想環境を複数用意し，それぞれで個別の

IP

アドレスで通信できる

Web

サーバプロセスを起動する．図

1

で，運用面とセキュリティを重視した場合に，

(2)

の手法を

Apache

で構築した場合の概要図を示す．

chroot

環境内部において，

Web

サーバプロセスは

chroot()

システムコールの実行権限をもたない一般ユーザとして起動し，

OS

のシステム領域に到達することはできないため，セキュリティ面で堅牢である．

また，

chroot

環境は

OS

のシステム領域とほぼ同等のライブラリ群を任意に配置できる．サーバプロセスの設定を全てホスト専用に設定することができ，運用面でも可用性が高い．更に，不必要なコマンドやライブラリを配置しないことで，セキュリティを高めることもできる．

JaveServlet [13]

のように個別の

JVM

を複数用意して，各

JVM

のプロセス単位で複数のホストを収容する方式は

(3)

に該当する．同様に，

Ruby on Rails

も

(3)

の方式であり，

Web

サーバ機能と一体となってアプリケーションサーバとして動作するため，複数ホストを収容するためにはその数だけアプリケーションサーバプロセスを用意する必要がある．

Stein

は，

(3)

の手法を利用して複数のサーバプロセスをそれぞれ異なるユーザ権限で起動する手法を提案している

[14]

．しかし，各

chroot

環境などにおいて，ホスティング利用者単位でサーバプロセスを起動させると，複数のサーバへのスケールアウト

[4]

することが困難になる

[2]

．

これに対し，

(4)

の手法による単一のサーバプロセス群で複数のホストを仮想的に処理する構成の場合，仮想ホスト方式

[6]

と呼ばれるマルチテナントアーキテ

図2 単一プロセスで複数ホストを扱う構成 Fig. 2 Conﬁguration that handles multiple hosts in

a single process.

クチャを用いることで，スケールアウト型の負荷分散の課題を解決できる．図

2

で

Apache

の

VirtualHost

で構築した場合の構成を示す．本論文では，仮想ホスト方式によるマルチテナントアーキテクチャにおいて数万以上のホストを収容できるものを高集積マルチテナントアーキテクチャと呼ぶ．

仮想ホスト方式では，アクセスのあったホスト名に対応したドキュメントルートにアクセスするように

Web

サーバ内部で制御するので，複数のホストに対して単一のサーバプロセス群が起動していればよい．

更に，複数の仮想ホストが設定されたサーバを複数台用意しておくことにより，いずれかのサーバの

Web

サーバプロセスにアクセスがあれば，共有ストレージを介して，適切なレスポンスを返すことができる．各サーバのサーバプロセス数は収容するホストの数に依存しないため，複数台の物理サーバ上で同一の設定のサーバプロセスを起動しておくことで，共有ストレージを用いた効率の良い負荷分散構成も構築できる．

Web

サーバにおける動的コンテンツの実行方式には，

Web

サーバプロセスにインタプリタを組み込み，

Web

サーバプロセス内部で直接プログラムを実行する

Dynamic Shared Object (DSO)

実行方式

[15]

と，新たに別のプロセスを

fork()

システムコールにより生成して，そのプロセスで

execve()

システムコールによりプログラムを実行する

Common Gateway Interface (CGI) [5]

実行方式がある．実行方式にかかわらず，権限分離機能を利用しない場合，動的コンテンツは

Web

サーバプロセスと同様のオーナで実行される．特に，

(4)

の仮想ホスト方式を権限分離機能を利用せずに採用すると，全てのホストのコンテンツが同一のオーナで実行されるため，セキュリティ上の問題がある．

(4)

2. 2 Web

サーバのリソース分離手法の分類単一のサーバで複数のホストを管理する場合，セキュリティを担保するための権限分離を考慮しながら，

複数のホストでサーバのハードウェアリソースを共有する構成が一般的である．

2. 1

で述べた分類において，手法

(1)

の，ホストそれぞれに対して，個別の仮想マシン

[16]

〜

[18]

を割り当てる構成では，仮想マシンレベルでのリソース分離機構により，特定のホストにアクセスが集中しても他のホストへの影響が及ばないような設定が可能である．

しかし，単一のサーバに複数の仮想マシンを収容するには，ホスト単位でのリソース使用量が多くなり，限られたリソースで，高集積にホストを収容するには不向きである．

(2)

や

(3)

の方式では，ホスト単位で

chroot()

システムコールによるファイルシステムの隔離やプロセスリソース管理技術を組み合わせたコンテナ環境

[19]

〜

[21]

を構築し，その環境ごとにサーバプロセスを起動させる．ホスト単位のリソース分離に，仮想ホスト方式では利用できない設定や，プロセス単位でのリソース制限や隔離機能を利用することができる．しかし，

プロセス数がホスト数に依存し，収容数が搭載メモリ容量により制約されるため，高集積にはむいていない．

(4)

のように，単一のサーバプロセス群で複数のホストを管理するアーキテクチャの場合，サーバプロセスがホスト数に依存しないため高集積が可能である．

しかし，

(4)

の方式では，単一のサーバプロセス群で複数のホストを処理しているため，特定のホストやリクエスト処理がリソースを占有した場合に，他のホストやリクエスト処理が影響を受けやすいという問題がある．

以上より，本論文では，高集積マルチテナントアーキテクチャを実現するための手法を主題としているため，

(4)

の方式において，リソース分離をどのように解決するかについて

3.

で述べる．

2. 3 Apache

のアーキテクチャ

Apache [22]

は，世界で最もシェアの高い

Web

サーバソフトウェアである

[23]

．高集積マルチテナントの運用では，

Apache

はリクエストを処理するための子プロセスをサーバプロセス起動時に複数起動させておき，

1

リクエストに対して一つの子プロセスを専有してレスポンス生成を行うモデルを基本とする．そのため，このモデルの場合，

Web

サーバに対する同時接続数の上限は子プロセスの起動数に依存する．

図3 Apacheモジュールの仕組み Fig. 3 Apache module speciﬁcation.

VirtualHost

は，

Apache

で仮想ホスト方式による高集積マルチテナントを実現する際，収容ホスト数にサーバプロセス数が依存しないようにするための機能である．

VirtualHost

は，前節で述べた

(4)

の手法により，単一のサーバプロセス群で複数のホストに対するリクエストを処理する．そのため，ホストの収容数を増加させたとしても，子プロセスの数を増やす必要がないため，コンピュータリソースを効率良く利用することができる．

VirtualHost

では，

Apache

のオーナとは別のオーナで動的コンテンツを実行する仕組みである

suEXEC [24]

を使って権限分離

( 4.

^で詳述

)

を行う場合，ホスト単位で一意の設定が必要になる．そのため，

VirtualHost

で管理するホスト数が増えるにつれ設定数は増加し，

Apache

起動時のメモリ使用量も増加する．

Apache

のサーバ機能の拡張には，

Apache

モジュールというプラグイン機構

[25]

が用いられる．図

3

に，

Apache

のコアとモジュールの概要図を示す．

Apache

のコアと

Apache

モジュールの連携は，

Apache

独自の

API

を介して実現されている．モジュールは，コアに近い実装から

Web

アプリケーションに近い実装まで，様々な領域での拡張が可能となっている．一般的な

Web

サーバソフトウェアと同様，

Apache

モジュールによる機能拡張は高速性と省メモリを考慮して

C

言語で実装する仕様になっている．

3.

高集積マルチテナントアーキテクチャのリソース分離

限られたコンピュータリソースで複数のホストをできるだけ高集積に管理・運用し，全体のコストを低減しながら安定稼働させるためには，特定のホストに対する

Web

アクセスがサーバ全体のリソースを占有しないように，ホスト単位で公平にリソースを配分する

(5)

ためのリソース分離手法が必要である．

Jao

は，リソース分離のために，ファイルやホスト単位で同時接続数を制御することによって，大量に同時アクセスがきたとしても，制限値以上のアクセスに対してはエラーを返す手法を提案している

[26]

，しかし，

CPU

や

Disk I/O

等のコンピュータリソースは共有のため，特定ホストにアクセスが集中したり，多くのリソースを消費するアプリケーションへのたった一つのリクエストによりリソースが占有されたりすることで，他のホストに影響を与える問題がある．そのような課題を解決するために，リソース分離手法が複数提案されている．

3. 1 VirtualHost

方式におけるリソース消費測定

Web

サーバでは，静的なファイルの配信だけでなく，負荷のかかる

CGI

プログラムなどの動的コンテンツの生成が行われる．マルチテナントアーキテクチャにおいては，特定のホストがリソースを占有することで，他のホストが影響を受ける状況はできるだけ回避したい．そのため，サーバ高負荷時の迅速な原因の特定と対処は非常に重要である．

ホスト単位で専用のサーバプロセスを起動するようなマルチテナントアーキテクチャの場合は，リソースを占有しているホストを特定し，最悪の場合，専用のサーバプロセスさえ停止させれば他のホストへの影響を緩和できる．一方，

VirtualHost

方式では，単一のサーバプロセス群で複数のホストを処理するために，

リソースを多く占有しているホストやファイルを厳密に特定して，問題となるリクエストのみを制限する必要がある．

DSO

実行方式で実行されたプログラムは，

ps

コマンドによりプロセス情報を取得すると，プロセス名はプログラムファイル名ではなくサーバプロセス名である

httpd

となる．そのため，サーバプロセスがリソースを大量に消費していた場合は，それがどのホストのどのスクリプトによるものであるかを迅速に特定することが困難である．

CGI

実行方式で実行されたプログラムは，

CGI

バイナリの引数としてプログラムファイル名が渡され，

プロセス名としては

CGI

バイナリ名が表示されるため，高負荷時等，迅速に対応しなければならない状況において，該当の原因となるプログラムファイル名を正確に特定できない．

DSO

実行方式であっても，リソースを占有しているプログラムを容易に特定するために，松本らは，

クライアントからのリクエストを

Apache

が受け付け処理を行ってからレスポンスを返すまでに，プロセスが消費したリソース量を測定するモジュール，

mod resource checker

^（注1）を提案している

[2]

．このモジュールによって，実行されたプログラムが，管理者によって設定されていたシステム

CPU

時間，ユーザ

CPU

時間，メモリ使用量のしきい値を超えていた場合に，プログラムの絶対パス，

VirtualHost

名，システム

CPU

使用時間，ユーザ

CPU

使用時間，メモリ使用量が計測されファイルに記録される．そのデータをもとに，高負荷ホストやスクリプトをリアルタイムで調査，検知できる．

3. 2

仮想ホスト単位でのリソース分離

chroot

環境や仮想マシンで

Web

サーバを起動している場合は，ホストごとにサーバプロセスが起動しているため，リソースの制限に関してサーバがもつ全ての設定を利用することができる．しかし，

VirtualHost

を利用した構成の場合，

Apache

では仕様上仮想ホスト単位で設定できる項目は限られている．例えば，最大同時接続数を設定するために

MaxClients

を仮想ホスト単位で設定することはできない．また，

VirtualHost

上でコンテンツ単位の同時接続数を柔軟に設定する方法がないのも高負荷ホストの制限を困難にしている．

VirtualHost

は複数のホストを単一のサーバプロセス群で管理しているため，サーバプロセスが高負荷で停止してしまうと全てのホストの機能が停止する．そのため，サーバプロセスが高負荷でサービス停止しないように制限することが必要となる．例えば，

Apache

が標準で備えるリソースの制限のための設定としては，メモリやプロセス数等があるが，

CPU

使用の制限の設定は限られており，

RlimitCPU

という設定のみである．

RlimitCPU

では，クライアントからリクエストを受けてレスポンスを生成するまでに，設定した

CPU

使用時間を超過した場合，カーネルによって処理が強制的に切断される．そのため，ミドルウェアや

Web

コンテンツの実装によらずレスポンス処理が中断されるため，

Web

コンテンツの動作として信頼性が低くなる．

高負荷ホスト全体や高負荷スクリプトへのアクセス数を制限するために，松本らは，リクエスト対象への最大同時接続数を設定するモジュール

mod vlimit

^（注2）を

（注1）：https://github.com/matsumotory/mod resource checker

（注2）：https://github.com/matsumotory/mod vlimit

(6)

提案している

[2]

．設定対象は，任意のホストやファイル名，ファイルへの絶対パス，任意のディレクトリ，正規表現にマッチしたファイルやフォルダ等である．同時接続数の設定値を超えた場合は，

HTTP

のステータスコード

503

（

Service Unavailable

）を返す．また，

同一クライアント

IP

からの同時接続数も設定できる．

高集積のホスティング環境においては，単一のサーバに収容しているホスト数が多いことから，リソースを多く占有するスクリプトにアクセスが集中し，サーバが高負荷となって

OS

が停止してしまうような状況は避けるべきである．そこで，松本らは，

CPU

処理や

I/O

処理の負荷の目安となるロードアベレージの数値に着目し，リクエストを受けた後，ロードアベレージの数値によってレスポンスを返すかどうかを

Apache

が判断するモジュール

mod lalimit

^（注3）を提案している

[2]

．ロードアベレージの数値をしきい値として設定し，その数値を超えた場合はステータスコード

503

を返すことで安全に処理を中断させる．

1

分平均のロードアベレージをしきい値に設定できる．

3. 3

リクエスト単位でのリソース分離

Linux

には，

cgroup [27]

と呼ばれるプロセスのリソース管理技術がある．

cgroup

の優先順位機能を使うことで，

CPU

や

I/O

を制御できる．筆者らは，リクエスト処理時に，

cgroup

を利用して，管理者が記述した内容に従って仮想的に分離されたリソース領域を作成し，サーバプロセスをそのリソース領域内で動作させることで，リクエスト単位で任意のリソース分離が可能な

Web

サーバのリソース分離手法を提案している

[28]

．クライアントからサーバプロセスに対してリクエスト処理があると，そのリクエストが制御対象であった場合，サーバプロセス上で動作しているリソースコントローラが，リソース分離ルールからリソースに関する設定値を取得する．そして，そのリソース設定値を元に確保された仮想リソース領域がなければ，

新規で領域を作成する．

例えば，任意のリクエストに対し，

CPU

使用率は最大

10%

，ディスクへの書き込みは最大

5MB/sec

に制限したいとする．その場合は，制御ルールを設定ファイルに記述する．記述後，新しいリクエストを受けた際に，リソースコントローラは制御ルールを解釈し，ルール通りにリソース領域を生成する．そして，

サーバプロセスを，作成したリソース領域に割り当て

（注3）：https://github.com/matsumotory/mod lalimit

た後，リクエストをそのリソース範囲内で処理する．

処理後は，レスポンスをクライアントに返し，リソース領域への割り当てを解除してから，次のリクエスト処理に備える．このようなアーキテクチャを取ることにより，リクエストに含まれる情報，例えば，ホスト名や

HTTP

メソッド，ユーザ情報等を条件に，管理者が

HTTP

リクエスト単位で柔軟にリソース分離を行える．

3. 4

特徴量抽出と変化点検出に基づくリソースの自律制御アーキテクチャ

高負荷時にどれぐらいのリソース使用量を割り当てるのが適切なのかということや，負荷原因の状況に応じて同時接続数制限との組み合わせをどう判定するかについて，刻々と変化しログの量も肥大化していく状況下で人力による調査に頼って判断することは高コストである．適切な制限項目や一定のルールに従った制限値を，いかにシステム管理者の運用コストをかけずに調査し制限するかという，ホスト単位で精細なリソース分離を行う際の課題がある．

松本らは，

Web

サーバのコンピュータリソースの特徴量を時系列データとして抽出してリクエストごとに変化点検出を行い，原因となるホストやプログラムの変化らしさの重み付けを行った上で，サーバ全体のリソース逼迫時には，重み付けリストの結果に基いて自律的に原因となるリクエストを特定し分離するアーキテクチャを提案している

[29]

．時系列データには，ホスト及びプログラム単位でのレスポンスタイムのデータとその時点の同時接続数を使用する．この時系列データに対して，変化の傾向を表すスコアを計算し，

リクエスト時のホスト名とプログラム名に基づいて，

計測したスコアからリソースの傾向変化に寄与したホスト及びプログラムの重み付けリストを更新していく．

そして，サーバ全体が高負荷状態になった場合に，重み付けリストに従って原因の可能性が高いリクエストのみを，リソース使用量が限定された隔離環境内で処理するようにする．これらを，

Web

サーバのレスポンス生成処理の過程に組み込むことにより，

Web

サーバはサーバ管理者の代わりに自律的に原因を解析し，必要なときにその原因に対処できる．

4.

高集積マルチテナントアーキテクチャにおける仮想ホスト方式の権限分離

Apache

は，歴史的にマルチテナントアーキテクチャのために様々な運用上の課題を解決し，改善した上で

(7)

運用可能なレベルで機能追加が行われてきている．本章では，

Apache

において，高集積マルチテナントアーキテクチャを実現する

VirtualHost

機能を例に，仮想ホスト方式における権限分離の具体的な課題をまとめることで，現実的なセキュリティ及び実運用上の課題と具体的な手法を整理する．

4. 1

システム領域や他ホスト領域の覗き見

Apache

の

VirtualHost

を採用した構成では，一般に

OS

のシステム領域で

Web

サーバプロセスを起動するため，

Web

サーバプロセスのユーザ権限や，動的コンテンツが実行される際のユーザ権限であっても，

システム上の一般ユーザ権限で閲覧可能な

/etc

等のシステム領域のファイルを覗き見することができる．また，閲覧できないように全てのシステム領域の権限を修正するコストは非常に高い．

VirtualHost

で動作している

Apache

は，サーバプロセス権限で全てのリクエストを処理する必要があり，

コンテンツファイルやディレクトリをサーバプロセス権限で操作可能にしなければならない．そのため，単純なマルチテナントアーキテクチャでは，異なるユーザが管理する他ホスト領域を覗き見することができてしまう．図

4

に，他ホスト領域のファイルを覗き見するための一般的な仕組みと権限設定を示す．

図

4

では，

index.cgi

は

Web

サーバプロセスの権限である

uid500

，

gid101

で実行され，

/var/www/hosts/

host1.example.com/

ディレクトリは

gid101

からの読み取り権限がある．更に，ディレクトリ配下のホスト領域内部のファイル群は

Web

サーバプロセス権限でアクセスできるように全ユーザに読み取り権限

図4 他ホスト領域の覗き見 Fig. 4 Peeping in another host area.

を与えている．そのため，

host1

を管理するユーザは，

/var/www/hosts/host2.example.com/

ディレクトリの下のコンテンツには直接アクセスできないが，

host1

の

index.cgi

内でシェル等の外部コマンドを実行することで，

host2

の

index.cgi

のソースコードなどを閲覧できてしまう．また，

CGI

プログラムを経由せずとも，シンボリックリンクを他ホスト領域のファイルに対して別名で設置するだけで，

Web

サーバプロセスを介した覗き見が可能となる．これを防ぐために，

CGI

プログラム実行時に利用できる

suEXEC [24]

のようなアクセス制御モジュールを用いて，コンテンツの権限で

CGI

プログラムを実行し，適切に各ホスト領域の権限を設定することで，覗き見できないようにする方法が用いられる

[3]

．同時に，

Apache

においてシンボリックリンク経由で他ホスト領域へ辿れないようにする設定も利用される．

4. 2 CGI

実行方式のためのセキュリティ機構

Apache

の

suEXEC

機能

[24]

を用いると，

Virtual- Host

を採用していても他ホスト領域を閲覧できなくする構成をとることができる．図

5

に

suEXEC

の利用例を示す．図

5

では，図

4

と同様のパーミッション設定をしている．

suEXEC

を採用すると，クライアントから

CGI

プログラムにアクセスがあった場合，

Apache

によって

CGI

プログラムの実行処理を

suEXEC

に依頼する．

suEXEC

は

index.cgi

を実行する際に，

index.cgi

の権限である

uid501

，

gid102

を取得する．

そして，プロセスの権限を変更するシステムコール

(setuid()

，

setgid()

システムコールなど

)

を実行して，プロセスの権限を変更し，

CGI

プログラムを実行

図5 suEXECの利用例 Fig. 5 Example of suEXEC.

(8)

図6 CGI実行方式のアクセス制御アーキテクチャ Fig. 6 Access control architecture of CGI.

する．そのため

uid501

，

gid102

のプロセスは，

/var/

www/hosts/host2.example.com/

配下での読み取り権限である

uid502

，

gid101

に対するアクセス許可がない．このように，

suEXEC

を採用することで，他ホスト領域にアクセスすることができず，他の領域の

index.cgi

の閲覧もできない．

図

6

にサーバプロセスと

suEXEC

の詳細なアーキテクチャを示す．図

6

のように，

suEXEC

はプログラムを実行するたびに，一般ユーザからの実行であっても

root

権限で実行されるように設定されたラッパープログラムを実行させていったん

root

権限になり，そこから実行対象のプログラムの権限に

setuid()

，

setgid()

システムコールを実行してからプログラムを実行する．

このように，

CGI

プログラム実行ごとにプロセスの生成，破棄が必要となるため，性能が低くなるという問題がある

[30]

．

Doersch

は，システム領域や他ホスト領域を覗き見できないように，

suEXEC

時に各ホスト環境で

ch- root()

システムコールにより，ルートディレクトリを各ホスト領域に移動し，隔離してからスクリプトを実行する手法を提案している

[31]

．図

7

は

suEXEC

プログラム内部で

chroot()

システムコールを実行する仕組みの概要図である．これにより，

CGI

プログラムはホスト領域内の隔離された領域で実行されるため，

利用しているホスト領域外のファイルを閲覧することができない．一方，隔離された領域でプログラムを実行するため，ホスト単位で個別にライブラリを含んだ実行環境をドキュメントルートディレクトリ配下に事前に用意しておく必要がある．ただし，複数の実行環境のファイル間をハードリンクし参照のみにすること

図7 suEXEC実行時にchroot()システムコールを実行する仕組み

Fig. 7 Architecture for executing chroot() at suEXEC execution.

により，実行環境の構築や使用容量のコストを下げることは可能である．

4. 3 DSO

実行方式のためのセキュリティ機構

DSO

実行方式は

Apache

モジュールとして組み込まれたインタプリタがプログラムを実行するため，一般的に

CGI

実行方式と比較して，リクエスト時にプロセスの生成と破棄が必要なくなり性能が高くなる．

また，スクリプトの処理を渡すインタプリタを指定するために，スクリプトの行頭に記述するシェバン行や権限を細かく設定する必要がない．しかし，

Apache

に組み込まれて実行される以上，基本的には

Apache

権限で実行されるため，図

4

と同様の他ホストが覗き見される問題が生じる．以下，

DSO

実行方式を安全に利用するためのセキュリティ機構としてこれまでに提案されているものを紹介するとともに，それらの課題について論ずる．

4. 3. 1 PHP

のセーフモード

DSO

実行方式において，広く使われている

DSO

版

PHP

は，他ホストの領域を閲覧できないようにするため，セーフモードという機能があった．セーフモード機能を利用すると，

DSO

版

PHP

であっても他ホスト領域のファイルを覗き見できない．しかし，

PHP

特有のセキュリティ機構であり汎用性が低いこと，共有サーバ上の

OS

やファイルシステム上のセキュリティ問題を

PHP

アプリケーションのレイヤーで解決しようと試みるのはアーキテクチャ上正しくないといった理由から，

PHP5.3.0

で使用が非推奨となり，

PHP5.4.0

では削除された

[32]

．

(9)

4. 3. 2 root

のサーバプロセスで権限分離する手法

DSO

実行方式を採用した場合でも，

mod suid2 [33]

というモジュールを利用すると，他ホスト領域の閲覧を防ぐことができる．

mod suid2

は，

Apache

のサーバプロセスを

root

権限で起動しておき，リクエストを処理するたびに

setuid()

及び

setgid()

システムコールによりユーザ権限に降格する．これによって，

Apache

の権限とは別の権限でプロセスを実行できるため，

suEXEC

と同様，他ホスト領域を閲覧できなくなる．

しかし，処理後はサーバプロセスが一般ユーザ権限であるため，権限を元の

root

権限に戻すことができない．そのため，ユーザ権限に降格されたプロセスはコンテンツ処理後に破棄する必要がある．その結果，プロセスを再利用できず，

DSO

実行方式を利用していたとしても，

suEXEC

よりも性能が大きく低下する．

また，セキュリティの観点からは，サーバプロセスを

root

で起動させていると，万一サーバプロセスそのものに任意のコマンドを実行できるなどの脆弱性があった場合や，設定ミスによってサーバプロセスの権限でコンテンツが動作した場合に，悪意のあるユーザが容易に

root

の特権を得られるという問題がある．

原らによる提案手法

[34]

では，サーバプロセスを

root

で起動し，セキュア

OS

の機能で

root

の権限を一部制限した状態で，リクエストごとに

fork()

システムコールでプロセスを新規生成し，新規生成したプロセスの権限を変更してからリクエスト処理を行う手法を提案している．しかし，

DSO

実行方式と比較した場合に，リクエストごとにプロセスの生成と破棄が必要となり，性能が低下する．

4. 3. 3

一般ユーザのサーバプロセスで権限分離す

る手法

鈴木らは，アクセスするクライアントが正確に特定できるようなイントラネットの環境において，ユーザ権限であっても

setuid()

システムコール等を実行可能にする手法を提案している

[35]

．この手法は，

UNIX

にユーザ権限でオーナを変更できる新たなシステムコールを実装し，

ident

プロトコルを利用せずに，

IP

オプションを用いてクライアントプロセスの認証情報を送ることと組み合わせることにより，

ident

プロトコルに依存しないイントラネット内での透過的なクライアントプロセスとサーバプロセス間の権限分離システムを構築可能である．しかし，信頼のあるクライアントとネットワークが前提となっており，不特定多数のクライアントには対応していない．

図8 mod ruid2のアクセス制御アーキテクチャ Fig. 8 Access control architecture of mod ruid2.

mod ruid2 [36]

というモジュールを利用すると，一時的にユーザ権限で起動しているサーバプロセスに，

root

の特権を細分化した

Linux Capability [37]

と呼ばれる機構の内，

CAP SETUID

，

CAP SETGID

の特権を与えられる．図

8

に

mod ruid2

の詳細なアーキテクチャを示す．

特権を与えられたサーバプロセスは，

root

権限で実行されていなくても，

setuid()

及び

setgid()

システムコールを実行可能となる．その後，

mod suid2

同様に

Apache

のサーバプロセス自体を任意の

uid

，

gid

に権限変更してから処理を実行し，再度，元の

uid

，

gid

に戻す．この仕組みによって，

DSO

実行方式であっても，

PHP

スクリプトは他ホスト領域を閲覧できない．また，実行後でも，元のサーバプロセスの権限に戻すことで，プロセスの再利用も可能にしているため，

DSO

実行方式の性能を維持できる．しかし，このようなプロセスは，

root

のように全ての権限をもたないものの，

setuid()

及び

setgid()

システムコールを実行できる特権を保持している．図

8

における

index.php

のような

Web

アプリケーションの脆弱性をつかれ悪意のある者に乗っ取られた場合，

setuid()

及び

setgid()

システムコールによる権限変更を利用し，他ホスト領域のファイル閲覧や変更及び不正プログラムの配置や配布等が可能となる．サーバプロセスに権限を変更できる特権の保持を許すことは，同時に数多くの脆弱性を許すことになる．一方で，

setuid()

及び

set- gid()

システムコールを実行した後に

CAP SETUID

及び

CAP SETGID

の

Capability

を放棄し，処理後にプロセスを復帰できないように改修すれば安全であるが，やはりサーバプロセスが再利用できなくなり，

mod suid2

同様性能は著しく低下する．

一般に，サーバプロセスにアクセス制御を設定後に

(10)

再度解除するというアプローチは性能上の利点を得られるが，共有型の大規模

Web

ホスティング基盤のセキュリティを考える上でリスクが非常に大きく，脆弱性をつかれた場合の利用者や閲覧者への被害は甚大であり，避けるべきと考えられる．

原らは，

Web

サーバからの権限変更を可逆的に変更可能にしながら，実行されるプログラムからは権限を変更されないように，プログラムから実行されるシステムコールをフック^（注4）してプログラムから実行される権限変更の処理を無効にしてセキュリティを担保する手法

[38]

を提案している．しかし，

Linux

においては，

システムコールを適切にフックするためには

Linux

カーネルに直接変更を加える必要があり，可搬性が低く，カーネルやライブラリを継続的に更新することが求められる現場において運用上の問題になることが多い．

4. 3. 4 Linux

スレッド単位で

DSO

方式の権限分離を行う手法

DSO

方式の利点は，プログラムを高速に実行できることである．そのため，

DSO

方式のアクセス制御アーキテクチャを設計する上では，性能劣化を十分考慮しなければならない．

suEXEC

のようなプログラム実行時に新たに子プロセスを生成し，コンテンツ処理後にプロセスを破棄するアーキテクチャは，性能を大幅に低下させる．また，

mod ruid2

のように，プロセスを生成せずにサーバプロセスに権限変更の特権を与えてプロセスを再利用すれば高速に実行できるが，

4. 3. 2

で述べたとおり，脆弱性が生じる．

そこで，筆者らは，

Linux

上で動作することを前提とし，

Linux

におけるスレッドを

pthread create()

関数によって一時的に生成し，そのスレッド上で権限分離を行った後，スレッド配下でプログラムの処理を行い，最後にスレッドを破棄する手法

mod process security

^（注⁵^）を提案している

[28]

．

Linux

におけるスレッドはプロセス内の同一メモリ空間上で実行でき，メモリ消費量等が軽減できる．また，

Linux

上では，スレッドの生成・破棄はプロセスの生成・破棄よりも処理が軽い

[39]

．スレッドの生成・破棄を利用することにより，サーバプロセスを破棄する必要もない．図

9

に

DSO

実行方式に

mod process security

を適用した場合の，処理の流れを示す．

（注4）：一連の処理の中で特定の処理フェーズが呼ばれたときに，同時に，あるいは，代わりに別の処理も実行できるようにあらかじめ処理を登録しておくこと．

（注5）：https://github.com/matsumotory/mod process security

図9 mod process securityのアクセス制御アーキテクチャ

Fig. 9 Access control architecture of mod process security.

Linux

上で動作する

Apache

は，親サーバプロセス

（

Parent Server Process

）から事前に

fork()

システムコールが実行され生成された複数の子サーバプロセス

（

Child Server Process

）がリクエストを受け付けるために待機している．リクエストを受け付けると，子サーバプロセス上で一時的にスレッド（

Control Thread

）を生成する．一時的に生成したスレッドに対し権限変更の特権である

Linux Capability

の

CAP SETUID

，

CAP SETGID

を付与する．この特権によって，ス

レッドは任意の

uid

，

gid

に権限変更可能となる．その後，実行対象のプログラムの

uig

，

gid

等の権限情報を動的に取得して，その権限にスレッドの権限変更を行う．スレッドの権限変更を行った後は，プログラムを実行する前にスレッドに付与された特権を破棄しておく．これによって，

mod ruid2

で生じたような，プログラム経由での権限変更を防止する．スレッド上で直接プログラムを実行した後は，スレッドを破棄して，

スレッドが属した子サーバプロセスは再度リクエスト受け付けに再利用される．

これによって，既存の

DSO

実行方式のアクセス制御アーキテクチャのように，サーバプロセスの生成破棄をすることなく，安全にアクセス制御を行える．また，スレッドの生成，破棄の処理時間の短さから性能劣化を低減し，

DSO

実行方式の特徴である高い性能を維持できる．

5.

高集積マルチテナントアーキテクチャの運用技術

Web

ホスティングサービスを提供する側が，サーバ

(11)

を運用管理する工数は，インターネットの普及に伴い，

日々増加してきている．

2. 1

で述べたとおり，高集積マルチテナントアーキテクチャにおいては，

Apache

の

VirtualHost

機能を使うことにより効率的にホストの収容数を増やすことができる．一方で，収容数が増えることにより運用面の課題が生じる

[2]

．

5. 1 suEXEC

時の

CGI

プログラムとインタプリタの紐付けする手法

suEXEC

を採用するためには，

CGI

版を利用しなければならず，シェバン行^（注6）の記述や適切な実行権限設定をホスティング利用者に強制する必要がある．

しかし，例えば

Web

サイトの動的コンテンツの開発に多く採用される

PHP

スクリプトのコードにおいては，一般にシェバン行は記述されない．そのため，シェバン行の記述や実行権限設定はホスティングサービス仕様上の問題となる．

mod suphp [40]

を利用すると，シェバン行の記述や実行権限設定をホスティング利用者に強制する必要なく，

suEXEC

と同様に

CGI

プログラムをユーザ権限で実行できる．しかし，

suEXEC

と同様に

Virtual- Host

単位で

uid

，

gid

を設定ファイル内で指定する必要があり，

mod vhost alias

でも動的に扱えない．また，他ホスト領域への覗き見を防ぐことができるが，

4. 1

で述べた，システム領域の覗き見問題を解決できていない．

mod actions [41]

を利用すると，

CGI

実行方式であっても，スクリプトにシェバン行や実行権限を設定しなくても実行できるラッパープログラムに渡す設定ができる．しかし，ラッパープログラムを

Apache

や各ホストの権限からアクセス可能なディレクトリに安全に配置する必要があり，設定や構成が煩雑になりがちである．また，ラッパープログラムは

URL

からアクセスできる領域に配置する必要があり，顧客の

URL

を一部占有することが問題となる場合もある．

4. 1

^で述べた，システム領域の覗き見問題も解決できない．

松本らは，

PHP

プログラムに対するリクエスト時は，

suEXEC

プログラム内部で

execve()

システムコールを実行し，

CGI

実行方式用の

PHP

インタプリタファイルにリクエストされたプログラムパスを引数に渡して実行するように改修した手法を提案している

[2]

．これによって，

PHP

プログラムのシェバン行や実行権限

（注6）：UNIXで実行されるスクリプトの1行目に，スクリプトを渡すインタプリタを指定するために書く行．#!/bin/shなどと記述される．

英語表記はshebang．

の有無をサービス利用者が意識することなく，

CGI

実行方式の

PHP

プログラムを

suEXEC

で実行できる．

改修によって，複数のモジュールやラッパー等を組み込む必要がないという点で非常にシンプルな構成になっている．また，ホスティング利用顧客が

DSO

版

PHP

を扱うために，シェバン行を記述しなかった

PHP

スクリプトに対しても，

suEXEC

内部で

CGI

版

PHP

として実行されるため，

CGI

版か

DSO

版かをホスティング利用顧客が気にする必要がない．一方で，

PHP

プログラムとインタプリタファイルの紐付けを

suEXEC

で行う必要があるため，

PHP

のようなシェバン行を通常書かないようなプログラミング言語を提供する場合には，別途ホスティングサービス提供者による紐付けが必要である．

5. 2

ホストの新規設定・追加に伴うコスト

3. 2

で述べたとおり，

VirtualHost

においては

Web

サーバプロセスが停止すると，全てのホスト機能が一時的に停止する．そのため，大規模化に伴う設定の増加を考慮すると，設定に追加あるいは変更があってもできる限り

Web

サーバプロセスのリロードやリスタートを実施しないようにするべきである．新規ホストの追加設定やチューニングを行う場合に，

Web

サーバのリロードを実施しないでよいようにするためには，

mod vhost alias [42]

を用いる．

mod vhost alias

は

Apache

モジュールで実装されており，

Dynamically Configured Mass Virtual Host- ing

（

DCMVH

）という設定記述方法を提供する．通常，

Apache

では，ホスト追加時に新規ホスト用の

Vir- tualHost

設定を追記する．しかし，仮想ホストの設定はホスト名やドキュメントルート名等が異なるだけで，

その他の設定は同じ場合が多い．そこで，

DCMVH

の設定記述法を利用すると，ドキュメントルートにホスト名を含んだパスになるようにディレクトリを作成しておけば，

VirtualHost

の設定においてパスのホスト名部分を変数で記述することができる．その記述によって，

VirtualHost

の設定を一つ書いておけば，アクセスのあったホスト名で設定を動的に読み替え，該当のドキュメントルートにアクセスできるようになる．また，設定の数がホストの数に依存しないため設定読み込みの負荷も少なくできる．図

10

に，通常の

VirtualHost

の設定を示す．

suEXEC

を採用するためにはホスト単位で

Suexe-

cUserGroup

という設定を記述する必要がある．

Suex-

ecUserGroup

に設定された

uid

と

gid

が，実行対象

(12)

図10 通常のVirtualHostの設定例 Fig. 10 Conﬁguration example of VirtualHost.

の

CGI

プログラムとオーナが一致するか確認し，その上で

CGI

を実行する際に

setuid()

及び

setgid()

システムコールにより，オーナを変更することでセキュリティを高めている．しかし，

5. 2

^{で述べたように，}

mod vhost alias

では

suEXEC

の設定の

uid

と

gid

を動的に扱う記述がないため，

VirtualHost

単位に

uid

と

gid

を静的に記述しなければならない．そのため，

新規

VirtualHost

を追加するたびに設定数が増加する．

設定反映には

Apache

のリロードが必要であるため，

ホスト数の増加とともにリロードによる設定読み込み時間も増加する．更に，設定数の増加によって

Web

サーバプロセスのメモリ使用量が増加し，その状態で

CGI

実行方式のような，

fork()

システムコールや

execve()

システムコールを伴う処理を行うと，ページテーブルエントリ数の増大とその複製と削除の処理に起因して処理のコストが高くなり，

CPU

使用時間を多く消費する．

松本らは，各仮想ホストの

suEXEC

のユーザ名とグループ名を同一のダミーとして設定した上で，

suEXEC

プログラム内部で実行ファイルのオーナ情報からユーザ名とグループ名を解釈できるように

suEXEC

を改良し，ホスト単位で権限分離が必要な場合でも，全ての仮想ホストの設定を一つの設定に書き直すことができるようにしている

[2]

．図

11

に，

mod vhost alias

による統一的設定例を示す．

また，

mod vhost alias

では，環境変数に保存されるドキュメントルートが，本来保存されるべき変数を読み替えたユーザごとの絶対パスにならない問題があるが，松本らは，ホスティングサービスの利用者が環境変数を使ったプログラムを配置する可能性を考慮し，正しいドキュメントルートで保存されるように，

mod vhost alias

を改良している

[2]

．

3. 1

^，

3. 2

^{で紹介した}

Apache

モジュールは，各ホスト専用の制限設定が書かれたファイルに設定を記述することができ，

Apache

のリロードを実行すること

図11 mod vhost aliasとsuEXECの改修による統一的設定例

Fig. 11 Uniﬁed conﬁguration example by modifying mod vhost alias and suEXEC.

無くリクエストごとに新たな設定を反映させることができる．その結果，ホスト数に依存した煩雑な設定無く，また，

Apache

のリロードをせずに制限の設定や新規に追加するホストの設定を反映させることができ，

運用性とサービス性が向上する．

5. 3

高集積マルチテナント

Web

サーバの大規模証明書管理

従来の

Web

サーバソフトウェアは

HTTPS

で通信を行うために，サーバ起動時に，サーバ証明書とペアとなる秘密鍵をホストごとに読み込んでおく必要がある．しかし，そのような仕組みでは，高集積マルチテナントアーキテクチャでのメリットである性能と低価格化の両立が難しい．なぜなら，高集積にホストを収容すると，大量のサーバ証明書の読み込みによってサーバプロセスの起動に多くの時間を要したり，サーバプロセスのメモリ使用量が増加したりするからである．更には，サーバプロセスの起動処理や，

CGI

のようなプロセス複製の処理が大幅に遅くなり，性能への影響が大きくなるというデメリットもある．また，

サーバ証明書をファイルで管理する必要があり，複数の

Web

サーバによる処理の分散や可用性の担保に支障をきたす．

松本らは，高集積マルチテナント方式による

Web

サーバにおいて，

Web

サーバプロセス起動時にサーバ証明書と秘密鍵を読み込んでおくのではなく，

SSL/TLS

ハンドシェイク時において，リクエストのあったホスト名を元に，対応するサーバ証明書と秘密鍵のデータをデータベースから動的に取得することで，

Web

サーバプロセスのメモリ消費量を大幅に低減する効率的なサーバ証明書の管理アーキテクチャを提案している

[43]

．

TLS

ハンドシェイク時の処理時間の大部分はクライアントから送られてきた共通鍵の復号処理にかかる

CPU

使用時間であり，

CPU

使用時間に関するコストにおいても，

TLS

のハンドシェイク時のコストと比較し，動的に証明書を読み込む処理はコストの低い処理となる．そのため，ほとんど性能劣化は見られず，実用上問題にならない性能がでることを実験から

(13)

示しており，メモリ消費量の大幅な改善が実現できている．また，データベースから証明書を都度取得するため，

Web

サーバプロセスの再起動なく収容ホストの

TLS

適用が可能となり，運用技術についても改善できている．

6.

^{むすび}

本論文では，

Web

サーバの高集積マルチテナントアーキテクチャの課題と関連研究の整理及び基礎概念の整理を行った．

Web

ホスティングサービスで実運用上採用されることの多い

Apache

に関する基礎概念や用語を整理した上で，高集積マルチテナントアーキテクチャにおける，運用技術，セキュリティ，及び，リソース分離に関する関連研究と課題を体系的にまとめた．

2.

から

5.

を通して紹介した研究は，全て実用可能なソフトウェアとして実装されており，既に

OSS

としても公開済みの

mod process security

や

mod resource checker

なども，実際に筆者が所属する

GMO

ペパボ株式会社では既に導入済みで実運用フェーズにある

[44]

．

今後の課題としては，

HTTPS

による通信が当たり前となっていく中で，高集積マルチテナントアーキテクチャのように，単一のサーバプロセス群で大量のサーバ証明書を管理する必要がある場合の，効率的な管理方法を検討する必要がある．

高集積マルチテナントアーキテクチャを採用しており，かつ，

Web

コンテンツを事業者が管理できないという特性をもった歴史ある

Web

サービスである

Web

ホスティングサービスの汎用性に着目し，周辺のシステムやミドルウェアの具体的な課題を体系的にまとめることによって，本論文が

Web

サービスにおけるシステムやミドルウェアのセキュリティや性能及び運用技術の向上のための研究開発に寄与できれば幸いである．

文献

[1] R. Prodan and S. Ostermann, “A survey and tax- onomy of infrastructure as a service and Web hosting cloud providers,” 10th IEEE/ACM International Conference on Grid Computing, pp.17–25, Oct. 2009.

[2] 松本亮介，川原将司，松岡輝夫，“大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善，” 情処学論，vol.54, no.3, pp.1077–1086, March 2013.

[3] S.A. Mirheidari, S. Arshad, and S. Khoshkdahan,

“Performance evaluation of shared hosting security methods,” IEEE 11th International Conference on Trust Security and Privacy in Computing and Com-

munications, pp.1310–1315, June 2012.

[4] M. Ferdman, A. Adileh, O. Kocberber, S. Volos, M.

Alisafaee, D. Jevdjic, and B. Falsaﬁ, “Clearing the clouds: A study of emerging scale-out workloads on modern hardware,” ACM SIGPLAN Notices, vol.47, no.4, pp.37–48, March 2012.

[5] The Apache Software Foundation, Apache Tutorial:

Dynamic Content with CGI, http://httpd.apache.

org/docs/2.2/en/howto/cgi.html

[6] The Apache Software Foundation, Apache Virtual Host documentation, http://httpd.apache.org/docs/

2.2/en/vhosts/

[7] R.T. Fielding, Architectural Styles and The Design of Network-based Software Architectures, Doctoral Dis- sertation, University of California, Irvine, 2000.

[8] 松本亮介，Webサーバの高集積マルチテナントアーキテクチャに関する研究，博士学位論文https://repository.

kulib.kyoto-u.ac.jp/dspace/handle/2433/225954, 京都大学，May 2017.

[9] L. Van Doorn, “Hardware virtualization trends,”

ACM/Usenix International Conference on Virtual Execution Environments, vol.14, no.16, p.45, June 2006.

[10] J.N. Matthews, W. Hu, M. Hapuarachchi, T.

Deshane, D. Dimatos, G. Hamilton, and J. Owens,

“Quantifying the performance isolation properties of virtualization systems,” ACM The 2007 Workshop on Experimental Computer Science, p.6, June 2007.

[11] J. Che, C. Shi, Y. Yu, and W. Lin, “A synthetical performance evaluation of OpenVZ, Xen and KVM,”

IEEE Asia Paciﬁc Services Computing Conference (APSCC), pp.587–594, Dec. 2010.

[12] H. Chen and D. Wagner, “MOPS: An infrastructure for examining security properties of software,” 9th ACM Conference on Computer and Communications Security, pp.235–244, Nov. 2002.

[13] Java Servlet 3.0 Speciﬁcation, http://jcp.org/en/jsr/

detail?id=315

[14] L. Stein, “SBOX, put CGI scripts in a box,”

USENIX Annual Technical Conference, General Track, pp.145–155, June 1999.

[15] The Apache Software Foundation, Dynamic Shared Object (DSO) Support, http://httpd.apache.org/

docs/2.2/en/dso.html

[16] R.P. Goldberg, “Survey of virtual machine research,”

Computer, vol.7, no.6, pp.34–45, 1974.

[17] T. Garﬁnkel and M. Rosenblum, “A virtual machine introspection based architecture for intrusion detec- tion,” NDSS, vol.3, pp.191–206, Feb. 2003.

[18] T. Garﬁnkel, B. Pfaﬀ, J. Chow, M. Rosenblum, and D. Boneh, “Terra: A virtual machine-based plat- form for trusted computing,” ACM SIGOPS Oper- ating Systems Review, vol.37, no.5, pp.193–206, Oct.

2003.

[19] S. Soltesz, H. P¨otzl, M.E. Fiuczynski, A. Bavier, and

Web サーバの高集積マルチテナントアーキテクチャと運用技術 *