PR

オンライン取引専業の松井証券は,顧客に安定したサービスを提供し続けられるように,ネットワークの強化・拡張を計画的に進めてきた。今も突発的なトラフィック増加に備え,想定する最大トランザクションの4倍超に耐えられるように増強作業を続けている。

写真1●松井証券の佐藤邦彦取締役システム部長兼品質管理担当役員
写真1●松井証券の佐藤邦彦取締役システム部長兼品質管理担当役員

 証券取引所が取引を開始する午前9時になると,インターネット証券のトラフィックは激増する。松井証券の場合も例外ではない。「万一システムが止まれば,我々の首が飛ぶ」と,松井証券の佐藤邦彦取締役システム部長兼品質管理担当役員(写真1)は語る。

 サービスが止まれば,顧客に迷惑をかけるだけではない。障害が長引けば金融庁から業務改善命令を受けて業務停止になる恐れもある。ネットワークを止めないことが,インターネット証券の生命線なのだ。

 提供するサービスを顧客にいかに快適に使ってもらえるかも重要だ。というのは,松井証券には基本的に営業担当者がいないから。使い勝手が顧客獲得と密接にかかわっているのだ。

 例えば,銀行の営業店の窓口で長時間待たせられると顧客はストレスを感じる。ネット証券のサイトも同様だ。アクセスしてもすぐにサービスを利用できないのなら,その顧客は別のネット証券を利用してしまう。そうならないようにするために,「ある程度のレスポンス速度を確保して,快適な環境を整えなければならない」(佐藤取締役)。

最初は負荷分散装置を自作

 松井証券がインターネット証券事業を開始したのは,1998年5月である。株の取引サービス「ネットストック」を開始した当初は,口座数も注文数もそれほど多くはなかった。それでも,ブロードバンドの普及に伴い,個人投資家がインターネット証券を積極的に利用するようになると,顧客数は増加の一途をたどった。

 顧客が増えると,オンライン取引のトラフィックも増える。そこで,アクセスしてきたトラフィックを複数あるWebサーバーに均等に割り振る仕組みが必要になってきた。サーバー1台当たりの負荷を軽くするためだ。

 松井証券の場合,ネットストックを開始した当初から,独自に開発した負荷分散の仕組みを利用していた。当時,システムはすべて自前で開発・運用していた。負荷分散システムも,ネットワークの知識があるスタッフが,パソコンにFreeBSDをインストールして独自に構築していた。ただし,急増を続けるトラフィックに対して,独自の負荷分散装置を利用し続けることのリスクは高まっていた。

負荷分散とSSL処理を別々に

 独自開発の負荷分散装置をリプレースする作業は,フロントオフィスとバックオフィスのシステムを刷新するタイミングで実施した。それまではシステムを自社で開発・運用してきたが,システムを刷新するのを機に,開発・運用を外部に委託することになった。その際,委託先のインテグレータから「FreeBSDで自作した負荷分散システムを利用して性能を維持することは難しい」と指摘されたのだ。

 これを受けて松井証券は2002年5月,システム更新と同時に,独自開発の負荷分散システムをやめて,F5ネットワークス製の負荷分散装置「BIG-IP」を導入することにした。

 BIG-IPは,一つのきょう体の中に負荷分散とSSLの暗号化/復号処理の両方の機能が搭載されている。1台で二つの機能を同時に利用できるところを,松井証券は負荷分散とSSL処理を別々に単独動作させて組み合わせる構成にした。具体的には,まず負荷分散専用のハイエンド機2台を並列に並べて冗長化構成にする。その後ろに,SSL処理用のローエンド機を複数台設置したのである(図1)。

図1●松井証券の最新のネットワーク構成図
図1●松井証券の最新のネットワーク構成図
負荷分散とSSL処理を別々の機器群に任せている。この構成は,2002年5月から採用している。
[画像のクリックで拡大表示]

 負荷分散とSSL処理をあえて別々に実行させる理由は二つある。一つは,大量のトラフィックが発生して障害が起こった際に,その原因が負荷分散上の問題なのか,それともSSL処理上の問題なのかを迅速に発見できるようにしたいこと。もう一つは,SSL処理能力を素早く増強できる構成にしておきたかったことだ。「負荷分散よりも,SSL処理の方が負荷が重い」(佐藤取締役)ので,トラフィックの急増に即応してSSL処理能力を拡張し続けなければならない。そこで,負荷分散はハイエンド機に任せ,SSL処理はローエンド機を必要に応じて追加していくことで負荷増大に対処したのである。

 実際に運用を始めたところ,負荷分散は2台のままだったが,SSL処理向けの台数は2006年4月までに当初の4台が12台にまで増強されたという。

ネット増強の指針は「4倍以上」

 2002年5月にBIG-IPを導入後も,松井証券の口座数と株取引にかかるトランザクション数は右肩上がりに増え続けた。例えば,2003年3月時点と2007年3月時点の口座数と1日当たりの注文件数を比べてみると,口座数は約7倍に,注文件数にしても約5倍に増えている(図2)。

図2●松井証券の口座数と1日平均の注文件数の推移
図2●松井証券の口座数と1日平均の注文件数の推移
増加の一途をたどり,2007年3月は4年前に比べて口座数が7倍強,注文件数は5倍強になった。
[画像のクリックで拡大表示]

 松井証券は,ネットワークを増強する際の指標を設けている。それは,トランザクションの想定最大値の4倍以上の処理能力を確保するというものだ。なぜ4倍なのだろうか。それは,「オンライン取引のトランザクション数は,相場を動かす大きな事件が発生すると一気に跳ね上がる」(佐藤取締役)傾向にあるためだ。

 4倍に増強したのは,2006年1月に起こったいわゆる「ライブドア・ショック」がきっかけだった。この影響で,松井証券にも個人投資家からの注文が殺到。1分当たりのトランザクション数は通常時の約2倍になり,システム・ダウンの一歩手前に達したという。この経験から,「このままトラフィック数が伸び続けるとネットワークが持たない」(佐藤取締役)と判断。当初は2倍だった処理能力の指標を4倍にまで引き上げて,ネットワークを増強することを決断した。

 新たな負荷分散装置として,松井証券は再びBIG-IPの最新版V9を導入することに決めた。理由は,証券業界ではBIG-IPを導入する企業が多かったことと,それまでの負荷分散とSSL処理の安定性を評価したためだ。

 また,BIG-IPの最新版V9がリリースされてからマイナー・バージョンアップされていたため,バグ修正が済んでいるだろうというの判断もあった。

 2006年4月にBIG-IPを最新版のV9に更新した。構成は,以前と同じ。負荷分散向けにBIG-IP 6400を2台,SSL処理向けにはBIG-IP 1500を4台設置した。

Webサーバー台数は最小限に

 負荷分散装置で割り当てられるWebサーバーの台数は,それほど多くない。しかも,「トラフィックの増加に伴って,安易にWebサーバーを拡充すれば運用コストが高くなってしまう」(佐藤取締役)。そこで松井証券では,Webサーバーの台数を抑えながら処理能力を高めている。具体的には,アプリケーションの改良だ。

 サービスへのログイン,注文内容や資産状況のチェックなど一つひとつの処理を取り出して,「もっと軽くできないか突き詰めている」(佐藤取締役)。もちろん,フロントオフィス・システムについても,不必要な部分はないか見直している。

 こうした作業を繰り返すことで,サーバー台数を変えずに処理能力を高めたい考えだ。「まずはアプリケーションの負荷を軽くすることから着手する。そして,それでも必要と判断すればハードを追加する。こうしていくことで,全体のコストをできるだけ引き下げながら,トラフィック増加に対処していく」(佐藤取締役)。

投資コストは“保険料”

 負荷分散やSSL処理の装置を増強するためのコストは決して安くはない。BIG-IP 6400の場合は税別875万円からとなっている。負荷分散装置とSSL処理の装置をすべて刷新するとなると,数千万円規模の投資が必要になる。

 それでも,障害が発生してから増強作業に着手したのでは遅すぎる。障害が発生してサービスが止まってしまえば,顧客に迷惑をかけるだけでなく,松井証券の営業そのものも危機に陥るからだ。障害が発生してサービスが止まらないようにネットワーク強化に投資していくのは,「保険のようなもの」(佐藤取締役)という考えだ。

 ネットワークの増強効果はなかなか実感しにくい。通常通り,日々サービスが継続されているという当たり前の状況を続けることが,その目的であるからだ。それでも佐藤取締役は「継続的に増強してこなかったら,過去最高のトラフィックに見舞われた際に耐えられなかったかもしれない。そう考えると,ネットワークを増強してきた意味は大きいはずだ」と力を込める。

次は冗長化の精度を上げる

 松井証券は,オンライン取引サービスを安定的に提供し続けるために,ネットワークの増強作業を今後も継続的に推し進めていく考えだ(図3)。

図3●松井証券のネットワーク増強に向けた取り組み
図3●松井証券のネットワーク増強に向けた取り組み

 今後計画している増強策の一つが,「完全な冗長化を目指す」(佐藤取締役)ことである。現在も負荷分散装置は冗長化構成にしているが「障害が発生した際に,顧客にまったく気付かれずに運用できるところまではできていない」(佐藤取締役)。これを,負荷分散装置に障害が発生した場合であっても,通常通りに顧客にサービスを提供し続けられるようにしたい考えだ。

 例えば,2台ある負荷分散装置のどちらかに障害が発生しているにもかかわらず,ヘルスチェックで「問題なし」と誤診断してしまうケース。こうなると,SSL処理に到達しない状態で処理が滞ってしまう。これを回避するには,負荷分散が正常に動作しているかどうかをヘルスチェックとは別の仕組みで検知しなければならない。

 ただし,新しい構成への変更作業は,慎重を期す。構成変更後には,高いトラフィックをかけてテストし,想定通りのパフォーマンスが出るかどうかを見極めてから本番で使うかどうかを決める予定である。