# Dynamically Scaling Applications in the Cloud > [!abstract] 概要 > スケーラビリティはクラウドのパラダイムがもたらす主要な利点の一つであり、とりわけ、クラウドを「高度なアウトソーシング」の解決策から区別する利点だと言われる。しかし、アプリケーションの自動スケーリングという夢を実現するには、重要な未解決の課題がいくつか残っている。本稿では、クラウド環境におけるアプリケーション全体のスケーラビリティに向けた、最も注目すべき取り組みを紹介する。最先端技術の縁にある関連の成果を示し、それぞれが辿る傾向の包括的な概観を与える。また、今後の新たな研究で取り組まれるであろう未解決の課題を明らかにし、理想的なスケーラブルなクラウドシステムを提示する。 ## 論文情報 - タイトル: Dynamically Scaling Applications in the Cloud - 著者: [[Luis M. Vaquero]]([[Hewlett Packard Labs]] ブリストル)、[[Luis Rodero-Merino]]([[INRIA]] LIP ENS Lyon、Graal/Avalon グループ)、[[Rajkumar Buyya]]([[The University of Melbourne]]) - 媒体: ACM SIGCOMM Computer Communication Review, Vol. 41, No. 1(2011 年 1 月号、pp. 45-52) - 分類: ACM C.4(システムの性能: 信頼性・可用性・保守性、設計研究)。キーワードは Cloud Computing, Scalability - 免責: 本稿の意見は HP Labs と INRIA の見解を表さないと末尾に明記されている。 ## 概要 クラウドアプリケーションを自動的に拡縮するための既存の仕組みを、サーバ・ネットワーク・プラットフォームの 3 階層に分けて概観する 8 ページのサーベイ(編集者宛ての覚書に近い短報)である。実験や評価はなく、既存の研究・製品を分類した表(Table 1、表1)と、理想的なスケーラブルなクラウドが備えるべき要素の列挙が成果物である。2010 年ごろ(参考文献の閲覧日は 2010 年 5〜8 月)の状況に基づく。 ## 問題設定 - 自動スケーリングの規則は、条件と、条件成立時に起動するインフラ・プラットフォーム上の動作から成る。多くの商用サービスは CPU やメモリなど固定的なインフラの指標に基づく単純な条件だけを許し、動作も水平スケール(VM とロードバランサの追加)が中心である。 - 一般的な OS は、再起動なしの CPU・メモリの動的な変更に対応せず、垂直スケールは難しい。より強力なサーバへの置き換えで代替する試みがある。 - VM の追加だけでは足りず、ロードバランサ(LB)自身のスケール、共有ネットワークの帯域、プラットフォーム層(コンテナとデータベース)まで含めて初めてアプリケーション全体のスケーラビリティが成立する。著者らはこれらを「全体論的(holistic)なアプリケーションのスケーラビリティ」と呼ぶ。 - アプリケーション提供者は多数の VM を個別に監視して判断する負担を避け、アプリケーション単位で扱いたい。これに対し、抽象度の高い API か、より高い自動化の程度のどちらかが必要になる。 ## 提案手法 手法は提案ではなく、文献の整理と分類である。 1. **全体像(Figure 1、図1)**: スケーリングを IaaS(水平: VM 複製とネットワークのスケーラビリティ、垂直: VM のライブ再サイジングと VM の置き換え)と PaaS(コンテナ複製・データベース複製)に分ける。VM 複製にはロードバランシングアルゴリズムと LB のスケーラビリティが、ネットワークにはネットワークスライシングと動的な帯域割り当てが、PaaS の複製にはロードバランシングとデータ複製が付随する。 ![[wiki/sources/_attachments/2011__SIGCOMM__Dynamically-Scaling-Applications-in-the-Cloud/fig01-holistic-scalability-mechanisms.png]] 2. **サーバ層(§2)**: 弾力性コントローラの実装は、ティアごとのコントローラ(調整と同期が要る。ボトルネックがティア間で移り得るため、他ティアがインターロックを保持しない間だけ資源を解放する案がある)と、アプリケーション全体で 1 つのコントローラ(例: Web 層への着信数が閾値を超えたらロジック層をスケールする)に分けられる。古典的な制御理論に沿い、センサがコントローラへ計測値を渡し、コントローラがクラウド API(アクチュエータ)を操作する(Figure 2、図2)。 ![[wiki/sources/_attachments/2011__SIGCOMM__Dynamically-Scaling-Applications-in-the-Cloud/fig02-elasticity-control-loop.png]] 規則は「条件(指標と修飾子の組を 1 つ以上)が成立したら動作(IaaS が対応する動作、例: VM のデプロイ)を実行する」という形で表す。条件には「利用可能な予算」「承認の受領」のような事象も使える。Lim らは、ストレージの複製のしきい値だけを利用者が設定する数式化を提案し、Rodero-Merino らは Open Virtual Format(OVF)を拡張してアプリケーション・コンポーネント・スケーリング規則を記述し、規則エンジンをコントローラとして使う。 3. **LB(§2 後半)**: LB のスケーラビリティは、少負荷では転送時間が無視でき、大負荷・多数 VM で O(p)(p は負荷分散される VM 数)を超えて増えないことと定義される。[[Amazon Web Services]] の Elastic Load Balancer は LB 自身をスケールする仕組みを持たない。Liu と Wee の経験則として、CPU 集約型は LB で分割し、ネットワーク集約型は強力な単独インスタンスを使い、さらにネットワーク負荷が高い場合は DNS ロードバランシングを使うとされる。 4. **ネットワーク層(§3)**: 仮想化されたネットワークは VLAN タグや L2/L3 オーバーレイで利用者のトラフィックを分離する。ただし分離だけでは統合データセンターの帯域増加に対応できず、過剰プロビジョニングは高価で静的である。Baldine らは、VM と帯域を保証したネットワーク資源を複数のクラウド事業者にまたがって同時にインスタンス化し、Network Description Language(NDL)ベースのオントロジで記述する。これらの発想は「サービスとしてのネットワーク(Network as a Service, NaaS)」と呼ばれ、フロー制御・分散レートリミット・ネットワークスライシングで支えられる。実際の割り当て帯域は統計的多重化で決める。 5. **プラットフォーム層(§4、Figure 3・Figure 4、図3・図4)**: PaaS の 2 つの主要層であるコンテナとデータベースを水平複製でスケールする構成を扱う。垂直スケールは 1 台で捌けない負荷の前で頭打ちになるとして採らない。 ![[wiki/sources/_attachments/2011__SIGCOMM__Dynamically-Scaling-Applications-in-the-Cloud/fig03-paas-architecture.png]] Figure 3(図3)は、LB が複数のコンテナへ要求を振り、各コンテナ内のユーザコンポーネントがデータベースサービス API とキャッシュサービス API を使い、その先に分散キャッシュ、データベースのアクセス・複製ミドルウェア、複数の DBMS が並ぶ構成を示す。コンテナは、マルチテナント(強い隔離が必要。標準の Java にはセキュリティ上の制約がある)か、利用者ごとに専用(GAE の方式)かを選ぶ。プラットフォーム自身がコンテナを自動で増減するのが望ましく、[[Google App Engine]] のオープンソース版 AppEngine と Aneka はこの方式である。コンポーネントは可能な限りステートレスにし、ステートフルにする場合は LB とコンテナ管理がセッションの所在を知る必要がある。セッション状態の複製にはソフトステート複製(Tempest、SSM)や [[memcached]] のような分散キャッシュを使う。 データベースには分散キャッシュ、NoSQL、データベースクラスタリングを組み合わせる。NoSQL(例: [[BigTable]]、その OSS 実装 HBase)は高い可用性とスケーラビリティを得る代わりに、複製が最終的一貫性で、完全な ACID トランザクションと完全な SQL を諦める。完全な関係データベース([[Microsoft Azure]] など)をクラスタ化する場合は、全ノードが各データの複製を持つ必要があり、トランザクション下では中程度の負荷でも性能が落ちる。ミドルウェア型の複製(C-JDBC、Middle-R、DBFarm)は、クライアントのプロキシドライバから複製ミドルウェアへ要求を流して全コピーを更新する。 ![[wiki/sources/_attachments/2011__SIGCOMM__Dynamically-Scaling-Applications-in-the-Cloud/fig04-paas-data-replication.png]] Figure 4(図4)は、コンポーネント複製間のショッピングカートの状態を更新で伝播させる必要があること、データベースのトランザクションが全複製上の関連データを保護(ロック)するため、競合するトランザクションが遅延または中断されることを描く。 ## 新規性 - クラウドのスケーラビリティを、サーバ・ネットワーク・プラットフォームの全階層にまたがる「全体論的」な問題として 1 つの枠で整理した点。VM 単位の自動スケーリングだけでなく、LB の自己スケーリング、NaaS、PaaS の状態・DB 複製までを同じ地図に載せた。 - 「弾力性コントローラ」を、センサ・コントローラ・アクチュエータの制御ループと、条件・動作から成る規則という形式で一般化し、既存システムをそこへ位置付けた点。 - 現状を踏まえた「理想的なスケーラブルなクラウド」の要件を IaaS(VM 複製、その場での再構成、自己スケールする LB)、ネットワーク、PaaS(コンポーネントの自動増減とセッション複製、ACID 対応の DB と一貫性維持のコストの均衡)に分けて明示した点。 ## 実験設定 実験はない。調査の範囲は、当時の商用 IaaS(RightScale、vCloud、Sun Cloud、GoGrid、Amazon)と、学術的な弾力性コントローラ(Lim ら、Rodero-Merino ら、Buyya ら、Marshall ら)、ネットワーク資源の研究、AppScale・Aneka などの PaaS 実装である。LB のアルゴリズムそのものと、PaaS のバス・アクセス制御などの周辺サービスは、範囲外だと断っている。 ## 実験結果 定量的な結果はない。成果物である表1(各階層の既存の取り組み)は次のとおり要約できる。 - **サーバ層**: 自動 VM スケーリング(RightScale、Amazon)は固定的な VM 指標に基づき VM 単位で水平スケールする。[[Nimbus]] は Amazon 上へフェデレーションしてスケールアウトし、さらにジョブ投入パターンへ動的に適応する技術を含む。全体アプリケーションのスケーリング(Buyya、Lim、Rodero-Merino)は、複数 VM・複数ティアの計測値を関係付ける複雑な規則を許す。Amazon の LB は自身をスケールさせない。DNS ロードバランシングは、全 VM が公開 IP を持つパブリッククラウドでは妥当そうだが、プライベート・ハイブリッドではどうするかが未解決とされる。 - **ネットワーク層**: 仮想ネットワーク資源のオンデマンド作成(Baldine、Keshariya)と、アプリケーション単位のフロー分離と動的な帯域割り当てとしてのネットワークスライシング(OpenFlow、分散レートリミット、Path Splicing)がある。 - **プラットフォーム層**: [[AppScale]] は負荷に応じてコンテナを載せる VM を増減し LB を自動設定する。[[Aneka]] は複数の IaaS 事業者上でコンテナを展開する。Tempest/SSM と自動セッション複製は、ソフトステートの複製を通じてどのレプリカもユーザ要求を処理できるようにする。memcached は複製間の明示的な状態共有と DB アクセスの削減に使う。BigTable/HBase は ACID と SQL を緩める代わりに可用性とスケーラビリティを得る。C-JDBC/Middle-R/DBFarm は、完全な SQL と ACID が必須の場合に複数 DBMS を組み合わせる。 - Marshall らのリソースマネージャは、Nimbus 上で Amazon へフェデレーションして処理能力を最大 10 倍に増やしたと紹介されている。 ## 考察 - 全体論的な管理には進展があるが、資源管理の程度、下位 API への束縛、複数クラウドにまたがる資源の調整が主要な懸念で、更なる研究が要る。LB の動的スケーリングが全体スケーラビリティへ与える影響は、まだ報告されていない。 - ネットワークの動的管理を VM のプロビジョニングと同期して実現する本番向けシステムは、知られる限り存在しない。運用ネットワークへの革新を嫌う通信事業者を説得する必要もある。 - PaaS では、マルチテナントコンテナは資源を節約するが未解決のセキュリティ問題を含み、専用コンテナは事業者の運用費を押し上げる。複製は強い性能上の代償を伴い、大幅な性能劣化なしの複製は未解決の研究課題である。 - 理想的なクラウドは、セッションの概念をプラットフォームが提供する(透明なデータ複製が要る)。ただし複製の更新は帯域と時間を消費し、要求処理を遅らせる。DB でも複製が増えるほど一貫性維持の負荷が遅延を生む。強力なプログラミング抽象と透明なスケーラビリティの均衡が要る。 ## 強み / 弱点・課題 - 強み: 当時ばらばらだった VM スケーリング、LB、NaaS、PaaS のコンテナと DB の話題を短い紙幅で一つの地図に整理し、弾力性コントローラの制御理論的な見方(センサ、コントローラ、アクチュエータ)を明快に示した。「離散的アクチュエータ」の問題(クラウド API が VM の追加・削除に限られる)にも言及する。 - 弱点: 実験・比較評価がなく、各システムの評価は原著の主張の紹介にとどまる。指標や比較基準を持たず、分類は著者の判断による。ネットワーク層は「本番向けの実装が無い」という現状確認が中心で、具体的な設計指針は乏しい。 - 課題: 対象は 2010 年ごろの VM 中心のクラウドであり、コンテナオーケストレーションやサーバレスは含まない。LB のアルゴリズムと PaaS の周辺サービス(バス、アクセス制御)は扱わない。 - 出典に無い記述は含めていない。表1 は本文中の表であり、要点のみ再構成した。 ## 関連 - 概念: [[クラウドコンピューティング]] / [[オートスケーリング]] / [[負荷分散]] / [[分散キャッシュ]] / [[ネットワーク仮想化]] - エンティティ: [[Luis M. Vaquero]] / [[Luis Rodero-Merino]] / [[Rajkumar Buyya]] / [[Hewlett Packard Labs]] / [[INRIA]] / [[The University of Melbourne]] / [[Amazon Web Services]] / [[Google App Engine]] / [[Microsoft Azure]] / [[memcached]] / [[BigTable]] / [[AppScale]] / [[Aneka]] / [[Nimbus]] - 関連ソース: [[@2008__SIGCOMM__A Break in the Clouds - Towards a Cloud Definition]]