人間とウェブの未来

「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。

第二回 #wsa研 でHTTPリクエスト単位でコンテナを再配置する仮想化基盤の高速なスケジューリング手法について発表しました

第二回Web System Architecture研究会で、タイトルの内容について発表してきましたので、そのスライドと予稿を以下に公開します。

speakerdeck.com

英文タイトルは以下の通り。

Fast Scheduler for a Cloud Platform to Relocate Containers at Each HTTP Request

クラウドサービスの普及に伴い,個人のWebサイトでもクラウドサービスに類する機能を利用して,突発的なアクセス集中に耐性があり,かつ,利用したリソース使用量に応じて課金するサービスの提供が求められている. 我々はその要求に応じるために,Webサイトをコンテナ上に構築し,コンテナの起動や停止,複製やリソース割り当てといった状態の変更を素早く実行できるコンテナ管理アーキテクチャFastContainerを提案した. 一方で,単一のコンテナが特定のサーバに収容されている状態で,サーバが過負荷に陥ったり停止したりするような状況においては,障害時にコンテナの収容サーバ情報の変更を手動で構成管理データベースに反映させる必要があった. 本研究では,HTTPリクエスト処理時において,収容サーバ,および,その経路までの状態に応じて,自動的にコンテナを収容するサーバを決定し,サービスを継続させる,HTTPリクエスト単位でのコンテナスケジューリング手法を提案する. 提案手法では,FastContainerの状態変化の高速性に基づいて,コンテナが頻繁に収容サーバを変更されてもサービスに影響がないことを利用する. それによって,プロキシサーバから収容サーバに1個のICMPパケットで応答速度を計測し,少ないパケット数と応答速度に基づいた短いタイムアウトで収容サーバの反応時間を計測できる. そのことで,単一のコンテナであっても,HTTPリクエスト単位でのコンテナスケジューリングを実現し,可用性を担保する.

1. はじめに

インターネットを活用した企業や個人の働き方の多様化に伴い,インターネット上で自らを表現する機会が増加している. 特に個人にとっては,TwitterやFacebookを活用して,自身が作成したコンテンツを拡散させることにより,効率よくコンテンツへの訪問数を増やすことができるようになった. その結果,コンテンツの内容の品質が高ければ,さらに拡散され,コンテンツに紐づく個人のブランド化も可能になってきている. そのため,コンテンツ拡散時であっても継続的に配信可能なWebサイトの構築は,個人用途であっても非常に重要になってきている.

Webコンテンツを継続的に配信するためには,オートスケーリングのような負荷対策と,冗長構成による可用性の担保が挙げられる. 一般的に,個人がWebコンテンツを配信するためには,Webホスティングサービスやクラウドサービスなどが利用される*1. 特に,個人の利用を想定した場合,単一のサーバに高集積にユーザ領域を収容するような低価格Webホスティングサービスが利用される. そのような低価格ホスティングサービスでは,利用者のWebコンテンツが特定のWebサーバに紐づくため,ユーザ領域単位で突発的なアクセス集中に対して負荷分散することが難しい. クラウドサービスの場合は,利用者がアクセス集中に耐えうるオートスケーリング*2の仕組みを作る必要があったり,各サービス・プロバイダが提供しているオートスケーリングの機能*3を使う必要がある.

可用性の面では,Webホスティングサービスの方式もクラウドサービスも,仮想的に構築されたサーバ環境であるインスタンスを複数のハードウェア上に起動させることにより,特定のハードウェアに障害が置きてもサービスを停止せずに提供可能である*4. しかし,複数台のインスタンスが必要であることに起因するコストの問題や,ハードウェアが停止すると縮退状態のインスタンスでサービスを提供することになり,場合によってはリソース不足に陥る.

我々は,従来のWebホスティングサービスを利用できる程度の知識を持った個人がWordPressのような一般的なCMSを利用したWebコンテンツを配信することを前提に,サービス利用者が負荷分散のシステム構築やライブラリの運用・管理を極力必要とせず,迅速にユーザ領域を複数のサーバに展開可能な,実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャのFastContainerを提案した*5. FastContainerは,インスタンスとしてコンテナのように起動の所要時間が小さい実行環境を採用し,リクエスト単位でコンテナの状態を決定する. そのため,オートスケーリングの観点において,アクセス集中時にはコンテナの負荷やアクセス数に応じて,コンテナをリクエスト契機に自動的に複製,あるいはリソースの追加割り当てを行い,迅速に自動的な負荷分散ができる. 一方,可用性の面では,単一のコンテナが収容されているサーバが稼働していることが前提であり,収容サーバが停止すると,手動によるコンテナ再配置が必要であった. そのため,可用性を担保するには,従来手法と同様にコンテナを複数の収容サーバに起動して配置しておく必要がある.

本研究では,HTTPリクエスト処理時において,単一のコンテナであっても,収容サーバの状態に応じて,自動的にコンテナを別の収容サーバに再配置し,サービスを継続させる,HTTPリクエスト単位でのコンテナスケジューリング手法を提案する. 提案手法では,FastContainerの状態変化の高速性に基づいて,コンテナが頻繁に収容サーバを変更されてもサービスに影響がないことを利用する. それによって,プロキシサーバから収容サーバに1個のICMPパケットで応答速度を計測し,少ないパケット数と応答速度に基づいた短いタイムアウトで収容サーバの反応時間を計測できる. そのことで,単一のコンテナであっても,HTTPリクエスト単位でのコンテナスケジューリングを実現し,可用性を担保する.

本論文の構成を述べる. 2章では,Webホスティングサービスやクラウドサービスにおけるオートスケーリング,FastContainer等の特徴とその課題について述べる. 3章では,2章で述べたインスタンスの再配置の課題を解決するための提案手法のアーキテクチャおよび実装を述べる. 4章では,HTTPリクエスト単位でのコンテナスケジューリング手法の評価を行い,5章でまとめとする.

2. Webサービス基盤の負荷分散と可用性

最もアクセスが集中しており,かつ,Webコンテンツを幅広く閲覧される可能性が高い状況においては,サーバが高負荷状態となってアクセスが困難となり,貴重なコンテンツ拡散の機会を逃すことも多い. また,ホストが収容されているハードウェアに障害があった場合に,いかにサービスを継続するかといった可用性の観点でシステムを構築する必要もある. 本章では,相互に関連の深いスケーリングの特性と可用性の観点から,Webホスティングサービスやクラウドサービスにおける関連研究と課題について整理する.

Webホスティングサービス

負荷対応のためのスケーリング手法は,大きく分けて,稼働している単一のインスタンスに割り当てるハードウェアリソースを増減させるスケールアップ型と,複数のインスタンスへと起動数を増減することによって負荷分散を行うスケールアウト型の2つに分類できる.

一般的に,個人がWebコンテンツを配信するためには,Webホスティングサービスやクラウドサービスなどが利用される*6. 特に,個人の利用を想定した場合,仮想ホスト方式を利用して,単一のサーバに高集積にユーザ領域を収容するような低価格Webホスティングサービスが利用される*7. 仮想ホスト方式では複数のホストを単一のサーバプロセス(ただし,ここでいう単一のサーバプロセスとは,ホスト毎にサーバプロセスを起動させるのではなく,複数のホストでサーバプロセスを共有することを示す)で処理するため,リクエストはWebサーバプロセスを共有して処理される. そのため,ホスト単位で使用するリソースを適切に制御したり,その原因を迅速に調査することが困難である*8

Webホスティングサービスでは,サービス利用者のWebコンテンツは特定のWebサーバに収容され,WebサーバとWebコンテンツが紐づくため,負荷に応じたオートスケーリングは,データの整合性の面と前述したホスト単位での適切な負荷計測・制御の面から困難である. このような場合に適用可能な手法として,ユーザデータ領域を共有ストレージにまとめた上で,仮想ホスト方式を採用した複数台のWebサーバで負荷分散と可用性を担保する手法*9がある. しかし,Webサーバを複数台配置して全ホストを同一の設定にすることが前提となる手法であるため,ホスト単位でのスケーリングや可用性の担保は対応できず,コストも高くなる. また,負荷に応じて,ホスト単位での即時性の高いスケールアップ型の負荷対応もできない.

クラウドサービス

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

クラウドサービスでは,Webコンテンツを配置するだけでなく,Webサーバソフトウェアやデータベースをサービス利用者が自ら構築する必要がある. そのため,負荷分散のためのシステム設計をホスト単位で個別に行うことができる点において自由度は高いが,前提として専門的な知識が必要となる.

オートスケーリングについては,負荷に応じてインスタンスを増減させる機能が提供されている*11. しかし,その負荷の監視間隔が分の単位であり,突発的なアクセスに対して検知するまでの時間が長くなる. 負荷状況に応じて仮想マシンを起動できたとしても,テレビ放映の影響のような突発的な高負荷時に,オートスケーリングのための処理自体が追いつかず,サービス停止に繋がることも多い.

仮想マシンの起動時間の問題を解決するためにコンテナを利用する手法*12や,外部サービス連携によってスケーリングを行う条件を詳細に定義できるサービス*13もある. しかし,スケーリング時の判定を行う際に,OSの負荷やプロセスの状態等を監視する方式がとられており,監視の時間間隔や取得できる情報の粒度が荒く,突発的な負荷やハードウェア障害に対する即時スケーリングと誤検知との両立が難しい.

高負荷状態に対して迅速に対応するためには,事前にある程度想定される量の仮想マシンを予測的に起動させておくことによって対処する手法がある*14. しかし,本手法は突発的なアクセスに対するスケーリングを対象としておらず,予測の精度を保つための各種パラメータの選定に関する課題もある.

上記のような問題を解決するために,クラウドサービスプロバイダのAWSは,プロバイダ指定の記法によってアプリケーションを実装すれば,自動的にコンピュータリソースを決定し,高負荷時には自動的にプロバイダ側でオートスケーリングする機能*15を提供している. しかし,前提としてプログラミングができるエンジニアを対象としており,一般的なOSSとして公開されているWebアプリケーションを利用できないことが多く,個人がWebコンテンツを配信する用途においては使用上の制限が大きい.

可用性の面では,Webホスティングサービスの方式と同様に,インスタンスを複数のハードウェア上に起動させることにより,特定のハードウェアに障害が置きてもサービスを停止せずに提供可能である. しかし,複数台のインスタンスが必要であることに起因するコストの問題や,ハードウェアが停止すると縮退状態のインスタンスでサービス提供することになり,場合によってはリソース不足に陥る.

FastContainerアーキテクチャ

我々は,個人がWebコンテンツを配信する用途において,Webホスティングサービスやクラウドサービスにおける突発的にアクセス集中の対応やオートスケーリングの課題を解決するために,FastContainerアーキテクチャを提案した*16. FastContainerは,Webホスティングサービスを利用できる程度の知識を持った個人が,WordPressのような一般的なCMSを利用したWebコンテンツを配信することを前提にしている. FastContainerは,そのようなサービス利用者が負荷分散のシステム構築やライブラリの運用・管理を極力必要とせず,迅速にユーザ領域を複数のサーバに展開可能な,実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャである. その特性を利用して,我々はメールシステムにも応用する手法を提案した*17

FastContainerアーキテクチャでは,インスタンスとして,仮想マシンではなくLinuxコンテナ*18を利用する. Linuxコンテナはカーネルを共有しながらプロセスレベルで仮想的にOS環境を隔離する仮想化技術のひとつである. そのため,コンテナの起動処理は仮想マシンのようなカーネルを含む起動処理と比べて,新しくプロセスを起動させる程度の処理で起動が可能であるため,起動時間が短時間で済むという特徴がある.

FastContainerアーキテクチャでは,コンテナが仮想マシンと比較して速く起動できる点と,FastCGI*19を参考に,サーバへの収容効率を高めつつ性能を担保するアーキテクチャを組み合わせる. さらに,HTTPリクエスト毎に負荷状態やアクセス数に応じて,Webアプリケーションコンテナの起動処理,起動継続時間,コンテナの起動数およびリソース割り当てをリアクティブに決定する. 一定時間起動することにより,一度コンテナが起動してしまえば,起動時間に影響なくレスポンスを送信できる. この特性によって,ホストをコンテナ単位で個別に起動しながらも,リクエストの無い不要なコンテナは自然に停止するため,高集積に収容できる.

FastContainerは,コンテナの起動が一般的に高速であること,リクエストを契機としたリアクティブな起動処理であることにより,突発的な負荷に対しても迅速にリクエスト単位でオートスケーリングが可能となる. スケールアップについても,コンテナのリソース管理がcgroupによってプロセス単位で制御されており,cgroupの特徴を利用して,プロセスが処理中であってもCPU使用時間などの割り当てを即時変更できる.

しかし,このアーキテクチャはコンテナが収容されるサーバが稼働していることが前提であり,収容サーバが停止すると,手動によるコンテナ再配置が必要であった. また,単一のコンテナで起動している場合は,その収容サーバが停止すると,手動で再配置が行われるまでには同様にサービスも停止してしまう. そのため,ハードウェア障害時の可用性については,Webホスティングサービスやクラウドサービスと同様に,複数の収容サーバに横断的に複数のコンテナを立ち上げておく必要があった.

3. 提案手法

個人の利用者がWordPressのような一般的なWebコンテンツを配信する仮想化基盤において,収容効率を高めつつ,アクセス集中による負荷やインスタンスの収容サーバの障害に対する可用性を担保可能な基盤にするためには,以下の要件が必要である.

  1. インスタンスでWordPressのような一般的なWebアプリケーションが動作する
  2. 単一のインスタンスであっても収容サーバ障害時には別サーバへ自動的に再配置される
  3. インスタンスの再配置の実行時であっても数秒の遅延でHTTPタイムアウトすることなくオンラインでレスポンスを返せる

本研究では,上述した3つの要件を満たすためにFastContainerを応用して,HTTPリクエスト単位でコンテナを再配置する仮想化基盤の高速なスケジューリング手法を提案する. 提案手法は,HTTPリクエスト処理時において,収容サーバ,および,その経路までの状態に応じて,自動的にコンテナを収容するサーバを決定し,サービスを継続させる. FastContainerの状態変化の高速性に基づいて,コンテナが誤検知によって再配置されてもサービスが停止しないことを利用する. それによって,プロキシサーバから収容サーバにICMPで接続を試みた上で,短いタイムアウトで収容サーバの反応時間を計測できる. そのことで,HTTPリクエスト単位でのコンテナスケジューリングを実現する.

図に,コンテナスケジューリングのフローを示す.

f:id:matsumoto_r:20180504122520p:plain

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のタイムアウトの時間と,コンテナの収容サーバ変更後のコンテナ再配置にかかる時間の合計値をできるたけ短くすれば良い.

ICMPのタイムアウト時間を短くするためには,Web ProxyとHost OS間の通常のICMPに必要とする時間にタイムアウト値をなるべく近くすることが必要となる. 同時に,一時的な遅延によって,障害と至らないにも関わらずタイムアウトした場合に再配置が発生したとしても,サービス継続への影響を最小化できれば良い. FastContainerのプロトタイプ実装と実験環境では,単一のコンテナを複数のコンテナにスケールアウトする場合に,レスポンスタイムが短縮されるまでにかかる時間が実験から数秒程度とわかっている*20. スケールアウト型のスケーリングは,コンテナを追加で起動させる処理であり,コンテナの再配置の起動にかかる処理と同一の処理と言える. そのため,再配置に必要となる時間が論文の環境では数秒程度で完了することが見込める. また,コンテナの起動時間自体はFastContainerの課題である*21ため,本手法のスコープは,再配置に要する時間をFastContainerにおけるコンテナの起動時間にできるだけ近づけられることとする.

以上のことから,FastContainerの状態変化の高速性を活用することにより,積極的にICMPタイムアウトを短くすることが可能である. また,Host OSが停止していない状況であっても,ICMPタイムアウトが生じた場合は何らかの負荷や異常が発生しているとも見なせる. それによって,別のHost OSにコンテナが再配置されることは,サービスが停止しない限りは有効なスケジューリングと考えられる.

4. 実験

f:id:matsumoto_r:20180504122929p:plain

本手法の有効性を確認するために,上の図に示すFastContainerを用いた実験環境を構築し,コンテナのスケジューリング処理を評価した. 下の表に実験環境と各種ロールの役割を示す.

f:id:matsumoto_r:20180504122818p:plain

実験環境の各ロールのNICとOSは全て,NICは1Gbps,OSはUbuntu16.04,カーネルは4.4.0-59-genericを利用した.

コンテナのデータはDataPool上に保存し,ComputeからDataPoolに対してNFSv3でマウントした.

ベンチマーク対象のコンテナは,40バイトの静的ファイルを返すだけのコンテナと,WordPress4.9.5をインストールしてデフォルトページを表示するコンテナを用意した. それぞれのコンテナには,Apache2.4.10をインストールし,PHPのバージョン7.1.11をApacheモジュールとして組み込んで利用した. Apache起動時には5プロセス起動し,アクセス集中時には150プロセスまで起動する設定を行った.

実験では,まず本実験のためのパラメータ設定と考察のために,予備実験を行った. その上で,本実験では,表のロールを構築し,ClientからUserProxyを介して,Computeに収容されているコンテナに対してベンチマークを行い,レスポンスタイムを計測した.

予備実験

ICMPタイムアウトに関する予備実験

最初に,ICMPチェックのタイムアウト時間を決定するために,UserProxyとCompute間のICMPの応答時間を計測した. 計測にはmruby-fast-remote-checkを利用し,ICMPパケットを1パケット送信しその応答時間を測定した. 測定は1000回行い,その平均と標準偏差,最大値,最小値を,小数点以下を有効数字3桁で計算した.

f:id:matsumoto_r:20180504123113p:plain

上の表に,ICMP応答時間の結果を示す. 実験環境では,ICMP応答時間は平均1msec程度であることがわかった. また,最大値は16msec程度であることから,ICMPタイムアウトの値を10msec程度にすると,Computeが停止していない状態でも誤検知を起こす場合があると考えられる. そこで,本実験ではUserProxyからComputeへHTTPリクエストを転送する際のICMPタイムアウトを,静的ファイルのような負荷の小さなコンテナの場合は10msec,WordPressのようなCPUを比較的多く利用するコンテナは100msecで計測することにした.

Apacheコンテナの起動時間に関する予備実験

続いて,実験環境において,Apacheコンテナが最初に起動するのに要する時間を計測した. 計測する理由として,Apacheコンテナの起動時間を計測しておくことにより,実際に再配置が行われた場合のレスポンスタイムから,そのレスポンスタイムの妥当性を考察するためである. コンテナの起動時間自体はFastContainerの課題であるため,本実験のスコープは,再配置に要する時間をFastContainerにおけるコンテナの起動時間にできるだけ近づけられることである.

FastContainerアーキテクチャによるコンテナ停止状態に対してHTTPリクエストを送信し,リクエスト契機にコンテナが起動してレスポンスを返すまでの時間を計測する. 上述した,ApacheとPHPが動作するコンテナを用いて,40バイトの静的ファイルに対するレスポンスタイムを測定することで,全体のレスポンスタイムの内,コンテナとApacheの起動時間の合計が支配的になるようにした. また,40バイトの静的ファイルに対するレスポンスタイムは,10msec前後である. 測定は500回行い,その平均と標準偏差,最大値,最小値を,小数点以下を有効数字3桁で計算した.

f:id:matsumoto_r:20180504123212p:plain

上の図に,コンテナとApacheの起動時間合計を示す. コンテナの起動時間については,平均的には1.758秒であったが,最大値としては4.817秒,最小値としては1.045秒となった. つまり,理想的には,本手法によって収容サーバであるComputeが停止した際には,ICMPタイムアウト値が1msec程度で,かつ,コンテナの再配置による起動時間が1758msecであるため,それらの総和程度であることが見込める.

最大値が4.817秒かかっている原因の詳細は考察できていないが,Apacheの起動時に設定ファイルやモジュールなどがキャッシュに載っているかどうかによって変わる可能性があるため,引き続き考察を行う.

再配置時のレスポンスタイムの本実験

予備実験の結果に基いて,静的ファイルとWordPressに対するレスポンスタイムを計測した. ベンチマーク測定中に,一定時間経過後にCompute上でipatablesコマンドによりUserProxyからのパケットをdropし,別のComputeにコンテナが再配置されるようにした.

静的ファイルのコンテナの最大CPU使用量は,cgroupの機能により1コアのみ利用できるように割り当て,メモリは512MBを割り当てた. また,WordPressのコンテナは,PHPの処理にCPU使用時間を静的ファイルと比較して多く必要とするため,割り当てメモリは512MBであるが,CPUは4コア利用可能となるように割り当てた.

静的ファイルを返すコンテナに対するベンチマークでは,abコマンドで,同時接続数10,総接続数100000で計測を行い,50秒の時点でネットワークを切断した. この50秒は,静的ファイルに対する上述したパラメータによる総処理時間が100秒程度であるため,前後の変化が明らかとなるようにその半分程度の時間に設定した.

また,WordPressのコンテナに対するベンチマークでは,abコマンドで,同時接続数10,総接続数5000で計測を行い,静的ファイルに対するコンテナと同様の理由から,100秒の時点でネットワークを切断した.

ベンチマークでは,秒間のレスポンスタイムの平均値を計算し,時系列データとしてベンチマークが完了するまでのレスポンスタイムの変化を計測した.

f:id:matsumoto_r:20180504123331p:plain

上のグラフに,ICMPタイムアウトが10msecの場合の静的ファイルに対するベンチマーク結果を示す. 実験環境においては,静的ファイルのベンチマークでは1リクエストにつき10msec前後でレスポンスを返せている. 50秒の時点でComputeが停止し,UserProxyがICMPタイムアウト10msec経過後に,CoreAPIから再配置の情報を取得し,もう一台の正常に動作しているComputeに再配置を行う. その際,ICMPタイムアウトに10msec,再配置後,コンテナを起動させてレスポンスを返すまでに秒間平均1400msec程度時間を要している. その後52秒の段階では,既に10msec前後のレスポンスタイムとなっているため,再配置に要する時間は1.5秒程度であった.

f:id:matsumoto_r:20180504123344p:plain

上のグラフに,ICMPタイムアウトが100msecの場合のWordPressに対するベンチマーク結果を示す WordPressでは,実験環境においては平均的に400msec前後のレスポンスタイムであった. 100秒の時点で再配置の処理が動作した際には,2080msecの処理時間を要した. ICMPのタイムアウト値が100msecであることから,コンテナの再配置からApacheの起動とレスポンス生成までには概ね1980msecで実現できている. そのことから,コンテナの再配置とコンテナ起動に要する時間は,WordPressのレスポンスタイム400msecを除くと,1580msecとなる.. また,22秒の時点から70秒の時点まで一時的にレスポンスタイムが2倍に増加している期間があった. これは,実験では原因が特定できなかったため,引き続き調査予定である.

以上の実験結果について,予備実験のICMPやコンテナ起動時間の数値からも,再配置に要する時間は妥当であることがわかった. 予備実験結果のコンテナの起動時間の平均や分散からも,再配置後のコンテナからのレスポンスに要する時間は,静的コンテンツもWordPressもコンテナの起動時間が支配的であり,本手法における再配置手法そのものの処理時間は影響がないことがわかった. また,誤検知による再配置は生じなかったが,1msecまでタイムアウトを短くすると,実験環境においては大量に再配置が発生することがわかっている.

一方で,再配置時に9リクエストだけ,500系のエラーを返していたことが分かった. これは,(同時接続数-1)の値であり,システム実装上の問題で,CoreAPIに対して同時に再配置の依頼が要求された際に,1つを除いてエラーを返す実装にしていたためである. この問題については,1つを除いて再配置の要求リクエストを一時停止させ,再配置が完了した時点で残りのコンテナへのHTTPリクエストを再配置後のコンテナに転送することで解決できる.

UserProxyからComputeにリクエスト転送が送信されて,Compute上のコンテナからUserProxyにレスポンスデータが送信される前の状態でComputeが停止してしまった場合は,そのレスポンスをUserProxyが正しく受信できないため,レスポンスを一部取りこぼすこともありえる. しかし,これは従来方式において複数のホストOSにそれぞれ分散してインスタンスを配置して可用性を担保する方式でも原理的に生じるため,本手法の特徴的な問題ではない.

本実験結果から,単一のコンテナインスタンスを単一の収容サーバに起動させておきながらも,その収容サーバの停止時には,迅速に再配置のスケジューリングが行えていることがわかった. また,実験環境程度のハードウェアスペックで,1.5秒から2秒程度であれば,実用上はHTTPタイムアウトすることなくレスポンスを返せると見込めるが,提供サービスレベルにも依存する問題でもあるため検討が必要である. 一方,FastContainerの課題のうち,コンテナのイメージ化によって起動時間を高速化する研究*22が改善されれば,再配置に占めるコンテナの起動時間も短縮できるため,よりこの手法を活かすことができる.

5. まとめ

本研究では,HTTPリクエスト処理時において,収容サーバ,および,その経路までの状態に応じて,自動的にコンテナを収容するサーバを決定し,サービスを継続させる,HTTPリクエスト単位でのコンテナスケジューリング手法を提案し,その有効性を評価した.

本研究により,WordPressのような一般的なWebアプリケーションが起動しているインスタンスにおいて,複数のホストOSに複数のインスタンスを配置して可用性を担保することなく,単一のインスタンスという少ないリソースで,1.5秒から2秒程度の再配置処理により,HTTPエラーを発生させることなく可用性を担保することができた. このようなリソース使用量の低減により,本手法は個人用途のホスティングサービスのような低価格が求められるサービスの設計に適している.

今後の課題として,従来からの課題であるFastContainerアーキテクチャのコンテナ起動時間を更に短縮することや,負荷やレスポンスタイムに応じたHTTPリクエスト単位でのコンテナスケジューリング手法の実現が挙げられる.その中で,コンテナ起動時間を短縮するアプローチとして、以下の研究を開始している。

接続待ちソケット生成前のプロセスイメージを利用したWebサーバの汎用的な起動時間短縮手法

スマートフォンやPCのモバイル化,SNSの爆発的普及に伴い,個人のWebサイトであってもコンテンツ次第でアクセスが集中する機会が増大してきている. 我々はアクセス数や負荷に応じて反応的かつ高速にリソースを再割当てすることで,サービス利用者や事業者に手間を強いることなく突発的なアクセス集中に耐えうるFastContainerアーキテクチャを提案した. しかし,新たなインスタンスとして新規でリソースを追加する場合は,インスタンス起動時のWebサーバプロセスの起動時間がオーバーヘッドとなってレスポンスが一時的に遅くなり,ユーザ体験を損なう課題があった. CRIUと呼ばれるLinuxプロセスのCheckpoint/Restore技術によってプロセスをイメージ化することにより,高速にプロセスの状態を復帰させることができるが,Webサーバが起動してからイメージ化すると,アドレスやポートの衝突,起動後のサーバやコンテンツの状態等を保持してしまうため,実用上扱いにくい. 一方で,各種Webサーバの起動処理時に,socket()システムコールを実行する直前でプロセスをイメージ化する場合,各種サーバソフトウェアの初期化処理にサーバソフトウェアに依存した拡張実装をそれぞれ追加する必要があり汎用性が低い. そこで,本研究では,Webサーバソフトウェアに拡張実装することなく,接続待ちソケットの生成時に実行されるシステムコールを監視して,システムコール実行前の段階でプロセスイメージを作成することにより,汎用的にWebサーバの起動時間を短縮する手法を提案する.

参考文献

*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: 実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャ, インターネットと運用技 術シンポジウム2017論文集,2017,89-97(2017-11-30), 2017年12月.

*6: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.

*7:松本 亮介, Webサーバの高集積マルチテナントアーキテクチャに関する研究, 京都大学博士(情報学)学位論文, 2017.

*8:松本亮介, 栗林 健太郎, 岡部寿男, リクエスト単位で仮想的にハードウェアリソースを分離するWebサーバのリソース制御アーキテクチャ, 情報処理学会論文誌, Vol.59, No.3, pp.1016-1025, 2018年3月.

*9:松本亮介, 川原将司, 松岡輝夫, 大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善, 情報処理学会論文誌, Vol.54, No.3, pp.1077-1086, 2013年3月.

*10: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.

*11:Amazon Web Services: Auto Scaling, https://aws.amazon.com/autoscaling/.

*12:He S, Guo L, Guo Y, Wu C, Ghanem M, Han R, Elastic application container: A lightweight approach for cloud resource provisioning, Advanced information networking and applications (AINA 2012) IEEE 26th international conference, pp. 15-22, March 2012.

*13:http://www.rightscale.com/

*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:松本 亮介, 小田 知央, 笠原 義晃, 嶋吉 隆夫, 金子晃介, 栗林 健太郎, 岡村 耕二, 精緻に解析可能な恒常性のあるメール基盤の設計, 研究報告インターネットと運用技術(IOT), Vol.2018-IOT-40(17), pp.1-8, 2018年3月.

*18: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.

*19:Brown Mark R, FastCGI: A high-performance gateway interface, Fifth International World Wide Web Conference. Vol. 6. 1996.

*20:松本亮介, 近藤宇智朗, 三宅悠介, 力武健次, 栗林健太郎, FastContainer: 実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャ, インターネットと運用技 術シンポジウム2017論文集,2017,89-97(2017-11-30), 2017年12月

*21:笠原 義晃, 松本 亮介, 近藤 宇智朗, 小田 知央, 嶋吉 隆夫, 金子晃介, 岡村 耕二, 軽量コンテナに基づく柔軟なホスティング・クラウド基盤の研究開発と大規模・高負荷テスト環境の構築, 研究報告インターネットと運用技術(IOT), Vol.2018-IOT-40(2), pp.1-8, 2018年3月.

*22:笠原 義晃, 松本 亮介, 近藤 宇智朗, 小田 知央, 嶋吉 隆夫, 金子晃介, 岡村 耕二, 軽量コンテナに基づく柔軟なホスティング・クラウド基盤の研究開発と大規模・高負 荷テスト環境の構築, 研究報告インターネットと運用技術(IOT), Vol.2018-IOT-40(2), pp.1-8, 2018年3月.