Comments
Description
Transcript
PDF (134187bytes)
Paper No.: WIT2000-G4-2 1 モバイルエージェントの生成数制御方式 佐々木宏， 吉井英樹 日本テレコム株式会社 情報通信研究所 〒 104-0032 東京都中央区八丁堀 2-9-1 秀和東八重洲ビル Tel: 03-5540-8487 E-Mail: 5F Fax: 03-5540-8485 fchacha,[email protected] 概 要 インターネットの普及はサービス，ビジネス形態を多様化させている．21 世紀の B2B，B2C そして，C2C はさらに多様化し，様々な形として提供されていくと予測される．このようなインターネット社会では，有効 活用できないユーザの存在が問題になる．我々は，この問題を解決するための手段としてエージェント技術に 期待している．システムの一部として実適用を考えた場合，サーバ数の増大による運用コストの増加，システ ムリソース不足によるシステム障害は避けなければならない問題である．この問題を解決するためにエージェ ントの生成数に着目し，制御方式を提案する．さらに，我々が開発したモバイルエージェントシステムに，提 案する生成数制御方式を実装した実験結果を紹介する． 1 はじめに エージェント技術は 21 世紀のインターネット社会で重要である．本稿では，エージェント技術の実適用を 考え，エージェント生成数制御に関する提案をおこなう． インターネットは，サービ ス，ビジネス形態を多様化させる一つの要因として，爆発的に普及している．今 までは，文献や資料を図書館を利用して探していた．今では，文献や資料を Web 検索サイトを利用して探す ようになってきた．今までのビジネスは，紙媒体や電話/FAX を利用した取引であった．今のビジネスはイン ターネットを利用した電子商取引となってきた．21 世紀のインターネットを利用したサービ ス，ビジネスは， さらに多種多様化し ，様々な形として提供されていくと予測される．その反面，このようなインターネット社 会では，様々なサービ ス，ビジネスが氾濫し ，これらを有効活用できないユーザの存在が問題になると予想す る．これからのインターネット社会は，彼らが存分に利用できる環境作りが，非常に重要な課題であると考え る．我々は，この課題を解決する一つの技術としてエージェント技術 [2][4][5] に期待している． エージェント技術は，これからのインターネットサービ スのシステムの一部として必要不可欠であると考え る．一般にエージェントの役割は，ユーザの作業を支援し ，的確に作業を遂行する技術として適用されること が考えられる． 膨大な情報の中からユーザの目的とする情報を探しだし提供するエージェント 情報を加工し ，ユーザの作業を軽減させるエージェント 環境，サービ スの変更に柔軟に対応し ，ユーザに意識させないでサービ スを提供するエージェント この他にも様々な役割のエージェントの適用が行われていくであろう． Paper No.: WIT2000-G4-2 2 我々は，エージェント技術の実適用を考える場合に，まず，２つの問題を解決しなければならないと考える． 第一に，一つのサーバ上で生成できるエージェントが少ないと，大量のエージェントを実行させるために大量 のエージェントサーバが必要になること．第二に，一つのサーバ上で生成できるエージェント数が超過すると， システム障害がおきること．本稿では，この問題を解決するために，できるだけエージェントの生成数を増や し ，エージェントの生成数超過による障害を回避することを目的とした生成数制御方式を提案する．さらに， 我々が開発したモバイルエージェントシステム"Tarantulas" に，提案する生成数制御方式を実装した実験結果 を紹介する． 本稿では，2 章で我々が開発した Talantulas の概要を説明し，3 章でエージェント生成数について述べ，4 章 でエージェント生成数の実験を行い，5 章で考察し ，6 章で今後の課題を含めまとめとする． 2 Tarantulas の概要 Tarantulas は，我々がエージェントの要素技術を検証するために開発した実験用モバイルエージェントシス テムである．Tarantulas は，Java 言語で開発した．Tarantulas は，Tarantulas Domain(以下，TD と記す)， Tarantulas Management Server(以下，TMS と記す)，Tarantulas Server(以下，TS と記す)，Tarantulas Client Interface(以下，TCI と記す)，Personal Agent(以下，PA と記す) によって構成する．構成図を図 1 に示す． それぞれの役割は以下の通りである． TD TMS Tarantulas が提供するシステムのグループ 単位である．TD の構造は DNS と同じような構造をして いる． TD 内に必ず一つ存在する．TD に所属する TS の位置，活動／停止などの状態管理，そして，他の TD へエージェントが移動する場合のゲートウェイ機能を提供する． TS エージェントはこの TS 上で実行する．また，エージェントの生成，移動，実行等の履歴管理を提供 するサーバである． TCI ユーザからのエージェントに対する要求や各 TS との情報交換を可能とする通信用インターフェイス である． PA ユーザのためのエージェントである．このエージェントは常駐エージェントの Master PA(以下，MPA と記す) と他の TS に移動することができる Clone PA(以下，CPA と記す) が存在する． 基本機能としてエージェントの生成，実行，移動および ，エージェント間通信を実装している． 生成機能 予め登録されているユーザ用の MPA を生成する．ユーザからエージェントに 作業要求が発行されると，MPA は CPA を生成する．CPA はユーザの作業要求 にもとづき実行する． 実行機能 CPA を生成する時に決定されるサービ スによって実行する．エージェントの振 る舞いは，サービ ス提供者によって決められた処理をおこなう． 移動機能 CPA が他の TS に移動する． エージェント 間通信機能 MPA と CPA，他の CPA と通信する．この機能により，エージェント同士が情 報の共有が可能になる． Paper No.: WIT2000-G4-2 3 図 1: 構成イメージ 3 エージェント 生成数 3.1 生成数 実適用を考えエージェントサーバ上のエージェント生成数について着目する．エージェントサーバで生成で きるエージェントの数は，使用できるスレッド 数と使用できるメモリサイズ等によって決定される．このエー ジェントの生成数に起因する問題として２つの問題がある． 第一に，一つのサーバ上で生成できるエージェントが少ないと，大量のエージェントを実行させるために大 量のエージェントサーバが必要になること．１つのエージェントサーバで，生成できるエージェント数は有限 である．そして，エージェントサーバで生成できるエージェント数が少なければ ，大量のエージェントを実行 させるために，大量のエージェントサーバが必要になる．例えば，100 万のエージェントを同時に動作させる場 合に，一つのエージェントサーバで実行できるエージェントの数が１つならば ，100 万台のエージェントサー バが必要になる．エージェントサーバが多くなれば ，管理作業の増大，設置場所の拡大等のシステム以外の人 的，物理的要素が増える．ユーザが満足するサービスを提供するための運用コストを考えると非現実的である． 第二に，一つのサーバ上で生成できるエージェント数が超過すると，システム障害がおきること．一つのエー ジェントサーバで，生成できるエージェント数が超過すると，すでに，サーバで実行されていたエージェントの 動作は保証されなくなる．スレッド 不足が原因であれば新たなスレッドが生成されず動作は止まる．また，メ モリ不足が原因であるならば，エージェントが メモリを使用できず動作は止まる．そして，エージェントから の応答が無くなり作業中なのかシステム障害なのかがわからなくなる．例えば ，協調作業中のエージェントは 作業が止まったり，ユーザは正常にエージェントを起動できたか確認できなくなる．このような問題は，エー ジェントの処理能力が遅いと同等な現象になると考えられる．本稿では，参考データとして生成時間を紹介す るが，生成処理能力については言及しないこととする． 3.2 生成数制御方式 我々は，生成拒否型，生成一時待機型，生成委託型，生成委託一時待機型のエージェント生成数制御方式に ついて検討した． 生成拒否型 Paper No.: WIT2000-G4-2 4 生成拒否型 (図 2 参照) とは，Web 検索エンジンや接続ライセンス付きサーバなどに実装されている機能 と同等の方式である．エージェントが生成許容数を越える生成要求があった場合に，生成拒否通知を発 行しエージェントの生成を許可しない方式である． 図 2: 生成拒否型 生成一時待機型 生成一時待機型 (図 3 参照) とは，First In First Out(FIFO) と同等の方法を利用する．エージェントが 生成許容数を越える生成要求があった場合に，エージェント生成要求を一時 DISK 上に保存する．サー バ上でエージェントの生成が可能な場合，一番始めに保存した生成要求からエージェントを生成する方 式である．この時，エージェント生成要求を一時保存できない場合は生成拒否通知を発行する．この方 式のように一時待機させる方式として，エージェントの生成要求をすべて受け付け，DISK 上にスワップ をおこなうことで，サーバ上のエージェント数を制限する Agent Scheduling Mechanism[1] が提案され ている． 図 3: 生成一時待機型 生成委託型 生成委託型 (図 4 参照) とは，インターネット上のミラーサーバが実現している機能と似ている．エージェ ントの生成許容数が自エージェントサーバで超過した場合，予め登録されているミラーエージェントサー バにエージェントの生成を委託する方式である．この委託は相互におこなわれ，登録されている優先第 一委託サーバがエージェント生成不能の場合は第二委託サーバ，第三委託サーバ，第Ｎ委託サーバと委 託先を探す．この時，エージェント生成要求を一時保存できない場合は生成拒否通知を発行する． 図 4: 生成委託型 生成委託一時待機型 生成委託一時待機型 (図 5 参照) とは，生成委託型と生成一時待機型の複合方式である．エージェントの Paper No.: WIT2000-G4-2 5 生成許容数が自エージェントサーバで超過した場合，生成委託型と同じ手順により，生成委託をおこな う．委託サーバの第Ｎ委託サーバまでのすべてのサーバにおいて生成委託が不可能な場合は自サーバに 一時保存し ，自サーバの生成許可がでるまで待機させる．この時，エージェント生成要求を一時保存で きない場合は生成拒否通知を発行する． 図 5: 生成委託一時待機型 3.3 生成許容数 エージェントの生成数制御において，サーバ上で生成できる最大数の決定方法が重要な要素になる．この許 容数の決定方法として，Agent Scheduling Mechanism で適用されているエージェントの最大生成数をあたえ る方法とメモリサイズの閾値をあたえる方法がある． M i ai s MX s S ai (1) M S i=1 Java 実行環境で利用できるメモリサイズ ，エージェントサーバの利用するメモリサイズ ， 番目のエージェントの生成時のメモリサイズ ， 番目のエージェントの実行によるメモリサ イズ増加分 ，予期せぬメモリ使用を避けるための安全率 ，より求めた値を閾値とする．(式 2) メモリ閾値 i di ai i S + X(ai + di) =1 M s i 4 S Java 実行環境で利用できるメモリサイズ ，エージェントサーバの利用するメモリサイズ ， 番目のエージェントのメモリサイズ ，予期せぬメモリ使用を避けるための安全率 ，より 求めた値を最大生成数とする．(式 1) 最大生成数 s (2) 実験 4.1 実験 1 実験 1 では，我々の開発した Tarantulas と代表的なエージェントシステムである Plangent[6]，Aglets[3] に ついて最大生成数と生成時間の実験をおこなった．実験環境は，表 1 に示すマシンを 100Mbps のネットワー クで接続し，1 台をエージェントサーバ，1 台を生成要求クライアントとした環境を用いた．測定は，それぞれ Paper No.: WIT2000-G4-2 6 のエージェントシステムを 10 エージェント，100 エージェント，1000 エージェント，10000 エージェントと増 やした．この時，エージェント生成要求でエージェントが生成できなくなり，"java.lang.OutOfMemoryError" を表示した時点の要求数-1 を最大生成数とした．この測定を 5 回行い，平均した結果を図 6 に示す．また，最 大生成数を表 2 に示す．参考データとしてそれぞれのエージェント生成時間も測定した． 表 1: 実験環境 マシン名 CPU OS 名 メモリサイズ 台数 Sun UE10S UltraSPARC-IIi Solaris7 512Mbyte 2台 1e+06 Tarantulas Plangent Aglets Generation time(ms) 100000 10000 1000 100 1 10 100 1000 10000 Number of generation 図 6: 生成数と生成時間 表 2: 最大生成数 Tarantulas Aglets Plangent 6549 4130 727 結果から，一つのサーバ上で生成できるエージェント数に関係する 2 つの問題が確認ができる．第一に，１ つのサーバ上に Tarantulas で "6549"，Aglets で "4130"，Plangent で "727" のエージェントが最大で生成可能 であることがわかる．このとき，100 万エージェントを同時に生成すると仮定した場合，Tarantulas で 152 台， Aglets で 242 台，Plangent で 1375 台のエージェントサーバが必要になる．実際には移動してきたエージェン トや処理のためのリソースが必要になるため，少なくとも 2 倍以上のサーバが必要になると考えられる．第二 に，"java.lang.OutOfMemoryError" 以降もエージェント生成要求を受け付けて，生成を試みるが メモリ不足 により生成できない．しかし ，ユーザからは正常に生成できているように見える． 実験をおこなった Tarantulas，Plangent，Aglets は実装している機能がそれぞれ違う．そのため，実装され ている機能によって生成数が大きく違う結果となったことが考えられる． Paper No.: WIT2000-G4-2 4.2 実験 7 2 実験 2 では，検討した生成数制御のうち，生成拒否型 (以下，Exp.1 と記す)，生成委託型 (以下，Exp.2 と 記す)，生成委託一時待機型 (以下，Exp.3 と記す) の 3 方式を Tarantulas に実装し，実験をおこなった．実験 環境は，表 1 に示すマシンを 100Mbps のネットワークで接続し，1 台をエージェントサーバ，1 台を生成要求 クライアントとした環境を用いた． 今回の実験では，エージェントの生成のみで振る舞いを実装しない．したがって，式 1 の di が無視できる． 生成許容数は最大生成数とメモリ閾値で同じエージェント数となる．よって，実験 2 では，メモリ閾値 (0.7) と して生成許容数を決定する．Exp.1 はエージェントサーバの使用メモリが メモリ閾値を越えた場合に，生成拒 否を通知する．Exp.2 はエージェントサーバの使用メモリがメモリ閾値を越えた場合に，もう一つのエージェン トサーバに生成委託をおこなう．このサーバの使用メモリがメモリ閾値を越えた場合に，生成拒否を通知する． Exp.3 は Exp.2 と同様に生成委託をおこない，生成拒否が通知されたら，DISK に生成情報を一時保存する． この 3 方式を実装し ，実験を行った結果を図 7 に，実装前との比較を表 3 に示す．ただし，生成委託一時待 機型については DISK 保存が許す限り生成可能となるので，30,000 エージェントまでの実験とした． 1e+06 Exp.1 Exp.2 Exp.3 Generation time(ms) 100000 10000 1000 100 1 10 100 1000 10000 100000 Number of generation 図 7: 生成数制御方式実装結果 表 3: 生成数制御方式実装前と実装後の生成数 生成拒否型 生成委託型 4582 9211 6549 実装前エージェント生成数 実装後エージェント生成数 生成委託一時待機型 30000 Tarantulas にエージェント生成数制御 3 方式を実装し実験を行った結果，生成拒否型はメモリ閾値 (0.7) で あるため，エージェント生成数を減少させたが，生成委託型，生成委託一時待機型はそれぞれエージェント生 成数を大幅に増やす結果となった．そして，生成不可能な場合には生成拒否通知を発行するため正常に動作し ているか確認することができる．本稿にて提案する生成数制御方式はエージェントの生成数を大幅に増やし ， システム障害を避ける有効な制御方式であると実証した． Paper No.: WIT2000-G4-2 5 8 考察 本稿の生成委託の方法は，ミラーエージェントサーバが存在し，生成要求を通知することを考えている．この 前提となることは生成委託するエージェントサーバがまったく同じであることを想定している．モバイルエー ジェントの特徴となる処理の振る舞いをもって移動し ，実行することは考慮していない． そこで，生成委託するのでは無く，まず，エージェントを生成してから，生成許容数を越えている場合に自 ら移動することを考えてみる．実験 2 と同じ環境でおこなった場合，エージェントの生成数はほぼ変わらない と考える．しかし ，生成のために必要な処理時間は，増大すると考える． 6 まとめ 本稿では，エージェント生成数を制御することにより，1 つのサーバ上でのエージェント生成数を増やし，シ ステム障害を避ける方法を提案し ，実験により実証した．その反面，メモリサイズチェック，移動／待機のた めの判断処理，移動のための通信処理，そして，一時待機のための DISK 保存処理などが要因となり生成時間 も大幅に増やす結果となってしまった．このエージェントが快適に動作するためには生成数増加とともに，生 成時間短縮が必要であると認識した．また，この他の要素技術として，エージェントの永続性，信頼性，実行 性能などが重要であると認識している． 今後はこれらの技術について研究し，21 世紀の情報化社会で "人"と"エージェント "が快適に共生し，ユーザ が快適に利用できるインターネット社会を目指したいと考えている． 謝辞 日本テレコム (株) 情報通信研究所の米田進課長には研究上のご支援をいただきました．査読者の方々には有 益なコメントをいただきました．ここに記して深謝いたします． 参考文献 [1] Gaku Yamamoto,Yuichi Nakamura: Architecture and Performance Evaluation of Massive Multi-Agent System, Autonomouse Agents99,1999. [2] 本位田真一, 飯島正, 大須賀昭彦: エージェント技術, 共立出版,1999. [3] 日本 IBM:IBM Aglets Software Development Kit Home Page, http://www.trl.ibm.co.jp/aglets/indexj.html,1998. [4] 佐藤 一郎, モバイルエージェント : コンピュータソフトウエア VOL.17 NO.2,pp.45-54,2000. [5] 田井 秀樹, 山本 学: 移動エージェント技術の現状と今後の課題, コンピュータソフトウエア Vol.16 No.5,pp.213,1999. [6] 東芝:Plangent WWW ページ , http://www2.toshiba.co.jp/plangent/,1997.