ランタイムフィールド ―― Elasticのschema on read

Elastic Stack 7.11より、schema on readのサポートを開始いたしました。1つのプラットフォームで、2つのメカニズムの“いいとこ取り”ができます。1つは従来からユーザーに愛用されていて、パフォーマンスとスケール性にすぐれるschema on write、そしてもう1つが、クエリの定義と実行に新たなレベルの柔軟性をもたらすschema on readです。Elasticは、ランタイムフィールドという名称でschema on readを実装しています。

ランタイムフィールドを使うと、クエリ時だけにデータ値を求めるフィールドを作成することができます。インジェスト時にすべてのフィールドが一律にインデックスされるのではなく、どのフィールドをインデックスするか、どのフィールドをランタイムに、つまりクエリ実行時に演算するかをあらかじめユーザーが指定することができます。ランタイムフィールドを使うとデータの再インデックスを行う必要がなく、まったく新たなユースケースもサポート可能です。具体的には、ログファイルフォーマットの変更や、インジェスト時にインデックスされていない新規フィールドに対するクエリの実行、インデックスマッピングに含まれるエラーの修正、定期的なインデックスの準備や仕上げ作業の反復に使うことができます。

「schema on writeかschema on readか？」 ―― 両方あって、どっちもいい

今後も、Elasticsearchがデータを取り込む際にデフォルトの方法はschema on writeのままです。つまり、ドキュメントのすべてのフィールドがインジェスト時にインデックスされます。これこそが、返されるデータ量や実行するクエリ数を問わず、Elasticのプロダクトが検索をすばやく実行できる理由です。こうしたメリットは、ユーザーからみたElasticの魅力の大きな部分を占めています。

「どのようなデータなのか」がインジェストする前からわかっている場合、schema on readは非常にうまく機能します。この場合ユーザーは、インデックスマッピングに完璧なスキーマの定義を作成できます。そしてschema on readでインデックスにクエリをかけると、このスキーマの定義に厳密に従うことになります。しかし、現実世界のデータは頻繁に変化します。たとえば、新たなデータソースが加わることもあります。インデックスした後でもデータを動的に抽出できる、あるいは新規フィールドにクエリできる、そんなフレキシブルなレイヤーがあれば、仮にパフォーマンスに軽微な犠牲を払ったとしてもなお、計り知れない価値を引き出すことができます。 

これがまさにschema on readを導入した理由です。schema on readを使う場合、タイムスタンプやレスポンスコードなど特定の必須フィールドを除いて、データをインデックスせずに生の形式でインジェストできます。他のフィールドは、データに対してクエリを実行する時にすばやく作成できます。ユーザーはデータについて深い知識を事前に入手する必要がなく、また将来、このデータに対してどのようなクエリが投げかけられる可能性があるか、いちいち予測する必要がありません。データ構造はいつでも、つまり、ドキュメントがインデックスされた後でも変更可能です。

今回Elasticは、schema on readを独特な形で導入しました。まずランタイムフィールドは、同じElasticsearchプラットフォームに組み込まれています。ユーザーがこれまで使ってきたアーキテクチャーやツール、インターフェースとまったく同一です。つまり新規のデータストアや言語、コンポーネントを使うことはなく、手順に一切のオーバーヘッドが生じません。さらにschema on readとschema on writeは互いに連携し、シームレスに補い合う形で動作します。これにより、どのフィールドを、クエリが要求した際に演算するか、またどのフィールドを、ドキュメントがElasticsearchにインジェストされる際にインデックスするか、ユーザーが決めることができます。 

言ってみれば、単一のスタックで2つのメカニズムの“いいとこ取り”が可能です。要は、ユーザーがschema on readとschema on writeを組み合わせる方法を手軽に決定して、ユースケースに最適な形で活用できる、ということです。 

データのバリューを引き出す、多数の新手法

フィールドをランタイムに定義し、すぐに使用できます。ここからは、schema on readが役立つ具体的なシナリオをいくつかご紹介します。

インデックス済みドキュメントに新規フィールドを追加する

「ドキュメントにフィールドを追加」する機能は、ドキュメントがインジェスト、およびインデックスされた時点で存在しなかったニーズを満たすための典型的な要件となります。完全に新規のフィールドを追加したいという場合もあれば、単に他のフィールドから演算（あるいは抽出、変換）するためにフィールドを追加したいという場合もあるでしょう。たとえば、メッセージフィールドの日付を曜日に変換して表示するとか、client.addressフィールドからIPアドレスを抽出してマップ可視化に使えるようにする、といったことです。どちらの場合も、ランタイムフィールドを追加するだけで、インデックスマッピングをアップデートしたり、ドキュメントを再インデックスするよりもはるかに高速に解決できます。

エフェメラルフィールドを使う

クエリや可視化のコンテクストにしか存在しないエフェメラルなフィールドを定義すると、たとえばアナリストなどは、ドキュメントインデックスに影響を及ぼしたり、同じデータを使う他の担当者の作業を上書きしたりすることなく独自の領域内で作業することができます。ニーズに応じて自律的にデータを調整するために必要な機能が提供されると、各ユーザーから管理者権限を持つユーザーにインデックス変更をリクエストしたり、リクエストの承認や完了を待つ必要がなくなり、コストの抑制や生産性の向上に寄与します。

インデックスのエラーを修正する

インデックス済みフィールドをランタイムフィールドでシャドーイングして、ドキュメントがインジェストされた際に生じたエラーをすばやく修正することができます。この機能があると、インデックス済みドキュメントを一層活用できるだけでなく、わずらわしいQAサイクルが必要なくなり、コストを減らして、ドキュメントを高速に読み込むことができます。

データプレパレーションを反復的に行って完成度を高める

新規ユーザーがデータソースをセットアップしてデータのインジェストを開始する際、どのようにインデックスマッピングを定義して仕上げるかの全体像をうまく掴めないことがあります。ランタイムフィールドが登場したおかげですべてのフィールドをあらかじめインデックスする必要がなくなり、また、ランタイムフィールドはニーズに応じて少しずつ追加できます。セットアップの後、ユーザーは時間をかけてインデックスのサイズや、様々なクエリの頻度、およびパフォーマンスを観測できます。「最も頻繁に実行されるクエリのパフォーマンスが、ピーク時に最適な水準に満たない」となった場合は、頻出のクエリで使われるランタイムフィールドの一部をインデックス済みフィールド転換することができます。このワークフローを採用すると、新規データソースの導入を大幅に高速化できるほか、インデックスサイズが下がり、インジェストスピードが上昇して、コストを抑制できます。

7.11 ― ベータ版ランタイムフィールド

7.11リリース現在、ランタイムフィールドはベータ提供されています。ランタイムフィールドはインデックスマッピングに、インデックス済みフィールドと並行して定義できます。ランタイムフィールドを定義するために必要なのはデータタイプと、クエリ時にフィールド値を求める方法を指定するPainlessスクリプトだけです。このPainlessスクリプトでは、regexを使用できます。また、スクリプトを使用せずにランタイムフィールドを定義することもできます。この場合、システムでは値と同一の名前を持つ_sourceフィールドの値が使用され、ユーザーはElasticsearch APIを使ってランタイムフィールドにクエリをかけます。このElasticsearch APIの使い方は、Query DSL経由でインデックス済みフィールドにクエリをかける時と同じです。さらに高速な方法として、クエリ自体の中でランタイムフィールドを定義し、そのクエリの範囲内で演算するというやり方もあります。

Kibana 7.11で、ランタイムフィールドは、KQL（Kibana Query Language、Kibanaクエリ言語）経由でエクスポーズされます。ユーザーは、インデックス済みフィールドに対する操作と同様に、ランタイムフィールドに対してKQLのクエリやフィルターを実行することができます。

ランタイムフィールドに関する今後の見通し

7.11リリースではランタイムフィールドを導入するための基本的な機能を公開していますが、ユーザーにより包括的なエクスペリエンスを提供するべく、Elasticは現在も多数の機能開発を進めています。将来的にランタイムフィールドはKibanaに完全に搭載され、DiscoverとLensの双方での検索や探索に対応する予定です。インデックスマッピングに定義されるランタイムフィールドをインデックス済みフィールドと共に表示して、インデックスパターンを作成することも可能になる予定です。これにより、ランタイムフィールドとインデックス済みフィールドを自由に組み合わせる可視化を簡単に構築できるようになります。

またKibanaのクエリインターフェースで直接ランタイムフィールドを定義、およびテストするためのUIエディターの公開も予定されています。このエディターは、Kibana上の多様なアプリで提供される見通しです。このUIエディターを使えば、実行するクエリや可視化の画面を操作するだけで、いつでもすぐにランタイムフィールドをすばやく作成できます。分析データの処理をすべて自分で行いたいアナリストなどに最適です。 

さらにElasitcでは、ランタイムフィールドでインデックス済みフィールドを上書きした後、ランタイムフィールドを転換してインデックス済みフィールドに戻す機能の追加も予定しています。この機能は、時間をかけて段階的にデータプレパレーションやインデックスの完成度を高めることを重視するユースケースで大いに役立ちます。この他に、クエリ時に外部インデックスからデータをエンリッチできる、Grok UIエディターも登場する予定です。 

シンプルかつパワフルなschema on readの実装で、パフォーマンスと柔軟性のバランスを最適化できるようになりました。schema on readは、Elasticの代名詞でもある従来のschema on writeメカニズムの機能を補完しながら、データインデキシングと検索に新たなアプローチを切り拓く実力を備えています。 

今すぐ使いはじめる

ランタイムフィールドは、Elasticsearch Serviceでクラスターを立ち上げて使いはじめることも、Elastic Stackの最新バージョンをインストールして使いはじめることもできます。すでにElasticsearchを導入済みの方は、お使いのクラスターを7.11にアップグレードするだけで新機能をお試しいただくことができます。schema on readを動作させる仕組みについてさらにご興味がおありの場合は、ランタイムフィールドの技術的な詳細を説明するブログ記事、またはランタイムフィールドのドキュメントをご覧ください。