前回ご好評をいただいたブログサーバおそおそランキングですが、より正確に計測しての第２回目です。
前回は私の感覚でランキング付けを行いましたが、今回は以下の条件を設定して、できるだけ正確かつ公平にサーバの重さを計測できるようにしました。
急激なユーザ増加により何かとシステム負荷問題に晒されやすい blog サービス。0:30 分からの管理画面での更新速度調査だそう。サービスの作り手側としてはドキッとするような記事です。おそるおそる見て見ると...
第６位 はてなダイアリー ２．０秒
(中略)
このあたりはゼンゼン問題ないですね。これくらいならストレスを感じることはないです。
おお、よかった..。
公平に測るために、ということですと各サービスの ping 送信機能は OFF にするとかして計測したほうがよさそうですね。深夜時間帯は ping の応答速度も、ping サーバによって結構ばらつきがあるようです。weblogs.com とか平気で timeout したりしますからね。
過去の経験からいくと RDBMS で集中的にデータを管理する blog サービスにおいて、ボトルネックになりやすいのはやはりスケールさせづらいデータベース周りと、画像などのファイルのディスク I/O なのですが、想定していいる以上のユーザ数の伸びに対して、あっというまに閾値を超えてしまっていかんともしがたい、みたいなところが顕著に出てきているのかなとも思います。中にはサーバのチューニングパラメータの最適値を探すのに四苦八苦しているところもあるかもしれませんが。段階的に負荷が高まっていくのであれば監視努力で事前にそれを回避することもできるのですが、データベースに関しては、ある一定のポイントを超えると急にシステムが不調を来たすほどの負荷がかかり始めるというのが、キャパシティプランニングの難しいところ。
増設すれば OK みたいな単純な話ではなく、むしろ増設さえすれば負荷減って OK というシステムは理想的であり、それで済むなら簡単に対応できるという。技術的にスケーラビリティを確保するのが難しいところにボトルネックが生じてしまうと、アプリケーションの改修による改善は時間がかかるので、縦のスケールを確保、つまりマシン単体の性能を上げるとかディスクI/O を改善するといった方法での対応になるので、データの入れ替え作業などによる時間のロスや、あるいはオペミスでデータをロスしてしまったりとリスクが付きまといます。
と、あーだこーだ考えている一方で、ぜんぜん想定していなかった箇所にボトルネックが発生してるのに、先入観でありがちなところを探っていて発見に遅れるということもありつつ。ほんと、現場は大変です。各社それを乗り越え、頑強なシステムに育っていくのでしょう。
