1．コンテナを活用したサービスの普及と課題

企業や個人がSNSを始めとした各種インターネットのサービスを活用することによって，生活の仕方や働き方が多様化し，インターネット上で自らを表現する機会が増加している．特に専門的な知識のない個人にとっても，TwitterやFacebookを活用して，短い文章を書くだけでなく，自身が作成したコンテンツを拡散させることにより，効率よくコンテンツへの訪問数を増やすことができるようになった．その結果，コンテンツの内容の品質が高ければ，さらに拡散され，コンテンツに紐づく個人のブランド化や仕事への展開も可能になってきている．一般的に個人が自由にWebコンテンツを配信するためには，Webホスティングサービス，クラウドサービスなどが利用される[26]．

Webホスティングサービスやクラウドサービスの低価格化と性能の向上，および，多数の機能提供[1]の背景には，Webアプリケーションの複数の実行環境を単一のWebサーバ上でセキュリティを担保しながら安定なサービスを提供するために，OSの仮想化技術[7]が活用されている．OSの仮想化技術の中でも，プロセス単位でユーザ領域を隔離してリソース管理ができるコンテナ型の仮想化技術[31]を活用することにより，仮想マシンと比べて，複数の実行環境の収容効率を高めることができる．また，プロセス単位でCPUやメモリなどの割当リソースやプロセスがアクセス可能な名前空間を詳細に設定することにより，複数プロセス間やプロセスと収容されているホストOS間でのセキュリティやリソースの隔離も担保できる．また，仮想マシンと比較して，高速に仮想環境を起動することも特徴であるため，アプリケーション実行環境のデプロイや再配置，負荷分散のためスケーリング処理が高速に実現できる．

一般的に，単一のサーバに複数のユーザ領域を収容するようなWebホスティングサービスでは，利用者のWebコンテンツデータが特定のWebサーバに紐づくため，負荷分散することが難しい[37]．また，クラウドサービスの場合は，利用者がデータの特性を考慮してアクセス集中に耐え得るオートスケール[29]の仕組みを作る必要があったり，各サービス・プロバイダが提供しているオートスケールの機能を使う必要がある．AWS^☆1などのサービス・プロバイダが提供しているオートスケール機能では，サービス・プロバイダ自身が提供する監視項目に基づき，内部で自分で構築した仮想マシンを起動させたり，外部のサービスを利用して仮想マシンを自動で起動させる必要がある．そのため，突発的なアクセス集中に対して，スケール処理に時間がかかり負荷分散が間に合わない場合が多い[14]．また，AWS Lambda[4]やFargate[2]，Google Cloud Serverless Computing[12]，Azure Functions[5]のようなServerless[22]サービスや，コンテナのオーケストレーションサービス[6],[11]を利用することで，サービス提供者側で自動でリソースを分配しオートスケールをするサービスもある．しかし，サービス提供側が指示するプログラミング言語の仕様にそってWebアプリケーションやシステムを実装する必要があり，専門的知識のない個人の利用者には実現困難である．

本研究では，WordPress^☆2ようなWebアプリケーションをユーザ環境に配置できる程度の，従来のWebホスティングサービスを利用できるような知識を持った個人がWebコンテンツを配信することを前提にする．その上で，そのような個人のサービス利用者が，アクセス集中時に負荷分散のシステム構築やライブラリの運用・管理を意識せず，Webアプリケーションが配置されているコンテナの状態をHTTPリクエスト単位でリアクティブに決定する，実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャを提案する．Webアプリケーションの実行におけるユーザのデータは共有ストレージやデータベースで共有し，アプリケーションの処理を明確に分離した上で，迅速に負荷分散処理を実現するために，HTTPリクエストを契機に，コンテナの起動処理，起動継続時間，リソース割り当ておよびコンテナ起動数を決定する．さらに，コンテナ上で実行されるWebアプリケーションを高速に起動させるために，起動処理完了直前のWebアプリケーションプロセスをLinuxのプロセスのダンプとリストアを可能にするCRIU[8]によってイメージ化しておき，起動時にはイメージからリストアする．

本研究で提案するアーキテクチャを実現することで，第4章の実験環境における評価で，オートスケールアップおよびオートスケールアウト，両方のオートスケーリングにおいても，CRIUを使っていない状態で，スケール処理が始まってから2sから5sでレスポンス性能が向上できること確認した．また，コンテナのように起動の所要時間が小さい実行環境とコンテナ上で動作するWebアプリケーションプロセスのイメージ化を活用することにより，Ruby on RailsのようなWebアプリケーションフレームワークがコンテナの停止状態であってもHTTPリクエストに応じて1200msでレスポンスを返すことができる．また，コンテナが一定期間で破棄され，プロセスの起動時間を短縮することによって，マルチテナント方式[23]のリソース効率を高め，同時に，ライブラリが更新された場合には新しい状態へと更新される頻度が高くなる．

本稿の構成を述べる．第2章では，Webホスティングサービスやクラウドサービスにおける負荷分散技術と運用技術，および，その課題について述べる．第3章では，第2章の課題を解決するための提案するシステムアーキテクチャの設計と実装を述べる．第4章では，提案するシステムアーキテクチャを実装して，オートスケーリングの効果やイメージから高速に起動させた場合のレスポンスの定量評価と考察を行い，第5章でまとめとする．

2．負荷分散技術と運用技術

コンテンツを配信するWebサーバに対してアクセスが集中し，コンテンツを幅広く閲覧される可能性が高い状況においては，サーバが高負荷状態となってアクセスが困難となり，貴重なコンテンツ拡散の機会を逃すことも多い．負荷対応のためのスケール手法は，大きく分けて，稼働している単一のインスタンス^☆3に割り当てるハードウェアリソースを増減させるスケールアップ型と，複数のインスタンスへと起動数を増減することによって負荷分散を行うスケールアウト型の2つに分類できる．本章では，Webホスティングサービスやクラウドサービスにおける，スケール手法の分類に基づいて，負荷分散のためのオートスケールや関連する運用技術について整理する．

2.1　Webホスティングサービス

一般的なWebホスティングサービス[26]では，サービス利用者のWebコンテンツは特定のWebサーバのテナントに収容され，WebサーバとWebコンテンツが紐づくため，負荷に応じたオートスケールはデータの整合性の面で困難である．このような場合に適用可能な手法として，ユーザデータ領域を共有ストレージにまとめた上で，仮想ホスト方式を採用した複数台のWebサーバで負荷分散を行う手法[38]がある．この手法には，テナントを高集積に収容できるメリットがある一方で，以下の課題がある．

仮想ホスト方式では複数のホストを単一のサーバプロセス群で処理するため，リクエストはサーバプロセス群に含まれるWebサーバの処理プロセスを共有して処理される．そのため，ホスト単位で使用するリソースを適切に制御したり，その原因を迅速に調査することが困難[36]であり，スケール時のコスト計算や必要な時に必要なだけリソースを追加するような方式が利用できない．また，テナント単位での負荷に応じて，一時的に割当リソースを増減させて負荷を簡易的に分散させるような，即時性の高いスケールアップ型の負荷対応もできない．

運用技術の観点からは，ライブラリの更新の際に，沢山のホストを単一のWebサーバプロセスで処理している特性上，Webサーバ・ソフトウェアの更新や設定変更におけるサーバプロセスの再起動時のサービス影響が大きくなる．また，サーバ高負荷時には，リソースを適切に限定することが困難であるため，高負荷原因の調査と制御にコストがかかり[39]，サービス品質への影響も大きい．

また，サービス利用者の観点では，利用できるWebサーバソフトウェアをはじめとしたミドルウェアおよび機能が全ホスト共通となり，Apache httpdで構築されている場合はApache httpdの機能に依存するため，各種プログラミング言語で実装されているWebアプリケーションサーバのアプリケーションが使えないといった観点で自由度が低い．

2.2　クラウドサービス

クラウドコンピューティング[25]とは，ネットワークやサーバといったコンピュータリソースのプールから必要なときに必要な量だけオンデマンドに利用可能とするコンピューティングモデルである．クラウドサービスはクラウドコンピューティングを各種サービスとして提供するサービスである．

クラウドサービスでは，Webコンテンツだけでなく，Webサーバソフトウェアやデータベースをサービス利用者が自ら構築する必要がある．そのため，負荷分散のためのシステム設計を個別に行うことができる点において自由度は高いが，専門的な知識が必要となる．オートスケールについても，負荷に応じて増減させる機能が提供されている[3]が，その負荷の監視間隔が分の単位であり，突発的なアクセスに対して検知するまでの時間が長くなる．負荷状況に応じて仮想マシンを起動させたとしても，テレビ放映の影響のような突発的な高負荷時に，オートスケールのための処理自体が追いつかず，サービス停止に繋がることも多い．

仮想マシンの起動時間の問題を解決するためにコンテナを利用する手法[14]や，外部サービス連携によってスケールを行う条件を詳細に定義できるサービス^☆4もある，これらのサービスでは，スケール時の判定を行う際に，外部サーバなどからOSの負荷やプロセスの状態等を監視する方式がとられており，監視の時間間隔や取得できる情報の粒度が荒く，突発的な負荷に対して即時性が低くなる問題もある．高負荷状態に対して迅速に対応する即時性を持たせるためには，事前にある程度想定される量の仮想マシンを起動させておくことによって対処する必要がある．しかし，定量的な見積もりや事前のメンテナンスが必要であったり，限られたコストの兼ね合いから適切な見積もりをすることは困難である．そのため，負荷の状態に基いて適切なインスタンスの数を決定することは難しく，必要以上にコンピュータリソースを使用していることが多い．

また，Webホスティングサービスで使われるような仮想ホスト方式であれば，単一のサーバプロセスで複数のテナントへのリクエストを共有して仮想的に転送するため高集積にテナントを収容できる．一方で，コンテナの場合はテナント単位でコンテナを立ち上げる必要があるため，テナント数に依存してプロセス数が増加するため常時専有するリソースが増加し，収容率が仮想ホスト方式よりも低下する．

上記のような問題を解決するために，クラウドサービスプロバイダは，プロバイダ指定の記法によってアプリケーションを実装すれば，自動的にコンピュータリソースを決定し，高負荷時には自動的にプロバイダ側でオートスケールするServerless[22]のサービス[4],[12]を提供している．しかし，前提としてプログラミングができるエンジニアを対象としており，一般的なOSSとして公開されているWebアプリケーションを利用できないことが多く，処理の実行時間が限定的であるといった使用上の制限が大きい．

コンテナのオーケストレーションサービス[6],[11]を利用することで，コンテナ上にWebアプリケーションを配置し，サービス利用者の設定によって，サービス適用側のシステムにおいて自動でリソースを分配したり，オートスケールをしたりするするサービスもある．しかし，このようなサービスを使う場合に，専門的な知識なくWebコンテンツを公開した上でコンテナのリソース管理やオートスケールを実現することは困難である．

SaaSとしてのブログサービスやTwitter，Facebookといったマイクロブログサービスは，専門的な知識が必要なくコンテンツを発信できる利点があるが，SaaSである特性上，各種サービスに指定された仕様に依存するため，個人の表現において自由度が低くなる．

2.3　Webサーバ機能のプロアクティブ性とリアクティブ性

突発的なアクセス集中といった大きな変化に耐え得るシステムを，限られた資金やリソースの中で構築するためには，負荷の状態に基いて適切なインスタンスの数を決定し，必要以上にコンピューティングリソースを使用しないように設計することも重要である．単一のサーバに高集積にホストが収容可能であり，ホスト単位でのリソース管理を適切に行いながら，セキュリティと性能および高負荷に強いWebホスティング環境を構築することを目的とした場合，Webサーバ機能をプロアクティブ性とリアクティブ性に基いて分類できる．以下に，Webサーバ機能のプロアクティブ性とリアクティブ性を定義する．

プロアクティブ性とは，Webサーバ機能を持つ仮想マシン，コンテナおよびWebサーバプロセスがあらかじめ起動しており，リクエストに応じて仮想マシンやコンテナの状態を即時変更できないが，常に起動状態であるため，高速にリクエストを処理できる性質とする．そのため，常時Webサーバ機能を稼働させておく必要があるためハードウェアリソースを専有するため，リソース効率が悪い．プロアクティブ性を持ったオートスケールは，たとえば2.2節で述べたように，事前にアクセス頻度から予測を行い，予測に基づいた数だけあらかじめインスタンスを起動させておくようなアプローチである．

リアクティブ性とは，CGIやFastCGI[9]，あるいは，xinetd[24]のように，アプリケーションが実用上現実的な速度で起動可能であることを前提に，リクエストに応じてサーバプロセスを起動する性質とする．リアクティブ性を持つWebサーバ機能は，起動と停止のコストは生じるため，性能面はプロアクティブ性を持つWebサーバ機能より劣るが，リクエストを受信しない限りはプロセスが起動しないため，リソース効率がよい．また，リクエストに応じて複数起動させるといった変更に強い処理が実装しやすい．一例として，FastCGIはリソース効率と性能を両立するために，一定期間起動して連続するリクエストを高速に処理可能とするアーキテクチャをとっている．

しかしながら，CGIのようなリアクティブ性に基づく従来の処理手法は性能面の問題などから利用されなくなってきており，オートスケールについても，リクエスト単位で仮想マシンやコンテナを都度起動させるコストを考慮すると，実用的な性能を満たすことは困難である．

3．提案する恒常性を持つシステムアーキテクチャ

インターネット技術に関する専門知識を持たない個人がSNSなどを通じてインターネットをより活用し自己表現を行うには，WordPressや各種プログラミング言語で提供されているアプリケーションサーバによって実装されたWebアプリケーションをサービス管理画面からユーザ環境に配置できる程度の，従来のWebホスティングサービスを利用できるような知識を持った個人がWebコンテンツを配信することを前提にする必要がある．その上で，そのような個人のサービス利用者が，アクセス集中時に負荷分散のシステム構築やコンテンツ配信に必要なソフトウェアのバージョンアップをはじめとして，関連するソフトウェアのライブラリの運用・管理を意識せず，低価格で利用でき，かつ，安定してコンテンツを配信し続ける必要がある．

サービス提供側においては，現状の関連研究や各種サービスの特徴を考慮した場合，限られたリソースの範囲内で負荷に応じて即時インスタンスを制御するためには，リアクティブ性を持つWebサーバ機能を前提に，インスタンスを状況に応じて起動・停止・複製し，実用上問題にならない程度の性能を担保するシステムアーキテクチャが必要となる． 以下に要件をまとめる．

• （1）HTTPリクエスト単位の粒度で迅速にインスタンスのスケールアウトとスケールアップができる
• （2）HTTPリクエスト単位の粒度でインスタンスの状態を定義し即時状態の変更命令を出せる
• （3）リソース効率化のため必要のないインスタンスは停止可能であり，必要なときにHTTPリクエスト単位で起動できる

また，このアーキテクチャによって実現されるWebホスティングサービスとしては以下の要件が必要となる．

• （1）OSやライブラリの更新作業のようなサーバ運用はサービス提供側が行う
• （2）広く使われる一般的なWebアプリケーション（WordPressなど）を利用できる
• （3）アクセスが集中した際に専門的な知識がなくてもオートスケールによる負荷分散を行える
• （4）Webアプリケーション実行時間程度の粒度での課金が可能である
• （5）ホストの収容効率を高めることによってハードウェアコストを低減する
• （6）高頻度でセキュリティを担保するためのOSやライブラリの更新が行われる

そこで，本研究では，Webコンテンツを配信するために，サービス利用者が負荷分散のシステム構築やライブラリの運用・管理を必要とせず，迅速にユーザ領域を複数のサーバに展開可能とするために，Webアプリケーションコンテナの起動，起動継続時間，起動数およびスケール処理の判定といった状態の変更をHTTPリクエストごとにリアクティブに決定し，実現するシステムアーキテクチャを提案する．このシステムアーキテクチャの特徴から，HTTPリクエスト単位で常に変化することができるため，実行環境や外部要因の変化に素早く適応でき，恒常性を持つ．このシステムアーキテクチャをFastContainerアーキテクチャと名付ける．

3.1　FastContainerアーキテクチャおよび関連技術

FastContainerアーキテクチャでは，インスタンスとして，仮想マシンではなくLinuxコンテナを利用する．Linuxにおけるコンテナ[10]はカーネルを共有しながらプロセスレベルで仮想的にOS環境を隔離する仮想化技術の1つである．コンテナの起動処理は仮想マシンのようなカーネルを含む起動処理と比べて，新しくプロセスを起動させる程度の処理で起動が可能であるため，起動時間が短時間で済むという特徴がある．また，コンテナ環境単位であるため広く使われているWebアプリケーションを隔離して利用できる．

図1に，FastContainerのフローを示す．図1のように，インターネット上からWebアプリケーションにリクエストが送信されると，システム内部でWebProxyが，リクエスト情報からWebアプリケーションが動作するコンテナの収容ホストを検索するために，（1）により収容ホストやコンテナの構成管理情報が保存されているデータベース（CMDB）にAPI経由で問合せて取得する．次に，（2）により，収容ホスト上に起動しているLocalWebProxyにリクエストを転送した上で，収容ホスト内のどのコンテナのWebアプリケーションへのリクエストであるかを，（3）により再度CMDBに問合せ，コンテナの構成管理情報を取得する．そして，（4）によりコンテナが起動していなければ，ContainerEngine経由で（5）によってコンテナを起動させてから，（6）によってリクエストを転送しWebアプリケーションにアクセスする．

FastContainerアーキテクチャでは，コンテナが仮想マシンと比較して速く起動できる点と，2.3節で述べたFastCGIのようにリソース効率を高めつつ，性能も担保するアーキテクチャを組み合わせた点が特徴である．そして，（5）におけるコンテナ上で起動するWebアプリケーションのユーザデータを共有ストレージに配置することで，複数の収容ホストを横断してコンテナが起動してもデータの整合性が保たれる．さらに，（3）により，HTTPリクエストごとに，Webアプリケーションコンテナの起動処理，起動継続時間，コンテナの起動数およびリソース割り当て設定を取得しリアクティブに状態を決定する．

提案手法では，（5’）によりコンテナが1つ以上起動していれば，（5）によるコンテナの起動を省略して即時レスポンスを送信し，コンテナが停止していた場合は，リクエストを契機に（5）によりコンテナを起動させてから．（6）により一定期間複数のリクエスト処理を行う．これによって，仮にコンテナがすべて停止していたとしても，コンテナがリクエスト単位で起動するため可用性が高くなる．

たとえば，メモリリークが生じるような不完全なソフトウェアが動作していたとしても，定期的に循環が行われることにより，メモリが解放される．この特徴により，システム全体がメモリ不足にならないため，そういったソフトウェアを許容できる．ただし，システムとしては許容できても，ソフトウェアとして不完すべてあることを検知する必要がある．また，一定時間起動することにより，一度コンテナが起動してしまえば，起動時間に影響なくレスポンスを送信できる．

アクセス集中時には，コンテナのリソース状態に合わせて，コンテナの状態を変えられるような構成にする．たとえば，すでに起動済みのコンテナがコンテナ自身のCPU使用時間の割り当ての失敗を示すcgroup[28]のthrottledの値を監視し，80%以上失敗していたらスケールアウトさせ，5分間の失敗の平均値が10%以下であれば，コンテナの起動継続時間に基づいてスケールアウトしたコンテナを停止させる，などである．ただし，本研究では，こういったリソース状態の監視と最適な状態の決定についてはスコープ外とし，そういった仕組みに対応できるシステムアーキテクチャの設計と実装を主目的とする．

スケールアウト処理時には，自動的に新しいコンテナの構成情報をコンテナの収容情報をCMDBに登録する．その後，コンテナの前段に配置されているLocalWebProxyがCMDBに基づいて，新しいコンテナへとリクエストを転送する．この転送作業では，（3）（4）（5）によりコンテナが収容されているサーバ上で動作しているLocalWebProxyが，プロキシ先のコンテナが起動していればそのままリクエストを転送し，起動していなければ，CMDBからコンテナの構成情報を取得して，コンテナを先に起動しリクエストを転送する．ただし，コンテナが起動中の場合は，これまで述べてきたとおり，すでに起動済みのコンテナにリクエストを転送し，起動が完了してからリクエストが振り分けられるようにする．Webアプリケーションに関するデータは共有ストレージ上に配置されているため，コンテナを収容するサーバ群は同一領域をマウントすれば，スケール処理によってどのサーバにコンテナが起動しても，CMDB上にコンテナの構成情報に基づいて適切に動作可能となる．

スケールアップについても，コンテナのリソース管理がLinuxのcgroupによってプロセス単位で制御されており，それらの構成情報はCMDBに保存されているため，cgroupの特徴を利用して，プロセスが処理中であってもCPU使用時間などの割り当てをリクエスト処理野中でリアクティブに変更できる．

状態遷移を高速に行うために，コンテナ上で起動するWebアプリケーションプロセスは，CRIU[8]を利用して，起動処理完了直後のプロセス状態をイメージ化しておく．その上で，コンテナ起動時にはそのイメージからリストアすることで，Ruby on Rails[27]のように，実装によっては数秒から数十秒かかるような起動時間の長いソフトウェアであっても，高速に起動可能になる．

提案手法では，コンテナの起動をCRIUをによって高速化させること，リクエストを契機としたリアクティブな起動処理であること，および，オートスケールの監視手法がリクエスト単位での粒度で行われることにより，突発的な負荷に対しても迅速にオートスケールが可能となる．また，コンテナが一定期間で破棄されることにより，不必要なプロセスの起動数を低減してコンテナの収容効率を高め，ライブラリが更新された場合には常に新しい状態へと更新されることが保証される．

3.2　Serverlessアーキテクチャや関連サービスとの違い

Serverlessアーキテクチャ[22]とFastContainerアーキテクチャとの違いについて述べる．Serverlessアーキテクチャは基本的にアプリケーションの運用を基盤側で行わないのに対し，FastContainerアーキテクチャでは，WordPress等の一般的なCMSを配置・オートスケール可能とし，アプリケーションの運用まで一部基盤側で対応する．また，AWS Lambda[4]やFargate[2]，Google Cloud Serverless Computing[12]，Azure Functions[5]などに類するServerlessアーキテクチャでは，サービス提供側の仕様に基づいて利用者による所定のコーディングが必要であるため，専門的な知識を有する利用者前提のサービスである．一方で，FastContainerアーキテクチャは汎用的なWebアプリケーションを利用でき，アクセス集中時には基盤側でスケーリングできるため，エンジニアの専門知識を持たない個人向けにも提供できる．ただし，FastContainerアーキテクチャにおけるデータベースのスケーリングは，基本的にコンテナへのリソース追加によるスケールアップが前提となる．

Heroku[15]の無料プランは，無料プラン利用によるサービスリソースを常時専有する使用量を低減するために，リクエスト単位で反応的にインスタンスを起動した後，インスタンスの稼働時間制限やリクエストを処理できないスリープ時間を設けている．Herokuのインスタンス上で状態を持つデータ，たとえばブラウザからアップロードしたファイルやセッション情報は，インスタンス再起動時に揮発し，永続化されない．Herokuの有料プランではスリープ時間がないことからも，定期的な再起動を行いながら，基本的にはコンテナを起動させ続けるアプローチによってリクエスト処理を安定的に処理するアーキテクチャと考えられる．

FastContainerアーキテクチャはリソース効率化に加えて，停止や起動，スケーリング処理やコンテナの別ハードウェアへの移動，複製などの状態の変化を高速化し，反応的に状態を変化させることによって常にインスタンスを循環させ，変化に強い恒常性を生み出すことが主目的である．また，コンテナに置かれた状態を持つデータはすべて永続化され，スケールアウト時であっても，複数のコンテナ間で共有される．さらに，コンテナの状態を監視することで適切な状態変化を行うための最適化や，サービスレベルとアクセス数からコンテナのライフタイムを適応的に決める手法の検討，コンテナの投機的起動により変化に強い恒常性を目指してシステムアーキテクチャを設計している．

3.3　Haconiwa：コンテナ管理ツール

FastContainerアーキテクチャをクラウド・ホスティングシステムとして実現するためには，コンテナの複雑な制御が必要である．そこで，このアーキテクチャを実現するために，我々は新たなコンテナ管理ツールであるHaconiwa[13],[34]を開発した．Haconiwaは筆者の1人である近藤らによって開発されており，コンテナのリソース割り当てやプロセス隔離の構成情報の設定だけでなく，コンテナ起動・停止時やコンテナのセットアップ時の各種フェーズでRuby DSL^☆5を実行することにより，コンテナの振る舞いをプラガブルに定義できるソフトウェアである．Haconiwaはコンテナを固定的な仮想環境としてのみ利用するだけでなく，プログラムで制御が可能な分散システム上で動作するある種のスレッドとみなせるような方針で開発されている．

Haconiwaは，FastContainerアーキテクチャのように，リクエスト単位でリアクティブにコンテナを起動させることができ，かつ，一定時間起動した後に停止する処理や，Haconiwaで起動されたコンテナを管理するプロセスがコンテナのリソース使用状態を監視して，状態によってHTTPベースのAPIにアクセスするといったような動的な処理をDSLで平易に記述できる．Haconiwaによって構築されたコンテナのリソース割り当てはcgroupを活用しており，コンテナのプロセスを停止させることなく，何らかの処理中であっても，CPUなどのリソース割り当てを即時変更することができる．

図2は，コンテナ環境を自動で作った上でプログラムを実行し，さらに，自動的にコンテナ環境自体を停止させる例である．このように書かれたHaconiwaの設定を実行すると，12行目のbootstrapAPIにより，gitでコンテナのイメージを取得後，17行目のprovisionAPIによりコンテナにRubyの環境を作り，4行目によりコンテナ起動と同時にコンテナ内部でRubyプログラムがsleepするだけの処理を実行する．その後，24行目のadd_async_hook APIの定義に従い，30秒後にコンテナを停止する．

FastContainerアーキテクチャを適用したシステムおよびツールは，多数のコンテナで構成されたシステムを自動で管理するためのコンテナオーケストレーションソフトウェアであり，Haconiwaは単一のコンテナを管理するツールと定義できる．

3.3.1　既存のコンテナ管理ツールとの比較

コンテナの状態を管理するソフトウェアとしては，Docker[18]やLXC[16]，rkt[17]などがある．Dockerはコンテナによる仮想環境の手軽な構築や周辺のエコシステムを重視しており，コンテナを構成するプロセスの隔離技術やリソース割り当て技術が機能として密結合になっている．一方でHaconiwaは，必要なコンポーネントを組み合わせて，chroot()システムコールによる最低限のファイルシステム隔離に加え，CPUやメモリのリソース割り当てのみを適用した環境，あるいは，コンテナの起動から生成までの流れの主要なフェーズで処理をフックできる機能などをDSLによって細かく記述することができる．そのため，構築したいコンテナ隔離環境に応じて，仮想環境の独立性と運用性，実行時の軽量さのバランスを検討しやすい設計になっている．

LXCはHaconiwaと同様にプラグインでカスタマイズ可能な作りになっているものの，コンテナの振る舞いを定義するためのフックフェーズが，コンテナ起動や停止時のみといったように限定的である．一方Haconiwaは，シグナルハンドラや起動後の非同期遅延処理，さらには定期実行のタイマー処理を定義して実行することも可能となっており，コンテナを活用したさまざまなシステムに適用しやすくなっている．また，HaconiwaはRuby DSLで記述することが可能であるため，Webサービス開発で広く使われているRubyの知識を有するエンジニアが，Webアプリケーションからその基盤のコンテナ環境をRubyの知識を使って表現することができる．

rktは多くの設定をサポートしているものの，Ruby DSLのように動的かつプログラマブルに記述することはできず，コマンドラインのオプション設定で実行する必要がある．

3.3.2　コンテナのオーケストレーションソフトウェアとの比較

代表的なコンテナのオーケストレーションソフトウェアとしてKubernetes[32]がある．Haconiwaは，通常のDockerやLXCによる単一あるいは複数の平易なコンテナ管理に加え，Ruby DSLを各コンテナの処理フェーズで記述可能で，任意の処理を実行可能であることから，独自で実装する場合に複雑になりがちなオーケストレーション層との連携を想定した作りとなっている．また，Haconiwa自体がオーケストレーションソフトウェアとしても遜色ない使い方が可能である．HaconiwaとKubernetesの機能を比較した場合，Kubernetesは設定を単一のyamlファイルで記述する必要がある．今後コンテナを活用した複雑なコンテナ設定，あるいは，kubernetesのようなオーケストレーション層との連携が求められることを想定すると，Haconiwaのようにコンテナの設定層およびオーケストレーション層との複雑な接続をDSLで統一的に記述でき，かつ，Rubyのような一般的に広く使われるプログラミング言語を利用できることにより，独自に定義された記述言語よりも自由度が高く，学習もしやすいと考えられる．

3.4　コンテナを利用したWebサービス基盤モデル

図3に，FastContainerアーキテクチャやその実装の立ち位置を明確化するために，コンテナを利用したWebサービス基盤モデルを定義し，示す．

図3の各層について説明する．サービス層は実際のWebアプリやWebサービスのコンテンツを含む層である．ストラテジー層は，Webサービスの特性に合わせてコンテナ基盤をより特徴的に制御する層であり，本研究のFastContainerはここに属する．

オーケストレーション層は，3.3.2項で言及したKubernetesを代表として，コンテナ群や収容ホスト群のモニタリングやリソース管理等によってCRI[20]と呼ばれるコンテナ管理ツール（コンテナランタイム）のインタフェース仕様を介してコンテナ全体を制御する層である．

コンテナランタイム層は，コンテナそのものの制御層であり，3.3節で言及したHaconiwaやDocker，LXC等を含む．コンテナランタイム層の中には，さらに2層に分類可能であり，CRIに基づいてオーケストレーション層からコンテナ構成情報を受け取ったり，コンテナイメージを管理するCRIランタイム^☆6の層，OCI[19]の仕様にしたがってコンテナの構成情報やイメージなどからコンテナのリソース割当や権限分離設定を行って実際にコンテナを起動させるOCIランタイム^☆7の層がある．

インフラストラクチャ層はハードウェアやVM，ベアメタル等のコンテナのリソースプールを実現する層である．

特に，オーケストレーション層の上のストラテジー層は，コンテナのオーケストレーションツール基盤の上に，さらにそれぞれのWebサービスの特性に合わせた戦略の層として位置するのではないかと考える．たとえば，本稿におけるホスティングサービスのスケーリングや運用効率化に基づいた戦略としてFastContainerアーキテクチャを提案し，その上の層に位置するWebアプリケーションのホスティング環境を改善していくことが目的である．そういう意味では，ホスティングサービスにより特化した基盤としてFastContainerはストラテジー層に位置し，オーケストレーション層に位置する各種ツールで実装可能であり，KubernetesやMesos Marathon[21]によって実現可能なアーキテクチャであることが望まれる．本研究では，FastContainerアーキテクチャをより最適にオーバーヘッドなく実現するために，3.1 節で述べた Haconiwa と各種連携ツールによって構成されるシステムの実装をNHHM Stack[33]として設計・開発し，命名した．

4．FastContainerアーキテクチャの実験と評価

4.1　スケーリング処理の評価

FastContainerアーキテクチャの有効性を確認するために，図4に示すFastContainerを用いたプロトタイプ環境を構築し，コンテナのスケーリング処理を評価した．表1に実環境と各種ロールの役割を示す．実験環境の各ロールのNICとOSはすべて，NICは1Gbps，OSはUbuntu14.04 Kernel4.4.0を利用した．

実験では，表1のロールのみを構築し，UserProxyからComputeで起動しているコンテナに対してベンチマークを行う．コンテナのデータはDataPool上に保存し，ComputeからDataPoolに対してNFSマウントする．コンテナ上には，Apache2.4.10を1プロセスで起動させた上でPHP5.6.30をインストールし，PHPの環境情報を取得するphpinfo()関数を実行するだけのコンテンツを動作させる．これによって，動的コンテンツに対応したWebサーバプロセスが動作しているコンテナを起動させながら，極力動的コンテンツの処理の影響を減らし，かつ，比較しやすい処理を実現する．

コンテナの最大CPU使用量は，cgroupの機能により1コアの30%に制限し，その設定のもと予備実験からCPUを30%使い切ることのできるベンチマークの設定を同時接続数100，総リクエスト数を10万に決定した．ベンチマークにはApache httpdに同封されるabコマンドを利用した．本実験では，コンテナ追加のためのCoreAPIへのリクエストは手動で実施した．CRIUによるイメージ化については，後述の実験で評価するために，本実験では行わない．

ベンチマークでは，1秒間のレスポンスタイムの平均値を時系列データとして作成しグラフ化した．続いて，同様のベンチマークを実施し，処理リクエスト数が5万を超えた段階で，コンテナ数を増やすスケールアウト型とコンテナへの割当リソースを増加させるスケールアップ型それぞれの負荷対応を実施し，即時スケール処理が実施され，レスポンスタイムが短くなるかどうかを確認した．図5にスケールアウト型，図6にスケールアップ型の実験結果を示す．

図5の1 containerで示されるグラフは1コンテナに対するベンチマークの結果を示している．ベンチマークの間は，制限された最大CPU使用率30%を常に使い切っている状態となっており，その状態でおおむねグラフのとおりレスポンスタイムは700msec前後程度になっている．また，これ以上同時接続数を増やすと，リクエストの処理に失敗する数が増えるため，この値が1コンテナがリクエストの処理に失敗することなく処理できる最大のレスポンスタイムであることを予備実験で確認した．

次に，横軸340秒あたりから下降する1to2 container from 50000reqで示されるグラフは，5万リクエストに到達した横軸で335秒の時点でオートスケールアウトを行った場合の結果である．グラフからも，コンテナが数秒で立ち上がることの高速性と，オートスケールアウトの処理がリクエストに対してリアクティブに起動することにより，迅速にスケールアウトし，リクエストを取りこぼすことなくレスポンスタイムが半分程度に短くなり，高速に処理できていることが分かる．具体的な数値としては，335秒時点でオートスケールアウトを発生させ，そこから339秒まではスケーリング処理が行われているため700msecのレスポンスタイムのままであり，340秒にはスケーリングが完了して，同時に秒間のレスポンスタイムは300msec前後程度となった．また，レスポンスタイムが短くなったことにより，1コンテナの場合は10万リクエストを処理するのに720秒程度かかっていたが，グラフのように470秒程度で10万リクエストの処理が完了していることが分かる．

図6の1 container CPU30%は，図5の1 containerと同様に，スケール処理を何もしない場合のグラフである．横軸300秒あたりから下降し始めている1 container CPU30%to60% from 50000reqのグラフは，5万リクエストに到達した横軸301秒の時点で，コンテナ管理ソフトウェアのHaconiwaによって即時CPUの最大使用率を60%までに引き上げた場合のレスポンスタイムの遷移を示している．

図6からも，リクエスト処理が5万リクエストまで到達した横軸301秒の時点から，大きなレスポンスタイムの遅延やレスポンス処理の失敗などなく，即時スケールアップ処理が行えていることが分かる．具体的な数値としては，301秒時点でオートスケールアップを発生させ，302秒からレスポンスタイムが700msecから574msecと下降が始まり，304秒の時点で358msecとなり，以降は350msec前後に安定した．オートスケールアウトよりも，オートスケールアップが即時レスポンスタイムへの影響があった理由としては，新たなコンテナを起動させてリクエストの振り分けに追加するスケールアウトに対して，直接稼働中のコンテナのリソースを増強できるからだと考えられる．

本節の実験はCRIUによるイメージ化を行っていない．これらのスケーリング処理において，スケールアウト型の5秒間のタイムラグはコンテナ環境そのものの起動時間ではなく，Apache httpdなどのコンテナ上で起動するサーバプロセスの起動時間が支配的であることが分かっている[30],[35]．すなわち，サーバプロセスの起動完了直前のイメージから起動することによりさらに短縮することが見込まれる．

4.2　CRIUによるイメージからの起動速度評価

本実験では，CRIUを利用してあらかじめ起動処理完了状態のプロセスをイメージ化しておき，レスポンスに応じてイメージから起動した場合のレスポンスタイムを測定した．表2に実験環境と各種ロールの役割を示す．4.1節の実験と同様に，図4に示すFastContainerを用いたプロトタイプ環境を構築した．実験環境の各ロールのNICとOSはすべて，NICは1Gbps，OSはUbuntu16.04，カーネルは4.4.0-59-genericを利用した．コンテナのデータはDataPool上に保存し，ComputeからDataPoolに対してNFSv3でマウントした．

Webアプリケーションサーバとして，起動に時間のかかるRuby on Railsのデフォルトページを実験に利用した．Ruby on Railsのバージョンは5.1.3で，Rubyのバージョンは2.5.1である．コンテナには，ComputeサーバのCPUコアを1コア割り当て，メモリは1GBytesを割り当てた．比較のために，CRIUを使った場合と使わない場合のコンテナを用意した．実験では，コンテナ上で起動しているRuby on Railsに対して，abコマンドを利用して同時接続数1でベンチマークを行い，ベンチマークが40秒程度経過した段階で，コンテナを停止させた．FastContainerアーキテクチャであるため，コンテナが停止しても，次のリクエストを受信した段階でリアクティブに起動する．その際に，イメージから起動する場合とそうでない場合でレスポンスタイムにどの程度違いがあるかを比較した．

図7にCRIUを使わない場合のRailsコンテナのレスポンスタイム，図8にCRIUを使った場合のレスポンスタイムを示す．

Ruby on Railsのデフォルトページは，デフォルトページでもRubyの拡張ライブラリであるgemを67個ロードし，プロセスのRSS（the real memory resident set size of the process）は75MBytes程度利用する．図7のように，このようなコンテナおよびWebアプリケーションの場合は，CRIUを使わない場合は起動だけに2900msecの時間を必要とする．一方で，CRIUを利用した場合は，図8のように，1200msecで起動し，レスポンスを返すことができている．

CRIUを使うことでWebアプリケーションの起動時間が遅いサーバであっても，あらかじめ起動処理を完了させたプロセスイメージから起動させることで速く起動させることができる．また，CRIUによるプロセスイメージからの起動時間は，プロセスのRSSのサイズによって時間が決定されることが報告されており，本実験環境と同様の環境で，メモリ上にシーケンシャルに展開されたプロセスのRSSが100MBytes前後で150msecで起動できる[40]．すなわち，1200msecのうち150msecはCRIUによる起動時間となるため，1050msecはアプリケーションのレスポンスタイムに加えて，システムのプロキシやデータベースなどを経由する処理，コンテナの起動時間，コンテナの状態チェックなどの時間の合計となる．レスポンスタイムを除くシステムの処理時間については，さらにシステムの実装を見直す必要がある．

以上の結果から，FastContainerの状態遷移にCRIUを使うことによって，Webアプリケーションサーバの起動時間に依存せず，リクエストに応じてリアクティブにレスポンスを返すことができる．このことから，オートスケーリングにおいても，高速にコンテナを複製することが可能である．

5．FastContainerのまとめと今後の展望

本研究では，Webホスティングサービスにおいて，サービス利用者に専門的な知識を要求することなく，アクセス集中時には，HTTPリクエスト単位でリアクティブにコンテナで構成されたユーザ環境が状態を変更できる，システムアーキテクチャのFastContainerを提案した．FastContainerアーキテクチャでは，HTTPリクエストごとに，コンテナ上のWebアプリケーションの起動，起動継続時間，起動数およびリソース割り当てをリアクティブに決定する．Webアプリケーションの起動に時間がかかるプロセスであっても，CRIUによるプロセスイメージのリストアを応用することで，オートスケールまでの処理を大幅に短縮し，リアクティブにオートスケールが可能となる．また，コンテナが一定期間で破棄されることによりリソース効率を高め，ライブラリが更新された場合には新しい状態へ更新される頻度も高くなる．アクセス数が低下したり必要なくなったコンテナは，起動計測期間終了後速やかに停止することから，システム全体の不必要なリソース専有も低減できる．

一方で，CRIUによるイメージのリストア時間は，プロセスのメモリサイズやプロセス数，スレッド数などに依存することが予備実験から分かってきている．今後は，それらの観点から，CRIUによるイメージのリストア活用と，Webアプリケーションプロセスの起動処理時間の相関関係を考察する必要がある．

今後の展望としては，さらにFastContainerアーキテクチャのシステム設計と実装，および改修を進めていき，実サービス環境における評価を継続的に行っていく．さらに，アクセスの変化に応じてコンテナの状態をリアクティブに決定できることから，コンテナのリソース割当や起動数を機械学習によって最適化したり，アクセスが集中することが予測できる場合は投機的にコンテナを起動させる，といったような，機械学習や統計的手法との連携も引き続き注目していきたい．

現在注目されているサーバレスアーキテクチャ[22]やそのオーケストレーション機能のスタンダート実装であるkubernetesとの関係性も考慮していく必要がある．その際，コンテナ時代のWebサービス基盤をモデル化した時に，Haconiwaの実装においても，世界中で活発に開発されているコンテナ技術と協調するために，前述したCRIやOpen Container Initiative（OCI）[19]に準拠した仕様にすべきであるし，KubernetesのCRIAPIやOCIにHaconiwaを対応させる必要もある．

FastContainerアーキテクチャやHaconiwaのような新しいソフトウェアを自社や個人で開発していく中で，コンテナ関連ソフトウェアの立ち位置と比較対象を明確化し，各層の連携をより汎用化していくためにも，その他のツールとの連携や技術的背景を考慮しつつ，ツール開発者と議論しながら研究開発を続けていく予定である．