予想以上にリソースを消費していた

図3●ボトルネックは3つあった
性能低下の最大の要因は,XMLデータの階層構造が深く項目数も多いために,Adobe Form ServerでHTMLデータを生成する処理が重くなっていたこと(1)。また, XMLデータをSQL Serverのテキスト型カラムにそのまま格納する手法を採っていたため,SQL文ではなくアプリケーション・レベルの検索ロジックに頼らねばならない場面があること(2),更新時にXMLデータ単位でロックせざるを得ないこと(3),という制約も性能低下の原因だった
図4●XMLDB「NeoCore XMS」の性能をテスト
Xeon 1基で動作する「Windows 2000 Server」と,UltraSPARC IIIi 4基で動作する「Solaris9」とで,NeoCore XMSの更新性能を比較した。その結果,Windows版のNeoCore XMSは,データ量が増えると性能が極端に低下することが分かった。これは,32ビット版のWindows 2000 Serverがアプリケーションの利用可能なメモリー空間を2Gバイトまでに制限していることに起因する。メモリー使用量が2Gバイトを超えるとディスクへのスワップが発生するため,ディスクI/Oによって性能が落ちる
図5●.NET FrameworkとXMLDBを組み合わせて再構築
ボトルネックが生じないように,システムを再構築することにした。データベースは,項目レベルで自動的にインデックスを生成できるXMLDB「NeoCore XMS」に置き換えた。アプリケーションは,XMLを処理するAPIが充実した.NET Frameworkで新たに作り直した

 性能が不足する最大のボトルネックは,構築に使用したAdobe Form Server 5にあった(図3[拡大表示]の(1))。このソフトは,複雑なXMLデータからHTMLフォームを生成する場合に,CPU/メモリーを大量に消費する傾向がある。

 運が悪いことに,三井物産がSIベンダーと共同で作成したXMLデータは,階層構造が深く項目数も多かった。特に個別業務マニュアル入力機能では,部品化した業務手順(XMLデータ)を階層的に組み合わせて新しい業務プロセスを作成するという仕様のため,XMLデータは共通業務マニュアル入力機能以上に複雑化していた。このため,個別業務マニュアル入力機能で性能低下が顕著になったのだ。

 さらに,XMLデータを格納するデータベース関連の処理にボトルネックがあった。三井物産は,XMLデータをSQL Serverのテキスト型カラムにまるごと格納する方法を採った。XMLデータに含まれる特定の項目だけを参照する場合,アプリケーションでXMLデータを読み込んだ後,該当項目を探して情報を取得する必要がある(図3[拡大表示]の(2))。ただでさえAdobe Form Server 5の処理が重いアプリケーション・サーバーに,データベース関連処理の負荷を上積みしていた。

 同様に更新時には,XMLデータ単位でロックがかかり,アプリケーションで更新対象の項目を探してから変更することになる(図3[拡大表示]の(3))。結果として,SQL文でダイレクトにカラムを参照/更新する場合と比べると処理が遅くなる。

 もちろん,XMLデータに含まれる各項目を個別にデータベースのカラムに格納すれば処理速度は向上する。しかしそうすると,後からXMLデータの構造を変更するとき,その影響をデータベースがまともに受けてしまう。「拡張性や柔軟性を損なうという不安があった」(同チーム 山口拓也氏)。

XMLDBでボトルネックを削減

 チューニングで乗り切れないか試したが,ほとんど焼け石に水だった。前述のようにSIベンダーはアプリケーション・サーバーの増設を提案したが,三井物産としては運用/保守の手間が増えることは避けたかった。

 悩んでいたとき,プロジェクトに参加していた情報子会社(三井情報開発)から,データベースをXMLDB(XML Database)に変更してみてはどうかと提案された。XMLデータの参照/更新に特化したXMLDBを使えば,少なくともデータベース関連のボトルネックは解消する。

 SIベンダーもXMLDBの有効性は認めたが,SIベンダーが取り扱うXMLDB製品には合計100GバイトものXMLデータを高速に処理する実績がなかった。そこで,三井情報開発が販売するXMLDB「NeoCore XMS」を評価,検討することになった。

 評価に当たって,実機を使ってベンチマーク試験を実施した(図4[拡大表示])。具体的には,NeoCore XMSにデータを登録するときに要する時間を,XMLデータの総容量と,登録するXMLデータの条件を変えて測定したのだ。

 その結果,XMLデータの総容量が50Gバイト程度になると,Windows版のNeoCore XMSの性能が極端に低下することが分かった。これは,32ビット版のWindows 2000 Serverがアプリケーションに最大2Gバイトまでしかメモリー空間を割り当てないことに起因する。XMLデータに対する索引などで2Gバイトを超えてメモリーを使用するときにスワップが発生。ディスクI/Oで,性能が低下していた。三井物産は,SPARC/Solaris9版のNeoCore XMSであれば,使用に耐えると判断した。

アプリケーションまで再開発

 NeoCore XMSを評価するうちに,アプリケーション全体を.NET Frameworkで再開発しようという意見が支配的になった。パッケージ・ベースだと,細かな部分で思い通りにならないからだ。NeoCore XMSには.NET Frameworkとの連携ソフト(XMS Data Provider)が提供されており,開発環境は整っていた。一方の.NET Frameworkにも,XMLデータを扱うクラス(xml)やデータベースから取得したデータをキャッシュしておくクラス(DataSet)などが充実しており,MICANの開発には適しているように見えた。

 2004年4月,三井物産は.NET FrameworkとNeoCore XMSの組み合わせで再開発することを正式に決めた(図5[拡大表示])。背景には,「サーバーの大幅増設を提案するようなSIベンダーと信頼関係を保って付き合っていけるか不安だ」という思いもあったようだ。

 とはいえ,設計からやり直している余裕はなかった。月内には共通業務マニュアル入力機能を,翌月には個別業務マニュアル入力機能を,それぞれ暫定稼働する計画だったからである。

 三井物産は,Adobe Form Server 5で構築していたシステムを“プロトタイプ”と位置づけ,画面デザインやXMLデータ構造などは,そのまま引き継ぐことにした。それでも,共通業務マニュアル入力機能については再開発が間に合わない。Adobe Form Server 5で開発済みのシステムを暫定稼働させて業務手順の情報を入力してもらった後,ユーザーが入力した情報をNeoCore XMSに移行し,寄せられた修正要望を再開発版に反映するという手順を踏んだ。

 その後,PDF出力,バックアップ・データ管理,マニュアル・データ管理,マスター保守といった機能を,後続のスパイラルで開発。2004年11月24日に本稼働にこぎ着けた。ただし,変更履歴管理や文字列置換などの一部機能は本稼働に間に合わず,2005年1月までに追加した。

 暫定稼働の段階では,余裕を見てアプリケーション・サーバーを9台構成としていた。だが,本稼働後には入力処理の頻度が下がったこともあり,2005年1月にはアプリケーション・サーバーを6台まで減らした(PDF変換サーバーは除く)。Adobe Form Server 5で実装した場合の見積もり(計19台)と比べると,約3分の1の台数で済んだことになる。

(実森 仁志)