前半セッション「ログローテートどうしてますか? (運用ノウハウ)」

Rails'Wiki「セッションのタネ」に一行書いてたらセッションのオーナーをおおせつかる。
質問がきっかけのセッションに、ノウハウを教えに来て下さった皆さん本当に有難うございます。

以下にメモを記します。そのとき話されたこと(の記憶)と感想、後で調べたこと (URLなど) が区別なしに混じっています。御免なさい。
運用ノウハウ - 理想未来はどうなった?」も参考にしています(コピーになってるところもあると思います)、有難うございます。

ログローテート

普通に UNIX系のログローテートの仕組みで大丈夫。Rail稼動中だからどうしたとか気にしないで大丈夫。ただ、HUP は必要、Railsに新しいログファイルを教えてあげる、ローテートスクリプトの最後にでも。
Mongrel 複数稼動中でも問題起きた事ない。
Rails にもその様な仕組みはある (参考: ADWR2, p.585, 27.7, ログファイルの扱い) けどそういう複数稼動とかでは変な感じがあるので使わないとか。
ログレベルは Fatal くらい、もっと詳しくするとログファイルが大きくなり過ぎるし遅くなるし。
syslog に飛ばしたり、FreeBSD で mysyslog 使ってるとか。
公開サービスなら「Google Marketing Platform - Unified Advertising and Analytics」使う手もあり。

ウェブサーバー

現状では Mongrel、スケーラビリティ考えても。
開発時から Mongrel、というか development と production でそこまで環境変わるの良くないよね。(「開発時 Rails(Ruby)同梱の Webrick 使い、運用でウェブサーバ変えるとかありか?」に応えて)
FastCGI (lighttpd) もあるよ、でもちょっと高負荷時の安定性にかけるかも。
gem で「Thin - yet another web server」というのがあって有望かも、まあ、これから。
負荷テスト(下記)とスケーラビリティ考えると現状では Mongrel ということになるみたい。

負荷分散

http://d.hatena.ne.jp/pcmaster/20080420/p2#p2 中ほどの図参照。
高いけど(数百万円から)「BIG-IP」(F5) 使う、同時数百接続とか普通にこなす。そして二台並列とかすれば可用性も。
あるいは「LVS(http://jlvs.infoscience.co.jp/)」とか。
結局はコスト、そういうの分かってて出来る人は人件費かかるので箱もので済ませるというのもいい。

負荷テスト

http://www.webload.org/the-webload-project.html」シナリオきめてアクセスしてテスト。
http://www.empirix.co.jp/web_app/web_test/e_load.html」なんかも。
テスト機は実際多数のリクエストを出すので凄くしっかりしたマシンじゃないといけない、スレッド一杯起てて同時接続多数出すんだから。多数のテスト機を用意してみたり。
きちんとテストして、エビデンスを以って提案する。

OS

あんまり人数いなかったからか、余り分散しなかった。

データベース

Oracle は信頼性高いし何でも出来るけど、高い。分散DBみたいな構成も出来て凄いんだけど、そこまでするとライセンス大変。

MySQL のインストールで、初期状態でルートユーザで何でも出来ちゃう件。
一般的なデータベースの使用形態としては危ないのかもしれないけど、ウェブアプリケーションを運用する際にウェブアプリがそう言う風にアクセスするだけならまあいんじゃないか。RailsMySQLを使う設定だと「ルートユーザで何でも」を前提にしたプログラミングになってる。

また、どのデータベースソフトも、初期設定ではかなり貧弱な環境でも動くような設定になってるので、運用時には調整必要。

上記負荷テストなんかすると、すぐにデータベースがネックになったりする。データベースのスループットを上げないといけない。クラスタリングして参照系を分散したり。
そうするとデータベースプロクシ(みたいなもの)の安全性が問題になるんだけど、各アプリケーションサーバに仕込んで夫々ローカルのデータベースを見に行ってるつもりになるという構成もある (http://www2b.biglobe.ne.jp/~caco/pgpool/)

バックアップ

データベースのバックアップ。まあ、一日一回バックアップとってネットワーク経由で違うマシンに保存かな。

データ保全の確実性を求めるときりが無くて、ストレージの安全性とかになって、NAS とか SAN とかになって、高価な機器は沢山あります。

コストと兼ね合いでどのくらいの確実さを求めるか考える事になる。

グラフ

Ruby/GDChart プロジェクト日本語トップページ - OSDN」というのがあって、Ruby で図を書く事ができる、いろんな種類のグラフ。描画ライブラリ GD を使って、グラフを書く GDChartRubyラッパー。日本語も通る。
で、時どき Rubyごと Rails落ちる。どうしよう?

Rubyの Cで書かれた系の拡張ライブラリはそんな感じで信用できないので注意必要、メモリリークとか。

他のグラフィックライブラリ「http://cairo.rubyforge.org/」「RMagick」の話しも出たけど、描画そのものじゃなくて、チャートやグラフを書く部分を自分で書くのは大変。
Google Chart」は日本語通らないっぽい。

Ruby/GDCahrt の呼び出しを別プロセスにする。そういうコマンド作って exec するとか。

監視

上記のように Ruby/Rails は何も言わずに落ちてることがあるので、プロセス監視は必須。

http://god.rubyforge.org/」(sudo gem install god) なんか良いです、監視ソフト。落ちてたら起動してくれたり。

http://www.fiveruns.com/Rails の監視、サーバ一つ数十弗/月。

統合システム運用管理 JP1:日立」こんなのも。

OS というかサーバ自身の監視をするのは当然。その上で上記のように Railsプロセスの監視をする。サーバの監視はいろいろ、メーカーの提供するツールなんかもある (HP Lights-Out、Dell OpenManage、OSX サーバモニター、とか)。

そして Rails のプロセス監視は自機で、それ以外に他機から http GET で stats=200 を確認。

SNMP で各種ネットワーク機器を監視 (SNMP対応という機器は見るけど、実際やっててる人周りにいないなあ -> 普通にやってますよ普通に。)

デプロイ

Subversion」使ってどうでしょう。

その他

XServeAppleだけあって(無駄に)カッコ良い。

随分忘れちゃってる所も多いような気がするし、そのときのニュアンスを全然汲み取れてないと思います。ご容赦下さい。