[過去ﾛｸﾞ] 【安藁】 楽天証券47マーケットくるくる♪【月間】 (984ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
84(1): 日経コンピュータの記事 05/02/27 11:53 ID:c7tXOk3O(1/4) AAS
誤算の検証：動かないコンピュータ
楽天証券
１０日間で２度の障害
原因は運用ミスとＤＢのバグ
１度目は復旧まで２２時間
楽天証券は２００５年１月、わずか１０日の間に２度にわたるシステム障害に見舞われ、
株式の売買ができない状態に陥った。１度目のトラブルはシステムのバッチ処理の異常に
伴う運用ミスによるもので、２度目はデータベース・サーバーの障害が原因だった。１度
目の障害は復旧までに２２時間を要した。
１度目の障害が起きたのは、１月１２日の午前８時１０分ころ。顧客から、画面表示上
省17
85: 日経コンピュータの記事 05/02/27 11:54 ID:c7tXOk3O(2/4) AAS
■障害対応でベンダーが誤操作
１２日に起きた障害の発端は、同社が日次で実行している夜間バッチ処理が異常終了し
たことだった。夜間バッチで実行するのは、最新の株式銘柄情報の取り込み、顧客の前日
の約定結果を反映した残高の確定といった処理で、深夜３時ころから約２時間をかけて処
理する。ところが１２日は、この処理が開始後約３０分で異常終了した。
バッチ処理の異常終了そのものは、「想定している範囲の障害」（楠氏）である。１月
１２日の場合は、一部データが入力されていなかったために書き込みエラーが発生し、異
常終了した。こうした事態に備えて、楽天証券では対応手順を明確に決めてある。まず、
後続処理への影響を確認し、異常終了したプログラムをスキップして後続プログラムを実
行させる。その後で、異常終了したプログラムだけを再実行し、影響が及んだ箇所を修正
省16
86: 日経コンピュータの記事 05/02/27 11:54 ID:c7tXOk3O(3/4) AAS
■２度目の引き金はＤＢの負荷
１２日のサービス停止から立ち直ったのもつかの間、翌週の２０日には再びシステムが
停止。データベース・サーバーの障害により、サービスできない状態に陥った。
原因は、アプリケーション・サーバーからデータベース・サーバーへの処理要求の量が
予想を上回ったこと。楽天証券は前の週末（１月１５日、１６日）、データベース・
サーバーをアップグレードして処理能力を向上させたが、これが裏目に出た。ハードウエ
アの性能向上を図った結果、データベース接続がボトルネックになってしまった。
多くの場合、アプリケーション・サーバーとデータベース・サーバーの間では、接続に
かかる時間の短縮とサーバーへの負担軽減を目的として、あらかじめ論理的な接続経路
（コネクション）を複数確立しておく。複数のアプリケーションでこれらのコネクション
省7
87: 日経コンピュータの記事 05/02/27 11:55 ID:c7tXOk3O(4/4) AAS
実際には、データベース・サーバーはアップグレードしたばかりだったから、処理能力
には余力があるはずだった。共有プールもシステムのリソースを食いつぶすような設定で
はない。
にもかかわらずデータベース・サーバーがダウンした原因は、データベース管理システ
ムのOracleにあった共有プール関連の未公表のバグ。その場は、データベース・サーバー
を再起動し、その際に共有プールのコネクション数の設定を２倍に増やすことで、障害
に対応した。
これと平行して「日本オラクルに連絡を取り、バグの内容を確認。その週のうちには
パッチ（修正プログラム）を適用した」（同氏）
これら一連の障害を受け、楽天証券は緊急の対策を施した。システム増強を進めるほ
省5
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.026s