Fluentdはあらゆるソースからログ・メトリクス・イベントを「JSON構造化された統一フォーマット」で収集・加工・転送する、プラグイン拡張型のデータ収集ミドルウェアです。Treasure Data社の創業エンジニアである古橋貞之（ふるはしさだゆき）が2011年に開発し、Apache License 2.0でオープンソース公開しました。日本発のOSSとしては珍しく世界規模で採用が広がり、2016年11月にKubernetesに次ぐCNCFのインキュベーションプロジェクトとして受け入れられ、2019年4月にはCNCF Graduatedに昇格しています。現在もFluent Bitと共にログ収集レイヤのデファクトとして広く運用されています。
この記事の目次
- Input・Filter・Outputと統一JSON
- 古橋貞之とTreasure Dataの誕生
- アグリゲータ・マルチクラウドでの活躍
- Fluent Bit・Logstash・Vectorとの違い
- まとめ
Input・Filter・Outputと統一JSON
Fluentdの基本構造は Input → Filter → Buffer → Output のパイプラインで、すべてのレコードを「タグ＋時刻＋JSONハッシュ」という統一フォーマットに変換します。Inputには tail、syslog、forward、http、tcp、journald など、Outputには Elasticsearch、S3、Kafka、BigQuery、Treasure Data、MongoDB、各種SaaSなど1000以上のプラグインがRubyGems経由で公開されています。Filterで record_transformer や grep を組み合わせれば、フィールド追加・マスク・正規表現抽出を設定ファイルだけで行えるため、Pythonスクリプトを書かずにETL的処理が完結します。
ChunkとBufferの仕組みが堅牢で、ネットワーク障害が起きたときに送信先へ届かなかったレコードをディスクに退避し、復旧後に自動再送できます。at-least-once配送保証と、複数Outputの障害分離が現場で重宝されるポイントです。ハイアベイラビリティ構成では、複数Fluentdをforward転送で多段化し、最終的にElasticsearchやS3に集約する構成が定番化しており、「データ収集のためのUNIX的パイプ＋プラグイン哲学」の体現として、長年エンジニアから愛されています。
古橋貞之とTreasure Dataの誕生
Fluentdは2011年、東京大学卒の古橋貞之が、シリコンバレーで創業したTreasure Data社のログ収集基盤として設計したものをApache License 2.0でオープンソース公開したのが始まりです。MessagePackフォーマットの発明者としても知られる古橋は、「ログ収集の世界を統一フォーマットで簡素化する」という思想で実装を進めました。日本発のOSSが世界で広く使われる珍しい成功例として、その後のCNCF入りへと繋がっていきます。
2016年11月、Fluentdは Kubernetes と Prometheus に続いてCNCFのインキュベーションプロジェクトに採択され、2019年4月にはGraduatedプロジェクトに昇格しました。Treasure Dataは2018年にArm Holdingsに買収され、その後IoT領域を分離し独立企業として再出発しており、Fluentd開発の中核メンバーは現Chronosphere社などにも分散しています。プロジェクトは現在もコミュニティ主導で活発に開発が続いており、CNCFが主催するKubeConでもログ収集の定番セッションとして毎年取り上げられています。
アグリゲータ・マルチクラウドでの活躍
Fluentdが最も力を発揮するのは「複数拠点からログを集めて単一の分析基盤へ流し込むアグリゲータ」役割です。Node側ではFluent Bitなどの軽量エージェントを使い、中央のアグリゲータでFluentdが受け取って、Filterで整形しつつ「リアルタイム解析用にKafka」「長期保存用にS3」「BI用にBigQuery」へ同時並列出力する、という構成が現場の定番です。S3 OutputとBigQuery Outputはどちらも公式コミュニティで活発にメンテされており、本番投入実績が豊富です。
Kubernetes時代でも「Node常駐のFluent Bit ＋ 集約サーバーのFluentd」という2段構成は引き続き有効です。Rubyランタイムゆえの自由度が高く、複雑なFilter処理やカスタムプラグインを内製で書き足せるのがFluentdの強みで、「ログを集める前にちょっとだけ正規化したい」「特定フィールドに応じてOutputを分岐したい」という細かな要件にプラグイン文化が応えてくれます。1000以上の公式・コミュニティプラグインの厚みは、後発のVectorなどがすぐには追いつけない資産として残り続けています。
Fluent Bit・Logstash・Vectorとの違い
兄弟分のFluent BitはC実装で軽量・高速、エッジやK8s Daemonset用途で第一候補となります。Logstash（Elastic社）はJVM実装でElasticsearchとの統合が深く、特にELKスタックの一員として歴史が長い選択肢です。Datadog社のVectorはRust実装で性能と宣言的設定（TOML／YAML）を売りに新規導入で勢いを増している新興勢力。Telegraf（InfluxData社）はメトリクス収集に特化したGo実装で、Fluentdとは守備範囲が少し異なります。
Fluentdの強みは依然として「プラグイン総数の多さ」「Rubyによる柔軟な拡張性」「中規模アグリゲータとしての本番実績」です。メモリ使用量や起動時間で見るとFluent BitやVectorに譲りますが、変換ロジックを記述する自由度や、既存OSSとの連携の幅では今も最右翼のひとつです。新規構築では「Node側はFluent Bit、中央アグリゲータはFluentdかVector」という選定が標準パターンとなっています。
まとめ
Fluentdは古橋貞之が2011年に生んだ日本発のCNCF Graduatedログ収集OSSで、統一JSONフォーマットと豊富なプラグインで業界デファクトの座を築きました。Fluent Bitと役割分担しながらアグリゲータ層を担い続け、新興のVectorに性能面で挑まれつつも、プラグイン資産と運用実績の厚みでログパイプラインの中核に残り続けています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント