招待論文 システム開発・ソフトウェア開発論文特集

大規模分散オペレーションサポートシステムの実用化

高橋 和秀†a) 大貫 雅史††b)

A Practical Large-Scale Distributed Operations Support System

Kazuhide TAKAHASHI†a) and Masafumi OONUKI††b)

あらまし 筆者らは，計算機ノード（小規模 IA サーバ）をインタコネクト (GbE) で結合することにより，高い処理能力を得る分散データ駆動型アーキテクチャ(D3A：Distributed Data Driven Architecture) を提案している．筆者らは，D3A を用いて，約 60 種類の個別オペレーションサポートシステム (OSS：Operations

Support System) を集約し，シングルシステムとして実用化した．本 OSS は，約 5,300 万の加入者を収容するモバイルネットワークを管理するための大規模分散システムであり，約 1,200台の計算機ノードから構成される．この実用化においては，複数の DNS ドメインを結合することにより，数千台の計算機ノードの連動を可能とした．また，二つのアプリケーション流用粒度を定義することにより，流用性を向上した．更に，XML を用いて記述する NE (Network Element) 仕様定義を実装し，ウォーターフォール型開発プロセスの開発工数を削減した．本システムは 2006 年に稼動を開始し，安定した運用実績を上げている．

キーワード オペレーションサポートシステム，ネットワークエレメント，大規模分散システム，SOA

1. ま え が き

通信ネットワークは，伝送装置，スイッチ，ルータ，

基地局，無線制御装置，交換機，サーバなどの多種多

様なネットワーク機器から構成される．これらのネッ

トワーク機器は，NE (Network Element) と呼ばれ

る．これらの NE の総数は数万ノードにも及ぶ場合

があり，地理的に分散配置される．これらの NEを一

元的に集約し，NEからの警報やネットワークを流れ

るトラヒックを監視し，NEの故障やネットワークの

ふくそうに対する回復措置を行うシステムをオペレー

ションサポートシステム (OSS：Operations Support

System)と呼んでいる（図 1）．OSSが支援する業務

は，NE監視制御業務，NE建設業務，NE維持管理業

務，トラヒック監視制御業務，トラヒックデータ管理

業務（設備計画，品質分析）など，多岐にわたる．通

†（株）NTT ドコモ ネットワーク開発部，横須賀市Network Development Department, NTTDoCoMo, Inc., 3–6

Hikarinooka, Yokosuka-shi, 239–8536 Japan††ドコモ・テクノロジ株式会社 NW マネジメント事業部，横須賀市

Network Management Department, DOCOMO Technology,

Inc., 3–6 Hikarinooka, Yokosuka-shi, 239–8536 Japan

a) E-mail: takahashikazu@nttdocomo.co.jp

b) E-mail: oonuki@docomo-tech.co.jp

信ネットワークの拡大に伴い，ネットワーク管理業務

の効率化の重要性が増し，これまでに様々なOSSが個

別に開発されてきた [1]．このように，OSS は，数万

ノード以上の NEを管理し，その業務アプリケーショ

ンも多岐にわたる，大規模システムであることから，

高い拡張性が求められる．

OSS の故障やふくそうにより，故障した NE から

の警報がネットワーク管理者に通知されない場合，そ

の故障やふくそうに対する回復措置が遅れ，通信サー

ビスの停止やサービス品質の低下が長期化するおそれ

がある．このように，OSSは，ミッションクリティカ

ルなシステムであるため，高い可用性も同時に求めら

れる．

高い拡張性と可用性を実現するために，OSSを大規

模分散システムとして構成する方法が考えられる．計

算機の演算性能を競う TOP500 [4]においては，数多

くの計算機ノード（小規模 IAサーバ）をインタコネ

クト (GbE)で結合したクラスタ構成が，主流となって

いる．小規模 IAサーバやGbEは，コモディティと呼

ばれ，そのユーザ層の裾野が広いため，低価格かつ高

品質であることを特長とする．したがって，このクラ

スタ構成を用いて，多数の個別 OSS を統廃合し，大

規模なシングルシステムへと集約することにより，そ

970 電子情報通信学会論文誌 B Vol. J92–B No. 7 pp. 970–980 c©（社）電子情報通信学会 2009

招待論文／大規模分散オペレーションサポートシステムの実用化

図 1 OSS 概 要Fig. 1 Overview of OSS.

の TCO (Total Costs of Ownership)（注1）を大幅に削

減することが可能である．

近年，ユーザ利便性の高い通信サービスを一般コン

シューマに提供することを目的として，3GPPによる

AIPN [2] や ITU-T による NGN [3] などの，ネット

ワークの All-IP化に向けた標準化活動が活発である．

今後，これらに向けたネットワークの移行や拡大が，

急速に進展することが予想される．OSS は，ネット

ワークの移行や拡大においても，その業務の効率化に

重要な役割を果たす．したがって，通信キャリヤが市

場シェア獲得競争を制するためには，その業務アプリ

ケーションを，迅速かつ低コストで開発することも，

重要な課題である．

本論文では，筆者らが実用化した大規模分散 OSS

について述べる．本OSSは，約 1,200台の計算機ノー

ドから構成されており，拡張性，可用性，及びアプリ

ケーション生産性の高さを併せ持っている．まず，本

OSSにおいては，複数の DNSドメインを結合したク

ラスタ構成を採用しているため，拡張性と可用性が高

い．また，二つのアプリケーション流用粒度を定義し

ていることから，木目細かな流用が可能である．更に，

NE仕様を XMLを用いて記述できることから，新し

い NE に対応する業務アプリケーションを，迅速か

つ低コストで開発することが可能である．本 OSSは，

2006 年に稼動を開始し，安定した運用実績を上げて

いる．

2. 大規模OSSの要件と関連研究

筆者らが実用化した OSSは，多数の個別 OSSを統

廃合し，シングルシステムに集約した大規模分散 OSS

である．本 OSS の性能要件を図 2 に示す．本 OSS

は，最大で 1秒間に 2,400件もの大量の自律メッセー

図 2 大規模 OSS の性能要件Fig. 2 Performance requirements for the large-scale

OSS.

ジ（警報を含む）を処理し，約 37 TByteものトラヒッ

クデータを常時蓄積する．

2. 1 拡張性の実現

通信ネットワークは，地理的に拡大し，機能的に進

化する．大規模分散OSSについては，通信ネットワー

クの成長に対応して，これを構成する多種多様な NE

を収容し，そのハードウェア構成やソフトウェア構成

を柔軟に拡張できるアーキテクチャが必要である．ま

た，大小様々な規模の通信キャリヤの通信ネットワー

クに対応するためには，小規模な通信ネットワークか

ら，大規模な通信ネットワークまで，幅広いレンジで，

柔軟に対応できる伸縮性をもったアーキテクチャが必

要である．

文献 [5]では，分散構成のコンピュータの故障と負荷

を，複数のコンピュータを用いて分散管理することに

より，アクセスネットワーク系OSSを高信頼化する三

つの方式を提案している．[5]は，三つの提案方式につ

いて，システム信頼度（非故障率）とアプリケーショ

ン処理時間を評価しているが，位置透過性をもつ大規

模分散システムとして，どの程度まで計算機ノード数

を拡張できるのか，についての評価がなされていない．

また，文献 [6]では，OSF/DCEを用いて，IPネット

ワークを管理する OSS をスケーラブルに構成する方

法を提案している．[6]は，計算機ノード間通信のオー

バヘッドを性能評価しているが， [5] と同様の拡張性

と，可用性についても，議論がなされていない．また，

文献 [7]では，OSSの業務アプリケーションの欠陥に

よる故障が発生した場合，その初期化範囲を局所化す

（注1）：総所有コスト．計算機システムを導入し，廃棄するまでに必要となるコストの総額．導入コストとランニングコストから構成される．

971

電子情報通信学会論文誌 2009/7 Vol. J92–B No. 7

ることで，コアネットワーク系 OSS を高可用化する

方法を提案している．[7]は，共通プロセスが再開する

場合は，その計算機ノードに配置されているすべての

プロセスの初期化（再開）を伴うため，初期化による

影響範囲が広く，故障局所性が低いだけでなく [5], [6]

と同様に拡張性の評価がなされていない．このように，

大規模 OSS の必須要件である拡張性と可用性の両面

から，実用的なシステムの報告は見当たらない．

2. 2 アプリケーション生産性の向上

アプリケーションプログラムの LOC (Line Of

Code)（注2）の大きさに対応して，開発費は増減する．

また，LOCが同程度のプログラムを開発する場合は，

その開発プロセスに要する開発稼動（開発工数）に対

応して，開発費は増減する．したがって，アプリケー

ションの生産性を向上するためには，LOCの削減（つ

まり，流用性の向上）と開発工数の削減の二つの方法

が考えられる．

（ 1） 流用性の向上

ソフトウェアの流用性を向上させるためには，複数

のソフトウェア粒度（メソッド，クラス，コンポーネ

ント，サービスなど）を考慮して，木目細かな流用を

可能とするアーキテクチャが必要である．OSSの業務

アプリケーションについては，NEの装置監視制御業

務やトラヒック監視業務などのアプリケーションを構

成するソフトウェアの流用の粒度に比較し，NEのソ

フトウェアを全体的に更新する業務（アップグレード）

や NEのソフトウェアにプラグイン（注3）を適用する業

務（バグフィックス）などのアプリケーションを構成

するソフトウェアの流用の粒度は，非常に小さい．

文献 [8] では，OSS の業務アプリケーションを

EJB（注4）を使ってコンポーネント化することにより，

その生産性を向上することを提案し，実際に EJB を

用いて大規模トラヒックデータを扱う方法を性能評価

している．しかし，その業務アプリケーションの流用

性の向上について，定量的な評価は，示されていな

い．また，OSSを開発するための API仕様を標準化

する活動に OSS/J (OSS through Java) [9] がある．

OSS/Jにおいては，OSSの業務アプリケーションの

各機能を EJB のコンポーネントとして，そのインタ

フェースを規定している．OSS/Jについては，リファ

レンスとなる実装や API 仕様のコンフォーマンステ

ストツールが提供されているが，ネットワークに導入

される，様々な新しい NE仕様に対し，これらの API

を用いて柔軟に追従する方法については，規定されて

いない．

（ 2） 開発工数の削減

OSS の業務アプリケーションのリリース期限が遅

延すると，ネットワークの移行や拡大が遅延し，通信

キャリヤの市場シェア獲得競争に深刻な影響を与えか

ねない．したがって，OSSの開発プロセスに対しては，

初期開発工程で決められた要求機能について，リリー

ス期限を厳守し，品質を確保し，性能要件を満足する

ことが，高く要求される．従来のウォーターフォール

型開発プロセスについては，各開発工程の生産物が明

確に定義されており，進捗を制御可能なため，リリー

ス期限を守りやすい，品質を確保しやすい，などの長

所がある．したがって，これらの長所を生かしつつ，

開発工数を削減できるように，ウォーターフォール型

開発プロセスを改良する必要がある．

ソフトウェア開発プロセスには，ウォーターフォー

ル型開発プロセスと反復型開発プロセスの二つが存在

する．最近，反復型については，前述したウォーター

フォール型の欠点を克服したアジャイル開発 [10]が注

目されている．しかし，本開発プロセスは，10人程度

で行う小規模システムに適用されるケースがほとんど

である．一方，我々が開発している大規模OSSは，数

Mstepにも及ぶ巨大なソフトウェアであり，数百人規

模の開発プロジェクトとなる．したがって，開発プロ

ジェクトのすべてのステークホルダ（注5）に，臨機応変

なコミュニケーションを要求することを特徴とするア

ジャイル開発は，適用できない．

3. 分散データ駆動型アーキテクチャとその課題

筆者らは，複数の計算機ノード（小規模 IAサーバ）

（注2）：ソフトウェアの規模を表す指標の一つ．空行やコメント行などを除いたソースコードの行数．（注3）：ソフトウェアに追加機能やバグフィックスを提供するための小さなサブルーチンプログラム．ユーザに対して，規格化されたサブルーチンの呼び出し手順と差し替え手順が公開されているため，ユーザがサブルーチンを差し替えることで，ソフトウェアの機能を追加できるようになる．ダイナミックリンクライブラリを用いて，メモリのアドレスを間接的に参照することにより，実行時にリンクが行われる．（注4）：Java 言語を用いて開発されたプログラム部品（コンポーネント）をネットワークを経由して呼び出す仕様．ビジネスロジック (Enterprise

Beans) と，データベース処理やトランザクション処理などのシステムサービスを利用したロジック（コンテナ）を分離し，その間の仕様を規定している．（注5）：ソフトウェア開発プロジェクトにおいて，意思決定を行うか，開発作業や開発するソフトウェアの影響を受ける個人，または組織．ステークホルダとしては，発注者，プロジェクトマネージャ，SE，プログラマ，エンドユーザなどが挙げられる．

972

招待論文／大規模分散オペレーションサポートシステムの実用化

をインタコネクト (GbE) で結合したクラスタ構成を

用いて，分散システムを実現する手段として，分散

データ駆動型アーキテクチャ(D3A：Distributed Data

Driven Architecture)を提案している [11]．本章では，

D3Aと，その課題について説明する．

3. 1 分散データ駆動型アーキテクチャ(D3A)

本アーキテクチャを図 3 に示す．ハードウェアの構

成要素を PE (Physical Element)と呼び，ソフトウェ

ア（OSSの業務アプリケーション）の構成要素を LE

(Logical Element)と呼ぶ．計算機ノード（小規模 IA

サーバ）が PEに相当する．ここで，小規模 IAサー

バとは，2 CPU以下の IAサーバを意味する．LEは，

業務アプリケーションを分割した並列実行単位であり，

PEに分散配備される．複数の LEを組み合わせるこ

とにより，一つの業務アプリケーションを構成する．

3 GHz以上の CPUを搭載した非常に高性能な PEが，

高速なGbEで結合されるため，LE間は高速な通信が

可能である．LPD (Logical Path Data)は，論理経路

定義とアプリケーションデータ定義の二つのパートか

ら構成される．各 LEは，前段の LEから LPDを受信

すると，自分が処理するべきアプリケーションデータ

だけを，LPDから抽出して処理し，その処理結果をア

プリケーションデータに再び設定して，次段の LEに

送信する．各 LPDのアプリケーションデータ定義は，

その論理経路における LE間の共通インタフェースと

みなすことも可能である．LPDD (LPD Driver) は，

LPDの経路制御を行うドライバであり，LPDの論理

経路定義に基づいて，LPDを LE間で論理的に経路制

御する．また，LPDDは，DNSを用いて LEインス

タンスの名前解決を行うことにより，LPDを物理的に

経路制御する．LPDDは，冗長構成を制御する機能や，

LEの故障を管理する機能などから構成され，本アー

キテクチャのプラットホームとなっている．論理経路

上に存在する仮想的な LEを LEクラスと呼び，物理

系路上に存在する PEに実装された LEを LEインス

タンスと呼ぶ．LPDM (LPD Manager)は，LPDの

原本を管理しているデータベースである．また，NA

(NE Adaptor)は，本アーキテクチャの外縁に配備さ

れ，NEインタフェースの違いを吸収し，共通インタ

フェース（すなわち，LPD）に変換する機能を有する．

エレメント構成マネージャ(ECM：Element Config-

uration Manager) は，エレメント構成情報ファイル

(ECIF：Element Configuration Information File)に

記述されたすべての LEに対して，LPDの送受信を用

図 3 D3A の概念構成Fig. 3 Distributed Data Driven Architecture (D3A).

いてヘルスチェック（注6）を行い，無応答の PEを検出す

ると DNSから該当のエントリを削除することにより，

故障した PEをシステム全体から隔離する．ECIFに

は，LEと PEの対応関係や LEの冗長構成方式などの

構成情報を記述する．各 LEは，初期起動時に ECM

から ECIFを取得し，故障処理時などに参照する．PE

の増設や減設により，ECIFが変更された場合，ECM

はすべての LPDDに対して新しい ECIFの変更を通

知する．LE，LPDD，LPDM，及び ECM について

は，異機種サーバへのポータビリティを確保するた

めに，Javaにより記述し，LCD及び ECIFについて

は，異機種サーバ間接続を考慮し，XMLにより記述

する．本アーキテクチャは，IA サーバに分散配備さ

れた LE（Java アプリケーション）を，LPD（XML

データ）により駆動することを特徴としている．この

ような理由から，本アーキテクチャを，分散データ駆

動型アーキテクチャ(D3A：Distributed Data Driven

Architecture)と呼んでいる．

LPDを論理的に経路制御するためのタグとしては，

六つのタグ定義があり [11]，その振舞いについては，

W3CのWS-BPEL [12]に基本的に準拠している．ま

た，経路制御の通信方法には非同期型と同期型を指定

することが可能である．図 4 においては，<flow>タ

グを用いて，LE2から LE3と LE4に対して LPDを

並列に分岐するように経路制御している．<flow>タ

グによる並列経路制御の LPD処理能力は，非同期型

で約 900 mpsである．mps (message per second)は

（注6）：複数の計算機ノードから構成されるネットワークシステムにおいて，計算機ノードやネットワーク機器が正常な状態にあるかどうかを，定期的に自動監視すること．

973

電子情報通信学会論文誌 2009/7 Vol. J92–B No. 7

1秒間に処理できるメッセージ数である．

また，D3Aは，3種類の冗長構成 [13]を具備してい

るだけでなく，OSSの業務アプリケーションを分割し

て，数多くの計算機ノードに分散配備するため，故障

局所性も高い．したがって，D3Aは，非常に可用性の

高いアーキテクチャとなっている．

3. 2 D3Aの課題

（ 1） 拡張性に関する課題

筆者らは，FOMAパケットネットワーク対応のOSS

に D3Aを適用した．本 OSSは，一つの DNSドメイ

ン内に収容された，数十台の計算機ノードから構成さ

れている．ところが，本論文で実用化を目的としてい

る大規模分散 OSS は，計算機ノード数が数百～数千

にも及ぶ．つまり，D3A を用いて，数千台の計算機

ノードから構成される大規模分散システムを構築する

方法は，課題として残されていた．

（ 2） アプリケーション生産性に関する課題

D3A においては，既に開発済みの LE（Java アプ

リケーション）を流用し，新しい LEと LPDを開発

するだけで，新しい業務に対応した機能追加を行うこ

とが可能である．このような理由から，D3Aは，アプ

リケーションの流用性が高いアーキテクチャであると

いえる．しかし，LEの粒度は 1種類であり，この LE

単位の流用しかできない．つまり，LE 内部を構成す

るソフトウェアについて，更に木目細かな流用を実現

する方法は，課題として残されていた．また，FOMA

パケットネットワーク対応の OSS を開発する際に適

用した開発プロセスは，単純にウォーターフォール型

を D3A に当てはめたものであった [14]．つまり，本

開発プロセスの開発工数を削減する方法も，課題とし

図 4 <flow> タグによる論理経路制御Fig. 4 Logical path control by the use of <flow> tag.

て残されていた．

4. 課題解決策

4. 1 拡張性の向上

D3Aは，LPDDによる自律分散制御方式を採用し

ており，基本的に，PE や LE に性能的なボトルネッ

クが発生しにくいアーキテクチャとなっているが，LE

インスタンスの名前解決処理については，DNSによる

集中管理方式を採用しており，性能的なボトルネック

となる懸念があった．そこで，DNSの負荷を分散する

ために，複数の DNSドメインを結合して，拡張性を

向上できることを検証した（図 5）．DNSの総レコー

ド数については，1 NE当りの平均レコード数と総NE

数から算出し，5万件を性能要件とした．測定環境と

しては，DNSは BIND9.2.2，J2SEは JDK5.0，OS

は RedHat Linux ES3.0，CPUは 3.60 GHz× 2（シ

ングルコア），メモリは 2 GByteとした．各ドメイン

の DNSには，全ドメインの NSレコードを登録して

おく．ドメイン間の問合せには，フォワーダを利用す

る．ここで，複数ドメインをまたがった，LPD経路制

御においては，名前解決処理を 2 回行うことになる．

そこで，ゾーン情報検索応答時間，ゾーン情報検索処

理能力，及びゾーン情報更新応答時間を測定し，名前

解決処理において，性能劣化がないことを評価した．

キャッシュ時間を 10秒とした場合，ドメイン間のゾー

ン情報検索応答時間は，約 0.5 msと高速で，ドメイン

内のそれとほぼ同等であり，総レコード数に対する依

存性もない．また，同条件の場合，ゾーン情報検索処

理が 200万 tpsでも，CPU使用率は 2%以下であり，

安定してゾーン情報検索が可能であった．また，ゾー

図 5 複数の DNS ドメインの結合Fig. 5 Multiple DNS domains.

974

招待論文／大規模分散オペレーションサポートシステムの実用化

図 6 enhanced D3A

Fig. 6 enhanced D3A.

ン情報更新応答時間についても，180 msと高速であっ

た．これらの性能評価結果から，複数の DNSドメイ

ンを結合することで，D3A の拡張性を向上できるこ

とが分かった．

4. 2 アプリケーション生産性の向上

4. 2. 1 流用性の向上

2.2（ 1）で述べた二つの粒度について，異なる LE

を定義し，流用性の向上を図ることにした．粒度の大

きな LE をラージ LE，粒度の小さな LE をスモール

LE と呼び，以降それぞれ，LEl，LEs と表記するこ

とにする．LE間通信の効率性を考慮し，基本的には，

LEl を 1 台の計算機ノード（IA サーバ）に一つ配備

し，LEs を 1台の計算機ノード（IAサーバ）に多数

配備することにした．本アーキテクチャを enhanced

D3A (eD3A)と呼ぶ（図 6）．ここでは，LEl をデータ

駆動する LPDを LPDl，LEs をデータ駆動する LPD

を LPDs と表記することにする．本アーキテクチャに

基づけば，より小さな単位で LEを流用し，新しい業

務アプリケーションを柔軟かつ迅速に機能追加するこ

とができる．

eD3A の構成を図 7 に示す．ここで，LEl，LPDl，

LPDlD，及び LPDlM は，それぞれ，D3A の LE，

LPD，LPDD，及び LPDMそのものである．LEs は，

2.2（ 1）で述べた NE のファイル更新業務やプラグ

イン業務などの業務を実現するアプリケーションの構

成要素であり，LEl に比較し，その粒度が非常に小さ

い．LPDs には，LEs の処理順序や LPDs と LEs と

の間で送受するアプリケーションデータなどを記述す

る．LPDsD (LPDs Driver)は，LPDs を構文解析し

て次に呼び出すべき LEs を決定するドライバである．

すなわち，LPDsD は，LPDs に基づいて LEs を駆

動する．LPDsM (LPDs Manager)は，LPDs を管理

図 7 eD3A の構成Fig. 7 eD3A configuration.

するデータベースである．LPDlG (LPDl Generator)

は，LEs の要求に基づいて，LPDl を生成するジェネ

レータである．LPDsD，LPDsM，及び LPDlGにつ

いては，D3A と同様に異機種サーバへのポータビリ

ティを確保するために，Javaにより記述する．これら

の構成要素は，初期開発後は，機能追加が発生しない

eD3Aのプラットホームである．LPDs 及び LEs つい

ては，NE業務手順の仕様変更により，頻繁に機能追

加が発生すると考えられるため，XMLによりスクリ

プトレベルで記述する．LPDs と LEs を記述するた

めのタグ定義については，文献 [15]を参照されたい．

また，筆者らが実用化したシステムにおいては，LEs

の場合，50 step以下の流用単位が全体の約 80%を占

め，LEl の場合，1,000 step以上の流用単位が全体の

約 90%を占めている．

4. 2. 2 開発工数の削減

D3Aにおける従来のウォーターフォール型開発プロ

セスは，ED（外部設計），BD（基本設計），FD（機能

設計），DD（詳細設計），M（製造），UT（単体試験），

IT（LE内結合試験，LE間結合試験，NE結合試験），

ST（システムテスト）の開発工程から構成され，M

を頂点とした V字型のモデルとして表現される．各工

程で問題が発生した場合は，当該工程より前の開発工

程に適切なフィードバックを行うことで品質をコント

ロールする．このウォーターフォール型開発プロセス

において，いくつかの開発工程を統廃合することが可

能であれば，開発プロセスを大幅に効率化できる．NE

仕様をコンパイルが不要な軽量プログラミング言語を

用いて，直接コーディングできれば，開発プロセスを

BI工程，M工程，及び ST/IT（NE結合試験）工程

975

電子情報通信学会論文誌 2009/7 Vol. J92–B No. 7

図 8 ウォーターフォール型開発プロセスの改善Fig. 8 Improvement in waterfall development pro-

cess.

図 9 NE 仕様の XML 表現Fig. 9 XML expression of NE specifications.

に削減できる（図 8）．筆者らは軽量プログラミング言

語として XMLを採用した．ここでは，XMLで記述

した NE 仕様を NE 仕様定義と呼ぶ（図 9）．開発プ

ロセスには，XMLを設計する XD (XML Design)工

程と，製造した XMLソースコードの妥当性を検証す

る XT (XML Test)工程を新規に追加する．

NE 仕様の変更や追加については，以下の（ 1）～

（ 8）のパターンに分類される．ここでは，これらのパ

ターンについて，XMLで記述できる NE仕様を明確

にする．新しい NEが導入される場合は，これらのパ

ターンの組合せとなる．

（ 1） NE～OSS間プロトコル仕様の変更と追加

D3Aにおいては，NE種別ごとに異なる NE～OSS

間プロトコル仕様の差異を NA (NE Adaptor)で吸収

している．NA と LE 間で送受信される各 LPD につ

いて，そのアプリケーションデータ部のデータ構造を

NE種別とは無関係に共通化した．したがって，本仕

様変更に関する影響は，NAに局所化されているため，

各 LEクラスが受け持つ機能を容易に共通化すること

ができる．ただし，NA の開発プロセスについては，

コンパイル言語である Java でコーディングし，従来

のウォーターフォール型開発プロセスに準拠する．つ

まり，XMLで記述できる NE仕様はない．

（ 2） 警報仕様の変更と追加

警報や警報状態取得コマンドとその応答に含まれる

文字列は，NE種別ごとに異なる．そこで，この文字

列操作については，警報装置状態合せ LEクラスに局

所化した．新しい警報が追加された場合，警報装置状

態合せ LEクラスについて，Javaソースコードの該当

文字列を操作する箇所を改修するだけである．また，

警報仕様のうち警報重要度については，OSSユーザが

変更できる NE仕様定義とした．

（ 3） コマンド仕様の変更と追加

コマンド仕様の変更と追加については，基本的に

Java ソースコードに対する影響がないように考慮し

た．ただし，（ 7）と（ 8）の業務において用いるコマン

ドに関する仕様の変更と追加に関しては，XMLソー

スコードに対する影響がある．また，誤操作防止やセ

キュリティ保護を目的として，その投入を制限するコ

マンドの指定については，OSS ユーザが変更できる

NE仕様定義とした．

（ 4） 装置構成の変更と追加

装置構成の包含関係を NE仕様定義とした．警報状

態，装置状態，工事中状態の上位装置への集約（伝搬）

は，この定義により自動的に行われる．装置状態変更

通知（自律メッセージ）や装置状態取得コマンドとそ

の応答に含まれる文字列は，NE 種別ごとに異なる．

そこで，この文字列操作についても警報装置状態合せ

LEクラスに局所化した．新しい装置が追加された場

合，警報装置状態管理 LEクラスにおいて XMLソー

スコードを追加し，警報装置状態合せ LEクラスにお

いて，Javaソースコードの該当文字列を操作する箇所

を改修するだけである．

（ 5） NE構成データ仕様の変更と追加

NEは，NEの装置構成，対向する NEとの接続構

成，トランスレータ（番号翻訳）などを表現するデー

タに基づいて呼処理を行っている．NE が保持する，

これらのデータを NE 構成データと呼んでいる．NE

構成データ仕様は，NE 種別ごとに異なる．NE 構成

データの物理的形式については，バイナリー形式の

ファイルを必要とする NE，テキスト形式のファイル

を必要とする NE，テキスト形式のコマンドを必要と

する NEなどがあり，その仕様は多種多様である．ま

た，NE構成データの論理的な意味や値に関する一貫

性チェック条件は，複雑であり，多岐にわたる．筆者ら

976

招待論文／大規模分散オペレーションサポートシステムの実用化

は，すべての NE構成データを OSSユーザが汎用の

XMLエディタで編集できる NE仕様定義とした．こ

れにより，従来，開発コストの大半を占めていた NE

構成データを入力するための GUI による編集画面の

開発コストを大幅に抑制できる．また，NE構成デー

タのデータ項目間やテーブル間の一貫性チェック条件

についても，NE仕様定義とした．更に，XMLから，

前述した NEが必要とする物理的形式への変換論理に

ついても，NE仕様定義とした．これらの NE仕様定

義の詳細については，文献 [16]を参照されたい．

（ 6） トラヒックデータ項目仕様の追加

OSSは，NEからトラヒックデータを定期的に収集

し，データベースに蓄積する．トラヒックデータ項目

仕様は，トラヒックデータ項目名，カウンタ種別（無

限，有限），蓄積有無，ふくそう判定実施有無，計算式

などの属性から構成される．これらのトラヒックデー

タ項目仕様とこれを格納するテーブル構成を NE仕様

定義とした．また，このテーブルに登録したり，参照

したりするクエリについても，NE仕様定義とした．

（ 7） NE業務手順の変更 (eD3A)

ファイル更新業務，プラグイン業務，NE構成デー

タ変更業務などの効率化を目的として，その手順が

変更になる場合がある．また，警報仕様やコマンド仕

様の変更や追加に伴い，これらの業務の手順が変更

になる場合もある．更に，業務手順については，OSS

ユーザの要求条件も加味する必要がある．筆者らは，

eD3Aを用いて，業務手順（LPDs と LEs）を XML

スクリプトで記述する NE仕様定義とした．これによ

り，OSSユーザも業務手順の変更を柔軟に行うことが

できる．

（ 8） トラヒック制御業務手順の変更

特定の NEのふくそう状態を検出し，他の NEから

の通信トラヒックがふくそう中の NEへ流入すること

を規制することにより，ふくそう状態を鎮静化させる

業務をトラヒック制御業務と呼んでいる．新しい通信

サービスを提供するためには，いくつかの NEへの機

能追加が必要となる．この機能追加により，NE間の

呼処理シーケンスが変更となるため，ふくそうパター

ンも変化する．また，おめでとうコールや地震などの

広域災害時のお見舞いコールをはじめ，数多くのふく

そうパターンが存在する．更に，特定の場所への移動

機端末の集中などの社会現象や，スパムメールなどに

代表される外部ネットワークからのトラヒックの増加

により，ふくそうパターンが変化することもある．本

手順も NE業務手順と同様に，XMLスクリプトによ

り記述する NE仕様定義とした．

5. 評価と議論

5. 1 拡 張 性

D3Aに基づいて構成する，システムのハードウェア

設計においては，LEクラスが必要とする処理能力だ

け，PEを静的に割り当てる（図 10）．LE間通信に用

いる LPDは，DNSを用いて物理的に経路制御される

ため，LEインスタンスは位置透過性をもつ．つまり，

LEインスタンスは，どの PEに配置されても，アプ

リケーションの改造を伴うことがない．このため，NE

のノード数が少ないなどの理由で，ハードウェアコス

トを抑制したい場合は，計算機リソースの制限内であ

れば，一つの PEに複数の LEインスタンスを集約で

きるだけでなく，NEのノード数が数万にも及ぶこと

が予想される場合は，一つの PEに一つの LEインス

タンスを割り当てることにより，LE クラスの処理能

力を伸縮することができる．

D3A に基づいて構成されたシステムの処理能力を

向上する方法として，PEを増設する方法（ハードウェ

ア増設）と処理能力の余っている PEに LEインスタ

ンスを増設する方法（ソフトウェア増設）の 2通りが

選択できる．どちらの場合でも，システムを停止する

ことのない動的な増設が可能である．

ECMによるヘルスチェックの性能限界から，1ドメ

イン内の PEと LEインスタンスの最大数は，それぞ

れ 600と 1,800としている．検証環境で動作確認可能

であったドメイン数は 10 ドメインまでであり，これ

をドメイン数の最大数として設計することにしている．

図 10 拡 張 性Fig. 10 Scalability.

977

電子情報通信学会論文誌 2009/7 Vol. J92–B No. 7

図 11 Web サービスと D3A

Fig. 11 Comparison between Web service and D3A.

したがって，D3Aは 1～6,000台の計算機ノード（小

規模 IAサーバ）に対応できるハードウェア伸縮性を

有する．実用化した大規模分散 OSSは，六つの DNS

ドメインに収容された約 1,200台の計算機ノードから

構成される（図 5）．

Webサービスとの比較で，拡張性を議論する．D3A

は SOA (Service Oriented Architecture)の一種であ

り，LE がサービスコンポーネントに，ワークフロー

が LPDに対応する．Webサービスを用いたシステム

のアーキテクチャを図 11 (a)に示す．図 11 (a)では，

ワークフローから各サービスコンポーネント SC1～

SCnを集中的に呼び出している．したがって，ワーク

フローを実装した計算機ノードが性能的なボトルネッ

クとなった場合は，本ワークフローによる処理を複数

のサーバに分散配備できないため，アプリケーション

の改造を必要とするケースが懸念される．また，いず

れかのサービスコンポーネントを搭載したサーバが性

能的なボトルネックとなった場合，ワークフローから

各サービスコンポーネントへの電文振り分け処理が必

要となり，アプリケーションの改造を必要とするケー

スが懸念される．一方，D3A においては，図 11 (b)

に示すように，ワークフローは，LPD に相当するた

め，そもそも集中制御は必要としない．また，サービ

スコンポーネントは，LEに相当し，LEについては，

何らかの単位で分割可能な設計を，基本設計工程から

義務づけており，設計書レビューの観点としている．

このように，D3Aにおいては，LPDDによる自律分

散制御方式を採用しており，基本的に，PE や LE に

性能的なボトルネックが発生しにくいアーキテクチャ

となっている．

5. 2 可 用 性

従来，通信キャリヤは，ネットワーク管理業務を支

援する複数種類の個別 OSS を利用してきた．この個

別 OSSは，大規模 UNIXサーバを用いて構成される

ことが多く，ハードウェア故障やファイル更新に伴う

フェイルオーバなどにより，業務アプリケーションの

処理中断の影響を受ける機能範囲が大きい．このとき，

その個別 OSS が提供するすべての機能が停止したこ

とを，OSSユーザは明確に認識する．つまり，従来の

個別 OSSについては，その故障局所性が低い．

一方，D3Aにおいては，nACT（ラウンドロビン）

型，nACT（並列実行）型，及び nACT/mSBY型の

三つの冗長構成を実装した [13]．小機能に分割された

LE に対して，小規模 IA サーバ (PE) を複数割り当

てることにより，これらの冗長構成を実現する．この

ため，一つの PEが故障しても，クライアントの画面

に一時的にエラーが表示されるなど，業務アプリケー

ションの一部が一時的に使用不可になったことを，OSS

ユーザは認識するのみである．このように，D3Aは，

故障局所性が高く，クライアントの背後にあるサーバ

の構成を意識させないアーキテクチャとなっている．

5. 3 生 産 性

筆者らが実用化した大規模分散 OSS に対して行っ

た，ある機能追加開発において，Java 及び XML で

コーディングしている部分を定量的に評価する．

（ 1） 機能追加の局所性に関する評価

この開発において，ソースコードの改修が発生した

LEクラスは 18種類であった．新しい NEの導入に伴

い，Java による改修を必要とした LE クラスは 5 種

類であり，XML による改修を必要とした LE クラス

は 18種類であった．一方，既存 NEへの機能追加に

伴い，Javaによる改修を必要とした LEクラスは，0

であり，XMLによる改修は，わずか 2種類であった

（表 1）．この評価結果から，既存 NEへの機能追加に

伴う，本 OSS への機能追加については，改修の局所

性が高いと判断している．

（ 2） 開発規模に関する評価

この開発において，本 OSS に機能追加を行った際

の LOC (Line Of Code)，及び，別の開発において，

従来方式の OSS（大規模 UNIXサーバ及び市販ミド

ルウェアを用いて構成されていた）に機能追加を行っ

た際の LOC とを分析した結果を図 12 に示す．これ

ら二つの開発の内容は異なるが，平均的な開発を抽出

している．母体の LOCに対する，その開発において

978

招待論文／大規模分散オペレーションサポートシステムの実用化

表 1 生産性評価（局所性）Table 1 Evaluation of productivity for localizing

modifications.

図 12 生産性評価（開発規模）Fig. 12 Evaluation of productivity for LOC (Line Of

Code).

改修した LOC の割合を算出した．従来方式の OSS

（C++によりコーディング）については，この割合が

14.3%に達しているのに対し，D3Aに基づいて開発し

た本 OSS の割合は Java で 0.9%，XML で 13.3%で

あった．コンパイル言語である Java の LOC が小さ

く，データやスクリプトである XMLの LOCが大き

い．この評価結果から，本 OSS は XML で記述でき

る部分が多く，開発工数の削減に寄与していることが

分かる．

6. 適 用 範 囲

D3A 及び eD3A を適用し，実用化した大規模分散

OSS においては，NE 監視制御業務，NE 建設業務，

NE維持管理業務，トラヒック監視制御業務，及びト

ラヒック管理業務（設備計画，品質分析）の 5種類の

業務を支援するアプリケーションを実現した．

D3A を適用することが困難である業務領域につい

て考察する．現状，D3A は，WS-TX [17] が規定し

ている 2フェーズコミット機能のような，分散配備さ

れたデータについて，その一貫性を保証する機能を実

装していないため，分散された複数テーブルの同期更

新を必要とするデータベースシステムには使えない．

また，WS-S [18]が規定している署名や暗号化のよう

なセキュリティ機能を実装していない．したがって，

データの信頼性や安全性を要件とする顧客管理系の業

図 13 ターンアラウンドタイムFig. 13 Turnaround time.

務アプリケーションへは，適用できない．

直列に四つの PE を接続した場合，TAT (Turn

Around Time) は，非同期型で約 0.7 ms，同期型で

約 2.5 msである（図 13）．直列に接続する PEの数が

増えると，更に TATが増大する．したがって，数ms

以下のリアルタイム性が要求されるアプリケーション

に，D3A を適用できない．ネットワーク管理業務に

おいて，数 ms以下のリアルタイム性が要求される業

務アプリケーションはない．OSS の業務アプリケー

ションではないが，音声/画像通信系，金融/証券系，

フィードバック制御系などの数 ms以下のリアルタイ

ム性が要求されるアプリケーションには，D3A を適

用できない．

7. む す び

本論文では，多数の計算機ノード（小規模 IAサー

バ）を束ねて高処理能力を得ることが可能な，D3A

を概観するとともに，このアーキテクチャに基づいて

実用化した大規模分散 OSSについて述べた．本 OSS

は，拡張性，可用性，及びアプリケーション生産性の

高さを併せ持つ大規模分散システムである．本システ

ムは，外部条件の急激な変動においても，ハードウェ

ア資源が不足している場合は PEを，ソフトウェア資

源が不足している場合は LE を，DNS とエレメント

構成マネージャ(ECM)にエントリを追加するだけで，

柔軟に増設できる．また，本システムにおいては，二

つの LE粒度を定義したこと，及び XMLにより記述

する NE仕様を定義したこと，によりアプリケーショ

ン生産性も向上できた．

文 献

[1] M. Ohnuki, N. Tanigawa, K. Hara, K. Terunuma,

et al., “Special issue on operation system,” DoCoMo

Technical Journal., vol.8, no.1, pp.6–30, April 2000.

[2] “AIPN,” http://www.3gpp.org/ftp/Specs/html-info/

22978.htm

979

電子情報通信学会論文誌 2009/7 Vol. J92–B No. 7

[3] “NGN,” http://www.itu.int/ITU-T/ngn/

[4] “TOP500,” http://www.top500.org/project

[5] 井上貴司，加島宜雄，清水正利，“アクセス系 OpS プラットホームにおける分散方式の提案，” 信学論（B-I），vol.J80-B-I, no.10, pp.692–700, Oct. 1997.

[6] 中村信孝，山田康晴，村重 彰，“分散処理環境を用いたIP ネットワーク管理システムの構成法とその評価，” 信学論（B），vol.J82-B, no.4, pp.505–513, April 1999.

[7] 木村伸宏，山田 祥，瀬社家光，西園敏弘，“IP通信サービスのための高可用化サーバプラットホーム，” 信学論（B），vol.J88-B, no.1, pp.224–233, Jan. 2005.

[8] 湊 賢治，川幡太一，岩下 克，“大量データを扱う OSS

に適用する EJB 実装法，” 信学論（B），vol.J86-B, no.3,

pp.353–361, March 2003.

[9] “OSS/J (OSS through Java Initiative),”

http://www.tmforum.org/ossj/

[10] “Agile Alliance,” http://www.agilealliance.org/

[11] 高橋和秀，昆 孝志，秋山一宜，神宮司誠，“分散データ駆動型アーキテクチャの性能評価とアプリケーション設計，” 信学論（B），vol.J88-B, no.7, pp.1202–1212, July

2005.

[12] “OASIS WS-BPEL,” http://www.oasis-open.org/

specs/#wsbpelv2.0

[13] 渡邉稔也，秋山一宜，昆 孝志，高橋和秀，谷川延広，“OSS サーバを実現するための分散データ駆動型アーキテクチャの提案，” 信学技報，TM2003-43, Nov. 2003.

[14] 高橋和秀，田村宏直，神代真琴，“分散データ駆動型アーキテクチャによる大規模 OSSの実用化，” 信学技報，TM2005-

60, March 2006.

[15] 秋山一宜，田村宏直，高橋和秀，神宮司誠，“2 次元分散データ駆動型アーキテクチャの実用化，” 信学技報，TM2004-43, Sept. 2004.

[16] 昆 孝志，秋山一宜，高橋和秀，神宮司誠，“XMLを用いた構成データ管理システムの実用化，”信学技報，TM2004-

87, Jan. 2005.

[17] “OASIS Web Services Trans. (WS-TX) TC,”

http://www.oasis-open.org/committees/

tc home.php?wg abbrev=wss

[18] “OASIS Web Services Security (WSS) TC,”

http://www.oasis-open.org/committees/

tc home.php?wg abbrev=ws-tx

付 録

用 語 一 覧

D3A: Distributed Data Driven Architecture

eD3A: enhanced D3A

PE: Physical Element

LE: Logical Element

LPD: Logical Path Data

LPDD: LPD Driver

LPDM: LPD Manager

CA: Client Adaptor

NA: NE Adaptor

DNS: Domain Name System

（平成 20 年 11 月 27 日受付，21 年 2 月 25 日再受付）

高橋 和秀 （正員）

1987 新潟大・工卒．1989 同大大学院工学研究科修士課程了．同年 NTT 入社．現在，（株）NTT ドコモ・ネットワーク開発部に所属．ネットワークオペレーションシステムの研究開発に従事．2003 本会 TM

研究賞受賞．2006 本会通信ソサイエティ論文賞受賞．

大貫 雅史 （正員）

1973東工大・工卒．同年電電公社武蔵野電気通信研究所入所．自動車電話方式，IN

サービス方式，衛星中継網方式の研究開発に従事．1995 NTT 移動通信網（株）へ転籍，R&D において PDC パケットネットワークの開発，ネットワークオペレーショ

ンシステムの開発などに従事．現在，ドコモ・テクノロジ（株）取締役，NW マネジメント事業部事業部長，工博．本会業績賞，前島賞受賞．

980