Comments
Description
Transcript
（PDFファイルが開きます）オペレーションシステム経済化技術
オペレーションシステム 経済化技術 −分散データ駆動型アーキテクチャ− 移動通信ネットワークは多種多様で，数多くのネットワ ーク設備から構成される．これらのネットワーク設備を監 視制御するシステムは OPS と呼ばれている．従来の OPS は，高価な大規模 UNIX サーバと市販ミドルウェアを用い て構成されているため，その TCO の増大を招いていた．そ こで，OPS の TCO の大幅な削減を可能とする，分散データ 駆動型アーキテクチャ“D3A”を考案した． あきやま かずよし こん たかし 秋山 一宜 昆 孝志 たかはし かずひで じ ん ぐ う じ まこと 高橋 和秀 神宮司 誠 1. まえがき OPS（OPeration System）[1][2]は，移動通信ネットワー クで発生する故障や輻輳の発見と，それに対する回復措置 を担っている重要なシステムである．OPS を構成するサー バの故障や内部輻輳などが要因で，ネットワーク設備 （NE ： Network Element）からの警報がネットワーク管理 者に通知されなかった場合，NE の故障や輻輳に対する措 置が遅れ，通信サービスの停止やサービス品質の低下が長 期化する．このため，OPS には高い信頼性と高い処理能力 が要求される．これらの要求条件を満たすために，従来の OPS は，大規模 UNIX サーバと RDBMS（Relational Data Base Management System）や CORBA（Common Object Request Broker Architecture）などの市販ミドルウェアを多 用して構築されてきた． しかし，大規模 UNIX サーバと市販ミドルウェアの導入 コストや保守コストは非常に高額である．また，大規模 UNIX サーバを提供するハードウェアベンダの都合（サー バの販売停止や保守停止など）に依存せざるを得ない状態 （ベンダロックイン）に陥り，後継機へのサーバリプレース や OS のバージョンアップなどを余儀なくされてきた．そ の結果，いったん特定のハードウェアベンダのサーバを採 用すると，後継機の導入コストだけでなく，OPS アプリケ ーションの動作検証コストについても高額な投資を伴うこ ととなる．市販ミドルウェアについても，その販売停止や 保守停止により，ハードウェアと同様なベンダロックイン 状態に陥る． 36 NTT DoCoMo テクニカル・ジャーナル Vol. 13 No.2 一方で，近年サーバ構成技術の動向は大きく変化してお 本アーキテクチャを図 1 に示す．本アーキテクチャは， り，小規模IA（Intel Architecture）サーバやギガビットイー サネット（GbE：Gigabit Ethernet）の低価格化が進み，市場 以下に示す 7つの要素から構成される． 流通性が増したことから，PCクラスタ[3]，グリッドコンピ ・物理エレメント（PE：Physical Element） ューティング[4][5]，モバイルエージェント[6][7]など複数の ・論理エレメント（LE ： Logical Element） サーバを結合して高い処理能力を得る技術が実用化段階を ・論理経路データ（LPD ： Logical Path Data） 向かえている．これらの技術分野は，ハイパフォーマンスコ ・LPD ドライバ（LPDD ：LPD Driver） ンピューティング（HPC：High Performance Computing）と ・LPD マネージャ（LPDM ：LPD Manager） 呼ばれている．また，Linuxに代表されるオープンソースソ ・外部アダプタ（EA：External Adaptor） フトウェア（OSS：Open Source Software）が安定化し，重 ・エレメント構成マネージャ（ECM ： Element 要なシステムにも採用される例が多くなってきた． Configuration Manager） 本稿では，これらの技術動向を踏まえ，OPS の TCO （Total Costs of Ownership）を大幅に削減することを目的と ハードウェアの構成要素が PE であるのに対し，ソフト して考案し，実用化した分散データ駆動型アーキテクチャ ウェア（OPS アプリケーション）の構成要素が LE である． （D3A ： Distributed Data Driven Architecture）[8]∼[17]につ PE は，ラックマウント型 IA サーバについては小規模 IA サ いて，その動作メカニズムと処理能力の測定結果について ーバそのものに相当し，ブレード型 IA サーバについてはエ 述べる．また，その評価についても従来の OPS と比較しな ンクロージャーに搭載された各サーバブレードに相当す がら述べる． る．ここで，小規模 IA サーバとは 2CPU（Central Processing Unit）以下の IAサーバとする．LEは OPSアプリ 2. D3A の基本動作 ケーションを分割した並列実行単位であり，PE に分散配置 D3A は，複数の IA サーバを束ねて高い処理能力を得るこ される．LE は機能分散の単位，つまり分散配置が可能な機 とが可能なアーキテクチャである．また，その技術的要素 能の最小単位といえる．PE は負荷分散の単位，つまりハー からハードウェアの拡張性やアプリケーション追加の柔軟 ドウェアの限られたリソースに対して，負荷処理を分散す 性に優れ，従来のシステムアーキテクチャと比較して，コ る単位ということもできる．これら複数の LEを組み合わせ スト面においても優位な新技術といえる． ることにより，1つのOPSアプリケーションを構成する本ア 物理エレメント 論理経路データ 論理エレメント DNS PE 入力 PE EA PE LE LPD LPDD PE LE LPD LPDD LPD LPDドライバ 論理経路 LPDD LPDD PE 論理経路データ＋アプリケーションデータ LPDM LE LPD LE LPD GbE LPDD LPDマネージャ PE 出力 EA LPDD PE PE LE LPD LE LPD LPDD LPDD エレメント構成 マネージャ PE LE LPD LPDD ECM 図1 D3A 37 ーキテクチャを使用すれば，高い処理能力を得ることが可 ンデータに再び設定して，次段の LE に送信する．LPD の 能である．また，動作環境としては，3GHz以上の処理速度 論理経路に指定された各 LE において必要となるデータ の CPU を搭載した非常に高性能な PE が，高速な GbE で結 （LE 間インタフェース）は，アプリケーションデータ部に て定義されるため，各 LPD のアプリケーションデータ部 合されるため，LE間は高速な通信が可能である． LPD に基づく論理経路制御の様子を図 2 に示す．LPD は， は，その論理経路における LE 間の共通インタフェースであ ると見なすことも可能である． 論理経路データ部とアプリケーションデータ部の 2 つの部 分から構成され，XML（eXtensible Markup Language）に LPDD による物理経路制御の様子を図 3 に示す．LPDD より記述される．各 LE は，前段の LE から LPD を受信する は，LPD の論理経路データ部に基づいて，LE 間で論理的に と，自分が処理すべきアプリケーションデータのみを， 経路制御を行うドライバである．また，LPDD はドメイン LPD から抽出して処理し，その処理結果をアプリケーショ ネームシステム（DNS ： Domain Name System）に基づい 入力 LE1 LE2 LE3 PE11 PE21 PE31 PE12 PE22 PE32 出力 PE33 論理経路 LPD LPD LE5 LE4 PE51 LE6 論理経路データ PE41 PE52 PE61 アプリケーションデータ PE42 PE53 PE62 図2 冗長 入力 論理経路制御 LE1 LE2 PE11 LPDD PE21 LPDD PE12 LPDD PE22 LPDD 論理経路 冗長 冗長 LE4 LE5 PE41 LPDD PE51 LPDD PE42 LPDD PE52 LPDD DNS 図3 物理経路制御 PE31 LPDD PE32 LPDD LPD 各PEの名前解決処理 38 LE3 PE33 LPDD LE6 冗長 PE61 LPDD 出力 NTT DoCoMo テクニカル・ジャーナル Vol. 13 No.2 て，PE 間で物理的に経路制御を行う．ここで DNS は，LE DNS から該当のエントリを削除することにより，LPDD が の存在する PE の名前解決を行うために用いる．LPDD は， 故障した PEへ経路制御しないように動作する． 冗長構成を制御する機能や LE/PE の故障を管理する機能な どから構成され，本アーキテクチャのプラットフォームと なっている．各 PE に分散配置された LPDD が LPD に基づ LPD には論理的に経路制御するためのタグとして，以下 いて LE を駆動することにより，その LPD に対応する OPS の 6 つの定義があり，基本的に W3C（World Wide Web アプリケーションが実行される．OPS アプリケーションか Consortium）[18]の BPEL4WS（Business Process Execution らは PE を意識することがないため，LPDD が PE を LE に仮 Language for Web Services）[19]に準拠している． 想化しているといえる． ・直列： <sequence> LPDM は LPD の原本を管理している．また，EA は本ア ・条件分岐： <switch> ーキテクチャの外縁に配置され，外部とのインタフェース ・並列分岐： <flow> の違いを吸収し，共通インタフェースに変換する機能を有 ・本流と分断された分岐： <drop> する．外部からの入力を契機に，EA に配置された LPDD ・繰り返し： <for> が LPDM の制御により，LPD を構成する論理経路データ ・同一のLE（異なるPE）に対する並列分岐：<invokeAll> 部へ，あるテンプレートを読み出し，そのテンプレート内 にアプリケーションデータ部を生成する．LPDD による また，経路制御の通信方法には非同期型と同期型があり， LPD の読出しを高速化するために，LPD は各 PE の LPDD 実現するアプリケーションの内容により，LPD のタグで指 にキャッシュされているが，その原本は LPDM で管理さ 定することが可能である．これらのタグ定義のうち代表的 れている． な<sequence> タグと<flow> タグについて説明する． ECM は，XML により記述されたエレメント構成情報フ 図 4 は，<sequence> タグにより LE1 から LE4 まで LPD を ァイル（ECIF ： Element Configuration Information File）の 直列に経路制御していることを示している．非同期型の場 原本を管理している．ECIF には，LE と PE の対応関係や 合，LPD を受信した LE は，直ちに前段の LE に応答を返送 LE の冗長構成方式などの構成情報が記述されている．各 し，自分が LPD を送信した次段の LE からの応答を待ち合 LE は，初期起動時にECM から ECIFを取得し，故障処理時 わせない．一方，同期型の場合，LPD を受信した LE は次段 などに参照する．この読出し処理を高速化するために， の LE に LPD を送信し，次段の LE からの応答を待ち合わせ ECIF は各 LE に配備された LPDD にキャッシュされている． て前段の LEに応答を返送する． PE の増設や撤去により ECIF が変更された場合，ECM はす 図 5 は，<flow> タグにより LE2 から LE3 と LE4 に並列に べての LPDD に対して新しい ECIF を通知する．ECM は， 分岐するように経路制御していることを示している．非同 ECIF に記述されたすべての LE に対して LPD の送受信を用 期型の場合，LE2 から分岐した LE3 と LE4 からの応答を待 いてヘルスチェックを行い，未応答の PE を検出すると ち合わせることなく LE1に応答を返送する．同期型の場合， <sequence> 非同期型 <process name=“EX2”sync=“false”> <logicalPath> <sequence> <invoke partner=“LE2”> <invoke partner=“LE3”> <invoke partner=“LE4”> </sequence> </logicalPath> </process> LE1 LPD LE2 LE3 LE4 <sequence> 同期型 論理経路データ部 <process name=“EX2”sync=“true”> <logicalPath> <sequence> <invoke partner=“LE2”> <invoke partner=“LE3”> <invoke partner=“LE4”> </sequence> </logicalPath> </process> LE1 LPD LE2 LE3 LE4 図4 <sequence> タグによる論理経路制御 39 <flow> 非同期型 <process name=“EX1”sync=“false”> <logicalPath> <invoke partner=“LE2”> <flow name=“EX1”sync=“false”> <invoke partner=“LE3”> <invoke partner=“LE4”> </flow> </logicalPath> </process> LE1 LPD LE2 LE3 LE4 並列分岐 <flow> 論理経路データ部 同期型 <process name=“EX1”sync=“true”> <logicalPath> <invoke partner=“LE2”> <flow name=“EX1”sync=“true”> <invoke partner=“LE3”> <invoke partner=“LE4”> </flow> </logicalPath> </process> LE1 LPD LE2 LE3 LE4 並列分岐 図5 <flow> タグによる論理経路制御 LE2 は LE3 と LE4 からの応答を待ち合わせ，LE1 に応答を 実行型）と同様に，ECM が ECIF に基づいて，PE に対して 返送する． 一定周期でヘルスチェックすることにより，PE の故障を監 3. D3A の冗長構成 視する（④）．ECM が PE の故障を検出する（⑤）と，DNS のエントリから，その PE の IP アドレスを削除する（⑥）． LEの信頼性を確保するために，PEの冗長構成と負荷分散 本方式により，故障した PE を系から切り離すことが可能 を実現する必要がある．PEの冗長構成としては，以下の3つ となる．また，本方式を適用すると，LE はデータを PE に の方式がある．それぞれの冗長構成方式を図6∼8に示す． 分散配置することで負荷分散を実現する． ・ n−ACT（ACTive）構成（選択実行型） ・ n−ACT 構成（並列実行型） ・ n−ACT/m−SBY（StandBY）構成 本方式は，ACT 状態にある n個の PE とSBY 状態にある m 個の PE から構成される冗長方式である．SBY 状態にある PE には通番が付与されており，このうちの最も若い通番を 本方式では，LPD を受信（①）した PE の LPDD が，ACT 持つ PE（代表 PE）が，ACT 状態にあるすべての PE に対し 状態にある n 個の PE に対して，ラウンドロビン方式で 1 つ て一定周期でヘルスチェックをすることにより，PE の故障 の PE を選択し，その PE に LPD を送信する（③）．この際 を監視する（①）．SBY 状態にある PE（代表 PE 以外）は， LPDD は，DNS に対して，LPD にて指定された LE 名によ 自分自身の通番より 1 つ若い通番を持つ PE に対して一定周 り，その LE が存在する PE の IP（Internet Protocol）アドレ 期でヘルスチェックすることにより，SBY 状態にある PE の スを問い合わせる（②）．また，ECM が ECIF に基づいて， 故障を監視する（②） ．代表 PE が ACT 状態にある PE の故障 PE に対して一定周期でヘルスチェックすることにより， を検出すると（③），ECM に故障した PE を通知（④）し， PE の故障を監視する（④）．ECM が PE の故障を検出する DNS のエントリから，その IP アドレスを削除するととも （⑤）と，DNS のエントリから，その PE の IP アドレスを削 に，自分自身の IP アドレスを ACT 状態にある PE として 除する（⑥） ．本方式により，PEの負荷分散を実現するとと DNS のエントリに登録し，故障した PE に成り代わる（⑤） ． もに，故障した PE を系から切り離すことが可能となる． SBY 状態にある PE（代表 PE 以外）が SBY 状態にある PE （代表 PE）の故障を検出すると，DNS のエントリから，そ の IP アドレスを削除するとともに，自分自身の IP アドレス 40 本方式では，LPD を受信（①）した PE の LPDD にて並列 を SBY 状態にある PE（代表 PE）として DNS のエントリに 指定されている ACT 状態にある n 個の PE すべてに対して， 登録し，故障したPE に成り代わる（⑥） ．本方式により，故 LPD を送信する（③） ．LPDD は，DNS に対して，LPD にて 障した PEを系から切り離すことが可能となる．また，本構 指定された LE名により，そのLEが存在するすべての PE の 成を適用すると，LE はデータを PE に分散配置することに IP アドレスを問い合わせる（②） ．また，n−ACT構成（選択 より負荷分散を実現する． NTT DoCoMo テクニカル・ジャーナル Vol. 13 No.2 LE2 ラウンドロビン PE21 （ACT） LPDD ③ LE1 ① PE22 （ACT） PE11 LPDD LPD ② LPDD 参照 PE23 （ACT） DNS LPDD NG ⑥ ④ ヘルス チェック ヘルス チェック ⑤ 故障したPEのIPアドレスを DNSのエントリから削除 図6 ヘルス チェック ECM n − ACT 構成（選択実行型） ACT状態にあるすべてのPEにLPDを送信 LE1 ① LE2 PE11 LPDD LPD ② LPDD 参照 PE22 （ACT） DNS LPDD NG ⑥ ④ ヘルス チェック 故障したPEのIPアドレスを DNSのエントリから削除 図7 PE21 （ACT） ③ ⑤ ヘルス チェック ECM n − ACT 構成（並列実行型） LE2 LE1 LPD PE22 （ACT1） PE11 LPDD PE21 （ACT0） 参照 ⑤ PE23をDNSのエントリから削除し， PE24のエントリをACT2に変更 ① ヘルス チェック ⑥ PE25のエントリをSBY0に変更 ④ ECMにPE23の故障を通知 ECM LPDD LPDD NG LPDD DNS PE23 （ACT2） ヘルス チェック ③ ヘルス チェック PE24 （SBY0→ACT2） LPDD ② ヘルス チェック PE25 （SBY1→SBY0） LPDD 図8 n − ACT/m − SBY 構成 41 クライアント サーバ PE1 PE2 CPU: Xeon 2.8GHz×2 （HyperThreading=Enabled） Memory: 2GB CPU: Xeon 3.06GHz×2 （HyperThreading=Enabled） Memory: 2GB JavaVM: JDK1.5.0 OS: RedHat ES3.0 XML parser: Crimson1.1.3 JavaVM: JDK1.5.0 OS: RedHat ES3.0 XML parser: Crimson1.1.3 GbE 1段目 図9 2段目 測定環境と測定方法 なお，DNS はプライマリ／セカンダリ構成で動作させて 4. D3A の基本処理能力の測定 本アーキテクチャにおいては，LPDD 内で LPD の XML パ <sequence>タグによる論理経路制御 処理能力（mps） いる． 2000 1500 1000 500 0 ース処理と LE 間通信処理が頻繁に発生するため，その処理 1 2 バと呼ぶこととする．複数のクライアントから 1 台のサー バに対して，並列に LPD を送信した場合の処理能力を測定 非同期型 同期型 <flow>タグによる論理経路制御 処理能力（mps） 動作に関してタグ定義ごとに LPDDの処理能力を測定する． 信元の LE をクライアントとし，LPD の送信先の LE をサー 6 LEの段数 能力を明確にしておく必要がある．ここでは，D3A の基本 測定環境と測定方法を図 9 に示す．ここでは，LPD の送 4 300 250 200 150 100 50 0 非同期型 2 4 並列分岐の数 図 10 同期型 測定結果 する．クライアントからサーバに対して LPD を合計 1000 回 送信し，クライアントが受信する単位時間当りの応答の平 収れんする．<flow> タグによる経路制御においては，非同 均値mps（message per second）を求めた．ただし，JavaVM 期型通信の場合，約 200mps ∼ 300mps 程度，同期型通信の ＊1 （Virtual Machine）による Java クラスのロード時間が実験 結果に影響しないように 1 回目の結果は除外した．また， <flow> タグ同期型通信については，並列分岐において次段 LPD のデータサイズを 10kB とした．なお，図 9 に示すとお のLEの処理を待ち合わせるため，並列分岐数が多くなると り，今回の測定環境は 3 章で述べた冗長構成を採用してい 性能劣化が大きくなると考えられる． ない． 5. D3A システムの利点 測定結果を図 10 に示す．<sequence> タグによる経路制御 OPS を構成するハードウェア／ミドルウェア製品やアプ においては，LE の段数が 1 段の場合，非同期型で約 リケーションの構造により，一概に比較することはできな 1800mps もの処理能力がある．また，本タグについては， いが，OPS の重要な性能指標値である警報受信能力（1 秒 非同期型通信でも同期型通信でも，LE の段数が多くなるに 間に受信可能な警報 400 件）に基づき評価した．所要の処 つれてその処理能力が低くなるが，約 500mps ∼ 600mps に 理能力を達成するために必要な TCO について，従来の OPS ＊ 1 Java ：米 Sun Microsystems 社が提唱しているネットワークに特化したオ ブジェクト指向型開発環境． 42 場合，約 150mps ∼ 200mps 程度の処理能力であった． と本アーキテクチャを用いて構成した OPS を比較した結果 を図 11 に示す．この比較には，ハードウェアの導入費と保 NTT DoCoMo テクニカル・ジャーナル Vol. 13 No.2 守費，およびミドルウェアの導入費と保守費を含んでいる ことはない．基本的に OSS のバージョンアップに追従する が，アプリケーションの開発費は含まれていない．保守費 必要はないが，ハードウェアのリプレースを契機に JavaVM については 5 年間で計算している．また，従来の OPS の のバージョンアップを伴うケースが想定される．このよう TCO を 100 ％として正規化している．図 11 に示すとおり， な場合でも，JavaVM にはアプリケーションに対する上位 TCO を約80 ％削減できる見通しを得た． 互換性があるため，基本的に下位バージョンの JavaVM に て開発されたアプリケーションは，上位バージョンの JavaVM 上で動作可能といえる．つまり，JavaVM に上位互 本アーキテクチャは，低価格な小規模 IA サーバと OSS を 換性があるため，ハードウェアベンダに束縛されることは 積極的に活用することを前提としている．また，アプリケ ない．本システムにおいて，唯一採用している Linux 上の ーション（LE/EA）は JavaVM 上に構築しており，アプリ OSS として，DBMS（DataBase Management System）であ ケーションから Linux のシステムコールやライブラリを直 る PostgreSQL 接に使用することを禁止している．これにより，IA サーバ JDBC（Java DataBase Connectivity）に制限していることか に搭載された CPU のマシン語との互換性にかかわらず，ど ら，ハードウェアに依存しない． ＊2 があるが，データベースへのアクセスを の機種の IA サーバ上でも動作可能となる．さらに，LE 間 の通信に用いる LPD を XML により記述するため，LE 間の 通信はハードウェアや OS に依存しない．したがって，PE 従来の OPS は，大規模 UNIX サーバから構成されている の異機種結合が非常に容易となり，本アーキテクチャに基 ため，一部のハードウェアリソース（例えば，CPU）が最 づいて開発された OPS アプリケーションは，異機種混在環 大実装されている場合，他のリソース（例えばメモリやデ 境での動作が可能である． ィスク）を増設可能であるにもかかわらず，そのリソース これまでに，異なる CPU を搭載した，異なるハードウェ （ここでは CPU）をそれ以上増設できないために，サーバ アベンダの IA サーバ10 機種について，本アーキテクチャの そのものを増設しなければならないケースが散見される． プラットフォームである LPDD の動作検証を実施した結果， このような場合，サーバそのものの導入だけでなく，市販 問題となる現象は検出されなかった[13]． ミドルウェアの導入も必要となるため，多大な投資を強い また，本システムでは市販ミドルウェアを一切採用して られる．一方，本アーキテクチャでは，特定の LE の処理能 いないことから，ミドルウェアベンダの戦略に束縛される 力不足に対して，その LE を配備した PE（小規模 IA サー バ）のみを増設するだけで対応可能である．つまり，大規 TCO削減効果が絶大 大規模UNIXサーバ 市販ミドルウェア 模 UNIX サーバと比較して，小規模 IA サーバは低価格であ り，きめ細かな増設が可能である． また，小規模 IA サーバを増設する際，異なるベンダの IA 120 サーバを増設することも可能である．小規模 IA サーバは PCをベースとしているため，市場流通性が高く，小規模 IA 100 サーバを販売するハードウェアベンダの数は多い．つまり， 80 増設する際に最も低価格のハードウェアを選択することが TCO 約80％削減 60 可能である．このように，増設するハードウェアの選択肢 が広いことは重要なポイントである． 小規模IAサーバ オープン・ソース・ソフトウェア 40 従来の OPS アプリケーションは，C や C++ などのコンパ 20 イル言語で実装されているため，新たな機能追加を行う場 0 従来のOPS D3AによるOPS 合，基本設計／機能設計／詳細設計の各設計工程，ソース プログラム編集／コンパイル／リンク／データ編集の製造 ミドルウェア保守費 ハードウェア保守費 ミドルウェア導入費 ハードウェア導入費 図 11 TCO 削減効果 工程，単体試験／結合試験／対向試験／総合試験の各試験 ＊ 2 PostgreSQL ：カリフォルニア大学バークレー校で開発されたデータベー スシステム． 43 工程がすべて必要となる．このように，すべての開発工程 は JavaRMI に比較し，応答時間については約 20 倍，処理能 を踏まなければならないため，機能追加には高額な投資が 力は 1/2 である．GT3 の実装にも，Apache Axis を用いてい 必要となる．文献[20][21]において提案されている方法で るため，OPS が要求する性能を満たさない．特に SOAP の も，コマンド仕様に関する軽微な変更に 2 週間程度を要す シリアライズ処理が重いため，条件分岐の数（つまり，シ る．一方，本アーキテクチャでは，LE の処理順序や処理条 リアライズ処理の数）に比例して処理能力が低下する． 件については，LPD において XML によりデータレベルで記 OPS を実現するためには 2 つ以上の分岐処理は必須であり， 述される．これにより，LPD の変更のみで機能追加が可能 これらの要求する性能を満たさない． な場合は，設計工程を基本設計のみに，製造工程をデータ 編集のみに，試験工程を結合試験からプログラム試験のみ に短縮することが可能であると考えている．したがって， このような場合は迅速かつ柔軟に機能追加が行える． モバイルエージェントをネットワーク管理に適用した報 告[6][7]がいくつかあるが，グリッドコンピューティング と同様に，通信キャリアレベルの商用・大規模なネットワ ーク管理において実用化された例は見当たらない．文献 従来の OPS では，特定のハードウェアの故障により，す [6][7]においては，NE にモバイルエージェントを送り込ん べての業務が数分程度中断し，その故障が影響を与える範 で NE を監視制御する．本稿では，このようなモデルを NE 囲は OPS 全体となっていた[22][23]．3 章で述べた冗長構成 依存型エージェントモデルと呼ぶことにする．NE 依存型 により，故障による業務の中断時間は最大の LE でも約 90 モバイルエージェントモデルに基づいたネットワーク管理 秒程度であり[12]，ハードウェアの故障が影響を与える範 の主な優位点として，NE が警報を多発しない場合，OPS 囲は，その LE にのみ限定される． ∼ NE 間（つまり，マネージャシステムとエージェントシ また，従来の OPS では，OPS アプリケーションに対する ステム間）の通信トラフィックの削減，および OPS（つま 機能追加や変更を行う場合，ロードモジュールの入替えが り，マネージャシステム）負荷の軽減が挙げられている． 必要になり，すべての業務が数分程度中断する．本システ OPS に，本稿で提案しているアーキテクチャを適用するこ ムでは，LPD と LE を入れ替えるのではなく，新しく追加 との優位点について，NE 依存型モバイルエージェントモ することにより，業務を中断することなく OPS アプリケー デルとの比較において議論する．まず，第 1 に，警報を多 ションを変更することが可能である． 発する NE が現実に存在しており，このような NE につい 6. 関連研究との比較 て，モバイルエージェントモデルを適用しても OPS ∼ NE 間のトラフィックを削減できない．第 2 に本アーキテクチ ャは，既存 NE へのエージェントシステムの追加や新しい 地理的に分散配置された多数の計算資源を連動させて， スーパーコンピュータを凌ぐハイパフォーマンスを得る技 来の OPS から本モデルにより実現した OPS へのマイグレー 術にグリッドコンピューティングがある．グリッドコンピ ションは，NE 依存型モバイルエージェントモデルに比較 ューティングを医療や物理学の分野で実用化した報告 し，容易であると考える．第 3 に，既存 NE にエージェント [4][5]がいくつかあるが，商用の大規模なネットワーク管 システムを搭載できない（特に JavaVM 上に構築されたシ 理において実用化された例は見当たらない．最近の技術動 ステムの文献が多いが，モバイルエージェントは JavaVM 向としては，Web サービスとグリッドコンピューティング を持たない NE には搭載できない）場合も存在する．また， の技術を融合したモデルとして，OGSA（Open Grid Service 特定のモバイルエージェントが搭載可能であることが，新 Architecture）[24]の標準化活動が盛んである．米アルゴン しい NE を導入するための必須条件となり，NE の選択肢が ヌ大学の Globus プロジェクト[25]は，OGSA を実装した 限定されてしまう．第 4 に，既存 NE にエージェントシステ GT3（Globus Toolkit3）[26]を 2003 年 7 月に公開した．GT3 ムを搭載できない場合は，新しくエージェントシステムを の実装においては，SOAP（Simple Object Access Protocol） 導入する必要があり，NE が設置されているすべてのビル による通信プロトコル処理に Apache Axis を用いており，こ に新しいハードウェアを導入しなければならない．NE が れに大きく依存した実装となっているようである．文献[8] 設置されているビルの数や NE の台数が多い場合は，多く に よ れ ば ， HTTP/SOAP（ Apache Axis） と JavaRMI のハードウェアを導入する必要があり，導入コストが膨大 （Remote Method Invocation）の性能評価から，HTTP/SOAP 44 エージェントシステムの導入が不要である．このため，従 になるものと予想される． NTT DoCoMo テクニカル・ジャーナル Vol. 13 No.2 103，No. 43，pp. 1−6，May 2003． 7. あとがき [9] K. Akiyama, T. Watanabe, K. Takahashi and N. Tanigawa:“A 本稿では，多数の小規模 IA サーバを束ねて高い処理能力 を得ることが可能な D3A について説明した．本アーキテク チャの優位点を以下にまとめる． ・ OPS の TCO を大幅に削減することが可能である． ・ハードウェアベンダやミドルウェアベンダの戦略に影 響されにくい． Distributed DataDriven Architecture for Operations Support Systems,” NOMS2004. [10]佐藤 豪一，高橋 和秀，谷川 延広：“組織階層型モバイルエージ ェントモデルに基づいた OSS の実用化,”SACSIS2004，May 2004． [11]佐藤 豪一，昆 孝志，秋山 一宜，高橋 和秀，神宮司 誠：“分散デ ータ駆動型アーキテクチャによる OSS の実用化,”FIT2004，LC− 003，Sep. 2004． [12]金子 伊織，牧野 雄至，高橋 和秀，神宮司 誠：“分散データ駆動 ・ OPS のハードウェアを安価な小規模IAサーバ単位で柔 軟に拡張可能である． ・ OPS アプリケーションへの機能追加に対して，迅速か つ柔軟に対応可能である． ・従来の OPS と比較して，OPS 性能指標値（警報受信能 力）が最大で約 5倍となる． 型アーキテクチャの信頼性評価,”信学技報，Vol. 104，No. 164， pp. 25−30，Jul. 2003． [13]西田 幸一，藤嶋 貴志，久川 誠，高橋 和秀，神宮司 誠：“分散デ ータ駆動型アーキテクチャの性能評価と移植性評価,”信学技報， Vol. 104，No. 565，pp. 7−12，Jan. 2005． [14]高橋 和秀，昆 孝志，秋山 一宜，神宮司 誠：“組織階層型モバイ ルエージェントモデルに基づいたネットワーク管理システムの実 用化,”信学論（D） ，Vol. J88−D1，No. 2，pp. 401−420，Feb. 2005． 本アーキテクチャを適用し，開発したxGSN（serving/gateway General packet radio service Support Node）対応 OPS は， すでにサービスを開始し，安定した運用実績をあげている． また，TCO 削減効果が非常に大きいことから，既存 OPS の 全面的なリプレースとなる次期 NW −OPS を本アーキテク チャに基づいて開発中である．さらに，本アーキテクチャ については，他の分野のシステムに対しても適用可能性が あると考えている[27][28]． [15]佐藤 豪一，久川 誠，高橋 和秀，牧野 雄至，神宮司 誠：“分散デ ータ駆動型アーキテクチャを用いたトラヒックコントロールシス テムの設計,”信学技報，Vol. 104，No. 707，pp. 13−18，Mar. 2005． [16]藤井 邦浩，久川 誠，藤嶋 貴志，高橋 和秀，牧野 雄至，神宮司 誠：“分散データ駆動型アーキテクチャによるトラフィック管理 システムの実現,”信学技報，Vol. 104，No. 707，pp. 7−12，Mar. 2005． [17]高橋 和秀，牧野 雄至，神宮司 誠：“分散データ駆動型アーキテ クチャによる大規模 OSS の設計,”信学技報，Vol. 104，No. 707， pp. 43−48，Mar. 2005． [18]“W3C”;http://www.w3.org 文 献 [1] 大貫，ほか：“オペレーションシステム特集,”本誌，Vol. 8，No. 1，pp. 6−30，Apr. 2000． [2] 松本，ほか：“モバイルマルチメディアサービス高度化共通基盤 3 （M In）の開発,”本誌，Vol. 11，No. 2，pp. 70−81，Jul. 2003． [3] PCクラスタ； http://www.pccluster.org/ [4] 水野（松木）由子，伊達 進，甲斐島 武：“グリッド技術による医 用インフラストラクチャ,”信学論（B），Vol. J85 −B，No. 8，pp. 1261−1268，Aug. 2002． [5] 朴 泰祐，佐藤 三久，小沼 賢治，牧野 淳一郎，須佐 元，高橋 大 介，梅村 雅之：“HMCS−G ：グリッド環境における計算宇宙物 理のためのハイブリッド計算システム,”情報処理学会論文誌コン ピューティングシステム，Vol. 44，No. SIG11（ACS 3） ，pp. 1−13， 2003． [6] I. Satoh:“A Framework for Building Reusable Mobile Agents for Network Management,”Proceedings of Network Operations and Managements Symposium（NOMS ’ 2002）, IEEE Communication Society, pp. 51−64, Apr. 2002. [7] D. Gavalas, D. Greenwood, M. Ghanbari and M. O ’ Mahony:“An Infrastructure for Distributed and Dynamic Network Management based on Mobile Agent Technology,”Proceeding of Conference on Communications（ICC ’ 99）,pp. 1326−1366, 1999. [19]“ Business Process Execution Language for Web Services”; http://www-106.ibm.com/developerworks/library/ws-bpel [20]瀬社家 光，木村 伸宏，藤原 健：“オペレーションシステムにお ける輻輳制御の検討,”信学技報，Vol. 99，No. 34, 35，pp. 7−12， Apr. 1999． [21]木村 伸宏，瀬社家 光：“分散 OSS における高信頼化の検討,”信 学技報，Vol. 100，No. 451, 452, 453, 454，pp. 29−34，Nov. 2000． [22]稲森 久由，上田 清，須永 宏：“大規模通信ノードシステムに対 応した TMN 構築支援技術の検討,”信学論（B） ，Vol. J84−B，No. 3，pp. 461−477，Mar. 2001． [23]H. Tojo, H. Ikeda, T. Goto and I. Yoda: “Development Method for the Operation Scenario Program using Script Language,”IEICE, Japan, Vol. J82−B, No. 5, pp. 877−885, May 1999. [24]OGSA; http://www.gridforum.org/mail_archive/ogsa-wg/Archive/ msg00172.html [25]Globus Alliance; http://www.globus.org/ [26]“GT3”;http://www-unix.globus.org/toolkit/about.html [27]秋山 一宜，藤井 邦浩，金内 正臣，渡邉 稔也，高橋 和秀，谷川 延 広：“IP サービスを実現するための分散データ駆動型アーキテク チャの提案,”信学技報，Vol. 102，No. 706，pp. 1−6，Mar. 2003． [28]秋山 一宜，ほか：“分散データ駆動型アーキテクチャによる広告 配信サービスの試作,”IEICE Technical Report，TM2003−114，pp. 19−24，Mar. 2004． [8] 藤井 邦浩，渡邉 稔也，秋山 一宜，高橋 和秀，谷川 延広：“分散 データ駆動型アーキテクチャの実装と性能評価,”信学技報，Vol. 45 用 語 一 覧 BPEL4WS ： Business Process Execution Language for Web Services CORBA ： Common Object Request Broker Architecture CPU ： Central Processing Unit D3A ： Distributed Data Driven Architecture （分散データ駆動型アーキテクチャ） DBMS ： DataBase Management System DNS ： Domain Name System（ドメインネームシステム） EA ： External Adaptor（外部アダプタ） ECIF ： Element Configuration Information File （エレメント構成情報ファイル） ECM ： Element Configuration Manager（エレメント構成マネージャ） GbE ： Gigabit Ethernet（ギガビットイーサネット） GT3 ： Globus Toolkit3 HPC ： High Performance Computing （ハイパフォーマンスコンピューティング） IA ： Intel Architecture IP ： Internet Protocol JDBC ： Java DataBase Connectivity 46 LE ： Logical Element（論理エレメント） LPD ： Logical Path Data（論理経路データ） LPDD ： LPD Driver（LPD ドライバ） LPDM ： LPD Manager（LPD マネージャ） mps ： message per second NE ： Network Element（ネットワーク設備） OGSA ： Open Grid Service Architecture OPS ： OPeration System OSS ： Open Source Software（オープンソースソフトウェア） PE ： Physical Element（物理エレメント） RDBMS ： Relational DataBase Management System RMI ： Remote Method Invocation SOAP ： Simple Object Access Protocol TCO ： Total Costs of Ownership W3C ： World Wide Web Consortium xGSN ： serving/gateway General packet radio service Support Node XML ： eXtensible Markup Language