ESQL 入門 - 柔軟で反復的な分析のための新しいクエリ言語

ESQL 概要

Elastic Platform　は、検索ユースケースや機械で生成されたデータの分析システムとして、長い間高く評価されてきました。分析では、Elasticsearch　にインデックスされたデータをどのように最適に構造化するかについて、重要な考慮がなされ、データをそのまま処理することに焦点が当てられています。Kibana　は　Elasticsearch　のアグリゲーションを公開し、それを使ってインタラクティブなダッシュボード、ビジュアライゼーション、アラートを作成します。
しかし、Elastic Platform　が検索、セキュリティ、観測、一般的な分析プラットフォームとしてより広く採用されるにつれ、アナリスト・ユーザーはデータをそのまま取得し、取得後に調査ニーズに合わせて変換し、Elasticsearch　インデックスデータの基礎から洞察を導き出す機能を必要とするようになりました。また、検索、フィルタリング、集計、変換を単一のクエリで実行でき、UIのコンテキスト切り替えがほとんどない、表現力豊かなクエリにより、簡潔で統合的、かつ効率的なワークフローが必要とされています。
これらの課題を解決するために、Elastic チームは現在 Elasticsearch Query Language（ESQL） を開発中です。ESQL は Elastic ユーザに、データを照会するための柔軟で強力、かつ堅牢なクエリ式言語を提供します。また、ESQL はポストインジェスト処理機能を備えた優れたクエリ　UX　を提供し、Elasticsearch の分析およびデータ処理機能を根本的に変革・拡張します。

新しいクエリおよびアグリゲーション・コンピュート・アーキテクチャ

ESQL は単なる言語ではありません。Elasticsearch の新しいコンピュート機能への重要な投資を意味します。ESQL の機能および性能要件を達成するためには、まったく新しい計算アーキテクチャを構築する必要があります。ESQL の検索、集約、変換機能は、Elasticsearch の中で直接実行されます。クエリ式は QueryDSL にトランスパイルされて実行されるわけではありません。むしろ、Elasticsearch の中で ESQL 関数のネイティブサポートを構築しています。
ESQL は、様々な役割やスキルレベルのユーザに対して、分散された計算機能を導入しています。これらの計算機能により、ESQL はいくつかの重要な方法でユーザのワークフローを簡素化することができます。
ESQL を使用すると、次のことが可能になります。
• 優れたクエリ UX の活用： ESQL のクエリ式は、複雑な分析やデータ処理をサポートします。また、学習、読み取り、共有が容易です。
• Elasticsearch の新しい計算およびデータ処理機能によって可能になったサブクエリおよびルックアップで、Elasticsearch のフィルタ、集約、変換機能を使用することができます。
• Discover、Kibana Lens、Elastic Solutions の Kibana 全体で ESQL を使用することで、シームレスなワークフローを実現します。ESQL クエリの可視化、ダッシュボードまたはクエリとしてのチームとの共有、クエリを使用したカスタムアラートの作成が可能になります。

ESQL の利用方法

ESQL はパイプ型クエリ言語で、パイプで区切られた一連のコマンドで Elasticsearch のデータを処理することができます。あるコマンドの出力が次のコマンドの入力となり、論理的なデータパイプラインが定義されます。ESQL の式は線形で、論理的で、読みやすくなっています。また、シンプルであるため、あらゆるレベルのアナリストが作成、使用、変更することができます。簡単な例です。

search index_name
| eval field_c = (field_a + field_b)
| sort field_c desc

上記の式はインデックスからすべてのデータを取得し，各レコードに対してフィールド A とフィールド B の和である新しいフィールド C を作成します。最後に、結果は fieldC でソートされます。

Security のために 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
windows	powershell.exe	Get-ADComputer -property * -filter { ipv4address -eq ‘172.16.0.3’}
windows	powershell.exe	Get-ADGroupMember -identity Helpdesk

その結果、PowerShell がファイルシステム情報、および Active Directory に関する情報を取得するために使用されていることが判明しました。これは、通常のシステム動作である可能性もありますが、悪意のある活動を示している可能性もあります。
さらに調査を進めるため、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 クエリ式の修正と拡張を続け、ホスト 2 による悪意のあるアクティビティがあるかどうかを判断することができます。この調査により、最終的に脅威のベクトルを理解し、改善策を講じるとともに、将来的にこの脅威を防止する方法 を見つけることができます。

Search のために　ESQLを使用する

Elasticsearch はこれまでも、そしてこれからも、検索用です。そのため、ESQL は昔から Elasticsearch の一部であった検索、関連性、ランキングの機能をサポートしています。ESQL を使うと、これらの検索機能をフルに活用することが非常に簡単になります。
単純な用語集計を考えてみましょう。ジャンルフィールドの上位3つの用語を文書数でソートしたバケットを作りたい場合です。

from music
| stats terms((genre), 3, doc_count, unwind)
| sort doc_count desc

doc_count	term
6	electronic
3	rock
2	jazz

日付ヒストグラムのようなバケット集計もサポートされています。このクエリでは、価格フィールドに基づく50の区間を使用して、売上高インデックスからヒストグラムを作成します。

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

Observability のために ESQL を使用する

サイトリライアビリティエンジニア（SRE）は、膨大な量のデータを扱うという難題に直面しています。SRE は、このデータを使ってシステムのダウンタイムやその他の関連する問題を防止・修復する責任を負っています。SRE は何千ものシステムを監視し、重要なトレース、ログ、およびメトリックデータを生成します。これらのデータは、SRE が問題を特定し、将来的にシステムやアプリケーションの中断を防ぐための対策を実施するために使用されます。そのため、SRE にとっては、複数のデータセットから複合的に理解してシステムの挙動を分析する能力が不可欠となるのです。
観測可能な取り込まれたデータは、本質的に予測不可能です。ESQL は、SRE がデータを関連付け、再構築することで、システムやアプリケーションの動作に関するより深い洞察を得るための手段を提供します。ESQL は、問題が特定された後に事後分析を行う能力を拡張し、この貴重な洞察を将来の同様の問題の防止に直接役立てることができます。
以下のデータ処理に関するセクションでは、Observability の例を使用します。

Elasticsearch の新しいコンピュート機能で、まったく新しいデータ処理の方法を探求する

ESQL 式は、インデックスデータから洞察を引き出す上で、柔軟かつ強力なものです。しかし、これらの式の背後にある重い作業は、Elasticsearch 自体で行われます。私たちは、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 … ]	email	state	userid
3455	…	bob	NY	3455

サブクエリを使用すると、別のクエリを他のクエリの中に引数として埋め込むことができます。例えば、SRE は、同じインデックスに対するクエリの引数として集約を使用したいとします。ここでは、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 は、Elasticsearch プラットフォームにおけるデータの扱い方を根本的に変え、向上させます。ESQL は、大規模なデータセットの迅速な変換と結合、膨大なデータの検索、フィルタリング、処理、そして最終的にはレスポンスと解決時間の短縮を実現する強力な機能によって、お客様のデータの価値を引き出します。そして、最終的にはレスポンスと解決時間を短縮します。

解析の旅に出かけよう

ESQL、トランスフォーム、ジョイン、マルチステップクエリに興奮しましたか？私たちも同じです。Elasticチームはこれらの機能を開発し、リリースに向けて準備を続けていますので、今後のニュースにもご注目ください。このソリューションを誰よりも早く試してみたいとお考えですか？ディスカッションフォーラム　や Elastic コミュニティの Slack チャンネルからご連絡ください。新しいクエリ言語、コンピュートエンジン、クエリベースの調査ワークフローの方向性を形作るために、ぜひ皆様のご意見をお聞かせください。
※ この投稿に記載された機能または性能のリリースおよびその時期は、Elastic の独自の裁量に委ねられます。現在提供されていない機能については、予定通りに、あるいは全く提供されない可能性があります。
元の本社ブログ

Elastic テクニカルプロダクトマーケティングマネージャー/エバンジェリスト
鈴木章太郎