J2EEアプリケーションにおける アプリケーションレベルスケジューリング 東京工業大学　千葉研究室 日比野秀章　光来健一　千葉滋 2006/1/27 DSW 2006

過負荷時のJ2EEサーバ 過負荷が原因で近年起きた事件 過負荷になると重要な処理が遅延 震度計の増加に伴う負荷の増大で、データ送信に遅れ 地震計ネットワークシステム 震度計の増加に伴う負荷の増大で、データ送信に遅れ 当初の予想より負荷が増大 東証、株式全取引停止 株式売買の注文が殺到し、システムの処理能力が限界 リクエストの増大 過負荷になると重要な処理が遅延 震度の高い地点のデータも遅延 ライブドア以外の注文も遅延 2006/1/27 DSW 2006

過負荷を改善する一般的な手法 一般的な手法 商用システムでは、正常動作と収益が密接 ハードウェアの追加 アプリケーションの抜本的改修 選定、追加開発に時間がかかる 購入予算がかかる アプリケーションの抜本的改修 軽量化、クラスタ化、多階層化（負荷分散） 検証に時間がかかる 改修の費用がかかる 商用システムでは、正常動作と収益が密接 対処の遅れは、大きな損失につながる 2006/1/27 DSW 2006

過負荷に対処する安価な対処法 QoS 制御を後から追加して対処 追加する際の用件 アドミッションコントロール 重要度の高い処理を優先する 追加する際の用件 アプリケーションのコードの変更を避ける 動いているロジックを壊す危険性を縮小 OS・ミドルウェアの大幅な変更を避ける 検証時間を短縮 E.g. リアルタイム機能を持つOS・ミドルウェアに変更 2006/1/27 DSW 2006

アスペクト指向プログラミング(AOP)を用いた アプリケーションレベルスケジューリング アプリケーションレベルでスケジューリング OS・ミドルウェアの変更不要 アスペクトを利用してJ2EEアプリケーションとスケジューラを結合 アプリケーションのコード書き換えが不必要 スケジューラを再利用 きめ細かい制御が可能 短い間隔で定期的にスケジューラを呼出す 様々な位置からスケジューラを利用 アプリケーションの情報を利用 2006/1/27 DSW 2006

スケジューラ スレッド アプリケーションのスレッドを管理 スケジューラ アプリケーションスレッドの登録・削除 スレッド実行の制御 要求 スケジューラに処理の開始・終了を通知 スレッド実行の制御 定期的に呼び出される 実行可能フラグに応じて、自発的に制御(wait/sleep) Javaのsuspend/resumeが推奨されていない 外部からの強制的なスレッド操作が不可 スケジューリングの変更要求 実行可能フラグを要求に応じて調整 フラグの一覧 false ID true 要求 確認 ID アプリ ID ID スレッド 2006/1/27 DSW 2006

アスペクト Fooクラス アスペクト Schedulerクラス ポイントカット スケジューリング制御を行う位置 アドバイス スケジューラのメソッドの呼び出し GluonJ[Chibaら’05]を利用 XMLを用いた記述 <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> void foo(){ Bar.bar(); } void beforeB(); void afterB(); Fooクラス アスペクト Schedulerクラス 2006/1/27 DSW 2006

スケジューラを呼び出す位置の自動決定 定期的な呼び出し位置を人手で探すのは面倒 プロファイリング情報から呼び出し位置を自動決定 呼び出し位置の候補 制御対象処理の実行中に呼ばれるすべてのメソッド プロファイリング情報 制御対象処理のみを単独で実行して取る 候補となるメソッドの名前と呼び出し時刻 呼び出し位置の決定方針 一定間隔(T秒) 少なくする 各区間で呼出しは１回 [(n-1/2)T,(n+1/2)T]で分割 出現頻度が1で、ｎＴに近いものを選択 選択数0の区間で、出現頻度が2、以下の加点が最大になるものを選択 新たに選択された区間の数 削除可能な呼び出しの出現頻度 出現頻度3,4,…,Nで3の繰り返し N:出現頻度の上限　 T:呼び出し間隔 ・methodA ・methodB ・methodC 2006/1/27 DSW 2006 (n-1)T nT (n+1)T

全体図 1. スケジューラ を作成 2. アスペクト を作成 3. プロファイリング 4. 呼び出し位置を 自動決定 1. スケジューラ 　　を作成 2. アスペクト 　　を作成 3. プロファイリング 4. 呼び出し位置を 　　自動決定 5. J2EEサーバに 　　配置 Jar J2EE アプリケーション 6. weave GluonJ J2EEサーバ 2006/1/27 DSW 2006

水位監視システム 収集サーバ 管理サーバ クライアント数増加により、管理サーバで欠測 収集サーバ 水位収集 全国各地に設置 全国の河川に設置された水位計より情報収集 管理サーバ 収集サーバから定期的に水位情報を収集 DB・メモリに格納 水位情報の閲覧 クライアント数増加により、管理サーバで欠測 一定時間内でのデータ取得に失敗 水位情報の取得 2006/1/27 DSW 2006 管理サーバ

グラフ表示ページ 2006/1/27 DSW 2006

追加したQoS制御 定期的な水位情報の取得処理を優先 スケジューラの動作 水位取得処理の実行中は、グラフ生成処理の並列処理数を１に制限、それ以外は40に制限 スケジューラの動作 水位収集処理開始時 グラフ生成処理のスレッドの実行可能フラグを1つ以外すべてfalse 水位収集処理終了時 計40個の実行可能フラグをtrue グラフ生成処理の途中 定期的に実行可能フラグを確認 Trueなら処理を継続 Falseなら待機 2006/1/27 DSW 2006

追加したQoS制御のプログラム グラフ生成 水位収集 フラグの確認位置(自動生成) <pointcut-decl> <name> lowImportant </name> <pointcut> execution(void PlaceChartCreatePseudActionImpl.execute(..)) </pointcut> </pointcut-decl> <name> highImportant </name> <pointcut> execution(void CollectorImpl.doObtain()) </pointcut> <name> checkpoint </name> <pointcut> (withincode(Range CategoryPlot.getDataRange(ValueAxis)) ANDAND call(Range Range.combine(Range.Range))) OROR : グラフ生成 水位収集 フラグの確認位置(自動生成) 2006/1/27 DSW 2006

追加したQoS制御のプログラム アスペクト スケジューラ <behavior> <pointcut> lowImportant </pointcut> <around> PriorityPolicy.beforeLowPriority(); $_ = proceed($$); PrioirtyPolicy.afterLowPriority(); </around> </behavior> <pointcut> highImportant </pointcut> PriorityPolicy.beforeHighPriority(); PriorityPolicy.afterHighPriority(); <pointcut> checkpoint </pointcut> <before>PriorityPolicy.checkpoint();</before> 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()); 2006/1/27 アスペクト DSW 2006 スケジューラ

実験条件 ワークロード 制御方式 グラフ表示ページに対し、リクエストを常に４０ 水位収集は15秒間隔 提案方式(ALS) 処理途中で制限できる 並列処理数の制限 40⇒1 従来のアドミッションコントロール(AC) 処理が終わった時点で制限される 制御なし(NC) 実験環境 サーバホスト×2 CPU: 3.06GHz×2 メモリ: 2GB クライアントホスト CPU: 1.53GHz メモリ: 1GB 2006/1/27 DSW 2006

水位収集にかかる時間 制御なし(NC) AC 提案手法(ALS) 毎回欠測 ALSより時間がかかる ばらつきが大きい 45秒で欠測 毎回5秒程度 2006/1/27 DSW 2006

グラフ生成処理用の 動作しているスレッド数の変化（ＡＣ） スレッド数を1に抑えるのに時間がかかる 水位収集が終わるまでに抑えられていないことも多い 2006/1/27 DSW 2006

グラフ生成処理用の 動作しているスレッド数の変化（ALS） スレッド数が短時間で1に抑えられている 2006/1/27 DSW 2006

負荷の違いによる制御への影響 グラフ生成処理に投げるリクエストの数を変えて計測(20 or 40) リクエストが増加した際 水位収集にかかる時間 並列処理数を抑えるのにかかる時間 リクエストが増加した際 ACでは、かなり時間がかかる ALSでは、比較的短時間で水位収集を終える 2006/1/27 水位収集にかかる時間（秒） DSW 2006 並列処理数を抑えるのにかかる時間（秒）

選択アルゴリズムのパラメータの影響 DB javax パラメータにより、呼び出し方がどう変化するか調べた 呼び出し間隔 候補にするメソッドの出現頻度 パラメータにより呼び出し方が大きく変化 呼び出しの状況から、適切なパラメータを選択 制御不可能な区間 DBアクセス 水位情報の検索 Javax内の処理 画像のエンコーディング 選択された呼び出しが実行された時間 2006/1/27 DSW 2006

関連研究 Capriccio [Behrenら’03] Gatekeeper [Elnikelyら’04] アプリケーションに応じたスレッドスケジューリング スレッドが処理するサービスの区別が困難 Gatekeeper [Elnikelyら’04] プロキシをサーバマシン間に挿入して、リクエストスケジューリング サーバ内で実行途中での制御が不可 Re-QoS [Tesanovicら’05] QoS制御の追加にアスペクトを使用 リクエストのアドミッションコントロールのみ 2006/1/27 DSW 2006

まとめと今後の課題 今後の課題 まとめ アプリケーションレベルスケジューリングを提案 河川水位監視システムに提案手法を適用 アスペクトを用いてQoS制御を追加 きめ細かい制御 河川水位監視システムに提案手法を適用 過負荷時にQoS要求を満たす 今後の課題 他のアプリケーションにも適用 2006/1/27 DSW 2006