J2EEアプリケーションにおける アプリケーションレベルスケジューリング 東京工業大学大学院　情報理工学研究科 数理計算科学専攻　千葉研究室所属 04M37254　日比野秀章 2006/2/6 修士論文

過負荷時のJ2EEサーバ 過負荷が原因で近年起きた事件 過負荷になると重要な処理が遅延 震度計の増加に伴う負荷の増大で、データ送信に遅れ 地震計ネットワークシステム 震度計の増加に伴う負荷の増大で、データ送信に遅れ 当初の予想より負荷が増大 過負荷になると重要な処理が遅延 震度の高い地点のデータも遅延 2006/2/6 修士論文

過負荷を改善する一般的な手法 一般的な手法 商用システムでは、正常動作と収益が密接 ハードウェアの追加 アプリケーションの抜本的改修 見積もりが困難、費用がかかる アプリケーションの抜本的改修 軽量化、クラスタ化、多階層化（負荷分散） 検証時間、改修費用がかかる 商用システムでは、正常動作と収益が密接 対処の遅れは、大きな損失につながる 2006/2/6 修士論文

過負荷に対する安価な対処法 QoS 制御を後から追加して対処 過負荷時のQoSの改善に有効な制御 アドミッションコントロール リクエストの種類やサーバの状態に応じて、リクエストの受付、実行を制限 高負荷時にリクエストの受付を拒否 リクエストの処理内容への影響は無い 過負荷時のQoSの改善に有効な制御 スケジューリングの制御 リソースの割り当て方(OSのスケジューリングポリシー)がリクエスト処理に影響 [Hibino et al. DSN Workshop’05] 2006/2/6 修士論文

制御を追加する際の要件 アプリケーションのコードの変更を避ける OS・ミドルウェアの大幅な変更を避ける 粒度の細かいスケジューリングを行なう 動いているロジックを壊す危険性を縮小 OS・ミドルウェアの大幅な変更を避ける 検証時間を短縮 E.g. リアルタイム機能を持つOS・ミドルウェアに変更 粒度の細かいスケジューリングを行なう 長時間かかる処理も存在 リクエスト処理の途中で制御できるべき 2006/2/6 修士論文

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

ALSアスペクト Fooクラス アスペクト Schedulerクラス ポイントカット アドバイス スケジューリング制御を行う位置 アドバイス スケジューラのメソッドの呼び出し GluonJ[Chiba et al. ’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/2/6 修士論文

ALSスケジューラ アプリ アプリケーションのスレッドの管理 実行可能フラグの管理 Javaで擬似的なスレッドスケジューリング スケジューラ スレッド1 スレッド2 スレッド3 開始 スケジューリング の変更要求 スレッド1 true スレッド2 true false アプリ スレッド3 true アプリケーションのスレッドの管理 実行可能フラグの管理 アプリケーションスレッドの登録・削除 スレッド実行の制御 スケジューリングの変更 Javaで擬似的なスレッドスケジューリング 外部からのスレッド操作が推奨されていない 終了 2006/2/6 修士論文

ポイントカットの自動決定 呼び出し位置を人手で探すのは面倒 プロファイリング情報 間隔が長くなり過ぎないように呼び出し位置を選択 呼び出し回数が2回 呼び出し回数が1回 呼び出し位置を人手で探すのは面倒 プロファイリング情報から呼び出し位置を自動決定 プロファイリング情報 制御対象処理のみを単独で実行して取る 制御対象処理の実行中に呼ばれるすべてのメソッドの名前と呼び出し時刻 間隔が長くなり過ぎないように呼び出し位置を選択 methodA() methodB() methodC() methodD() methodE() methodF() methodG() methodH() methodI() methodJ() methodK() (n-1)T methodC() nT methodF() methodC() (n+1)T methodJ() 時刻 2006/2/6 修士論文

スケジューラ適用の流れ 1. スケジューラ を作成 2. アスペクト を作成 3. プロファイリング 4. 呼び出し位置を 自動決定 1. スケジューラ 　　を作成 2. アスペクト 　　を作成 3. プロファイリング 4. 呼び出し位置を 　　自動決定 Jar 5. J2EEサーバに 　　配置 J2EE アプリケーション 6. weave GluonJ J2EEサーバ 2006/2/6 修士論文

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

追加したリクエストスケジューリング 定期的な水位情報の取得処理を即座に優先 水位取得処理の実行中は、グラフ生成処理の並列処理数を１に制限、それ以外は40に制限 グラフ生成処理の途中で頻繁にスケジューラを呼び出し、できるだけ早く停止させる 実行可能フラグがfalseの場合、停止 スケジューラ Waitキュー Runキュー 2006/2/6 修士論文

追加したスケジューリングのプログラム グラフ生成 水位収集 フラグの確認位置(自動生成) <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/2/6 修士論文

追加したスケジューリングのプログラム アスペクト スケジューラ <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/2/6 アスペクト 修士論文 スケジューラ

実験 ワークロード 制御方式 グラフ表示ページに対し、リクエストを常に４０ 水位収集は15秒間隔 自動決定アルゴリズム 提案方式(ALS) 呼び出し間隔10ms、出現頻度1回 制御方式 提案方式(ALS) 処理途中で制限できる 並列処理数の制限 40⇒1 従来のアドミッションコントロール(AC) 処理が終わった時点で制限される 制御なし(NC) 実験環境 サーバホスト×2 CPU: 3.06GHz×2 メモリ: 2GB クライアントホスト CPU: 1.53GHz メモリ: 1GB 2006/2/6 修士論文

水位収集にかかる時間 制御なし(NC) 提案手法(ALS) AC 毎回欠測 毎回5秒程度 ALSより時間がかかる ばらつきが大きい 45秒の時点で欠測 欠測 2006/2/6 修士論文

追加した制御によるオーバーヘッド グラフ生成処理の処理数(1分) オーバーヘッドはそれほど大きくない ALSはACより2%大きいだけ 水位収集処理をオフ オーバーヘッドはそれほど大きくない ALSはACより2%大きいだけ 決定アルゴリズムの効果 4% 6% 2006/2/6 修士論文

グラフ生成処理用の 動作しているスレッド数の変化 平均12.0秒 平均1.9秒 AC ALS 2006/2/6 修士論文

選択アルゴリズムのパラメータの影響(1/2) DB javax パラメータにより、呼び出し方がどう変化するか調べた パラメータ 呼び出し間隔 候補にするメソッドの出現頻度 実験で利用した設定 呼び出し間隔10ms 呼び出し回数1回 選択された呼び出しが実行された時間 2006/2/6 修士論文

選択アルゴリズムのパラメータの影響(2/2) 6%減 呼び出し間隔を短くすると 呼び出し箇所の増加 並列処理数の制限にかかる時間の減少 水位収集時間の減少 オーバーヘッドの増加 10%のオーバヘッドは大きい 水位収集にかかる時間(秒) 6% 14% 1分当たりの処理数 2006/2/6 修士論文

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

まとめ 過負荷時のアプリケーションサーバの挙動を分析 [Hibino et al. DSN Workshop’05] OSのスケジューリングポリシーがリクエスト処理に大きく影響 アプリケーションレベルスケジューリングを提案 [日比野ら DSW’06] アプリケーションレベルでスケジューリング アスペクトを用いてQoS制御を追加 きめ細かい制御 河川水位監視システムに提案手法を適用 過負荷時にQoS要求を満たす 2006/2/6 修士論文

御清聴ありがとうございます 2006/2/6 修士論文