[StreamCloud] 研究概要

以下、StreamCloud プロジェクトの研究課題及び解決策案、実装案を書きます。

[前提]
- 有限個の計算資源しかなく、マシンの増強は様々な要因で困難
（マシン設置環境、電源容量の限界、経済的な問題）
- 複数のアプリケーション（ストリーム処理のみ）が混在し、それぞれ SLA (応答時間の上限など）が異なる
- ターゲットとするアプリケーションのトラフィックの変動が激しく予測困難（周期性はところどころある）
- Load Shedding などデータを間引いて処理することは考えず、すべてのデータを処理する


[課題]
上記の前提を受けて、すべてのアプリケーションの SLA を満たすような手法及びアーキテクチャとは何か

[我々の解決手法の概要]
自身が保有する計算資源で間に合わない場合には、その処理をクラウド上の DSMS に委譲する

[本研究の Technical Challenge]
(A) どのようなアルゴリズムを持って、クラウド上に処理を委譲するか？また、クラウドのVMMは何個立ち上げれば SLA を守れるか？
(B) VMM の起動・停止の時間がかかるため、どのようなタイミングでクラウドの VMM を起動しておくか、停止するか？
(C) 現行のデータストリーム処理システムでは実行時にノードを追加する仕組みがないのでそれをどのように解決するか？

[解決策の前提]
- クラウドの定義とは、Amazon 及び Eucalyptus などの Iaas のみをここでは指し、VMM をオンデマンドで提供する環境とする。また、条件としては、ローカルの計算資源と比較して、レイテンシが相対的に高く、バンド幅も制限される。また、VMM 上の DSMS の稼動なので、ランタイムのオーバーヘッドが存在する。
- ただし、クラウドを利用している他のユーザーのジョブの混入によるパフォーマンスの劣化は考えなく、占有できる
- 自身の保有する計算資源で処理が間に合わない場合のみを以下の議論の対象にする
- SLA は本研究では単純化して応答時間とする

[解決策の詳細]
(1) クラウドへの処理委譲の条件 (上記A に対する解決策)
　(a) 応答時間が緩やかなアプリケーションの場合には、クラウド実行時の実行時間 =
（クラウド上へのデータの送受信時間）＋（VMM によるオーバーヘッドを加味した計算実行時間)
と定義できるので、この時間が応答時間を上回ってなければ委譲する
　(b)クラウド実行時の実行時間は前処理によって統計値を取っておき、データレートに応じた
計算時間を線形式で定式化し、（重）回帰分析を行って係数を求め、数理的なモデル式を構築する
　(c)上記の実行時間予測よりも応答時間が下回る、または許容範囲内に収まっていれば、クラウドに委譲する

(2) VMM の起動・停止のタイミング
- 自身の保有する計算資源で処理できないデータレートをあらかじめ求めておく.これは待ち行列理論により
　レイテンシが大幅に増加する段階のデータレートで判断することができる。
- データレートの変化を定期的にチェックし、変化の勾配がある閾値を越えた場合には、即座に
クラウドに対して、VMM の起動リクエストを発行する。起動リクエストと VMM の起動（または Resume) の
時間はあらかじめ測定しておき、それを加味した上で、上記の閾値を設定する
- 逆にデータレートが自身の保有する計算資源で処理できる量以下の値が一定時間続けば、クラウドに対して
VMM の停止リクエストを発行する

[実装の詳細]
- クラウド環境は Eucalyptus を使用する.
- クラウドの高レイテンシ及び低バンド幅を再現するために ns2 などのネットワークシミュレータを用いる
- データストリーム処理システムは System S を使用する。
- VMM の起動、停止は UDOPオペレータ内で実装し、その中から Eucalyptus への起動・停止リクエストを発行する
- 現行の System S には動的にホストを追加する機構がない (ジョブの再投入時に有効になる）ので,
クラウド上の VMM のホストを実行時に認識させる仕組みを設計し、実装する

[評価アプリケーション]
アプリケーションおよびシナリオはいろいろ考えられるので、また考えましょう。
手持ちのものとしては、VWAP (低レイテンシ), SST (1次元のみ, レイテンシ緩やかな場合を想定), Twitter などが考えられます