« iモード.net | トップページ | マヌケ時空(古)発生中 »

2008.03.11

デッドロック

東証システム障害、原因は注文集中による「デッドロック」

デッドロックが原因というのは、まぁ、ありがちと言えばありがちですが・・・

東証のシステムでは、注文をデータベースに登録する際、ほかの注文が書き込まれないよう「デッドロック」と呼ばれるロックをかける。

デッドロックをかけちゃイカンだろ(^^;
仮にもIT系ニュースサイトを謳うITmediaの記者や、記事の公開を認めたデスクが、この記事のおかしさに気付かないというのは、東証以上に問題があるような気が・・・

ちなみに、ここはプログラマ以外の人も見てるので、蛇足的に解説を付けておくと、他の処理で上書きされてしまわないようにする処理は「ロック」で、このロックは前の処理が終了すれば解除されて次の処理が「ロック」して・・・と続いて行くのが通常。
しかし、複数のロックが必要な状態で、その複数のロックをどの処理もできないままに、お互い待ち続けてしまうような状態になったのが「デッドロック」

たとえば通販で、店側は「振り込みが確認できないと発送しない」と振り込み待ちをして、お客側は「品物が来ないと入金しない」と商品の到着を待ってたら、いつまで経っても店は商品を送らず、お客も金を振り込まずという状態になってしまう。
こういう状態が「デッドロック」です。

通常は、「銀行振込みの場合は前払いです」と明示したり、クレジットカードなどで入金は無いまでも一定の「回収の保証」を取り付けた上で先に商品を送ったり、ロックを一か所にまとめるために代引にしたりという感じで「デッドロック」を起こさないようなビジネスロジックを作ります。

コンピュータでの処理も同様に、「デッドロック」を起こさないようなロジックとなるよう慎重に設計しますし、更にクリチカルなシステムでは、万が一デッドロックが起こった場合にはそれを検出して強制的にロックを解除して一定のリカバリをするようになっている場合もあります。
(それほどクリチカルでない場合は、手動で止めたりするけど)

いずれにせよ、設計上「デッドロック」は起こるべきではない事象です。

と、長々と解説を書いてるうちに、さすがにココまでヒドいのはITmediaも気付いたようで(^^;速攻で差し替えられてますね。

登録の再試行は100回までと設定されていたが、3月10日は短時間に大量の注文が集中したため、上限回数を超えても2銘柄の注文が登録できない「デッドロック」が発生し、システムが停止したという。

それは単にリトライ回数制限を超えただけで「デッドロック」ではないでしょう。
って東証のリリースにも「デッドロック」と書かれてますが、本当に理解した上で書いてるんだろうか?

「デッドロック」というのは、ロジック上いつまで待っても(リカバリ処理が無ければ)絶対に進まない状況で使う語であって、単に処理負荷に対してシステムのリソースが足らなくてタイムアウトしてしまうようなのは「デッドロック」ではありません。
システムリソース不足が原因なのか、システムロジックが原因なのかという、全く違う原因に起因する事なので、この違いは重要。

先の通販の例で言えば、ビジネスロジック上問題があって「デッドロック」になっているのか、注文が多すぎて発送が間に合わないのかの違いと言ったら良いでしょうか。
ロジック上の問題であれば、ロジックを見直さなきゃいけないし、発送が追い付いていないのなら発送の担当者を増やすとかしなきゃいけない。
ロジックの問題なのに人を増やしたり、人手の問題なのにロジックばかり見直してても、解決はできません。

【追記】
思考維持装置さんから久々にマトモなトラックバック(謎)をもらったので拝見したのですが、ここでリンクされていたITProの記事にちょっと詳細な原因(というか現象)の解説が載っていました。
この記事も何かおかしいが(^^;
まぁ、記事というより、東証の説明がおかしいんだろうけど、それをそのまま記事にするのもどうかと・・・

どの辺がおかしいかというと

デッドロックが発生した場合、後から起動したトランザクションを強制的に終了させて先行するトランザクションを優先的に完了させるのが一般的だ。

というあたりとか(他にもあるけど)。
「デッドロック」は「死んだロック」であって、デッドロックに陥れば何回待とうと何十年待とうと先行する処理は終わらない。
もう死んでるんだからいくら待っても生き返ったりはしない。
だから、本当に「デッドロック」ならば、先行する(引っかかってる)トランザクションを強制終了しないとダメですね。
(もちろん、関連する処理のロールバックやロックの強制解除とか含めて)

ここからは想像、というかむしろ妄想(^^;ですが、ありそうな事象は2通り。

まず一つ目のパターンは本当にデッドロックで引っかかった。
東証のシステムはボロボロ継ぎ接ぎだらけだし、ハードやOSもリプレース/増強し続けているので、当初設計ではありえないと思われていたようなタイミングでデッドロックが発生してしまったという可能性は十分考えられる。
で、あるタイミングで競合する処理が来るとデッドロックしてしまうようになっていた所に、大量の注文が来る事によって、偶然そのタイミングに合致してしまう状況が現れてしまった。
説明がおかしいのは、単に説明した人の理解不足。
というパターン。

もう一つ考えられるのは、実はデッドロックじゃない可能性。
当初設計では、「いくら時間がかかっても100回試行すればOKのハズ。それでもダメならデッドロックだろうからリカバリ処理に移ろう」と考えられていたのが、システムリソースの枯渇(というか想定以上のトランザクション量)で「正常に処理は進んでるんだけど、極端に遅くなって100回のリトライでも成功できない程になってしまった」という可能性。
で、ベンダの「大量の注文による処理の遅延のために、デッドロック検出機構に引っかかってしまいました」という説明を「原因はデッドロック」と東証が誤って理解してしまったというのもありそうなパターン。

ま、どちらが(あるいは他の何かが)正解かは現時点ではわかりませんが・・・

|

« iモード.net | トップページ | マヌケ時空(古)発生中 »

日記・コラム・つぶやき」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/4003/40465797

この記事へのトラックバック一覧です: デッドロック:

» [情報技術]東証システム障害の原因 [思考維持装置]
東証がシステム障害で2銘柄の取引が一時停止になった件について。 ITMeaiaの記事では最初「東証のシステムでは、注文をデータベースに登録する際、ほかの注文が書き込まれないよう「デッドロック」と呼ばれるロックをかける。」と書いてあったのだが、後で「「デッドロック... [続きを読む]

受信: 2008.03.11 21:49

« iモード.net | トップページ | マヌケ時空(古)発生中 »