第四回Web System Architecture研究会@京都で発表してきましたので、その予稿とスライドを公開します。
収容ホストにいかに効率的かつ高速にコンテナをリアクティブにスケジューリングするかについて、今回はWordPress on mod_phpやRails、Djangoなどで実験をしてみたので、それの方向となります。
スライドは以下の通りです。
※ 本エントリは下記の研究に基づいて執筆しています.
- 松本亮介, 近藤宇智朗, CRIUを利用したHTTPリクエスト単位でコンテナを再配置できる低コストで高速なスケジューリング手法, 情報処理学会研究報告インターネットと運用技術(IOT), No.2019-IOT-44, Vol.21, pp.1-8, 2018年3月.
概要
スマートフォンやPCのモバイル化,SNSの爆発的普及に伴い,個人のWebサイトであってもコンテンツ次第でアクセスが集中する機会が増大してきている.
我々は,サービス利用者に専門的な知識を要求せず,アクセス数や負荷に応じて反応的かつ高速にリソースをコンテナ再割当てすることで,サービス利用者や事業者に手間を強いることなく突発的なアクセス集中に耐えうるFastContainerアーキテクチャを提案した. 一方で,従来のホスティングサービスやクラウドサービスと同様に,コンテナの収容サーバ障害時に,HTTPタイムアウトが生じない程度での可用性を担保しサービスを継続提供するためには,複数収容サーバに横断して,それぞれ複数コンテナを立ち上げておく必要があった. そのため,利用者にとってはサービス利用コストの増加に繋がっていた.
本研究では,HTTPリクエスト処理時において,単一のコンテナであっても,収容サーバの状態に応じて自動的にコンテナを別の収容サーバに再配置しWebサービスを継続させる,HTTPリクエスト単位での低コストで高速なコンテナのスケジューリング手法を提案する. リソースコストを低減し,複数の収容サーバにコンテナを立ち上げておくことなく,高速にインスタンスを再配置するために,Webサーバソフトウェアが起動完了する直後にフックする処理を入れることでプロセスをイメージ化しておき,コンテナ再配置時にはコンテナ上のWebサーバプロセスをイメージから高速に起動させる.
1. はじめに
インターネットを活用した企業や個人の働き方の多様化に伴い,インターネット上で自らを表現する機会が増加している. 特に個人にとっては,TwitterやFacebookを活用して,自身が作成したコンテンツを拡散させることにより,効率よくコンテンツへの訪問数を増やすことができるようになった. その結果,コンテンツの内容の品質が高ければ,さらに拡散され,コンテンツに紐づく個人のブランド化も可能になってきている. そのため,コンテンツ拡散時であっても継続的に配信可能なWebサイトの構築は,個人用途であっても非常に重要になってきている.
Webコンテンツを継続的に配信するためには,オートスケーリングのような負荷対策と,冗長構成による可用性の担保が重要である. 一般的に,個人がWebコンテンツを配信するためには,Webホスティングサービスやクラウドサービスなどが利用される*1. 特に,個人の利用を想定した場合,単一の物理サーバに高集積にユーザ領域を収容するような低価格Webホスティングサービスが利用される. そのような低価格ホスティングサービスでは,利用者のWebコンテンツが特定のWebサーバに紐づくため,ユーザ領域単位で突発的なアクセス集中に対して負荷分散することが難しい. クラウドサービスの場合は,利用者がアクセス集中に耐えうるオートスケーリング*2の仕組みを作る必要があった り,各サービス・プロバイダが提供しているオートスケーリングの機能*3を使う必要がある. しかし,クラウドサービスに関する専門的な知識を有さない個人が,費用を最低限に抑えつつ,突発的なアクセス集中を予測的かつ安定的に対応することは依然として困難である.
可用性の面では,Webホスティングサービスの方式もクラウドサービスも,仮想的に構築されたサーバ環境であるインスタンスを複数のハードウェア上に起動させることにより,特定のハードウェアに障害が置きてもサービスを停止せずに提供可能である*4. しかし,複数台のインスタンスが必要であることから,インスタンスの利用コストが増加する. さらに,可用性のためのインスタンスをコストの兼ね合いから負荷分散用途に転用してしまうことにより,収容サーバが停止した際に縮退状態のインスタンス数でサービスを提供することになり,場合によってはリソース不足に陥る.
我々はアクセス数や負荷に応じて反応的かつ高速にリソースをインスタンス*5再割当てすることで,サービス利用者や事業者に手間を強いることなく突発的なアクセス集中に耐えうるFastContainerアーキテクチャ*6を提案した.
一方,可用性の面では,依然として単一のインスタンスの場合,そのインスタンスが収容されている物理サーバが正常に稼働していることが前提であり,収容サーバが停止すると,手動によるインスタンスの再配置が必要であった. そのため,障害時にHTTPタイムアウトを生じさせない程度の可用性を担保するには,上図のように従来手法と同様にインスタンスを複数の収容サーバに起動できるようにしておく必要があり,利用者にとっては利用コストの増加に繋がっていた. また,新たなインスタンスを新規で再配置する場合は,インスタンス起動時のWebサーバプロセスの起動時間がオーバーヘッドとなってレスポンスが一時的に遅くなり,ユーザ体験を損なう課題があった*7.
プロセスの起動時間を高速化するために,CRIU*8と呼ばれるLinuxプロセスのCheckpoint/Restore技術によってプロセスをイメージ化することにより,高速にプロセスの状態を復帰させる手法がある. しかし,Webサーバが起動してからリクエストを処理している状態のプロセスをイメージ化すると,起動後のサーバプロセスの状態やコンテンツの状態等を保持してしまうため,実用上扱いにくい.
本研究では,HTTPリクエスト処理時において,単一のインスタンスであっても,収容サーバの状態に応じて,自動的にインスタンスを別の収容サーバに再配置し,サービスを継続させる,HTTPリクエスト単位でのインスタンスのスケジューリング手法を提案する.
提案手法により,上図のように単一のインスタンスであっても,収容サーバに障害が起きたときに,自動的に別の収容サーバに再配置されることで可用性を担保できる. 提案手法では,FastContainerの状態変化の高速性に基づいて,インスタンスが頻繁に収容サーバを変更されてもサービスに影響がないことを利用する. それによって,プロキシサーバから収容サーバに1個のICMPあるいはTCPパケットで応答速度を計測し,少ないパケット数と短いタイムアウトで収容サーバの反応時間を計測できる. そのことで,HTTPリクエスト単位でのインスタンススケジューリングを実現する. さらに,高速にインスタンスを再配置するために,Webサーバソフトウェア自体を拡張することなくWebサーバプロセス起動完了直後にフックする処理を入れることでプロセスイメージを作成しておくことにより,高速にWebサーバプロセスをそのイメージから起動させる.
本稿の構成を述べる. 2章では,Webホスティングサービスやクラウドサービスにおける可用性の担保のための取り組みとその課題について述べる. 3章では,2章で述べたインスタンスの再配置の課題を解決するための提案手法のアーキテクチャおよび実装を述べる. 4章では,HTTPリクエスト単位でのインスタンススケジューリング手法の評価を行い,5章でまとめとする.
2. Webサービス基盤の可用性
Webサイトが収容されている物理サーバに障害があった場合に,いかにサービスを継続するかといった可用性の観点でシステムを構築する必要がある. 本章では,相互に関連の深い負荷分散と可用性の観点から,Webホスティングサービスやクラウドサービスにおける関連研究と課題について整理する.
本論文における可用性とは,インスタンスの収容サーバが停止しても,クライアントからインスタンスに対するリクエストがHTTPタイムアウトせずに,オンラインでサービス継続を可能とする程度を前提とする.
2.1 Webホスティングサービス
Webホスティングサービスとは,複数のホストで物理サーバのリソースを共有し,それぞれの管理者のドメインに対してHTTPサーバ機能を提供するサービスである. Webホスティングサービスにおいて,ドメイン名(FQDN)によって識別され,対応するコンテンツを配信する機能をホストと呼ぶ.
一般的に,個人がWebコンテンツを配信するためには,Webホスティングサービスやクラウドサービスなどが利用される. 特に,個人の利用を想定した場合,仮想ホスト方式を利用して,単一の物理サーバに高集積にユーザ領域を収容するような低価格Webホスティングサービスが利用される*9. 仮想ホスト方式では複数のホストをApache httpdのような単一のサーバプロセス群で処理するため,リクエストはWebサーバプロセスを共有して処理される. そのため,ホスト単位で使用するリソースを適切に制御したり,その原因を迅速に調査することが困難である*10.
Webホスティングサービスでは,サービス利用者のWebコンテンツは特定のWebサーバに収容され,WebサーバとWebコンテンツが紐づくため,負荷に応じたオートスケーリング*11は,データの整合性の面と前述したホスト単位での適切な負荷計測・制御の面から困難である.
Webホスティングサービスにおける負荷分散と可用性を両立する手法として,ユーザデータ領域を共有ストレージにまとめた上で,仮想ホスト方式を採用した複数台のWebサーバで負荷分散と可用性を担保する手法*12がある. しかし,ホストの収容サーバを複数台配置して全ホストを複数の物理サーバに配置することが前提となる手法であるため,ホスト単位でのスケーリングや可用性の担保は対応できず,コストも高くなる. また,負荷に応じて,ホスト単位での即時性の高いスケールアップ型の負荷対応もできない.
2.2 クラウドサービス
クラウドコンピューティング*13とは,ネットワークやサーバといったコンピュータリソースのプールから必要な 時に必要な量だけオンデマンドに利用可能とするコンピューティングモデルである. クラウドサービスはクラウドコンピューティングを各種サービスとして提供するサービスである.
クラウドサービスでは,Webコンテンツを配置するだけでなく,Webサーバソフトウェアやデータベースをサービス利用者が自ら構築する必要がある. そのため,負荷分散のためのシステム設計をホスト単位で個別に行うことができる点において自由度は高いが,前提として専門的な知識が必要となる.
クラウドサービスで可用性を担保するためには,複数のインスタンスを複数の収容サーバにホットスタンバイ状態で起動させておき,特定の収容サーバに障害が発生した場合には,ホットスタンバイ状態のインスタンスにリクエストが送信されるように変更する. これによって,障害対応時に,新規でインスタンスを立ち上げ直す処理を省略し,継続的にサービスを提供し続けることが可能となる. しかし,複数台のインスタンスが必要であることに起因して,必要なハードウェアコストが増加する. また,そのようなハードウェアコストを限られた予算の中で活用するために,ホットスタンバイ状態のインスタンスを負荷分散に利用することもある. しかし,収容サーバが停止すると縮退状態のインスタンスでサービス提供することになり,場合によってはリソース不足に陥る.
高負荷状態に対して迅速に対応するために,事前にある程度想定される量の仮想マシンを予測的に起動させておくことによって対処する手法がある*14. しかし,本手法は突発的なアクセスに対するスケーリングを対象としておらず,予測の精度を保つための各種パラメータの選定に関する課題もある. また,可用性を担保することは想定されていない.
上記のような問題を解決するために,クラウドサービスプロバイダのAWSは,プロバイダ指定の記法によってアプリケーションを 実装すれば,自動的にコンピュータリソースを決定し,可用性を担保しながらも高負荷時には自動的にプロバイダ側でオートスケーリングする機能*15を提供している. しかし,前提としてプログラミングができるエンジニアを対象としており,一般的なOSSとして公開されているWebアプリケーションを利用できないことが多く,個人がWebコンテンツを配信する用途においては使用上の制限が大きい.
2.3 FastContainerアーキテクチャ
松本らは,個人がWebコンテンツを配信する用途において,Webホスティングサービスやクラウドサービスにおける突発的にアクセス集中の対応やオートスケーリングの課題を解決するために,FastContainerアーキテクチャを提案している*16. FastContainerは,Webホスティングサービスを利用できる程度の知識を持った個人が,WordPressのような一般的なCMSを利用したWebコンテンツを配信することを前提にしている. そのような個人のサービス利用者が負荷分散のシステム構築やライブラリの運用・管理を極力必要とせず,HTTPリクエスト単位でインスタンスの状態を決定し,迅速にユーザ領域を複数の物理サーバに展開可能で,実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャである.
FastContainerアーキテクチャでは,インスタンスとして,仮想マシンではなくLinuxコンテナ*17を利用する. Linuxコンテナはカーネルを共有しながらプロセスレベルで仮想的にOS環境を隔離する仮想化技術のひとつである. そのため,コンテナの起動処理は仮想マシンのようなカーネルを含む起動処理と比べて,新しくプロセスを起動させる程度の処理で起動が可能であるため,起動時間が短時間で済むという特徴がある.
FastContainerアーキテクチャでは,コンテナが仮想マシンと比較して速く起動できる点と,FastCGI*18を参考に,物理サーバへの収容効率を高めつつ性能を担保するアーキテクチャを組み合わせる. さらに,HTTPリクエスト毎に負荷状態やアクセス数に応じて,Webアプリケーションコンテナの起動処理,起動継続時間,コンテ ナの起動数およびリソース割り当てをリアクティブに決定する. 一定時間起動することにより,一度コンテナが起動してしまえば,起動時間に影響なくレスポンスを送信できる. この特性によって,ホストをコンテナ単位で個別に起動しながらも,リクエストの無いコンテナは自然に停止するため,高集積に収容できる.
FastContainerは,コンテナの起動が一般的に高速であること,リクエストを契機としたリアクティブな起動処理であることにより,突発的な負荷に対しても迅速にリクエスト単位でオートスケーリングが可能となる. スケールアップについても,コンテナのリソース管理がcgroupによってプロセス単位で制御されており,cgroupの特徴を利用して,プロセスが処理中であってもCPU使用時間などの割り当てを即時変更できる.
しかし,このアーキテクチャはコンテナが収容される物理サーバが適切に稼働していることが前提であり,収容サーバが停止すると,手動によるコンテナ再配置が必要であった. そのため,ホスティングサービスやクラウドサービスと同様に,収容サーバが停止した際にサービスを停止させることなく継続的にレスポンスを返すためには,複数の収容サーバにそれぞれ複数インスタンスを配置する必要があり,利用者にとってのサービス利用コストが増加する. また,単一のコンテナで起動している場合は,その収容サーバが停止すると,手動で再配置が行われるまでには同様にサービスも停止してしまう.
3. 提案手法
個人の利用者がWordPressのような一般的なWebコンテンツを配信する仮想化基盤において,収容効率を高めつつ,アクセス集中による負荷やインスタンスの収容サーバの障害に対する可用性を担保可能な基盤にするためには,以下の要件が必要である.
- インスタンスでWordPressのような一般的なWebアプリケーションが動作する
- 単一のインスタンスであっても収容サーバ障害時には別サーバへ自動的に再配置される
- インスタンスの再配置の実行時であっても数秒の遅延でHTTPタイムアウトすることなくオンラインでレスポンスを返せる
本研究では,上述した3つの要件を満たすためにFastContainerを応用して,HTTPリクエスト単位でコンテナを再配置する仮想化基盤の高速なスケジューリング手法を提案する. 提案手法は,HTTPリクエスト処理時において,収容サーバ,および,その経路までの状態に応じて,自動的にコンテナを収容する物理サーバを決定し,サービスを継続させる. FastContainerの状態変化の高速性に基づいて,コンテナが誤検知によって再配置されてもサービスが停止しないことを利用する . それによって,プロキシサーバから収容サーバにICMPあるいはSO_LINGERオプションを用いたTCPで接続を試みた上で,短いタイ ムアウトで収容サーバの反応時間を計測できる. 実装には,mruby-fast-remote-check*19を採用した. そのことで,HTTPリクエスト単位でのコンテナスケジューリングを実現する.
さらに,コンテナ再配置後の最初のリクエストに対する起動時間を速くするために,予めインスタンスの起動処理完了直後のプロセスをイメージ化(Checkpoint)しておく. 起動時は,そのイメージから起動する(Restore)ことにより,通常起動よりも高速化を実現する.
3.1 スケジューリングフロー
上図に,コンテナスケジューリングのフローを示す. このフローでは簡単のため,ホストの監視にICMPを使う.
Host OSが障害を起こしていない正常時のフローについて述べる. この図におけるClientからContainerに対してHTTPリクエストがあった場合,ClientからWeb Proxyに一旦集約される. Web Proxyにリクエストが到達した段階で,Containerの収容情報や構成管理情報を保持するCMDB APIに情報を問い合せ,Containerの収容サーバやIPアドレス/ポート情報を得る. Web Proxyは収容サーバであるHost OS上に存在するContainerにリクエストを転送する前に,そのHost OSが稼働しているかをICMPパケットによって確認する. Web ProxyはICMPの疎通を確認した後に,いったんHost OS上に稼働しているContainer Dispatcherにリクエストを転送する. Container Dispatcherはコンテナが稼働していればそのままHTTPリクエストを転送し,稼働していなければ,再度CMDB API情報に基いてコンテナを起動させてからリクエストを転送する.
次に,コンテナが収容されているHost OSが突発的な障害で停止した場合のフローについて述べる. ClientからCMDB APIを介してWeb Proxyに到達し,転送先の収容サーバにICMPのチェックを行う. その際に,収容サーバがダウンしている場合は,ICMPのチェックタイムアウトを経て,Web Proxyが収容サーバのダウンを認識す る. その後,Web Proxyは再度CMDB APIに接続を行い,コンテナの収容情報を他に起動しているHost OSの情報に基いて再生成する. その収容情報に基いて,再度起動中のHost OSにICMPチェックを行い,起動していることを確認した上で,Host OS上で動作しているContainer Dispatcherにリクエストを転送する. この場合,収容サーバにはコンテナが起動していないため,Container Dispatcherによって該当コンテナを起動し,HTTPリクエストを転送する.
提案手法では,要件(1)について,本手法はFastContainerアーキテクチャに基いており,複数のHost OS間で共有ストレージによ りデータを共有しているため,コンテナ上にWordPressのようなWebアプリケーションが動作可能であり,かつ,別のHost OS上で も同様に動作可能である. さらに,要件(2)について,上記のスケジューリングフローによって,収容サーバがダウンしてもクライアントからのHTTPリクエ スト処理の過程で再配置が行われる. 要件(3)を満たすためには,(1)で述べた通り,共有ストレージによってデータをHost OS間で共有しているため,データのコピー は発生しないことから,ICMPやTCPのタイムアウトの時間と,コンテナの収容サーバ変更後のコンテナ再配置にかかる時間の合計 値をできるたけ短くすれば良い.
ICMPやTCPのタイムアウト時間を短くするためには,Web ProxyとHost OS間の通常のICMPやTCPに必要とする時間にタイムアウト値をなるべく近くすることが必要となる. 同時に,一時的な遅延によって,障害と至らないにも関わらずタイムアウトした場合に再配置が発生したとしても,サービス継続への影響を最小化できれば良い. FastContainerのプロトタイプ実装と実験環境では,単一のコンテナを複数のコンテナにスケールアウトする場合に,レスポンス タイムが短縮されるまでにかかる時間が実験から数秒程度とわかっている. スケールアウト型のスケーリングは,コンテナを追加で起動させる処理であり,コンテナの再配置の起動にかかる処理と同一の処理と言える. そのため,再配置に必要となる時間が論文の環境では数秒程度で完了することが見込める.
3.2 コンテナ環境の起動高速化
再配置時のコンテナの起動時間をさらに短縮するために,コンテナ上で起動するサーバプロセスの起動時間を高速化する. そのために,CRIUを使ってプロセスの起動処理完了直前の状態でプロセスのCheckpointを行い,プロセスをイメージ化する. その場合,複数のWebサーバソフトウェアに対して,個々にCIRUを組み込むことにより対応していくことは,多数のサーバソフト ウェアの拡張が必要となり実装面で非効率である.
任意のGUIアプリケーションに対して,初期化時に実行されるシステムコールを監視しながら,初期化完了直前にプロセスをイメ ージ化する研究がされている*20. しかし,任意のシステムコール実行前に自動で停止するといったことができておらず,手動で感覚的に初期化完了時を予想してイメージ化する方が速いといった実験結果になっている.
そこで,個々のWebサーバソフトウェアに機能拡張を実装することなく,汎用的かつ自動でプロセスのCheckpoint/Restoreを実現 するために,Haconiwa*21を利用する. Haconiwaは近藤らが開発しているコンテナランタイムであり,コンテナ上で起動するプロセスの完了直後をフックして任意の処理を実行することができる. その機能を利用して,Haconiwaでコンテナ上にプロセスを起動させ,起動完了直後にHaconiwaプロセスから起動処理中のサーバプロセスをイメージ化する.
定期的にプロセスイメージの作成を行い,FastContainerアーキテクチャに従って,コンテナ停止時のリクエストやコンテナの再 配置が実行されるタイミングで,作成済みのプロセスイメージからRestore処理によりプロセスの起動を行う. それによって,起動時間の高速化を実現する.
4. 実験
本手法の有効性を確認するために,上図に示すFastContainerを用いた実験環境を構築し,コンテナのスケジューリング処理を評価した. 上表に実験環境と各種ロールの役割を示す. 実験環境の各ロールのNICとOSは全て,NICは1Gbps,OSはUbuntu16.04,カーネルは4.4.0-59-genericを利用した. 本実験では,Comupteノードを2台利用して,ノードの障害をエミュレートした. コンテナのデータはDataPool上に保存し,ComputeからDataPoolに対してNFSv3でマウントした.
本実験の前に,プロセスのメモリサイズによってCRIUのCheckpoint/Restoreがどの程度処理時間を要するか計測した. mruby-simplehttpserver*22でWebサーバを起動させsetsockopt()を監視し,setsockopt()実行前にCheckpointする. setsockopt()実行前にメモリを確保して、メモリサイズに応じてCheckpoint/Restoreの速度の変化を計測した.
上図はプロセスのメモリサイズによるCRIUの処理時間の変化を示している. メモリサイズが100MB相当でも,350 ms程度でCheckpoint可能であり,Restoreについては概ね 12 MB から 102 MB までは,150 ms で処理可能であることがわかった.
本実験では,Checkpoint/Restoreによるサーバプロセスの起動の高速化手法を組み込んだ場合と組み込まない場合とで,Wordpress,Ruby on Rails,Djangoそれぞれのレスポンスタイムを計測した. Wordpressは,WebサーバにはApache 2.4.18,PHP 7.3.0,Wordpress 5.0.3を利用した. PHPはOpcache機能を有効にした. また,CRIUによるイメージ化時のApacheのプロセス数は3,スレッド数3,単一のプロセスのメモリサイズ(RSS)は35MBytesであっ た.
Ruby on Railsは,Ruby 2.5.1,Rails 5.2.1,Puma 3.12.0を利用し,起動するアプリケーションは現実的な規模(個人/グループ内での利用のアプリケーション程度)でDBを利用したものを採用した*23. Ruby on Railsは,gemを事前コンパイルしておくことにより起動を高速化させるbootsnapという機能があるため,CRIUを使わない場合は,bootsnapを使った場合と使わない場合も計測した. また,CRIUによるイメージ化時のRailsのプロセス数は2,スレッド数は14,単一のプロセスのメモリサイズ(RSS)は89MBytesであ った.
Djangoは,Python 3.7.1,Django 2.1.4,gunicorn 19.9.0を利用し,Railsと同様に,現実的な規模でDBを利用したWebアプリケ ーションを採用した*24. また,CRIUによるイメージ化時のDjangoのプロセス数は2,スレッド数は2,単一のプロセスのメモリサイズ(RSS)は33MBytesであ った.
全てのWebアプリケーションはHaconiwa 0.10.0で作成したコンテナ上で起動した. データベースはUserDB上のMySQL 5.7.24を利用した. コンテナの割り当てメモリは1024MBであり,CPUは1コアを割り当てた. コンテナに対するベンチマークでは,abコマンドで,同時接続数1,総接続数3000で計測を行い,数十秒たった時点で手動でネッ トワークを切断し,収容ホストの再配置を発生させた. コンテナの収容サーバに対するTCP監視にはmruby-fast-remote-checkを利用してSO_LINGERオプション付きのTCPパケットを送信 し,タイムアウトは100msとした.
ベンチマーク測定中に,一定時間経過後にCompute上でipatablesコマンドによりUserProxyからのパケットをdropし,別のComputeにコンテナが再配置されるようにした. 今回採用したコンテナランタイムのHaconiwa 0.10.0のCheckpoint/Restore機能*25を利用して,各Webアプリケーションをイメージ化しておく. 各Webアプリケーションの起動が完了し、コンテナ内部のポートをリッスンした状態でイメージ化している。 したがって、通常起動時はワーカーが全て起動し切っていなくともレスポンスを返すため、CRIUからの起動では若干の条件の違いがある。
ベンチマークでは,秒間のレスポンスタイムの平均値を計算し,時系列データとしてベンチマークが完了するまでのレスポンスタイムの変化を計測した.
図3に,WordPressに対するベンチマーク結果を示す. WordPressは,実験環境においては平均的に70ms前後のレスポンスタイムであった. 45秒の時点で再配置の処理が動作した際には,3037msのレスポンスタイムを要した. TCPのタイムアウト値が100msであることから,コンテナの再配置からApacheの起動とレスポンス生成までには概ね2937msで実現できている. そのことから,コンテナの再配置とコンテナ起動に要する時間は,WordPressのレスポンスタイム70msを除くと,2867msとなる.
一方,CRIUのイメージ化を使った場合のWordpressに対するベンチマークは,ベンチマークが55秒経過したときに,手動でネット ワークを切断した. WordPressは,CRIUを使わない場合の実験と同様に,平均的に70ms前後のレスポンスタイムであった. 55秒の時点で再配置の処理が動作した際には,2163msの処理時間を要した. TCPのタイムアウト値が100msであることから,コンテナの再配置からApacheの起動とレスポンス生成までには概ね2063msで実現できている. そのことから,コンテナの再配置とコンテナ起動に要する時間は,WordPressのレスポンスタイム70msを除くと,1993msとなる. これらの結果から,CRIUを使ったイメージ化を組み合わせることにより,874ms高速に起動できた. 高速に起動できることから,収容サーバ障害時にも,874ms速くレスポンスを返すことができる.
図4に,Ruby on Railsに対するベンチマーク結果を示す. Ruby on Railsは,実験環境においては平均的に20ms前後のレスポンスタイムであった. CRIUもbootsnapも使わない場合は,38秒の時点で再配置の処理が発生した際に,8575msのレスポンスタイムを要した. TCPのタイムアウト値が100msであることから,コンテナの再配置からRailsの起動とレスポンス生成までには概ね8475msで実現で きている. そのことから,コンテナの再配置とコンテナ起動に要する時間は,Railsのレスポンスタイム70msを除くと,8455msとなる.
一方,CRIUのイメージ化を使った場合は,35秒の時点で再配置の処理が動作した際には,1544msの処理時間であった. TCPのタイムアウト値が100msであることから,コンテナの再配置からRailsの起動とレスポンス生成までには概ね1444msで実現で きている. そのことから,コンテナの再配置とコンテナ起動に要する時間は,レスポンスタイム20msを除くと,1424msとなる. これらの結果から,CRIUを使ったイメージ化を組み合わせることにより,7011ms高速に起動できた. 同様に,bootsnapと比較した場合は,同様の計算式から,2734ms高速に起動できた.
図5に,Djangoに対するベンチマーク結果を示す. Djangoは,実験環境においては平均的に15ms前後のレスポンスタイムであった. 42秒の時点で再配置の処理が動作した際に,6030msのレスポンスタイムを要した. WordpressやRailsのレスポンスタイムと同様の計算式から,コンテナの再配置とコンテナ,および,Webアプリケーション起動に 要する時間は,5915msとなる. 同様に,CRIUを使った場合は,コンテナの再配置実行時に2249msのレスポンスタイムになっている. つまり,CRIUを使ったイメージ化を組み合わせることにより,3781ms高速に再配置とレスポンス送信が可能になる.
UserProxyからComputeにリクエスト転送が送信されて,Compute上のコンテナからUserProxyにレスポンスデータが送信される前の状態でComputeが停止してしまった場合は,そのレスポンスをUserProxyが正しく受信できないため,レスポンスを一部取りこぼすこともありえる. しかし,これは従来方式において複数のホストOSにそれぞれ分散してインスタンスを配置して可用性を担保する方式でも原理的に生じるため,本手法の特徴的な問題ではない.
本実験結果から,単一のコンテナインスタンスを単一の収容サーバに起動させておきながらも,その収容サーバの停止時には,プロセスのイメージ化を組み合わせることにより,迅速に再配置のスケジューリングが行えていることがわかった. また,実験環境程度のハードウェアスペックで,2秒程度であれば,実用上はHTTPタイムアウトすることなくレスポンスを返せる と見込める. Ruby on RailsやDjangoのように,起動してしまえばレスポンスは速いが,起動に時間がかかるようなWebアプリケーションに対して,大きな効果が見込めることもわかった. 一方で,コンテナの再配置が頻発する場合には,提供サービスレベルにも依存する問題でもあるため,再配置の頻度についてはサービスに合わせた検討が必要である.
5. まとめ
本研究では,HTTPリクエスト処理時において,収容サーバ,および,その経路までの状態に応じて,自動的にコンテナを収容する物理サーバを決定し,サービスを継続させる,HTTPリクエスト単位でのコンテナスケジューリング手法を提案し,その有効性を示した.
実験から,一般的なWebアプリケーションが起動しているコンテナにおいて,複数のホストOSに複数のインスタンスを配置して可用性を担保することなく,単一のインスタンスという少ないリソースで,1.5sから2s程度の再配置処理により,HTTPエラーを発生させることなく可用性を担保することができた. このようなリソース使用量の削減により,サービス利用者は可用性の担保のために,複数の収容サーバに横断的に複数のインスタンスを配置する必要がなくなり,サービス利用料を削減できる. また,データセンターやホストOSを抽象化して,障害や高負荷時に自律的に収容サーバを移動するようなスケジューリングが可能となる.
今後の課題として,コンテナ起動時間の高速化手法をプロダクション環境で評価を行うことや,負荷やレスポンスタイムに応じたHTTPリクエスト単位でのより適応的なコンテナスケジューリング手法の実現が挙げられる.
*1:Prodan R, Ostermann S, A Survey and Taxonomy of Infrastructure as a Service and Web Hosting Cloud Providers,10th IEEE/ACM International Conference on Grid Computing, pp. 17-25, October 2009.
*2:Ferdman M, Adileh A, Kocberber O, Volos S, Alisafaee M, Jevdjic D, Falsafi B, 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.
*3:Amazon Web Services: Lambda, https://aws.amazon.com/lambda/
*4:松本亮介, 川原将司, 松岡輝夫, 大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善, 情報処理学会論文誌, Vol.54, No.3, pp.1077-1086, 2013年3月.
*5:FastContainerにおけるインスタンスとは リクエストを契機に一定期間起動するものであり,リクエストが送られてきていない場合は停止している場合もありうる論理的なインスタンスである.これをFastContainerではMortalと名付ける.
*6:松本亮介, 近藤宇智朗, 三宅悠介, 力武健次, 栗林健太郎, FastContainer: 実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャ, インターネットと運用技術シンポジウム2017論文集,2017,89-97(2017-11-30), 2017年12月.
*7:笠原 義晃, 松本 亮介, 近藤 宇智朗, 小田 知央, 嶋吉 隆夫, 金子晃介, 岡村 耕二, 軽量コンテナに基づく柔軟なホスティング・クラウド基盤の研究開発と大規模・高負荷テスト環境の構築 , 研究報告インターネットと運用技術(IOT), Vol.2018-IOT-40(2), pp.1-8, 2018年3月.
*8:CRIU -- A project to implement checkpoint/restore functionality for Linux, https://criu.org/
*9:松本亮介, Webサーバの高集積マルチテナントアーキテクチャに関する研究, 京都大学博士(情報学)学位論文, 2017.
*10:松本亮介, 栗林 健太郎, 岡部寿男, リクエスト単位で仮想的にハードウェアリソースを分離するWebサーバのリソース制御アーキテクチャ, 情報処理学会論文誌, Vol.59, No.3, pp.1016-1025, 2018年3月.
*11:自動的にハードウェアリソースを追加し負荷分散を実現する機能
*12:松本亮介, 川原将司, 松岡輝夫, 大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善, 情報処理学会論文誌, Vol.54, No.3, pp.1077-1086, 2013年3月.
*13:P Mell, T Grance, The NIST Definition of Cloud Computing", US Nat'l Inst. of Science and Technology, 2011, http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
*14:三宅 悠介, 松本 亮介, 力武 健次, 栗林 健太郎, アクセス頻度予測に基づく仮想サーバの計画的オートスケーリ ング, 情報処理学会研究報告インターネットと運用技術(IOT),2017-IOT-38, Vol.13, pp.1-8, 2017年6月.
*15:Amazon Web Services: Lambda, https://aws.amazon.com/lambda/
*16:松本亮介, 近藤宇智朗, 三宅悠介, 力武健次, 栗林健太郎, FastContainer: 実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャ, インターネットと運用技術シンポジウム2017論文集,2017,89-97(2017-11-30), 2017年12月.
*17:Felter W, Ferreira A, Rajamony R, Rubio J, An Updated Performance Comparison of Virtual Machines and Linux Containers, IEEE International Symposium Performance Analysis of Systems and Software (ISPASS), pp. 171-172, March 2015.
*18:Brown Mark R, FastCGI: A high-performance gateway interface, Fifth International World Wide Web Conference. Vol. 6. 1996.
*19:Ryosuke Matsumoto, mruby-fast-remote-check, https://github.com/matsumotory/mruby-fast-remote-check
*20:阿部 敏和, 中山 泰一, プロセスの保存と復元によるGUIアプリケーションの起動高速化, 情報処理学会全国大会講演論文集, 第72回アーキテクチャ, pp95-96, 2010年3月
*21:Haconiwa - the mruby on container, https://haconiwa.mruby.org/
*22:matsumotory/mruby-simplehttpserver, https://github.com/matsumotory/mruby-simplehttpserver
*23:https://github.com/everyleaf/el-training
*24:https://mclolipop.zendesk.com/hc/ja/articles/360011824713