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

はじめに

Webサービスの運用において，急激なアクセス頻度の上昇に対する安定性を保つため，Webアプリケーションにスケーラビリティの仕組みが一般的に求められるようになった． これを支援するためにWebアプリケーションを稼働させるクラウドサービスやオーケストレーションツールから，オートスケーリング機能が提供されている． これらのオートスケーリング機能では，開発運用者が予め定めた条件を元にWebアプリケーションの状況が監視される． そうして，条件を満たせば，開発運用者が予め定めたスケール方法とその実施量に従いWebアプリケーションをスケールさせる．

このようにオートスケーリングによって，ユーザからのリクエスト数の増減に応じて最適なサーバ台数を調整されることで利用者の快適さと情報システムの運用コストを両立できるようになった． 一方で，オートスケーリングを導入し，継続的に安定した運用するためには開発運用者の運用努力が必要であるが，これらは管理する環境の増加に従い困難になる． そのため，多環境での運用性を考慮した自動化可能なオートスケーリング戦略が求められる．

オートスケーリングの継続的に安定した運用に向けた課題は大きく二つある． 一つ目は，アプリケーション特性の把握，二つ目は，“遅れ”の考慮である．

課題1: アプリケーション特性の把握

スケールにはWebアプリケーションを稼働する仮想サーバへリソースを追加する垂直スケール（スケールアップ），稼働する仮想サーバを追加する水平スケール（スケールアウト）の2種類の方法がある． しかしながら，どちらの方法を用いるにせよ，開発運用者はWebアプリケーションの特性に応じたオートスケーリングの条件やその実施量を予め定める必要がある． 例えば，時刻ベースであればアクセス頻度の時系列的傾向や，リソース変動ベースであればボトルネックとなるメトリクスである． また，これらの条件に対する必要台数の算出も必要となる． Webアプリケーションは常に変更が加わることから，手動での継続的な特性の把握と決定は運用負荷の面で現実的ではない．

そこで，特性把握の自動化が行われている． 三宅らは，過去のアクセス頻度のデータからLSTMを用いて24時間先までの1時間単位のアクセス頻度を予測するモデルを構築し，予測アクセス頻度を元に経験から得られたサーバ単位のスループットにより必要なサーバ台数を求めた[1]． スループットの把握では，パラメタを連続的に変化させながら最良の結果を得る値を探索的に求める方法も提案されている[2]． これらの予測的，探索的なアプローチによる特性把握の自動化により，変化する環境に対する追従性は向上する． 一方で，事前的なアプローチであるため，予測の誤差，探索を行った環境と本番環境の誤差に対処できないという課題が残る．

そのため，三宅らはフィードバック制御による個別の特性把握を必要としないアプローチ[3][4]を提案した． この手法では，直近のレスポンスタイムが均衡する点に収束するような台数調整によって特性把握が不要で実行時に誤差を修正することができる． ただし，フィードバック制御を用いるため，制御量であるサーバ台数の決定は探索的である． 待ち行列理論によれば窓口利用率が1を超えると待ち行列は収束しないとされていることから，サーバ台数は即時かつ決定的に求められることが望ましい．

課題2: “遅れ”の考慮

オートスケーリングでは，本番環境の誤差に対応するための即応的なアプローチを採用すると"遅れ"の課題が発生する． 一つ目の遅れは，負荷上昇からサーバ台数を見積もるまでの時間差である． 本稿ではこれを「入力の遅れ」と呼ぶ． 次はサーバ台数の変更指示から起動までの時間差である． 本稿ではこれを「出力の遅れ」と呼ぶ． 待ち行列理論によれば窓口利用率が1を超えると待ち行列は収束しないとされていることから，これらの遅れに対して発生した待ちリクエストが系の安定性を崩す． 安定性の低下は開発運用者による不定期な対応を要請し，運用負荷につながることからこれを回避する必要がある．

そのために，遅れを最小化する手法が適用される． 入力の遅れでは，変化点検出などにより負荷上昇を即時に察知する方式がある． また，出力の遅れではCRIUを利用することで起動までの時間を短縮する方式[5]がある． しかしながら，精度の観点やシステム制約によって遅れを0にはできないため，遅れそのものに対する対策は必要となる．

遅れを踏まえた準備では，前述の予測的なアプローチが考えられる． 三宅らの手法[1]では，予測と事前起動によりこれらの遅れを考慮するが，本番環境の誤差への課題が残る． そこで，スミスの予測法[6]のようにフィードバック制御において遅れによる影響を踏まえた制御量を算出する手法がある． 一方で，予測のためには精度の高い予測モデルの構築が必要であり，追従にはここの自動化が必須となる．

提案手法

多環境での運用性を考慮したアプリケーション特性の把握の自動化と安定性の両立のためには，以下の要件が必要となる．

1. Webアプリケーション特性として負荷に対する実施量の関係が把握できる
2. これを不必要な負荷をかけることなく実行時に自動で把握できる
3. 把握したWebアプリケーション特性と実環境に誤差が生じた場合に修正できる
4. これを実現するリアクティブなアプローチで発生する”遅れ”へ対処できる

そこで，フィードフォワード制御を中心とし，実環境の特性把握・追従のためにフィードバック制御を組み込んだ2自由度のオートスケーリング制御系を提案する． 提案手法により，特性把握・追従の自動化ならびに待ち行列理論を用いた決定的な台数算出・遅れ補償による安定化が見込める． なお，本提案手法の実装はKaburaya AutoScalerとして，OSSでの公開・開発を続けている．

• monochromegane/kaburaya-autoscaler

提案手法では，Webアプリケーション特性を求めるにあたって低負荷時では理想的なレスポンスタイム，高負荷時ではスループット限界を用いることで対象のWebアプリケーションに不必要な負荷をかけることなく現状に即したWebアプリケーション特性を把握することができる． また，仮想サーバ起動までの遅れに伴う負荷状況を予測し，これを見越した実施量を見積もる遅れ補償機構を設けた．

提案手法のアーキテクチャを以下に示す．

ここで$F$はフィードフォワード制御部である． 現状の負荷状況に応じて実施量であるサーバ台数を算出する． 算出には待ち行列理論の窓口利用率を求める式を変形した$\lambda/\rho\mu$を用いる． なお，$\lambda$は平均到着率（req/単位時間），$\mu$は平均サービス率（req/単位時間），$\rho$は窓口利用率を表す． 提案手法では$\rho$には0より大きく1未満の任意の値を設定することができる．

$P$はプラントであり，$F$で求めたサーバ台数を用いて実際にWebサービスを運用する実環境である． 提案手法では実環境の計測誤差をフィードバックすることで自動かつ継続的な安定性を保つ． $P$は計測結果として単位時間での平均レスポンスタイムである$T_s$と単位時間での1台あたりの処理数である$\mu$を返却する． これらの値は，$F$における新しい$\mu$に用いられる．

提案手法では仮想サーバ起動までの遅れに伴う負荷状況を予測し，これを見越した実施量を見積もる遅れ補償機構を設けた． 待ち行列理論では無限時間の平均した待ち時間を求めるため，窓口利用率が1以上の場合に発散し，理論を適用することができない． 一方で，遅れ時間は有限であることから，窓口利用率が1以上の場合であっても待ち行列の長さを求めることができると考えた． そこで$(\lambda^{t-1}-s^{t-1}\mu^{t-1})\gamma$のように不足処理能力による待ち行列の長さとて加えて，これを捌くことができるサーバ台数を求めている．

評価

プラントのシミュレータを使って提案手法によるオートスケーリングの自律・適応の性能を評価した．

右下のグラフにより$\mu$の推定・追従が行えていること，左上のグラフにより遅れ補償が働きアクセス増加時に一時的に多いサーバを投入することで収束できていることが確認できる． 個別の評価についてはスライドを参照されたい．

発表スライド

まとめ

本研究会ではオートスケーリングと開発運用者間の関係をなめらかにするための多環境での運用を考慮した自律適応型オートスケーリング制御系を提案した． 評価ではM/M/Sモデルを前提としたプラントシミュレータによってこれらが達成可能なことを示した． 実用化に向けて今後はプラントに実際のWebサーバ/アプリケーションサーバを適用した評価や実際の到着，サービス時間間隔に近い分布での評価が必要である． また，提案手法では入力の遅れに伴い単位時間内に待ちリクエストが必ず発生するため変化点検出などで遅れ時間自体を短縮する方式も検討したい．

発表を終えて

今回のWSA研究会もとても面白かった． Webシステムアーキテクチャという題材で色々な分野の人が集まって議論することで持ち寄ったアイディアが前進して行くのを何度も見ている． 自分自身の取り組みも研究としてWSA#3からWSA#4を通してGopherConで登壇できるぐらいに育った． 加えて，今回は，オートスケーリングの課題に着目して新しいアプローチを試してみる中で，制御工学や待ち行列理論などを学び楽しめた． このような普段の研究から少し離れた取り組みであっても，定期的に発表を促されることで形にすることができるのはとても大切で，やりっぱなし学びっぱなしではなく一つの区切りまで考え実装することで次回以降の研究への糧となる． Webシステムアーキテクチャに関する運用知見を研究的アプローチで前進させること興味がある方は次回開催の参加を検討してみてはいかがでしょうか．

• Web System Architecture研究会の発足と挨拶
• 研究会の目的

リファレンス

• [1]: 三宅 悠介, 松本 亮介, 力武 健次, 栗林 健太郎, アクセス頻度予測に基づく仮想サーバの計画的オートスケーリング, FIT 2018 第17回情報科学技術フォーラム, CL-002, Sep 2018.
• [2]: 全自動パラメータチューニングさん https://blog.mirakui.com/entry/2013/02/20/003401
• [3]: Yusuke Miyake, Optimization for Number of goroutines Using Feedback Control, GopherCon Marriott Marquis San Diego Marina, California, July 2019.
• [4]: 三宅 悠介, Ebira: アクセス負荷に応じて継続的にスケーリング基準を最適化する汎用オートスケーリング機構, 第四回 Webシステムアーキテクチャ研究会, 2019年4月.
• [5]: 松本 亮介, 近藤 宇智朗, CRIUを利用したHTTPリクエスト単位でコンテナを再配置できる低コストで高速なスケジューリング手法, 研究報告インターネットと運用技術（IOT）, Vol.2019-IOT-44, pp.1-8, Feb 2019.
• [6]: O. Smith, “Closer control of loops with dead time”, Chemical engineering progress, Vol. 53, No. 5, pp. 217-219, 1957.