岡崎図書館はなぜおちたのか
勝手な予測をドヤ顔して書いて間違ったこといっちゃうのも恥ずかしいんだけどなんとなく書いてみる。
Like検索で落ちているんじゃないかというのがTwitterやブログでの大半の意見だけど、どうもそれだけが原因だとはなかなか思えない。だって、ベタにLike検索なげたとしても最近のサーバーは性能がいいからそれでもなんとか動くはずだ。
図書館のシステムがOracleをつかっていたというのが本当なら、インデックスを貼っていなくても、あまつさえフルインデックスにしちゃっても１００万件ぐらいのLike検索で、輻輳して落ちるほどまでいくかいな？
どうもそれだけとも思えないわけですよ。別の理由「も」あるんじゃないかな。
逮捕され２０日間拘留され、結果不起訴になった事件の当事者が説明ブログを立ち上げました。
岡崎市立中央図書館Webサイトから新着図書データを自動で取得するプログラムを実行し、同サイトの一部機能を利用できない状態にしたため、逮捕された容疑者が事件について解説
http://librahack.jp/
Like検索
著書名や著者名ぐらいのLike検索でシステムを落とすの大変だと思う。
著書名や著者名ぐらいのデータサイズでならインデックスさえちゃんと貼ってやれば、十分に機能するとおもう。
検索インデックス
そもそものシステムがインデックスがまったく貼られていなくてフルスキャンになっていた可能性というのはどうだろう？正直あまり考えられない。
少なくともこれだってひとつのシステムなのだから、システム設計ができるレベルの人物がつくっているハズで、そんなインデックスがどうこうというレベルでつまづくような人には完成までもっていく総合的な力がないはず。
ありそうなのが設計やオリジナルを作成したエンジニアと、現場を担当したエンジニアが違うケースだ。
現場にはいった人物が、図書館側などからの要望で、「本の概要も検索対象に含めてくれ」などといわれ、「できます（ｷﾘ」と対応した場合、著書名、著者名にはインデックスが貼られているが、本の概要にはインデックスが無いなどといった状態になりうる。素敵ワールドが発現する。低レベルのエンジニアのSQL小手先変更で要望の検索はできるようになるが、従来の設計には盛り込まれていたインデックスもぶち殺してしまうことになる。
みんなこのシステムを信じられないアフォシステムだと馬鹿にしているけど、どんなシステムだって、一撃で屑システムにできる。それがソフトウエアエンジニアリングだ……。逆はない。
１０階建のビルの１階を駐車場にしたいから、この柱を切ってといわれて、ノコギリしか使えない新人でもその柱を取っ払える……。そしてそのような変更は、事故がおきるまで発覚しないのだ……。
検索キー
噂によると１文字で検索できるという。まあ、これは設計レベルの話しだと思う。
微妙。「妹」とか、一文字で検索したいときもあるしね。
著書名ぐらいの捜査領域がせまければ、１文字でも十分機能するとおもうけど。走査対象のフィールドがテキストフィールドぐらいでかくなれば無理だよね。
設計思想を無視して改変すれば、いろいろなところでガタがでてくる。
テーブル結合
これもあまり考えられないのだけど、先程と同じように設定するエンジニアと設計した人が別だった場合おこりえる。
従来絞り込んでから結合をおこなうが、先のように変な修正をされることによって、フルスキャンされたうえで結合が入ると、指数関数的に負荷があがる。
１００万件のなかから１つのデータをさがすのぐらいであればさほど時間はかからないが、１００万件のなかから１つのデータをさがすのを１００万件繰り返すのをｘ回繰り返さなければならないなどというパターン。
検索が終わらない。
新人さんがやりがち。検索に時間がかかるというのなら、こちらのほうが原因かもしれない。
遅延についてはLike検索と、キーインデックスと結合の複合的要因である可能性が高い。
マシンの低スペック
これはないと思うなぁ。
こういう公共系は不必要なぐらい高いマシンを売りつけたり、やたら高いだけの保守費用でサーバ貸出するのがメインのビジネスなので、マシンが低スペックで落ちたというのは考えにくい。
I/O
デバッグ設定か何かがONになっていて、ログをファイルに書き出す仕組みかなんかが生きていて、クエリが発行されるたびに不必要な複数のディスクI/Oが発生していた可能性。こちらは十分ありうる。
またそのファイルが不必要に肥大化していたり、フラグメンテーションしちゃってたりしたら悲劇かもね。
まあでもこっちは、リアルにダウンするのでWEBのサービスリスタートじゃすまんので原因にはならないかな。
メモリとCPUは食いそうだからレイテンシの一要因にはなりそうだけどね。スレッド単位の遅延要因にはならないか。
RAIDとかダンプ
低スペックなマシン単体で動かしておけば十分なものも、不必要に高いシステムをうるのはよくある話し。さらにそれが仇になることがある。リアルタイムでバックアップ処理が行われていた場合や、アクセス分散のためのカラクリが仇となっているケース。
数十分間かかり続けた微弱な負荷のせいでバッチ処理的なものが終了せずに、どかーん！
まあ…ない。
セキュリティ関係のソフトがデータ転送とかの連携を邪魔しちゃってくれてて終わるはずの処理も終わらなくなってたとかはたまにあるよね。でも、そういうのは最初から終わらないので今回みたいなオーバーロードで落ちるっていうケースとは違うとは思いますけど。
DBコネクト
こっちのほうがありそうですね。ディスコネクションとかWEBサービス系だと結構実装から漏れたりしますよね。最近はDBが賢いからここらへんのガベージはあまり問題がないんだけど、可能性としては捨てきれない。
コネクション数に制限がある環境下とかで、どのDBを見に行くのかなんていうロードバランサ的な機能をサーバーサイドスクリプトの方に盛り込んだ場合、WEBサーバー-DBサーバーの連携がジャムしてぐっずぐずになる可能性もある。
図書館のシステムなので更新系はないとおもうのだけど、ログをDBに落としこむ仕組みだと、裏ではファイアーフォースモードとか、デッドロックとかでコネクション数がマックスまでいっちゃうとかね。まあ、ここらへんはいろいろ可能性がある。
結果として新規クエリ発行時に新しいコネクションが確立できず、webサーバーじゃなくて、サーバーサイドプログラムのほうで５０３とかを返す。遅延原因はSQLクエリかもしれないけど、落ちる原因はこっちかもしんないね。参照系だけの負荷でシステム吹っ飛ばすのはDosアタックでもしなきゃ無理なんじゃね？
感想
単純に考えたらシステムがだめだったというよりは設定や改変がだめだったというだけなのではないかなと思います。スパイダーボットで逮捕された方は本当に不運としかいいようがありません。人身御供、人柱です。
逮捕で名前報道こそされましたが、理解のある対応で立件には至らなかったようでなによりです。
結論から言えば、緊急性や身柄確保の必要がある逮捕だったとは思えません。
ですが他方でそれを判断する能力が警察や被害届を提出したユーザー側にないのも事実です。残念ですね。
逮捕されたかたの名誉回復の為に言うならば、この人の作ったクローラーは目的を達するため、また過重な負荷をかけないように配慮されたものであり悪意を感じさせるものではないと思います。
こういう方の意見を取り入れてシステムを設置すればもっと一般ユーザーの利便性もあがるものと思います。
もし罪があるとするならば、使いにくいものを自分が使うために使いやすくしようとしたところでしょうか。
使いにくいシステムを自分のために使いやすくする。
問題の根本解決ではないですよね。
使えないシステムをHackしても使えません。逮捕されます…。悲しい現実ですね。
ブスが痩せてもブスです。by 綾小路きみまろ
ダメシステムはチューニングしてもダメです(´･ω･｀)
宣伝
そうだ、明日のプログラマーズカフェは大部屋でやりますよー
http://atnd.org/events/4685
７階です。
プログラマーズカフェ終了後にmitaka.rbがあります。
http://atnd.org/events/4899
こちらは場所がレストランなので、キャンセル待ちですが、pgcafeのほうは実質100人はつっこめる部屋なのでいくらでも入れるよ('(ﾟ∀ﾟ∩
入場自由なのでお気軽にどうぞ！
（といってお気軽に来れない時間帯でやってるのがpgcafe）
