概要
ログの収集にfluentdを利用して一カ所に集めるというよくある構成の場合、
収集するログの量と対象のサーバーのスケールアウトでログの量が急増した時に
ログ転送先がスケールできなかったり下手すると単一障害点になることもあります。
そこで、fluent-plugin-forward-awsで疎結合なログ転送 で、「スケールし、落ちないログ転送先」として紹介されている
各サーバーから直接S3にログを転送し、SQSを使ってログの収集元と収集先を疎結合にする
という方法が良さそうだなあと思ったんです。
しかし、肝心のS3のリクエスト数に制限は無いのかどうか心配になり調べてみました。
S3のリクエスト数の限界
Amazon S3のパフォーマンスをあげるコツ によると、秒間50リクエストを超えるような場合は、この記事中のベストプラクティスに従わないとパフォーマンスが出ないようです。
fluentdを使って毎分定時でアップロードするとなると、1台あたり10個のログを保存するとなると、サーバー5台で同時50リクエストに達してしまいます。
毎分転送はやり過ぎかもしませんが・・・
S3のパフォーマンスを最高にする
Amazon S3のパフォーマンスをあげるコツや、
Request Rate and Performance Considerations に記載されているのですが、
オブジェクト名の先頭の３〜4文字をランダムにすれば良いようです。
例えば、
examplebucket/2013-26-05-15-00-00/host01/apache/access_log
examplebucket/2013-26-05-15-00-00/host02/apache/access_log
examplebucket/2013-26-05-15-00-00/host03/apache/access_log
examplebucket/2013-26-05-15-00-00/host04/apache/access_log
こういうような日付が先頭になる形式はよくやってしまうとおもうんですが、これが最悪なパターンなようです。
改善するためには、以下のように、
examplebucket/0Dke-2013-26-05-15-00-00/host01/apache/access_log
examplebucket/AkqD-2013-26-05-15-00-00/host02/apache/access_log
examplebucket/1T8H-2013-26-05-15-00-00/host03/apache/access_log
examplebucket/vZgR-2013-26-05-15-00-00/host04/apache/access_log
先頭にランダムな文字をいれることで最高のパフォーマンスが得られるようです。
fluentdのS3プラグインは上記のようなハッシュを生成できないため改造が必要です。
面倒なら、ログファイルのIDをハッシュ化して16進を使う方法か、ハッシュをbase64して+,/,=をurlセーフな他の文字に置換する方法を推奨しているようですね。
ハッシュは、rubyだとこんな感じで生成するといい感じで4文字が生まれるのかも
Base64.urlsafe_encode64(Digest::MD5.digest("hogefuga")[0,3])
というわけで
fluentdのプラグインを作らないと・・・