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: もし、実装に問題は無く、そういう「仕様」だったとするならば、今回の現象は、「仕様通りのエラー発生」だったという事だ。それを知っていながら、他者のせいにして被害届を出したという事であれば、これは大問題だ。

■ 関連記事

詳細はこの日の詳細から

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

■1 Linuxサーバの3分の2はウイルス未対策、ソフォスが「考えて」[http://www.atmarkit.co.jp/news/200507/27/sophos.html][セキュリティ]次の記事 >> このエントリーをはてなブックマークに追加

Stressful Angel[http://stressfulangel.cocolog-nifty.com/stressful_angel/2005/07/_727__23a2.html] から。
ソフォスの代表取締役社長 アラン・ブロデリック(Alan Broderick)氏は、「ウイルス対策を行っていないLinuxサーバがWindowsのウイルスを検知できず、Windowsクライアントに感染させるケースがある」と警告、「管理者には考えてもらいたい」としている。
考えてみても良いけど、Linuxサーバ側でWindowsのウイルス対策をするというのは、どうも納得がいかないソリューションだ。
ディスクにウイルス対策ソフトを入れるとか、ルータにウイルス対策ソフトを入れるとか、まぁどっちもやってる話はあるけど、違うレイヤで対策している様に感じる。
一般的に、本来やるべきレイヤやポイントではないところで対策せざるを得ない状況というのはあんまり良くない状況だ。これはメタな原則なので、何かのシステムを設計する時は考えてみるべき。

この記事に頂いたコメント

Re: Linuxサーバの3分の2はウイルス未対策、ソフォスが「考えて」 by てんて    2005/07/29 02:28
わからないところがあるのでよかったら教えてください。 >ディスクにウイルス対策...

■ 関連記事

■2 PICでもっと遊ぶその1「ラジコンサーボを自由自在に動かす」[http://www.itmedia.co.jp/pcupdate/articles/0507/08/news039.html]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

連載になっている。PICも面白いもんなぁ。仕事で書くのとは全く違う方向で何かお馬鹿なおもちゃを作りたい。

■ 関連記事

■3 着メロの“万引き”が行われている?[http://www.itmedia.co.jp/news/articles/0507/26/news053.html][著作権]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

確かに、視聴版を録音あるいは変換して着メロというか着信音にすることは比較的簡単にできるだろうけど、
平均的なコンピュータユーザーなら、着メロの試聴版を右クリックして自分のコンピュータに保存し、それをBluetooth対応デバイスで携帯電話に転送するという方法で、いとも簡単に着メロを万引きできる」とQpassの広報担当者はinternetnews.comに語った。
「平均的なコンピュータユーザー」がそんなことをできるかどうかは微妙だ。
直接録音するのが簡単かも知れないし、着信音だったら十分なのかも。

■ 関連記事

■4「台風はディズニーランドには来ない。ここは夢の国だから。」<< 前の記事 このエントリーをはてなブックマークに追加

台風7号が近づく中、ディズニーランドに向かう人達にインタビューしたら聞かれたという台詞。
なんか、報道者の創作では無いかというフレーズな気がする。創作でなくても。
記者「台風が来そうですが、大丈夫ですか?」
来場者「台風、来ないんじゃないですか?」
記者「夢の国だから、来ないということですか?」
来場者「そんな気がする」
の様なインタビューで、表題の様な台詞になるのかも知れない。
愛知万博の会場では、警備員の人がトラメガを持って注意を呼びかけていた映像があったけれども、ディズニーランドではそういう光景は見られなかった様だ。
本当に危ない時は、夢を壊さずに何とかするマニュアルが作られているのかも知れない。重要なトレードシークレットだろう。実際にそれなりの事態が起きるまではなかなか見ることができない光景だろう。
実は準備はしていないとしたら、それはそれでトレードシークレットだろうけど。
もちろん、ディズニーランドでは大丈夫かも知れないが、帰りに JR舞浜駅、TDL帰りの客で深夜まで混乱[http://www.asahi.com/national/update/0723/TKY200507230326.html] 等という事態に巻き込まれることはある。
地震発生当時、計約6万人の入場者がいたが、JR京葉線が23日午後11時35分まで、約7時間にわたって運転を見合わせたため、多くの客が帰りの足を奪われた。最寄りのJR舞浜駅は行き場を失った人々でごった返し、日付が変わった24日未明も数百人が座り込んだままだった。
「いつまで動かないんだ」「ちゃんと説明しろ」。人であふれかえった舞浜駅では怒声が飛び交い、バス停には長蛇の列ができた。携帯電話の電池が切れた人たちが公衆電話の前に長い列を作り、運転再開を待ちくたびれた客同士が怒鳴りあう姿もあった。
遊び疲れた子どもを連れてこれは辛い。夢の国から出てきた途端に、阿鼻叫喚。
午後7時ごろまで園内で遊んだ後、大混雑する駅に来て初めて事態の深刻さを知った。「園内で具体的な交通情報を知らせてくれたら」。疲れ切った表情でそう話した。
という意見もある様だけれども、これをやると夢の国の雰囲気は損なわれてしまう。 自己責任の上に成り立つ夢の国というか、この辺りは夢の国にいても考えておかなければなるまい。

■ 関連記事

詳細はこの日の詳細から

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

■1はいぱー日記システムとGPL このエントリーをはてなブックマークに追加

最近日記の更新が全くもって滞っているのは、書き初めに大きなポテンシャルが必要だというところにあるんじゃないかなと考えました。
実は、 「はいぱー日記システム」[http://www.h14m.org/] というすごいシステムがあるのです。 FAQ[http://www.h14m.org/docs/FAQ-j.html] によれば、
とのことですから、「日記書くならこれだ!」って感じです。
導入したいなぁと思って思案中。実はWeb日記の総合検索サイトとか、あるいはWeb日記用のサーバレンタルとかあったら良いなぁとか、ウチでやってみようかなぁなんて思いもあります。
商売にするとなるとGPL2では厳しいかなぁ、新たに書き起こすにしても。既にhnsは業界標準的な存在ですし、意識しないわけにはいかない存在ですね。
いつか書こうと思っていた、LinuxじゃなくてFreeBSDを使っている理由の一つ。
Linuxの配布系の多くの部分は、 GPL[http://www.gnu.org/philosophy/philosophy.html] に則って配布されており、対してFreeBSDの配布物の多くは、 (修正)BSDライセンス[http://www.jp.freebsd.org/www.freebsd.org/ja/handbook/x15242.html] に則っています。
なお、「修正」というのは以前のBSDライセンスにあった、いわゆる広告条項のことで、そのプログラムを使ったソフトウェアを広告する場合、「このプログラムはだれそれによって開発したプログラムが含まれています」という文章を加えないと行けないという条件が取り除かれたもののことを言います。詳しくは、 "The BSD License Problem"[http://www.gnu.org/philosophy/bsd.html] をご覧下さい。
で、どちらのルールも各々目指すところがあって作られているわけで、逆にいえば各々に理想があって、異なる宣言が成されているわけです。
いずれにせよ、フリーソフトだからといって何をするのもフリーなわけではなく、選んだらからにはちゃんとルールを守る義務があります。そういう中で弊社の業務として「常にGPLで大丈夫か」というと厳しい場合もあると考えています。
例えば、サーバーを運用する場合、あるいはお客様向けにサーバをセットアップする場合、カーネルやシステムに手を加えるのは良くあることですし、その辺がプロバイダとしての技術力でもあります。この辺、私の読み間違いであれば良いのですが、
  • 1.プログラムに変更を加える場合はGPLに従わなければならない。
  • 2.変更したプログラムはGPLに従って配布しなければならない。
という様に読めます。結局、全く変更せずにそのまま使うか、ちょっとでも変更したらソースを含めて全て公開するかを選択しなければならないわけで、特にセキュリティがらみの変更(コンフィグレーション)を行った場合はとても困ります。
これはちょっと困るんじゃないかなぁというのが、Linuxに手を出せないでいる理由です。
他のところはどうしてるんでしょうか?それとも私がGPLを勘違いしてるだけだったら、ぜひ教えてください。

■ 関連記事

詳細はこの日の詳細から

以上、12 日分です。

指定日の日記を表示

前月 2019年10月 翌月
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年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

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

2018年12月25日

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

2018年12月23日

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

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


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

予定

    ToDo

      link

      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