LogstashとElasticsearchのIngestノード、どちらを使うべき？
LogstashはElastic Stackの登場時からのプロダクトで、データのパースや整形、処理ツールとして確かな実績があります。入力、出力、フィルタープラグインも豊富に作成されており、多様なアーキテクチャーで驚くほどフレキシブルに、パワフルに活用できます。
Ingestノードは、インデックスの前処理としてElasticsearchでドキュメントを処理する方法としてElasticsearch 5.0から登場しました。最小限のコンポーネントとシンプルなアーキテクチャーで、アプリケーションが直接Elasticsearchに送ったデータを処理、インデックスします。Ingestノードを使えばシンプルな手順でElastic Stackの導入を開始することができ、またデータ量が増えてもスケールできるメリットもあります。
一方、Ingestノードの機能はLogstashと重複する部分があります。そこでよくお寄せいただくお問い合わせが、「どっちを使えばいいの？」という質問です。このブログ記事では、アーキテクチャーという観点から最適な判断を下すためにチェックすべき要素について説明します。
本記事は、よくあるご質問に回答するシリーズの3回目です。以前の記事はこちらです：
データの入力と出力
まずLogstashとIngestノードで大きく異なるのが、データの入出力方法です。
IngestノードはElasticsearchのインデックス処理フロー内で実行されるため、バルク、またはインデックスリクエストを経由してデータをElasticsearchにプッシュする必要があります。つまりElasticsearchに能動的にデータを記入するプロセスが必要です。Ingestノードはメッセージキューやデータベースとは異なり、外部ソースからデータをプルすることはできません。
データを処理した後も制限があります。データをインデックスするオプションは1つしかなく、Elasticsearchのローカルにインデックスするしかありません。
これに対し、Logstashは豊富な入力/出力プラグインを使って多様なアーキテクチャーをサポートすることができます。つまりサーバーとして振る舞い、TCPやUDP、HTTP経由でクライアントがプッシュするデータを受け取ることも、データベースやメッセージキューから能動的にデータをプルすることもできます。出力にも幅広いオプションがあり、KafkaやRabbitMQなどのメッセージキューを使うことも、S3やHDFSで長期のデータアーカイブにすることもできます。
キューイングとバックプレッシャー
Elasticsearchへのデータ送信では、直接送信する場合も、Ingestパイプラインを経由する場合も、Elasticsearchの処理が追いつかない（途中までしかデータを受け入れない）場合には、各クライアントで対応する必要があります。このような場合に適用されるのがバックプレッシャーです。バックプレッシャーを適用すると、データノードがデータを受け入れない場合は、Ingestノードもデータの受け入れを停止します。
処理パイプラインにキューイングメカニズムが組み込まれていないアーキテクチャーでは、Elasticsearchが長時間応答しない、あるいはデータを受け入れない場合に、ソースやその他の箇所でデータロスが生じる可能性があります。Beatsやsyslog-ngなど、ファイルからデータを読み込んでElasticsearchに直接書き込むことができるが、データを保存できないという他のプロセスの場合も同様です。
一方、Logstashは永続化キュー機能を使用してディスクのデータをキューイングすることができます。Logstashは1回以上の送信を保証でき、投入量のスパイクがあるとデータをローカルにバッファします。Logstashは複数の異なるタイプのメッセージキューを統合することもできるため、幅広いパターンのデプロイをサポートします。
データの整形と処理
Ingestノードには20以上の多様なプロセッサーがあり、一般的に使われるLogstashプラグインの機能性をほぼカバーしています。唯一の制限は、Ingestノードパイプラインが1種類のイベントのコンテクストでしか動作しない点です。通常、プロセッサーは他のシステムを呼び出したり、ディスクからデータを読み込むことはできません。したがって、実行できるデータ整形のタイプには限りがあります。
一方、Logstashプラグインのラインナップはさらに充実しています。設定ファイルやElasticsearch、リレーショナルデータベースを参照してコンテンツを追加、または変換させるプラグインも複数あります。
また、BeatsとLogstashは設定に基づくイベントのフィルタリングやドロップをサポートしていますが、Ingestノードはサポートしていません。
設定のしやすさ
設定のしやすさは、作業する人の主観や経験によってもかなり異なります。IngestノードのパイプラインはJSONドキュメントで定義され、Elasticsearchに格納されます。複数の異なるパイプラインを定義できますが、Ingestノードを経由する各ドキュメントはすべて1つのパイプラインで処理されることになります。ある程度シンプルで、定義が明確なパイプラインであれば、Ingestノードの設定の形式はLogstashの設定ファイル形式より扱いやすいと言えます。一方、複数のデータ形式を扱う複雑なパイプラインの場合、フローを制御する条件の扱いはLogstashの方が容易です。またLogstashは複数の論理的に個別のパイプラインをサポートし、Kibanaベースのユーザーインターフェースで管理することができます。
さらに、一般的にLogstashの方がパイプラインのパフォーマンス測定や最適化を簡単に行えることも知っておいて損はありません。Logstashは監視機能をサポートし、優れたパイプラインビューアーUIを備えています。そのため、各種機能やUIを使用してボトルネックや潜在的な問題をすばやく発見することが可能です。
ハードウェアのフットプリントへの影響は？
Ingestノードの魅力はアーキテクチャーが非常にシンプルで、Beatsで直接Ingestノードパイプラインに書き込みできることです。ElasticsearchクラスターのすべてのノードはIngestノードとして振る舞うことができるため、比較的小規模なユースケースであればハードウェアリソースの使用を小さくし、アーキテクチャーをシンプルに保つことができます。
しかしデータ量が多い場合や複雑な処理の場合は、クラスターのCPU負荷が大きくなり、一般的には専用Ingestノードへの切り替えが推奨されます。この時点で、専用IngestノードまたはLogstashをホストする追加ハードウェアが必要になり、ハードウェアリソースの使用量はアーキテクチャーよりもユースケースに依存します。
Ingestノードだけで使える機能
ここまで比較してきた内容から、"Ingestノードは機能性においてはLogstashのサブセット、あるいは簡易版なんだな"という印象をお持ちかもしれません。実は、そうではない部分もあります。
IngestノードはIngest Attachmentプロセッサープラグインをサポートしています。これは、PPTやXLS、PDFなどの一般的なフォーマットの添付ファイルの処理とインデックスに利用できるプラグインです。現在、この機能に該当するプラグインはLogstashには存在しません。様々な添付ファイルをインデックスするという場合は、Ingestノードが必要になる可能性があります。
またIngestパイプラインはデータがインデックスされる直前に動作します。したがってイベントがインデックスされたことを示すタイムスタンプを追加する場合に、最も信頼性が高い方法となります。たとえば投入の遅れを正確に測定、分析する場合などに有用です。データが正常にElasticsearchに到着する前にタイムスタンプを設定していると、タイムスタンプからElasticsearchでのインデックスまでに遅延が生じた場合に混乱が生じます。バックプレッシャーが適用された場合や、クライアントが同じデータについて複数回インデックスを強制的に試みた場合などです。Ingestパイプラインのタイムスタンプではそうした問題がなく、ドキュメントあたりの投入遅延の測定に使用することができます。
LogstashとIngestノードを併用する
ここまでLogstashを使う方法とIngestノードを使う方法を比較してきましたが、LogstashはIngestパイプラインへのデータ送信をサポートしており、実は併用することもできます。複雑なアーキテクチャーでは、要件が大きく異なる複数のロジカルフローが必要になることもあります。そうした場合には、一部のデータはLogstashを経由させ、別の部分はIngestノードでElasticsearchに直接送るということもできます。各データストリームを最も合理的に扱えるよう設計することで、保守もしやすくなります。
まとめ
LogstashとElasticsearchのIngestノードには機能性が重複する部分があります。したがって、そのどちらかを実装すれば成り立つアーキテクチャーが多くあります。LogstashとIngestノードにはそれぞれの長所と短所があり、パイプライン全体の要件とアーキテクチャーを分析した上で、適切な方法を選ぶことが大切です。判断の各基準について、本ブログ記事も参考にしてみてください。またLogstashとIngestノードは、どちらか1つしか選べないというわけではありません。パイプライン処理で一緒に使う、あるいは部分ごとに併用することもできます。