このエントリは、第四回 Web System Architecture 研究会 (WSA研)の予稿です。

はじめに

Webサービスの運用において，急激なアクセス頻度の上昇に対する安定性を保つため，Webアプリケーションにスケーラビリティの仕組みが一般的に求められるようになった． これを支援するためにWebアプリケーションを稼働させるクラウドサービスやオーケストレーションツールから，オートスケーリング機能が提供されている． しかしながら，機能を利用するためのスケーリング契機となる指標や基準値は，運用するWebサービスの特性を考慮して個別に決定する必要がある． ホスティングサービスのように個々の運用対象に対する特性が不明かつ多様な環境においては，Webサービスの特性に依存しない汎用的なスケーリング戦略を備えた機構を 横断的に適用できることが，運用効率化並びに運用対象全体での安定化のために重要である．

Webサービスの特性に依存しない汎用的なスケーリング戦略のためには，汎用的な指標や基準値が必要である．

Webアプリケーションにおけるアプリケーションサーバは通常，複数のロールのサーバに処理を依頼し，これを統合してリクエストを返すことから， CPUやメモリといった単一サーバにおけるプリミティブな指標からはその負荷状態を表すことが難しい． 三宅らは仮想サーバの予測的オートスケーリングにおいて， アプリケーションの処理内容ではなく運用経験から得られたサーバ単位のスループットを指標として，これを予測するモデルによってサーバ台数調整機能を実現した．

一方で基準となる値は運用経験から得られたものであり，運用対象に対する特性が不明な環境では用いることができない． そこで，この特性を明らかにするために，「全自動パラメータチューニングさん」のような探索的なアプローチ， または，予測的なアプローチが採用される． しかしながら，ホスティングのような環境では学習データの蓄積を含め，負荷の発生しうる操作の実施には慎重にならざるを得ない． クラウドサービスやオーケストレーションツールで利用可能な指標の基準値はCPU使用率や秒間クエリ数，コネクション数などシステムが許容可能とみなせる値であり，これらを導くための負荷検証も同様である．

三宅はKaburaya: CPU負荷に応じて継続的に上限値を最適化する動的セマフォにおいて， 最適な並行数を継続的に求めるために処理対象の負荷の均衡点を目標とする方式を提案した． この方式では，目標値を動的に変更しフィードバック制御を用いることで，並行数が増えすぎないようにすることができるためオートスケール機能への転用も可能であると述べた． しかしながら，CLIツールを対象とした実装のため，目標値をCPU使用率と定めたこと，一定の負荷が継続的に発生することを前提としたことから，目標値への追従のため継続的に負荷が発生する．

Webサービスの特性に依存しない汎用的なスケーリング戦略のためには，汎用的な指標として外形的な指標を用いながら，特性に依存しない基準値をWebサービスへの負担なく求めたい． 本研究では，アクセス負荷に応じて継続的にスケーリング基準を最適化する汎用オートスケーリング機構を提案する． 実装には，Kaburayaのうち，ダイナミックターゲットコントローラの仕組みをCPU負荷ではなくWebサービスのレスポンスタイムに対して適用する． すなわち，直近のレスポンスタイムが均衡する点に収束するような台数調整が行う． なお，算出する理想台数と実際に追加する台数は分離可能とすることで，ホストのコンピューティングリソースの限界を加味した運用が可能となる．

評価

本報告では，提案手法を算出エンジンに用いたシミュレーション環境で評価する．

シミュレーションは，同時アクセス数によってレスポンスタイムが変化するサーバーによって，水平スケーリングがリニアに有効な状況と 同様の傾向を持つ後段サーバーへのアクセスによるボトルネックが発生し，水平スケーリングがリニアには有効とならない状況を用意した． これらの環境において，単純なPID制御と比較して，提案手法が前提とする環境において有効であることを示す．

シミュレーション環境

同時アクセス数によってレスポンスタイムが変化するサーバーは以下のようにモデル化した．

$exp(c/el)-1+r$

ここで，cは同時アクセス数，rは最小レスポンスタイムである． elは伸長用の定数であり，これが大きければ同時アクセス数の増加に対してレスポンスタイムの増加が繰り延べされる．前段は100，後段は300とした． なお，後段は水平スケーリングが行われず，前段からのアクセス数の合計が後段に対するアクセス数となり，レスポンスタイムはこれを合算したものとする．

それぞれのシミュレーション環境の最低な台数とレスポンスタイムを示す．

水平スケーリングがリニアに有効な場合

PID制御と提案手法の比較を示す． PID制御は最小レスポンスタイムを平常時の運用において把握したとする． なお，提案手法では内部にPID制御を用いるが，最適値を動的に求めるため最小レスポンスタイムの把握は不要である．

レスポンスタイムとスケーリングの台数が単純な関係である場合，実装は簡単である． PID制御は最小レスポンスタイムさえ取得できれば綺麗な適応をする． 一方で提案手法は下げ幅が不足して供給過剰な状態が発生した． これは目標値の変更を止めるための判定が早期に行われたためであり，間接的には変化率を直前との比較でしか行なっていないことが理由となる． 実運用では，この期間を延伸，さらには移動平均のような形で平滑化してこの精度を向上させる必要がある．

ボトルネックがある場合

PID制御と提案手法の比較を示す． 最小レスポンスタイムに関する注釈は上記と同じである．

このシミュレーションではボトルネックに達したことでPID制御によるスケーリングが最小レスポンスに到達しないことで永遠に台数を追加している． 実際にはシステムに最大上限が設けられるが，その最適な上限値についてもWebサービスの特性に依存することから容易に決定することはできない． 一方，提案システムでは，これらの情報を知らずとも目標値の修正によってこれに対処する． 下げ幅の不足については上記と同じ方法での解決が見込める．

発表スライド

発表を終えて

今回の発表は前回のアイディアであるKaburayaの具体的な適用箇所を想定したものとした． 個人的な最近の一番の変化だと思っているのが，長期間付き合えるアイディアが出てくるようになったことだ． 長期間付き合えるというのは，1. ビジョンがあって長期間かけてそれらを実現していくもの，2. 汎用的なアイディアがあってそれらの適用先を広げていくもの，の2つがあると思う． 1.については，研究テーマであるなめらかなマッチングに対して一歩づつ進めており，2.についてはWSA研を始めとした個人の興味発のプロダクトがそのようになっている． 特に研究に携わるまでの個人の興味発のプロダクトはたくさんOSSとして公開していたものの，その場限りのもも多く，実際の適用や発展が少なかったように思う． Kaburayaを始めとする最近のプロダクトでは，なるべく実装から切り離して目的，妥当性，そして背景を整理しながらアーキテクチャ，機構，システムとしての骨組みを整え，自分なりにその本質に迫るようになった． そして，どのような評価をすればこれらの有効性を示せるかを踏まえた上で実装をする． これはまさに研究の論文的アプローチであり，これから生まれたプロダクトは以前と比べて芯があり発展性が増してきたように思える． 実際にKaburayaは，WSA研#3での発表を皮切りに東京のGoConで発表し今年サンディエゴであるGopherConにも採択された．そして今回のWSA#4ではオートスケーリングへの転用の可能性も示せた．

周りを見れば具体と抽象を自在に素早く行き来し，自由闊達かつ高度な意見を交わす人々ばかりで自信を失いかけるけれども，己だけを見た時には多少の成長も感じられるようにはなったと思う． 研究職になってレベルが0になった時期もあったけれども，エンジニアとしての具体化能力との相乗効果が出せるようにこれからも精進して行きたい．

普段の研究から少し離れながらも研究的なアプローチを進めることができているのはWSA研によるところも大きい． 予稿をブログで書いておけばあとは当日の議論がメインであり，色々な観点からアイディアを練ることができる．このスピード感と濃密感は，エンジニア向けのカンファレンスと学会のいいとこ取りになっている． 定期的にあるところも大変良くて，強制的にアイディアが形になり，進んでいく．

総じて第四回もとても良い会であった．興味がある方は9月福岡で開催の第五回への参加を検討してみてはいかがだろうか．