2012/1/11
ちょっと、「システムはなぜダウンするのか」という本を図書館で借りてみました。
そこで、すごくびっくりしたのが、下記のような構成図らしきものが多数記述があるのです。
説明をよめば、決して間違いとはいえないかも・・・
とは思えるものの、
「WEBサーバの同時接続数×WEBサーバの台数」
が、「同時要求データ件数」である。
とあります。
おいおい、これを書いている人はWEBサーバがどの程度、同時接続可能なのか？知っているのかい？
たいていは、APPサーバ１台の方が同時に裁ける件数はすくないのですよ。
といいたくなります。
また、APPサーバは、リクエストを待ち行列に加えるとある。
確かに待ち行列に加えるとあるが、そのリクエストにタイムアウトがあるのだよ。
いったいクライアントはいつまで待ってくれる前提で書かれているのか・・・
そして、実際私は、この構成をしたために、ダウンしたシステムを何度見たことか。
（両手の指では数え切れないくらいはあります。
そのたびに、ひたすらApacheの接続数とプロセスのプール数を少なくしてきました。）
たいていのWEB+DBのシステムではWEBサーバが一番少なくていいはずである。
なぜなら、一番処理が軽いのですから。
これは、システムに限らず、私たちの身の回りでもこのノウハウは使われている。
たとえば、レストランを想像すればよい。
通常のWEB+DBのシステムでは、
WEBサーバはレストランの入り口だとおもえばよい。
もっとも、負荷がかるいところである。
でも、なぜか、その入り口で人が待ってはいないだろうか？
これは、わざと待たせているのである。
テーブルがあいているじゃないか？
と思うこともあるだろう。
でも、テーブルにすわって、注文を受けたら２時間待たされた。ということはほとんど無いはずである。
（これがあったら、私はそうとう頭にくるし、多くの人がそう思うだろう。）
でも、入り口で２時間くらい待たせるときはある。
（一応、その説明は店員からうけるが・・・）
そして、テーブルに座ったら、込んでいても、すいていても、全体の待ち時間を含めて考慮すれば、
体感的にそれほど変わらないはずである。
それに、入り口が最大のボトルネックのシステムなんて、
設計も非常に楽だろう。
途中が一番重いから、負荷に対する処理の設計が難しく、そして、トラブルが起きやすいのである。
といっても、サーバだけを見ている人が入り口を狭めるという英断はし難いだろう。
教科書的な本にも、WEBサーバが一番多く描かれているし、
そして、なにより、APPサーバが満足に動くようにWEBサーバの接続で問題を起こさせるわけになるのだが、
そこで責任問題が起きれば、サーバ管理者が責められる。
本当は、システムが急なアクセス増加（攻撃だってありえる）でも安全に動くようにしているにもかかわらず。
と、まあ、実は、システム設計の問題ではなく、
単に、責任問題で障害が起きている。
単一部署（責任者）がサーバもアプリも見ていれば、このような障害は起きにくく、
また、起きても、その間違いに気がつけば、次の爆発的なサービス的成功なくして、まず再発はない。
しかし、ハード屋さん、ソフト屋さん、みたいに分かれているところは、
そこら中でこの問題を発生させるのである。
もしかしたら、追加ハードや追加ライセンスを買わせるためかもしれませんけどね・・・
Posted in 
