Performance comparison between iLogtail and Filebeat

1. はじめに

先日、iLogtail [1]（Alibaba Cloud の数万インスタンスに対応する可観測性コレクター）がオープンソース化されました。iLogtail の収集性能は 1 コアあたり 100 MB/s に達し、オープンソースの収集エージェントと比較して 5〜10 倍のパフォーマンス優位性を持つことが紹介されました。iLogtail の具体的な性能データやリソース消費について、多くの方が関心をお持ちです。本記事では、現在業界で広く使用されており、比較的パフォーマンスに優れるエージェントである Filebeat と比較し、さまざまな負荷シナリオで両エージェントがどのように動作するかを検証します。

2. テスト内容の説明

Kubernetes の普及に伴い、Kubernetes 環境下でのログ収集の需要はますます一般化しています。そのため、以降のセクションではコンテナの標準出力ストリーム収集とコンテナ内ファイル収集の比較テストを実施します（静的ファイル収集については、コンテナ内ファイル収集を参照してください。比較テストにおいて、iLogtail の純粋な静的ファイル収集は、テスト 2 のコンテナ内ファイル収集より若干良好な結果となります）。テスト項目の詳細は以下のとおりです。

実験 1：収集設定数 4 固定、生ログ生成レート 1M/s、2M/s、3M/s における Filebeat と iLogtail の標準出力ストリーム収集性能の比較。
実験 2：収集設定数 4 固定、生ログ生成レート 1M/s、2M/s、3M/s における Filebeat と iLogtail のコンテナ内ファイル収集性能の比較。
実際の本番環境では、ログ収集コンポーネントの運用性も非常に重要です。運用保守やその後のアップグレードが容易であることが求められます。Sidecar モードと比較して、K8s 環境では DaemonSet モードで収集コンポーネントをデプロイする方が一般的です。ただし、DaemonSet はクラスター全体の収集設定を各収集ノードに同時に配信するため、単一収集ノードの動作設定数は必ず全体の収集設定数より少なくなります。そこで、収集設定の拡大がコレクターの動作効率に影響を与えるかを検証するため、以下の 2 つの実験を実施します。

実験 3：入力レート 3M/s 固定、収集設定数 50、100、500、1000 における Filebeat と iLogtail の標準出力ストリーム収集性能の比較。
実験 4：入力レート 3M/s 固定、収集設定数 50、100、500、1000 における Filebeat と iLogtail のコンテナ内ファイル収集性能の比較。

最後に、iLogtail の高流量負荷テストを実施します。詳細は以下のとおりです。

実験 5：5M/s、10M/s、20M/s、40M/s における iLogtail の標準出力ストリーム収集性能。
実験 6：5M/s、10M/s、20M/s、40M/s における iLogtail のコンテナ内ファイル収集性能。

3. テスト環境

すべての収集環境データは [2] に保存されています。関心のある方は、ご自身で比較テスト全体を再現できます。以降のセクションでは、各収集モードの具体的な設定について説明します。収集比較の結果のみを確認したい場合は、この部分をスキップして読み進めてください。

3.1 環境

動作環境：Alibaba Cloud ACK Pro
ノード構成：ecs.g6.xlarge（4 vCPU 16 GB）ディスク ESSD
基盤コンテナ：Containerd
iLogtail バージョン：1.0.28
Filebeat バージョン：v7.16.2

3.2 データソース

データソースについては、正規表現解析や複数行結合機能の差異による影響を排除し、最も基本的な単一行収集のみを比較します。データ生成ソースは NGINX のアクセスログを模擬し、1 行あたりのログサイズは 283 B です。以下の設定は、1000 の入力ソースにおける bar/s レートを表しています。

3.3 Filebeat 標準出力ストリーム収集設定

Filebeat はコンテナファイル収集をネイティブにサポートしており、add_kubernetes_metadata コンポーネントを通じて Kubernetes のメタデータを追加します。出力コンポーネントによるパフォーマンス差を回避するため、drop_event プラグインを通じてデータを破棄し出力を省略します。Filebeat のテスト設定は以下のとおりです（harvester_buffer_size を 512K に調整、filebeat.registry.flush を 30s に設定、queue.mem パラメーターを適切に拡張してスループットを向上）。

3.4 Filebeat コンテナ内ファイル収集設定

Filebeat はコンテナ内のファイル収集をネイティブにサポートしていないため、ホストの HostPath にログ出力パスを手動でマウントする必要があります。ここでは subPath と DirectoryOrCreate 機能を使用して、サービス出力パスを分離します。以下は、異なるサービスのログ出力パスの独立性を模擬するものです。

Filebeat は基本的なログ読み取り機能を使用して /testlog パス配下のログを読み取ります。出力コンポーネントによるパフォーマンス差を回避するため、drop_event プラグインを通じてデータを破棄し出力を省略します。テスト設定は以下のとおりです（harvester_buffer_size を 512K に調整、filebeat.registry.flush を 30s に設定、queue.mem パラメーターを適切に拡張してスループットを向上）。

3.5 iLogtail 標準出力ストリーム収集設定

iLogtail も標準出力ストリーム収集をネイティブにサポートしています。service_docker_stdout コンポーネントが Kubernetes のメタデータを既に抽出します。出力コンポーネントによるパフォーマンス差を回避するため、processor_filter_regex を通じてすべてのログをフィルタリングします。テスト設定は以下のとおりです。

3.6 iLogtail コンテナ内ファイル収集設定

iLogtail はコンテナ内のファイル収集をネイティブにサポートしていますが、ファイル収集のメタデータはタグに格納されるため、現時点ではフィルタープラグインが存在しません。出力コンポーネントによるパフォーマンス差を回避するため、空の出力プラグインを使用して出力します。テスト設定は以下のとおりです。

4. Filebeat と iLogtail の比較テスト

Filebeat と iLogtail の比較項目は主に以下のとおりです：標準出力ストリーム収集性能、コンテナ内ファイル収集性能、標準出力ストリームの多ユーザー設定性能、コンテナ内ファイルの多ユーザー設定性能、および大流量収集性能。

4.1 標準出力ストリーム収集性能の比較

入力データソース：283 B/s、基盤コンテナ Containerd、標準出力ストリームは 328 B に拡張、合計 4 つの入力ソース：

1M/s 入力：ログ 3,700 件/s
2M/s 入力：ログ 7,400 件/s
3M/s 入力：ログ 11,100 件/s

以下に、異なる収集方法による標準出力ストリームの性能比較を示します。iLogtail は Filebeat と比較して約 10 倍のパフォーマンス優位性を持つことが確認できます（CPU の割合はシングルコアに対するパーセンテージです）。

以下に、異なる収集方法による標準出力ストリームのメモリ比較を示します。iLogtail と Filebeat の全体メモリ使用量に大きな差はなく、収集トラフィックの増加に伴うメモリの急増も見られません。

4.2 コンテナ内ファイル収集性能の比較

入力データソース：283 B/s、合計 4 つの入力ソース：

1M/s 入力：ログ 3,700 件/s
2M/s 入力：ログ 7,400 件/s
3M/s 入力：ログ 11,100 件/s

以下に、異なる収集方法によるコンテナ内ファイル収集の性能比較を示します。Filebeat のコンテナ内ファイル収集は、コンテナ収集と収集コンポーネントを共有し、Kubernetes のメタデータ関連コンポーネントを省略しているため、標準出力ストリーム収集と比較して大幅な性能向上が見られます。iLogtail のコンテナ内ファイル収集は Polling + inotify メカニズムを採用しており、こちらも標準出力ストリーム収集と比較して性能が向上していますが、iLogtail は Filebeat と比較して約 5 倍のパフォーマンス優位性を持つことが確認できます（CPU の割合はシングルコアに対するパーセンテージです）。

以下に、異なる収集方法による標準出力ストリームのメモリ比較を示します。iLogtail と Filebeat の全体メモリ使用量に大きな差はなく、収集トラフィックの増加に伴うメモリの急増も見られません。

4.3 収集設定の拡張性能比較

収集設定の拡張性能比較では、入力ソース数を 4、合計入力レートを 3M/s に固定し、収集設定数 50、100、500、1000 でそれぞれ比較します。

標準出力ストリーム収集設定の拡張比較

以下に、異なる収集方法による標準出力ストリームの性能比較を示します。Filebeat は、コンテナ収集と静的ファイル収集が同じ静的ファイル収集ロジックを共有しているため、標準出力ストリーム収集パス /var/log/containers で大量の正規表現マッチング処理が発生します。収集データ量は設定数の増加に伴って増えていないにもかかわらず、CPU 消費量が 10% 以上増加していることが確認できます。一方、iLogtail はコンテナ収集モデルに対してコンテナパス検出メカニズムをグローバルに共有することで、正規表現ロジックによるパフォーマンス損失を回避しています（CPU の割合はシングルコアに対するパーセンテージです）。

メモリ拡張については、Filebeat と iLogtail の両方とも収集設定数の増加に伴いメモリが増加しますが、いずれの増加量も許容範囲内です。

コンテナ内ファイル収集設定の拡張比較

以下に、異なるコレクターによるコンテナ内ファイル収集の性能比較を示します。Filebeat の静的ファイル収集は標準出力ストリームの共通パスに対する正規表現マッチングを回避しているため、標準出力ストリーム収集よりも若干良好な性能を示します（CPU の割合はシングルコアに対するパーセンテージです）。

メモリ拡張についても、Filebeat と iLogtail の両方とも収集設定数の増加に伴いメモリが増加しますが、いずれの増加量も許容範囲内です。

4.4 iLogtail 収集性能テスト

Filebeat は大量のログがあるシナリオで収集遅延の問題が発生するため、以降のシナリオは iLogtail のみを対象にテストします。iLogtail のコンテナ標準出力ストリームとコンテナ内ファイルについて、それぞれ 5M/s、10M/s、20M/s で性能負荷テストを実施します。

入力ソース数：10
ログ 1 件あたりのサイズ：283 B
5M/s：ログレート 18,526 件/s、単一入力ソースの生成レート 1,852 件/s
10M/s：ログレート 37,052 件/s、単一入力ソースの生成レート 3,705 件/s
20M/s：ログレート 74,104 件/s、単一入力ソースの生成レート 7,410 件/s
40M/s：ログレート 148,208 件/s、単一入力ソースの生成レート 14,820 件/s
前述の実験と同様に、CPU 消費量については、コンテナ内ファイル収集がコンテナ標準出力ストリーム収集より若干良好な性能を示します（CPU の割合はシングルコアに対するパーセンテージです）。これは主に、コンテナ内ファイル収集の基盤となる Polling + inotify メカニズムによるものです。

メモリについては、標準出力ストリーム収集は主に GO に依存し、コンテナ内ファイル収集は主に C に依存します。GC メカニズムの存在により、速度が上がるにつれて標準出力ストリーム収集が消費するメモリは徐々にコンテナ内ファイル収集のメモリ消費量を上回ります。

4.5 比較まとめ

5. Filebeat のコンテナ標準出力とファイル収集に大きな差がある理由

上記の実験から、Filebeat は異なる動作モードで大きな CPU 消費量の差が生じることが確認できます。以下のフレームグラフは、コンテナの標準出力ストリーム収集から pprof でダンプした結果です。Filebeat のコンテナ収集における add_kubernets_meta プラグインがパフォーマンスボトルネックであることが確認できます。add_kubernets_meta は各ノードが api-server を監視する方式を採用しており、api-server への負荷問題も存在します。

iLogtail が取得する Kubernetes メタデータは Kubernetes CRI プロトコルと完全に互換であり、メタデータは Kubernetes サンドボックスを通じて直接読み取られるため、iLogtail の高性能な収集効率が保証されます。

6. iLogtail DaemonSet シナリオの最適化

上記の比較から、iLogtail は Filebeat と比較してメモリと CPU 消費量に優れていることが確認できます。なぜ iLogtail がこれほど高いパフォーマンスを実現できるのか疑問に思う方もいるでしょう。以下では、主に iLogtail の DaemonSet シナリオの最適化と、標準出力ストリーム収集で Filebeat の 10 倍のパフォーマンスを実現している理由について説明します。

まず、標準出力ストリームシナリオについて、Filebeat や Fluentd などの他のオープンソースコレクターと比較します。一般的に、コンテナの標準出力ストリームファイルの収集は /var/log/containers や /var/log/pods/ を監視することで実現されます。たとえば、/var/log/pods/ のパス構造は /var/log/pods/_// であり、このパスを通じて物理マシンの静的ファイル収集モードを再利用して収集します。

一方、iLogtail はコンテナ化を完全にサポートしています。検出メカニズムを通じて、iLogtail はノードのコンテナリストをグローバルに管理し、このコンテナリストをリアルタイムで監視・維持します。コンテナリストを持つことで、以下の利点が得られます。

収集パスが静的設定パスに依存せず、コンテナラベルに基づいて収集ソースを動的に選択できるため、ユーザーの導入コストを簡素化できます。

コンテナが自動的にマウントしたノードの動的パスをコンテナメタ情報に基づいて検出できるため、iLogtail はマウントなしでコンテナ内のファイルを収集できます。一方、Filebeat などのコレクターは、コンテナ内のパスをホストマシンのパスにマウントしてから静的ファイル収集を行う必要があります。

新規の収集設定に対して、既存のコンテナリストを再利用して迅速に収集を開始できます。空の収集設定についても、コンテナ検出のグローバル共有メカニズムが存在するため、空のポーリング監視パスのメカニズムが回避され、このような動的な環境においても iLogtail の運用コストを抑制できます。

7. まとめ

以上のとおり、動的な Kubernetes 環境において、iLogtail は DaemonSet のデプロイモデルによる複数設定の問題で大幅なメモリ増加を引き起こすことはありません。静的ファイル収集では約 5 倍のパフォーマンス優位性を持ち、標準出力ストリーム収集では iLogtail の収集メカニズムにより約 10 倍のパフォーマンス優位性を有しています。ただし、Filebeat や Fluentd などの従来のオープンソース製品と比較して、ドキュメントやコミュニティの構築にはまだ多くの課題があります。iLogtail に関心のある方は、ぜひ参加して、使いやすく高性能な iLogtail プロダクトを一緒に作り上げていきましょう。