2010年07月22日(木) << 前の日記 | 次の日記 >>
これまでの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サーバからのレスポンスも正常になる。
と、これまでに明らかになった情報や推察と一致する挙動が明らかになっている様です。

■ 関連記事

今日のつぶやき

  • @masason は、ソフト流通業界の覇者として、日本発の携帯アプリ、コンテンツ流通市場を創出すると思っています。いつまでもアップルストアに独占させてはおかないと。そのための、#Androidだと。#X06HTだと。まだ機が熟していなかっただけかも知れません。2010-07-22 00:04:13 Tween masason宛て
  • 【再掲】混乱している人がいそうな気がするので強調しておきます。Webの「普通の使い方」と「普通でない(新しい)使い方」に線を引こうとするから混乱するのです。HTTPサービスに対する「DoS攻撃」かどうかを判断すれば良くて、ほとんどはサーバ側で判断できます。 #LibraHack2010-07-22 07:40:57 Tween
  • @hrjn 具体的にどういう風にミスするとその程度のクロールで停止するサーバが出来上がりますか?そして、そのミスに設定した側は通常気付かないものでしょうか? #libraHack2010-07-22 07:51:58 Tween hrjn宛て
  • 試しに、ウチで一番貧弱なサーバを引っ張り出してきて、ノーウェイト無限リクエストを一晩掛けっぱなしにしてみたのだけど、何の問題もなく動いていた。当然と言えば当然。 #LibraHack http://twitpic.com/27erxs2010-07-22 08:17:47 Twitpic
  • @seri_nazuna おはようございます。長崎よりもむしろ関東の方が暑そうですね。お気をつけて。2010-07-22 08:29:13 Tween seri_nazuna宛て
  • @gutei そのあたりの話は、 http://bit.ly/9N6wK8 で書いた通り、理解はしているのですが、「貧弱なサーバだと、大量にアクセスすると落ちるのは仕方がない」とか、勘違いする人がいる訳です。いくら貧弱でもシリアルアクセスでは落ちませんと。 #libraHack2010-07-22 08:46:10 Tween gutei宛て
  • @hrjn その場合、ブラウザで見たら簡単に死ぬので気付き得るでしょうし、むしろ、シリアルアクセスをするクローラの方が安全なんじゃ無いでしょうか。 #libraHack2010-07-22 10:55:16 Tween hrjn宛て
  • @gutei ぜひ、どっかでまとめを。2010-07-22 11:03:46 Tween gutei宛て
  • @hrjn そういう環境はあり得ると思います。ですが、それに気付かずに実運用に入れるのは特殊なケースだと思いますし、その場合は「そういうサーバ」なので、それを知らずにアクセスしてきた人に、「故意にサーバを落とした」と言うのはおかしいと考えます。 #libraHack2010-07-22 11:17:53 Tween hrjn宛て
  • あるいは、コネクションプールを使っていても、セッション変数にオブジェクト格納しているとか。 #libraHack2010-07-22 11:20:07 Tween
  • @hrjn 迷惑なのは話を切り分けましょう。クローラを作る立場としては相手への配慮は必要で、配慮がないクローラを動かすと、サーバ運用者からアクセス禁止という罰を受けます。しかし故意でないのに、刑事罰を受けるのはおかしいと主張しています。この点は合意ですよね? #libraHack2010-07-22 11:27:23 Tween hrjn宛て
  • @hrjn 例えば、10秒間に1リクエストしか答えられないサーバがあるかも知れませんが、それを公開するのもアクセスするのも自由ですよね。一方、10秒間に1リクエストなのに、エラーを返しても1秒経ったらリトライしてくる人がいるかも知れませんが、それは仕方がないことです。2010-07-22 11:47:27 Tween hrjn宛て
  • @hrjn なるほど。私の方では、「俺の直感では一秒に1回のクロールはapacheの設定ミスったら停止する」を一般化して、「そういうサーバも普通にあるのだから」「クロールする側に責任がある」と短絡的に結論する人が出るのを危惧した訳です。2010-07-22 12:30:38 Tween hrjn宛て
  • @katzchang それが結構あるんですよ。困ったことに。そんなのインターネットにつなぐなと。 http://bit.ly/cMlfxO #libraHack2010-07-22 12:35:15 Tween katzchang宛て
  • @gutei @yasushia Session_OnStartでSession変数内にSet、Session_OnEndで解放という形ではどうでしょう? #libraHack2010-07-22 12:42:29 Tween gutei宛て
  • I'm at 長崎夢彩都 (元船町10-1, 長崎市). http://4sq.com/56x0ME2010-07-22 14:00:55 foursquare
  • @gutei 素晴らしい。実際のシステムでは、Database_oo4oとかSession_oo4oを、その場ではCloseやnothingしないで、Session_Endで処理してたのではないでしょうか。あるいはDynasetも(リストの移動は早いので)。 #libraHack2010-07-22 15:40:38 Tween gutei宛て
  • @gutei おつかれさまです。期待しています! #libraHack2010-07-22 15:46:36 Tween gutei宛て
  • @seri_nazuna という見識がある人のところにまとめたわけですね。人徳。人徳。2010-07-22 17:08:22 Tween seri_nazuna宛て
  • 「まさか、しばらくたてば回復するのを再起動しておいて、被害届も無いだろう」の、まさかであった可能性が高くなった。そもそもこの様な実装であれば、アクセスが集中するとしばらくアクセスできなくなるのは「仕様」ではないか。 http://bit.ly/amAmOM #libraHack2010-07-22 22:14:01 Tween
以上、1 日分です。

指定日の日記を表示

前月 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

最近の日記

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

2018年12月18日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
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