[fluentd] #Fluentd Casual Talks で「fluentdでWebサイト運用を楽にする」話をしてきました

id:tagomoris さんにお声がけいただきまして、Fluentd Casual Talks にて「fluentdでWebサイト運用を楽にする」というタイトルで発表させていただきました。

主催者の id:tagomoris さん、会場を提供していただいた DeNA 様、いろいろ準備をしてくださった id:riywo さんはじめ多くの方々、参加してくださった100名以上の皆様、ありがとうございました！楽しかったです。

発表ではここ半年ほど Fluentd を運用して来た経験をお話ししましたが、発表内で触れなかったことで大事(?)なことがありますので以下に補遺をいくつか書いておきます。

太田さん (@kzk_mover) の発表内でも触れられていましたが、数千万件程度にしておいたほうがいいのでは……という実感です。

発表内で触れた koebu の行動ログ、MTAログなどはメインメモリ 8GB のホストで、それぞれ 4GBの Capped collection (容量を超えた分は投入が古い順から自動的に削除される) に保存しています。

index なども含め、現在データファイルで確保されている総容量が 23GB ほどのシングル構成ですが、これは特に問題なくデータ投入、mongodump によるバックアップ取得ができています。

ところが別のところで、10GB Capped × 4, データファイル 50GB ほどの ReplicaSet 構成を作っていたところ、データ投入に問題はないのですが、レプリケーションの再構築がいつまでたっても終わらないという現象に遭遇しました。

ログを見た限りではこのような現象で……原因不明のままですが、何度かやり直しても同じ症状で変わらないため、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 にはあまり大量のログをため込まないようにしたほうがいいのではないか、という印象ですね。

内部のログが他のメッセージと同様に流通する仕様については、ドキュメントにない、そうです。念のため。

ぼかしたいところに、ブラウザのユーザCSSで以下のルールを適用しています。

 .bokasitai {
   color: transparent;
   text-shadow: 0 0 10px #333;
 }

文字色透明 + text-shadow (画面にはこっちが見えている) ということですね。

あくまで CSS で見た目をぼかしているだけなので、HTML source には元の文字がばっちり書かれています。お気をつけください。