人間とウェブの未来

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

実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャと今後の課題

一年前にFastContainer構想という記事を書いてから、主にアカデミアでFastContainerに関する研究をすすめたり、FastContainerに基いて実装されている「ロリポップ！マネージドクラウド」というロリポップ！の新しいプランのリリースに向けて取り組みを行ったりしておりました。

hb.matsumoto-r.jp

そこで、ブログでも「FastContainer: 実行環境の変化に素早く適応できる 恒常性を持つシステムアーキテクチャ」についての構想からのアップデートをまとめておきたいと思います。

英文タイトルは、

A Homeostatic System Architecture Rapidly Adapting Execution Environment Changes

です。

クラウドサービスやWebホスティングサービスの低価格化と性能の向上に伴い、コンテナ型の仮想化技術を活用することにより、複数のユーザ環境の収容効率を高めると同時に、セキュリティの担保とリソース管理を適切に行うことが求められている。一方で、障害時の可用性やアクセス集中時の負荷分散については依然として各システムに依存している。

本研究では、 HTTPリクエスト毎に、コンテナの起動、起動時間、起動数およびリソース割り当てをリアクティブに決定する、実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャを提案する。

提案手法により、アクセス集中時にはコンテナがHTTPリクエストを契機に、アクセス状況に応じて複製・破棄されることで、迅速に自動的な負荷分散が可能となる。さらに、コンテナが一定期間で破棄されることにより、収容効率を高め、ライブラリが更新された場合には常に新しい状態へと更新される頻度が高くなる。

はじめに

背景

  • 個人が当たり前に多種多様なWebサイトを持つ時代
    • VPSのような自由度と隔離環境も求められてきている
  • SNSを介して個人のコンテンツを拡散しやすい時代
    • 個人のWebサイトへのアクセス集中する機会の増大
  • 個人サイトでも迅速にオートスケールできる基盤が必要

しかし、一般的に、単一のサーバに複数のユーザ領域を収容するようなWebホスティングサービスでは、利用者のWebコンテンツが特定のWebサーバに紐づくため、負荷分散することが難しい。また、クラウドサービスの場合は、利用者がアクセス集中に耐えうるオートスケールの仕組みを作る必要があったり、各サービス・プロバイダが提供しているオートスケールの機能を使う必要がある。

AWSなどのサービス・プロバイダが提供しているオートスケール機能では、サービス・プロバイダ自身が提供する監視項目に基づき内部で自力構築した仮想マシンを起動するかまたは外部のサービスを利用して仮想マシンを自動で起動させる必要があるため、突発的なアクセス集中に対して、インスタンス追加処理に時間がかかり負荷分散が間に合わない。また、負荷分散のために事前にインスタンスを複数起動させておくこともリソース効率やコストの観点で課題がある。そもそも、迅速に負荷分散の仕組みを構築するのは、専門的なインフラの知識を持たない個人の利用者（レンタルサーバにコンテンツを配置する程度の知識）には困難である。

目的

改めて、一般的な仮想化基盤のオートスケールの課題をまとめると、

  1. インスタンス追加処理が低速であること
  2. ハードウェアリソースの利用効率の低さ
  3. スケーリングすべき状況検知のリアルタイム性の低さ
  4. 空きリソース確認のためのスケジューリング処理の遅延

本発表では1.と2.の課題を解決できるアーキテクチャの提案し専門的なインフラの知識を持たない個人が意識せずとも使えるサービスへの実装を目指す。（一部3についても言及するが、仮置きのレベルで今後の課題としての扱いが強い。）

そのために、インスタンスが循環する変化に強い基盤の提案したい。そのために以下のように課題を解決する。

  • インスタンス追加処理が低速であることを解決
    • インスタンスの状態の停止・起動・変更を高速に循環できることを目指す
    • リクエスト単位で状態を決定
  • ハードウェアリソースの利用効率の低さを解決
    • リクエストが無いインスタンスは一定期間起動後に停止
    • リクエスト単位でインスタンスの状態を決定する手法の提案

提案の概要

本研究では、従来のWebホスティングサービスを利用できる程度の知識を持った個人がWebコンテンツを配信することを前提に、サービス利用者が負荷分散のシステム構築やライブラリの 運用・管理を必要とせず、迅速にユーザ領域を複数のサーバに展開可能にするために、コンテナの起動をHTTPリクエスト単位でリアクティブに決定する、実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャを提案する。

ここで述べる「リアクティブな決定」とは、HTTPリクエスト単位で外的要因に基づく負荷の状態やレスポンス性能を検出し、状況に応じたコンテナの構成を迅速に決定することを意味する。 具体的な手法としては、Webアプリケーションの実行におけるユーザデータとアプリケーションの処理を明確に分離した上で、迅速に負荷分散処理を実現するために、HTTPリクエストを契機に、コンテナの起動処理、起動継続時間、リソース割り当ておよびコンテナ起動数を決定する。

また、コンテナが一定期間で破棄され、プロセスの起動時間を短縮することによって、マルチテナント方式のリソース効率を高め、同時に、ライブラリが更新された場合には新しい状態へと更新される頻度が高くなる。

加えて、セキュリティや運用技術の課題も同時に解決できる。

  • ホストが循環するのでライブラリが自然に更新されていく
  • 収容先情報を変えるだけで自然に収容サーバ間を移動可能

Serverlessアーキテクチャによる実装との違い

  • WordPress等の一般的なCMSを配置・オートスケール可能とし、アプリケーション側まで基盤で面倒を見る点
    • 基盤での運用管理領域の違い
    • クラウドプロバイダ指定のコーディングの必要も基本ない
      • AWS lambdaに類するServerless Architectureでは利用者による所定のコーディングが必要であるため、基本的にはエンジニア向けである
      • FastContainerは汎用的なWebアプリケーションを使えてアクセス集中時には基盤側でスケーリングできるため、エンジニアのような知識を必要としない個人向けにも提供できる
        • 自由度は低め（WebアプリケーションやRuby on Rails、nodeなどの選択が可能）でデータベースは基本スケールアップが前提

Herokuとの違い

Herokuの無料プランのアーキテクチャとの差については、Herokuはあくまでリソース制限を目的として稼働時間やスリープ時間を設けているが、本手法はリソース効率化に加えて、スリープや復帰、スケール処理などの状態の変化を高速化しリアクティブに状態を変化させることによって、変化に強い恒常性を生み出すことが目的である。今後の課題にも示す通り、FastContainerは、サービスレベルとアクセス数からコンテナのライフタイムを適応的に決めていったり、投機的起動により変化に強い恒常性を目指している。

Herokuの有料プランはスリープ時間がないことからも、基本的には従来の起動させ続けるアプローチによって安定化させる(定期的な再起動をさせつつ)というアーキテクチャである。以下1年前のHerokuの中のあゆみんさんとのやりとりも参考になる。

https://twitter.com/ayumin/status/811610070299525120

仮想化基盤のスケーリングと運用技術の課題

本発表では1.と2.の課題をスコープとする。

  1. インスタンス追加処理が低速であること
  2. ハードウェアリソースの利用効率の低さ

インスタンスの追加処理が低速であること

  • VMの場合、検知からのインスタンス起動に時間がかかる
    • 突発的なアクセス時にスケール処理が間に合わない
    • スケールアップ（割り当てリソース増強）も簡単にできない

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

クラウドサービスでは、Webコンテンツだけでなく、Webサーバソフトウェアやデータベースをサービス利用者が自ら構築する必要がある。そのため、負荷分散のためのシステム設計を個別に 行うことができる点において自由度は高いが、専門的な知識が必要となる。 オートスケールについても、負荷に応じて増減させる機能が提供されているが、その負荷の監視間隔が分の単位であり、突発的なアクセスに対して検知するまでの時間が長くなる。 負荷状況に応じて仮想マシンを起動させたとしても、テレビ放映の影響のような突発的な高負荷時に、オートスケールのための処理自体が追いつかず、サービス停止に繋がることも多い。 また、仮想マシンの起動時間の問題を解決するためにコンテナを利用する手法や、外部サービス連携によってスケールを行う条件を詳細に定義できるサービスもあるが、スケール時の判定を行う際に、外部サーバなどからOSの負荷やプロセスの状態等を監視する方式がとられており、監視の時間間隔や取得できる情報の粒度が荒く、突発的な負荷に対して即時性が低くなる問題もある。

ハードウェアリソースの利用効率の低さ

  • インスタンスが基本的に起動しリソースを占有し続ける
    • インスタンスがVMの場合に使用するリソース量も多い
  • 一般的には常時インスタンスが起動し続ける方式
    • 起動インスタンスの数だけ常時リソースを占有する
    • メモリリークするプロセスの影響も受けやすい
  • 高負荷に備えて事前に複数インスタンスを立ち上げておくと良いが、リソース効率が悪い

高負荷状態に対して迅速に対応する即時性を持たせるためには、事前にある程度想定される量の仮想マシンを起動させておくことによって対処する必要があるが、定量的な見積もりや事前のメンテナンスが必要であったり、限られたコストの兼ね合いから適切な見積もりをすることは困難である。 そのため、負荷の状態に基いて適切なインスタンスの数を決定することは難しく、必要以上にコンピュータリソースを使用していることが多い。

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

その他の運用技術やセキュリティの課題

その他の運用技術やセキュリティの課題として、

  • 脆弱性対応やバージョンアップのコストが高い
    • サービスの停止→バージョンアップ→起動など
  • メンテナンス時の調整のコストが高い
    • 収容サーバの移動のコスト
    • サービス停止時間の調整など高い頻度での実施が困難

などが挙げられる。

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

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

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

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

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

FastContainerアーキテクチャ

アーキテクチャの要件

現状の各種サービスの特徴を考慮した場合、限られたリソースの範囲内で負荷に応じて即時インスタンスを制御するためには、リアクティブ性を持つWebサーバ機能を前提に、インスタンスを柔軟に管理し、実用上問題にならない程度の性能を担保するアーキテクチャが必要となる。以下に要件をまとめる。

  • HTTPリクエスト単位の粒度で迅速にインスタンスのスケールアウトとスケールアップできる
  • HTTPリクエスト単位の粒度でインスタンスの監視を行い即時スケール処理の命令を出せる
  • リソース効率化のため必要の無いインスタンスは停止可能であり、必要な時にHTTPリクエスト単位で起動できる

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

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

恒常性を持つアーキテクチャ

これらの要件に基づいて、可用性高く変化に強い基盤を設計するにはどういう性質があればよいか？

  • 状態の変化を高速に行えて反応的に動作できることを重視
    • システムの要素の停止から起動処理の効率化に着目
    • システムの要素の停止状態を許容するシステム
    • 常に停止と起動が循環可能な恒常性を持つシステムを目指す
  • 循環可能 = 可用性が高く常に変化可能な基盤が実現できる

変化し続けることから得られる安定性をもつシステムを目指す。

f:id:matsumoto_r:20171219214341p:plain

この性質をもつアーキテクチャをFastContainerアーキテクチャと命名する。

  • ホストの起動・複製・停止・増強処理の効率化を重視
  • 各種処理をHTTPリクエスト時にリアクティブに実施
  • ホストにはコンテナ型仮想化を採用して起動を高速に実現
  • リクエストに基いてリアクティブにコンテナの状態を決定

ここで、アーキテクチャを実現するに当たって開発したコンテナランタイムのHaconiwaとそのコンテナ関連技術について言及する。

FastContainerとコンテナ関連技術

Haconiwa: コンテナランタイム

FastContainerアーキテクチャをシステムとして実現するためには、コンテナの複雑な制御が必要である。 Haconiwaは近藤らによって開発されており、コンテナのリソース割り当てやプロセス隔離の構成情報の設定だけでなく、コンテナ起動・停止時やコンテナのセットアップ時の各種フェーズでRuby DSLを実行することにより、コンテナの振る舞いをcomposable（システム要求に応じたコンテナを組み合わせて作れる）かつscalable（要求に応じ自分自身を拡張できる）に定義可能で、programmable（上記を満たすため様々なコンテナ戦略に答えるためのコードが書ける）に制御できるソフトウェアである。

Haconiwaはコンテナを固定的な仮想環境としてのみ利用するだけでなく、プログラムで制御が可能なネットワーク上で動作するスレッドとみなせるような方針で開発されている。 また、FastContainerアーキテクチャのように、リクエスト単位でリアクティブにコンテナを起動させることができ、かつ、一定時間起動した後に停止する処理や、Haconiwaで起動されたコンテナを管理するプロセスがコンテナのリソース使用状態を監視して、状態によってHTTPベースのAPIにアクセスするといったような動的な処理をDSLで平易に記述できる。 Haconiwaによって構築されたコンテナのリソース割り当てはcgroupを活用しており、コンテナのプロセスを停止させることなく、処理中であっても割り当てを即時変更することができる。

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

既存のコンテナランタイムとの比較

コンテナの構成を管理するソフトウェアとしては、LXCやDocker、rktがある。 Dockerはコンテナによる仮想環境の独立性を重視しているため、コンテナを構成するプロセスの隔離技術やリソース割り当て技術が機能として密結合になっている。 一方でHaconiwaは、必要なコンポーネントを組み合わせて、chroot()システムコールによる最低限のファイルシステム隔離に加え、CPUやメモリのリソース割り当てのみを適用した環境をDSLによって平易に記述することができる。 そのため、構築したい仮想環境に応じて、仮想環境の独立性と運用性のバランスを検討しやすい設計になっている。

LXCはHaconiwaと同様に比較的プラガブルな作りになっているものの、コンテナの振る舞いを定義するためのフックフェーズが、コンテナ起動や停止時のみといったように限定的である。 一方Haconiwaは、シグナルハンドラや起動後の非同期遅延処理、さらには定期実行のタイマー処理を定義して実行することも可能となっており、コンテナを活用した様々なシステムに適用しやすくなっている。 rktは多くの設定をサポートしているものの、Ruby DSLのようにプログラマブルに記述することはできず、コマンドラインのオプション設定で実行する必要がある。

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

代表的なコンテナのオーケストレーションソフトウェアとしてKubernetesがある。 HaconiwaはKubernetesのように、通常のDockerやLXCによる単一あるいは複数の平易なコンテナ管理に加え、Ruby DSLを各コンテナの処理フェーズで記述可能で、任意の処理を実行可能であることから、独自で実装する場合に複雑になりがちなオーケストレーション層との連携を想定した作りとなっており、Haconiwa自体がオーケストレーションソフトウェアとしても遜色ない使い方が可能である。

今後コンテナを活用した複雑なコンテナ設定、あるいは、オーケストレーション層との連携が求められることを想定すると、Haconiwaのようにコンテナの設定層およびオーケストレーション層との接続をDSLで統一的に記述でき、かつ、Rubyのような一般的に広く使われるプログラミング言語を利用できることにより、独自に定義された記述言語よりも自由度が高く、学習もしやすいと考えられる。

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

コンテナ時代のWebサービス基盤モデルを定義して、FastContainerの立ち位置を明確化する。

f:id:matsumoto_r:20171219214503p:plain

  • サービス層は実際のWebアプリやWebサービスのコンテンツを含む層である。
  • ストラテジー層は、Webサービスの特性に合わせてコンテナ基盤をより特徴的に制御する層であり、FastContainerはここに属する。
  • オーケストレーション層は、Kubernetesを代表として、コンテナ群や収容ホスト群のモニタリングやリソース管理等によってCRIと呼ばれるコンテナ管理ツール（コンテナランタイム）のインタフェース仕様を介してコンテナを制御する層である。
  • コンテナランタイム層は、コンテナそのものの制御層であり、HaconiwaやDocker、LXC等を含む。
  • インフラストラクチャ層はハードウェアやVM、ベアメタル等のコンテナのリソースプールを実現する層である。

コンテナを利用したWebサービス基盤モデルにおける層は、大きく上記のように分類できる。

特に、オーケストレーション層の上のストラテジー層は、コンテナのオーケストレーションツール基盤の上に、さらにそれぞれのWebサービスの特性に合わせた戦略の層として位置するのではないかと考える。 例えば、本論文におけるホスティングサービスのスケーリングや運用効率化に基づいた戦略としてFastContainerアーキテクチャを提案し、その上の層に位置するWebアプリケーションのホスティング環境を改善していくことが目的である。 そういう意味では、ホスティングサービスにより特化した基盤としてFastContainerはストラテジー層に位置し、オーケストレーション層に位置する各種ツールで実装可能であり、KubernetesやMesos MarathonによってFastContainer以下の実装を実現することも可能となるように、Haconiwaも含めて設計・実装していく予定である。

本研究では、FastContainerアーキテクチャをより最適にオーバーヘッドなく実現するために、Haconiwaと各種連携ツールによって構成されるシステムの実装をNHHM Stackと命名した。

状態遷移のアーキテクチャ

次にFastContainerの具体的な処理フローを示す。

HTTPベース

f:id:matsumoto_r:20171219214642p:plain

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

FastContainerアーキテクチャでは、コンテナが仮想マシンと比較して速く起動できる点と、FastCGIのようにリソース効率を高めつつ、性能も担保するアーキテクチャを組み合わせた上で、コンテナ上で起動するWebアプリケーションの実行処理におけるデータとアプリケーションの処理を明確に分離する。 さらに、HTTPリクエスト毎に負荷状態やレスポンス性能に応じて、Webアプリケーションコンテナの起動処理、起動継続時間、コンテナの起動数およびリソース割り当てをリアクティブに決定する。

提案手法では、コンテナが一つ以上起動していれば即時レスポンスを送信し、コンテナが停止していた場合は、リクエストを契機にコンテナを一定期間起動させて複数のリクエスト処理を行う。 これによって、仮にコンテナが全て停止していたとしても、コンテナがリクエスト単位で起動するため可用性が高くなる。 例えば、メモリリークが生じるような不完全なソフトウェアが動作していたとしても、定期的に循環が行われることにより、メモリが解放される。 この特徴により、システム全体がメモリ不足にならないため、そういったソフトウェアを許容できる。 ただし、システムとしては許容できても、ソフトウェアとして不完全であることを検知する必要がある。 また、一定時間起動することにより、一度コンテナが起動してしまえば、起動時間に影響なくレスポンスを送信できる。

TCP/UDPベース

HTTPベースに対して、ポートとIPアドレスをプールしておいて、より汎用的なTCP/UDPレイヤーでのFastContainerは以下のような処理フローになる。

f:id:matsumoto_r:20171220182944p:plain

  • HTTPベースだけでなくTCP/UDPベースのFastContainerを実現させる
    • HTTPベースだとdomainをキーに振り分けが可能
    • TCP/UDPベースだとポートとIPアドレスベースの振り分けが必要
      • プロトコルの中身を見ずにより汎用化させる

これにより、HTTP意外のプロトコルについても同様の枠組みでFastContainerの恒常正を提供することが可能である。例えば、現在研究中の「精緻に解析可能な恒常性のあるメール基盤の設計」においては、メールシステムの恒常性をTCPベースのFastContainerで設計している。

FastContainerの循環モデルとサービスレベル

FastContainerは、インスタンスが循環する前提で設計されたアーキテクチャであるため、サービスレベルに応じて以下の遷移パターンを用意する。

ここでのサービスレベルを考える上では、起動時間の影響、ライフタイムの時間、秒間アクセス数、サービスレベルを関係式に落とし込む必要がある。例えば、これぐらいのアクセス数であれば、起動時間に数秒かかっても、ライフタイムの時間絡みた時にはほとんど無視できる、というサービスレベルの話を論理的に導けるようにすべきである。同時に、この関係式が定義できれば、アクセス数に応じて自動的に最適なライフタイムを設定することも可能であるだろう。また、サービス・プロバイダ側は起動時間にかかる許容時間も設定できるだろう。

以下FastContainerのモデルをまとめる。

  • モータルモデル: ライフタイムが設定されているだけで、純粋にリクエストで起動後、ライフタイム経過後に停止
    • 停止中のコンテナに対する最初のアクセスは起動時間に伴って遅くなる
  • サイクルモデル: ライフタイムが設定されており、ライフタイム経過後の停止時に、さきに新たなコンテナを起動させて、リクエストの向き先を変えてから元コンテナを落とす
    • 最初のアクセスが起動時間の影響を受けない
    • 循環はしているものの、常に1個以上起動している状態と変わらないので、モータルモデルよりリソースを比較的利用する
  • レジデントモデル: 最低1コンテナはライフタイム無しで常時起動しており、負荷時には新しいコンテナを追加する
    • シンプルかつこれまでのイモータルなサーバプロセスモデル

ここで、リクエストに対するプロセスの概念について定義しておく。

  • mortal: リクエスト契機にプロセスが一定期間起動してリクエストを複数処理し、ライフタイムが来たら停止する（FastCGI的）
  • short-lived: リクエスト契機にプロセスが起動してそのリクエストを処理したら停止する（CGI的）
  • immortal: 常にプロセスが起動し続けリクエストを処理し続ける（DSO的httpdのmod_phpなど）

これまでに一般的なWebアプリケーションはimmortalであるといえる。

負荷検知からスケールまでのアーキテクチャ

オートスケーリングのトリガー監視のアーキテクチャは以下の通り。一旦はルールベースで仮置きしている。

f:id:matsumoto_r:20171219214720p:plain

アクセス集中時には、PrometheusがCPU使用量だけでなくCPU使用時間の割り当ての失敗を示すcgroupのthrottledの値、HTTPリクエストに関する同時接続数などを数秒の粒度で収集し、

  • 1分間のCPU使用率が80％超過かつCPUのthrotteledが50%超過していたらスケールアウト
  • 1分間のリクエストが1000req/mを超過かつデータ転送量が32MiB/mを超過していたらスケールアウト
  • 3分間のCPU使用率が30%以下かつ分間リクエストが100req/mかつデータ転送量が1MiB/mしていたらコンテナが1個以上あった場合スケールイン

させる。

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

提案手法では、コンテナの起動が一般的に高速であること、リクエストを契機としたリアクティブな起動処理であること、および、オートスケールの適用方法がリクエスト単位での粒度で行われることにより、突発的な負荷に対しても、負荷状態を迅速に検知できれば、負荷に応じたオートスケールが可能となる。 スケールアップについても、コンテナのリソース管理がcgroupによってプロセス単位で制御されており、cgroupの特徴を利用して、プロセスが処理中であってもCPU使用時間などの割り当てを 即時変更できる。 また、コンテナが一定期間で破棄されることにより、不必要なプロセスの起動数を低減してコンテナの収容効率を高め、ライブラリが更新された場合には常に新しい状態へと更新されることが保証される。

FastContainerまとめ

FastContainerをまとめると、

  • リクエスト単位で高速にスケールアップ・スケールアウト可能
  • コンテナに恒常性を持たせることでリソースの効率化
    • コンテナを使い捨て可能に → immutability
    • 一定時間起動することで都度起動より高速化 → mortality
    • 考え方によってはメモリリークするソフトウェアをも許容
  • コンテナが循環するのでライブラリが自然に更新されていく
    • 利用者にとってはセキュリティ向上
    • 提供側にとっては脆弱性対応やバージョンアップの効率化
  • CMDBの収容先情報を変えるだけで自然に収容サーバを移動
    • メンテナンスや障害対応時の無停止対応が容易になる

実験と考察

実験環境の構成

f:id:matsumoto_r:20171219215952p:plain

CMDBに構成やコンテナの状態が全て保存されている。 UserProxyとComputeがリクエストに基いてCoreAPI経由でCMDBから状態を取得・変更し構成を変化させる。 Computeは複数台でDataPoolをNFSで共有し、コンテナをHTTPリクエストからリアクティブに起動する。

実験環境は以下の通り。

f:id:matsumoto_r:20171220002454p:plain

実験方法

FastContainerアーキテクチャの有効性を確認するために、FastContainerを用いたプロトタイプ環境を構築し、コンテナのスケール処理を評価した。 実験環境の各ロールのNICとOSは全て、NICは1Gbps、OSはUbuntu 14.04 Kernel4.4.0を利用した。 実験では、UserProxyからComputeで起動しているコンテナに対してベンチマークを行う。コンテナのデータはDataPool上に保存し、ComputeからDataPoolに対してNFSマウントする。 コンテナ上には、Apache2.4.10を1プロセスで起動させた上でPHP5.6.30をインストールし、PHPの環境情報を取得するphpinfo()関数を実行するだけのコンテンツを動作させる。 また、コンテナの最大CPU使用量は、cgroupの機能により1コアの30%に制限し、その設定のもと予備実験からCPUを30%使い切ることのできるベンチマークの設定を同時接続数100、総リクエスト数を10万に決定した。ベンチマークにはabコマンドを利用した。 本実験では、コンテナの負荷に応じてコンテナ追加を、起動済みのコンテナが自身でCoreAPIを介してスケール処理を実施する処理は未実装であるため、コンテナ追加のためのCoreAPIへのリクエストは手動で実施した。

ベンチマークでは、1秒間のレスポンスタイムの平均値を時系列データとして作成しグラフ化した。 続いて、同様のベンチマークを実施し、処理リクエスト数が5万を超えた段階で、スケールアウト型とスケールアップ型それぞれの負荷対応を実施し、即時スケール処理が実施され、レスポンスタイムが短くなるかどうかを確認した。

実験結果

スケールアウト型

スケールアウト型の実験結果を示す。

f:id:matsumoto_r:20171219220252p:plain

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

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

スケールアップ型

スケールアップ型の実験結果を示す。

f:id:matsumoto_r:20171219220323p:plain

1 containerは、スケール処理を何もしない場合のグラフであり、横軸300秒あたりから下降し始めている1 container CPU30%to60%のグラフは、5万リクエストに到達した横軸301秒の時点で、Haconiwaによって即時CPUの最大使用率を60%までに引き上げた場合のレスポンスタイムの遷移を示している。 このグラフからも、リクエスト処理が5万リクエストまで到達した横軸301秒の時点から、大きなレスポンスタイムの遅延やレスポンス処理の失敗などなく、即時スケールアップ処理が行えていることが分かる。 具体的な数値としては、301秒時点でオートスケールアップを発生させ、302秒からレスポンスタイムが700msecから574msecと下降が始まり、304秒の時点で358msecとなり、以降は350msec前後に安定した。 オートスケールアウトよりも、オートスケールアップが即時レスポンスタイムへの影響があった理由としては、新たなコンテナを起動させてリクエストの振り分けに追加するスケールアウトに対して、直接稼働中のコンテナのリソースを増強できるからだと考えられる。

まとめ

本研究では、Webホスティングサービスにおいて、サービス利用者に専門的な知識を要求することなく、アクセス集中時には、HTTPリクエスト単位で迅速にコンテナで構成されたユーザ環境がオートスケールできる、コンテナ管理アーキテクチャのFastContainerを提案した。 FastContainerアーキテクチャでは、HTTPリクエスト毎に、コンテナ上のWebアプリケーションの起動、起動継続時間、起動数およびリソース割り当てをリアクティブに決定する。 これによって、Webアプリケーションの負荷や性能劣化をリクエスト単位で検知し、オートスケールまでの処理を大幅に短縮して、迅速にオートスケールが可能となる。 また、コンテナが一定期間で破棄されることによりリソース効率を高め、ライブラリが更新された場合には新しい状態へ更新される頻度も高くなる。

要点としては、

  • オートスケールの処理コストとリソース効率化の課題に着目
  • 不変性を伴う基盤のセキュリティと運用技術の課題に着目
  • インスタンスが循環し変化に強い仮想化基盤技術の提案
  • ロリポップ！マネージドクラウドとしてサービスもリリース
    • 本アーキテクチャと自作コンテナエンジンを実装して実現

が挙げられる。

今後の課題

リソース効率化の実証実験

今後の課題として、

  • 恒常性によるリソース効率化を九州大学と共同でNIIクラウドにおいて実証実験中
    • 不要な時は停止したり循環することによって、そうでない場合と比べどの程度リソース効率化されるかを定量評価

のように、どの程度リソースが効率化されているかを実証実験で検証していく。

サービスレベルとライフタイムや起動時間との関係性の定義

  • サービスとして実装し実運用上の効果を測定中
  • 初回起動時間と起動継続時間とアクセス数の関係を考察
    • ユーザ体験を損なわない起動継続時間（ライフタイム）の適応的決定が可能か
      • サービスレベルに基いて、起動時間とライフタイムと秒間アクセス数の関係から最適な関係式を定義したい

ここでのサービスレベルを考える上では、起動時間の影響、ライフタイムの時間、秒間アクセス数、サービスレベルを関係式に落とし込む必要がある。例えば、これぐらいのアクセス数であれば、起動時間に数秒かかっても、ライフタイムの時間絡みた時にはほとんど無視できる、というサービスレベルの話を論理的に導けるようにすべきである。同時に、この関係式が定義できれば、アクセス数に応じて適応的にライフタイムを設定することも可能であるだろう。また、サービス・プロバイダ側は起動時間にかかる許容時間も設定できるだろう。

コンテナの起動時間の影響を減らす取り組み

起動時間の影響を減らすアプローチとして、

  1. プロセスのサスペンドなどによるプロセスのダンプリストア
  2. プロセスの事前起動から切り替えによる循環（サイクルモデル）

があり得る。1. については、

  • CRIUによりコンテナ内のアプリをイメージ化して高速起動
  • レジデントモデルのように料金を多く頂くが最低ひとつのコンテナは常に起動させておく
    • 仕組みは非常にシンプル
    • いずれにせよモータルモデルと比較してコンテナが0にならないので、リソース効率は比較的低い

次に、2. については、

  • 事前に起動させてリクエストの振り分けを新しいコンテナに向ける
    • 仕組みは複雑
    • コンテナ視点では循環するのでメモリリークやプロセスの起動し続けることによる課題は生じない

スケーリングすべき状況の迅速な検知または誤検知の扱い

一般的な仮想化基盤のオートスケールの課題の3つ目であるスケーリングすべき状況検知のリアルタイム性の低さも対応していく。

  • データ収集自体は数十秒単位
  • スケーリングのトリガー検知は最大1分必要
  • 誤検知を減らしながら素早くスケーリングを検知できるか
    • スケールアウト・インが無駄に頻発しないようなルール設計
      • コンテナだから逆に頻発しても良いのかも？NIクラウド実証実験で評価したい
    • オンラインに適した変化点検出のような統計的手法にも帰着

これをうまくやるためには、

  • ルールベースの設定
  • 全体の需要予測
  • 直近のリアルタイム性の高い変化点検出（changefinderなど）
  • それぞれのパラメータや閾値設定をいかに適応的に行うか

この4つの観点を、プロダクトの課題や基盤の仕様に合わせてうまく組み合わせながら検討していくのが良いだろう。

wsa研の研究発表の中でも、iPhoneの加速度センサーなどからSVMによって、行動（歩く、走る、階段など）を予測する手法が提案されていたが、そのリアルタイム性が数秒で、センサーデータ数も100ms程度の粒度で非線形または非定常なデータを高い精度で予測できていたことから、それをコンテナのリソース使用量やアクセス頻度に基づいて突発的な負荷やアクセスに対してスケーリングを予測することも十分できそうである。これらの方法論が定まってきたら、リクエストを予測して投機的にコンテナを起動させることも可能になるだろう。そうすれば、FastContainerの起動時間の問題も低減できそうである。

また、FastContainerは状態の遷移をいかに効率化するかに着目したシステムアーキテクチャであるため、そもそも誤検知によってコンテナのスケールアウトやスケールインが短時間で頻発したとしても、システム全体としては許容できるのではないかという観点もある。これまでのWebアプリケーションの常識として、そうした誤検知やプロセスが生き続ける状態を正としてきたが、そういったエラーを許容するシステムとして改善していく方針もあり得るだろう。

スライド

speakerdeck.com

参考文献

  1. Amazon Web Services, https://aws.amazon.com/.
  2. Amazon Web Services: Auto Scaling, https://aws.amazon.com/autoscaling/.
  3. Che J, Shi C, Yu Y, Lin W, A Synthetical Performance Evaluation of Openvz, Xen and KVM, IEEE Asia Pacific Services Computing Conference (APSCC), pp. 587-594, December 2010.
  4. Brown Mark R, FastCGI: A high-performance gateway interface, Fifth International World Wide Web Conference. Vol. 6. 1996.
  5. 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.
  6. 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.
  7. LXC, https://linuxcontainers.org/.
  8. rkt: A security-minded, standards-based container engine, https://coreos.com/rkt/.
  9. Docker, Inc., Docker: Build, Ship, and Run Any App, Anywhere, https://www.docker.com/.
  10. Open Container Project, The Open Container Initiative, https://www.opencontainers.org/.
  11. The Kubernetes Authors, Introducing Container Runtime Interface (CRI) in Kubernetes, http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html.
  12. Mesosphere, Inc., Marathon: A container orchestration platform for Mesos and DC/OS, https://mesosphere.github.io/marathon/.
  13. M Roberts, Serverless Architectures, https://martinfowler.com/articles/serverless.html.
  14. Mietzner R, Metzger A, Leymann F, Pohl K, Variability Modeling to Support Customization and Deployment of Multi-tenant-aware Software as a Service Applications, the 2009 ICSE Workshop on Principles of Engineering Service Oriented Systems, pp. 18-25, May 2009.
  15. 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.
  16. 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.
  17. Rosen R, Resource Management: Linux Kernel Namespaces and cgroups, Haifux, May 2013.
  18. 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.
  19. Soltesz S, Pötzl H, Fiuczynski M E, Bavier A, Peterson L, Container-based Operating System Virtualization: A Scalable, High-performance Alternative to Hypervisors, ACM SIGOPS Operating Systems Review, Vol. 41, No. 3, pp. 275-287, March 2007.
  20. The Kubernetes Authors, kubernetes: Production-Grade Container Orchestration, https://kubernetes.io/.
  21. 近藤宇智朗, 変拍子パワーポップ系コンテナ、Haconiwa /the-alternative-container, https://speakerdeck.com/udzura/the-alternative-container.
  22. 松本亮介, 川原将司, 松岡輝夫, 大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善, 情報処理学会論文誌, Vol.54, No.3, pp.1077-1086, 2013年3月.
  23. 松本亮介, 田平 康朗, 山下 和彦, 栗林 健太郎, 特徴量抽出と変化点検出に基づくWebサーバの高集積マルチテナント方式におけるリソースの自律制御アーキテクチャ, 情報処理学会研究報告インターネットと運用技術（IOT）,2017-IOT-36(26), 1-8, (2017-02-24).
  24. 松本亮介、岡部寿男, リクエスト単位で仮想的にコンピュータリソースを分離するWebサーバのリソース制御アーキテクチャ, 情報処理学会研究報告 Vol.2013-IOT-23, No.4, 2013年9月.
  25. 松本亮介, 近藤宇智朗, 三宅悠介, 力武健次, 栗林健太郎, FastContainer: 実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャ, インターネットと運用技術シンポジウム2017論文集，2017，89-97（2017-11-30）, 2017年12月.
  26. 松本亮介, 小田 知央, 笠原 義晃, 嶋吉 隆夫, 岡村 耕二, 精緻に解析可能な恒常性のあるメール基盤の設計, 2017年 CKP-QGPOP合同研究会, 2017年12月.