分散環境におけるエージェントスナップショット管理機構の開発

全文

(1)「マルチメディア，分散，協調とモバイル (DICOMO2014)シンポジウム」平成26年7月. 分散環境におけるエージェントスナップショット管理機構の開発岸上友樹1. 打矢隆弘1. 内匠逸1. 木下哲男2. 概要：近年，柔軟に対処すべき問題を解決するシステムの設計手法として，エージェント指向コンピューティングが注目されている．エージェント指向コンピューティングでは，エージェントシステムと呼ばれる知識情報に応じて自律的に動作するソフトウェアを用いたシステムによってユーザにサービスを提供する．現在，エージェントシステムの開発・運用を行うために様々なフレームワークが存在する．本研究では，数あるフレームワークの中で DASH と呼ばれるリポジトリ型エージェントフレームワークについて取り扱う．従来の DASH には分散環境で動作するエージェントシステムの再利用を目的とした機構が存在せず，エージェントシステムの永続性について十分にサポートされていない．そこで，利用中・利用後のエージェントをデータベースに保存して管理し，保存時と同じ状態でエージェントシステムを再利用するための機構を提案する．この機構の実装により，DASH におけるエージェントシステムの永続性の向上を図る．. Development of Agent Snapshot Management Mechanism on Distributed Environment Yuuki Kishigami1. Takahiro Uchiya1. Ichi Takumi1. Tetsuo Kinoshita2. 即応性エージェント自身の内部状態や外部環境を認識. 1. はじめに. し，様々な変化に対して即座に状態に適応した動作を. 近年，インターネット等の広域分散処理の発展に伴い，ユーザのソフトウェアやサービスに求める要求や利用形態. 行う．移動性通信量の削減や負荷の分散のために，エージェン. が多様化している．そこで，サービス要求に柔軟に対応できるシステムの設計手法が求められており，その実現方法. トが動作に適した環境に自ら移動する．学習性自ら経験を積むことで情報を獲得し，以降の意思. としてエージェントシステムが注目されている．エージェ. 決定に用いる．. ントとは，人間の様々な仕事を代行するソフトウェアの総. このように，エージェントはユーザの操作を介さずに他. 称である．エージェントは問題解決を図るために様々な性. のエージェント，データベース，WEB システムなど，様々. 質を持っており，主な性質を以下に示す．. なコンポーネントと協調して動作することで，ユーザの代. 自律性自らの行う動作の選択をエージェント自身が独自. わりに問題の解決を図り，サービスを提供する．このよう. に判断して行う．. にエージェントが協調して動作する一つのシステムをエー. 社会性他のコンポーネントと通信して情報を共有するな. ジェントシステムと呼ぶ．. ど，目的の達成のために連携して動作を行う．. 本研究では，エージェントの動作基盤となるフレームワークの一つである DASH(Distributed Agent System. 1. 2. 名古屋工業大学大学院工学研究科情報工学専攻 Nagoya Institute of Technology, Gokiso-chou, Syowa-ku, Nagoya, 466-8555 JAPAN 東北大学電気通信研究所 Research Institute of Electrical Communication, Tohoku University, 2-1-1 Katahira, Aoba-ku, Sendai, 980-8577 JAPAN. based on Hybrid architecture) について研究を行っている． DASH はエージェントシステムの運用環境として用いられており，エージェントシステムの効率的な利用を支援している．DASH は目的を達成するために動的にエージェント. ― 61 ―.

(2) システムを組織するため，状況に応じて柔軟にシステムの. なければならない場合がある．そのような場合には，ネー. 形態を変更することができる．従来の DASH においては，. ムサーバと呼ばれるデータストア用サーバが用いられる．. 利用後のエージェントシステムは消去するしかなく，エー. ネームサーバを用いることで，ネットワークで接続された. ジェント情報の再取得や動的に形成された問題解決に適し. リポジトリとワークプレースに存在するエージェントの名. たエージェントシステムの継続利用の方法が支援されて. 前や機能などを把握することができる．. いない．そこで，利用中・利用後のエージェントをデータベースに保存・管理し，エージェントの再利用を行うため. 2.2 DASH エージェントの動作方法. の機構を提案する．この機構の実装により，エージェント. 各エージェントは元々与えられていた情報や，他のエー. の再利用性を向上してエージェントシステムの永続性を支. ジェントからのメッセージ等によって知識情報 (ファクト). 援し，DASH におけるエージェントシステムの運用の利便. を得て，各エージェントがそれぞれ保持している，DASH. 化を図る．. エージェントは if-then 型のルール (図 2) の集まりによっ. 本稿では，前提知識として DASH について説明した後. て構成されており，これらルールによってエージェントの. に，提案機構について説明する．最後に，評価実験を通し. 動作を決定する．ルールの条件部に該当したファクトが存. て提案機構の実用性を検証し評価を行う．. 在する場合，そのルールのアクション部を実行する．ルールとのマッチングはファーストマッチングで行われ，マッ. 2. エージェントフレームワーク DASH. チするルールが複数存在する場合は，上に記述されたルー. 本研究で取り扱うエージェントフレームワークである. ルが優先される．このように，ルールのマッチングと実行. DASH[1][2] について説明する．本章では，DASH の構成，. を繰り返すことによってエージェントは動作する．エー. エージェントの動作方法，エージェントの構成について説. ジェントがマッチングを繰り返して何らかの動作を行って. 明する．また，従来の DASH に存在する問題点について言. いる状態を推論状態と呼ぶ．また，実行できるルールがな. 及する．. くなった場合は，他のエージェント等からメッセージを受け取るなど，新たにファクトを得るまでは動作ができない. 2.1 DASH の基本的な構成. ため，メッセージの受け取り待ちをする．この状態をメッ. DASH はリポジトリ型エージェントフレームワークと呼. セージ待ち状態と呼ぶ．. ばれ，作成されたエージェントを保存しておくサーバであるリポジトリと，エージェントが実際に動作する環境であ. (rule roop1. 条件部. るワークプレースによって主に構成されている．DASH に. (test :roop1 ?loop) = ?test -->. おけるユーザへのサービス提供は以下の手順で行われる. (sleep 500). アクション部. (図 1)．. (make (test :roop2 “roop1")) (remove ?test). ( 1 ) ユーザがワークプレースに対してサービス要求を行う．. (print ?loop) ). ( 2 ) ワークプレースが受け取った要求をリポジトリに伝える．. 図 2. ( 3 ) リポジトリが受け取った要求を基にエージェントシス. . DASH エージェントのルール記述例 . テムを組織してワークプレースに生成する．. ( 4 ) ワークプレースでエージェントが実際に動作して得ら. 2.3 エージェントの構成. れた結果をサービスとしてユーザに提供する．. DASH エージェントを構成している要素を以下に示す．ルール群エージェントの動作を決定付ける記述．ファク. AS. トと条件部でマッチングを行い，マッチしたルールの. ①サービス要求. ②要求通知. ④サービス提供. ③組織構成ワークプレース. ユーザ. 図 1. DASH. アクション部を実行することでエージェントは動作する．エージェントの自体に記述されたルール以外に，ルールセットと呼ばれるルールをパッケージ化したも. リポジトリ. のをインポートすることで，汎用性のあるルールを容易に利用できる．ワーキングメモリエージェントの持つファクトを格納す. DASH におけるサービス提供の流れ . る場所．エージェントが生成された時点で，エージェントの名前，最初に生成されたワークプレース，現在. エージェントシステムの動作を行うにあたって，エー. 属するワークプレースなどの基本的な情報を持つ．ま. ジェントが互いの名前と存在するワークプレースを把握し. た，エージェント作成者が自ら記述したファクトを初. ― 62 ―.

(3) 期ファクトとしてエージェントに生成時から保持させ. ジェントシステムを構成するエージェントが複数の計算. ることもできる．. 機に分かれて存在する場合は，ワークプレース間でメッ. ベースプロセス DASH で実現できない動作を実行するた. セージを送りあうことで，エージェントシステムを構成す. めの Java プロセス．エージェントがアクション部で. る全てのエージェントを保存する．スナップショットの保. 実行できるコマンドの種類が乏しいため，エージェン. 存はそれぞれの計算機から分散データベースに保存を行. ト以外のコンポーネントを操作するなどの複雑な動作. い，データベースがノード間でデータの同期を行うことで，. は行うことができない．そこで，エージェントは予め. エージェントの情報をそれぞれの環境で共有することがで. ベースプロセスを登録しておくことで Java プロセス. きる．エージェントを再利用したい際は，データベースに. を用いた動作が可能となる．エージェントからベース. 保存されたスナップショットを基に，エージェントを保存. プロセスに対して実行するメソッドと引数を指定して. 時の状態で指定したワークプレースに生成することでエー. 実行することで，GUI を用いたアプリケーションの実. ジェントの復元を行う．エージェントシステムのサービス. 行など，DASH エージェントだけでは実現できない動. 提供終了のタイミングは自動的に把握することができない. 作を可能としている．また，ベースプロセスからエー. ため，エージェントシステム終了時にエージェントを削除. ジェントに対してイベントと呼ばれる通知を行うこと. する前にユーザが保存指示を GUI 上で行う．この機能により，エージェントシステムのサービスを再. で，エージェントはベースプロセスから様々な情報を. 利用する際は，データベースから復元することで保存時の. ファクトの形で得ることができる．. 状態から継続して利用することが可能となる．エージェントシステムを始めから組織し直す方法に比べて，時間的に. 2.4 DASH の問題点従来の DASH には以下のような問題点が挙げられる．. 効率化できるだけでなく，実行環境で動的に組織されて最適化されたエージェントシステムの構成と知識情報をその. (P1) 利用後のエージェントシステムの再利用が困難エージェントシステムは利用後に消去してしまうため，. まま再利用できる．これらの実装によって，従来の DASH. 以前利用したエージェントシステムの情報を取得したり，. において十分でなかったエージェントの永続性の支援を. 再び動作させるためには，エージェントシステムを組織し. 行う．. なおして初めから動作させなければならない．そのため，. (F2) スナップショット自動取得による自動バックアップ. 余分に時間と手間がかかる上に，以前の動作と異なるサー. 機能ワークプレース上に起動している全てのエージェントの. ビス結果になる可能性があり，エージェントシステムの継続的な利用に支障がある．. 情報をスナップショットとして自動的に取得して，データ. (P2) 利用中のエージェントシステムの不意の消滅に対処. ベースに保存を行う．この機能により，エージェントの予. 不可能. 定外の消滅の際に，再びエージェントシステムを消滅時に. 計算機の電源断等によって，予定外に消滅してしまった. 近い状態で再利用できる．. エージェントシステムを再度同じ状態で利用するための機構を，従来の DASH は有していない．リアルタイムに動作を行っているエージェントシステムにとっては，持っている知識情報の消失に繋がるため，非常に大きな問題となる．. 3. 提案機構の設計前章で示した問題点を“エージェントスナップショット管理機構”を導入することで解決を図る．本章では，提案機構の設計について説明する． . 3.1 提案機構の機能. 図 3. 提案機構の有する機能を以下に示す．. 提案機構の概要図 . (F1) データベースによるエージェント情報の管理機能提案機構の概要図を図 3 に示す．サービス提供を終了し. 3.2 分散環境における制約. たエージェントシステムのエージェント情報をデータベー. エージェントシステムは，異なる計算機を含めた複数の. スに保存して管理することで，再利用したいエージェン. ワークプレース上にエージェントを配置して動作する場合. トの消失を防ぐ．この際，エージェント情報としてデータ. が存在する．そのため，エージェントの保存を行う際は，. ベースに格納する情報群をスナップショットと呼ぶ．エー. それぞれの環境に存在するエージェントを全て保存しなけ. ― 63 ―.

(4) ればならない．しかし，エージェントに対して操作を行う. ントが待ち状態であることは稀である．そこで，スナップ. ことができるのは，エージェントが存在するワークプレー. ショットの取得を行うために，エージェントを強制的に停. スからのみである．そのため，複数のワークプレースにま. 止させ，エージェントの状態が更新されないようにした上. たがるエージェントシステムの保存を行う際は，保存タイ. で，スナップショットを取得する．その後，エージェント. ミングをワークプレース間で同期する必要がある．. を再始動させることでエージェント間での情報の食い違い無くスナップショットを取得する．推論状態のエージェントの停止を行う際に注意しなけれ. 3.3 スナップショットの内容スナップショットとして保存を行う内容は，2.3 節で述べ. ばならない点として，実行中のルールをどの程度実行した. たルール群，ワーキングメモリ，ベースプロセスに加えて，. かという点がある．図 4 に示すように，ルールのアクショ. エージェント名，エージェントシステム内の親エージェン. ン部を実行している途中でエージェントが停止された場. ト子エージェントの関係性，ルールの発火履歴が挙げられ. 合，このままスナップショットを取得すると，エージェン. る．これらの情報を用いることで，エージェントを保存時. トを復元した際に実行されないまま読み飛ばされてしま. と同じ状態で復元することが可能となる．. う命令が発生する．そのため，ルールの実行中で停止したエージェントは再度動作を開始して，実行中のルールを実. 4. 提案機構の実装. 行し終えて，次のルールが選択される前に改めて動作を停. 本章では，提案機構の実装方法として，スナップショットの取得方法，エージェント保存の流れについて説明する．. 止する．このように実装することで，エージェントの保存時と同じ状態でエージェントの復元が可能となる． (rule roop1. 4.1 スナップショットの取得. 条件部. 4.1.1 スナップショットの文字列化. (test :roop1 ?loop) = ?test -->. 本研究でスナップショットの保存に用いるデータベース. (sleep 500) (make (test :roop2 “roop1")). アクション部. は，文字列のみを保存可能なデータベースである．そのた. (remove ?test). め，前章で述べたスナップショットの内容を Java のクラ. (print ?loop). エージェントの復元時に実行されない命令. ). スとしてまとめ，バイト列にシリアライズして取得する．. DASH エージェントは専用形式のファイル (dash ファイ. (rule roop2. ・・・. ル) によって記述されているが，エージェントの運用環境. ). である DASH は Java で記述されている．DASH 上でエー. . ジェントが動作する際は，dash ファイルを読み込んで Java 図 4. のプロセス上で動作するため，エージェントの情報は Java のクラスに集約することができる．また，DASH エージェントが操作するベースプロセスも Java プロセスで動作す. スナップショット取得時に実行中の命令. 推論状態のエージェントのスナップショット取得 . 4.2 エージェント保存の流れ. るため，同様に Java のクラスにまとめることができる．. エージェントの保存は，保存対象となるエージェントが. このようにして，エージェントの復元に必要となる情報を. 存在するワークプレース間でメッセージを送りあうことで. 全てまとめ，これをシリアライズすることでバイト列に変. エージェントの停止，スナップショットの取得，エージェ. 換し，データベースに格納する．シリアライズを行う関係. ントの再始動を同期させて行う．なお，取得したスナップ. 上，ベースプロセスとして用いる Java プロセスはシリア. ショットのデータベースへの格納は，エージェントの再始. ライズできる形式で作成する必要があり，Serializable イン. 動を行ったうえで行う．これにより，スナップショット取. タフェースを実装する必要がある．. 得のために生じるエージェント停止時間を最小化し，エー. 4.1.2 スナップショット取得のタイミング. ジェントシステムの動作を極力阻害しないようにしている．. エージェントのスナップショットを取得するためには，エージェントのある瞬間の状態を取得する必要がある．し. 上記を踏まえたエージェントの保存手順を以下に示す．. 1. 保存を行うエージェントの名前と環境名を取得する．. かし，エージェントが推論状態のときは，エージェントの持. ネームサーバを用いてネットワークに繋がっている全. つ情報がリアルタイムで変更されていく．そのため，エー. てのエージェントを把握し，保存を行うエージェント. ジェントのスナップショットを取得するタイミングは待ち. の名前とそのワークプレース名を取得する．手動で保. 状態のエージェントであることが望ましい．エージェント. 存を行う際は，ユーザ自らエージェントを選択し，自. システムを構成する全てのエージェントが待ち状態であれ. 動で保存を行う際は，保存対象となるエージェントシ. ば容易にスナップショットを取得することができるが，実. ステムに属する全てのエージェントを対象とする．. 際のエージェントシステムの運用において全てのエージェ. 2. 各ワークプレースにエージェントの停止命令を送る．. ― 64 ―.

(5) 保存対象エージェントが存在するワークプレースに対. 間に影響を与えることなくデータベースへの保存が可. してエージェント停止命令メッセージを送信する．. 能となる．. 3. 保存対象エージェントを停止させる．保存対象エージェントを全て停止させることで，4.1.2. 5. 評価実験提案機構では，エージェント保存時にエージェントシス. 節で述べたように保存の前後でエージェントの状態に食い違いが無いスナップショットの取得が可能となる．. テムのサービス提供を妨げる時間が発生する．この時間は最大でも，エージェントの停止命令を送信した時間から，. 4. エージェントの停止完了メッセージを返信する．ワークプレース内に存在する全ての保存対象エージェ. 全てのエージェントの再起動完了を確認するまでとなる．. ントが停止したことを確認したうえで，エージェント. そこで，提案機構のプロトタイプシステムを用いてエー. の停止完了の旨を停止命令メッセージを送ってきた. ジェント保存速度の計測実験を行い，提案機構の実用性を. ワークプレースに返信する．. 評価するためのエージェント保存時間の内訳を求めた．. 5. 各ワークプレースにスナップショットの取得命令を送る．各ワークプレースから保存対象エージェントの停止完. 5.1 実験概要. 了を伝えるメッセージが届いたことを確認したうえ. エージェントの保存時間を計測し保存開始から保存終了. で，各ワークプレースにスナップショット取得命令. までの各工程に要する時間を計測する．実験には 2 台の計. メッセージで送信する．. 算機を用いる．片方の計算機に推論状態のエージェントを. 6. 保存対象エージェントのスナップショットを取得する．. 10 個配置し，もう片方の計算機からそれらのエージェント. 保存対象となるエージェントの情報をまとめてシリア. の保存命令メッセージを送信する．計測回数は 10 回であ. ライズし，データベースに格納できるバイト列に変換. り，その平均を求めて考察する．. する．取得したスナップショットはすぐにデータベー. 実験環境を表 1，2 に示す．. スに保存を行わず，エージェントの再始動と並行して. 表 1 実験環境 (保存命令を出す計算機). 保存を行う．. 7. スナップショットの取得完了メッセージを返信する．. OS. Windows 7 Professional 64bit. CPU. R CoreTM i7-2600 CPU @3.40GHz Intel⃝. ワークプレース内に存在する全ての保存対象エージェ. メモリ. 4GB. ントのスナップショットを取得したことを確認した. DASH Version. DASH-1.9.7h1. うえで，スナップショット取得完了の旨をスナップ. Java Version. ビルド 1.7.0 04-b22. ショット取得命令メッセージを送ってきたワークプ. 表 2. レースに返信する．. 8. 各ワークプレースにエージェント再始動命令を送る．. 実験環境 (保存命令を受け取る計算機). OS. Windows 7 Professional 64bit. CPU. R CoreTM i7 CPU 870 @2.93GHz Intel⃝. 各ワークプレースからスナップショットの取得完了を. メモリ. 4GB. 伝えるメッセージが届いたことを確認したうえで，各. DASH Version. DASH-1.9.7h1. ワークプレースにエージェント再始動命令メッセージ. Java Version. ビルド 1.6.0 24-b0. で送信する．. 9. 保存対象エージェントを再始動させる．. 5.2 結果・考察. 保存対象エージェントを全て再始動させてエージェン. 実験結果を表 3 に示す．. トシステムの動作を再開する．表 3. 10. エージェントの再始動完了メッセージを返信する．. 動作. ワークプレース内に存在する全ての保存対象エージェ. 計測実験結果動作時間 (ms). 通信 (メッセージの送受信合計). 1.3. エージェント停止操作. 2.8. トの再始動完了の旨を再始動命令メッセージを送って. スナップショット取得操作. 0.1. きたワークプレースに返信する．. エージェント再始動操作. 0.6. 小計. 4.8. ントが再始動したことを確認したうえで，エージェン. 11. 各ワークプレースにおける再始動完了を確認する．各ワークプレースからスナップショットの取得完了を. データベース書込み操作. 139.9. 伝えるメッセージが届いたことを確認してメッセージ. 合計. 144.7. の送受信を終了する．. 12. スナップショットをデータベースに保存する．. 実験の結果，エージェントの保存を行う工程のうち，エー. 手順 6 で取得したスナップショットはエージェントの. ジェントの停止から再始動に要する時間は，通信時間を含. 再起動と並行して行うことで，エージェントの停止時. めても 5 ミリ秒弱と分かった．この時間は，現在 DASH. ― 65 ―.

(6) で作成されているエージェントシステムで運用する場合においては十分に速い保存速度であると思われる．しかし，この時間であれば十分という指標が無いため，絶対的評価を行うことができない．そのため，他のエージェントフレームワークの同等の機能と比較をすることで，提案機構の実用性を相対的に評価を行う必要がある．マルチエージェントを取り扱うエージェントフレームワークである. JADE[3] に，エージェントの永続性向上を図る機能として persistence[4] と呼ばれる機能がある．今後は，JADE の persistence について調査し，提案機構と比較して，提案機構のエージェント保存・管理機能の実用性の評価を行う．また，データベースへの書込み時間は 139.9 ミリ秒と長い時間が計測された．提案機構において，エージェントの再始動とデータベースへの書込みは並行して行うため，データベースへの書込みの速度はエージェントシステムのサービス提供には大きく影響しない (CPU 等リソースの競合はある)．しかし，データベースへの書込み時間も短いことが望ましいため，書込みに要している時間の詳細を調査し時間の短縮を目指す．. 6. おわりに本稿では，エージェントフレームワーク DASH における永続性に関する問題点を挙げ，その解決手法としてエージェントの情報をデータベースに保存して管理するスナップショット管理機構を提案した．この機構により，再利用が困難であった DASH 上でのエージェントシステムを容易に再利用できるようにし，永続性の点から DASH エージェントの利便性を向上を実現した．提案機構のプロトタイプシステムを用いた実験により，エージェントの保存速度を考察したが，評価には比較対象となるエージェントフレームワークが必要であると考える．今後は同等の機能を有すると思われるエージェントフレームワーク JADE の persistence と機能，保存の方法，保存速度等で比較を行って，提案機構の評価を行っていく．参考文献 [1]. [2]. [3] [4]. 打矢隆弘，原英樹，高垣暁，菅原研次，木下哲男， “リポジトリ型エージェントフレームワークの開発と評価” ，情報技術レターズ，Vol.2，pp.139-141，2003．打矢隆弘，前村貴秀，今野将，木下哲男， “発展型システムのための高機能エージェントリポジトリ” ，合同エージェントワークショップ＆シンポジウム JAWS2006 講演論文集，2006． Jade - Java Agent DEvelopment Framework， http://jade.cselt.it/index.html JADE Object Management and Persistence in Java， http://www.jade.co.nz/downloads/jade/papers/ jade wp javapersistence.pdf. ― 66 ―.

(7)