Elastic、Elasticsearchの新機能、Kubernetesの可視化を発表

オープンソースの検索エンジンElasticsearchを開発するElasticは、サンフランシスコで年次カンファレンス、Elastic{ON}を開催した。今回の記事では、Elasticsearchの新機能とモニタリングのためのインフラストラクチャーとなるBeatに関するセッション、そしてeBayの事例のセッションを紹介する。

カンファレンス2日目の最初に行われたのは「What's Evolving in Elasticsearch」と題されたセッションで、ここではElasticsearchチームのテックリードであるエンジニアが最新機能を解説した。

最初に解説したのは、初日のキーノートでも紹介されたData Rollupsだ。これはログのデータ量が爆発的に増加してしまうことに対する対処方法として、データを集約してサイズを圧縮する機能であるという。

複数のクラスター上に異なるバージョンで実装されたElasticsearchにおいて検索を可能にするCross Cluster Searchは、5.xから最新の7.xをまたがって検索が可能になる機能だ。

Cross Cluster Searchの概要

検索においてSQLのシンタックスが利用可能になる機能は「SQL Client」と呼ばれるもので、X-Packに含まれる。この他にも多くの機能がX-Packで実装されることになるが、初日のキーノートでもあったように全てのソースが公開されることは記憶にとどめておくべきだろう。

ElasticsearchのElastic、年次カンファレンスで「全てのコードを公開する」と宣言

SQL ClientでSQLを用いた検索が可能に

また実装の方法もCLI、JDBCだけではなくODBCによる接続も可能になることから、エンタープライズにも評価されるのではないだろうか。

OBDCからも利用することが可能になる

運用面からは、SAML（Security Assertion Markup Language）によるシングルサインオンが可能になるという機能もエンタープライズには高く評価される機能だろう。この辺りは、顧客の声を充分に反映した開発が行われていることを感じさせる内容となった。

SAMLを使ったシングルサインオン

このセッションは、すでにElasticsearchを使っているエンジニア向けということもあり、かなり内容を省いて駆け足で概要を紹介するというものだったが、ElasticがコアであるElasticsearchにおいても開発のスピードを緩めずに、オンプレミスにおける検索エンジンのデファクトスタンダードの地位を強化していることを感じることができた。

拡がるBeatのエコシステム

次に紹介するのは、買収したPacketbeatのエンジニアによるBeatの解説だ。

Beatの解説を行うセッション

Beatは、アプリケーションパフォーマンスモニタリングとしてElasticが新たに実装した機能のインフラストラクチャーと呼べるもので、ネットワークやファイルシステムなどのコンポーネントからメトリックスを収集してモニタリングを行うためのシステムである。このスライドにある「libbeat」というライブラリーをベースにして、様々な型のBeatが開発されている。

libbeatとその上に実装される様々なBeat

またBeatにはElasticの開発によるもの以外にも、コミュニティによって開発されたものが多く存在するという。Elasticの製品は、主な開発をElasticのエンジニアが行うことが基本だが、特殊なコンポーネントなどに対するモジュールは外部のコミュニティに任せるという辺りは、合理的な判断だろう。

コミュニティによって開発されたBeatモジュールは60以上にもなる

公開されてから3年で、すでに5000万回以上ダウンロードされていることから、Beatの利用者も確実に増加していることが分かる。

また特に最近、非常に注目されているコンテナとKubernetesに関しても、Beatが対応していることを紹介した。ここでは、Metricbeatを使ってKubernetesクラスターの多くのメトリックスを収集できることを解説した。

Kubernetesクラスターをモニタリングできる

実装の方法はノードの中にデーモンとして配置して、メトリックスを収集するというもののようだ。だが、サービスメッシュのIstioのように、「KubernetesのPodの中にサイドカーとして配置することも可能である」というコメントをElasticのエンジニアから得られた。この辺りは別途、解説を行いたいと思う。

ノードに配置されたMetricbeatとFilebeatがデータを収集する

ノードをまたがって複数のデーモンとして配置することで、クラスター全体のモニタリングも可能になる。この辺りは、Kubernetesだけに集中して開発が進むIstioと、一般的なファイルシステム、アプリケーションなどもカバーするBeatの発想の違いが表れているということだろう。必ずしも全てのシステムが一度にマイクロサービス化されるわけではないことを考えると、BeatのようにKubernetesによるコンテナのシステムからモノリシックなシステムまで横断的にモニタリングができることは、現実的な仕様と言えるかもしれない。

クラスター間を横断するようにノードにデーモンを配置

またビジュアライゼーションのツールであるKibanaを通して、Kubernetesの状況を可視化することも可能になっている。ここではノード単位、namespace単位、そしてPod単位のビューが可能だ。

Kubernetesのノード、namespace、Podを可視化できる

この例ではRole及びMachine Typeでフィルターされており、メタデータを使って様々な可視化が可能だ。より詳細な情報をドリルダウンして見ることが可能になるのは、Kibanaの得意な部分と言っていいだろう。

より詳細な可視化も可能

次に紹介したAuditbeatは、OSのカーネルとファイルシステムを監視するモジュールとして紹介されたもので、メトリックスを直接Elasticsearchに送信できることと、User IDを可読可能なユーザーネームとして認識できる点が強調された。

Auditbeatの概要

Auditbeatが備えるファイルシステムに対する変更などを監視するFile Integrityは、全てのファイルに対してハッシュ値を作成し、変化を常に記録することで、悪意のあるプログラムの挙動などを検知できるという。

File Integrityの概要

ユースケースとして、2017年に1億人以上の個人情報が漏洩したとして大きな問題となったEquifaxのデータ漏洩を例に挙げて、「もしもAuditbeatを入れていればこんなことにならなかったのに」と解説した。

Equifaxのデータ漏洩はAuditbeatを入れていれば起こらなかった？

＜編注：2018-03-21 01:30更新＞一部の社名が間違っておりましたのでお詫びして訂正致します。