最初に結論:最大のボトルネックはCPUとディスクの読み書き速度、サーバのハードウェアとしてのスペックをさらにあげる必要性あり

まずins-magazine.netで使っていたのはさくらのマネージドサーバで、これは共有ではなく1個のサーバを借りるという専有プランである、予算の都合上、選んだのは一番下の「Atomプラン」で、2010年1月23日に申し込みをしたもの。

◆Atomプラン
初期費用:2万5000円
月額:7800円
CPU:Intel Atom 330 @ 1.60GHz
メモリ:2GB
OS:FreeBSD 7.1-RELEASE-p16 i386

少し重くなり始めたのが2012年に入ってからで、ついにタイムアウトまでするようになったのが2013年に入ってから。正確には2013年1月。

どれぐらい重たいのかを計測するため、「Pingdom」の無料版を導入したのが2013年3月16日。

で、以下が2013年3月の測定結果。

「Uptime」がサーバの稼働率で、ここを「100%」にするのが目標。「Outages」というのはまったく接続できなくなった回数。「Response time」はサーバが反応するまでの秒数(単位はミリセカンド、1000ミリセカンドで1秒)、そして「Downtime」が接続できなくなった総合計時間。

◆2013年3月(3月16日~3月31日まで)
Uptime:99.85%
Outages:8
Response time:3168ms
Downtime:32分

これだけだとわかりにくいので、グラフ化するとこうなる。

201303

なんということでせう。さらに翌月の結果も衝撃的。

◆2013年4月(4月1日~4月30日まで)
Uptime:99.88%
Outages:17
Response time:3415ms
Downtime:52分

グラフで見るとこうなる。

201304

問題は落ちた時間ではなくその回数の多さと間隔。1ヶ月に1回だけ落ちて52分接続できなかったというわけではなく、ほぼ1日半に1回ぐらいのペースで落ちており、しかも4月前半は春休みで更新が滞ったので落ちていないだけで、実際にはそこからあと延々と落ち続けている状態。そもそも論として実は既に2012年の段階でキャッシュとかの対策はほぼ済んでおり、これ以上できることはあまりない状態。

で、そのまま11月まで手を打てず、以下のような状態が続くという有様に。

◆2013年5月
Uptime:99.67%
Outages:15
Response time:3385ms

◆2013年6月
Uptime:99.78%
Outages:25
Response time:3410ms

◆2013年7月
Uptime:99.79%
Outages:26
Response time:3041ms

◆2013年8月
Uptime:98.58%
Outages:23
Response time:2789ms

◆2013年9月
Uptime:98.86%
Outages:32
Response time:3019ms

◆2013年10月
Uptime:99.68%
Outages:26
Response time:2920ms

◆2013年11月
Uptime:99.89%
Outages:19
Response time:2816ms

グラフで見るとなんとこうなる。特に9月がひどいのは文化祭などで更新が重なったため。
201305-11

ところがレスポンスタイムを見るとわかるように、実はサーバ自体の反応速度は悪化していない。なぜかというと、重くて落ちる原因はサーバを軽くするためのキャッシュファイル生成処理にあって、以下のような流れになっているため。

「記事を投稿する」

「それまで保持していた数百のキャッシュファイルを一斉に削除」

「さらに新しくキャッシュファイルを生成」

キャッシュファイルさえ生成できてしまえば、もうCPUも動かず、メモリもさほど使わないので爆速であるものの、キャッシュファイルの生成が一段落するまでの間も人は見に来るわけで、それだけでなく海外からの管理者権限を奪取しようとする定番の攻撃、Googleなどの検索エンジンによるクロール、などなどのさまざまなアクセスが常に発生し続けているということが判明。なので、ファイアウォールを立ててアクセスを弾くと一気に軽くなる。

また、専用サーバのくせにデータベースは別個に共有であったため、MySQLの反応が遅く、それがさらにキャッシュ生成の足を引っ張るという悪循環。厳密にはこうなっていた。

「記事を投稿する」

「データベースに書き込む」

「キャッシュファイルがすべて消える」

「キャッシュファイル生成のためにアクセスが来た順番にデータベースを読み込んでキャッシュ生成」

「キャッシュ生成しようにもデータベースが素早く返事をしないので順番待ちが発生」

「順番待ちをしている間にも次々とアクセスが来るのでその間はキャッシュではなく普通に反応を返そうとする」

「キャッシュではないので生成するためにCPUなどを激しく使う」

「しかもそもそもキャッシュ生成のためにデータベースに接続しているのに、そこへ次々とアクセスがやってくる」

「一度に大量に接続できないので反応待ちになって列に並ぶようになっていく」

「列に並んでいる間にも次々とアクセスが来るので列がどんどん伸びていく」

「列が伸びるとさらに反応速度が遅くなる」

というような、典型的な過負荷の状態に突入していた、というわけ。

別のこの期間の間もずっと何もしていなかったわけではなく、サーバの乗り換えを検討するものの、制限の多い専用サーバであったため当時の予算と時間で打てる手がほぼ皆無。そしてもう悠長にしていられない非常事態に直面したのが2013年12月。

◆2013年12月
Uptime:98.84%
Outages:73
Response time:2924ms

グラフで見ると露骨で、あの急激に上昇しているのはみんなで一斉に更新した日ですな……そう、十数人が一斉にログインすると記事を更新していなくてももう耐えられないということが判明。つまりMySQLが遅すぎる&多数の接続に耐えられない。つまり何をしてももう無駄、ここから出て行くしか方法がない!
201312

で、さくらのマネージドサーバからこの時点でついに今まで手を出してこなかったクラウド環境への移行に挑戦することになり、Amazon EC2に乗り換えた最初の結果がコレ。

◆2014年1月
Uptime:99.95%
Outages:1
Response time:2354ms

グラフを見ればわかるように、落ちたのは1回だけで、それも落ちたのではなくてコレはさらにスペックアップのために自分で落としたため。つまり、過負荷ではもう1度も落ちていない、ということ。やたー!また、反応速度も改善しており、かなりいい感じに。
201401

いやー、実に長い道のりであった。

ここまで来るためにさまざまなサーバ関係のあれこれを実行してメモっているので、そのあたりも備忘録から引きずり出して順次公開していくことに決めた。

というのも、2010年1月から現時点までで実に4年以上の歳月をかけて積み上げてきた結果、ins-magazine.netはみんなが想像している以上の規模になっており、なぜ高校のクラブで報道部のようなところがまったく存在しないのか、そしてここまでのものを積み上げて支えるためにはどれぐらいのノウハウが必要かというのがどこにも書かれていないため。

おそらく余所の高校とかでも、ins-magazine.netみたいなサイトを作ろうとしては失敗を繰り返しているはずで、対してins-magazine.netは堅実に歩みを進めている。この差は何かという点を明らかにしていくことで、ほかの高校・中学、あるいは大学などが必要とするノウハウを共有し、同じようなことをしたいと考えている教職員やOB/OGや現役の人たちの参考になれば幸い。

こちらの記事もどうぞ