2006年02月02日

東京ガスが顧客管理システムの更改に失敗、50億の損害

http://headlines.yahoo.co.jp/hl?a=20060201-00000178-kyodo-bus_all
http://www.yomiuri.co.jp/atmoney/news/20060201i215.htm

ここ最近東証とかでも頻繁に起きているシステム更改の失敗が、東京ガスにも発生してしまったようだ。しかも損害額は50億。東証とはスケールが違うね。

IT関連の失敗事例なので、スラッシュドットでも話題になっているようだ。
http://slashdot.jp/article.pl?sid=06/02/01/153219
さて上記スラッシュドットの話題をもとに推測または憶測または妄想してみよう。
まずこのシステム更改を失敗とした理由なんだけれども、顧客情報の検索レスポンスが既存システムより40秒も遅く、とても業務に耐えられないということのようだ。

今までどれくらいの時間で顧客情報を検索していたのかわからないけど、コンピュータの世界の40秒というのは物凄く長い時間だ。音楽の分野から見てもそうだよね。下手すると1曲が終わってしまっている場合もある。例えばS.O.D.の"Speak English Or Die"に収録されている"The Ballad Of Jimi Hendrix"なんかがそうだ。これは4秒だ。また同じように"Diamond And Rust"は2秒だ。比較する対象を著しく間違っているような気もするけど、とにかくとても長いであることは間違いないんだ。

さてその対象となる顧客の数だけど、東京ガスの発表によると取付メーター数は去年の12月現在で約9,743,000件。恐らくこれが顧客数となっているんじゃないかな。で、たぶんこのメーター一つ一つにユニークなIDが振られていることだと思う。便宜上「顧客ID」とでも呼んでおこうか。

僕の開発経験では、顧客に関するデータはこの顧客IDを検索キーとして設定し、その他の情報(例えば住所とか電話番号とか契約者の名前とか好きなロックは何かとか)をデータベース化するというのが一般的だ。
例えば顧客ID「A00001」の●●さんは東京都千代田区に住んでいて、好きなバンドはMEGADETHだとかね。ワオ! MEGADETHが好きだなんてクールじゃないか。

いや、とりあえずMEGADETHが好きかとかSLAYERが好きだとかはおいといて、このように検索キーとされる情報(この場合は顧客IDという部分だ)は、予めデータベースエンジンも探しやすいようにインデクスというものを作成しておくものだ。

インデクスというのはそのまんまずばり目次だね。書籍にある目次と全く同じだ。
「イングヴェイ来日独占インタビューは●●ページ」とか「芸能界お宝流出写真は●●ページ」とかいうように、「顧客IDがA00001の情報はハードディスクのこのへんから」というように書かれているんだ。
お陰でデータベースに登録されている情報全てをいちいち探さず、素早く目的の場所を探し当てることができる仕組みになっている。

前振りが長くなってしまったけど、たかだか1,000万件程度のレコードインデクスを調べるのに40秒もかかるというのはちょっとおかしいと感じたんだ。どんなデータベースを使っているのかわからないし、あくまで僕の経験則が元になっているだけなんだけどね。


因みにおかしいと思っているのは僕だけではなくて、/.-Jの中の人達も疑っているみたいだ。
例えば

---
まーさーかー、カーソルをループ回して頭から最後まで自前のコードで舐めてるんじゃなかろうな。
---
(略)
顧客番号といったら普通ユニークキーなわけで、どうやったらユニークキーによる検索でそれだけの時間がかかるような糞システムを作れるのかさっぱり理解できませんね。
(略)
ちなみに、私が仕事で顧客情報のDBを作った時が氏名50桁住所100桁くらいだったから諸々の属性情報を多めに見積もって顧客一件300byteと仮定したら
1000万件で3GB、
端末とサーバは1000Baseで結ばれているとして3GBの転送にかかる時間は
3000*8/1000 = 24秒
実際には帯域の半分くらいしか使えないとすると48秒

48秒ということは
顧客番号で検索して、現行システムより40秒以上
にだいたい合致するではないですか!!!

謎は全て解けた !!!!!

結論:このシステムを組んだ奴はデータベースの正しい使い方も知らないド素人
---

↑インデクスを使っていない、そもそもインデクスを作っていないんじゃないかという疑惑。

---
顧客番号ってユニークだとおもう
手元の検針票見ると4桁-3桁-4桁の番号
いくら1億レコードあったとしても、uniq indexなフィールドの検索に40秒ってそんなバナナって気がする。

既存システムとの連携のためテーブル構造の変更不可
新番号と旧番号の変換に変換テーブル使用
マスターテーブルや変換テーブルの不整備により参照整合性が破綻、外部結合使用
外部結合を二重に使うので一旦一時的な検索結果を一時テーブルに保存してから再度検索
とかならそこまで遅いの納得するかも
---

↑既存システムとは違うコード体系の顧客IDを使う為、変換しまくって遅くなっているんじゃないかという疑惑。


ひょっとしたらこの2つの疑惑の両方が当てはまるのかもしれないね。
コード体系が変わってしまったお陰で旧コードから新コードへの変換をしなくてはならない。
更にその変換のキーに対してインデクスが作成されていなく(呼び出す度に全件検索)、ものすごーい時間がかかってしまっている、とか…。

何にせよ旧システムの動きを完全に把握していないまま稼働工程にまで行ってしまったような気がするよ。全く悲しい話だね。

ていうか今僕が関わっているシステムもちょうどこんな感じだ。そろそろ納品だけどすごく不安になってきたよ(笑)。
posted by カリフラワー・ジョー:芋場町の人 at 22:12| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

この記事へのトラックバックURL
http://blog.seesaa.jp/tb/12659467

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。