情報処理学会研究報告
IPSJ SIG Technical Report

高集積マルチテナント Web サーバの大規模証明書管理松本 亮介1,a)

三宅 悠介1

力武 健次1,2

栗林 健太郎1,b)

概要：インターネットの利用に際して，ユーザーや企業においてセキュリティ意識が高まっている．また，HTTP のパフォーマンス上の問題を解消するために，HTTP/2 が RFC として採択された．それらを背景に，常時 HTTPS 化が進む中で，高集積マルチテナント方式の Web サーバで管理している大量のホストもHTTPS 化を進めていく必要がある．同方式は単一のサーバプロセスで複数のホストを管理する必要があ
るが，Web サーバの標準的な設定を用いて事前にホスト数に依存した数の証明書を読み込んでおく方法では，必要なメモリ使用量が増大することで，サーバプロセスの起動時や，CGI のようなプロセスの複製時に OS のページテーブルのエントリ数に依存するシステムコールの性能が著しく低下する．そこで，Server
Name Indication(SNI) を利用可能である条件下において，事前にサーバプロセスに証明書を読み込んでおくことなく，SSL/TLS ハンドシェイク時にホスト名から動的にホストに紐づく証明書を読み込み，メモリ使用量を低減させる手法を提案する．実装には，我々が開発した，mruby を用いて高速かつ少ないメモリ
使用量で Web サーバの機能を拡張するモジュール ngx mruby を採用して，動的にサーバ証明書を選択する機能を実装した．また，サーバ証明書データは，Redis によるキャッシュサーバによって管理し，本手法の有効性を評価した．

Large-scale Certificate Management on Highly-integrated Multi-tenant
Web Servers
Ryosuke Matsumoto1,a)Yusuke Miyake1

Kenji Rikitake1,2

Kentaro Kuribayashi1,b)

Abstract: Introducing HTTPS to a large number of the hosts supervised under highly-integrated multitenant Web servers is critical to meet the security demand of the individual and corporate users, and tocomply with the HTTP/2, an RFC to solve the HTTPS performance issues. Preloading the massive numberof certificates for managing a large number of hosts under the single server process results in increasing therequired memory usage due to the respective page table entry manipulation, which may largely degrade theperformance of system calls during the creation of the server process and process replication required for
CGI invocation. To solve this issue, we propose a method to dynamically load the certificates bound to thehostnames found during the SSL/TLS handshake sequences without preloading, provided the Server Name
Indication (SNI) extension is available. We implement the function of choosing the respective certificateswith ngx mruby module, which we developed to extend Web server functions using mruby with small memory footprint while maintaining the execution speed. We also evaluate the feasibility of our proposal with acache server of the server certificate data running on Redis.

1. はじめに
1

2

a)
b)

GMO ペパボ株式会社 ペパボ研究所
Pepabo Research and Development Institute, GMO Pepabo,Inc., Tenjin, Chuo ku, Fukuoka 810-0001 Japan
力武健次技術士事務所
Kenji Rikitake Professional Engineer’s Oﬃce, Toyonaka
City, Osaka 560-0043 Japanmatsumotory@pepabo.com
antipop@pepabo.com

c 2017 Information Processing Society of Japan⃝HTTPS による通信が前提となる HTTP/2 プロトコルのRFC 採択 [2] と Google による常時 SSL/TLS 化の推進 [5]に伴い，Web ホスティング事業者によって管理されている Web サイトの HTTPS 化が急務となっている．一般にHTTPS 化は事業者にとってもサービス利用者にとって1

情報処理学会研究報告
IPSJ SIG Technical Report

も，サーバ証明書の価格の高さや，HTTPS を行うためのいる [19], [25], [27]．

基盤整備のコストが高いとされてきた [11]．しかし，Let’s

本論文の構成を述べる．2 章では，高集積マルチテナン

Encrypt[6] などのような無料の DV 証明書の提供が開始さ

ト方式の Web サーバにおける常時 HTTPS 化に向けた課

れはじめ，比較的低コストで HTTPS 化が実現可能になっ題を整理する．3 章では，2 章の課題を解決するための提てきている．

案手法のアーキテクチャおよび実装を述べる．4 章では，

高集積マルチテナント方式 [10] による Web ホスティン

2 章における性能面での課題をより明確化するために従来

グサービスでは，高集積にホストを収容することで，ハー手法の性能劣化やメモリ使用量の問題についての検証を

ドウェアコストや運用コストを低減し低価格化を実現す行った上で，Redis にサーバ証明書等のデータを保存してるために，単一のサーバプロセス*1 で複数のホストを管理

おき SSL/TLS ハンドシェイク毎にサーバ証明書と秘密鍵する必要がある [29]．従来の Web サーバソフトウェアはを Redis から動的に取得する提案手法と，従来の事前に

HTTPS で通信を行うために，サーバ起動時に，サーバ証

データを読み込んでおく方式との性能比較を行って有効性

明書とペアとなる秘密鍵をホストごとに読み込んでおく必を評価し，5 章でまとめとする．

要 [22] がある．しかし，そのような仕組みでは，高集積マ
ルチテナント方式でのメリットである性能と低価格化の両立が難しい．なぜなら，高集積にホストを収容すると，大2. 従来の高集積マルチテナント方式のサーバ
証明書管理

量のサーバ証明書の読み込みによってサーバプロセスの高集積マルチテナント方式の代表的なサービスである起動に多くの時間を要したり，サーバプロセスのメモリ使

Web ホスティングとは，複数のホストでサーバのリソー

用量が増加したりするからである．さらには，サーバプロスを共有し，それぞれの管理者のドメインに対して HTTP

セスの起動処理や，CGI[23] のようなプロセス複製の処理

サーバ機能を提供するサービス [15] である．Web ホスティが大幅に遅くなり，性能への影響が大きくなるというデメ

ングサービスにおいて，ドメイン名 (FQDN) によって識別

リットもある．また，サーバ証明書をファイルで管理する

され，対応するコンテンツを配信する機能をホストと呼ぶ．

必要があり，複数の Web サーバによる処理の分散や可用性の担保に支障をきたす．

従来の Web サーバのサーバ証明書管理では，Web サー
バプロセスの起動時にホストに紐づく証明書を読み込み，本論文では，高集積マルチテナント方式による Web サー

HTTPS 接続時に IP アドレスあるいはホスト名に対応した

バにおいて，TLS 拡張の Server Name Indication(SNI)[3]

証明書をメモリ上から読み出し，SSL/TLS ハンドシェイ

を前提に，Web サーバプロセス起動時にサーバ証明書と秘クによってセッションを確立する．この管理方法の場合，

密鍵を読み込んでおくのではなく，SSL/TLS ハンドシェ

事前にメモリ上に証明書を読み込んでおくため，SSL/TLS

イク時において，リクエストのあったホスト名を元に，対ハンドシェイク時に高速に処理することができる．一方，応するサーバ証明書と秘密鍵のデータをデータベースから

高集積マルチテナント方式の場合，サーバに収容するホス

動的に取得することで，Web サーバプロセスのメモリ消トが非常に多いため，事前に読み込んでおくサーバ証明書

費量を大幅に低減する効率的なサーバ証明書の管理アーや秘密鍵の数もホスト数に応じて多くなり，Web サーバプ

キテクチャを提案する．SSL/TLS ハンドシェイク時におロセス起動にで時間がかかったり，プロセスが使用するメ

ける証明書と秘密鍵の動的な読み込みは，筆者らが開発

モリ使用量が増大したりする．それにより，再起動に時間した，nginx[12] を mruby[26] で拡張できる ngx mruby[28]がかかるため，サービス停止の時間が長くなってしまう．

に，証明書の取り扱いを制御できる機能追加を行うことでまた，プロセスのメモリ使用量増大に伴う OS のメモリ管対応した．サーバ証明書と秘密鍵は KVS[7] の一種である理の影響により，特定の処理時に著しく性能が低下するとRedis[17] に保存しておき，mruby のコードによってホスいう課題もある．

ト名に対応した証明書と秘密鍵を取得するようにした．本
手法は，HTTPS 通信を終端する Web サーバとして広く

2.1 プロセスの再起動時間の課題

使われている nginx に対して，ngx mruby を用いること

代 表 的 な Web サ ー バ ソ フ ト ウ ェ ア で あ る Apacheにより nginx 本体を変更することなく簡単に組み込めるた

httpd[20] や nginx では，仮想ホスト機能によって，単め，実用的である．また，実装は既に OSS として公開し一のサーバプロセスで複数のホストを処理することができており*2 ，複数のドメインの HTTPS 化が必要となる Web

る．ただし，ここでいう単一のサーバプロセスとは，ホスサービス事業者によって，幾つかの採用事例も報告されてト毎にサーバプロセスを起動させるのではなく，複数のホストでサーバプロセスを共有することを示す．実際にサー*1*2

Web サーバソフトウェアの実装により複数の処理プロセスが起動するが，ホスト数に依存しないことを示すために単一のサーバプロセスと呼ぶことにする
https://github.com/matsumotory/ngx mruby

c 2017 Information Processing Society of Japan⃝

バプロセスの処理を行うプロセスは，ホスト数とは無関係であるが，複数存在する．
高集積マルチテナント方式は大量のホストを管理する必2

情報処理学会研究報告
IPSJ SIG Technical Report

要があるため，仮想ホスト機能を利用してできるだけ設定

ムコールの実行に非常に時間がかかる．また，fork() シス

内容やプロセスの起動アーキテクチャをホスト数に依存しテムコールとともに実行されることの多い execve() システ

ない構成にする必要がある．実運用上では，ホスト数を万ムコールではページテーブルエントリの大部分を削除するの単位で収容することも多く，従来手法では，サーバ起動

処理が実行されるため，fork() システムコールによるペー時に大量の証明書と秘密鍵をメモリ上に読み込んでおく必

ジテーブルエントリのアドレスのコピーと同程度の処理が要がある．その場合，サーバ証明書の読み込み数が増大す行われる．

ることにより，起動時の読み込み時間が大幅に増え，サーWeb サーバ上で利用される CGI 実行方式では，リクエ

バプロセスのメモリ使用量も大幅に増える．また，ホスト

スト毎に fork() システムコールと execve() システムコーに紐づく証明書の設定を全て記述する必要があり，Webルが実行されるため，大量のページテーブルエントリのア

サーバ設定の行数も大幅に増えるため，設定ファイルの可

ドレスのコピーと削除が実行され，非常に遅くなる．プロ

読性が低くなり、サーバ管理に支障をきたす．

セスのメモリ使用量増大による，fork() システムコールの

例えば nginx を利用している場合に，10 万ホストの仮想

CPU 使用時間の増加については，4 節でより詳細に述べる．

ホストを設定し，各ホストに紐づく証明書と秘密鍵を読みここまで述べたことから次のことがわかる．HTTP/2 の込んだ場合，nginx の設定行数は 200 万行程度になる上に，実用化に伴い HTTPS 通信が既定の方式として使われる

サーバプロセスの起動は 50 秒かかり，プロセスのメモリ

Web サービスにおいて，従来の Web サーバプロセス起動

使用量は証明書の設定だけで 3GB 程度になる．そのため，時に静的にサーバ証明書を読み込んでおく方式では，高設定変更時のサーバプロセスの再起動に，非常に時間がか

集積マルチテナント方式を採用する Web サービスにおいかる．このメモリ使用量に関する詳細については，4 節でて，サーバプロセス起動に時間がかかる問題がある．また，言及する．

サーバプロセスのメモリ使用量が増大することによりシス
テムコールの実行が遅くなり，証明書を事前に読み込んで2.2 メモリ使用量増大によるシステムコールの性能低下に関する課題おくことによる性能面の利点が失われ，結果的に性能が劣化するという問題もある．

サーバ証明書を事前に読み込んでおく場合，Web サー
バプロセスのメモリ使用量は証明書の数に従って単調増加する．ところで，一般的に，Linux においてプロセスのメ

3. 提案手法
3.1 効率的なサーバ証明書の管理アーキテクチャ

モリ使用量が増加した場合に，プロセスを fork() システ

コンピュータリソースと性能効率のバランスの最大化，

ムコールにより複製しても，Copy on Write[1] の機能によ

および，システム運用コストの効率化が求められる高集積り，メモリ上のデータに変更がかからない限りメモリ領域

マルチテナント方式において，2 節で述べた課題を解決すのコピーは発生しない．そのため，高速にプロセスの複製るためには，以下の 3 つの要件を満たすことが必要である．

を行うことができる．しかし，プロセスのメモリ使用量が( 1 ) 高集積化を実現するために，IP アドレスではなくホ

数 GB 単位になった場合，プロセス毎に保持しているペー

スト名に紐づくサーバ証明書を用いる Server Name

ジテーブルと呼ばれる仮想メモリと物理メモリのアドレス

Indication(SNI) 拡張を利用する．

の対応表のサイズが増大することにより性能低下を招く．
ページテーブルサイズ T は，プロセスのメモリ使用量を( 2 ) Web サーバプロセス起動を高速にするために，サーバ
証明書は起動時に読み込まない．

P ，ページテーブルエントリサイズを e，ページテーブル( 3 ) Web サーバプロセスのメモリ使用量がホスト数に依存

エントリ数を E ，ページサイズを t*3 とした場合，以下のしないようにするために，サーバ証明書は SSL/TLS
ハンドシェイク時に動的に読み込む．

通り求められる．

SNI[3] とは，SSL/TLS の拡張仕様の一つである．通常

P
=E
t

(1)

TLS による通信では，IP アドレス単位でサーバ証明書を

eE = T(2)

利用する．その場合，高集積マルチテナント方式では，ホストの数だけ IP アドレスが必要となり，IP アドレスの取この状況下では，P が大きくなればなるほど，(1) 式によ

得コストを考慮すると，コストの制約を満たしながら低るページテーブルエントリ数 E および (2) 式によるページ

価格化を実現するという要件に向かない．一方，SNI では

テーブルサイズ T が増大する．また，fork() システムコー

SSL/TLS ハンドシェイク時にアクセスしたいホスト名をルを実行すると，Copy on Write でメモリ領域がコピーさサーバに伝えることにより，従来の IP アドレス単位ではれない場合でも，ページテーブルに保存されているページ

なくホスト名単位でサーバ証明書を使い分けることがで

テーブルエントリは全てコピーされるため，fork() システ

きる．SNI は，高集積マルチテナント方式のように，単一*3Linux 標準では 4096Bytesc 2017 Information Processing Society of Japan⃝のサーバプロセスかつ単一の IP アドレスで複数のホスト

3

情報処理学会研究報告
IPSJ SIG Technical Reportserver {listen443 ssl;server_name_;ssl_protocols

TLSv1 TLSv1.1 TLSv1.2;

ssl_ciphers

HIGH:!aNULL:!MD5;

ssl_certificate/path/to/dummy.crt;

ssl_certificate_key /path/to/dummy.key;
mruby_ssl_handshake_handler_code ’
ssl = Nginx::SSL.new
host = ssl.servername

図 1

ssl.certificate = "/path/to/#{host}.crt"

TLS の SNI 拡張の違い

ssl.certificate_key = "/path/to/#{host}.key"

Fig. 1 Characteristics of TLS SNI Extension.

’;

を仮想的に処理するような方式において，各ホストとホスト名を用いて HTTPS 通信を行う場合に利用されることが
多い．

}





図 2

動的なサーバ証明書読み込みの設定例 (ファイルベース)

Fig. 2 File-based Configuration Example of Dynamic Server

そこで，SNI による SSL/TLS ハンドシェイクを前提に，

HTTPS によって Web サーバにリクエストがあった場合に，ホスト名にもとづいてデータベース上からサーバ証明書と秘密鍵を取得し，SSL /TLS ハンドシェイクを行う．

Certificate Management.



server {listen443 ssl;

このようにすることで，高集積マルチテナント方式のようserver_name_;に大量のサーバ証明書が必要な状況において，事前にサー

ssl_protocols

TLSv1 TLSv1.1 TLSv1.2;

ssl_ciphers

HIGH:!aNULL:!MD5;

ssl_certificate/path/to/dummy.crt;

バ証明書を読み込んでおく必要がないため，Web サーバ
プロセスの起動は速く，メモリ使用量もホスト数に依存し

ssl_certificate_key /path/to/dummy.key;て増加することがないため少なくて済む．さらに，データ
mruby_ssl_handshake_handler_code ’

を TCP 通信可能なデータベースやキャッシュに集約して

ssl = Nginx::SSL.new

おくことにより，HTTPS リクエストが増加してきた際に，

host = ssl.servername

Web サーバを複数台に増加させて容易に可用性と性能を担

redis = Redis.new "127.0.0.1", 6379

保することができるとともに，実サービスにおけるユーザ

ssl.certificate_data = redis["#{host}.crt"]
ssl.certificate_key_data = redis["#{host}.key"]との SSL/TLS の契約から証明書を Web サーバに設定するシステムとの連携も，データベースを介して容易に実現で
きる．

’;
}





図 3 動的なサーバ証明書読み込みの設定例 (KVS ベース)

3.2 提案手法の実装

Fig. 3 KVS-based Configuration Example of Dynamic Server
Certificate Management.

提案手法の実装には，nginx の機能拡張を mruby で記述
でき，高速かつ少ないメモリ使用量で動作する ngx mruby

Nginx::SSL のインスタンスの certificate メソッドおよびを利用した．また，OpenSSL ライブラリ [13] のバージョ

certificate key メソッドにファイルのパスを渡すことで，ン 1.0.2 以降から，SSL/TLS ハンドシェイク時にサーバ証

SSL/TLS ハンドシェイク時に動的にサーバ証明書と秘密鍵

明書や秘密鍵を読み込むような関数をコールバックできるを読み込むことができる．図 3 は，サーバ証明書を Redis

関数 SSL CTX set cert cb()[14] が利用できるようになっという Key-Value Store(KVS) に保存しておき，ホスト名

たため，その関数を利用して，nginx における SSL/TLS ハからデータのキーを決定し，キーに紐づくサーバ証明書

ンドシェイク時に呼び出すコールバック処理を，mruby でデータを取得する例である．certificate data メソッドおよ

記述できるようにした [16]．これにより，サーバ管理者はび certificate key data メソッドは，サーバ証明書や秘密鍵システムの用途に合わせて簡単に動的証明書の実装が可能のデータを直接渡すことにより，SSL/TLS ハンドシェイとなる．

ク時に動的に読み込むことができる．

ngx mruby を利用した，SSL/TLS ハンドシェイク時に実運用における設計としては，図 4 のように，サーバ

動的にサーバ証明書と秘密鍵を読み込む実装例を示す．

証明書や秘密鍵のデータはデータベースに保存しておき，

図 2 は，動的にサーバ証明書を，リクエストのあったホ

nginx が HTTPS リクエストを受信した際，ngx mruby 経

スト名からファイルのパスを決定して読み込む例である．

由で SSL/TLS ハンドシェイク時にデータベースから取得

c 2017 Information Processing Society of Japan⃝4

情報処理学会研究報告
IPSJ SIG Technical Report
表 2 従来手法のプロセスの起動時間とメモリ使用量の検証結果

Table 2 Result of Startup Time and Memory Usage of Process
by Existing Method.

図 4

動的なサーバ証明書読み込みのシステム例

Fig. 4 System Example of Dynamic Server Certificate Management.

項目

値

プロセス起動の実時間42.662 sec

プロセス起動のユーザ CPU 使用時間

37.280 sec

プロセス起動のシステム CPU 使用時間

5.387 secプロセスのメモリ使用量（VSZ）

3207592 KBytes

プロセスのメモリ使用量（RSS）

3175912 KBytes

4.1 従来手法のメモリ使用量と起動時間の検証
2.1 節で述べた課題について，表 1 の環境において，nginxのバージョン 1.11.13 を利用して検証する．openssl コマ
ンドによって生成した 10 万ホスト分の 4096bits の鍵長の

表 1 実験環境

Table 1 Experimental Environment.
仕様

サーバ証明書と秘密鍵を nginx のホスト設定毎に記述し，nginx のサーバプロセスの起動時間とメモリ使用量を計測した．nginx は，最初に起動する master プロセスがサーバ
証明書のデータなどを全て読み込み，その処理が完了後にCPUIntel Xeon E5-2620 v3 2.40GHz 24core

Memory32GBytes

Server

NEC Express5800/R120f-2E

テムコールにより複製される．本実験環境では，worker プ

OS

CentOS6 Linux Kernel 4.8.14

ロセスは CPU の論理コアの数だけ起動させるように設定

リクエスト処理を担当する worker プロセスが fork() シス

し，24 個の worker プロセスが起動を完了するまでの時間
を，Linux の time コマンドにより，実時間，システム CPU
したサーバ証明書と秘密鍵を取得して SSL/TLS セッショ

使用時間，および，ユーザ CPU 使用時間を計測した．まンを確立する．その際に，リクエスト毎にデータベースへた，起動完了後の worker プロセスのメモリ使用量は， ps

接続するコストを低減するため，保存できるデータサイズ

コマンドの仮想メモリ使用量 (VSZ) と物理メモリ使用量は少ないものの，高速にデータの取り出しを行える Redis(RSS) 項目を用いて計測した．

のような KVS を使ってキャッシュとして一時的にデータ

表 2 に結果を示す．表 1 の環境の CPU では，10 万ホスを保存しておく．また，データベース及びキャッシュサー

ト分のサーバ証明書と秘密鍵を読み込むのに 42.662 秒か

バと TCP 接続を行うことにより，可用性や性能のためにかった．サーバ証明書等の読み込みは最初に単一の master

サーバ台数を増やしても，簡単にサーバ証明書に関するプロセスが処理するため，CPU を一つだけしか利用できデータを共有できる．複数台の Web サーバで HTTPS 通

ないため，コアあたりの性能に依存する．そのため，CPU

信の負荷分散を行う場合に，Web サーバからキャッシュの使用効率をコア数で高めていく時代においては，この処

サーバへのネットワークレイテンシが性能面で問題となる

理時間を大幅に短縮することは困難である．ユーザ CPU

場合は，データベース，キャッシュサーバに加えて，インやシステム CPU の使用時間については特筆すべき点は見メモリキャッシュも用いるといったシステム設計も可能で当たらなかった．

ある．

4. 実験と考察

メモリ使用量は，ps コマンドから得られるプロセスの仮想メモリ使用量（VSZ）と物理メモリ使用量（RSS）を計測した結果，両項目共に 3GB 程度となった．昨今の Web

本手法の有効性を確認するために，2.1 節と 2.2 節で述べサーバが搭載している物理メモリは数十 GB から数百 GBた従来の課題において，Web サーバプロセス起動時に予めも一般的になってきているため，プロセスが占有する 3GB

データを読み込んでおく従来の方式 (preload) の，起動時のメモリ使用量では，サーバの物理メモリ量の不足という間とメモリ使用量，および，CGI で多用される fork() シス

観点では問題にならない場合も多い．しかしながら，2.2

テムコールと execve() システムコールの実行に関する問題

節で述べたとおり，プロセスが数 GB のメモリを使用するを，実験から明らかにする．続いて，Redis にサーバ証明

ことによる OS のプロセスとメモリ管理に起因する性能面

書と秘密鍵データを保存しておき， SSL/TLS ハンドシェの問題が生じ得る．

イク毎にデータをファイルや Redis から取得する提案手法(dynamic load) と，従来の方式 (preload) の性能を比較する．表 1 に実験環境を示す．

c 2017 Information Processing Society of Japan
⃝4.2 従来手法のメモリ使用量と性能の検証
2.2 節で述べた課題について，表 1 の環境において，高5

情報処理学会研究報告
IPSJ SIG Technical Report

集積マルチテナント方式によって多数のホストを収容し，



プロセスのメモリ使用量が増加した場合の性能への影響を

22.38% [kernel] [k] copy_pte_range

検証するために，筆者の勤務先である GMO ペパボ株式会

18.44% [kernel] [k] zap_pte_range

社にて Apache httpd バージョン 2.4.9 を利用して実際に稼動しているホスティングサービス環境において，収容ホ
スト数の違うパターンで動作しているサーバを選択し，メ
モリ使用量によって fork() システムコールの CPU 使用時
間がどの程度変動するかを検証した．収容数は，2456 ホス

11.13% [kernel] [k] change_pte_range
3.58% [kernel] [k] page_fault
3.32% [kernel] [k] page_remove_rmap




図 5

高負荷時のカーネルのデバッグログ

Fig. 5 Kernel Debug Log Under Heavy Load.

ト，13408 ホスト，22259 ホストのパターンを用意し，その時のプロセスのメモリ使用量と CGI を実行した時の fork()

用されていた．図 5 は，調査時のカーネル内の処理であシステムコールの処理時間を Linux の strace[18] によってる．copy pte range は，clone() システムコールの内部処理計測した．fork() システムコールは，表 1 で採用しているで，ページテーブルエントリのアドレスをコピーする処理

Linux カーネルバージョン 4 系では，clone() システムコー

であり，zap pte range は execve() システムコールの内部

ルとして実行されているため，clone() システムコールの処処理で，ページテーブルエントリのアドレスを削除する処

理時間を計測した．

理である．図 5 の perf のログからも，ページテーブルエ

表 3 に結果を示す．ホスト数に概ね依存してメモリ使用量も増加しており，メモリ使用量に応じて clone() システ

ントリのアドレスの処理の負荷は，プロセスのメモリ使用量に強く依存することがわかる．

ムコールの CPU 使用時間が増加していることがわかる．

2.2 節で述べたとおり，clone() システムコールの実行時に

4.3 提案手法の性能評価

おいては，Copy on Write によりメモリコピーはほとんど

Web サーバプロセス起動時に静的にサーバ証明書等を生じないが，ページテーブルエントリのコピーは必要であ

読み込む方式による，メモリ使用量と起動時間が増加する

る．そのため，プロセスのメモリ使用量が増加したことに問題を解決するための提案手法について，評価を行った評よってページテーブルエントリ数が増加し，ページテーブ

価には，Web サーバソフトウェアとして ngx mruby を組

ルエントリのコピーによってシステム CPU 使用時間が増み込んだ nginx を用いた．図 6 に ngx mruby の設定を示加している．

す．ポート 58080 で Listen する設定は，提案手法によっプロセスのメモリ使用量が 1.6GB 程度になると，clone()て SSL/TLS ハンドシェイク時に，リクエストされたホス

システムコールは表 1 の環境で 0.05 秒の CPU を使用する

ト名をキーにサーバ証明書と秘密鍵を読み込む設定であことになる．clone() システムコールの CPU 使用時間がシる．また，ポート 58081 は Web サーバプロセス起動時にステム CPU であることを考えると，1 コアで 1 秒間に最サーバ証明書等を静的に読み込んでおく従来手法の設定

大 20 回程度しか clone() システムコールを実行できないこである．両方の設定は，サーバ側での cipher suites を固定とになり，clone() システムコールや，ページテーブルエ

し，SSL/TLS ハンドシェイク時の影響を最大化するためントリを削除する処理が実行される execve() システムコーに，SSL/TLS セッションキャッシュが生じないようにしルの実行時間，実際のユーザ CPU による CGI のコンテン

た．従来手法の設定と提案手法の設定双方で読み込む証明

ツの処理も考慮すると，clone() システムコールと execve()

書を一つにしているのは，複数の証明書であっても従来手システムコールが実行される CGI のような処理では，1 コ法は nginx の中でハッシュとして扱われるため計算量はアで少なくとも 1 秒間に数回程度しか実行することができO(1) であり，KVS からドメインをキーに証明書を取得すない．

る処理も O(1) であるため，一つの証明書に関するデータ

Web サーバの処理において，C10K 問題 [8] のように同で評価には必要十分であると推察したためである．

時並行的に処理することが当たり前とされる時代において，性能を比較するために，wrk[24] という HTTPS のベンチ

1 コアで 1 秒間に数回程度のリクエスト処理しかできない

マークソフトウェアを使い，同時接続数を変化させながら総という状態は非常に問題である．また，サーバ証明書を読リクエストで 500 万リクエスト送信し，1 秒間に処理できる

み込むことでさらにメモリ使用量が増大するため，CGI のリクエストの数を計測した．一般的にベンチマークで広くような処理を効率的に処理できないことは明らかである．

使われる ab[21] コマンドは，シングルスレッドで動作する

上記のホスティングサービス環境で，サーバの高負荷状ため，HTTPS のベンチマークを行う場合は，サーバソフト態に陥った状況で，CPU の使用率を調査すると 80%以上シ

ウェアよりも先にベンチマークコマンドが SSL/TLS ハン

ステム CPU が使用しており，その状態でのカーネルの処

ドシェイク時の CPU 使用時間によって一つの CPU コアを

理を perf コマンドにより調査したところ，システム CPU

使い果たしてしまう．そこでこの問題を回避するため，マル使用率の 50%以上は，ページテーブルエントリの操作に利チスレッドで動作する wrk を採用した．TLS のバージョン

c 2017 Information Processing Society of Japan⃝6

情報処理学会研究報告
IPSJ SIG Technical Report
表 3 従来手法のプロセスのメモリ使用量と性能の検証結果

Table 3 Result of Memory Usage and Performance of Process by Exisiging method.
ホスト収容数プロセスのメモリ使用量（RSS）

clone() システムコールの実行時間

2456

256624 KBytes

0.010114 sec

13408

611368 KBytes

0.028492 sec

22259

1624012 KBytes

0.053687 sec



表 4 実験結果

Table 4 Experimental Result of Proposed Method.

# dynamic certificate
server {listen58085 ssl;

提案方式

従来方式

dynamic load(req/sec)

preload(req/sec)

server_name

_;

同時接続数

ssl_protocols

TLSv1 TLSv1.1 TLSv1.2;

10171456.60

171914.98

ssl_ciphers

HIGH:!aNULL:!MD5;

100

172383.84

172758.28

ssl_certificate/path/to/dummy.crt;

500172714.81

173631.06

ssl_certificate_key /path/to//dummy.key;

1000

171872.24

173272.53

ssl_prefer_server_ciphers on;

表 4 に結果を示す．実験結果では，事前にサーバ証明

ssl_session_cache off;

書を読み込む従来方式と今回提案した方式の間に性能差はmruby_ssl_handshake_handler_code ’

ほとんどないことを観測した．今回採用した cipher suites

ssl = Nginx::SSL.new
redis = Userdata.new.redis

は，SSL/TLS ハンドシェイク時の鍵交換時に利用される

domain = ssl.servername

暗号化アルゴリズムとして RSA を利用しており，暗号化

ssl.certificate_data = redis["#{domain}.crt"]と複合の処理が証明書を動的に読み込むか静的に読み込ん

ssl.certificate_key_data = redis["#{domain}.key"]

だメモリ領域から取得するかの処理と比較してほとんど無’;視できる程度の処理であるためだと考えられる．また，同location / {時接続数が 1000 の場合に従来方式と提案方式共に多少性

root /path/to/html/;能が劣化しているが，その差異も 1%未満であるため誤差}の範囲だと判断した．

}

従来の静的に読み込む方式では，高集積マルチテナント# preload certificate

方式においては，ホスト数に依存してメモリ使用量が大きserver {listen58086 ssl;

くなり，4.2 節で述べた問題がある．これに対して提案手

server_name_;法である動的読み込み方式は Web サーバプロセスがサー

ssl_protocols

TLSv1 TLSv1.1 TLSv1.2;

ssl_ciphers

HIGH:!aNULL:!MD5;

バ証明書等のデータをメモリに保存しておく必要がない

ssl_certificate/path/to/dummy.crt;

ためメモリ使用量は非常に少なく，かつ，性能面でも実

ssl_certificate_key /path/to/dummy.key;

用的である．証明書の保存方法についても，Redis のようなキャッシュサーバを TCP で接続できるようにしておく

ssl_prefer_server_ciphers on;

ことで，HTTP と比較して多くの CPU 処理が必要となる

ssl_session_cache off;

HTTPS においても，サーバを複数台増やす事で簡単にス
location / {ケールアウト [4] によるサーバ増強が可能となって，運用

root /path/to/html/;

上のメリットも大きい．

}
}




図 6

動的読み込みと事前読み込みの設定

Fig. 6 Configuration of Dynamic Loadding and Preloading.

は TLSv1.2 を利用し，cipher suites は，現在セキュリティ

予備実験として，Redis からサーバ証明書データを取得する方式以外に，動的にファイルパスをホスト名から決定
して読み込む方式も評価を行ったが，ほとんど性能差は見られなかった．

5. まとめを担保するために Mozilla が推奨している cipher suites[9]HTTP/2 の RFC 採択に伴い，常時 HTTPS が進む中での中から ECDHE-RSA-AES128-GCM-SHA256 を利用しは，高集積マルチテナント方式を採用している Web サー

た．リクエストするコンテンツは nginx に同封されているバにおいて，Web サーバプロセス起動時にホストに紐づく

612Bytes の index.html を利用した．

サーバ証明書を大量に読み込む必要があり，Web サーバプ

c 2017 Information Processing Society of Japan⃝7

情報処理学会研究報告
IPSJ SIG Technical Report

ロセス起動に時間がかかる問題や Web サーバプロセスがメモリを大量に使用することにより性能が劣化する問題が

[11]

あった．
提案手法では，SSL/TLS ハンドシェイク時に SNI を前提にリクエストのあったホスト名から該当するサーバ証
明書と秘密鍵を読み込み，HTTPS 通信を行うことによっ

[12]
[13]

て，起動時に大量のサーバ証明書を読み込むことなく動的に HTTPS 通信を行うことができる．また，TLS のハンド

[14]

シェイク時のコストと比較し，動的に証明書を読み込む処
理はコストの低い処理となるため，実用上問題にならない
性能がでることを実験から示した．さらに，サーバ証明書[15]

データを一元管理することにより，HTTP よりも CPU の処理コストの高い HTTPS 通信においても，SSL/TLS ハ
ンドシェイク時の性能不足を簡単にスケールアウトによる[16]

サーバ増強が可能となるため，今後の高集積マルチテナン
ト方式の常時 HTTPS 化を達成するための実運用可能なシステム設計を実現する上で有望な方式の一つということが

[17]
[18]
[19]

できる．提案手法の応用例として，Let’s Encrypt と連携して，Web サーバに対して A レコードさえ向いていれば，最初の HTTPS アクセス時に自動的に DV 証明書を取得して設定し，HTTPS 通信を行うようなシステム設計も可能である [30]．
参考文献
[1]

[2]
[3]
[4]

[5]

[6]

[7]

[8]
[9]

[10]

Accetta M, Baron R, Bolosky W, Golub D, Rashid R,
Tevanian A, Young M, Mach: A new kernel foundation
for unix development. In USENIX Conference, pages 93112, 1986.
Belshe M, Thomson M, Peon R, Hypertext Transfer Protocol Version 2 (HTTP/2). RFC 7540, 2015.
Eastlake D, Transport Layer Security (TLS) Extensions:
Extension Definitions, RFC 6066, 2011.
Ferdman M, Adileh A, Kocberber O, Volos S, Alisafaee
M, Jevdjic D, Falsafi B, Clearing the clouds: a studyof emerging scale-out workloads on modern hardware,
ACM SIGPLAN Notices, Vol. 47, No. 4, pp. 37-48,
March 2012.
Ilya Grigorik, Pierre Far, Google I/O 2014 - HTTPSEverywhere,
https://www.youtube.com/watch?v=
cBhZ6S0PFCY.
Internet Security Research Group (ISRG), Let’s Encrypt- Free SSL/TLS Certificates, https://letsencrypt.
org/.
Han J, Haihong E, Le G, Du J, Survey on NoSQL
database. 2011 6th International Conference on Pervasive computing and applications (ICPCA), pp. 363-366,
October 2011.
Kegel D, The C10K problem, http://www.kegel.com/
c10k.html.
Mozilla Project, mozilla wiki Security/Server Side
TLS, https://wiki.mozilla.org/Security/Server_
Side_TLS.
Mietzner R, Metzger A, Leymann F, Pohl K, Variability
Modeling to Support Customization and Deployment ofMulti-tenant-aware Software as a Service Applications,the 2009 ICSE Workshop on Principles of Engineeringc 2017 Information Processing Society of Japan
⃝

[20]
[21]

[22]

[23]

[24]
[25]

[26]
[27]

[28]

[29]

[30]

Service Oriented Systems, pp. 18-25, May 2009.
Naylor D, Finamore A, Leontiadis I, Grunenberger Y,
Mellia M, Munaf M, Steenkiste P, The cost of the S
in HTTPS, the 10th ACM International on Conferenceon emerging Networking Experiments and Technologies(CoNEXT ’14), pp. 133-140, ACM, December 2014.
Nginx, Nginx, http://nginx.org/ja/.
OpenSSL Software Foundation, OpenSSL, https://www.openssl.org/.
OpenSSL Software Foundation, SSL CTX set client certcb,SSL CTX get client cert cb - handle client certificate
callback function, https://www.openssl.org/docs/
man1.0.2/ssl/SSL_CTX_set_client_cert_cb.html.
Prodan R, Ostermann S, A Survey and Taxonomy ofInfrastructure as a Service and Web Hosting Cloud
Providers,10th IEEE/ACM International Conference on
Grid Computing, pp. 17-25, October 2009.
Ryosuke M, ngx mruby: Support ssl handshake handler
and dynamic certificate change, https://github.com/
matsumotory/ngx_mruby/pull/145.
Sanfilippo S, Noordhuis P, Redis, https://redis.io/.
strace - linux syscall tracer, https://strace.io/.
Takahiro Okumura, Dynamic certificate internals with
ngx mruby, https://speakerdeck.com/hfm/dynamiccertificate-internals-with-ngx-mruby-numbernagoyark03.
The Apache Software Foundation, Apache HTTP Server,
http://httpd.apache.org/.
The Apache Software Foundation, ab - Apache HTTP
server benchmarking tool, https://httpd.apache.
org/docs/2.4/programs/ab.html.
The Apache Software Foundation, Apache HTTP Server
Version 2.4 Apache Module mod ssl, http://httpd.
apache.org/docs/current/mod/mod_ssl.html.
The Apache Software Foundation, Apache Tutorial: Dynamic Content with CGI, http://httpd.apache.org/
docs/2.2/en/howto/cgi.html.
Will Glozer, wrk - a HTTP benchmarking tool, https://github.com/wg/wrk.
アスタミューゼ株式会社, nginx + ngx mruby で SSL
証明書の動的読み込みを実現して、作業がとても楽にな っ た 話, http://lab.astamuse.co.jp/entry/2016/11/30/114500.
NPO 法人軽量 Ruby フォーラム, http://forum.mruby.
org/.
BASE 株 式 会 社, BASE 開 発 チ ー ム ブ ロ グ 独 自 ド メ
インのショップで https でアクセスできるようになりました, http://devblog.thebase.in/entry/2017/03/
22/111015.
松本亮介, 岡部寿男, mod mruby：スクリプト言語で高速かつ省メモリに拡張可能な Web サーバの機能拡張支援機構 , 情報処理学会論文誌, Vol.55, No.11, pp.2451-2460,
2014 年 11 月
松本亮介, 川原将司, 松岡輝夫, 大規模共有型 Web バー
チャルホスティング基盤のセキュリティと運用技術の改善, 情報処理学会論文誌, Vol.54, No.3, pp.1077-1086,
2013 年 3 月.
松本亮介, ngx mruby で最初の HTTPS アクセス時に自動で証明書を設定可能にする FastCertificate の提案と PoC, http://hb.matsumoto-r.jp/entry/2017/03/
23/173236.

8