Improving FaultTolerance by Replicating Agents Alan Fedoruk Ralph Deters 早稲田大学深澤研究室 鄭 顕志 背景 マルチエージェントシステム(MAS) 多大な労力をかけて開発されている が 実際に稼働しているシステムはごく小規模 システムの脆弱性 １つのエージェントの障害が伝播 全体の障害につながる 複製を用いることで堅固なMASを構築する 発表の流れ 1. 2. 3. 4. マルチエージェントシステムの特徴 複製プロキシの導入 FIPA-OSを用いての実装、評価、議論 まとめ MASの概要 自立的なソフトウェアエージェントから成る 集中管理を行わない 動的環境と情報のやりとりをする MAS内のエージェントは社会性を持つ Host1 Environment Agents Communication Links Host2 Network Host3 MASの障害 MAS内のコンポーネントに障害発生 MAS全体に伝播 主な障害の原因 プログラムのバグ 予期しない状態 プロセッサの障害 コミュニケーション障害 対応策 エージェント中心策 エージェントが複雑になる システム中心策 エージェントの数が増える システムワイドの障害を検知で きる 発表の流れ 1. 2. 3. 4. マルチエージェントシステムの特徴 複製プロキシの導入 FIPA-OSを用いての実装、評価、議論 まとめ 複製を用いた例 複製 WWWの例 インターネット 利点 １つのサーバに障害が 起きても大丈夫 検索時間の向上 欠点 アップデートに余計な作業 が必要 クライアントがどれを選べば いいかわからない MASの場合でも同じことがいえる エージェントの複製 オリジナルと同じタスクをこな せるエージェントを作成する 複製の種類 同種複製 同じコードのエージェントを作成 異種複製 機能が同じエージェントを作成 複製グループ 障害への対応 Type Faults Type 同種複製＋ 決定的エージェント プロセッサ障害 コミュニケーション障害 同種複製＋ 非決定的エージェント プログラムのバグ 予期しない状態 プロセッサ障害 コミュニケーション障害 異種複製 プログラムのバグ 予期しない状態 プロセッサ障害 コミュニケーション障害 複製の問題点 1. エージェント間通信 ■ ■ 複製グループ内の誰と通信していいかわからない 複数の結果の中からどれを採用していいかわからない 2. Read/Writeの一貫性 ■ ■ 環境からの情報がグループ内で同一とは限らない 環境への書き込み、動作要求などをどのようにマージするか 3. 状態の同期 ■ ■ 処理の引き継ぎ時にどこから処理を再開すればいいか 異種複製だとより複雑に 複製グループプロキシ Environment Proxy Replicant Group 複製グループを１つのエンティティとしてみせる 複製グループの処理管理、状態管理を行う プロキシの機能 コミュニケーションプロキシ データプロキシ 複製グループ管理 パフォーマンス管理 プロキシの機能： コミュニケーションプロキシ 複製グループ内外のメッセージの調整機能 外部からのメッセージを上手く振り分ける 複製からの複数のリプライを独自のロジックで 統合 メッセージ量は倍になる プロキシが障害を起こす危険性が残る プロキシの機能：データプロキシ 環境へのRead/Write一貫性を保つ 環境からの情報を複製グループ内で同一に する 環境への書き込み、動作要求を統合する 環境からのデータが古いものである可能性 がある プロキシが障害を起こす危険性が残る プロキシ機能：複製グループ管理 複製の稼働/休止などの管理 稼働中 全ての複製が稼働 ホットスタンバイ １つだけが稼働、他の全ては休止 コールドスタンバイ １つだけが稼働、他の全ては休止 Read/Writeの一貫性を気にしなくていい プロキシ機能：複製グループ管理 ホットスタンバイ 状態通知 Proxy 稼働中のエージェントが定期期に休止 中のエージェントに状態を通知 稼働中のエージェントに障害が起きる とプロキシが休止中のエージェントを１ つ稼働させる 選ばれたエージェントは１つ前の状態 から稼働 復帰は早い 状態通知にコストがかかる プロキシ機能：複製グループ管理 コールドスタンバイ 状態通知 Proxy 稼働中のエージェントが定期期にプロ キシに状態を通知 稼働中のエージェントに障害が起きる とプロキシが休止中のエージェントを１ つ稼働させる プロキシは最新の状態を通知 状態をアップデートして処理開始 復帰に時間がかかる 状態通知が低コスト プロキシ機能：パフォーマンス管理 パフォーマンスを向上させる プロキシが複製要素の特徴を知る (複製からの通知もしくは学習) 新しい候補を選ぶときに最速、最安 定のものを選ぶ(ホット・コールドスタ ンバイ時) 発表の流れ 1. 2. 3. 4. マルチエージェントシステムの特徴 複製プロキシの導入 FIPA-OSを用いての実装、評価、議論 まとめ 複製サーバの実装 プロキシを用いた複製テクニックを実際に適応 評価 システムの障害発生率がどれだけ低減？ 使用リソースがどれだけ増加？ 複製サーバ FIPA-OSを用いて実装 コミュニケーションプロキシ機能 ホット・コールドスタンバイ対応 異種・同種複製対応 複製グループ内の状態同期 複製サーバ RepServer0 RepServer1 RepGroupA RepGroupB A B RepGroupC C A2 A0 A1 B1 B2 B アプリケーション例：I-Help MAS 複製サーバのテストベット用に作成 学生が自分にあったヘルパーを捜すアプリ PersAgent PersAgent PersAgent MatchMaker PersAgent PersAgent PersAgent UIAgent UIAgent 実験環境 ■ ■ ■ ■ I-HELPシステムを２パターンで実装 1. スタンダードなFIPA-OSで 2. マッチメーカエージェントとパーソナルエージェントに 複製を用いる(withホットスタンバイ) 閉じた信頼できる環境で実験 擬似的に障害発生確率を与える 環境 ◆ FIPA-OS 2.1.0 ◆ Java Version 1.3.0 ◆ Sun SunFire 3800 with 4 UltraSparcIII CPUs 750MHz and 8GB of RAM, Solaris 2.8 実験１：複製グループ導入のオーバヘッド 実験環境 マッチメーカエージェント：１ UI エージェント：２ 複製グループ：各３エージェントから構 成 パーソナルエージェント：２〜６４ プロキシの追加、エージェント数の増加による メッセージ量の倍増 約1.25倍の処理時間増加 実験２：複製数の増加によるオーバヘッド 実験環境 マッチメーカエージェント：１ UI エージェント：２ パーソナルエージェント：４ 複製グループ：３〜２８ ホットスタンバイにより ほとんどのエージェントが休止状態 パフォーマンスはわずかに低下 実験３：複製数による障害発生率の低減 実験環境 マッチメーカエージェント：１ UI エージェント：２ パーソナルエージェント：４ 障害発生確率：５〜９０％ 障害発生率 結果(システム障害発生率) 50%未満 ２，３個の複製でほぼ0% 50％以上 １０個の複製で0.1%未満 ただし９０％あたりでは初期設定時に障害が 発生して正確に測定できなかった わずかな複製で十分な信頼性 発表の流れ 1. 2. 3. 4. マルチエージェントシステムの特徴 複製プロキシの導入 FIPA-OSを用いての実装、評価、議論 まとめ まとめ MASにおいて、複製を用いることで信頼性をあ げる プロキシを用いることで複製透過性を得る FIPA-OSにより実装、評価 わずかな数の複製で、それほどパフォーマンス を落とさずに、高い信頼性を得る Future Work プロキシの機能を分散させることによりプロキシ の障害発生を防ぐ 複数のエージェントでチームを組んでプロキシとしてのタスクをこなす プロキシに障害が起きた場合、他のチームが代わりにタスクをこなす テストシステムを様々な環境でも動くように実装 する
© Copyright 2024 ExpyDoc
