id:tagomoris さんにお声がけいただきまして、Fluentd Casual Talks にて「fluentdでWebサイト運用を楽にする」というタイトルで発表させていただきました。
主催者の id:tagomoris さん、会場を提供していただいた DeNA 様、いろいろ準備をしてくださった id:riywo さんはじめ多くの方々、参加してくださった100名以上の皆様、ありがとうございました!楽しかったです。
発表ではここ半年ほど Fluentd を運用して来た経験をお話ししましたが、発表内で触れなかったことで大事(?)なことがありますので以下に補遺をいくつか書いておきます。
MongoDB にログを溜めすぎない方がいいかも
太田さん (@kzk_mover) の発表内でも触れられていましたが、数千万件程度にしておいたほうがいいのでは……という実感です。
発表内で触れた koebu の行動ログ、MTAログなどはメインメモリ 8GB のホストで、それぞれ 4GBの Capped collection (容量を超えた分は投入が古い順から自動的に削除される) に保存しています。
index なども含め、現在データファイルで確保されている総容量が 23GB ほどのシングル構成ですが、これは特に問題なくデータ投入、mongodump によるバックアップ取得ができています。
ところが別のところで、10GB Capped × 4, データファイル 50GB ほどの ReplicaSet 構成を作っていたところ、データ投入に問題はないのですが、レプリケーションの再構築がいつまでたっても終わらないという現象に遭遇しました。
- 複製する側でデータのコピー、indexの再構成は終わる
- その後 100MB/sec ぐらいで disk からの読み込みが止まない
- mongostat でみると locked が 100% になっている
- oplog (mysqlでいうところのbinlog) の実行が全く進んでいないように見える
ログを見た限りではこのような現象で……原因不明のままですが、何度かやり直しても同じ症状で変わらないため、Replica Set での運用は諦めてシングル構成に戻してしまいました。version 2.0.5 です。
またメモリ 4GB、swap 1GBのホストでは、index 再構築時に mongod がメモリを食いすぎて OOM Killer に殺されるという現象も経験しています。
どうも MongoDB のアーキテクチャは mmap でデータ全体を確保する構成のようで、メモリや swap が少ないと大量のデータを扱う際に問題が出そうです。
Sharding については構築したことがないのですが、桑野さんによれば
個人的な完走としては、いまのところmongoに入れる場合は、メインメモリからそれほど大きくならない程度の量でcapped collectionにして古いのを消していくのがいいかなと
同意。なのでそれ以上やりたいならシャード組んでいくしかないけど、insertが大量かつ継続的だとChunkのmigration<Insertになって立ちいかなくなると思います。
ということですし、MongoDB にはあまり大量のログをため込まないようにしたほうがいいのではないか、という印象ですね。
fluentd 内部ログについては undocumented
内部のログが他のメッセージと同様に流通する仕様については、ドキュメントにない、そうです。念のため。