4月1日に発生したJALのシステム障害は追加されたキャッシュの排他処理によるデッドロックが原因 16
ストーリー by hylom
どうしてこうなった 部門より
どうしてこうなった 部門より
あるAnonymous Coward 曰く、
4月1日、日本航空の重量管理システムで障害が発生したが、この原因が新たに追加されたキャッシュの排他制御機構にあることが判明した。元々実装されていたディスクの排他制御との間でデッドロックが発生したために障害が起きたという（日経ITpro）。
3月23日に開発元から提供されたパッチでキャッシュの排他制御機構が追加されたそうだが、なぜこの排他制御機構が追加されたのかは不明だという。
なぜこの排他制御機構が追加されたのかは不明だという。 (スコア:5, 参考になる)
> なぜこの排他制御機構が追加されたのかは不明だという。
が気になったけどJALの言葉なんですね。
http://itpro.nikkeibp.co.jp/atcl/news/16/040601011/?ST=erm&P=2 [nikkeibp.co.jp]
従来キャッシュへのアクセス時は、ほとんどが読み出しだけで書き込み処理がほぼないとの理由で排他制御を行っていなかった。一方、データベースサーバーのディスクに対するアクセスは書き込みが大半であり、当初からアクセス時に排他制御を行う設計となっていた。「なぜキャッシュの排他制御を施すことにしたのかについて、説明は受けていない。またパッチの内容についても詳しい説明は受けていない」（JAL）という。
Re: (スコア:0)
> パッチの内容についても詳しい説明は受けていない
最大の問題はここだろうけど、説明を受けたところで回避できたかというと疑問。
Re:なぜこの排他制御機構が追加されたのかは不明だという。 (スコア:2)
トラブルの発端となったのは、LHSから提供を受けJALが3月23日に適用したパッチ。この中に、アプリケーションサーバーのキャッシュへアクセスする際に排他制御を行うようにする設計変更が含まれていた。このパッチはJAL以外のユーザー企業からの要望で提供されたものという。
こんなの回避無理でしょ。LHS自体が把握してなかったんだから。
真犯人は誰だ。
Re: (スコア:0)
請ける側にとってはJALの責任にできるということろが重要で、回避できるかどうかはぶっちゃけどうでもいい
キャッシュの排他制御機構？ (スコア:2)
Re: (スコア:0)
キャッシュと本物が互いの排他をとって互いに更新しようとしたんじゃない？
Re:キャッシュの排他制御機構？ (スコア:3, 参考になる)
・キャッシュは、ほぼ読み込みのみ
・ディスクは、読み書きがある
・キャッシュとディスクはネットワーク上の別ノード
当初
・ディスクのみ排他処理アリ
パッチ後
・キャッシュ、ディスクともに「個々に」排他処理アリ
問題点
・トランザクション的に次の２パターンがあった
1.キャッシュアクセス → ディスクアクセス
2.ディスクアクセス → キャッシュアクセス
・キャッシュアクセス、ディスクアクセスで別々に排他処理をしていた
開けてみればシンプルなデッドロックではありますが・・・・
Re:キャッシュの排他制御機構？ (スコア:4, 参考になる)
システム構成図見る限り、アプリケーションサーバにキャッシュを持たせるという構成がそもそもダメだと思う。
素直にデータベースサーバを増強するか、百歩譲っても、そういうトリッキーな構成を採るなら、きちんとデータの整合性が確保できるようにデータ更新のお作法の基準を決めてレビュー項目・テスト項目に入れておかなくちゃダメだろ。
だいたい、ロック機構を入れてデッドロックが起こったということは、実はこれまでもデータの上書きが発生してたけど、問題が露見しなかっただけという可能性も十分考えられる。
システム組む人なら、まずは、あの構成図見て「これはイカン」と感じるセンスが必要だと思う。そして予算がなくて工夫でカバーするにも、それなりの手当てが必要だということも理解しないと。
Re: (スコア:0)
教科書に乗ってそうなくらい綺麗な例ですね。
垢抜けない多重ロック (スコア:0)
今はプログラミングからは離れていますが…
同時に複数のオブジェクトのロックを使用する場合は順序（アドレス順とか）を決めればいいのですが…オブジェクト指向でインタフェースをシンプルで使い易くする為に御親切にも内部の奥深くでロックを使用するようなライブラリで、ロックの必要があるオブジェクトを複数使用する場合（特にオブジェクトの種類やライブラリが別のオブジェクトで）はちょっと悩みますね（同種の場合はコピーやスワップ、演算等ができるように、同時ロックが内部で行われていたりもしますが…。）
ソースが提供されていても面倒で、ロッ
Re: (スコア:0)
ほぼ読み込みのみでも書き込みがあるなら、当然、排他制御はした方がいい。でも1.と2.の両方があるならタイミング次第でデッドロックになることは火を見るより明らかだから、キャッシュアクセスやディスクアクセスじゃなくて、1.と2.の両方に共通する排他制御が必要。
JAL(ルフトハンザ)はパッチをbackoutしようと思ってるから、デッドロックは避けられても、長期的に見れば不安を抱えることになるな。あと、今はデッドロック上等の状況で運用してることにもちょっと驚いた。でも、そりゃそうか。職員のみなさんはお疲れさまです。
Re: (スコア:0)
キャッシュとディスクで別々に排他処理してたなら
1 ロック(C)→キャッシュアクセス→アンロック(C)→ロック(D)→ディスクアクセス→アンロック(D)
2 ロック(D)→ディスクアクセス→アンロック(D)→ロック(C)→キャッシュアクセス→アンロック(C)
でデットロックしないと思うんだけど
1 ロック(C)→キャッシュアクセス→ロック(D)＜ここでデッドロック＞→ディスクアクセス→アンロック(D)→アンロック(C）
2 ロック(D)→ディスクアクセス→ロック(C)＜ここでデッドロック＞→キャッシュアクセス→アンロック(C)→アンロック(D)
みたいに、キャッシュアクセスの中でディスクアクセス（およびその逆）があるならなら解るんだけど
Re: (スコア:0)
ディスクとキャッシュで同じはずの値を格納している変数にアクセスして比較するわけだから、アクセス中にディスクの値が変わってしまうと意味がないんだと思う。
つまり、元々
2. ロック(D)→アクセス(D)→アクセス(C)→アンロック(D)
だったんじゃないかな。
ここでキャッシュのロックを実装してしまうと
「アクセス(C)」の部分が「ロック(C)→アクセス(C)→アンロック(C)」に置き換わるわけだから、
2. ロック(D)→アクセス(D)→ロック(C)→アクセス(C)→アンロック(C)→アンロック(D)
になるのが自然だと思う。
Re: (スコア:0)
白ヤギさんからお手紙ついた、黒ヤギさんたら読まずに食べた
仕方がないのでお手紙書いた「さっきの手紙のご用事なあに」
黒ヤギさんからお手紙ついた、白ヤギさんたら読まずに食べた
仕方がないのでお手紙書いた「さっきの手紙のご用事なあに」
：
：
：
こんな感じ？
Re: (スコア:0)
Re: (スコア:0)
こっちもデッドロックですか。