Transcript SR(サービスリゾルバ)配置機構

SR（サービスリゾルバ）配置機構
東京大学大学院工学系研究科
青山・森川研究室
修士2年 大石 佳敬
1
研究の背景
ネットワーク上に偏在する機器間の接続が自動
的になされる世界
プラグアンドプレイの普及･進化
Jini、UPnP、SLP・・・
サービス提供アーキテクチャに関する研究
DANSE、VNA、STONE・・・
ディレクトリサービスが重要な位置を占める
2
ディレクトリサービス
目的
サービス自身の定期的広告
ユーザがサービスを発見するためにブロードキャスト
冗長性・帯域浪費低減
STONE
SR（サービスリゾルバ）がディレクトリサービスとしての
役割を保持
SRはマニュアルで配置
配置数などは固定的
3
SRの配置数に関する考察
SRが過少
負荷が集中し、結果的に応答時間が増加
耐障害性低
SRが過多
リソースに達するまでに、無駄なホップ数重ねることで、ユーザ要
求等に対する応答時間が増加
ディレクトリサーバを置く意味が低下
SRを適切な数に保つことは重要
ネットワーク帯域
SRの性能
リソース数
仮定：リソースは潜在的にSRとしての能力を保持
4
SR配置機構（１）
目的
SRを用いた際のサービス発見までの平均的な応答時
間の向上
負荷分散
ディレクトリサーバ
ネットワーク
耐障害性の向上
SR配置にかかる管理の為の人的コスト低減
5
SR配置機構（２）
動作
SR（サービスリゾルバ）側
SRの生成・消滅
SR間のConnection追加・変更
Name Caching
リソース（サービス / 機能）側
登録先SR変更
自身の複製生成や移動（Mobile Code)
6
SR側動作
SRの生成・消滅
SRを適応的に配置
配置数：ユーザ要求の頻度、サービス数などに応じて
SRを配置
位置：サービスやユーザの位置から判断される妥当
な物理的位置にSRを配置
負荷分散
応答性向上
7
SR側動作
SR間のConnectionの追加・変更
応答時間向上の為のショートカットの作成
あまりにも沢山ショートカットを作成すると、更新情報氾濫
リゾルバの負荷分散の為の迂回路の作成
これだけだと本質的解決にはならない！
特に迂回路形成に関しては、良く参照されるリソースを直接管理
するSRはどうしても負荷が増加
「リソース側アプローチの登録SR変更」との組み合わせが必要
辛いよ～。
SR
サービス / 機能
8
SR側動作
Name Caching
機能偏在化を容易にするために必要
解決率UP
応答時間向上
オブジェクトの実体を複製するわけではないので。
負荷分散にはならない
複製の出来ないオブジェクトに対して有効
9
リソース側動作
登録先SR変更
登録先SRを変更、もしくは複数のSRに登録
SR
SR
SR ：サービスリゾルバ
：リソース
：登録先SR変更を
しようとしているリソース
変更前
SR
SR
SR
SR
登録先変更
登録先の多重化
•直接的な管理負荷の移譲
•クエリー数の低減
10
リソース側動作
自身の複製生成や移動（Mobile Code)
複製可能なリソース（プログラム、データ等）であ
れば、参照頻度などに応じて自身の複製を作成
ネットワーク上の適切な位置に移動
適切な＝ユーザに対する応答時間向上、SRやネット
ワーク帯域の負荷分散
11
SR配置機構（３）
動作のためのトリガ情報
SRの負荷状態
履歴情報
リソースに対するアクセス頻度
クライアント（要求元ユーザ・要求先リソース）の位
置情報
ユーザ要求に対する応答時間
12
SR配置機構の存在形態
SR自体が水平分散的に配置
SR配置機構も分散型を利用
集中型
SR配置機構
分散型
この辺にリゾル
バがあったほう
がいいよ！
この辺にリゾル
バがあったほう
がいいよ！
SR
サービス / 機能
13
SR配置機構に関するシミュレーション
SR配置機構の動作
リソース側動作の「自身の複製生成や移動」は除く
動作のトリガとなる情報
SRの負荷状態
確認項目
負荷分散：それぞれのSRの保持する負荷のバランシ
ング
安定動作：生成・消滅といった相反する動作によるシ
ステムの発散を抑制
14
まとめと今後の課題
まとめ
SR配置機構の基本動作
それぞれの動作に関して概説
現在シミュレーションを開始。近日中に結果
今後の課題
履歴情報等を利用した、よりインテリジェントなシステ
ム
配置位置を決定するアルゴリズム
STONEへの実装
15