J2EEアプリケーションにおけるアプリケーションレベルスケジューリング東京工業大学千葉研究室日比野秀章光来健一千葉滋 2006/1/27 DSW 2006 1 過負荷時のJ2EEサーバ  過負荷が原因で近年起きた事件  地震計ネットワークシステム  震度計の増加に伴う負荷の増大で、データ送信に遅れ  当初の予想より負荷が増大  東証、株式全取引停止  株式売買の注文が殺到し、システムの処理能力が限界  リクエストの増大  過負荷になると重要な処理が遅延  震度の高い地点のデータも遅延  ライブドア以外の注文も遅延 2006/1/27 DSW 2006 2 過負荷を改善する一般的な手法  一般的な手法  ハードウェアの追加  選定、追加開発に時間がかかる  購入予算がかかる  アプリケーションの抜本的改修  軽量化、クラスタ化、多階層化（負荷分散）  検証に時間がかかる  改修の費用がかかる  商用システムでは、正常動作と収益が密接  対処の遅れは、大きな損失につながる 2006/1/27 DSW 2006 3 過負荷に対処する安価な対処法  QoS 制御を後から追加して対処  アドミッションコントロール  重要度の高い処理を優先する  追加する際の用件  アプリケーションのコードの変更を避ける  動いているロジックを壊す危険性を縮小  OS・ミドルウェアの大幅な変更を避ける  検証時間を短縮  E.g. リアルタイム機能を持つOS・ミドルウェアに変更 2006/1/27 DSW 2006 4 アスペクト指向プログラミング(AOP)を用いたアプリケーションレベルスケジューリング  アプリケーションレベルでスケジューリング  OS・ミドルウェアの変更不要  アスペクトを利用してJ2EEアプリケーションとスケジューラを結合  アプリケーションのコード書き換えが不必要  スケジューラを再利用  きめ細かい制御が可能  短い間隔で定期的にスケジューラを呼出す  様々な位置からスケジューラを利用  アプリケーションの情報を利用 2006/1/27 DSW 2006 5 スケジューラスケジューラ  アプリケーションのスレッドを管理  アプリケーションスレッドの登録・削除  スケジューラに処理の開始・終了を通知  スレッド実行の制御要求フラグの一覧 ID false ID false ID true ID false  定期的に呼び出される   実行可能フラグに応じて、自発的に制御(wait/sleep) Javaのsuspend/resumeが推奨されていない  外部からの強制的なスレッド操作が不可確認 ID アプリ  スケジューリングの変更要求  実行可能フラグを要求に応じて調整 2006/1/27 DSW 2006 ID ID 6 スレッドアスペクト    ポイントカット  スケジューリング制御を行う位置アドバイス  スケジューラのメソッドの呼び出し GluonJ[Chibaら’05]を利用  XMLを用いた記述 void foo(){ void beforeB(); Bar.bar(); void afterB(); } 2006/1/27 アスペクト Schedulerクラス DSW 2006 Fooクラス <glue> <pointcut-decl> <name> point </name> <pointcut> withincode(void Foo.foo()) ANDAND call(void Bar.bar()) </pointcut> </pointcut-decl> <behavior> <around> Scheduler.beforeB(); $_ = $proceed($$); Scheduler.afterB(); </around> </behavior> </glue> 7 スケジューラを呼び出す位置の自動決定  定期的な呼び出し位置を人手で探すのは面倒  プロファイリング情報から呼び出し位置を自動決定  1. 2. 3. 呼び出し位置の候補  制御対象処理の実行中に呼ばれるすべてのメソッド  プロファイリング情報  制御対象処理のみを単独で実行して取る 4. [(n-1/2)T,(n+1/2)T]で分割出現頻度が1で、ｎＴに近いものを選択選択数0の区間で、出現頻度が2、以下の加点が最大になるものを選択 1. 新たに選択された区間の数 2. 削除可能な呼び出しの出現頻度出現頻度3,4,…,Nで3の繰り返し N:出現頻度の上限 T:呼び出し間隔・methodA ・methodB ・methodC  候補となるメソッドの名前と呼び出し時刻  呼び出し位置の決定方針  一定間隔(T秒)  少なくする  2006/1/27 各区間で呼出しは１回 DSW 2006 (n-1)T nT (n+1)T 8 全体図 1. スケジューラを作成 5. J2EEサーバに配置 2. アスペクトを作成 3. プロファイリング 4. 呼び出し位置を自動決定 Jar J2EE アプリケーション GluonJ 6. weave J2EEサーバ 2006/1/27 DSW 2006 9 収集サーバ水位監視システム水位収集  収集サーバ  全国各地に設置  全国の河川に設置された水位計より情報収集  管理サーバ  収集サーバから定期的に水位情報を収集水位情報  DB・メモリに格納の取得  水位情報の閲覧  クライアント数増加により、管理サーバで欠測  一定時間内でのデータ取得に失敗 2006/1/27 DSW 2006 10 管理サーバグラフ表示ページ 2006/1/27 DSW 2006 11 追加したQoS制御  定期的な水位情報の取得処理を優先  水位取得処理の実行中は、グラフ生成処理の並列処理数を１に制限、それ以外は40に制限  スケジューラの動作  水位収集処理開始時  グラフ生成処理のスレッドの実行可能フラグを1つ以外すべてfalse  水位収集処理終了時  計40個の実行可能フラグをtrue  グラフ生成処理の途中  定期的に実行可能フラグを確認   2006/1/27 Trueなら処理を継続 Falseなら待機 DSW 2006 12 追加したQoS制御のプログラム <pointcut-decl> <name> lowImportant </name> <pointcut> execution(void PlaceChartCreatePseudActionImpl.execute(..)) </pointcut> グラフ生成 </pointcut-decl> <pointcut-decl> <name> highImportant </name> <pointcut> execution(void CollectorImpl.doObtain()) </pointcut> </pointcut-decl> 水位収集 <pointcut-decl> <name> checkpoint </name> <pointcut> (withincode(Range CategoryPlot.getDataRange(ValueAxis)) ANDAND call(Range Range.combine(Range.Range))) OROR : </pointcut> フラグの確認位置(自動生成) </pointcut-decl> 2006/1/27 DSW 2006 13 追加したQoS制御のプログラム <behavior> <pointcut> lowImportant </pointcut> <around> PriorityPolicy.beforeLowPriority(); $_ = proceed($$); PrioirtyPolicy.afterLowPriority(); </around> </behavior> <behavior> <pointcut> highImportant </pointcut> <around> PriorityPolicy.beforeHighPriority(); $_ = proceed($$); PriorityPolicy.afterHighPriority(); </around> </behavior> <behavior> <pointcut> checkpoint </pointcut> <before>PriorityPolicy.checkpoint();</before> </behavior> 2006/1/27 アスペクト Public class PriorityPolicy { public static void beforeLowPriority() { controller.enter(Thread.currentThread()); } public static void afterLowPriority() { controller.exit(Thread.currentThread()); } public static void beforeHighPriority() { controller.schedule(1); } public static void afterHighPriority() { controller.schedule(40); } public static void checkpoint() { controller.checkpoint( Thread.currentThread()); } } DSW 2006 スケジューラ 14 実験条件  ワークロード  グラフ表示ページに対し、リクエストを常に４０  水位収集は15秒間隔  制御方式  提案方式(ALS) 実験環境  処理途中で制限できる サーバホスト×2  並列処理数の制限 40⇒1 CPU: 3.06GHz×2  従来のアドミッションコントロール(AC) メモリ: 2GB  処理が終わった時点で制限される クライアントホスト  並列処理数の制限 40⇒1 CPU: 1.53GHz  制御なし(NC) メモリ: 1GB 2006/1/27 DSW 2006 15 水位収集にかかる時間  制御なし(NC)  毎回欠測  AC  ALSより時間がかかる  ばらつきが大きい  45秒で欠測  提案手法(ALS)  毎回5秒程度 2006/1/27 DSW 2006 16 グラフ生成処理用の動作しているスレッド数の変化（ＡＣ）  スレッド数を1に抑えるのに時間がかかる  水位収集が終わるまでに抑えられていないことも多い 2006/1/27 DSW 2006 17 グラフ生成処理用の動作しているスレッド数の変化（ALS）  スレッド数が短時間で1 に抑えられている 2006/1/27 DSW 2006 18 負荷の違いによる制御への影響  グラフ生成処理に投げるリクエストの数を変えて計測(20 or 40)   水位収集にかかる時間並列処理数を抑えるのにかかる時間  リクエストが増加した際   2006/1/27 ACでは、かなり時間がかかる ALSでは、比較的短時間で水位収集を終える水位収集にかかる時間（秒） DSW 2006 19 並列処理数を抑えるのにかかる時間（秒）選択アルゴリズムのパラメータの影響 DB  パラメータにより、呼び出し方がどう変化するか調べた  javax パラメータ  呼び出し間隔  候補にするメソッドの出現頻度  パラメータにより呼び出し方が大きく変化  呼び出しの状況から、適切なパラメータを選択  制御不可能な区間  DBアクセス  水位情報の検索  Javax内の処理  画像のエンコーディング選択された呼び出しが実行された時間 2006/1/27 DSW 2006 20 関連研究  Capriccio [Behrenら’03]   アプリケーションに応じたスレッドスケジューリングスレッドが処理するサービスの区別が困難  Gatekeeper [Elnikelyら’04]   プロキシをサーバマシン間に挿入して、リクエストスケジューリングサーバ内で実行途中での制御が不可  Re-QoS [Tesanovicら’05]   2006/1/27 QoS制御の追加にアスペクトを使用リクエストのアドミッションコントロールのみ DSW 2006 21 まとめと今後の課題  まとめ  アプリケーションレベルスケジューリングを提案  アスペクトを用いてQoS制御を追加  きめ細かい制御  河川水位監視システムに提案手法を適用  過負荷時にQoS要求を満たす  今後の課題  他のアプリケーションにも適用 2006/1/27 DSW 2006 22