ワイワイ！これはFluentd Advent Calendar 12日目の記事です。
私は現在、VOYAGE GROUPの子会社であるZucksというところで、Zucks Adnetworkという広告配信サービスを作っています。で、その中でFluentdが活躍しているよーという話をしてみます。事例紹介ってやつです。
Zucks Adnetworkは、いわゆる広告配信サービスです。
広告配信サービスは配信した結果を何らかの形で集約して、よーするにお金がどうチャリンチャリンしてるかを確かめる必要があるわけです。その一つのやり方として、「配信結果を1件ずつ行分割したテキストファイルの出力しておいて、そいつをいい感じにまとめて、数え上げる」みたいな方式があって、つまるところ、私たちはそうやってます。
- 集約されるサーバに負荷が集中する
- 一次的な集計をさせつつ、それをMySQLに突っ込む頻度を調整することでそれなりに乗り切れるはず
- Fluentd的に、out-execのバッファ時間の調整をすればいい
- MySQLにつながらないかも
- いい感じに勝手にリトライしてほしい
- Fluentd的に、out-execにリトライをお任せすればいい
ということで、Fluentdが大活躍しています。こんな感じ。
log file -- in-tail --> Fluentd -- out-exec --> scriptで一次集計 -- sql --> MySQL on RDS
私たちは新しいものなんて非常に怖くて、Fluentdなんか全く信用しないんですよ。最初は。特に今回は広告配信結果の集約、つまり、顧客と金銭のやり取りをする部分に直結する箇所であって、欠損や二重計上などは許されない部分です。いざとなれば、古き良きcrontabに簡単に乗り換えられるよう、Fluentdにあまり依存しないよう、保守的な構成を選んでいます。核となる処理は全てGaucheで書いており、Fluentdを通さずとも実行できます。
そう、Fluentdは単なるログファイルのバッファリングサービスとして使っています。
しかしもちろん、期待通りに動いてくれています。crontabに乗り換える予定はありません。
- out-execはfile bufferを使ってるんだけど、
td-agent stopのタイミングでflushされないらしい - see http://d.hatena.ne.jp/tagomoris/20130123/1358929254
- logの流れを止めてから、
bufferディレクトリが空になるのを確認してtd-agent stopする必要がある - flush-bufferみたいなコマンドを作っておいて、任意のタイミングでstopした後、flushさせる
- mem bufferにする…かなぁ
- 「再試行の待機時間は前回の2倍」仕様が、たまにキツい
- 朝起きたら4時間失敗し続けていた、みたいなケースだと、次の実行が4時間後だったりするので、さすがに待てない
- ので、そのときは手動で対応した
- でももう少し緩やかに増える感じにしたいかなー
みたいなことに困っていますが、まぁちょっと困ってるかなーくらいなので、大した問題ではありません。
私たちの事例の紹介でした。まぁなんだ、普通に使ってます。特別なことは全然していません。が、広告配信の結果やメディアの広告収入については、管理画面上で、10秒程度の遅れで確認できるようになっています。すばらしい。
自分たちにとって新たなミドルウェアを導入するのはしんどい話なので、あまり依存しないような形から導入し始めるのは大事かなーと思っています。
さてこれは、Fluentd Advent Calendar 12日目の記事でした。
明日は私の元"隣の人"で、ここで紹介した事例をともに導入した実績を持つ@bash0C7先生です。抱腹絶倒エントリを期待しましょう。
おお、すばらしい。ありがとーございます！
使ってるバージョンがたぶん少しだけ古いものなので、新しくする必要があるかもしれない。
確認してみます。