v1.0がリリースされたログ収集のFluentdが目指す「黒子のような存在」とは？
CNCF（Cloud Native Computing Foundation）配下のログ収集のためのオープンソースソフトウェアであるFluentdは、2017年にバージョン1.0がリリースされた。記念すべき1.0というマイルストーンを達成したFluentdのデベロッパーにしてトレジャーデータ株式会社のシニアソフトウェアエンジニア、中川真宏氏にインタビューを行った。
まずリリース1.0の発表ということで1.0とそれ以前のバージョンの違いなどについて教えてください。
トレジャーデータの中川真宏氏
ツイッターなどでも誤解されている方を見かけますが、実は0.14と1.0で中身は何も変わっていないんですね。Fluentdは、0.12という最も広く使われているバージョンと最新の0.14というバージョンがあります。0.12に対して色々な問題を解決するために長い時間をかけて開発されたものが0.14なのですが、そのバージョンが安定してきたタイミングで1.0にしようというのは決まっていました。でも、なかなかタイミングがつかめなくて…… そこでKubeCon+CloudNativeConが開催されるということで、それに合せて1.0としたという感じです。
0.12から0.14へのバージョンアップで、バッファの持ち方や設定の方法などもかなり変えましたが、それに伴うバグも報告をいただいているモノについてはほぼ修正できたので、このタイミングで1.0というバージョンにしました、ということです。
すでに0.14を使っていた人から見ると何も変わっていませんが、「0.xx」という表記だと「まだバグがあるんじゃないか？」と考えるユーザーもいると思います。そこで「ちゃんとエンタープライズでも使ってもらえるようになりました」という象徴的なリリースとして出したというわけです。
FluentdはDockerイメージでも提供していますが、Dockerイメージで使っている人はバージョンアップに対してはとても能動的というか、進んでバージョンアップをしてくれるんですね。そして、実際に色々なフィードバックもいただいています。その人達からも、「もう安定してきた」という印象を持ってもらえていると思います。
CNCFに入ったことで利用の拡大に影響はありましたか？
CNCFに入ってから、ダウンロード数は増えていますね。やはり、Kubernetesの標準になったことの影響が大きく、数百万台という規模だと思います。今回のKubeConでも、ブースに来てくれた中国のエンジニアから「ここで数万台使っているよ」と教えられることがありました。これまであまり把握していなかったユースケースを知ることが、KubeConに出て良かったことのひとつですね。
Kubernetesのログは標準出力に出るので、それを取り込むためにFluentd側で結構頑張らないといけない部分が多くて、そこは皆さんも苦労しているところだと思います。とにかく色々なソフトウェアがログを出すので、フォーマットもバラバラなんですね。だからFluentdとプラグインが評価されていると思います。
CNCF配下のプロジェクトは増えていますが、そのプロジェクト同士で「ログはこうやって出そうよ」みたいな話し合いはされているんですか？
まだそこまでは進んでないですね。プロジェクト間では「インテグレーションをもっと進めよう」といった議論はありますが、ログに関してはまだこれからという感じだと思います。Kubernetesは真ん中にいる存在なので、ログに関してはタマにイシューが流れてくることはあります。
どうしてもOpenStack Foundationと比べてしまうんですが、CNCFの中でコントリビューター同士が議論する場所、OpenStack Foundationだとサミットの中にデザインサミットと言ってコントリビューターが集中的に議論する場所があるんですが、CNCFにそういう仕組みはあるんですか？
CNCFの場合はSIG（Special Interest Group）とWG（Working Group）がそれに当たると思いますね。実際に今回のKubeConの時もブースやセッションの合間にコントリビューター同士で議論はされていましたけど、フォーマルな仕組みというとSIGとWGだと思います。
2015年にトレジャーデータのCTO、太田さんにインタビューした記事では「Fluentdは機能を追加した有償版は作らない」という話でしたが、それは今も変わらないんですか？
参考：「Fluentdをきっかけにビジネスが回る仕掛けがとっても気持ちイイです。」
現在、Fluentdにも有償のEnterprise版がありますが、これの中身はオープンソースソフトウェア版のFluentdと同じで、サポートを提供することがサービスになります。エンタープライズ向けのプラグインがパッケージされていますが、基本のコードは変わりません。
ちなみにFluentdの開発は何人いるんですか？
今は3人くらいですね。あとは外部のコントリビューターがいると言う感じです。
最近、Logstashを作っているElasticのCEOにもインタビューしたんですが、その時にElasticはElastic Stackとしてセットとして提供していきたい、そのほうが顧客の利便性が増す、という発想を語ってくれたんですね。でも日本ではFluentdがすごく浸透しているので、ログ収集についてはFluentdを無視するようなことはしない、と発言していました。そしてElasticはアプリケーションパフォーマンスモニタリングの方向に行こうとしています。Fluentdは、そういう外部のソフトウェアを取り込んでセットにして提供するみたいな発想はないのですか？
今のところはないですね。ログの収集と言っても、これからもっと分散されたアプリケーションが増えてくるとログのソースも増えるわけですし、メトリックスやトレーシングなどの方向に進めば、もっとログの収集を高速にそして柔軟に実行することが重要になってくると思います。ElasticはElastic Stackの中で完結できますけど、Fluentdの場合は連携するソフトウェアがものすごく多いので、変に機能を取り込んでしまってコミュニティが望まない方向に行くよりは、基本的な機能に集中して最終的にはFluentdの姿が見えなくなるぐらいの存在になりたいと思っているんですよ。
システムに入れたら自動的にログを集めて、どんなに負荷が高くなってもログを欠損しない。そういう堅牢性とか高速化とか、そっちに注力したいと思っています。
また、より大規模なシステムに対応するために分散バッファのような仕組みも検討していますが、なかなか難しいんですよね。分散メッセージのプラットフォームであるKafkaが安定するまでにかなりの年数がかかっていることをみても、すごく難しい問題なのだと思います。それにFluentdの場合、色々な構成でシステムの中に置かれるので、分散構成にした時に「こういう構成でないとできません」のような制約がどうしても出てきてしまいます。今のFluentdの使われ方とはだいぶ異なってしまうわけです。なので「シンプルで高速に動く」という部分を保ちながら、もっとそれを極めていくという方向がFluentdの行く道だと思います。
この先のFluentdの向かう先を教えてください。
「メモリー使用量やCPU使用量を抑えて高速に」というのは目標ですが、それ以外にもFluentdのエコシステムを拡大することですね。CNCFのKubernetesや、最近ユーザーが増えているPrometheusのサポートはもっと進めていきたいです。すでにFluentdのプラグインで、FluentdのヘルスチェックをPrometheusで行うなんていうのも出てきていますので、CNCFのプロジェクトとの親和性はもっと上げていきたいです。実際にCNCFに入る前は、トレジャーデータがスポンサーしているオープンソースソフトウェアのひとつとして見られていたFluentdですが、CNCFに入ったことでエンタープライズからも評価されるようになっています。つまりCNCFから認められているので、何かあっても安心という感じですね。
Fluentdの開発とトレジャーデータのビジネスは別であり、CNCFの一員としてコミュニティを重視するという姿勢が垣間見えた中川氏のインタビューであった。Elastic Stackのような独自の組み合わせで提供するよりも、黒子のような存在でありたいというスピリットが言葉の端々から感じられた。
なお、Fluentd 1.0の詳細は、中川氏によるFluentdブログのポストを参照してほしい。
