Elasticのデータ前処理、どっちを選ぶ？ Logstash vs Ingest Pipeline 徹底比較

Elastic Stack（ELKスタック）を導入する際、多くのエンジニアが最初に頭を悩ませるのが「データの収集・加工（前処理）に何を使うか」という問題です。

かつては「前処理といえばLogstash」の一択でしたが、Elasticsearchに Ingest Pipeline が実装されて以降、その手軽さとパフォーマンスから強力な選択肢となっています。

本記事では、LogstashとIngest Pipelineのアーキテクチャの違い、機能面での優劣、そして「結局どちらを選ぶべきか」の判断基準を技術者視点で解説します。

1. LogstashとIngest Pipelineの概要
1. Logstash とは？
2. Ingest Pipeline とは？
2. 4つの軸で見る決定的な違い
3. 【結論】どちらを選ぶべきか？ユースケース別の推奨
1. ✅ Ingest Pipeline を選ぶべきケース
2. ✅ Logstash を選ぶべきケース
💡 比較サマリー
💡 ハイブリッド構成（併用）という選択肢も
まとめ

1. LogstashとIngest Pipelineの概要

比較に入る前に、それぞれの立ち位置を簡単におさらいしておきましょう。

Logstash とは？

データ処理パイプラインを構築するための独立した外部サーバー（コンポーネント）です。豊富なプラグイン（Input / Filter / Output）を備え、多様なデータソースからデータを吸い上げ、複雑な加工を施した上で、Elasticsearchをはじめとする様々な宛先にデータを送信できます。

Ingest Pipeline とは？

Elasticsearchのクラスタ内部（Ingestノード）で動作する 前処理機能です。データがElasticsearchにインデックス（格納）される直前に、JSON形式のドキュメントに対して「プロセッサ」と呼ばれる処理を数珠つなぎに適用してデータを加工します。

2. 4つの軸で見る決定的な違い

2つのコンポーネントの特性を、「入出力」「データ加工能力」「耐障害性」「運用コスト」の4つの軸で比較します。

① 入出力の柔軟性（Inputs & Outputs）

Logstash:
- 圧倒的な柔軟性を持ちます。HTTPやSyslogなどのPush型だけでなく、リレーショナルデータベース（JDBC）やメッセージキュー（Kafka, RabbitMQ）からデータを自発的に取得（Pull）できます。また、加工したデータをElasticsearchに送りつつ、同時にS3へ生ログをアーカイブする、といったマルチ出力が可能です。
Ingest Pipeline:
- あくまですべての処理が「Elasticsearchにデータが書き込まれるタイミング」で動作するため、外部へデータを読みに行くことはできません。Beatsやアプリケーションからデータを「Push」してもらう必要があります。また、出力先もパイプラインが動いているElasticsearch自身に限定されます。

② データの加工・拡充能力（Transformation）

Logstash:
- 条件分岐（if-else）のネストや、Rubyプラグインを用いたコードレベルでの柔軟な記述が可能です。また、処理中に外部のファイルやデータベースを参照してデータを補完（エンリッチ）する処理も得意です。
Ingest Pipeline:
- Grok、GeoIP、JSONなどの主要なプロセッサが標準搭載されており、一般的なログ（Apache, Nginx, システムログなど）のパースであれば十分すぎる性能を持っています。enrich プロセッサを使えばElasticsearch内の別インデックスを参照したデータ拡充も可能ですが、Logstashほど外部システムと密に連携した複雑な加工はできません。

③ 耐障害性とバッファリング（Queueing）

Logstash:
- 永続的キュー（Persistent Queues）を内蔵しています。Elasticsearch側が一時的なスパイクやメンテナンスでデータを受け付けなくなっても、Logstashがローカルディスクにデータを安全にバッファリングし、データロストを防ぎます。
Ingest Pipeline:
- 自身にデータを溜めるディスクキューはありません。Elasticsearchのインデキシング負荷が高くなると、データ送信元（Beatsなど）に対して「これ以上送らないでくれ」というバックプレッシャーをかけます。送信元がバッファを持っていない場合、データロストの追跡や再送管理を送信元側で担保する必要があります。

④ インフラ構成と運用コスト

Logstash:
- 独立したプロセス（JVM）として動くため、メモリやCPUの設計、パッチ当て、監視などの運用コストが上乗せされます。ただし、データ処理の負荷をElasticsearchクラスタから完全に分離できるというメリットもあります。
Ingest Pipeline:
- 新たにサーバーを構築する必要がありません。KibanaのUIやREST APIからJSON定義を投入するだけで即座にデプロイ・変更が可能です。運用は非常にシンプルになりますが、重いパース処理（複雑なGrokなど）が大量に走ると、Elasticsearch自体のリソース（検索やインデックス性能）を圧迫するリスクがあります。

3. 【結論】どちらを選ぶべきか？ユースケース別の推奨

システム要件や現在の構成に合わせて、インフラエンジニアは以下の基準で選択することをお勧めします。

✅ Ingest Pipeline を選ぶべきケース

「シンプルさ」と「スピード」を最優先する場合

データソースが Elastic Agent や Beats に統一されており、直接ElasticsearchにデータをPushできる。
ログの加工要件が、タイムスタンプの整形や不要フィールドの削除、シンプルなGrokパース程度である。
これ以上、管理対象のサーバーやコンポーネント（ミドルウェア）を増やしたくない。

✅ Logstash を選ぶべきケース

「複雑なパイプライン」や「大規模・多様な環境」を管理する場合

データベース（SQL）やKafka、サードパーティのAPIなど、多種多様な場所からデータをPullで収集する必要がある。
受け取ったデータをElasticsearchだけでなく、S3や別のオブジェクトストレージにも同時にバックアップしたい。
パース処理が非常に複雑で、Elasticsearchの検索・インデックス性能に影響を与えたくない（負荷を分離したい）。
データの突発的なスパイクに備え、堅牢なディスクバッファリング（永続的キュー）が必須である。

💡 比較サマリー

比較項目	Logstash	Ingest Pipeline
配置・アーキテクチャ	独立した外部サーバー（JVM）	Elasticsearchクラスタの内部（Ingestノード）
入力（データ収集）	自由度：高（Pull型、Push型、各種DB、MQ対応）	自由度：低（ElasticsearchへのPushのみ）
出力（データ送信）	マルチ出力対応（ES、S3、Kafka、ファイル等）	Elasticsearch内部のみ
キュー・バッファリング	内蔵（Persistent Queuesによるデータロスト防止）	なし（送信元にバックプレッシャーをかける）
加工・拡充の複雑さ	非常に複雑なロジック、Rubyコード、外部DB参照	単一ドキュメント内の処理、簡単なクラスタ内ルックアップ
インフラ管理負荷	高（追加のサーバー管理やチューニングが必要）	低（Elasticsearchの設定としてAPI管理可能）
推奨ユースケース	多種多様なソースからのデータ収集、マルチ出力、複雑なパース処理、負荷分離、高堅牢性が求められる大規模環境。	シンプルさとスピードを優先する場合。Beats/Agent利用時、標準的なログパース、管理コンポーネントを増やしたくない場合。

💡 ハイブリッド構成（併用）という選択肢も

「Logstashで多様なデータソースから収集・バッファリングを行い、Elasticsearchに転送した後の細かいパースはElasticのIntegration（標準のIngest Pipeline）に任せる」という Logstash ➔ Ingest Pipeline のハイブリッド構成も、大規模環境では一般的です。