Document

J2EEアプリケーションにおける
アプリケーションレベルスケジューリング
東京工業大学大学院情報理工学研究科
数理計算科学専攻千葉研究室所属
04M37254 日比野秀章
2006/2/6
修士論文
1
過負荷時のJ2EEサーバ
 過負荷が原因で近年起きた事件
 地震計ネットワークシステム
 震度計の増加に伴う負荷の増大で、データ
送信に遅れ
 当初の予想より負荷が増大
 過負荷になると重要な処理が遅延
 震度の高い地点のデータも遅延
2006/2/6
修士論文
2
過負荷を改善する一般的な手法
 一般的な手法
 ハードウェアの追加
 見積もりが困難、費用がかかる
 アプリケーションの抜本的改修
 軽量化、クラスタ化、多階層化（負荷分散）
 検証時間、改修費用がかかる
 商用システムでは、正常動作と収益が密接
 対処の遅れは、大きな損失につながる
2006/2/6
修士論文
3
過負荷に対する安価な対処法
 QoS 制御を後から追加して対処
 アドミッションコントロール
 リクエストの種類やサーバの状態に応じて、リクエスト
の受付、実行を制限
 高負荷時にリクエストの受付を拒否
 リクエストの処理内容への影響は無い
 過負荷時のQoSの改善に有効な制御
 スケジューリングの制御
 リソースの割り当て方(OSのスケジューリングポリ
シー)がリクエスト処理に影響
[Hibino et al. DSN Workshop’05]
2006/2/6
修士論文
4
制御を追加する際の要件
 アプリケーションのコードの変更を避ける
 動いているロジックを壊す危険性を縮小
 OS・ミドルウェアの大幅な変更を避ける
 検証時間を短縮
 E.g. リアルタイム機能を持つOS・ミドルウェアに
変更
 粒度の細かいスケジューリングを行なう
 長時間かかる処理も存在
 リクエスト処理の途中で制御できるべき
2006/2/6
修士論文
5
アスペクト指向プログラミングを用いた
アプリケーションレベルスケジューリング(ALS)
 アプリケーションレベルでスケジューリング
 OS・ミドルウェアの変更不要
 アスペクトを利用してJ2EEアプリケーションとスケ
ジューラを結合
 アプリケーションのコード書き換えが不必要
 スケジューラを再利用
アスペクト
 きめ細かいスケジューリングが可能
 短い間隔でスケジューラを呼出す
アプリ
スケジューラ
 様々な位置からスケジューラを利用
 アプリケーションの情報を利用
2006/2/6
修士論文
6
ALSアスペクト

ポイントカット


アドバイス


スケジューリング制御を行う位置
スケジューラのメソッドの呼び出
し
GluonJ[Chiba et al. ’05]を利用

XMLを用いた記述
void foo(){
void beforeB();
Bar.bar();
void afterB();
}
2006/2/6
Fooクラス
修士論文
アスペクト Schedulerクラス
<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
ALSスケジューラ
スケジューラ
スケジューリング
の変更要求
アプリ
開始
スレッド1
スレッド2
スレッド3
true
スレッド2 false
true
スレッド3 false
true
スレッド1
 アプリケーションのスレッドの管理
 実行可能フラグの管理
1. アプリケーションスレッドの登録・削除
2. スレッド実行の制御
3. スケジューリングの変更
 Javaで擬似的なスレッドスケジューリング
 外部からのスレッド操作が推奨されていない
2006/2/6
修士論文
終了
8
ポイントカットの自動決定
 呼び出し位置を人手で探す
のは面倒

プロファイリング情報から呼び
出し位置を自動決定
 プロファイリング情報
 制御対象処理のみを単
独で実行して取る
 制御対象処理の実行中に
呼ばれるすべてのメソッド
の名前と呼び出し時刻
 間隔が長くなり過ぎない
ように呼び出し位置を選
択
2006/2/6
修士論文
呼び出し回数が1回
呼び出し回数が2回
methodA()
methodB()
methodB()
methodB()
(n-1)T
methodC()
methodB()
methodD()
methodE()
methodF()
nT
methodG()
methodH()
methodI()
methodC()
(n+1)T
methodI()
methodJ()
methodI()
methodK()
時刻
9
スケジューラ適用の流れ
1. スケジューラ
を作成
5. J2EEサーバに
配置
2. アスペクト
を作成
3. プロファイリング 4. 呼び出し位置を
自動決定
Jar
J2EE
アプリケーション
GluonJ
6. weave
J2EEサーバ
2006/2/6
修士論文
10
収集サーバ
河川水位監視システム
水位収集
 収集サーバ
 全国各地に設置
 全国の河川に設置された
水位計より情報収集
 管理サーバ
 収集サーバから定期的に
水位情報を収集
水位情報
 DB・メモリに格納
の取得
 水位情報の閲覧
 クライアント数増加により、
管理サーバで欠測
 一定時間内でのデータ取
得に失敗
2006/2/6
修士論文
11
管理サーバ
追加したリクエストスケジューリング
 定期的な水位情報の取得処理を即座に優先
 水位取得処理の実行中は、グラフ生成処理の並
列処理数を１に制限、それ以外は40に制限
 グラフ生成処理の途中で頻繁にスケジューラを呼
び出し、できるだけ早く停止させる
 実行可能フラグがfalseの場合、停止
スケジューラ
Waitキュー
2006/2/6
Runキュー
修士論文
12
追加したスケジューリングのプログラム
<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/2/6
修士論文
13
追加したスケジューリングのプログラム
<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/2/6
アスペクト
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());
}
}
修士論文
スケジューラ
14
実験
 ワークロード
 グラフ表示ページに対し、リクエストを常に４０
 水位収集は15秒間隔
 自動決定アルゴリズム
 呼び出し間隔10ms、出現頻度1回
 制御方式
 提案方式(ALS)
実験環境
 処理途中で制限できる
 並列処理数の制限 40⇒1
 従来のアドミッションコントロール(AC)
 処理が終わった時点で制限される
 並列処理数の制限 40⇒1
 制御なし(NC)
2006/2/6
サーバホスト×2
CPU: 3.06GHz×2
メモリ: 2GB
クライアントホスト
CPU: 1.53GHz
メモリ: 1GB
修士論文
15
水位収集にかかる時間
 制御なし(NC)
 毎回欠測
 提案手法(ALS)
欠測
 毎回5秒程度
 AC
 ALSより時間がかかる
 ばらつきが大きい
 45秒の時点で欠測
2006/2/6
修士論文
16
追加した制御によるオーバーヘッド
 グラフ生成処理の処理
数(1分)
 水位収集処理をオフ
4%
 オーバーヘッドはそれ
ほど大きくない
 ALSはACより2%大き
いだけ
6%
 決定アルゴリズムの効
果
2006/2/6
修士論文
17
グラフ生成処理用の
動作しているスレッド数の変化
平均12.0秒
2006/2/6
平均1.9秒
AC
修士論文
ALS
18
選択アルゴリズムのパラメータの影響(1/2)
DB
 パラメータにより、呼び出
し方がどう変化するか調
べた
javax
 パラメータ
 呼び出し間隔
 候補にするメソッドの出
現頻度
 実験で利用した設定
 呼び出し間隔10ms
 呼び出し回数1回
選択された呼び出しが実行された時間
2006/2/6
修士論文
19
選択アルゴリズムのパラメータの影響
(2/2)
6%減
 呼び出し間隔を短くす
ると
 呼び出し箇所の増加
 並列処理数の制限にか
かる時間の減少
 水位収集時間の減少
 オーバーヘッドの増加
 10%のオーバヘッドは
大きい
2006/2/6
修士論文
水位収集にかかる時間(秒)
6%
14%
1分当たりの処理数
20
関連研究
 Capriccio [Behren et al. ’03]


アプリケーションに応じたスレッドスケジューリング
スレッドが処理するサービスの区別が困難
 Gatekeeper [Elnikely et al. ’04]


プロキシをサーバマシン間に挿入して、リクエストスケ
ジューリング
サーバ内で実行途中での制御が不可
 Re-QoS [Tesanovic et al. ’05]


2006/2/6
QoS制御の追加にアスペクトを使用
リクエスト単位のアドミッションコントロールのみ
修士論文
21
まとめ
 過負荷時のアプリケーションサーバの挙動を分析
[Hibino et al. DSN Workshop’05]

OSのスケジューリングポリシーがリクエスト処理に大きく影響
 アプリケーションレベルスケジューリングを提案
[日比野ら DSW’06]



アプリケーションレベルでスケジューリング
アスペクトを用いてQoS制御を追加
きめ細かい制御
 河川水位監視システムに提案手法を適用

2006/2/6
過負荷時にQoS要求を満たす
修士論文
22
御清聴ありがとうございます
2006/2/6
修士論文
23

Download Report