2012年05月04日
unkarの構成を変更して応答速度を向上させました
unkarの応答速度が遅くて、2chへのアクセスが多い時間帯にスレッドを取得できず、dat落ちと表示されてしまう事が多々ありました。
そこで、GW中の暇を使ってunkarの構成を見なおしてみました。
応答速度が遅くなる原因と対策
unkarでは、スレッドにアクセスされた際にその場で2chからデータを取得して表示しています。
dat落ちが判定されたスレッドや1000まで達したスレッドは2chにアクセスせずにunkarに保存されたキャッシュを返すため高速に処理できていますが、dat落ちしていないスレッドについては2chへのアクセスが発生してしまうため、2chの応答に引きずられてunkarの応答も遅くなっていました。
2chの応答速度ですが、普通の2chブラウザを使用している方なら分かると思いますが、2chのサーバが不調でもない限り高速です。
それなのに、なぜunkarの応答速度が遅くなってしまうかというと、unkarが基本的にバーボンハウス送り*1にされており、バーボンハウス送りにされている最中にデータを取得することができる2chのキャッシュサーバ（bg20サーバ）が重いからです。
2chのキャッシュサーバは、リクエストをしてから応答が帰ってくるまでに10秒近くかかることもざらにあります。
普通の2chログ保存サイトのように2ch全体をクロールしてログを保存する方式ならば、クローラーを裏で動作させるため、キャッシュサーバの応答が遅くてもサイトの応答速度には影響はありません。
unkar等のビューアを名乗っているサイトには、キャッシュサーバの応答の遅さは致命的で、サイトの応答速度そのものが遅くなってしまいます。
応答速度が遅くなるのを解消するためにはキャッシュサーバを使用しないのが一番です。
そのためには、単純に2chへのアクセス数を減らして、バーボンハウスに送られないようにするか、2chにアクセスするサーバを分散して、2chのバーボンハウスを判定する機能を誤魔化すかの2択になります。
今回、unkarでは、後者寄りの方法を取ることで、キャッシュサーバをなるべく使用しないようにする変更を行いました。
構成について
アメリカ側のサーバはAmazonEC2、日本側はさくらインターネットを利用しています。
今までの構成
| サーバ種類 | 台数 | スペック |
|---|---|---|
| WEBサーバ(unkar.org) | 1 | AmazonEC2 c1.xlarge |
| WEBサーバ(file.unkar.org) | 1 | さくらインターネット 2CPU8Core 12GBメモリ |
| DBサーバ | 1 | AmazonEC2 m2.xlarge |
unkarでは、サーバを3台使用して、スレッドの表示とスレッドタイトル検索を提供していました。
2chにアクセスするサーバは1台しかないため、キャッシュの仕組みを強化することで2chへの無駄なアクセスを減らし、1秒でもバーボンハウスに送られないようにする対策を行って来ました。
これからの構成
| サーバ種類 | 台数 | スペック |
|---|---|---|
| WEBサーバ(unkar.org) | 1 | AmazonEC2 c1.xlarge |
| WEBサーバ(file.unkar.org) | 1 | さくらインターネット 2CPU8Core 12GBメモリ |
| DBサーバ | 1 | AmazonEC2 m2.xlarge |
| プロキシサーバ（串） | 6 | AmazonEC2 c1.medium |
今回、プロキシ専用のサーバを6台追加*2して、そのサーバに2chへのアクセスを代理で行なってもらう事により、unkar全体がバーボンハウスに飛ばされないように調節しています。
プロキシサーバを6台も追加していますが、全ての2chへのアクセスをプロキシサーバ経由で行なっているわけではなく、検索ロボットなどの人間が操作していないと思われるアクセスについてはキャッシュサーバを経由しての情報の取得を行なっています。
unkarではunkar.orgのみのリクエストで一日400万程ありますが、アクセス解析結果のPVとしては150万程度なので、人間のアクセスのみに限定するだけで、2chへのアクセス自体をかなり少なくすることができています。
追加したサーバは全部AmazonEC2で動作しており、今はとりあえずハイCPUミディアムインスタンス(c1.medium)で動作させています。
64bitOSに最近対応したそうなので、64bitで動作させたかったのですが、Status Checksが完了せず正常に動作しなかったため、32bitを利用しています。
稼働している様子を見ていると、すごく忙しい時でも1サーバあたり秒間3リクエスト程度のアクセスしかないため、処理内容的にマイクロインスタンスでも問題はないかもしれません。
マイクロインスタンスに置き換えが出来れば、同じ料金で8倍の数のサーバを運用できるので、このあたりは少しずつ調整してみます。
また、今はプロキシサーバが6台固定ですが、AmazonEC2が提供しているロードバランサの仕組みを利用して稼働中に台数を可変できるようにしていきたいと思っています。
ロードバランサを使ったインスタンスの自動起動をうまく制御出来れば、バーボンハウスに送られたサーバを自動で切り離して*3、新しいインスタンスに置き換えることが可能になるため、2chのキャッシュサーバを利用しない運用が可能かもしれません。
まあ、面倒ですし2chからAmazonEC2がまるごとアク禁にされると思うのでそこまではやらないです。
プロキシサーバについて
下記の条件を満たしたソフトウェアを探すのが面倒だったので、WEBサーバの勉強という名目で自作しました。
https://github.com/tanaton/salami
nginxとかSquidの設定を弄るだけで良かった気もします。
Go言語で書いてあります。
2ch時間検索について
話は変わりますが、2ch時間検索というサービスで使用していたDBサーバを解約しました。
理由としては、月に100PV程度しかないサイトなのにDBサーバ（MySQL）の維持費が5万円程かかっており、誰がどう見ても非常に無駄な状態だったからです。
借りていたDBサーバは16GBメモリを積んだ2CPU8コアのサーバだったのですが、この規模のサーバでも2ch時間検索の無駄にでかいDBの検索にはスペックが足りていなかったようで、ちょっと範囲指定をしただけで時間がかかっていました。
一応、移転先として、月額2万円以下で64GBメモリなサーバを用意したので、そちらにDBをまた一から構築してサービスを再開するつもりです。64GBメモリのサーバですが、現状で30億レコード以上、インデックスサイズが50GB以上に達したMySQLを高速に検索できるかは不明です。
DBにデータを挿入する作業に数週間かかるので、復旧は6月くらいになると思います。
金銭的にまずくなってきた場合には真っ先に停止させるつもりなので、よろしくお願いします。