日興ビーンズ証券は,インターネット経由で株や投資信託の売り買いができるシステムを99年10月に稼働した。開発期間は5カ月間しかなかったため,既存システムの再利用や使い慣れた製品の利用,および,生産性の高いJavaの採用で納期を守った。また,ホスト処理の分散や負荷分散ソフトの導入などで,レスポンス問題を回避した。

写真1●日興ビーンズ証券の利用画面
トップ・ページのURLは,

  99年10月,日興證券系インターネット証券取引専門会社「日興ビーンズ証券」のホームページ(写真1[拡大表示])が始動した。証券会社に行かずとも,自宅や外出先から最新の株価情報が参照でき,株や投資信託の取り引きができる。

 日興證券でインターネット・ビジネスのプロジェクトが立ち上がったのは,99年3月のこと。システム関連の検討開始は同年5月で,その5カ月後にはインターネットを介した取り引きシステムをカットオーバーという強行スケジュールだった。

 大変だったのは,開発期間の短さだけではない。システムの性格上,かなり高いレベルの信頼性とレスポンスが要求される。そこに問題が発生すれば,それは顧客が離れていくことに直結しかねないからだ。とりあえず動くシステムを作り,ユーザーの不満を聞きながら手直ししていくという手法が使えるシステムではない。しかも,インターネット経由ではピーク時の同時接続数の予測がし難く,正確なキャパシティ・プランニングも難しい。

 システム開発を担当した日興證券のシステム関連会社ファイナンシャル・ネットワーク・テクノロジーズ 第二開発事業部カスタマーサポート部長兼金融総合システム開発部長の横田真次氏らのグループは,新旧技術の組み合わせで短期開発を実現し,処理の分散によるボトルネック回避によって,レスポンスを確保するといった工夫で,これらの課題を乗り越えた(図1[拡大表示])。

 「土日も無く,毎日夜の2時か3時まで仕事をした」(横田氏)結果,予定通りにシステムを稼働させ,現在,約100万ページ・ビュー/日,約1万取り引き/日を支えている。2000年3月,検索処理を高速化するためにデータベースのインデックスを追加したことが原因で「夜間バッチが終わらない」(横田氏)というトラブルを起こしたが,それ以外は順調に稼働している。


図1●システム構築のポイント

新旧技術のいいとこ取り

 5カ月間では,すべてを一から作っていては間に合わないし,信頼性も確保できない。そこで,再利用できるものは再利用し,新規に作る必要がある部分は新旧技術を適材適所で組み合わせることにした(図2[拡大表示])。

 まず,東京証券取引所とのやり取りを行うバックエンドは,日興證券のホスト・システムを使う。一方,利用者向けサービス・メニューなどを提供するフロントエンドのシステムには,再利用できるシステムはない。作り込みが必要なため,生産性の高いJavaを採用した。ただしここでは,過去のプロジェクトでJavaを採用した経験からJavaの生産性の高さは実証済みということもあったが,「どうせなら新技術にチャレンジしたい」(横田氏)という思いがあったことも確かだ。

 フロントエンドとバックエンドの接続部分は,既存技術やノウハウをフルに活用した。RDBMSにはOracleを採用。機能的には他社製RDBMSでも良かったが,決め手は,自社でもつチューニング技術のノウハウだ。同社ではOracleを「死ぬほど使った」(横田氏)経験があり,システム全体のレスポンスを決めるのはRDBMSだと分かっていたため,Oracleを選んだのである。

図2●短期間にシステムを完成させるための工夫
使い慣れた技術と,生産性の高い新技術を適材適所に組み合わせた。作り込みの必要な個所は,Javaでフレームワークを作成し,短期開発を実現。RDBMSやキューイング・ソフトウエアなどは,使い慣れた製品を採用して高い生産性を維持した

 フロントエンドのロジック部分とバックエンドのホストとの連携に米IBMのキューイング・ソフトウエア「MQSeries」を,ホストからバッチ処理でOracleにデータを切り出してくる部分にはセゾン情報システムズのファイル転送ソフトウエア「HULFT」を採用したのも,同じ理由からだ。両製品とも利用経験が長く,「即時性が要求される場合のシステム間連携にはMQSeries,バッチ処理で大量のファイル転送にはHULFTを使うことが標準のようになっている」(横田氏)。ともに過去のプロジェクトで蓄えたノウハウが豊富にあった。

フレームワークで高生産性を実現

 Javaの経験があったとはいえ,大規模なシステムにJavaを適用するのは今回が初めてであり,同社にとっては新技術といえる。さらに,Javaを使えば必ず生産性が高くなるわけでは無い。「オブジェクト指向技術を駆使して初めて生産性が高くなる」(横田氏)ことを,過去の経験で知っていた。

 オブジェクト指向技術を駆使すれば高い生産性が得られる半面,クラス設計などには高度な技術が求められる。スキル不足を補うために,金融システムとオブジェクト指向技術に詳しい新日本製鉄の協力を仰いだが,それでも,当初2カ月弱でできると考えていたクラス設計が3カ月に延びた。今回約100個のクラスを設計したが,「業務知識を持ったエンジニアと,オブジェクト指向技術を持ったエンジニアの技術の擦りあわせに時間がかかった」(横田氏)ことが大きな原因である。

 生産性に関しては,オブジェクト指向の効果はやはり高かった。オブジェクト指向技術の一つである「フレームワーク」という考え方を採用したこともあり,クラス設計以降の工程は短い期間で終わった。フレームワークとはアプリケーションのひな型に当たるもの。オブジェクト指向の継承技術などを駆使する方法で,ベースとなるクラスを再利用し,詳細設計工程やコーディング工程を簡略化できる。今後の機能拡張に対しても効果を発揮すると期待している。

図3●レスポンスを確保するために行った工夫
フロントエンドは,WWW/APサーバーを複数台用意し,負荷分散ソフトウエアで処理を分散した。バックエンドは,参照用のDBを作成することでホストへのオンライン接続を減らし,ホストの負荷を削減した

ボトルネックは今も昔もDBMS

 レスポンス面では,いくつかの心配があった。まず,インターネットではユーザー数の予測が難しい。しかも,高いセキュリティを確保するために128ビットの暗号化技術を採用している。WWWサーバー上でのSSL(Secure Sockets Layer)の処理や,大量の履歴データを参照する処理,東京証券取引所との接続を含む証券取引処理などの負荷が高くなるとレスポンスに影響が出ると予想された。

 フロントエンドのロジック部分では,WWWサーバーの拡張技術としてCGI(Common Gateway Interface)よりも負荷の軽いJavaサーブレットを採用したが,利用実績が少なくレスポンスはやってみないと分からなかった。レスポンス問題解決のために取った方策は,データベースのチューニング,処理の分散によるボトルネックの回避,負荷分散ソフトウエアの導入などだ(図3[拡大表示])。

 「どんな言語を使って開発してもアプリケーションの重い部分は変わらない。ボトルネックになりやすい箇所は今も昔もデータベース回りだ」(横田氏)。同社で主に使うRDBMSはOracleであり,Oracleに関するチューニング・テクニックは蓄えている。テーブル設計や,SQL文の書き方などに細心の注意を払い,ボトルネックになりやすいRDBMSの処理性能を向上させた。

負荷分散でレスポンス問題を解消

 ハードウエアは,CPUやメモリーが増強できる機種を選んだ。システム構成も工夫した。処理を分散し,できるだけボトルネックを作らないようにした。

 株の取り引きなどを処理するホスト・ベースのシステムには,処理内容による分散を行った。証券の売り買いはリアルタイムで処理する必要があるが,取引履歴の参照などはリアルタイムの情報でなくてもよい。ホストから切り出した参照用のデータベースに問い合わせるだけで十分だ。このように考え,更新処理と参照処理を分けた。参照用のデータベースを切り出し,Oracle上に実装。毎日,ファイル転送ソフトウエアでホストから差分情報を転送し,夜間バッチでデータベースを更新する。夜間バッチのプログラムは,処理性能を重視してC言語で開発した。

 WWWベースのフロントエンド・システムには,複数マシンによる処理の分散を行った。複数台のWWW/APサーバーを並べ,負荷分散ソフトウエアで処理を振り分ける方法である。この方法は,システムの拡張性を飛躍的に高めてくれる。レスポンス劣化が起きてもマシンの追加だけで処理能力が向上でき,レスポンス劣化に対応できる。また,1台のマシンがダウンしてもシステムは停止しないため,信頼性も向上する。ただし,高負荷状態で効率よく性能を上げるには,負荷分散ソフトウエアのチューニングが欠かせない。今回のシステムでは,製品の供給元である日本IBMにチューニングを依頼し,性能を引き出した。

(松山貴之=matsuyam@nikkeibp.co.jp



システム構成

図A●システム構成図
 日興ビーンズ証券のインターネット証券取引システムは,従来専用端末で利用していたホスト・システムをバックエンドに利用し,フロントエンドのWWWシステムはJavaで新たに作り込んだ。Javaベースのシステムとホストとの連携には,キューイング・ソフトウエアとファイル転送ソフトウエアを使い分けた。
 フロント側のサーバーは,Oracleが稼働するDBサーバー×2,WebSphereを搭載したWWW/APサーバー×4,負荷分散サーバー×2台などからなる(図A[拡大表示])。構築費用は,ハードとソフトの総額が約3億円,人件費は約5億円。ハード,ソフトの中で単体で最も高価なのはOracle。インターネットに公開し,2台のサーバーで2重化して利用する使い方で約5000万円で購入した。ハードは,DBサーバーが1台約1500万円,WWW/APサーバーが1台約1000万円なので,Oracleの割高感が強かったという。負荷分散ソフトウエアを含むWWW/APサーバーWebSphereの価格は,サーバー1台当たり約300万円だった。