2010年07月09日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1GRAILSの講演会[LL][GRAILS] このエントリーをはてなブックマークに追加

地元のフォーラムの関係で GRAILS[http://www.grails.org/] の講演会を聞きに行ってきた。予習なし。

Groovyの言語仕様:

Groovyについて。PerlとかJavaScript触ってると、Javaを書いているときに、「どうしてこれができんのだ!」ということが解決できて嬉しいいという言語仕様。
ただ、チーム開発時には、Lintが欲しいかも知れない。
ドメインモデル。「RDBスキーマに特別なこだわりがある場合には、Grailsは使うべきではない」
HIBERNATE。「セッション」という概念が中心になる。セッションには過去のオブジェクトが永続化されているイメージ。Grailsでは、httpセッションとhibernateセッションが同期しているのが大きな特徴。
トランザクションには課題がある→RDBスキーマに特別なこだわりがある場合には…
Hibernateを活用するためにも、できるだけ単純なドメイン・モデルに昇華させる(このあたり、どのデータベース使っても同じ)

ドメイン固有言語(DSL):

仕様から実装の生成。「形式仕様書け」そんなん無理。それ書くのはコード書くより大変。
「プログラミング言語で仕様書け」そんなん無理。できたらコード完成してる。
「UMLで書け」モデルできても、本当にそれは仕様になってる?
「ドメイン固有言語」その世界用の言語を作って、それで仕様を書く。その世界用だから、自然言語とドメイン固有言語の翻訳は比較的容易なはず。
そして、GrailsではDSLを実装しやすいし、既存のDSLもいろいろある。
MissingMethod使って実装。なるほど。
DSLをうまく書けば、実装から仕様書作れるね。

保守:

実は、進化かバグ取り。

発注側のメリット:

  1. 早い時期に何ができつつあるのか分かる(scaffold)
  2. 自分たちの問題をDSLで記述できる(ロジカルに書ける)
  3. システムの進化(保守)がやりやすい
    • 少ないコード量(JavaEEの1/3〜1/5)
    • 明確な仕様の埋め込み(DSL)
    • テスト環境の充実
    • Java互換なので技術者はやや調達しやすい

テスト環境:

  • 単体テスト(JUnit)
  • 機能テスト(Canoo or Selenium)
  • 振る舞い駆動開発(BDD)
  • 継続的インテグレーション(Hudson)

労働集約産業から知識集約産業へ:

  • フレームワークは、単純労働を知的生産に変える
  • 「フレームワークを採用したら、生産性が半分に下がった。我が社の社員は、導入前には1日3,000行書いていたのに、フレームワークを導入したら1,000行しか書けなくなった!」
  • 再利用可能部分が大きくなるよね→会社の資産になる
  • 分業(バリバリコードを書く人、お客さんに聞きながらドメインを記述する人)がしやすくなるね
  • より上流に(社内で地位が上、より上流工程)に普及させないとメリットが出せない

■ 関連記事

詳細はこの日の詳細から

2010年07月12日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・ robots.txtに従わず、図書館HPにアクセス3万3千回 業務妨害容疑で男逮捕[http://www.nantoka.com/~kei/diary/?20100621S1][セキュリティ][プライバシー]次の記事 >> このエントリーをはてなブックマークに追加

岡崎図書館事件について その1[http://takagi-hiromitsu.jp/diary/20100710.html#p01] として、高木先生の日記で触れられている。
DoS等で業務妨害罪とされた過去の報道事例[http://takagi-hiromitsu.jp/diary/20100710.html#p02] がまとまっていて、今回のケースの 最初の報道[http://www.nantoka.com/~kei/diary/?20100526S2] で感じた違和感の正体が良く分かる。
最後に挙げられている、 山形の事件[http://yamagata-np.jp/news/200809/04/kj_2008090400060.php] については、同じ記事に行き当たって不思議に思っていたところ。
女は、短時間に大量のアクセス操作ができるコンピューターソフトを使ったとみられ、攻撃で同社のサーバーコンピューターは容量オーバーになり、機能が停止。復旧した後、女は再び攻撃を繰り返していた。調べに対し、容疑を認めているといい「HPの掲載内容に不満があった」などとする趣旨の供述をしているという。捜査当局は、刑事責任能力の有無について慎重に調べている。今年6月、県警生活環境課サイバー犯罪対策室に相談が寄せられた。
掲載内容への不満から掲示板への書き込みや、電話での苦情などのやり取りを経ているのではないかと想像したのだけれども、これが事実であれば、事前に、 HPの掲載内容に不満があって、 短時間に大量のアクセス操作ができるコンピューターソフトを使って、 攻撃をしていたということが、逮捕前に分かっていたという点が違うということになる。
刑事責任能力の有無について慎重に調べているという記述と、実名報道されていない点が、逆恨みというか、筋の通らない怨恨を伺わせるのだけれども、これはやや深読みしすぎかも知れない。
山形在住の方で、図書館等で当時の山形新聞にあたる等できる方がいないだろうか。

■ 関連記事

■2私が「iなんとか」を買わずにAndroidを買った3つの理由[Android][desire][携帯端末]<< 前の記事 このエントリーをはてなブックマークに追加

しばらく前に、 HTC DesireをGet[http://www.nantoka.com/~kei/diary/?20100604S1] したのだけど、その少し前までは、「最近流行だから、iPadなりiPhoneなりの携帯情報端末を持って、流行に追いつけるようにしないとなぁ」という程度のことを考えていた。
ただ、良く考えてみると、せっかく買ったからにはコードも書いてみたいし、より色々いじりたい。とすると、ソースが公開されている点。手持ちの環境でも開発できる点。マーケットの自由度が高い点。そういうところが魅力的に思えて、Androidに興味が湧いてきた。
だけれども、日本においてはまだまだiPhoneやiPadが主流で、周りにAndroid携帯を持っている人はいないばかりか、ソフトバンクショップに行っても「なんですかそれ」と言われる程度の認知度だ。
こんなものを買ってしまって良いのかと随分迷ったのだけど、いずれAndroidが主流になると信じてAndroidを選んだ。
理由は3つある。
1つ目。iなんとかを作るのは、Apple一社であり、Apple社の価格戦略、Apple社のデザインに乗った製品しか出荷されることはない。つまり多様な生態系は生まれえないということ。Androidは、安いのも高いのも、高級感のあるデザインもキッチュなデザインも各メーカーから多様性を持って供給されることになるに違いない。
2つ目。 山寨機[http://ja.wikipedia.org/wiki/%E5%B1%B1%E5%AF%A8%E6%89%8B%E6%A9%9F] メーカーの存在。偽物携帯ではなく、正真正銘本物のAndroid携帯を作り、そこに自由なカスタマイズを施して自社のオリジナル製品を作ることができる。彼らがこんな市場を放っておくだろうか。
3つ目。Appleによるコンテンツのコントロールの厳しさ。アプリやコンテンツを販売するのに、完成させた後に審査を受けなければならず、しかも発売後に取り消しを受けるなどというリスクを負いたくないアプリプロバイダやコンテンツプロバイダは多いはずだ。
といったところが、Android携帯を買ってしまった後ででっち上げた後付けの理由であるが、近い将来、「iなんとか携帯のガラパゴス化」という現象が必ず起こると私は確信している。 βのビデオデッキを、Digital8のムービーカムを、Hi-MDのプレーヤーを買った私が言うのだから間違いはない。

■ 関連記事

詳細はこの日の詳細から

2010年07月13日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1Sledgeを試してみる[WebApp][Perl][Sledge]次の記事 >> このエントリーをはてなブックマークに追加

ちょっとしたWebアプリを作ることにしたので、今日は Sledge[http://sl.edge.jp/] を試してみる予定。
前段階で、Portsをどこどことupdateして環境を整えるなど。

portupgrade大会:

しばらくさぼっていたので、大騒ぎしながらupgradeするなどした。

p5-Bundle-Sledge:

# portinstall p5-Bundle-Sledge
一発。すんごいお手軽。

mod_perl:

そうか。mod_perl2対応していないのか。うーん。いじれば動きそうだけど、後々が面倒になったらフレームワークに乗るお手軽さが半減するなぁ。

Catalyst:

にするかなぁ。ちょっと牛刀割鶏感があるんだよなぁ。

■ 関連記事

■2他のサイトのパスワードを聞き出すことを禁止できないものだろうか[セキュリティ][mashup]<< 前の記事 このエントリーをはてなブックマークに追加

「夢ふくらむプロジェクト事務局」なるところが、「株式会社 電通イーマーケティングワン」が登録したドメイン、YUME-FUKURAMU-PROJECT.JPを使って、 夢ふくらむプロジェクト[http://yume-fukuramu-project.jp/] という、Twitter連携企画をやっていることを知った。
夢ふくらむプロジェクトログイン画面
ユニクロのフィッシング詐欺風サイトに見る群集心理[http://www.nantoka.com/~kei/diary/?20100526S3] で書いたような嫌な予感がしたのだが、全くその通りで、Twitterの生のパスワードを入力させ、これをサーバに送信した上で、サーバ側がそのパスワードを使って、ユーザに成りかわって、Tweetを生成するという仕組みの様だ。
ユーザ名・パスワードの入力ユーザ名・パスワードの送信
ユニクロのフィッシング詐欺風サイトに見る群集心理[http://www.nantoka.com/~kei/diary/?20100526S3] でも書いたが、 この様なサービスが増えてしまうと、社会全体のフィッシング詐欺耐性が著しく低下する し、世の中 全てのサービスで全く関連の無いパスワードを設定している人ばかりでは無い から、Twitterのパスワードだけでなく、そこから検索で紐付くメールのパスワード、メールに保存していた各種通信販売サイト、クレジットカード、オンラインバンキング等のパスワードが芋づる的に知られてしまう人も出てくる恐れがある。
それだけ社会を危険にさらしてやるべきキャンペーンであるとはとても思えないし、百歩譲ってそれをやるならば、十分なリスクの説明も必要だろうし、結果に対して責任を負う覚悟も必要であろう。
例えばの話。デバッグ用に残っていたコードがあって、サーバのlogin-debug.txtファイルにユーザ名とパスワードの組が記録されていて、かつ、誰からも見える状態になっていたために、ユーザ名とパスワードが流出し、一部のユーザはそのパスワードを他のサービスにも使っていたため、メールが盗み読まれたり、オンラインストレージのプライベートな写真が流出したり、ネットショップで大量の買い物をされたりする様な被害が出た時に、その責任を負う覚悟があるだろうか。
一切の責任は負いません
そういう心配をすれば、とてもこういうサービスは作れないと思うのだが、責任を利用者に押し付けて、こういうサービスを作り出す人がやはりいるようだ。
それこそ、ガイドライン等で、他のサイトのパスワードを聞き出すことを禁止できないものだろうか。

7月15日追記[http://www.nantoka.com/~kei/diary/?20100715S1]:

素早く対応頂いたので追記した。

■ 関連記事

詳細はこの日の詳細から

2010年07月14日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・クロールとDoSの違いと業務妨害罪と[http://www.nantoka.com/~kei/diary/?20100624S1][電子自治体][DoS][セキュリティ] このエントリーをはてなブックマークに追加

6月24日の日記[http://www.nantoka.com/~kei/diary/20100624.html] に追記。
日記の最後の方で、
確認した限りでは、岡崎市立図書館だけが、 件の謎の挙動[http://www.nantoka.com/~kei/diary/?20100621S1#T201006211S1] を示すようだ。
と書いたのだが、他の図書館でも、一度タイムアウトすると、同じCookieを持ってアクセスすると応答がなくなるという同様の現象が発生するところが見つかった。
気づいたのはたまたまだったのだが、 岡崎市立図書館と同じ、MELILを採用している図書館のリストが、 日本のソフト別OPACリスト[http://www.asahi-net.or.jp/~gb4k-ktr/indexjv.htm#melil] にあり、この中で検索ページが.aspになっているものでは同じ現象が発生する様で、発生条件もかなり緩く、
  1. 検索などでのタイムアウト発生
  2. 応答が遅かった場合のキャンセル
  3. 検索結果ページを閲覧していて、画面内の戻るボタン以外でページ遷移を行った場合
に、以降の応答がなくなるという症状が発生する様だ。
検索ページが.aspxになっているものでは、確認した範囲では発生を見ていないので、これは後に改修されたのだろう。
Cookieを削除してやればアクセスできるようになるから、1回程度確認しただけで即座にサーバが停止するということは無いことは確認したが、後述するように私は、 多数回にわたって繰り返せば、何らかの不具合が顕在化してサーバ停止につながるバグを抱えているのではないか と推測しているので、その推測を持っていながら繰り返すことは、それこそDoSとみなされる危険があるので、最低限の回数しか確認はしていない。
この挙動については、 岡崎市立図書館蔵書検索システムの謎[http://www.nantoka.com/~kei/diary/?20100621S1#T201006211S1] で書いたが、なぜこうなったかを、クライアント側でのtcpdumpでの観測からやや大胆に推察すれば、
  1. 「1クライアントからのリクエストを、同時に1つに制限する」というリクワイアメントがあって、Cookieでセッション管理をすることにした。
  2. 各ASP処理の最初で、Cookieに対して他のASP処理が「実行中」かどうかを調べる。「実行中」だったら、「実行終了」まで待つ。
  3. 実行中でなければ、そのCookieに対して「実行中」として処理を行う。
  4. 処理を完了したら、「実行終了」とする。
の様な構造になっていて、タイムアウトやクライアントからの切断等のエラーが発生したときに、エラー処理に何らかの不手際があって、4.の「実行終了」ができていないのでは無いかと推察される。 こうなると、2.が無限か恐らく相当に長いタイムアウトまで待ちに入ってしまう。
この作りは明らかにまずいし、そもそも最初のリクワイアメントが、単に負荷を考えたものならば分かるけれども、 全体が「同時に複数やられると困ったことになる」作りになっているために、それを防ぐためにこのリクワイアメントが出てきたのだとしたら、全体が相当にまずい *1 。 そうだとすると、 Cookieを食わないでアクセスしただけで、困ったことになる からだ *2 。 たいていのクローラはCookieを食わないから、つまりこれは、クロールされただけで困ったことになるということを意味している *3
インターネットに公開することを考えて作られたシステムであれば、最初からこんな設計にはしなかっただろうし *4つぶやいた[http://twitter.com/keikuma/status/16781256147] 様に、 汎用機端末→VB,Accessクラサバ→Webイントラと、実現手段が代替わりする間に、上位設計のやり直しをしないで来て、さらにこれを同じWebだと思ってインターネットにつないでしまったシステム という感じが激しくする。
だとすると、他のMELILを採用している図書館でも、定期的にダウンしたり、館内の検索端末から検索がしばらくできなくなったりという不具合が出ているのではないか。
もし、そうだとすれば、システムの欠陥をたまたま露呈させてしまったからと言って、逮捕される人が出るのは本当に気の毒であるし、そもそも逮捕者が出るのは許されることではない。

netcraftのuptime[http://uptime.netcraft.com/up/graph?mode_u=on&site=www.library.okazaki.aichi.jp&mode_w=off&avg_days=360&submit=Redisplay+Graph]:

netcraftによるuptimeグラフ
Netcraft[http://news.netcraft.com/] というところが、様々なサイトの連続稼働時間の調査を行っている。 定期的にサイトにアクセスをして、前回の起動からの日数 *5 をグラフ化しており、どの程度安定的にサーバが稼働しているのかを知る手がかりにすることができる。
Libra[http://www.libra.okazaki.aichi.jp/] のサーバもその調査対象にたまたま入っている。
残念ながら、今年の5月ごろからしか調査データが無いが、27回ほど計測して、その全てが「0日」という結果になっている。
この調査を信じればだが、そもそも毎日、再起動を行う運用になっているのかも知れない。

Cookieを食わないブラウザ:

世の中にはCookieを食わないブラウザもあるし、やたらとCookieは食べないことにしている人もいるのだけれども、そういう状況でアクセスするとどういう表示がされるのか確認してみた。
結果。何の表示も警告もなく使える。但し、例えば検索結果の一覧から詳細に移動して戻った時等に、検索結果を忘れてしまうという現象が発生する。パラメータを引き渡す術がないのだから挙動は理解できる。
ところが、例えば新着図書一覧等のリンクを辿った時に、 Cookieを食べない様にしていると、結果が表示されるのが遅い ことに気付いた。実測してみると、確かに100msec程余計に時間が掛かっていた。
Cookieを食べるようにした場合、初回の要求はCookieを食べない時と同じで、2回目以降は100msec程度短縮されることになる。
これを素直に解釈すれば、 セッション開始時にDB接続を行って、ページを移動してもそのセッションに紐付いたDB接続を使いまわしている ということだろう。100msecは新たなDB接続に掛かる時間だ *6
だとすると、 Cookieを食わずにアクセスするのは非常にまずい 。 毎回、新たなDB接続が行われて、使い終わったDB接続は、そのままタイムアウトまで解放されないことになることが予想されるからだ。
それでも、エラー処理が完全であれば、順次、セッションがタイムアウトしていって、いずれは定常状態に戻るはずだが、エラー処理に漏れがあって、途中まで構築したオブジェクトを破棄せずに終了してしまうといった何らかの問題があって、二次災害を引き起こすのかも知れない。
従って、 ASP版のMELILにアクセスする場合は、Cookieを受け付ける設定にしておかないとサーバ停止を招きかねない *7 。注意が必要だ。

念力デバッグ:

「念力デバッグ」という仕事があって、ごく稀にお仕事を頂く。
念力デバッグというのは、安楽椅子探偵に似たようなデバッグで、デバッガやデバッグ用のコードを使わずに、直観と論理に基づく推理だけでバグを探すデバッグだ。
通常のデバッグでは、デバッガを用いたり、デバッグ用のコードを走らせたりできるので、念力デバッグの出番はあまりないのだが、既に仕様書やソースコードが存在しなかったり、実機に触れることができなかったり、その全てがなくて、バグレポートだけでバグ解析して運用回避手段を見つける必要があったりという状況があって、そういう場合に、念力デバッグの登場となる様だ。
念力デバッグの結果は、材料が少ないときは特に占いめいていて、「午前2時に、おにぎりを大量に買ってみて下さい。日配品の集計モジュールを書いた人が、コードを書いた当時に経験が浅かったとしたら、集計タイミングに売上が発生する可能性を考慮しておらず、一貫性が保てなくなった可能性があります。推理が正しければ、件の現象が再現すると思われます。」といったレポートを書いて、推理が当たれば一件落着となる訳だ。
閑話休題。今回のケースを念力デバッグしてみると、
  • DB接続をCookieに基づくセッションによって管理する作りになっている。
  • Cookieを食わないクライアントからリクエストを受けると、リクエスト毎にDB接続が生成される。
  • DB接続を含めたサーバリソースは、タイムアウトによってセッションが破棄されるまで解放されず、確保されたままになる。
  • DB接続に必要なサーバリソース(DB接続の上限あるいはコネクションプールと思われる)が不足した状態でリクエストを受け付けると、リソース確保時にエラーが発生するが、このエラー処理が不完全なため、途中まで構築されたオブジェクト等の何らかの別のリソースの解放処理が行われない。
  • このため、エラーが発生している状況でさらにアクセスを行おうとすると、エラー処理の漏れによって、タイムアウトで解放されない形でサーバリソースが枯渇して、ASPの停止に至る。
ということだと思われる。
確認は容易だが、万が一、真似する人が出て「教唆だ」等と言われるとたまらないので、あえて書かない。しかし、その方法は、一般的なクローラの挙動そのものだ。
しかも、この推理が当たっていれば、DB接続の上限に達するまでは、ほとんどサーバの応答時間は変わらないであろうし、エラーが発生したとしても、順次タイムアウトで解放されていくリソースがあるために、散発的にしかエラーが観測されないということが起こり得る。まさに、最後の一アクセスがサーバダウンの引き金を引くロシアンルーレットだ。しかも、停止するのがASPサービスだけだったとしたら、こういう内部事情に気づけと言うのは、それこそ 魔法を要求している[http://twitter.com/rocaz/status/18508517455] に等しい。ネットは魔法使いの世界ではないはずだ。
まだこの結論を信じられない自分がいるのだが、もし本当に、 こんなバグを抱えているのだとしたら、これはもはや、インターネットにはつないではいけないレベルの製品だと言わざるを得ないだろう。
ASP版のMELILを導入していて、実証のためにサーバが停止する可能性があるアクセスを許容してくださる図書館の関係者の方がいらっしゃれば、日時等の実験条件は当然、指定に従うので、ぜひ連絡を頂けないだろうか。

7月23日追記[http://www.nantoka.com/~kei/diary/?20100722S1]:

その後の情報で、「念力デバッグ」の推察をアップデートした。
シリーズ・クロールとDoSの違いと業務妨害罪と(5) - その後の念力デバッグ[http://www.nantoka.com/~kei/diary/?20100722S1] を参照頂きたい。
*1: 例えば、ページを開くたびにDBに接続しに行っていては遅いから、ADOオブジェクトをSessionオブジェクトとして保持しているとか。
*2: 例えば、接続毎にADOオブジェクトを新規に作って、破棄の方はSession_OnEndに任せていたりすると、タイムアウト(デフォルトでは20分)まで、DBセッションが解放されないことになる。
*3: robots.txtが激しいのは、これを問題だと認識していたからだろうか。
*4: 館内検索端末など、台数と操作が限定された端末のみあれば、「例えば」と書いた実装でも、問題が表面化することなく動作するケースが多いだろう。
*5: 恐らくTCPのシーケンス番号を用いているのだと思われる。
*6: 素直でない解釈としては、Cookie食べることを控えめに要求するために、100msecのペナルティを与えているとか?
*7: 当然、この記事を読んで、「試しにCookie無しでアクセスしてみよう」というのは慎んで頂きたい。

■ 関連記事

詳細はこの日の詳細から

2010年07月15日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・他のサイトのパスワードを聞き出すことを禁止できないものだろうか[http://www.nantoka.com/~kei/diary/?20100713S2][セキュリティ][mashup]次の記事 >> このエントリーをはてなブックマークに追加

旧ログイン画面新ログイン画面
「さすが電通」と言っても良いだろう。件のサイトの仕様が変更されており、Twitterのホームから直接、書き込む形式になっていた。
当然、パスワードを第三者サイトで入力する必要はないし、このサービスの場合、その場限りの書き込みだから、OAuthよりも好ましいだろう。
この変更によって、第三者サイトでパスワードを入れるのに抵抗があった人も、このサービスが利用できるようになったことだろう。
この方法が、Twitterとハッシュタグを連携したキャンペーンを実装する際のデファクトスタンダードになることを期待する。

■ 関連記事

■2 シリーズ・クロールとDoSの違いと業務妨害罪と(3)[http://www.nantoka.com/~kei/diary/?20100714S1][電子自治体][DoS][mashup][セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

タイトルを付け直そうかと思ったが、まだ続くかも知れないのでシリーズ化することにした。
初出の時に
サーバ側から観測した時に、相手が行っているのが過剰なクロールか、あるいはDoSなのかは、Webサーバのログでも大体見当は付く
と書いたが、この点を改めて強調しておきたい。

レガシー世界とインターネット:

インターネットでは、専用線接続やクラサバとは根本的に異なり、ネットの向こうには何があるのか分からないというのがスタートラインだ。これは、インターネット全盛の今にあっては当たり前のことだが、レガシー世界からすると、クライアントが何かも分からないというのは確かに別世界だ。
レガシー世界のサーバとクライアントは一対のものとして実装され、お互いの挙動を把握しながら動いていた。
ところが、インターネットの世界では、 RFC[http://ja.wikipedia.org/wiki/Request_for_Comments] で提案されたプロトコルを拠り所に、サーバとクライアントがばらばらに実装される。
プロトコルが決められていると言っても、 全銀協手順[http://ja.wikipedia.org/wiki/%E5%85%A8%E9%8A%80%E5%8D%94%E6%A8%99%E6%BA%96%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB] とか、ISO 8583とか、 CAFIS *1 の様な厳密さは無いし、ましてや接続のための認定等もない。
それでも動いているのは、サーバ - クライアント共に、なるべく広い相手と話せるように努力した結果だし、話せなければそれでも良いという割り切りの結果でもあるだろう。
これだけ別世界だと、レガシー世界の方から、 サービス提供側が意図しない使い方をして被害が生じれば罪になる[http://twitter.com/hatsanhat/status/18574777672] とか、 提供側が意図しない使い方を戒めて欲しい[http://twitter.com/hatsanhat/status/18575234658] といった、インターネット以降の常識からすると、首を傾げるような意見が出てくるのだが、これは、まさに世界観の違いによるものなので仕方がない。
今回の事件が、図書館に置いてある検索端末を意図しない使い方 *2 をして、検索端末が使えなくなったとか、システムが使えなくなったという話であれば、まだレガシー世界の話かも知れないが、 今回はインターネットで起きた話なので、インターネット以降の常識をベースに話を進めたい。レガシー世界の方は、別世界の話にしばしお付き合い頂きたい。

サーバが落ちるということ:

サーバにどれだけの能力が要求されるかについては、キャパシティプランニングとして、今も昔も上流工程で検討される事項の一つであろう。
レガシー世界では、キャパシティは絶対のスペックであって、それを超えるとシステムが動作しないというのは、望ましくは無いけれども仕方がない事だった *3 。 万が一、キャパシティをオーバーする可能性が生じたら、利用者に協力してもらって、運用で回避をするしかなかった *4
インターネットでは、何しろサービスの利用者はネットの向こうにいるのだから、いつ、どれだけアクセスが来るかは分からない。アクセスが集中して困ったとしても、アクセスをやめてもらう方法も無い。
処理できないほどのアクセスが来たらどうするか。 答えは簡単で、 処理できるようになるまで待ってもらうか、返事をしないか、余裕があればエラーだけ返すかだ *5 。 インターネットでは、できないときはできる範囲でやるというポリシーによって、リソースを有効活用しており、このポリシーがあるからこそ、高速なインターネット接続を、専用線とは比べ物にならないほどの低価格で利用できている。
もしも、年に一度あるかどうかのアクセス集中時にも遅延なくインターネットが使えなければならないとしたら、月額数十万円払って128Kbpsという世界で、多くの人の手元にインターネットは届いていないに違いない。 できないことはできる範囲でやる、ベストエフォートというポリシーがネットの低価格化と普及を実現し、今日のインターネットの隆盛がある。
サーバについても同様だ。 インターネットに対してサービスを提供する以上、処理能力を超えたアクセスの集中は必ず起こるとして、処理できないアクセスが来たら、待ってもらうか、返事をしないか、エラーを返し続けて、アクセスの集中が去れば定常状態に回復するというのが、インターネットに接続されるサーバとしての要件だ。
遅くなっても、返事をしなくなっても、それは処理能力の一時的な低下であり、それは「落ちた」とは言わない。一方、アクセス集中という原因が取り除かれても、なお復旧しない様な障害が発生した時に「サーバが落ちた」と言う。
今回のケースについては、報道等を通じて見る限りでは「サーバが落ちた」と言うのは事実のようだが、これまで述べたように、 アクセス集中によってサーバが落ちるのは、インターネットに向けてサービスを提供するサーバとしての要件を欠いている と言わざるを得ない。

ブラウザとクローラとヒトとロボットとネコ:

「Webサービスとは何か」と突き詰めて行くと、究極的には「HTTPサービスです」ということになる。「Webサーバ=HTTPサーバ」と言い直せるくらいだ。
HTTPサービスを利用するためのプログラムは、「HTTPクライアント」で、ブラウザもクローラも、HTTPクライアントであるという点に違いは無い。
当然、HTTPサービスを提供する側から見ても、HTTPクライアントである点に違いは無い。
一方、HTTPクライアントを使って、サービスを受けているのが、ヒトかロボットかネコかということも、HTTPサービスを提供からする側から見れば、みな「HTTPサービス」を受けているという点で等価だ。なおこのネコは後に重要な役目を帯びて再登場する。
サーバが提供するのは「HTTPサービス」であって、「IEサービス」でも「FireFoxサービス」でも無い。HTTPサービスを提供するということは、HTTPクライアント向けのサービスを提供するということであって、その中には、行儀が良いのも悪いのも *6 、実装にバグがあるものも、標準と違う動きをするものもあるけれど、そういう多様なクライアントからアクセスされるのが、インターネット上のサーバだ。
もちろん、一つ一つのクライアントに合わせてサーバを実装するわけではないし、そんなことができるはずもない *7 。サーバは、ただHTTPサービスを提供すれば良い。
この様に、通信プロトコルとユーザーインターフェイス等の表現を分離したところも、Webが広く普及した理由の一つであると考えられるが、とにかく、ここで理解して頂きたいのは、 Webサーバ(=HTTPサーバ)は、HTTPサービスを提供するサーバである ということに尽きる。
従って、 Webサービス(=HTTPサービス)を提供することは、HTTPサービスを提供すること になる。
そもそも「HTTPサービス」を提供しているのだから、HTTPクライアントからアクセスされることが想定されていて、 同じHTTPクライアントである、ブラウザとクローラを分けて考えることには無理がある。 この問題には、ヒトとロボットを判断する際にも直面して、その技術的な解決の一つとして CAPTCHA[http://ja.wikipedia.org/wiki/CAPTCHA] が使われているが、これも前述したように、ブラウザとクローラを判断するのが難しいからこそ利用されている技術である。

アクセスとアタックと:

原点に帰ろう。「ブラウザかクローラか」は、実はどうでも良い問題で、 焦点は「アクセスかアタックか」だったはずだ。
アクセスなのかアタックなのかはサーバ側で見当が付く[http://www.nantoka.com/~kei/diary/?20100624S1] という趣旨のことを書いたが、ここをもう少し詳しく書いてみたい。
パターンとしては、大まかに次のパターンが考えられる。
  1. ブラウザによる通常のアクセス
  2. クローラによる目立たないアクセス
  3. ブラウザによる過激なアクセス(だが、DoSではない)
  4. クローラによる過激なアクセス(だが、DoSではない)
  5. ブラウザによるDoSを意図したアクセス
  6. クローラによるDoSを意図したアクセス
1,2の中には、「怨念を込めて密かに1日1回アクセスを繰り返すことによって、サーバの負荷を上げてやろう」というものが混じっているかも知れないが、実害は生じないので無視することにして良いだろう。そもそも、霊感が無ければログから怨念を感じ取ることは不可能なので、気づかないケースがほとんどだろう *8
実際に問題になるのは、3,4と5,6を分離することだろう。 どこに違いが生じるかと言えば、 リクエストしたデータを利用しているかどうか だ。
例えば、常識的に更新頻度が高いことが想定されない同じページを、ノーウェイトで取得していれば、これは怪しいと見ていいだろう *9
クローラの場合、リクエストしてくるURLが異なると判別が難しいかも知れないが、クライアントまでのRTT *10 を得て、ローカルで同じページをアクセスした時に掛かる時間と足せば、クライアントからWebページを取得したときの大まかなRTTが分かる。これより長い間隔でのアクセスであれば、迷惑ではあるかも知れないが、恐らく意図はクロールだと判断できる。
今回のケースは恐らくこのパターンだったはずで、この程度の検証もしないで攻撃だと判断したのも、それを鵜呑みにして逮捕したのもあまりにも杜撰だ。
一方、これより短い間隔でアクセスしてくるとしたら、複数プロセスあるいはスレッドを使っているか、バグっているか、アタックしようとしているかだろう。サーバの応答時間を長くして、リクエスト数が変わらない様だったら、怪しいと見て良いだろう。
怪しいケースについては、あくまで「怪しい」であって、これが直ちにアタックの証拠になるものでは無い。バグによるものだったかも知れないし、「ブラウザでF5アタック」と思ったら、キーボードの上にネコが寝ていただけかも知れない。
IPアドレスやUserAgentで弾くことができないような形で続く様だったら、アタックと見なすことになるかも知れない。
なお、専用の攻撃ツールを使うと、効率的にアタックできる分、アタックとしか考えられない挙動を示すので、この場合は一回でアタックだと判断できるだろう。
*1: (7月24日)PIAFSとtypoしていたのを修正。
*2: 勝手にプログラムをインストールしたとか、設定を変えたとか。
*3: 例えば、夜間バッチ処理は、翌朝の業務開始までには絶対に完了していなければいけないだろう。
*4: 極端な例を取り上げております。
*5: HTTP Error 500のInternal Server Errorだが、文字通り、内部で何らかのエラー(リソースの不足、あるはずのファイルが見つからない、内部矛盾)を検出して、詳細は伝えない(攻撃に悪用される恐れがあるから、クライアントにはあえて詳細な原因を通知しないことが多い。)ながら、エラーが発生したという事実を正しく応答している。あくまで、クライアントに向けて、期待した応答が返せない理由として通知する「エラーコード」であって、サーバの管理者に対してのエラーでは無い。致命的な障害をクライアントに通知したからと言って、クライアントにはサーバを救う手だては無い。
*6: クローラが行儀が悪い訳ではない。ブラウザが行儀が良い訳でもない。無関係に、行儀が良いのも悪いのも存在する。
*7: 細かく言えば、ブラウザ向けに最適化することはあるが、本筋ではないので割愛。
*8: 不能犯になりそうでもあるし。
*9: 一方、ある時刻に予約の受付開始を行うようなサイトでは、リロードを繰り返すのは、当然、想定される操作だろう。
*10: 目安であるから、tracerouteして、クライアントよりいくつか手前でも構わない。

■ 関連記事

詳細はこの日の詳細から

2010年07月16日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 レガシー脳の恐怖[http://www.nantoka.com/~kei/diary/?20100715S2] このエントリーをはてなブックマークに追加

昨日の日記[http://www.nantoka.com/~kei/diary/?20100715S2] を書いていて、レガシーモデルの置き換えでWebシステムを捉えている人を揶揄するような流れになってしまった *1 。後悔はしていない。
レガシーのC/Sモデルでインターネットを理解して、この問題を議論したりするのは弊害 が大きいし、その他、インターネットが絡む全てを正しく理解できないのだから、この際、新しいモデルを理解しておくべきだ。
新しく出てくる様々な技術を、レガシーなモデルになぞらえて納得するのは、表層的な受け入れは早いかも知れないが、 根本的な部分の理解を抜きになぞらえるのは、 レガシーマイグレーション[http://ja.wikipedia.org/wiki/%E3%83%AC%E3%82%AC%E3%82%B7%E3%83%BC%E3%83%9E%E3%82%A4%E3%82%B0%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3] と同じで様々な問題を後に残しやすい。
しかも、それを繰り返すうちに、脳がレガシー化していく。新しい考え方を受け入れることがさらに難しくなり、例えに無理が出てきて、しかもそれに気づかないようになってしまうのだ。
「クラウドって、あれでしょ。VANでしょ。」とか言い出す前に、思考をオープン化しよう。

■ 関連記事

詳細はこの日の詳細から

2010年07月18日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ・クロールとDoSの違いと業務妨害罪と(4)[http://www.nantoka.com/~kei/diary/?20100715S2][電子自治体][DoS][mashup][セキュリティ][LibraHack] このエントリーをはてなブックマークに追加

情報ネットワーク法学会 - 第1回「技術屋と法律屋の座談会」[http://in-law.jp/bn/2010/20100716.html] 関連のTweetで、事実関係が新たにいくつか明らかになった様なので、メモしておく。
まず、 貸出業務等に目に見えた支障はなかった[http://twitter.com/tetsutalow/status/18800959731] ということが判明した。
一部には、 館内業務が止まるほどの被害が出たのだから、警察は逮捕して当然[http://twilog.org/Sikushima/date-100628] という見方をする人もあって、システムの構成から *1 考えれば、いくらなんでも館内業務に影響は出ないだろうと思って、何を根拠にこういう主張をしているのかと訝っていた。
館内の業務に影響がなかったのであれば、同氏も、
岡崎図書館は館内業務も止まっていた前提で書いています。 館内業務が止まってないのに逮捕はやり過ぎです。
と書いている様に、「逮捕はやり過ぎ」という感覚を理解いただけたのではないかと思う。
また、図書館側の対応が、時系列でもう少し明らかになっている。
以下、要約する。
  1. (3月中旬)新着図書ページがある時間になると閲覧不能になるという苦情があり、調査したところ、実際に閲覧不能になっていた。 [http://twitter.com/tetsutalow/status/18796534863]
  2. この時点での図書館の認識は「何か普通でないことを機械的にされている(ので困る)」という認識。 [http://twitter.com/tetsutalow/status/18796741940]
  3. アクセスはURL決め打ちだったので、URLの一部を動的に変化させる様にした。 [http://twitter.com/tetsutalow/status/18796741940]
  4. 動的に変化といっても1文字変化する文字をURLに加えるだけだったので簡単に対応された。 [http://twitter.com/tetsutalow/status/18796927113]
  5. IPアドレス遮断をこの時点で考え始めた模様である。 [http://twitter.com/tetsutalow/status/18796927113]
  6. 「このアクセスを行っている人物はこの図書館の利用者か」を調べるために、IPの逆引き結果からISPを調べ、そのドメインを持つメールアドレスがLibraの登録者DBにあるか探した。 [http://twitter.com/tetsutalow/status/18797135716]
  7. 警察に簡単な相談 [http://twitter.com/tetsutalow/status/18797578659]
  8. (3月末)当時はレンタルサーバを使用していたため、前述の方法で図書館の利用者ではないと判断し、IPをブロックした。 [http://twitter.com/tetsutalow/status/18797289839]
  9. (4月上旬)違うアドレスから同様のアクセスが来たため、同様にアドレスからドメインを調査したところ、Libraにも多くユーザがいるドメインだったため、遮断は容易にできなかった。 [http://twitter.com/tetsutalow/status/18797826472]
  10. 警察に任意でアクセスログを提出して相談 [http://twitter.com/tetsutalow/status/18798035052]
  11. (4月中旬〜下旬)警察が事件として捜査できると判断したので、被害届を提出。 [http://twitter.com/tetsutalow/status/18798239953]
6.は、9.と考え合わせると、「このアクセスを行っている人物はこの図書館の利用者か」というよりも、「このIPアドレスを遮断すると図書館の利用者に影響が出るか」という確認だったと思われるが、いずれにせよ、今日においては、IPアドレスとメールアドレスの紐付きを期待するは無理があるので、中途半端な確認だったと感じる。
10.については、 6月22日に電話を掛けて確認したこと[http://www.nantoka.com/~kei/diary/?20100622S1] と食い違うように感じる。ひょっとすると、ログの抽出から提出まで、図書館側はノータッチだったという可能性もあるが、それはそれで、利用者のプライバシーに密接に結び付くものを、そこまで業者任せにして良いのかという疑問が残る。
*1: 対外系のWebサーバと、館内業務向けのWebあるいはアプリケーションサーバを兼用する構成にはさすがにしないはず。

■ 関連記事

詳細はこの日の詳細から

2010年07月19日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1 Androidが中国で大躍進する理由―影響は世界に及ぶ[http://jp.techcrunch.com/archives/20100718android-china/][Android][desire][携帯端末] このエントリーをはてなブックマークに追加

先日、 私が「iなんとか」を買わずにAndroidを買った3つの理由[http://www.nantoka.com/~kei/diary/?20100712S2] で書いた、山寨機メーカーの話。彼らが、偽Windowsモバイルや、偽iPhoneではなく、本物のAndroid端末を作る様になったら、相当の競争力を持つことになるに違いない。
そういった、高性能で低価格な端末が、SIMフリー化された国内市場にも入って来るようになった時、ガラパゴス生態系はどうなるのだろうか。

■ 関連記事

詳細はこの日の詳細から

2010年07月21日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1ASP版MELIL/CS導入図書館リスト[電子自治体][DoS][mashup][セキュリティ][LibraHack] このエントリーをはてなブックマークに追加

日本のソフト別OPACリスト[http://www.asahi-net.or.jp/~gb4k-ktr/indexjv.htm#melil] を基にして、ASP版のMELIL/CSを稼働させていると思われる図書館と、検索ページをリストアップした。
ASP版のMELIL/CS導入図書館リスト(2010.7.20)
図書館名検索ページ検索ASPファイル名jfSubmitのタイプ
新冠郡新冠町図書プラザhttp://www.record-unet.ocn.ne.jp/book/toshow/Asp/kensaku_w.aspkensaku_w.aspなし
中野区立図書館http://www3.city.tokyo-nakano.lg.jp/tosho/asp/xkensaku_w.aspxkensaku_w.aspA
足柄下郡真鶴町まなづる図書館https://www2.manazuruinfo.jp/asp/kensaku_w.aspkensaku_w.aspB
小田原市立図書館https://www.opac.city.odawara.kanagawa.jp/a_top/asp/kensaku_w.aspkensaku_w.aspA'
茅ヶ崎市立図書館https://www.lib.chigasaki.kanagawa.jp/asp/kensaku_w.aspkensaku_w.aspA'
加賀市立図書館http://www.kagalib.jp/toshow/asp/kensaku_w.aspkensaku_w.aspA'
岡崎市立図書館http://www.library.okazaki.aichi.jp/tosho/asp/kensaku_g.aspkensaku_g.aspA'
瑞浪市民図書館http://library.city.mizunami.gifu.jp/tosho/Asp/kensaku_w.aspkensaku_w.aspA'
可児市立図書館http://www.tosyokan.kani.gifu.jp/tosho/Asp/kensaku_w.aspkensaku_w.aspA'
八幡市民図書館http://www3.city.yawata.kyoto.jp/toshow/asp/kensaku_w.aspkensaku_w.aspB
長岡京市立図書館https://www.lib.city.nagaokakyo.kyoto.jp/tosho/Asp/kensaku_w.aspkensaku_w.aspB
北葛城郡広陵町立図書館https://www.library.koryo.nara.jp/toshow/asp/kensaku_w.aspkensaku_w.aspA'
大和郡山市立図書館https://www.yamatokoriyama-library.jp/toshow/asp/kensaku_w.aspkensaku_w.aspA'
貝塚市民図書館http://www.city.kaizuka.osaka.jp/tosho/Asp/kensaku_w.aspkensaku_w.aspB
摂津市民図書館http://www.library-settsu-osaka.jp/toshow/asp/kensaku.aspkensaku.aspA'
尼崎市立図書館http://www.amagasaki-library.jp/tosho/asp/kensaku_w.aspkensaku_w.aspB
府中市立図書館http://www-lib.city.fuchu.hiroshima.jp/toshow/asp/kensaku_w.aspkensaku_w.aspC
観音寺市立図書館http://www3.city.kanonji.kagawa.jp/library/Asp/kensaku_w.aspkensaku_w.aspB
大宰府市民図書館http://www.library.dazaifu.fukuoka.jp/Asp/kensaku_w.aspkensaku_w.aspB
三養基郡上峰町図書館http://lib.town.kamimine.saga.jp/asp/kensaku_w.aspkensaku_w.aspB
武雄市図書館・歴史資料館https://www.epochal.city.takeo.lg.jp/ASP/kensaku_w.aspkensaku_w.aspB
松浦市立図書館http://www.city.matsuura.nagasaki.jp/search/kensaku_w.aspkensaku_w.aspB
「jfSubmitのタイプ」は、「2重実行防止」とされたJavaScriptのコードで、この部分が図書館ごとに微妙に異なっている。
タイプA
//2重実行防止
function jfSubmit() {
  if(document.frmKensaku.hidKensakuF.value == ""0""){
    document.frmKensaku.hidKensakuF.value = ""1"";
    return true;
  }else{
   return true;
} }
タイプB
//2重実行防止
function jfSubmit() {
  if(document.frmKensaku.hidKensakuF.value == ""0""){
    document.frmKensaku.hidKensakuF.value = ""1"";
    return true;
  }else{
   return false;
} }
タイプA'
//2重実行防止
function jfSubmit() {
  if(document.frmKensaku.hidKensakuF.value == ""0""){
   //alert(document.frmKensaku.hidKensakuF.value);
document.frmKensaku.hidKensakuF.value = ""1""; return true; }else{ return true;
} }
タイプC
//2重実行防止
function jfSubmit() {
//alert(document.frmKensaku.hidKensakuF.value);
// if(document.frmKensaku.hidKensakuF.value == ""0""){
//  document.frmKensaku.hidKensakuF.value = ""1"";
//  return true;
// }else{
//  return true;
// }
//
  if(document.frmKensaku.hidKensakuF.value == ""0""){
    document.frmKensaku.hidKensakuF.value = ""1"";
    return true;
  }else{
    if(document.frmKensaku.hidKensakuF.value == ""1""){
      document.frmKensaku.hidKensakuF.value = ""1"";
      return true;
    }else{
      return true;
    }    
  }
}
このコードが何を目的にしていて、どの様に改変されていったのか。 ソフトウェア考古学者の出番だ。

■ 関連記事

詳細はこの日の詳細から

2010年07月22日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ・クロールとDoSの違いと業務妨害罪と(5) - その後の念力デバッグ[http://www.nantoka.com/~kei/diary/?20100714S1#T201007141S3][電子自治体][DoS][mashup][セキュリティ][LibraHack] このエントリーをはてなブックマークに追加

多くの方の尽力によって、少しずつ色々な情報が明らかになって、当て推量で「ではないか」と書いていた部分を外せそうなところも出てきたし、逆に、これは間違っていたという部分も出てきた。
最近では、一部では語感が好評だった 念力デバッグ[http://www.nantoka.com/~kei/diary/?20100714S1#T201007141S3] のデバッグから。
情報が少ないからこそ、一次情報は貴重で、より正しいと思われる情報を集めるところから始めるのが、念力デバッグの鉄則なのに、その部分で手を抜いた罰が当たった。
  • DB接続をCookieに基づくセッションによって管理する作りになっている。
  • Cookieを食わないクライアントからリクエストを受けると、リクエスト毎にDB接続が生成される。
  • DB接続を含めたサーバリソースは、タイムアウトによってセッションが破棄されるまで解放されず、確保されたままになる。
  • DB接続に必要なサーバリソース(DB接続の上限あるいはコネクションプールと思われる)が不足した状態でリクエストを受け付けると、リソース確保時にエラーが発生するが、このエラー処理が不完全なため、途中まで構築されたオブジェクト等の何らかの別のリソースの解放処理が行われない。
  • このため、エラーが発生している状況でさらにアクセスを行おうとすると、エラー処理の漏れによって、タイムアウトで解放されない形でサーバリソースが枯渇して、ASPの停止に至る。
と、推理していたのだが、マーカーを掛けた後ろの2つは、どうも余計な推量だった様だ。
当時、この様に推理したのは、 各社新聞記事の比較[http://librahack.jp/okazaki-library-case/mass-communication-report.html] の、
  • 計8回機能を停止させ、図書館の業務を妨害したとされる。
  • アクセスできない状態が生じるたびにコンピューターを遮断し回復処置をとったという。
  • サーバーを21回シャットダウンさせた疑いがある。
という内容から、 一度「アクセスできない状態」に陥ると、再起動を実施するまで回復しない。 という予断を持っていて、 まさか、しばらくたてば回復するのを再起動しておいて、被害届も無いだろう と考えて、時間が経っても解決しない障害だったという線で推理を進めた訳だ。
ところが、この件について、高木先生から 利用者から電話で苦情が来て対応しているのだから、すぐに再起動していた[http://twitter.com/HiromitsuTakagi/status/19055260081] という情報を頂いた。
従って、後ろ2項目は、余計なメカニズムだったことになる。
真実は、
  • DB接続を含めたサーバリソースは、タイムアウトによってセッションが破棄されるまで解放されず、確保されたままになる。
  • セッションタイムアウトを待てずに、図書館職員が再起動を行う。
という、よりシンプルなものだった様だ。
考えてみれば、この2つの項目自体、いかにも オッカムの剃刀[http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%83%E3%82%AB%E3%83%A0%E3%81%AE%E5%89%83%E5%88%80] によってそぎ落とされそうな感じではあった。

念力ではなくてハンドパワーです[http://gutei-blog.blogspot.com/2010/07/blog-httplibrahack.html]:

念力よりも実際に手を動かす方がえらくて、コードを書いた人がえらくて、井戸を掘った人がえらいのです。
というわけで、入手できている情報で推察できる環境を構築して、多分こうだっただろうという(問題がある)実装を入れたら、同じような障害が発生したという、実験を行って下さった方がいます。
2秒間隔でのアクセスが、今回のクロールの状況に近いと思うのですが、
  • 限界に達するまでは、遅くなるとかそういう現象は見られずに、あるアクセスをきっかけに、500を返し始める。
  • 500を返し始めると、連続してエラーが発生する。
  • 放置しておくとセッション情報がクリアされ、再度、クライアントからのリクエストもIISサーバからのレスポンスも正常になる。
と、これまでに明らかになった情報や推察と一致する挙動が明らかになっている様です。

■ 関連記事

詳細はこの日の詳細から

2010年07月23日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ・クロールとDoSの違いと業務妨害罪と(6) - レガシーの呪縛[http://www.nantoka.com/~kei/diary/?20100722S1][電子自治体][DoS][mashup][セキュリティ][LibraHack] このエントリーをはてなブックマークに追加

昨日までの議論や、 gutei氏の実験[http://gutei-blog.blogspot.com/2010/07/blog-httplibrahack.html] によって、岡崎市立中央図書館 のWebアプリケーションは、 アクセスが集中すると、一定時間、新たなアクセスを受け付けなくなる「仕様」 *1 である可能性が高まってきている。 せいぜい数千程度で限りがある「データベース接続」が使い果たされてしまうと、もはやアクセスを受け付けなくなってしまうという、 インターネットにつないで、無事に動くことを期待する方が無茶な仕様 だ。
この「仕様」がどうやって作りこまれたかは、やはり「レガシーの呪縛」によるものだろう。
以下、世の中そんなこともあるかも知れないという、フィクションの積りで読んで頂きたい。

普通のWebアプリケーション:

普通のWebアプリケーションでは、数千件程度アクセスが集中したからと言って、アクセスを受け付けなくなったりはしないし、仮に、処理能力を超える負荷が掛かって、エラーを生じることがあっても、負荷を取り除けば元の状態に速やかに復帰する。
これが、ごく当たり前のWebサービスの挙動だ。
あるページのリクエストを受けたら、データベースへの接続を行って、データベース処理で必要な情報を取り出し、データベースとの接続を解除する。
この繰り返しを行うのだから、 データベース接続が使用されるのは、ページのリクエストを受けてから、データベースでの処理を行い、処理を終了するまで、短ければ数10ミリ秒から、全文検索の様な重い検索を行った時でも、10数秒程度 *2 の占有時間で、この時間内に、数百から数千のデータベース接続数が埋まってしまうことはまず考えられない。仮に、瞬間的にアクセスが集中したとしても、今、行っているデータベース処理が終了すれば、順次、空きが出て、アクセスの集中が去れば速やかに元の状態に復帰する。

レガシーの呪縛:

その昔、クライアント・サーバシステムは、クライアントを起動して、サーバに接続して、様々な処理を行って、仕事が終わったら、ログアウトするか、クライアントを終了する…といったシステムだった。いわゆるレガシーシステムだ。
こういうシステムでは、利用者がクライアントを使用している間は、データベース接続は確保されたままになるが、利用者の数は決まっているのだし、データベース接続数に余裕が無ければ、「使い終わったらログオフしましょう」と教育を徹底すれば良い。
データベース接続をつなぎっぱなしにしておけば、毎回、ログイン処理を行わなくても良いし、検索の結果が数十ページに亘る場合でも、同じ接続を使っている間は、「さっきの続き」と言うだけで、次のページが読み出せる。
プログラムも簡単だし、性能も出る。こちらの世界でシステムを作っていると、「データベース接続を毎回切断するなんて考えられない」ということになる。

館内Webアプリケーションへの移行:

(7月26日、ストーリが分かりにくくなるため、この段落削除)

WebOPAC対応:

世の中、インターネットというものがブームになって来て、ウェブを使ってインターネットを通じて蔵書検索したいという要望が多くなってきた。
Webアプリケーションとして作り直す必要が生じたのだが、普通のWebアプリケーションで述べたような作りに移行しようとすると、データベース接続のタイミングなどを大きく見直さなければならなくなる。
さらに、検索の結果を複数ページに亘って見せる場合、データベース接続を使いまわす前提のシステムでは「前のデータ」「後ろのデータ」を簡単に取り出すことができるが、データベース接続を切ってしまうとなると、毎回、新たに検索が必要になるために、このための検索条件を管理する仕組みも必要になってくる。
いまさら、これだけの大変更を入れるのは大変だし、「データベース接続を毎回切断するなんて考えられない」世界にいたため、「毎回切断するのが常識」という話を聞いても、 プロジェクトマネージャーという名前のレガシー時代のプログラマには、その変更の必要性が理解できない。
また、Web検索機能はシステム全体にとっては、 おまけの様なものなので、そもそも、そんな大きな見直しは考えられない。
これまで作成してきた、VBアプリという「資産」を「活用」することができれば、より安く、早く移行ができる筈だという考えもあった。
といった様な事情で「Web検索に対応するために最低限」の作業で、Webアプリケーションに「移植」する方針が打ち出された。
幸いなことに、IISには「セッション」という仕組みがあって、同じユーザが接続している間は、「セッション変数」内に、データベースへの接続を保持することができる仕組みがあるので、これを使えば、データベース接続をつなぎっぱなしにすることができた。 データベースの後始末は、「セッション」が終了する際に行えば良い *3
導入当初は、ブラウザの挙動の違いによってうまく検索できないとか、海外からロボットがやってきて重くなるとか、検索が遅いと思って検索ボタンをもう一回押したら固まるとか、そういう問題があったけれども、 そもそも市民図書館の検索システムを使う人は大していなかったのか、非常に使いにくくできてるのが幸いして、誰も使いたがらなくなったのか、良く分かっている人はカーリル経由で使っているのか 、データベース接続の制限が問題になることなく、レガシーの呪縛を抱えたシステムが、インターネット上でサービスを提供し続けることになった。

図書館システムだけの問題か:

実は、自治体の多くのシステムにおいて、こういったレガシーの呪縛を抱えたままの、レガシーマイグレーションが行われつつあって、庁内的には「Webアプリ化しました」という状況だが、クライアント・サーバシステムのクライアントをブラウザに変えただけ、という、従来のシステムの「横移動」になっているところが多いと仄聞する。
今後、「電子自治体2.0」なり「自治体クラウド」という言葉に乗って、もう一度、自治体サービスのWeb化が進むだろうし、様々なことを考えれば、これは推進すべきなのだけれども、上記の架空の図書館のストーリーに見る様に、 横に移動するのではなく、Web向けのシステムとして再構築する勇気 を持たなければ、まともなシステムが作れないと考える。

7月26日付記:

以前のストーリーは、全く別のレガシーシステムにおける経験を基に、「C/S→庁内Web→インターネット」という流れにしていたが、 分かりにくいというご指摘[http://twitter.com/HiromitsuTakagi/status/19490504760] を頂いたので、少し、シンプルに直した。
ちなみに、上記のストーリーはフィクションなので、あくまで参考情報だが、 MELIL/CS[http://www.mdis.co.jp/products/melil/] の利用者検索端末の画面を見た感じ、専用クライアントの様だ。
*1: 「仕様」に皮肉の響きを感じ取って頂きたい。実装時の「バグ」は修正できるが、設計時の「バグ」は、もはや修正不可能な場合が多くて、それは「仕様」になることが多い。
*2: これだけの時間、データベース接続を独占するだけでも、Webアプリケーションの作りとしてはかなりひどい。
*3: 当時書かれた、IIS+VB ASPの「入門」には、その類のコードが散見されるし、プログラミングに関するQ&Aのページでも、この仕組みを前提とした質問が見られる。キーワードは「global.asa」。但し、本格的なシステムでは使うなと、当時も言われていた。

■ 関連記事

詳細はこの日の詳細から

2010年07月24日()<< 前の日記 | 次の日記 >>
この日の詳細

■1Catalystを試してみる[WebApp][Perl][Catalyst]次の記事 >> このエントリーをはてなブックマークに追加

■ 関連記事

■2DMC-FX7の修理[写真]<< 前の記事 このエントリーをはてなブックマークに追加

来週、海に行く予定にしているので、壊しても(あんまり)惜しくないデジカメを用意する必要があって、勝手に電源が入るという電源スイッチ周りの故障でお蔵入りしていたDMC-FX7を修理することにした。
勝手に電源が入るDMC-FX7
写真をよく見て頂くと分かると思うが、電源スイッチはOFFのポジションにあるのに、電源が勝手に入ってレンズが出てきている。
バッグの中に入れている時などにこの症状が出ると、レンズが押さえられたまま、レンズを繰り出そうとするのか、他のエラーも発生したりする様だ。
この症状は、この機種では割合良く発生している様で情報源も多い。
エンジニア父ちゃんの育児日記[http://fn23.seesaa.net/article/130587056.html] や、 サービスマニュアル(DMC-FX7_SvcMnls.pdf)を参考にして、部品を取り寄せる。210円(税込)。
DMC-FX7電源スイッチDMC-FX7分解の様子
後はサービスマニュアルに従って、分解、半田ごてで部品交換。さすがに非常に小さい部品なのと、鉛フリーはんだを使っているのか取り外しに少々苦労をする。
こんな修理をしようと思うくらいの人ならば大丈夫だとは思うけれども、フラッシュのコンデンサーのディスチャージを忘れないようと、ディスチャージ前に触ってしまわない様に注意。非常に危険。それも含めて自己責任でお願いします。

■ 関連記事

詳細はこの日の詳細から

2010年07月25日()<< 前の日記 | 次の日記 >>
この日の詳細

■1自治体の図書館ページに見る地域ドメインの混乱[電子自治体][セキュリティ] このエントリーをはてなブックマークに追加

今回の一件で、各地の地域図書館のページを見て回って気付いたのだけれど、自治体のドメイン名の使い方は、やはり混沌としたものがある。
例えば、 ASP版MELIL/CS導入図書館リスト[http://www.nantoka.com/~kei/diary/?20100721S1] にある、 貝塚市民図書館[http://www.city.kaizuka.osaka.jp/tosho/index.html]
http://www.city.kaizuka.osaka.jp/[http://www.city.kaizuka.osaka.jp/] が市役所のページかと思ったら、なぜか「Directory Listing Denied」。貝津市役所のページは、 http://www.city.kaizuka.lg.jp/[http://www.city.kaizuka.lg.jp/] が正解。
歴史的に、図書館はインターネットへの接続が早かったために、市役所のページが出遅れて、混乱していているのと、政治的に市役所の方とは独立しているために、調整しにくいのだとは思うけれども、市民のためにせめて、リンクを「設置」 *1 する位の配慮はしてもらえないものだろうか。
*1: お役所的には、「設置」らしい。リンク設置許可申請とか出すらしい。

■ 関連記事

詳細はこの日の詳細から

2010年07月27日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ・クロールとDoSの違いと業務妨害罪と(7) - 念力デバッグ再び[http://www.nantoka.com/~kei/diary/?20100722S1][電子自治体][DoS][mashup][セキュリティ][LibraHack] このエントリーをはてなブックマークに追加

その後も、 #LibraHack[http://search.twitter.com/search?q=%23LibraHack] の方では、検討が続いており、セッションのタイムアウトの時間等、様々なことが明らかになりつつある。
これまでの検討で、連続したアクセスを受けた場合、恐らくデータベース接続に絡む何らかのリソース(以下、単に「リソース」と呼ぶ)が、使い尽くされ、しばらくの時間、応答ができなくなる…といった現象が発生していたのであろうということが、明らかになりつつある。
発生した現象をグラフにすれば、以下の様なグラフになるであろう。
シミュレーションによるDB接続数とデータ取得件数のグラフ
ここでは、
  1. 「リソース」はスタート時点では、全てが使える状態であり、ここでは400あるものとしている。
  2. 1秒間に1度、ページを取得し続ける。1ページを取得するたびに「リソース」も、1消費されていく。
  3. ここでは、1リクエスト/秒としているため、タイムアウト時間の秒数が、「リソース」の個数に達したとき、「リソース」が使い尽くされ、新たなリクエストに応えられなくなる。
  4. タイムアウト時間(ここでは600秒)に到達し、スタート時点で確保した「リソース」が解放され始めると、再び取得が可能になる。
  5. その1秒後には、スタートから1秒後に確保した「リソース」が解放され、以下、その繰り返しで、取得が可能な状態が継続する。
  6. 再び取得可能になった時刻から、「リソース」の個数分だけリクエストを行うと、再び「リソース」が枯渇し、3.の状態となる。
  7. 以下、その繰り返し。
  8. アクセスを止めれば、1秒ごとに「リソース」が解放され、定常状態に戻る。
と言った状況をシミュレートしている。なお、このグラフでは、他にも一般の利用者を模したアクセスを発生させている。
発生した状況が、この通りのものであったとすると、
nResource = 「リソース」の個数[n]
tTOut = タイムアウト時間[sec]
tWait = ページ取得間隔[sec]
とした時、アクセスできなくなる時間、tDownは、
tDown = tTOut - nResource × tWait [sec]
(但し、tDown < 0の時、アクセスできなくなる時間は生じない。)
と、表されるが、これまでに明らかになっている情報や、取材結果から受ける印象では、tDownはある程度大きい *1 はずで、これまでの分析で推定されている他のパラメータからして、この単純なモデルでは、tDownの長さを説明できないように感じる。
  • 実際の「リソース」解放のタイミングやメカニズムが異なる(まとめて解放される)。
  • 実は、セッションタイムアウトで明示的な後処理をしておらず、ガベージコレクタが走るまで「リソース」が解放されていなかった。
  • 実は、書誌と所蔵、予約情報を取得するために複数の「リソース」を獲得する必要があり、途中で失敗した時に、途中まで確保した「リソース」を開放していなかった。
  • そもそも新着図書更新のタイミングでは、新刊図書に予約を入れようとする利用者がおり、アクセスが集中する上に、エラーが出たら、すぐ苦情が発生する状況にあった。
  • その他
といった、何か他の要因があるのかも知れないが、いずれにせよ、プログラムの実装に問題があった *2 ことは間違いないようだ。

普通のシステムでは:

「リソース」は、例えば、数ギガバイトのディスクに対して、数キロバイトだったり、データベースのレコードだったりして、数十万とか数百万のオーダーに達する。
このため、ネットワークやCPU、HDDと言った要素が律速になり、「リソース」個数の不足によるサービス停止状況と言うのは発生しないのが普通だ。
*1: 利用者が発見して、苦情の電話をして、職員が確認してシャットダウンする位の時間であるから、少なくとも5分程度はあったのでは無かろうか。
*2: もし、実装に問題は無く、そういう「仕様」だったとするならば、今回の現象は、「仕様通りのエラー発生」だったという事だ。それを知っていながら、他者のせいにして被害届を出したという事であれば、これは大問題だ。

■ 関連記事

詳細はこの日の詳細から

2010年07月31日()<< 前の日記 | 次の日記 >>
この日の詳細

■1暑中お見舞い このエントリーをはてなブックマークに追加

バンクから暑中お見舞い用のショットを探し出してきて、フィルムスキャンしたりレタッチしたり。
暑中見舞い2010用素材

■ 関連記事

詳細はこの日の詳細から

以上、31 日分です。

指定日の日記を表示

前月 2010年07月 翌月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

最近の日記

2017年02月21日

BIGの投票内容(発番)につきまして(2017.02.20)

2016年06月29日

「SEI-Net」不正侵入事件にみる佐賀県教育委員会の杜撰

2015年11月26日

武雄市図書館から“地方自治”を考える!

2015年11月21日

シリーズ武雄市TSUTAYA図書館(34) - 「第3のツタヤ図書館にデキレース疑惑 内部資料を独占入手!」落ち穂拾い

2015年10月30日

シリーズ武雄市TSUTAYA図書館(33) - 海老名市ツタヤ館運営の行方

2015年10月26日

シリーズ武雄市TSUTAYA図書館(32) - 10月26日付 文化通信「TRC、CCCとの関係解消へ」

2015年10月25日

シリーズ武雄市TSUTAYA図書館(31) - 続・検証「9つの市民価値」

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

keikuma on Twitter

keikuma Name:前田勝之
Location:長崎市
Web:http://www.nantok...
Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

サイト内検索

Google AdSense

Powered by hns-2.19.9, HyperNikkiSystem Project