ローソンチケットのWebサイトが42日ぶりに復旧、原因はNEC製品のバグ

http://itpro.nikkeibp.co.jp/article/NEWS/20051202/225638/
http://slashdot.jp/articles/05/12/05/0640214.shtml

Java言語とは限らないけれど,*1

10月24日に閉鎖してから、実に42日ぶりの稼働となる。同社によれば、原因はNECのWebコンテンツ変換ソフト「MobilenetServer/WEB」の不具合。*2(中略)
MobilenetServer/WEBに高負荷がかかると、ごくまれに、本来ユーザーに返信するべきWebページとは別のページを返す事象が発生したのである。この原因を究明するのに約1カ月を要したのは、「同じ現象がめったに発生しなかったから」(ローソンチケット)だという。

えーっと,ひょっとして,お約束の同期バグ?*3

滅多に発生しないから検出が難しいが,だからこそ極めて悪質なバグとして有名なのだ.*4テストやデバッグが極めて難しいので*5,基本的なアルゴリズムの設計段階から同期バグを排除できるように設計するのが鉄則になっている.

同期バグの原因究明が一ヶ月で済んだとすれば,まだ運のいい方だ.


世の中には同期のことを理解せずにJ2EE開発を行っている者もいるらしい.世も末だ.
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=26411&forum=12

*1:Javaとは限らないけれど,この手のサイトだとかなり高い確率でJavaだろうな.まさかC#PHPで作りたいとは思わない.

*2:「コンテンツ変換ソフトの不具合」.何故か悪寒が.

*3:並列プログラムであれば,同期の問題自体は言語によらず存在する.クリティカルセクションやロック等の同期プリミティブ,擬似共有などの基本的な考え方も同じ.ただし言語によって使われる同期プリミティブやメモリモデルなどが少しずつ異なるために,プログラミングの詳細まで完全に同じというわけではない.

*4:ひょっとしたら最悪かもしれない.悪質なバグとしてはメモリリークが有名だが,メモリリークは「少しずつ」ジワジワとメモリを食いつぶすだけなので,致命的な状態にはなかなかならない.緊急対応としてならメモリやサーバーを増やして,さらに一定時間ごとにアプリを再起動する対処療法で急場を凌ぐという手も考えられる.そうすれば今回のような一ヶ月以上のサービス停止という危機は避けることができただろう.
これに対し同期バグは,発生するときは正に瞬時に発生する.その結果として何が起こるかはアプリ次第だが,サーバーサイドだと同期バグは致命的状態におちいり易い.例えば他人に個人情報やパスワードが見られてしまったり,預金や株取引が謝って操作されて数百万の損失を被るかも知れない.しかもメモリリークのように簡単な回避策は存在しないので,まれにでもこういうトラブルが発生すれば今回の一件のように長期に渡るサービス停止を余儀なくされる.

*5:同期バグのテストは基本的に不可能である.負荷テストも気休め程度にしかならない.負荷テストで運良く検出できる同期バグもあるけれど,負荷テストで検出できない同期バグは遙かに多いのだ.さらに言えばデバッガもほとんど頼りにならないので,デバッガ頼みのデバッグしかできない者は満足にデバッグもできなくなる.