世界初の6ノード
OPS構成の大規模基幹システム
−NTTデータの新NOA−

劾TTデータの大規模基幹シス テム「新NOA」が、稼動を開始し た。本システムは、HP-UXと Oracle-DB技術の組み合わせで、世 界的にも例のない6ノードOPS (オラクルパラレルサーバ)構成の クライアント/サーバ・システム だ。4月12日の一般会計業務を皮 切りに、逐次移行作業を行い、順次 サービス開始している。本稿では、 ミッションクリティカルな大規模基 幹システムのフルダウンサイズ化の 実例をレポートする。

メインフレームから 3階層C/Sシステムへ

NOAは、NTTデータがNTTか ら分離独立した際に構築した社内情 報システムだ。IBM、日立、富士 通3社のメインフレーム4台からな る大規模基幹システムで、同社情報 システム部では10年以上経過し、 マシンの老巧化と同時に間近に迫っ た2000年問題をクリアするために は、システムを再構築する必要に迫 られていた。 特に2000年対応の面では、全面 的にプログラムを書き換えなければ クリアできないと主張するメーカも あり、マシンの更改費用も合わせる と莫大な投資を必要とする。また、 NOAは業務アプリに対応して3社の メインフレームが導入されており、 データベースもばらばらであるため、 データの二重投入を余儀なくされて いた。さらにはコード類の統一もな されていなかったため、データを加 工し難いといった問題もあった。 また、NTTデータ・情報システ ム部の役割が、「利用部門の要請に よる社内システムの開発・維持管 理」から、「専門知識を背景とし、 経営活動と密着した戦略部門」さら には「データ管理/コンテンツ管理、 情報の共有化と活用の ための社内情報インフ ラ整備による経営支 援」へと変化してきて おり、新NOAシステ ムの開発と情報インフ ラ整備が最重要課題で あった。
これらの点を解決す るため、UNIXサーバ によるフルダウンサイ ズを図り、クライアン ト・サーバ型で、しかもデータベー スを統合したシステムへの移行を決 定した(図1)。
「統合データベース方式を採用す ることに関しては、これまで業務ホ スト毎に分散していたDBが1カ所 に統合されるので、性能面を考える と非常に不安でした。それと、従来 のプロセス設計からデータ中心設計 で開発する方向を決定したため、特 にコードの統一化では相当苦労しま した。全ファイルを調査してその整 合性チェックにかなりの時間を要し ました。コードの統合さえ終われば、 性能的な面は方式の問題なのでなん とかなると思っていました」(NTT データ・情報システム部共通方式担 当 津田慶治部長)。
さらに、ERPパッケージの導入 に関しては、「もちろん検討しまし た。しかし、当社の場合、原価計算 が特殊であり、システム検討当時の ERPパッケージではかなりの部分 をカスタマイズする必要がありまし た。オウンコーディングの部分が3 割以上あると、将来のバージョンア ップも含めると、コスト的に高くな ると判断しました」(津田慶治部長) という。

統合DB(Oracle7.3)を中核に デファクトによるデータ中心設計

システムの仕様を検討した平成7 年当時は、3階層アーキテクチャー (GUI、AP、DB)の考え方が脚光を 浴びていた時期であった。システム の基本方針は、デファクトスタンダ ード技術を採用し、統合DBを中核 とするデータ中心設計によるオープ ンなクライアント/サーバ・システ ムの開発だ。これにより、全社デー タの統一・一元化を図るとともに、 各部門からの発信データに加えて新 NOA基幹系システムで収集したデ ータの共有によるワークスタイルの 変革を図ろうというものである。 4台のメーンフレームから、HP-UX サーバ7台、Oracle7.3DBMS のOPS構成によるクラスタシステ ムへと再構築したが、設計にあたっ ては、以下のような点を重視した。
●コードの統一化
個々のシステムが独自のコード体 系であるため、データの連携が困難。 これを解決するため、全社コードの 統一化を図る。設計上、個別情報は コードに付加した属性ファイルで管 理し、情報分析に必要なキー項目を 設定する他、採番方法や重複チェッ ク等の自動化を考慮した。
●データの一元化
個々のシステムが縦割りのため、 データの共有化が困難、経理数値 に不符号が生じることから、全社 データの一元化を図る。データの 一元化に当たっては、処理方式、 性能、容量等の面からすべてのデ ータを一つのDBで管理するのは困 難と判断し、約700ファイルのマス タ類を、業務個別DB(約100ファ イル)と統合DB(約136ファイル) にデータを分離した。
●プログラムのスリム化
度重なる機能追加によりシステ ムが肥大化・複雑化し、拡張性・ 柔軟性に欠けるため、プログラム の整理統合を図る。
●BPR(ビジネス・プロセス・リエ ンジニアリング)支援
スタッフ部門支援が中心なため、 第一線支援機能が脆弱であり、シ ングルインプット、ペーパレス化 等のBPR支援を図る。新NOAのシ ステム構成を図2に示す。

OPS6ノード構成実現のポイント

新NOAの開発の基本方針は、前述 したようにデファクトスタンダード 技術の採用だ。4台のメインフレー ムから、7台のサーバによる統合デ ータベースを中核としたデータ中心 型のシステムへと再構築したが、こ のような多ノード・クラスタシステ ムの構築、運用・監視などにあたって は、以下のようなデファクトスタン ダード技術を組み合わせるとともに、 独自の工夫を凝らせて完成させた。
●HP-UX
●MC/LockManager(HPのクラスタ リング技術)
●TPモニタ
●OracleXAインタフェース
●利用者規制・運用日付
●ログインサービス
●コールドスタンバイ系切り替え

●性能低下の防止策●

4台のメーンフレームを7台の HP−UXサーバにダウンサイズし たが、この7台のサーバ間をつなぐ 方法として、
@RPC(Remote Procedure Call) コールで各DB間をつなぐ
AOPS(Oracle Parallel Server) で一つのDBとしてしまう 方式のうち、新NOAではアプリケ ーション開発のしやすさと柔軟性の 面からOPSによる方式を採用した。 OPSは、オープンなクラスタ化 システムを活用するためにオラクル が提供しているDBMS技術だ。
OPSを利用すると、すべてのノード は単一のOracleデータベースおよ びクラスタに接続されているすべて のディスクに対してアクセスを行う ことができる。DB管理者はたった 一つのDBを管理すればよく、アプ リケーション開発者はデータの記憶 位置を気にする必要がないため、よ り多くのアプリケーションを開発す ることができる。また、業務の拡張 に伴うシステムの拡大も、ノードを 追加するだけで、Oracleデータベ ースの変更やアプリケーションの修 正はほとんど不要である。 しかし、DB更新が各サーバから あると、各サーバからDBに対して 頻繁にPingが飛ぶため性能が大幅 にダウンする。新NOAで使用して いるOracle7.3のバージョンでは、 EMC社のディスクとの組み合わせ で最大8ノードまで拡大可能であ る。しかし、理論上は可能であって も、実行上はDB設計が複雑で難し くなることや、DB制御のオーバヘ ッドが大きくなるため、処理能力向 上が見込めず、2ノード構成までが 限界だと言われてきた。 6ノードのOPS構成は世界的に も実例がないが、NTTデータ・情 報システム部では、アプリケーショ ンのパーティショニングとして、以 下の工夫を行うことによりこの問題 を解決したのである。
@統合DBへの書き込みを更新処理 として共通化してとりまとめ、さ らにRB(リモートバッチ)処理 化した。また、全体の共通コード 類の変更も1サーバに集中させ、 他サーバからは照会のみとした。
A各業務のみに必要なDBは、各業 務サーバからのみ更新し、連動処 理による他業務該当データへの更 新は、アプリケーションをその DB更新が可能なサーバへ移動し 分散した(サーバ間はRPCコー ルを使用)。

●6ノードによる障害時対策●
OPSには、上述したように、一 つのOracle DBMSを複数のノード が同時に実行可能という特徴があ る。新NOAの場合は、6ノードで 同時接続ユーザ数は最大250にのぼ る。さらに、あるノードが故障した 場合、別のノードがそのDBへのア クセスを行って処理を続行すること が可能となっている。新NOAでは、 高信頼性を目標に、待機サーバを用 意し、業務サーバ障害時に短時間で 系切り替えを可能にしている(フロ ーティングIPアドレスを採用し、 サーバが替わってもIPアドレスを 変更することなく、ネットワーク接 続の切り替えおよびディスク構成の 切り替えによる動作環境の引継を可 能とした)。これにより、サービス 中に障害が発生し、系切り替え運転 を行ってもサーバが入れ替わったこ とを意識せず利用可能となった。さ らに二重障害を想定し、縮退運転も 可能にしている。 もともと、サーバの信頼性は、メ インフレームと比べるとかなり低い。 それを可用性で補っているわけだ。 サーバがダウンしても、サービスが 止まらなければそれで良いというの がメインフレームベンダとサーバベ ンダの大きな考え方の違いである。

●大量データのバックアップ●
EMC社のTimeFinderBCV機能 を利用し、バックアップ処理をバッ チ処理やオンライン処理と並行して 走行可能にしている。バックアップ 開始前にミラーディスクを業務処理 と切り離し、バックアップ処理後、 ディスクを業務サーバに戻し、ディ スク単体で同期をとることを繰り返 す方法をとっている。この際、オペ レータの運用ミスを防止するため、 自動運転化するなどの工夫を凝らし ている。これにより、見かけ上のバ ックアップ時間を大幅に短縮するこ とが可能となった。

●月次処理の工夫●
経理の月次処理は、当初2〜3日 かかると予想したため、購買・請 求・在庫等のオンライン処理が経理 の月次中はサービスできないことに なる。これを改善するため、月次処 理を月次専用のサーバ(通常は待機) で走行し、月次結果データのみ業務 サーバのDBに戻す(差分による整 合性チェック)方式を開発した。こ れにより、月次処理と並行して上記 業務のオンライン処理を可能にして いる。 サーバにはチャネルがないため、 バッチジョブは遅いと言われている が、「月次処理専用サーバ、Oracle のパラレルインサート機能を使うこ とで、相当早く処理できます。クラ イアント/サーバでは、バッチ処理 は遅いため、月次処理は難しいと言 われていましたが、当初の目標値で ある2〜3日を大幅に短縮できまし た。現在なんと12時間で終わって しまいます。これはメインフレーム の時よりも早い」(津田慶治部長) という。

●その他●
●レスポンスタイムの向上
新NOAは、NOAネットワークに 接続している全社員のクライアント からセンタに全部アクセスできるよ うになっている。したがって地方に よっては、INS64で 接続している所もあ る。そこからでもレ スポンスタイムが遅 くならないように、 ネットワークの負荷 をできるだけ小さく する必要がある。こ のため、当初4Kバ イト以上の電文は作 らないように指導し た。
●ネットワークの分割
各ノードの制御信号がデータと衝 突しないようにLANを分割配置し、 大量データ送受信時のノードダウン を防いだ。
●LANの二重化
●採番テーブルの工夫
●サーバの相互監視
●運転の自動化

今後の展開 −仕事に役立つ情報共有の実現−

これまで紹介してきたように、さ まざまな工夫の上に、世界初の6ノ ードOPS構成のミッションクリテ ィカル・システムを実現した新 NOAだが、今後の展開としてはデ ータウェアハウスを核にした仕事に 役立つ情報共有環境の実現だとい う。収集したデータをどのように情 報提供するか、事業活動のパフォー マンスを把握する仕組みをいかに提 供するかである。データウェアハウ スなどの一部事業計画支援等につい ては現在開発を行っている。すでに 購買統計などは、データ移行ツール (Sagent)や多次元分析ツール (Impromptu)を導入し、一部のユ ーザは利用している。情報システム 部では、図3に示すように、新 NOA基幹システムと情報インフラ (クライアント、ネットワーク、情 報共有環境)との融合により、仕事 に役立つ情報共有の実現を目指して いる。日常業務運営で必要データを 集め活用する仕組みを作ることによ り、業務の生産性向上を図るのが狙 いだ。インターネットを介して関連 会社、ビジネスパートナー、取引会 社も含めた情報連携も行う。

最後に、世界初のHP-UXサーバ 6台のOPS構成(8ノードまで拡 張可能)による大規模クライアン ト/サーバ・システムの開発を可能 にしたのは、わが国有数のSI事業 者であるNTTデータならではの卓 越した創意工夫が随所にあったから だと言っても過言ではない。