
Elastic Platformは検索ユースケースや機械生成データのための分析システムとして長い間高く評価されてきました。分析は取り込まれたままのデータを処理することに重点が置かれており、Elasticsearchでインデックスを作成するデータを最適に構造化するためにさまざまな工夫がなされています。KibanaはElasticsearchのアグリゲーションを公開し、それを使用して、インタラクティブなダッシュボード、ビジュアライゼーション、アラートを作成します。
しかし、Elastic Platformが検索、セキュリティ、オブザーバビリティ、一般的な分析プラットフォームとして広く採用されるにつれて、アナリストユーザーは取り込まれたままのデータを受け取り、取り込み後に調査ニーズに合わせて変換し、基となるElasticsearchインデックスデータからインサイトを引き出す機能を必要とするようになりました。多機能で表現力が豊かなクエリによって実現される簡潔で効率的な統合ワークフローを必要としています。しかも、UIコンテクストをほとんどあるいはまったく切り替えることなく、単一のクエリ式で検索、フィルター、アグリゲーション、変換を実行できるワークフローです。
こうした課題を解決するために、Elasticチームは現在Elasticsearch Query Language(ESQL)を開発しています。ESQLは、データを調査するElasticユーザーのためのフレキシブルかつパワフルで堅牢なクエリ式言語です。優れたクエリUXと取り込み後の処理機能を備えており、Elasticsearchの分析およびデータ処理機能を根本的に変革し、拡張します。
新しいクエリとアグリゲーションのコンピューティングアーキテクチャー
ESQLは単なる言語ではありません。これは、Elasticsearch内の新しいコンピューティング機能への多大な投資を意味しています。ESQLの機能面とパフォーマンス面の両方の要件を満たすには、まったく新しいコンピューティングアーキテクチャーを構築する必要があります。ESQLの検索、アグリゲーション、変換の各機能はElasticsearch内で直接実行されます。クエリ式をQueryDSLにトランスパイルして実行する方式は採らず、Elasticsearch内にESQL機能のネイティブサポートを構築しています。
ESQLにより、さまざまな役割やスキルレベルのユーザーが分散型のコンピューティング機能を利用できるようになります。このコンピューティング機能を利用することで、ユーザーのワークフローを複数の重要な方法でシンプルにすることができます。
ESQLを利用すると、次のことができます。
- 優れたクエリUXを利用する。ESQLのクエリ式は複雑な分析とデータ処理をサポートしており、学習、判読、共有が容易です。
- Elasticsearchの新しいコンピューティングとデータ処理機能によって可能になるElasticsearchのフィルター、アグリゲーション、変換の各機能をサブクエリやルックアップで利用する。
- KibanaのDiscover、Kibana Lens、ElasticソリューションでESQLを使用して、シームレスなワークフローを実現する。ESQLクエリを可視化したり、ダッシュボード上で、またはクエリとしてチームと共有したり、クエリを使用してカスタムアラートを作成したりできます。

ESQLの活用方法
ESQLはパイプ型クエリ言語なので、パイプで区切った一連のコマンドでElasticsearchデータを処理できます。1つのコマンドの出力が次のコマンドの入力となって、論理的なデータパイプラインが定義されます。ESQLの式は直線的かつ論理的で、可読性に優れています。シンプルなため、どのような習熟度のアナリストでも作成、使用、変更できます。シンプルな例を以下に示します。
search index_name
| eval field_c = (field_a + field_b)
| sort field_c desc
上記の式は、インデックスからすべてのデータを取得し、レコードごとにfield_aとfield_bの合計である新しいfield_cを作成し、最後に結果をfield_cでソートします。
セキュリティにESQLを利用する
ESQLは特にセキュリティアナリストによるアドホックの脅威ハンティングに便利です。たとえば、アナリストはまずログデータに対してクエリを実行して、"powershell.exe"によって生成された固有のプロセスを表示し、コマンドライン引数の文字列の長さでソートできます。
from winlog
| where host.os.family == ‘windows’
| where process.name == "powershell.exe"
| unique process.command_line
| sort len(process.command_lin) desc
| limit 3
host.os.family | process.name | process.command_line |
windows | powershell.exe | (get-acl \\smb_file\share).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags -auto |
windows | powershell.exe | Get-ADComputer -property * -filter { ipv4address -eq ‘172.16.0.3’} |
windows | powershell.exe | Get-ADGroupMember -identity Helpdesk |
結果からは、ファイルシステム情報やActive Directoryに関する情報を取得するためにPowerShellが使用されていることがわかりました。これは通常のシステム動作である可能性もありますが、悪意のあるアクティビティを示している可能性もあります。
さらに調査するために、クエリを変更して、Active Directoryとファイルシステム関係のコマンドライン引数でフィルタリングします。次に、process.command_lineの一意の値をカウントし、hostnameでグループ化します。
from winlog
| where host.os.family == ‘windows’
| where process.name == "powershell.exe"
| where process.command_line in (‘*get-acl*’, ‘*Get-AD*’)
| stats count(unique process.command_line) as cl_count by hostname
| sort cl_count desc
| limit 3
cl_count | hostname |
155 | host2 |
74 | host1 |
67 | host3 |
結果からは、host2が他のホストよりもファイルやAD関連のコマンドライン引数を呼び出すPowerShellプロセスの数がはるかに多いことがわかりました。アナリストはESQLのクエリ式の変更と拡張を続けて、host2による悪意のあるアクティビティがあるかどうかを確認することができます。この調査により、最終的に脅威ベクトルを理解して、改善策を講じることができるうえに、今後この脅威を防止できるようにもなります。
検索にESQLを利用する
Elasticsearchは現在も、これからもずっと検索に利用できます。そのため、ESQLは、Elasticsearchが以前から備えている検索、関連性、順位付けの各機能をサポートしています。ESQLにより、非常にシンプルに、こうした検索機能を最大限に活用できます。
genreフィールドの上位3つの用語をドキュメント数でソートしたバケットを生成するシンプルな用語アグリゲーションについて考えてみましょう。
from music
| stats terms((genre), 3, doc_count, unwind)
| sort doc_count desc
doc_count | term |
6 | electronic |
3 | rock |
2 | jazz |
日付ヒストグラムなどのバケットアグリゲーションもサポートされます。次のクエリでは、priceフィールドに基づいた50の区間を使用して、salesインデックスからヒストグラムを作成します。
from sales
| stats histogram(price, 50)
| sort bucket desc
doc_count | bucket |
3 | 200 |
2 | 150 |
0 | 100 |
1 | 50 |
1 | 0 |
ESQLでは、非常にシンプルに、現在のパイプラインアグリゲーションに近い形でデータを処理することもできます。たとえば、微分の計算をする必要があるとしましょう。最もシンプルな形式を以下に示します。
from sales
| eval (stats derivative(sales)) as fist_der
| eval (stats derivative(first_der)) as second_der
オブザーバビリティにESQLを利用する
サイトリライアビリティエンジニア(SRE)は大量のデータを処理するという課題に直面しています。そのデータを利用して、システムのダウンタイムやその他の関連する問題を防止、緩和しなければなりません。重要なトレース、ログ、メトリックデータを生成する何千ものシステムを監視しています。そのデータを利用して、問題を特定し、今後システムやアプリケーションの中断が起こらないよう対策を実施します。そのため、SREには、複数のデータセットから得た知見を組み合わせてシステムの挙動を分析する能力が不可欠です。
オブザーバビリティのために取り込まれたデータは本質的に予測不可能です。ESQLは、SREがデータを相関付け、再構築して、システムやアプリケーションの挙動に関する詳細なインサイトを導き出すための手段を提供します。問題を特定した後の事後分析を実行する能力を拡張します。この非常に貴重なインサイトを直接使用すると、将来の同様の問題を防止することができます。
以下のデータ処理に関するセクターでは、オブザーバビリティの例を使用します。
Elasticsearchの新しいコンピューティング機能を使用したまったく新しいデータ処理方法を探る
ESQLの式では、フレキシブルかつパワフルにインデックスデータからインサイトを引き出すことができます。一方、そうした式の裏側にある面倒な処理はElasticsearch内で実行されます。Elasticは、ESQLによって公開されるデータ処理機能をサポートする新しいコンピューティングエンジンを開発しました。中でも注目すべき点は、取り込み後のデータ処理、中間データの状態、ルックアップ機能、サブクエリの改善です。
ESQLはElasticsearchの新しいコンピューティングと処理機能を全面的に活用します。ESQLがトランスパイルを介して解釈、実行されることはなく、ESQLの式は完全にElasticsearch内で処理されます。
取り込み後の処理
ESQLはKibanaに全面的に統合されているため、非常に一般的で役に立つアグリゲーションや予測にすばやく簡単にアクセスできます。メトリックデータのインデックスを扱う場合を想像してみてください。アナリストは取り込まれたデータの比率を計算したり、アグリゲーションを実行したりする必要があるかもしれません。ESQLを利用すれば、基となるインデックスからそれらを簡単に導き出すことができます。
from network_flow
| stats count(*) filter (where transport == ‘udp’) as udp_count
| stats count(*) filter (where transport == ‘tcp’) as tcp_count
| eval total_transport_events = udp_count + tcp_count
| eval udp_per_total = udp_count / total_transport_events
ESQLでは、基となるインデックスのアグリゲーションや変換をすばやく簡単に実行できるため、アナリストがデータを整形して探索する際に重要な新しいインサイトがもたらされます。ESQLを使用すると、データの取り込みがシンプルになり、アナリストは基となる広範なインデックスから新しい構造やインサイトを引き出すことができます。
データパイプラインと中間データ
ESQLの式のサポートに関する重要なもう1つの側面は、中間状態のデータの処理です。データが個々のパイプラインステージを通過する際にデータを処理、変更する機能はESQLによって公開される処理機能の中核をなしています。
メトリックインデックスを検索して、ピークのCPU使用率が最も高い5つのホスト名を検索する次のクエリについて考えてみましょう。
from metrics
| stats max(system.process.cpu.total.pct) as max_cpu by hostname
| where max_cpu > .800 and hostname == '*web*'
| sort max_cpu desc
| limit 5
このデータパイプラインの各ステージでは表形式の出力を生成します。最初のfrom metricsコマンドは、すべてのインデックスデータを取得します。次に、そのテーブルをsystem.process.cpu.total.pctで集計し、hostnameでグループ化して、一意のテーブルを作成します。これらの表形式の結果をフィルター、ソートして、目的の出力を生成します。
max_cpu | hostname |
.989 | 1webapache |
.978 | 1websftp |
.964 | nfsweb |
.955 | 2webredis |
.943 | web_staging_primary |
この出力を基にビジュアライゼーションやアラートを作成できます。
ルックアップとサブクエリ
ESQLはElasticsearchにルックアップとサブクエリ機能も導入します。
ESQLは個々のルックアップインデックスの値をルックアップできます。その主な用途はクエリ時の結果のエンリッチです。ルックアップはSQLの左結合に似ており、指定されたキーを使用して外部インデックスからフィールドを返します。
たとえば、ルックアップインデックスには、一意のキーで特定されたシステムユーザーに関する情報が含まれています。ESQLの式では、それらのインデックス内のデータをルックアップして、その外部データを結果として返すことができます。次のクエリは、access_logsインデックスの結果を、user_info_lookupインデックスのユーザーデータでエンリッチします。具体的には、ルックアップインデックスのemailとstateフィールドが返されます。
from access_logs where user != 'root'
| lookup user_info_lookup['email', 'state'] on userid
userid | [ … access_logs … ] | state | userid | |
3455 | … | bob | NY | 3455 |
サブクエリを使用すると、別のクエリを引数として他のクエリの中に埋め込むことができます。たとえば、SREは同じインデックスに対するクエリの引数としてアグリゲーションを使用することが必要な場合があります。ここでは、全ログインのカウントを使用して、特定のユーザーのログイン率を計算します。
from user_login where userid = 1234
| eval stats count(*) as 1234_logins
| eval total_logins = [from logs where userid = *| stats count(*) as total_logins]
| eval round((1234_logins / total_logins), 2) as 1234_pct
アナリストもSREもルックアップとサブクエリを使用することで、Elasticsearchを最大限に活用して、Elasticsearchで信じられないほどリッチなデータ構造を生成し、データから新しいインサイトを引き出すことができます。
ESQLは、Elastic Search Platformにおけるデータの扱い方を根本的に変革し、強化します。大規模なデータセットの迅速な変換と結合、膨大な量のデータの検索、フィルター、処理、そして最終的には対応時間や解決時間の短縮を実現するパワフルな機能でデータの価値を解き放ちます。皆さんが活用するのを楽しみにしております。
この分析の旅に加わりませんか
ESQL、変換と結合、マルチステップクエリにワクワクしていますか?私たちもワクワクしています。Elasticチームはご紹介した機能の開発、リリースに向けた準備に引き続き取り組んでいるので、最新情報をお見逃しのないようにしてください。
このソリューションを誰よりも先に試したい場合は、ディスカッションフォーラムまたはElasticコミュニティのSlackチャンネルでお問い合わせください。新しいクエリ言語、コンピューティングエンジン、クエリベースの調査ワークフローの方向性を決めるのに役立つフィードバックをお待ちしています。
本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。