(cache) 岡崎図書館事件について - SQLer 生島勘富の日記

2010-06-21

岡崎図書館事件について

　以下、憶測ですけれど、多分、当たってますよ。

　岡崎市立中央図書館（りぶら）のウェブサイトにアクセスを繰り返して、ほかの利用者が閲覧しにくい状態にしたとして、偽計業務妨害で容疑者が逮捕された。

　という事件について、不起訴になった方がその内容を公開され始めた。

　今ある情報だけで考察するのは拙速かも知れないけれど、私の思うところについて。

　1日2000リクエスト30分で終わる程度のアクセスで、使いにくい新着図書のページをクロールしてオリジナルのデータベースを作ろうとされたそうです。1日2000リクエストで半月ほど運用して33,000回ほどアクセスしたことが偽計業務妨害に当たるとして逮捕されたようです。新聞発表とも合っていますからウソはないでしょう。

　で、気になって対象の図書館の蔵書検索をしてみました。

　http://www.library.okazaki.aichi.jp/tosho/asp/kensaku_g.asp

　検索が速いときと、数十秒掛かるときがあります。蔵書数は100万点らしくレコード長は600～800Byte程度のようです。つまり、蔵書のデータ量は800MByteぐらいのものです。今のサーバなら間違いなく全データがメモリーに載っています。

　このデータ量で遅いときの動作を見る限り、蔵書検索では単純にLIKE検索しているようです。同じキーワードで時間を空けて検索しても次からは速いので、検索結果をキャッシュする形になっているのでしょう。

　不起訴になった方（もう少しよい呼び方はないのか）のプログラムは

　http://www.library.okazaki.aichi.jp/tosho/Asp/Syousai_g.asp?TosCode=xxxxxxxxx

　という形でクロールするプログラムになっているようで、これのレスポンスは良くキー読みになっているでしょう。レコード長が800Byteとするならば、2000リクエストしても、1.6MByteほどのメモリー上のアクセスしかしない。インデックスを含めても2MByte程度でしょう。CPUも一瞬しか使わない。

　つまり、サーバに負荷なんて掛かってないのです。

　しかし、もし、単純なLIKE検索を行っているという予想が当たっていてたとしたら（個人的には間違いないと思っているけどね）、メモリー上とはいえ800MByteをフルスキャンしなければならない。数十秒掛かっているので輻輳する可能性も高い。新規のキーワードの検索が輻輳したらサーバが止まっても不思議はない。

　Like検索1回は、1日2000回のリクエストの数百倍の負荷が掛かっている計算になるのです。

　更に、現在の情報では分からないけれど、cronで日中のアクセスが多い時間に廻ったとは考えにくい。もし、日中にクロールしていたのならちょっと配慮が足らなかったと言えるかも知れないが、サーバが落ちた時間とクロールしていた時間が完全にズレていたんじゃないか？

　これで逮捕はあまりにも非道い。名誉毀損で訴えても良いぐらいの内容だな。

　岡崎私立図書館に入っているシステムはこれらしい。 http://www.mdis.co.jp/case/city-okazaki/200908.html

　三菱さん。弊社の全文検索エンジンを買ってよ。