Comments
Description
Transcript
オンライン株取引
特集 「 （通常のピークの）2倍，3倍は想定 を提供するジェイティービー （JTB）は いていたにもかかわらず， （当時は） していたが，瞬間的に5倍を超す負荷 2003年3月，データベース・サーバー コストを優先せざるを得ない状況であ がかかった」 （カブドットコム証券 シ のディスク交換作業時に予期せぬ状況 った」 （同社 チーフエンジニア 戴漢民 ステム統括部長 兼 業務開発課長の阿 に陥り，作業を中止してリカバリを実 氏）ことがトラブルの背景にある。ネ 部吉伸氏） 。2003年7月，カブドット 施した。 「手順に関する （仕様上の）誤 ット上のサービスでは，最初から大規 コム証券が提供するオンライン株取引 解があった」 （JTB Webトラベル事業 模なシステム投資を行うのは難しい。 サービスの処理性能が低下。アクセス 部 研究員・データベーススペシャリ 冗長化構成などは後回しにならざるを 急増でシステムが耐え切れなくなり， スト 矢嶋健一氏） 。結果的には仕様の 得ず， 「ハードウエアは壊れないもの 同社が独自に定めるサービスレベルを 読み誤りであるが，担当者は想定外の として扱っていた」 （戴氏） 。 守れないケースが頻発した。負荷テス 事態になるまで正しい作業だと確信し トは実施していたが， 「7月のアクセ ていた。 “正しいと信じていたことが スは経営側も想定していない規模」 実は誤りである”といった状況では， （同社 代表取締役COO 齋藤正勝氏） 。 いくら事前に作業手順を確認してもト 定した範囲内で動作している場合は有 ラブルは防げない。 効だ。ただし，想定した範囲を越えた たいかんみん 想定を上回る事態になれば，事前のテ ストは無意味と化す。 事前のテストをいくら強化しても， トラブルを根絶させることはできない （図1） 。 旅行予約サイト 「JTB INFO CREW」 変化と不具合は表裏一体 テストは，システムがあらかじめ想 2002年8月末，プライムリンクが提 り前提条件が変わったりすれば，テス 供するホテル予約サイト 「一休.com」 ト結果は何も保証しない。アクセス数 のサービスが停止した。ルーターの不 が変わる，利用者の使い方が変わる， 具合が直接の原因であるが， 「以前か アプリケーションが変わる，ソフトの らルーターの処理能力がピークに近づ バージョンが変わる ―― 。これらは いずれもテストを無効にする危険をは らんでいる。だが「経営サイドは臨機 トラブル 図1 ●テストを強化してもトラブルは なくならない いネット上のシステムでは，事前のテ 予想を上回るアクセスがある １．予想 予想を上回るア 上回るアクセスが スがある ある 利用者の使い方が変わる ２．利用者の使 利用者の使い方が 方が変わ 変わる コスト・パフォーマンスを ３．コスト・パフォーマ ーマンス ンスを 優先せざるを得ない 優先せざるを得な 優先せ 得ない ４．仕様書の解釈違いに気付く 仕様書の解釈違いに気付 仕様書の解釈違 気付く ・負荷テストの実施 負荷 実施 ・テスト項目の増加 テスト項目 項目の増加 増加 ・テスト期間の延長 テスト期間 期間の延長 延長 なければビジネスで勝てない」 （カブ ドットコム証券 齋藤氏） 。変化の激し ・サービス停止 停止 ・処理性能の低下 処理性能 低下 ・異常処理 テスト強化 ト強化 応変なシステムを望む。変化を許容し ５．市販ソフトのバグが見つかる 市販ソフトのバ 市販 トのバグが見つかる ストで安心することが許されない。 変化を許容する以上，不具合の種は 常にシステムに内在する。そのような 状況で“トラブルをゼロにするといっ てもどうしたらいいか分からない”と いうのが現場の本音だ。 「予測できな いからアクシデント。アクシデントが トラブルに発展することがあるが，予 測できないものは防ぎようが無い」 （カブドットコム証券 齋藤氏） 。 94 Nikkei System Integration 2003.11 トラブルと闘う 不具合を前提にした対策 とはいえ，踏みとどまって はいられない。ネット上でサ ービスを提供する企業では， 新たな取り組みを始めてい る。 松井証券のオンライン株取 引システム 「ネットストック」 の担当者が常に考えているこ とは， 「トラブルが起きた後 で，速やかにリカバリできる かどうか」 （同社 システム部 品質管理担当 部長 大石忠洋 氏）である。同社は2003年2 月，市販ソフトの不具合でシ ステムが異常になり，復旧に （イラスト：柴田 次郎） 図2 ●トラブルが起きることを前提に対策を練る 11時間かかった経験をした。 その不具合は極めてレアなケ ースで起きる現象だったが，同社に与 が上がってくると，その一つひとつの コミュニケーションシステム データ えたインパクトは大きかった。システ 情報をベンダーと共に分析する。 「パ センター事業部 運用部 副責任者 秋枝 ムが異常になったことよりも，復旧に ッチは何らかのバグを示している。自 正治氏）姿勢は欠かせない。 時間がかかったことが大きなダメージ 社システムにとって致命的な問題なの トラブルの発生原因は千差万別であ となった。 かどうかを精査する」 （中村氏）という るため，テストを実施する際は不具合 取り組みをはじめた。 個所を見抜く力が求められる。見抜く 松井証券ではそのトラブル以降，リ これから取り組むべきトラブル対策 力をつけるには，システムの運用監視 さらに，システムの完成度に対する考 は，不具合があることを前提とした対 を経験するなどしてシステムをよく知 え方を変えた。 「運用しているシステ 策だ （図2） 。 ることが基本である。トラブルを経験 カバリを強く意識するようになった。 ムであってもその完成度は10 ％∼ 20％。不具合はあって当たり前。 （運 テストで手を抜けば人災 すればするほど見抜く力が養われる。 「他社のトラブル事例を基に，自社シ 用しているシステムに対して）やるべ テストが役に立たないわけではな ステムの場合を考える」 （プライムリ きことがたくさんある」 （同社 常務取 い。 「やるべきテストをやらないでト ンク システム開発 栗原俊樹氏）といっ 締役 中村明氏） 。システムには未知の ラブルが起きたとしたら，それは人為 た地道な積み重ねが効いてくる。 不具合が存在することをまず認識し， 的災害」 （カブドットコム証券 齋藤氏） そのうえでトラブル対策を立てるよう である。 「とことん様々なパターンを かった，代表的なトラブル事例を紹介 になった。例えばソフトのパッチ情報 想定してトラブルをつぶす」 （京セラ する。 続くPart1では，予期するのが難し Nikkei System Integration 2003.11 95 特集 常を検知していたが，ステータスはそ Part1 事例 こで止まっていた。スタンバイ・サー トラブルは止められない バーに切り替えるにはプライマリ側の データベース・ソフトを正常に終了さ 「NIC，ディスク，ネットワーク機 り，停止したのはデータベース・サー せなければならず，その処理の終了を 器…。ほぼすべての機器の故障を経 バーのマシン。このトラブルによって 延々と待ち続けていた。データベース 験した」 （カブドットコム証券 阿部氏） 。 家電製品のカタログ情報を閲覧できな として採用したビーコンITのXMLデ ハードウエアの故障に対して冗長化構 くなった。家電を販売する同サイトに ータベース 「Tamino」の終了確認が取 成は有効な手段だが，肝となるクラス してみれば致命的なトラブルである。 れなかったため，スタンバイ・サーバ タリング・ソフトの機能範囲は実は限 リニューアル時に可用性の向上を図 ーに切り替わらなかった。 り，このような事態に備えてデータベ この例はフェールオーバーしなかっ ース・サーバー2台でクラスタリング た事例だが，クラスタリング・ソフト 構成を採っていた。プライマリ・サー の異常とは言えない。 「クラスタリン バーに不具合が生じればクラスタリン グ・ソフトは基本的にハードウエアの グ・ソフトが故障を検知し，スタンバ 障害に対するソフト」 （日本ヒューレ イ・サーバーのデータベース・ソフト ット・パッカード ビジネスクリティ を自動的に起動してサービスを継続す カルシステム統括本部 サーバプロダ ECサイト 「murauchi.com」を2003年2 る仕組みであった。しかし，クラスタ クト本部 OEマーケティング部 部長 月にリニューアル。データセンターに リング・ソフトは役に立たなかった。 栄谷政己氏）であるため，アプリケー サーバーを預けて運用監視体制を一新 異常に気づいた後，手動でスタンバ ションは基本的にサポート外。ムラウ した矢先の2月27日，CPUが故障して イ・サーバーに切り替えて約2時間後 チの例ではXMLデータベースの終了 1台のサーバーが停止した。同社のEC に復旧した。 処理が終わらなかったために起きてお 定的である。●● 事例 1 冗長化していたのに… クラスタリング・ソフト の限界 家電製品の販売を行うムラウチは， サイトはWebサーバーとデータベー 調査したところ，クラスタリング・ り，クラスタリング・ソフトとしては ス・サーバーの2層構造になってお ソフトは想定した通りにサーバーの異 どうすることもできない領域なのだ。 クラスタリング・ソフトを利用する クラスタリング・ソフト アプリケーション・ ソフト 際は，異常の定義に注意したい。クラ スタリング・ソフトは異常を検知した 後でフェールオーバーする機能を提供 “異常とは何か” “異常 異常とは何か 何か” を独自に策定 を独自 独自に策定 策定 ミドルウエア するが，異常の検出ルールは技術者の 異常の 異常 検知 フェール オーバー OS タイムアウト値などで ト値な 値などで 異常を定義 異常 定義 ハードウエア 設定しだい。ハードウエアに関しては タイムアウト値などを設定するだけで よいが，アプリケーションに関しては 「何を異常とするか」から決めなけれ 図3 ●クラスタリング・ソフトの限界 クラスタリング・ソフトの基本機能は，異常検知後にサーバーを切り替えること。切り替え処理に問題は少 ないが，異常の検知を漏れなく行うことは難しい 96 Nikkei System Integration 2003.11 ばならない（図3） 。一般的にはプロセ スの死活で判断することが多いが，カ トラブルと闘う 2003年3月某日24時過 2003年3月某日24時過ぎ 時過ぎ 3月某日から1泊を当日予約 予約 ブドットコム証券は「プロセスが生き ているにもかかわらず処理が継続でき ない状態になったために，フェールオ ーバーしなかった」 （カブドットコム 予約機能を強化 予約機能 強化 証券 阿部氏）という経験をした。クラ スタリング・ソフトの限界を知ってお きたい。●● 新予約システム 新予約 新機能 ●当日受付可能 前提条件 ●受付は午前3時まで可能 事例 2 テストしたのに… 前提が崩れ テストが無効に 新機能を追加したら既存の機能がお 在庫管理システム 在庫管理 予約は必ず 未来 2004年 2004 3月某日から 1泊の予約と 1泊の予約 の予約として処理 処理 図4 ●近畿日本ツーリストが経験したトラブル 予約機能の強化によって，在庫管理の前提条件が崩れてしまった。そのために，それまで問題がなかった在 庫管理システムで問題が起きた かしくなった。次はそんな例である。 大手旅行会社の近畿日本ツーリストが 情報が，翌年同日の予約になっていた う例だ。このような事態は，あいまい 提供するWeb上の予約サイト 「Tourist ことが分かった。調査した結果，この な仕様書が原因で起きやすい。 「パラ Village」は，顧客のニーズを取り入れ 問題の原因は機能強化を図った予約シ メータ設定に関する （仕様書の記述の） て次々と機能強化を図っている。最近 ステムではなく，予約システムと連携 認識違いでトラブルを招いた」 （松井 では，ホテルの予約受付を深夜の午前 する「在庫管理システム」にあった。 証券 大石氏） 。そのほかJTBとムラウ 3時までに延長し，当日の予約受付を 在庫管理システムが，今年の予約を翌 チでも，仕様書の解釈違いに起因する 可能にした。 年の予約に変えていた。 トラブルを経験している。解釈違いの 場合，間違いに気づくまで「正しい」 2003年3月のある深夜12時過ぎのこ なぜか。在庫管理システムは予約を と，今から泊まるホテルを予約した顧 受け付けると該当在庫を減らすが，そ と判断しているため，いくら確認チェ 客がいた。新機能が顧客のニーズを満 の場合の予約は必ず“未来”であるこ ックを行っても不具合として認識でき たした瞬間だった。予約システムの新 とを前提にしていたからだ。新機能を ない。あいまいな仕様書では解釈違い 機能はテストで確認した通りに稼働 追加するまでは，予約は必ず未来であ が起きやすく，トラブルが起きるまで し，顧客の希望をかなえることができ り，現在日時より古い日時の予約はあ 不具合箇所を特定するのは難しい。● た。ところが，その顧客がホテルに向 り得なかった。ところが予約システム かったところ，予約が取られていなか った （図4） 。たまたま空き部屋があっ の強化によって，この前提条件が崩れ 事例 3 市販ソフトなのに… た。前提条件が変わってしまえば，そ たので事なきを得たが，一歩間違えば れまでのテスト結果は意味をなさなく 顧客に迷惑をかけるところだった。 なる。 ホテルは近畿日本ツーリストに事情 近畿日本ツーリストの例は，それま ベンダーでさえ 分からない 2，3年前のことだが，リクルートが を説明。ホテル側で調べたところ，近 で正しいと判断して良かったものが， 運営する情報提供サイト 「ISIZE」が2 畿日本ツーリストから届けられた予約 途中で間違いに変わってしまったとい 日ほど止まったことがある。 「ディス Nikkei System Integration 2003.11 97