ログインID パスワード
タグツリー検索
ナビゲーション リンクのスキップ

更新されたページ

人気のページ

Brup Log Viewer のページ
Ogaworld Explosion
 フリーウェアを作っているオトモダチ

ページ検索

カレンダー検索

ヒストリ



(作成)  2010/10/17 03:23:44  はぐれSE さん
(更新)  2010/11/07 13:46:20  はぐれSE さん
(バージョン) 7

Web技術者が犯罪者にならないために

ここ数か月、Web技術者たちが注目してきた岡崎図書館事件の話をしようと思います。

この事件では、愛知県の岡崎市立中央図書館のWebサイトに集中的にアクセスを行い、サーバーを繋がりにくい状態に陥れたとして、業務妨害の疑いでこのWebサイトを利用していた男性が逮捕されました。

逮捕された方は、20日間の拘留と取り調べの後、起訴猶予処分になって釈放されたそうです。

ネットでも話題になっている事件です。

事件に関する詳しい情報は以下の各サイトをご覧ください。

サーバーが繋がりにくい状態となった直接の原因は、逮捕された方が自作したクローラーを使って図書館システムの新着図書検索機能に大量アクセスを仕掛けたためだとされています。

クローラーとは、Webサイトを自動的に巡回するプログラムのことです。

その名前から、キモい、悪い人が使ってそうなどとネガティブなイメージがこのところ広まってしまった感がありますが、今日のインターネットWebを裏で支えている非常に重要な技術です。

例えば、検索エンジンで使われています。

GoogleYahooBingといった検索エンジンを使ったことがないというインターネットユーザーはいないのではないでしょうか。

検索エンジンが、検索機能を実現するために裏で行っているのが、ロボットと呼ばれるクローラーによるWebサイトの巡回です。

ロボットはリンクを辿りながら自動的にWebサイトを巡回していくクローラーで、検索エンジンはこの結果を元にインデックスを作成することでユーザーからの様々な検索に応えているのです。

検索エンジンに限らず、他のWebサイトが発信している情報をかき集めて、それらを組合わせて新たな情報として発信しているWebサイトは珍しくありません。

こうしたWebサイトが情報をかき集める際にも、クローラーがよく使われます。

また、個人でも、様々な理由でクローラーを使う方がいらっしゃるかと思います。

ひと昔前、まだモデムでインターネットに接続していた頃にはアクセスに大変時間がかかったということもあり、予め閲覧したいWebサイトのURLをクローラーに登録して夜間に自動的にWebサイトを巡回させ、翌朝、巡回したWebサイトをオフラインで閲覧するといった使い方がありました。

私もWeb技術者のはしくれとしてクローラーを使う場合が考えられる立場にありますので、この事件の成り行きにはとても注目していたわけです。

今回、私が注目する観点は、以下の3つになります。

  • クローラーを使ったら犯罪になってしまうのか?
  • 本当にクローラーによる大量アクセスがサーバー障害を引き起こしたのか?
  • 犯罪者にならないためにはどのようにクローラーを使ったらよいのか?

クローラーを使ったら犯罪になってしまうのか?

事件の成り行きを見る限り、クローラーを使ってサーバーに何らかの障害が発生し、そのWebサイトの運営者が警察に被害届を提出した場合には、犯罪になってしまう懸念が残されてしまいました。

逮捕された方は起訴猶予処分という判断が下されました。

起訴猶予処分とは、犯罪であると認められるが、被害が軽微である、初犯である、本人が反省していて再犯の可能性が低いと考えられる等の事情を考慮して下される処分だそうです。

前科はつきませんが、前歴がつくのだそうです。

となりますと、Web技術者としては極力クローラーを使うのを避けなければならなくなってしまいます。

何故なら、クローラーを使ってサーバーに障害が発生しないことを完全に保証する手段をクローラーを使う側は持ち合わせていないからです。

※もっともこれはブラウザであっても同じことなのですが、クローラーだけがターゲットにされてしまっています。

クローラーが滅多なことでは使えないというのであれば、これはもうインターネットWebの危機的状況だと言えると思います。

では、この事件は本当にクローラーによる大量アクセスが原因だったのでしょうか?

本当にクローラーによる大量アクセスがサーバー障害を引き起こしたのか?

上で紹介した各サイトの情報によると、この事件に限ってはクローラーによる大量アクセスが原因ではなかったように思われます。

そもそも大量アクセスが何を以て大量であると定められるかという議論があるようですが、私の理解では、この文脈に関する限りサーバー障害を引き起こす怖れが考えられるアクセス量となります。

決して定性的な意味でも相対的な意味でもないと思っていますので、この議論で不毛な時間を費やすことのないようにしたいと思います。

どれだけのアクセス量でサーバーに障害が発生するかはサーバー機器のスペックやシステムの作り方によって変わってきますので一般的な解は見出せないと思いますが、特定のWebサイトにおける閾値であれば定量的かつ絶対的に求めることができると思います。

一方、大量アクセスがサーバー障害を引き起こすメカニズムについては、一般的な解として以下のものが考えられます。

  • 同時に集中するアクセスの過多により処理を実行するリソースが不足した
  • アクセスが続いた結果、恒常的なリソースの消費が累積し、ついに枯渇した
  • その他(機器やOS・ミドルウェア・Webアプリケーションの欠陥、設定の不備等)

まず、同時に集中するアクセスの過多により処理を実行するリソースが不足した場合ですが、某遊園地の入場口を例にとってみたいと思います。

この遊園地の入場口には複数のゲートが設置されていますが、開場直後はどのゲートにも入場者が列をなしており、待ちが発生しています。

この場合、ゲートの数が処理能力を決めるリソースであり、入場者がアクセスであると考えてください。

リソースを上回る大量アクセスが原因となって、遅延障害が発生している状況がうかがえます。

さて、しばらく時間が経ちますと入場者の列はなくなり待ち行列も解消します。

アクセスに比べて十分なリソースが存在するときには、遅延することなく処理が実行できるのです。

この場合のポイントは、同時集中的な大量アクセスであることです。

逮捕された方の説明によると、自作したクローラーはシリアルアクセス(アクセスが完了してから次のアクセスを行う = 同時には1アクセスのみ)だったとのことです。

これを信じるならば、クローラーだけでアクセスが集中することはないとみて間違いないでしょう。

クローラーを実行していた時間帯に他の利用者のアクセスもたくさんあったためにアクセスが集中した可能性がありますが、もしそうなら、クローラーだけを原因とするのは適切な判断ではないと思います。

次に、アクセスが続いた結果、恒常的なリソースの消費が累積し、ついに枯渇した場合ですが、これも某遊園地を例にとってみたいと思います。

この遊園地は1日の最大入場者数が1万人と定められており、1万人を超えた場合には入場できなくなってしまいます。

この場合、最大入場者数が恒常的なリソースの消費の限界値であり、入場者がアクセスであると考えてください。

1万アクセスの時点でリソースが枯渇し、それ以降、サービスが停止してしまった状況がうかがえます。

遊園地の場合は、翌日にならないと解消しません。

システムの場合、例えばアクセスログを無制限に記録する仕様となっていて、これに対するディスク容量が少なかったためにディスクが一杯になってしまった等が考えられます。

この場合、ディスク容量を増やすか、一杯になったアクセスログをディスクから削除しなければサービスを再開することはできません。

通常このような怖れが考えられる場合には、アクセスログの記録容量の最大値をシステムで設定し、設定値を超える事態が生じた場合には古いアクセスログから順に削除して、容量を設定値以下に抑える工夫が組み込まれることと思います。

この場合のポイントは、累積的な大量アクセスであることです。

図書館システムのアクセスログの記録方式が実際にどのような作りであったかは今のところ文献等確認できていませんが、仮にこのシナリオだった場合、クローラーだけでなく一般の利用者であっても等しくサーバー障害を発生させる可能性があったことになります。

実際にディスク容量が枯渇してしまうほど少なかったのだとしたら、上記の工夫を組み込むか、ディスク容量を増強する等して、システム側で事前に対処することができたはずです。

また、過去から累積し続けたアクセスログを放置していたことが原因だとしたら、システム運用のやり方をまず問題視すべきでしょう。

いずれにしても、クローラーだけを原因と決めつけるような判断は適切ではないと思います。

実際この事件の真相は、その他(機器やOS・ミドルウェア・Webアプリケーションの欠陥、設定の不備等)の原因であったことが、朝日新聞の記者の方やセキュリティの専門家らによる調査の結果、分かってきました。

原因は、Webアプリケーションをプログラミングする際の基本的なアーキテクチャの欠陥が招いたDBコネクションの枯渇エラー状態セッションの使用だったそうです。

詳細については、上で紹介した各サイトが詳しいのでここでは取り上げませんが、大量アクセスなどなくても、条件さえ合致すれば一定量のアクセスでサーバー障害が発生する状態だったわけです。

大量アクセスをサーバー障害を引き起こす怖れが考えられる量を超えるアクセスと定義した場合、この文脈で想定できるのは同時集中的、または累積的なアクセスの量だけとなります。

その他の原因というのはそもそも想定されない原因ですので、今となっては大量アクセスという表現自体が適切でなかったと判断できると思います。

ただ、これにも関わらず気になるのは、

  • では何故、逮捕された方は無罪放免ではなく、起訴猶予処分なのか?
  • 何故、図書館側は大量アクセスによってサーバー障害が発生したと主張したのか?

です。

願わくば、逮捕された方の名誉が回復されますことと、大量アクセスが原因ではなかったことが公式にアナウンスされることを希望します。

これが解決しない限り、インターネットWebが危機的状況であるとの認識は完全には払しょくできないのではないかと思っています。

ということで、最後に現時点で犯罪者にならないためにはどのようにクローラーを使ったらよいのかについて考えたいと思います。

犯罪者にならないためにはどのようにクローラーを使ったらよいのか?

第一に、クローラーを使わないで済むのなら現時点では使わない方がいいのかもしれません。

残念ながら、この結論です。

まずは代替案を検討しましょう。

第二に、クローラーの動作はシリアルアクセスとし、アクセスが同時に多数集中することがないようにプログラムすべきです。

加えて、前のアクセスの応答を受信してから次のアクセスの要求を送信するまでの間を一定時間空けるようにしましょう。

サーバーにアイドル時間を与えることで、サーバー側のリソース管理がよりスムーズに働くことを期待できます。

可能なら、サーバからのエラー応答やタイムアウトを識別し、クロール処理を中止できるようにプログラムしましょう。

第三に、クロール先が特定のWebサイトであるならば、事前にその管理者に連絡を取っておく方がいいかもしれません。

・・・なんだか消極的な結論になってしまいました。

やはり危機的状況が解消されることが最良だと思いますので、今後も事件の成り行きには注目していきたいと思います。

日本のWeb技術者に明るい未来が待ってますように。

このページに対するコメント
コメントがありません。
Copyright 2006-2015 はぐれSE All Rights Reserved.
Powered by Cvec*KCS.