プラグイン開発者から見るv1.0 の活用法 @joker1007 (Tomohiro Hashidate)

self.inspect @joker1007 Repro inc. CTO やってること DB のスキーマ改善、データ仕様の変更 fluentd を中心にしたデータフローの設計構築 Bigquery やhive, presto を使ったバッチフローの設計構築 インフラのコード化とメンテ Docker, ECS の利用環境を整備 外向きの技術発表 最近、ハンター業が忙しい

fluentd との関わり 一昨年ぐらいから社内でデータフローを構築する基盤として 採用 それまでは余り触ってなかった ちょうど0.14 が出たぐらいの時期 主にアプリデータをBQ とS3 に転送するために利用している 0.14 には比較的早めにアップデートして利用を開始 現在1.0.2 、そろそろ上げたい docker で運用している

プラグイン開発とメンテナ業 使い始めると色々と不満が出てくるので、PR を出したり自分で作 ったりすることになる。 割とメンテを諦めているプラグインがいくつかあるようなので、 PR を何度か出した上で、話をしてコミット権を頂くことになった ものがいくつか。 fluent­plugin­cloudwatch­put ( 作者) fluent­plugin­filter­single_key ( 作者) fluent­plugin­bigquery ( メンテナ) fluent­plugin­remote_syslog ( メンテナ) fluent­plugin­dd ( メンテナ) その他、PR 出したりしたものがいくつか。

fluent­plugin­bigquery メインで触る人が転々と移り変わって、今私が良く弄っている。 いかつい 複雑 総ダウンロード数が多い 開発する上で知見をいくつか獲得したので、その辺を元に話を。 そういえば、さっきv1.2.0 の話でretry 方法の改善案が上がってて期 待している。 現在、 r e t r y _ s t a t e _ c r e a t e という内部API を読んで強制中断して いるケースがある。

プラグイン開発者から見たv1.0 の利点 parser, formatter, buffer が明確に分離され、 config セクションとして独立したこと 今迄、input やoutput プラグインの中でフラットに設定が記述され ていて、標準的なやり方が無かった。 v1.0 になることで、それらを選択設定する方法の標準ができたの で、各プラグインに対するポータビリティがめっちゃ向上した。 filter で頑張って加工したりmixin を突っ込まなくても、データの入 出力に任意のフォーマットを利用できる。

プラグイン開発者がやるべきこと 独自のパース処理やフォーマット処理ではなくplugin helper を利用 する f o r m a t t e r _ c o n f i g = c o n f . e l e m e n t s ( " f o r m a t " ) [ 0 ] @ f o r m a t t e r = f o r m a t t e r _ c r e a t e ( u s a g e : ' o u t _ b i g q u e r y _ f o r _ l o a d ' , c o n f : f o r m a t t e r _ c o n f i g , d e f a u l t _ t y p e : ' j s o n ' ) d e f f o r m a t ( t a g , t i m e , r e c o r d ) @ f o r m a t t e r . f o r m a t ( t a g , t i m e , r o w ) e n d

v1.0 のoutput プラグイン開発 最も大きく機能が変わったのがoutput プラグインのAPI metadata を利用したchunk をサポート これによりTimeSliced の区別が無くなる delay commit のサポート chunk_limit_records のサポート 加えて各種プラグインヘルパーにより開発がとても楽になった。

chunk with metadata v1.0 からmetadata をキーにしてbuffer chunk を分けられる様になっ た。 metadata とは以下のものを差す。 tag time record のproperty そして、キーに利用したメタデータはconfig 上でplaceholder として 利用可能になる。

fluent­plugin­bigquery の例 < m a t c h b q . { h t t p _ l o g s , a p p _ l o g s } > @ t y p e b i g q u e r y t a b l e $ { t a g [ 1 ] } $ % Y % m % d s c h e m a _ p a t h s c h e m a s / $ { t a g [ 1 ] } . j s o n < b u f f e r t a g , t i m e > t i m e k e y 1 d < / b u f f e r > < / m a t c h >

プラグイン側の対応方法 p l a c e h o l d e r _ v a l i d a t e ! と e x t r a c t _ p l a c e h o l d e r s を利用する p l a c e h o l d e r _ p a r a m s = " p r o j e c t = # { @ p r o j e c t } / d a t a s e t = # { @ d a t a s e t } / . . . 省略" p l a c e h o l d e r _ v a l i d a t e ! ( : b i g q u e r y , p l a c e h o l d e r _ p a r a m s ) p r o j e c t = e x t r a c t _ p l a c e h o l d e r s ( @ p r o j e c t , c h u n k . m e t a d a t a ) d a t a s e t = e x t r a c t _ p l a c e h o l d e r s ( @ d a t a s e t , c h u n k . m e t a d a t a )

metadata とplaceholder によりforest プラグインが 不要になる ただし、どの項目でplaceholder が利用できるかは プラグインの対応状況によって変わる プラグイン開発者は使えそうな所にガンガン placeholder サポートを追加して欲しい

helper によるデータ加工方法の共通化 よく利用する処理がplugin helper として再利用可能になり、config の項目も標準化されたため、プラグインでのデータ加工が簡単に なった。 利用しやすいものは以下。 extract ( レコードからタグや時間として利用するものを抽出す る) inject ( レコードにタグやタイムスタンプ等のメタデータを注 入する) record_accessor ( レコードの中のデータを文字列のフォーマ ットを利用して取得する) これらを利用することで、プラグイン独自に対応しなければいけ ない範囲はかなり少なくなる

新しいプラグインのAPI を利用することで、かつて 利用されていたmixin モジュールの大半は不要にな ったり、似た設定や実装が氾濫することがなくなる

その他プラグイン開発で意識すること 多機能化はダメ絶対！ fluent­plugin­bigquery は悪い例 私がload とか追加してしまったので、整理したい…… 組込のhelper やその組み合わせで解決できないか考える thread や子プロセスを利用する場合のハンドリング等 大分便利になってるので、plugin_helpers 以下は一通り読 んでおくと良い 無理にマルチバージョンサポートをしない 0.12 系はそろそろ機能追加等を打ち切って良いと思う 設定の互換性は維持できても、同一のコードベースでは placeholder 等が使えない どうにもメンテできない場合は、人に譲る

まとめ v1.0 は開発者にとってめっちゃ便利になってる！ まだ0.12 系を利用しているなら、頑張って上げる価 値がある 特にプラグイン自体の構造をシンプルに維持したま ま柔軟性を上げられる点が大きい 自分のプラグインの改修や、PR を出すチャンスも