AWDwR "Chapter22 Deployment and Scaling" つづき

ruby rails

帰省先から書いてます:-)。

Scaling: The Share-Nothing Architecture

Railsアプリケーションをスケールする際のコンセプトがShare-Nothing Architecture。Share-Nothing Architectureにより状態の管理をWeb層やアプリケーション層でなくデータベースやネットワークドライブのような下位層で行えば良くなり、アプリケーションを複数のサーバ上で実行することが簡単になる。このShare-Nothing Architectureを実現するためにはセッション、キャッシュそしてアップロードファイルなどのデータをどう扱うかを考える必要がある。

まずセッションだけど、セッションデータはデフォルトではテンポラリディレクトリにファイルとして保存されている。しかし全てのサーバが同じセッションデータにアクセスしなければならないので、共有されているネットワークドライブに保存するようにするというようなことをしなければならない。しかしこれにはもっと良い方法があって、それはActiveRecordStoreというデータベースにセッション情報を保存する方法。これを使う場合はconfig/environment.rbまたは各環境の設定ファイルに以下のように設定する。

ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS[:database_manager] = CGI::Session::ActiveRecordStore

他にもDRbやmemcachedに保存する方法がある。

一方、キャッシュはセッションと違っていろいろなサイズのファイルができるし、1ユーザ当たり多くのファイルができるので、データベースに保存するのは適さない。しかし、複数のサーバを使用する場合はローカルにキャッシュのファイルを保存することはできないので、ネットワークドライブを使用する必要がある。ファイルベースのキャッシングはconfig/environment.rbまたは各環境の設定ファイルに以下のように設定する。

ActionController::Base.fragment_cache_store = ActionController::Caching::Fragments::FileStore.new("#{RAILS_ROOT}/cache")

このキャッシングはアクションのキャッシングとフラグメントのキャッシングのみで有効で、ページのキャッシングはpublicディレクトリに保存する必要がある。なので、複数のサーバを使用する場合はpublicディレクトリにネットワークドライブをシンボリックリンクする。

Finding and Dealing with Bottlenecks

パフォーマンスチューニングの第一のそして最も重要なルールは計測なしに行わないこと。そして第二のルールは計測なしに行わないこと。パフォーマンスを改善するにはボトルネックに注目する。このボトルネックを見つける最も簡単でアプリケーションに影響を与えない方法はproduction.logをtailコマンドで見ること。これによりアプリケーションが内部で何をやっていて、どのくらいの時間がかかっているかを知ることができる。

ボトルネックが見つかったら、今度はチューニングの基準を計測し、それに基づいて調整を行なう。Unixには2つのパフォーマンス計測ツールがあって、その一つがab(Apache HTTP server benchmarking tool)で以下のようにして使う。

ab -c 9 -n 1000 http://www.foo.com/controller/action

このabは同じに1アクションしかテストできないので、もっと現実的なストレステストを行いたい場合はsiegeを使いましょう。

Case Studies: Rails Runing Daily

以下では実際の3つのアプリケーションが直面した問題を紹介するよ。

Basecamp by 37signals (www.basecamphq.com)

Basecampは何万人ものユーザに使われているプロジェクト管理アプリケーションで、RailsはこのBasecampで生まれた。

Basecampはデュアル2.4GHz Xeon、2MBメモリのマシン上で15個のFastCGIプロセスと50から100個のApache 1.3.xプロセスが動作している2つのWeb/アプリケーションサーバによって、1日約40万リクエストを処理している。しかし、マシンのロードは通常0.5から1.5程度。

MySQLのサーバは他の2つのアプリケーション(Ta-da ListとBackpack)で共有されていて、最大50万行のテーブルを持っている。このMySQLは3つのアプリケーションから利用されているが、ロードは0.1から0.3の間で、ボトルネックにはなっていない。

43Things by the Robot Co-op (www.43things.com)

43thingsは自分の夢や目標をシェアするサービス。

キャッシュは主にmemcachedに保存される。セッションもmemcachedに保存されるので複数サーバ間でセッションを共有できる。また処理の重いデータベースの検索もActiveRecordのオブジェクトとしてmemcachedに保存している。

43thingsはデュアル3GHz Xeon、2MBメモリを持つ、2台のアプリケーション/Webサーバと1台のデータベースから構成されており、1日約20万リクエストを処理している。それぞれのApache 1.3.xプロセスは25個のFastCGIプロセスを走らせている。サーバのロードが0.3を超えることはめったになく、CPUのアイドル時間も通常80%を超えている。

Mortgage processing engine (www.rapidreporting.com)

(RapidReportingって何やってるの?)

アプリケーションはデータベースにPostgreSQL、Webサーバとしてlighttpdを使用していて、IPトンネリングによるバーチャルサーバの後ろで1アプリケーションサーバ当たり10個のFastCGIプロセスが動作している。こうすることによってWebサーバを再起動することなくFastCGIを追加したり取り除いたりできる。


読了!　うっ、間に合わなかったよ…。