カブドットコムで断続的に処理が遅延

原因はDB接続ソフトの不具合や取次会社のサーバー障害

吉田晃

2004.04.06

カブドットコム証券は3月初旬，相次いでWebサイトのトラブルに直面した。まず，画面の応答速度が低下する，注文/約定データの反映処理が遅れる，といった事態が起きた。同社はすぐに対策チームを設置して調査。ようやく見つけた原因はDB接続ソフトにあった。その後も取次会社のサーバー障害に見舞われた。

図1●カブドットコム証券で発生した障害と対策
3月1日から3月5日にかけて，同社のWebサイトで，画面の応答時間や，注文/約定データをDBサーバーへ格納する処理などが遅延してしまった

写真1●「当初は原因が分からず，対策に苦心した」と語るカブドットコム証券のシステム統括部長兼事務統括部部長阿部吉伸氏

図2●DB接続ソフトをDBサーバーから切り離す
同社が3月2日の夜に実施した障害対策は2つ。(1)DBサーバー（SQL Server 2000）上で動作していたDB接続ソフトを，旧システムで利用していたバージョンに戻す，(2)そのDB接続ソフトをDBサーバー（SQL Server 2000）とは別のサーバーで動作させる――だ。これにより，SQL Server 2000を搭載するDBサーバーのCPU使用率を100％から60％に抑えることに成功した

　3月1日から3日と，3月5日の計4日間，カブドットコム証券のWebサイトで画面の応答速度の劣化，注文や約定データのDBサーバーへの反映処理の遅延などのトラブルが断続的に発生した（図1[拡大表示]）。原因は，1日と2日がDBサーバー関連の不具合，3日と5日が同社と証券取引所を仲介する取次会社のサーバー障害だった。

　これらの障害により，金銭面での損害も生じた。同社は，顧客から受け付けた注文を，証券取引所に取り次ぐまでの時間が5分を超えないことを保障している。この内容に基づき，「処理の遅延によって損金が生じた顧客に対し，損金を返却した」（システム統括部長兼事務統括部部長阿部吉伸氏，p.13の写真1）。

●3月1日
DBサーバーが性能劣化，原因特定に至らず

　株式市場での取引が始まって間もない3月1日の午前9時10分。同社サイトで，画面の応答が悪くなったり，注文/約定データをデータベースへ反映する処理が遅れたりする現象が発生した。顧客からの注文を受け付け，約定結果を反映する注文用DBサーバー（SQL Server 2000）の「CPU使用率が100％で高止まりしてしまった」（阿部氏）のである。

　処理が遅延したのは，一日のうちで最も注文が殺到する朝9時台。原因究明よりも，注文や約定にかかわる処理の遅延を解消する方が先だ。そこで，待機系サーバーへの切り替えに着手した。しかし，DBサーバーのCPU使用率が高止まっていたため，通常なら数分で終わるはずの切り替えに20分を要してしまった。復旧したのは9時38分である。

　待機系サーバーに切り替えた後も，同様の不具合が発生する可能性がある。その際，サーバーの切り替えに数十分もかかってしまうのは避けたい。そこで，SQL Server 2000が利用できるCPU数を16個のうち14個に限定した。こうすれば，万が一，SQL Server 2000が利用する14CPUの使用率が100％になっても，「残りの2CPUをサーバーの切り替え処理に利用できるので，切り替え時間を短縮できる」（阿部氏）と考えたのである。

　同社は今年2月初旬に，注文用DBサーバーを上位機にスケールアップし，SQL Server 2000を32ビット版から64ビット版に置き換えることで，十分なキャパシティを確保したばかりだった。この日のアクセス数は，ピークの9時すぎで平常時の1.5倍程度と，想定していた範囲内に収まっている。キャパシティ不足は考えられない。同社の対策チームは原因究明に取り掛かったが，「3月1日の時点では，原因が分からなかった」（阿部氏）。

●3月2日
DBサーバーがダウン，DB接続ソフトを切り出す

　翌3月2日も，株式市場が始まった直後から，3月1日と同じ現象が見られた。午前9時1分から，注文用DBサーバーのCPU使用率がみるみる上昇。9時20分には，ついに注文用DBサーバーがダウンしてしまった。注文用DBサーバーを再起動するなどして，処理の遅延がなくなったのが10時15分である。調べてみると，この日のアクセス数も想定範囲内のものだった。やはり注文用DBサーバーのキャパシティが問題とは考えにくかった。

　そうした中，前日から原因を探していた対策チームは夜になり，注文用DBサーバーのログなどからようやく原因を特定した。それは，注文用DBサーバー上で動かしていたDB接続ソフトの不具合だった。注文用DBサーバーのほか，顧客の預かり資産額などのデータを管理する残高用DBサーバー（Oracle）へ接続するために利用していたものだ。

　「アプリケーションからDBサーバーへの接続要求が短時間に大量に発生した結果，DB接続ソフトがCPU資源を食いつぶしていた」（阿部氏）のが真相だった。このDB接続ソフトはSQL Server 2000と同じプロセス内で動作していた。そのために，原因特定に余計に手間取ってしまった。

　DB接続ソフトは，SQL Server 2000を64ビット版に入れ替えたのに伴い，それまで利用していた32ビット版ソフトから，性能を高める目的で64ビット版ソフトに置き換えていた。

　対策チームは，DB接続ソフトを2月初旬まで使っていた32ビット版に戻すとともに，障害の切り分けを容易にするためにDBサーバーとは別のサーバーで動作させた（図2[拡大表示]）。その結果，DBサーバーのCPU使用率を，ピーク時で60％程度に抑えられた。

　注文用DBサーバーに起こったこの現象は，DBサーバーやDB接続ソフトの入れ替えから1カ月の間は出なかった。なぜ3月に入って発生したのか。理由として推測されるのは，2月28日にDBサーバーを計画停止していたことである。カブドットコム証券は，2月下旬の米国株式市場の活況を受けて，国内株価が上昇すると予想していた。そこで，多数のアクセスに耐えられるかどうかをチェックするために，DBサーバーを計画停止したのだ。これにより，「各種のキャッシュがクリアされてしまい，DBサーバーへの接続要求が，高アクセス下で短時間に大量に発生してしまったのがいけなかったのかもしれない」（阿部氏）と見ている。この条件は，負荷テストの要件に含まれていなかった。原因が判明した後，すぐに負荷テストの要件に取り入れた。