2013年4月に新卒でとある中小SIer会社に入社し、前年に発足したばかりのビッグデータチームに配属された私はそこでトレジャーデータを初めて知ることとなった。 その後、紆余曲折があり、2023年時点もトレジャーデータで働いています。このシリーズでは、私の社会人生活においてずっと関わっている、トレジャーデータの様々な機能や歴史について備忘録として残していきます。(注意: 個人の記憶を思い起こして書いてるだけなので、実際と異なる可能性がある点を注意ください。）
記事一覧: 私とTreasureData カテゴリーの記事一覧 - Secret Ninja Blog
Fluentd
Fluentdについて知らなければFluentd実践入門をまず読みましょう。
私自身は、トレジャーデータのサポートエンジニアとして、トレジャーデータだけでなくFluentdのサポートも提供しつつ、さらにはFluentdを取り巻くOSSコミュニティに対するサポート（たぶん）も経験しました。記憶がある限りではTD関係者が主催するようなfluentdのイベントに参加したり開催のお手伝いをしたり、そのほかのイベントでも機会があればFluentd関連の発表もしたように思います。（世界で一番初めに日本語でFluent Bitについて発表したに違いない。）
- 20140928_fluentdで非構造化データとゆるふわっと戯れる会 | PPT
- Check your fluentd before log analytics (2015-10-15) | PPT
- IoT Data Connector Fluent Bit | PPT
仕事の上では、TDの顧客向けにtd-agentのアップデート方法を書いたり、fluentdの不具合調査したり、色々した気もします。そんなわけで、この記事ではFluentdの思い出を書いていきます。
トレジャーデータとFluentd
Fluentdは当初、トレジャーデータサービスにてデータの取り込みから解析までエンドtoエンドでサポートするためのログコレクタとして作られました。そのため、トレジャーデータが起業した同年の2011年6月*Tags · fluent/fluentd · GitHub)にFluentd自体もリリースが行われています。
トレジャーデータがデータ管理のサブスクリプション型のSaaSビジネス（現在は、Customer Data Platform）を行う上で、キラーソリューションとしてFluentdというOSSを一部に添えたクラウドサービスを提供するというビジネスモデルをとりました。
Fluentd に Treasure Data がコミットする理由 | Kazuki Ohta's Space
Fluentdとトレジャーデータの関係性は少し特殊だけど素晴らしいと思っています。世の中の流れで見ると、Elasticsearch (OSS) -> ElasticCloud (SaaS)、 Apache Kafka -> Confluent Cloud 、というようにOSS版とSaaS版の両方を出すというビジネスモデルが主流ですが、こうした企業の多くはAWSなどのビッグテックによる同じOSS製品による競合サービスとの戦いが行われ、コードのライセンスを変え、類似のコードが作られ、エンドユーザの世界観としてはどんどんカオスとなっているように思います。
一方で、トレジャーデータの場合は、Fluentd (OSS)でそのデータの送り先は自分たちの競合製品だっていいよ、という構造になっており、対立関係になっていません。これは、データを手軽に正しく集められる世界を作る、という思想が色濃く反映されており、個人的にはとても好きな構造になっています。この構造が現在のOSSビジネスの問題を解決するわけではないですが、一つの新しい形として今後も利用できるでしょう。
ロゴも変わった
2016年ごろには、CNCF (Cloud Native Computing Foundation)にFluentdが参加するといった活動もあり、マーケティング活動の中で多く資料にFluentdのロゴを利用していました。
そうした中で、2016年にはロゴが変更するということもありました。
昔のロゴ:
現在のロゴ:
私は、どちらのロゴも愛着がありますが、昔のロゴは白地だったために、スライドに貼った時に認知しずらい問題があり、現在の形の方がみやすいですね。
Fluent Bit
Eduardo(https://twitter.com/edsiper)というナイスな開発者がトレジャーデータに入社したのは2015年ごろだったと思います。彼はOracleでLinux周りの開発者をしてたり、Monkey HTTP Server(GitHub - monkey/monkey: Monkey HTTP Server)というOSS開発を過去にしていました。彼のすごいところは、FluentdのOSS活動推進、例えばLinux FoundationのCNCFの参加だったり、Fluentdの利用ユースケース拡大のためにFluent Bitを0から実装してとドキュメントを一人で全部してしまうというのを一年くらいでやってのけたことだろう。
とはいえ、さらっと世の中にリリースされた後に顧客から普通に問い合わせが来るもんだから大変だった。全く別のC言語実装なのに名前が似ているから同じでしょ感で聞かれてもなんもわからんし、Fluent Bitを知っていたのはEduardoしかいないからやはりなんもわからん・・・状態だったわけです。
当初はIoT向けにするためにC実装にしていたはずなんですが、IoTではログコレクタ自体はそんなに流行らず。しかし、Fluentdのマーケットを活かしつつ、Fluentdのフットプリントの大きさから苦手領域だったコンテナのエコシステムの中で上手く生きる道を作ることができました。その結果、AWSのFireLensやGoogle Kubernetes Engine (GKE)のデフォルトのログプロセッサとして利用されるまでになりました。
Fluentd Enterprise Support
トレジャーデータのビッグデータビジネスが、Google BigQuery / Amazon Redshiftなどの競合出現によってチャレンジを迎えている最中、トレジャーデータには二つの方向性がありました。一つ目がCDPにリブランディングにしていく、もう一つ目がFluentd Enteprise Supportです。今現在は、CDPへの舵取りが大いに成功だったと言えますが、Fluentdのマーケットを活用したサポートとそして専用のSaaSを提供するというものも2016年ごろには考えられていました。
しかし、CDPのビジネスが順調だったこと、そしてエンタープライズサポートのビジネスの伸びにも問題があり、このサービスの提供は途中で終了することになりました。このときのFluentd EnterpriseのビジネスのPdMだったAnuragとメインエンジニアのEduardoが、現在はCalyptiaというFluentd/FleuntBitを含めてObserbilityのSaaS企業を立ち上げて自分たちでビジネスを行っているのもまた感慨深いですね。
今後のFluentd/Fluent Bit
Fluentdがリリースされ、11年の時を経て、現在Fluentdの開発はトレジャーデータの手から離れ、クリアコードさんを中心にコミュニティベースでの開発する体制にかわっています。
そしてついに、td-agentというパッケージ名をやめて、fluent-packageとしてv5がリリースされことになりました。
これからもfluentdは、クリアコードさんを中心として開発が進められていきますし、コミュニティのパワーでメンテナンスがされていくでしょう。
Fluent BitについてはCalyptiaを中心として開発が行われています。また、Calyptia自身でもFluentd向けのパッケージを作っており、Fluentdに対してもコントリビューションをしていくでしょう。
今後もまだまだニアリアルタイムのニーズは多くあり、Fluentd / Fluent-Bitをデファクトとしたソリューションがでてきたり、もしくは全く新しいソリューションがでてくるかもしれません。 Fleuntdという伝書鳩がどんな未来を運んでいくのか引き続き楽しみですね！
おわりに
人生で初めて深く関わったOSSがFluentdだったため、そのコミュニティ・OSSとしてのあり方というのは、自分のエンジニアの考え方に大きく反映されていると思う。 また、Fluentdの開発者でない人間の中でFluentdそのものについて世界で一番詳しい？かもしれない、という特殊な経歴をもっているので、ざっくりと記憶にあるところで色々書いてみた。 この11年で当たり前にFluentdがつかわれるようにり、歴史の一部をちょっとでも共有できていら嬉しいかぎり。
