リリース

Elastic Stack 6.6.0リリース

著者
Steve Kearns

6.6.0 がリリースされました!

このリリースはStackの次のような新機能があります。クラスターをスケールしたり管理するのを簡単にする機能、geoshapeのインデックスや検索をより効率よく行えるようにした保存方法、Elasticsearch SQL、機械学習、Auditbeatなどの改良です。

Elastic Cloud でクラスターを起動したり、ダウンロードして、新しい機能をお試しください。

インデックスライフサイクル管理による大規模なデータライフサイクルの管理

ロギング、メトリック、APMといった時系列のユースケースで使われている方は、時間ベースのインデックス（インデックス名に日付など）にデータを保存しています。保管しているデータをもっと費用対効果が良い方法で保存したくなります。例えば、インデックスが古くなるに従って、シャードの数を減らしたり、レプリカの数を減らしたり、より安価なハードウェアのノードにインデックスを移動したくなります。また、一定期間を過ぎたインデックスは削除するといったことも行います。クラスターの外部にあるインデックスのライフサイクルを管理するポリシーを定義する既存の方法（Curatorや独自の自動化スクリプトなど）は、制限があり、設定や監視のオーバーヘッドもあります。新しいインデックスライフサイクル管理機能は、より統合され洗練されたデータ管理の方法を提供し、ベストプラクティスを簡単に提供してくれます。

インデックスライフサイクル管理機能は、インデックスのライフサイクルを4つのフェーズに分けます。 hot, warm, cold, delete フェーズです。また、インデックスのライフサイクルポリシーを次のように定義できるようになります。

  • インデックスのスループットを最大化するためにhotノードに1つずつprimary shardを配置する
  • 既存インデックスがいっぱいになるもしくは、一定時間過ぎたらすぐに、空のindexに置き換える
  • 古いインデックスをwarm ノードに移動する。また、クエリーや保管サイズを最適化するために、シャードを1つにshrinkし、　segmentを1つにforce-mergeさせることも可能。
  • さらに安いストレージのcold ノードにインデックスを移動する

今後のリリースでは、"freeze"インデックスにもできるようになります。検索レイテンシーに対してストレージの密度をトレードするような状態に置くことを意味します。最終的に、必要でなくなったインデックスを削除できます。

インデックスライフサイクル管理によってこれらを自動で運用できるようになります。

Frozenインデックスでより大きなメモリとストレージの比率を可能に

Elasticsearchはできる限り効果的かつ高速に検索できるように最適化されています。これまでの歴史では、open(検索可能)なindexは、高速に検索が実行されるようにするために、少量ですがメモリーを使用していました。ノードに割り当てられたインデックスの数やサイズが大きい場合、これらのインデックスをopenした状態を維持するためにはより多くのメモリが必要でした。これは、JVMに割り当てることができるストレージの総量に事実上の制限があることを意味します。多くのユーザーやユースケースの場合は問題にはなりません。ですが、規制などの理由でデータを複数年にわたって長期的に保管しないといけないようなユースケースの場合に、データをオンラインかつ検索できるようにしておく必要がありますが、古いデータに対してピーク時の検索リクエストの性能は必要ありません。

Frozen インデックスは、検索のレイテンシーを落とす代わりに、ヒープとディスクの割合をより高くすることができます。インデックスがfrozenの時、ヒープを使用せず、低いオーバーヘッドで数千のインデックスを1つのノードで管理できるようにします。frozenインデックスへの検索が来た場合は、クエリがインデックスをオープンし、検索し、クローズするといった処理を順番に行います。FrozenインデックスはCloseされたインデックスとは異なり、レプリカされます。Frozenのインデックスは、ニーズに応じた性能とコストの最適な方法を選択する新しい手段になります。

Bkd-Backed Geoshapesをより小さく高速に

Bkd treeデータ構造を使用しています。5.0で、Bkd-backed geopointsが導入され、ストレージやメモリ、geopointsに対する検索の性能の改善などをもたらしました。6.6.0で、geoshapesにもBkd-basedのメリットを導入しました!検索の三冠（登録の高速化、ディスク使用量の削減、そして省メモリ）達成です！

Elasticsearch SQLがDate Histogramをサポート

Elasticsearch SQLはGAに向かって、SQLシンタックスを使用したdate histogramのネイティブサポートなどの時間に対するクエリを改善する多数の改良を行なっています。これらの改善はElasticsearch SQLの全てのユーザに対して重要ですが、Canvasユーザーに対して非常に重要であり、Kibanaで時系列のグラフを作るのが簡単になると想定しています。

Machine LearningにAnnotationsを導入

システムやセキュリティの問題の可能性を調査する時、調査や進捗を記録したいと思うはずです。システムの問題の根本的な原因や解決の手順を記録することです。本リリースから、Machine LearningUIに直接、他のユーザーにも見える形でannotation（注釈）を作成できます。これにより、より手軽にコラボレーションし、Kibanaを離れることなく行なった作業を記録できます。

Elastic APM に新しいAgentメトリックを追加

APMがバージョン6.6でエージェントのメトリックを導入します。最新版のエージェントが、システムやプロセスレベルのCPUやメモリのメトリックをトレースやエラーと一緒に自動的に記録してくれます。

その他のニュースは、Distributed Tracing（分散トレース）がGAされ、全てのエージェントがOpenTracing互換になりました。APM UIが、APMから簡単に関連するLoggingやInfra UIに移動可能になり、また、Javaエージェントが2つの新機能を導入しました。詳細についてはこちらのブログをご覧ください。

さらに、Elastic APMがElasticsearch Service(read blog)とElastic Cloud Enterprise(read blog)で利用可能になりました。

最後ではありません、まだあります。

ご紹介した新機能以外にも、Beats、Logstash、Kibanaでその他の新機能や改善があります。

Auditbeatに、システムからセキュリティに関する様々な情報を収集するための新しいsystemモジューうるが追加されています。このモジュールでは、OS、プロセス、ソケット、特定のホストに存在するユーザーといった情報が含まれます。Auditbeatのsystemモジュールについてはこちらの詳細ブログをご覧ください。

Machine learningに、Auditbeatのデータのための機械学習のジョブがインストールされた状態になります。これにより、auditデータの異常検知をより簡単に始めることが可能になります。

FilebeatにNetFlow inputが追加されました。これを使用すると、Netflow、IPFIXのレコードをUDP経由で収集できます。NetFlow v1, v5, v6, v7, v8, v9 および IPFIXをサポートします。

Beats Central Managementを使用した場合に、MetricbeatとFilebeatの一部の設定変更を受け付けなくすることが可能になりました。これにより、リモートの設定で変更可能なものを指定可能になります。セキュアな操作を強化するために、デフォルトでconsoleやfileへの出力変更をブロックします。

Logstashでは、Javaの実行エンジンがより効率的になりました。これは、6.1でベータとしてリリースされましたが、本リリースでGAとなります。

Kibanaでは、待ち望まれていた複数へのElasticsearchノードの接続がKibanaで可能になりました。これにより、Kibana <> Elasticsearch接続の単一障害点が無くなります。可視化機能では、KibanaのダッシュボードをPNGで出力できるようになりました。その他の変更や詳細についてはKibana 6.6 release highlightsをご覧ください。

ぜひお試しください。

Elastic Cloud でクラスターを起動したり、ダウンロードして、新しい機能をお試しください。