重いサイト関連で、最近「SIerとしての責務を果たせていなかった」 図書館システム問題でMDIS謝罪」というニュースが上がっていました。

決してアクセスが非常にあるようなサイト(サービス)大規模でないにもかかわらず、サイトが重かったことからいろいろとおかしな状況になってしまった一例です。
(それだけではないかもしれませんが・・・)

これに関連して、「DoS攻撃?」と悩んだら相談を、IPAなどというニュース(?)まで出てしまう有様です。

記事の内容をそのまま読めば、そんなケースに発展しそうもないのですが、
この記事では、事件の内容の是非よりも、この記事の内容を信じて、
どこがおかしいのか?その背景にはどのような技術的間違いがありそうなのか?かを想像してみることにしました。

ただし、あくまでも記事からの想像なので本当にそうなのかはわかりませんが、
記事を読んだだけでも、この程度の可能性については検討できるという事です。

原因は「1アクセスにつき10分間のDB接続を維持」する仕様

まず、この文です。
明らかに不自然で、仕様のはずはありません。単なるバグのはずです。
もし、これの目的は問わず、これを仕様として実現するとなるとどうすればいいのでしょうか?
アクセスが終わっても、その後約10分間接続を維持するという要求を実現するのは結構難しいです。
まず、PHPのようなアクセス毎にプロセスが終わってしまう(ケースを想定しなければならない)タイプのApacheのモジュール型として実現されているケースでは、
実現はそうとう難しいはずです。
ということは、ここであり得るのはWEBからの接続をメモリ空間にとっておける常駐型インフラの「Java」ベースか「IIS」ベースだなと。

しかし、「Java」でコネクションプーリングの時間をアクセス毎にするのはこれまた至難の技です。
自分でアプリケーションサーバを作ってしまえばできない事もないですが、
既存のアプリケーションサーバでそのような意味のない機能をサポートするはずはないので、
「Java」ではないな。と。
「IIS」ベースかどうかは、私にはこの時点では判断つきません。
それは、単に私が「IIS」ベースの知識をもっていないからに過ぎませんが、
消去法で「IIS」ベースであるだろうということが想像つきます。
あえてそれ以外も考えて、ないとは思いますが、FastCGIのように特殊な事をやっているケースもなくはありませんが、
ここで、使われているOSがWindowsであればそのようなチャレンジングな環境を作ることはまずありません。

また、すべての1アクセスで10分の接続とは記述されていません。
それだと、すぐに問題になってしまいバグ(仕様ではない)だと誰でもすぐに気がついてしまいますし、
さすがに初めての導入で問題になってしまい、2つ目はないでしょう。

であれば、問題となっているケース(ここではクローリングらしい)の時に発生するはずです。

ここまで疑うべき原因の候補はやはり、「コネクションプーリング」に関するバグだろうな。と思えます。
要するに、10分がアイドル時間の期限切れ設定なのだろう。と。
そして、このシステムを構築したエンジニアは、コネクションプーリングをという概念を理解していなく、
また、その開放ということが厳密にできなかったのであろうと。
(理解があれば、仮にそのようなコードを作ってしまっても、問題を聞けば、あーやってしまったとすぐに気がついて直すことができます。)

というのは多少勘のある方なら疑いの1つとして頭の片隅に置くはずです。

障害発生の連絡を受け、同社は「他の利用者へのサービスを優先し、機械的なアクセスを回避する種々の処置を講じたが、完全な回避はできなかった」という。

次に、この文です。
まず、ここで使われるサービスはメディアのような物ではないので、大量に世界各国からアクセスを想定することはありえず、
しかも、悪意がある攻撃の意味は少ないはずです。
また、多少レスポンスが遅くても遅くても問題ないはずです。
(つまり、人間が遅いと感じないレベルを保ちつつ、機械的には明らかに遅いというレベルです。)

なので、極限までパフォーマンスを保ちつつ、不正なものだけブロックという必要はないはずです。

であれば、パケットレベルのアクセス制限で簡単に目的が達成できるはずです。
iptablesを使えば、iptablesでできるDoS/DDoS対策のように、
ノウハウは至るところに落ちております。
狙い澄ました悪意ある攻撃にどこまで耐えられるかは私は言えるほど知識をもっていませんが、
すくなくとも、無知の第三者からパソコンのウィルスが仕掛けるようなおもしろ半分の無作為の攻撃ぐらいならたいてい防げるはずです。

そして、製品という性質上、その単体で対応できることを望まれますが、問題となっているケースでそれをすぐに、
しかも、ただで対応できるのならば、顧客もその解決策をNoと言わないはずです。
ただし、Windowsでそのような同じレベルでの解決策をすればいいんじゃないの!という提案を私は聞いたことはありません。
(技術的にできないかといえば、それはあり得ないと思いますが、やはりそのあたりは環境がもつキャラクター(個性)というのがあるのも事実です。)

とここまでくれば、このサービスはWindowsベースで運用されていたな。という事が想像つきます。
これで、FastCGIやその他のようにあまり広く使われていないようなレアケースもないはずです。
まず、このレベルを使っている方達は自分たちで解決できる自信を持っていることが通常です。
(なので、別に本人達にとってはチャレンジニングな環境ではないでしょうが、人材を一般市場から調達することを考えればやはりチャレンジングです。)

ここまでを見ていくと・・・

これらを踏まえると、問題を解決するキーワードは「IIS・VB」「DB」「コネクションプール」のような感じになり、
その用語で検索をしていくと、
その関連のエンジニアがどんなことはまり、そして悩んでいるのかが見えてくるかもしれません。
(もし現場に入ることができるのならば、どんな本を読んでいるかだけで、かなり状況は見えてくるのですが・・・)

すると見えてきます。問題になりそうな事が。
いきなり、Googleの検索のTOPに同じようなことを言っている方がいます。

これ以外にもみてると、「ユーザのセッションオブジェクトにDBのコネクションを入れるのは危険」のようなことが書いてあります。
そりゃ、危険ですよね。あたりまえです。
HTTPは基本ステートレスなのですから・・・
そのような声明をMicrosoftが出しているという記述までありました(ただし、私はその記述が本当にあるかまでは確かめていません)。

ただ、よくある間違いとして認識されているという事実だけはあるような気がします。

また、このバグをもし、「仕様」と扱って説明を作ってくれと無理矢理たのまれれば、
「1アクセスにつき10分間のDB接続を維持」
のように言ったにも納得がいきます。

とここまでの仮定を製品名などや、ほかのニュースを元に検証していくと、

やはり、Windows/IISのようです。
また、解決方法としてアクセス毎にDBの接続をするように変えた。とありました。
仮定は90%以上正しいと思います。

まあ、理屈でわからなくても経験的に原因がわかる方も多いはずです。
それほど、これと似たようなケースは至る所で見ることができます。
それが問題になるほどのサイトになっていない、もうちょっとレアなケースで発生しているなどなど。
また、多くの方がこのような間違いを通じて、事件にならないまでも問題として解決していくことで今があるわけです。

なので、私がもっとも問題だと思うのは、このような障害の問題が発生してしまうことよりも、
社会的な問題(もしくは、経営的にも影響があるほど)にまで発展させてしまうほど、技術的な常識力が機能しなくなってきている事ではないでしょうか?

そして、それを抑制(防止)させるだけの相談できる技術者(有識者)が経営にかかわる人たちにいなくなっているということの気がします。
これは、どこかにあった「間違ってファイルの日付を変えてしまった」のようないいわけに無理があるにもかかわらず、
それが表に出てしまったことも似たようなケースのような気がします。

それだけ、技術という基盤が一般の方達から何とも説明ができない「魔法」になってしまったのか、
それとも技術者達が「社会的に信用できないやつ」に成り下がってしまったからなのでしょうか?

だとしたら、エンジニアが弁護士のように会社の専属相談役として働けるような仕組みがあれば、
このようなケースも多少は防げるのではないかとたびたび思います。
(法律家だって、社会的に信用がある職業から、信用がない職業までありますよね・・・)

法律的な解釈のことは、普通の人はあまり突っ込まず専属の弁護士の先生に相談しておしまいですよね。
そして話している内容が難しい用語で固められていても、同じ法律家同士で理解するための必要な事であれば問題ありません。

それと同様に、技術的な正しい解釈をすべての人が理解できなくても、同じ技術者通しで理解できれば問題ないのではないでしょうか?
それで「よし」とする文化や信頼を作れる環境も必要なのではと感じてしまいます。

まあ、その相談役としてIPAが買って出ますよということなのでしょうが、
大きな案件ではそれでいいかもしれませんが、小さい案件では厳しいでしょうね。

お仕事のご依頼・相談を承ります
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら

Leave a Reply

お仕事のご依頼・相談
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら
ソフトウェア&ライブラリ




ライブラリ
airxmail(en)
AIR版メール送受信ライブラリ
airxzip
AIR版ZIP圧縮・解凍ライブラリ
執筆書籍
本、雑誌等

WEB記事:CodeZine
執筆記事はこちら
カレンダー
2010年12月
« 11月   1月 »
 12345
6789101112
13141516171819
20212223242526
2728293031  

カスタム検索
RSS
Add to Google < !–adsense–>
アーカイブ
カテゴリ
にほんブログ村 IT技術ブログへ