岡崎市立図書館の件
この件、一部で「1秒に1クエリ」という数字が多いか少ないか議論になっていたので、この点について検討してみます。
(なお本件の法的側面については、id:fuka_fukaさんがまとめてくれているのが参考になります。http://d.hatena.ne.jp/fuka_fuka/20100624/p1)
■試算
Libraそのものの平均アクセス量は不明だが、横浜市立図書館蔵書検索トップページのPV約53万PV/月を参考にする(http://www.city.yokohama.jp/me/kyoiku/library/ad/)と、横浜市の人口約368万(H22/6/1現在)と岡崎市の人口約37.6万(H22/6/1現在)の比率から、LibraトップページのPVは約5.4万PV/月であると推定できる。まず、これを30で割って、約1800PV/日を算出する。
上記により1PVあたりの平均アクセス間隔は48秒となるが、ピーク特性を考慮する必要があるので、仮にピークPVが平均PVの3倍とすると、ピーク時は1PVあたり16秒となる。
さらに、「蔵書検索トップページ」への1PVにつき、平均どの程度の検索クエリが発生するかを算出する必要があるが、横浜市立図書館蔵書検索の仕組み上(ここで見るべきはLibraの仕組みでない点に注意)、
(1)検索結果ページでの再検索が不可
(2)検索結果ページから蔵書検索トップへの遷移がPOSTメソッドで、キャッシュが効いてない
といった点を考慮し、ブラウザバック経由での再検索を最大限考慮しても、蔵書検索トップ1PVに対する検索クエリは2を超えないと推定する。
■結論
結論として、問題となったスクリプトがなかった場合のLibra検索クエリ数は、ピーク時でも8秒間に1度以下であったと推定します。このため、「1ユーザが毎秒1クエリを送出する」という事態は、キャパシティ要件の範囲外であったと思われます。
■だから？
相手サーバの正確なキャパシティなんて事前に知りようがないわけで、Librahackさんのスクリプトが起こした「最初の」システムダウンは不可抗力的側面もあったと思います。
しかし、スクリプトを慎重にモニタリングしていれば相手サーバの不調には気づけたでしょうから、2回目から21回目までのシステムダウンは本来防げたのではないでしょうか。人様のサーバにスクリプトで連続クエリを送るのであれば、この「慎重なモニタリング」はプロとして絶対に欠かしてはいけないプロセスだったと思います。(もちろん事前に相手の了解を得るのが最善ですが。)
念のため申し添えますが、高木先生他が指摘してるように過失と刑事責任は別ですし、今回の逮捕が適切であったとは私も全く思いません。しかし勢いあまって「Librahackさんに全く過失がない」かのようにまで言ってしまうのも、技術者として避けるべき態度だと考えます。
■つーかキャパの問題じゃなくLibraのバグなんじゃ？
DBコネクションの開放にバグがあったのでは、と一部で言われてますね。これに関しては、十分に説得力のある推定だと思います。ただし、これを「バグ」と呼ぶかどうかは、要件次第だったりします。どんなに糞な実装でも、キャパシティ要件内のリクエストを正常に捌けていたなら仕様と言えます。例えば、仮にDBメンテの都合かなんかで「1日に1度再起動する」という運用要件だったとすると、「コネクション開放しなくても限界に達する前に再起動するので運用上問題ない」から「仕様だよねこれは」という判断もあり得ます。まあこれは根拠ある推定ではなくあくまで一般論。
■余談:思い出話
ぶっちゃけ、私も昔こういうスクレイピングツール作ったことがあります。バイト先のPC向けで処理系がインストールできなかったので、PerlとかPHPじゃなく、CとWinsock使って自前でHTTP喋ってHTML解析という悲しい代物でしたが。だからこれで逮捕とかマジきついしやめてほしいのは完全に同意なんです。ただし、当時私はプロじゃなく学生で、相手も市立図書館ではなく某巨大ネット書店でしたけど、それでも、レスポンスから次リクエストまでに十分でランダムなディレイを置くとか(Librahackさんはレスポンス起算でなく、リクエストから次リクエストまでの固定ディレイとのこと)、相手のレスポンスに異常がないか常にモニタリングするとか、それなりに気は遣ってましたよ。
■余談2:SIerって……
別の視点として、「秒間1クエリを捌けないSIerの技術力ってどうよ？」というのはあるでしょう。確かにSIerの主な存在意義って「いつでも何人でも人を用意する」とか「プロジェクトが億単位の赤字を出しても逃げない潰れない」だったりするので、いつでも人を用意するために逆に「技術的に高度なことはなるべくしない」が美徳だったりする世界。そりゃギークさん達と比べれば技術力は低い……場合が多い。
ただパフォーマンスが出ないことに関しては、「システム要件としてpoorなDBシステムとDBLinkが必要」とか「糞なパッケージだが予算上これでいくしかない」とか「糞なHWだけど以下同文」とか「最低限のキャパシティ要件しか満たしてないけど予算上以下同文」とか「Oracleのパッチ当てたら高速化するけど保守の予算上以下同文」(趣味プログラマの時は知らなかったけど、ちょっとした修正でもテスト工数やら何やらで結構かかるんだね！)とか色々事情もあるかも知れない場合もなきにしもあらずなので、SIerの技術力だけに原因を短絡するのもどうかな、とか思ったり思わなかったりするわけです。
まあ、多分どーせそこのPMがグズだったんでしょうけどハハ。
以上
(なお本件の法的側面については、id:fuka_fukaさんがまとめてくれているのが参考になります。http://d.hatena.ne.jp/fuka_fuka/20100624/p1)
■試算
Libraそのものの平均アクセス量は不明だが、横浜市立図書館蔵書検索トップページのPV約53万PV/月を参考にする(http://www.city.yokohama.jp/me/kyoiku/library/ad/)と、横浜市の人口約368万(H22/6/1現在)と岡崎市の人口約37.6万(H22/6/1現在)の比率から、LibraトップページのPVは約5.4万PV/月であると推定できる。まず、これを30で割って、約1800PV/日を算出する。
上記により1PVあたりの平均アクセス間隔は48秒となるが、ピーク特性を考慮する必要があるので、仮にピークPVが平均PVの3倍とすると、ピーク時は1PVあたり16秒となる。
さらに、「蔵書検索トップページ」への1PVにつき、平均どの程度の検索クエリが発生するかを算出する必要があるが、横浜市立図書館蔵書検索の仕組み上(ここで見るべきはLibraの仕組みでない点に注意)、
(1)検索結果ページでの再検索が不可
(2)検索結果ページから蔵書検索トップへの遷移がPOSTメソッドで、キャッシュが効いてない
といった点を考慮し、ブラウザバック経由での再検索を最大限考慮しても、蔵書検索トップ1PVに対する検索クエリは2を超えないと推定する。
■結論
結論として、問題となったスクリプトがなかった場合のLibra検索クエリ数は、ピーク時でも8秒間に1度以下であったと推定します。このため、「1ユーザが毎秒1クエリを送出する」という事態は、キャパシティ要件の範囲外であったと思われます。
■だから？
相手サーバの正確なキャパシティなんて事前に知りようがないわけで、Librahackさんのスクリプトが起こした「最初の」システムダウンは不可抗力的側面もあったと思います。
しかし、スクリプトを慎重にモニタリングしていれば相手サーバの不調には気づけたでしょうから、2回目から21回目までのシステムダウンは本来防げたのではないでしょうか。人様のサーバにスクリプトで連続クエリを送るのであれば、この「慎重なモニタリング」はプロとして絶対に欠かしてはいけないプロセスだったと思います。(もちろん事前に相手の了解を得るのが最善ですが。)
念のため申し添えますが、高木先生他が指摘してるように過失と刑事責任は別ですし、今回の逮捕が適切であったとは私も全く思いません。しかし勢いあまって「Librahackさんに全く過失がない」かのようにまで言ってしまうのも、技術者として避けるべき態度だと考えます。
■つーかキャパの問題じゃなくLibraのバグなんじゃ？
DBコネクションの開放にバグがあったのでは、と一部で言われてますね。これに関しては、十分に説得力のある推定だと思います。ただし、これを「バグ」と呼ぶかどうかは、要件次第だったりします。どんなに糞な実装でも、キャパシティ要件内のリクエストを正常に捌けていたなら仕様と言えます。例えば、仮にDBメンテの都合かなんかで「1日に1度再起動する」という運用要件だったとすると、「コネクション開放しなくても限界に達する前に再起動するので運用上問題ない」から「仕様だよねこれは」という判断もあり得ます。まあこれは根拠ある推定ではなくあくまで一般論。
■余談:思い出話
ぶっちゃけ、私も昔こういうスクレイピングツール作ったことがあります。バイト先のPC向けで処理系がインストールできなかったので、PerlとかPHPじゃなく、CとWinsock使って自前でHTTP喋ってHTML解析という悲しい代物でしたが。だからこれで逮捕とかマジきついしやめてほしいのは完全に同意なんです。ただし、当時私はプロじゃなく学生で、相手も市立図書館ではなく某巨大ネット書店でしたけど、それでも、レスポンスから次リクエストまでに十分でランダムなディレイを置くとか(Librahackさんはレスポンス起算でなく、リクエストから次リクエストまでの固定ディレイとのこと)、相手のレスポンスに異常がないか常にモニタリングするとか、それなりに気は遣ってましたよ。
■余談2:SIerって……
別の視点として、「秒間1クエリを捌けないSIerの技術力ってどうよ？」というのはあるでしょう。確かにSIerの主な存在意義って「いつでも何人でも人を用意する」とか「プロジェクトが億単位の赤字を出しても逃げない潰れない」だったりするので、いつでも人を用意するために逆に「技術的に高度なことはなるべくしない」が美徳だったりする世界。そりゃギークさん達と比べれば技術力は低い……場合が多い。
ただパフォーマンスが出ないことに関しては、「システム要件としてpoorなDBシステムとDBLinkが必要」とか「糞なパッケージだが予算上これでいくしかない」とか「糞なHWだけど以下同文」とか「最低限のキャパシティ要件しか満たしてないけど予算上以下同文」とか「Oracleのパッチ当てたら高速化するけど保守の予算上以下同文」(趣味プログラマの時は知らなかったけど、ちょっとした修正でもテスト工数やら何やらで結構かかるんだね！)とか色々事情もあるかも知れない場合もなきにしもあらずなので、SIerの技術力だけに原因を短絡するのもどうかな、とか思ったり思わなかったりするわけです。
まあ、多分どーせそこのPMがグズだったんでしょうけどハハ。
以上