Help us understand the problem. What is going on with this article?

fluent-plugin-s3 の hex_random プレースホルダー

More than 3 years have passed since last update.

Advent Calendar に書くネタを作ろうと思っていたのですが、風邪を引いて週末なにもできなかったので、ちょっと前に fluent-plugin-s3 に入れたオプションについて書いてお茶を濁します ^^;

fluent-plugin-s3 v0.6.0 に hex_random というプレースホルダーが追加されています。

リクエスト率およびリクエストパフォーマンスに関する留意事項

Amazon S3 に リクエスト率およびリクエストパフォーマンスに関する留意事項 というページがあります。

それによると、

examplebucket/2013-26-05-15-00-00/cust1234234/photo1.jpg
examplebucket/2013-26-05-15-00-00/cust3857422/photo2.jpg
examplebucket/2013-26-05-15-00-00/cust1248473/photo2.jpg
examplebucket/2013-26-05-15-00-00/cust8474937/photo2.jpg
examplebucket/2013-26-05-15-00-00/cust1248473/photo3.jpg
...
examplebucket/2013-26-05-15-00-01/cust1248473/photo4.jpg
examplebucket/2013-26-05-15-00-01/cust1248473/photo5.jpg
examplebucket/2013-26-05-15-00-01/cust1248473/photo6.jpg
examplebucket/2013-26-05-15-00-01/cust1248473/photo7.jpg    
...

のように、キー名を連続するパターンにすると、パフォーマンス上の問題が発生します。とあります。

この問題を避けるには、例えば 16 進のハッシュプレフィックスをキー名に追加すると良いと述べています。

examplebucket/232a-2013-26-05-15-00-00/cust1234234/photo1.jpg
examplebucket/7b54-2013-26-05-15-00-00/cust3857422/photo2.jpg
examplebucket/921c-2013-26-05-15-00-00/cust1248473/photo2.jpg
examplebucket/ba65-2013-26-05-15-00-00/cust8474937/photo2.jpg
examplebucket/8761-2013-26-05-15-00-00/cust1248473/photo3.jpg
examplebucket/2e4f-2013-26-05-15-00-01/cust1248473/photo4.jpg
examplebucket/9810-2013-26-05-15-00-01/cust1248473/photo5.jpg
examplebucket/7e34-2013-26-05-15-00-01/cust1248473/photo6.jpg
examplebucket/c34a-2013-26-05-15-00-01/cust1248473/photo7.jpg    
...

より詳しくは、リンク先を参照してください。

hex_random プレースホルダ

fluent-plugin-s3 の hex_random プレースホルダを使う事で、16進のハッシュプレフィックスをキー名に追加することができます。例えばこんな感じ。

   s3_bucket examplebucket
   s3_object_key_format %{hex_random}-%{path}.jsonl.gz
   path %Y-%m-%d-%H-%M
   hex_random_length 4

こうすることでリクエスト率およびリクエストパフォーマンスに関する留意事項に書いてある方法を利用することができ、パフォーマンスを改善できます。

file buffer chunk の unique id として使う

実はその他の使い方もあります。

retry しても値が変わらないように hex_random の値は file buffer の tsuffix から取り出しています。file buffer に16進数の文字列がついているのをみたことがあるでしょうか?あれです。

buffer/foo.bar.baz.test.b50b56bd280da5547.log

この tsuffix の値を reverse したものから、先頭 hex_random_length (デフォルト4) 文字取り出したものを hex_random として利用しています。なぜ、reverse しているのかというと、tsuffix の値は (time_sec, time_usec, rand) のように生成されており、4文字取り出すような処理をする場合、後ろから取り出したほうがランダム性が高いからです。

さて、hex_random_length 16 とすると tsuffix 全体を取り出せるので(正確には reverse していますが)、file buffer chunk の unique id として使うことができます。

間違った retry が発生しても、同じ file buffer chunk ならば値が変わらないので、重複チェックに利用できます。

なお、uuid_flush というプレースホルダもありますが、あちらは、flush の度に値が変わるので、retry されると値が変わってしまい、冪等性を保てません。

おわりに

unique id として使う場合は、hex_random という名前がそぐわないのですが、すでに hex_random として実装したものを再利用しているだけなので、そのままにしています。そんな使い方もできますよ、という話でした。

sonots
A Ruby, Fluentd, and Chainer Committer. SRE Engineer. Qiitaは小ネタの投稿場所として利用しています。業務コードで、なぜそういう書き方をしているのか解説をQiitaに書いて、コードにはQiitaへのリンクを張る、という使い方をしていることが多いです(自己紹介じゃない)
https://medium.com/@sonots
zozotech
70億人のファッションを技術の力で変えていく
https://tech.zozo.com/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away