Elastic (ESTC) の技術的な企業分析

Elasticsearchは、膨大な量のデータを非常に高い可用性で処理するために構築された新しいデータベースで、多くのマシンに分散してフォールトトレラントとスケーラビリティを実現し、シンプルかつパワフルな API を維持しながら、あらゆる言語やフレームワークからアプリケーションがデータベースにアクセスできるようになっている。

Apache Luceneをベースに構築された水平方向にスケーラブルな分散型データベースは、シンプルかつパワフルなAPIでテラバイトのデータに対応したフル機能の検索体験を提供する。多くの企業がElasticsearchを使用して、セットアップが簡単で拡張性が高く、クラウド向けに構築された強力な検索機能をアプリケーションに展開するのに役立っている（弊社のサイトにはサイト内検索がないが、おそらく弊社も将来的にはElasticsearchを利用することになるだろう）。

歴史と技術基盤

Elasticは検索企業である。長年にわたり、インターネットベースのソフトウェア企業に適用される検索の概念は大きく進化してきた。元々の最も基本的な使用例はテキスト検索であり、検索ボックスにいくつかのキーワードを入力して結果を得ることは誰もがよく知っている。

しかし、Elasticは汎用的な検索機能を構築した最初の企業ではなかった。Googleのようなプロプライエタリなソリューションはあったものの、最初の汎用的なオープンソース検索技術はLuceneだった。Elasticsearchでは、その基礎としてApache Luceneを使用している。Luceneは1999年にApache Hadoopも構築したオープンソースの第一人者であるDoug Cuttingによって開発された。Luceneは汎用的なオープンソースの検索エンジンソフトウェアライブラリで、元々はJavaで書かれていたが、他の主要なプログラミング言語に移植されている。Luceneは2005年にApacheのトップレベルのプロジェクトになった。Luceneを補完するために、CuttingはオープンソースのウェブクローラーであるNutchも構築した。

Apache Luceneプロジェクトは10年以上にわたって成長を続けており、今では強力でありながら統合が容易なオープンソースの検索ライブラリだ。検索ライブラリとしてのLuceneは、その機能をアプリケーションで利用できるようにするために、インターフェースでラップされていなければならない。このようなインターフェイスは、さまざまなプラットフォームやユースケースに合わせて多くのものが作られてきた。

しかし、Apache Solrのようなインターフェースは、単一のサーバがデータのインデックス作成と問い合わせの全作業負荷を処理できるような世界のために設計されている。データ量が限界を超えて増加し始めると、Solr（および Lucene と同様のインターフェイス）は使い勝手が悪くなり、RDBMSシステムで発生するシャーディング、レプリケーション、クエリディスパッチと同じ問題が再び発生し始める。そして、RDBMSの世界でこれらの困難に対処するための様々な方法が存在するように、Solrを中心としたシャーディングの作成と配布のための様々なツールが存在する。

しかし、ビッグデータデータベースに対する正しい解決策は、RDBMSからNoSQL技術に移行することを意味するように、Luceneのスケーリングに対する正しい解決策は、SOLRのようなツールから離れて、テラバイト級のデータを水平方向にスケーラブルに、分散して、フォールトトレラント（障害許容）な方法で扱うためにゼロから構築されたツールを使用することだ。それがElasticsearchだった。

2000年代初頭、2001年のドットコム不況から回復している間に、いくつかのインターネットベースの企業がウェブ上でビジネスを構築していた。大規模な運用検索機能を必要とする場合には、Luceneの他に選択肢がほとんどなかった。

Luceneは検索機能を構築するのに適したライブラリ群を提供していたが、サーバーに導入してすぐにコンテンツのインデックス作成や検索を開始することはできなかった。Luceneを「サーバー」 （ここでは HTTPのような中立的なプロトコルでリクエストに応答することを意味する）にするためには、このような仕組みやインフラストラクチャを処理するための追加機能が必要となる。

その頃、Elasticの創業者であるシェイ・バノンは、独自の検索ソリューションに取り組んでいた。彼は妻の料理レシピのコレクションのための検索エンジンを構築しようとしていた。2004年、彼の最初の製品はCompassと呼ばれた。Compassのカイゼンに取り組んだ後、彼は統合のための共通のインターフェイス、すなわち JSON over HTTPをサポートする分散型ソリューションを作りたいと考えた。これがElasticsearchとなり、2010年にリリースされた。バノンはコアとなる検索ライブラリにApache Luceneを利用することも選択した。

Elastic NVは、Elasticsearchを中心とした商用サービスや製品を提供するために、2012年にShayと他の3人によって設立された。その頃、他にも2つの関連するオープンソースプロジェクトが台頭してきていた。1つ目はLogstashで、様々なソースからログデータを収集し、それを共通のフォーマットに変換し、その出力を開発者が選択したElasticsearchクラスタに転送するためのツールを提供していた。2つ目は、Elasticsearchのデータを可視化する方法を提供するKibanaだった。これら2つのプロジェクトの背後にある開発者たちは、Elasticsearchの会社に参加することを決めた。これらのプロジェクトを一つの製品群にまとめると、ELK (Elasticsearch, Logstash, Kibana) Stackと名付けられた。同社はElasticsearch製品との混同を減らすために、Elasticとしてリブランドされた。

同社は新しい製品機能を追加し続けた。監視用のMarvelとセキュリティ用のShieldという2つの商用プラグインをリリースした。2015年には、ソースサーバからLogstashとElasticsearchにあらゆる種類のデータ（ネットワーク、ログ、メトリクスなど）を送信するための軽量シッパーのセットを提供するBeatsがElasticに追加された。このコードはすべてパッケージとしてダウンロードできるようになっており、エンジニアリング組織が自分たちで実行できるようになっていた。導入を簡単にするために、ElasticはElasticsearchとKibanaをAWS上でサービスとして利用できるようにし、これをElastic Cloudと名付けた。

2016年には、すべての製品がElastic Stack 5.0と呼ばれる単一のパッケージにバンドルされた。これは、完全にテストされ統合されたオファリングを導入したことで、大きな前進となった。このリリースでは、商用プラグイン（Shield、Marvel、Watcher）をX-Packと呼ばれる単一のバンドルに分離することも正式に行われた。機能には、コアとなるElastic Stackのセキュリティ、監視、アラート機能が含まれていた。

2017年、ハイブリッドクラウドソリューションの台頭に伴い、Elasticはスタンドアロン版のElastic Stackをリリースし、顧客企業が自らElastic Stackを実行するために利用できるようにした。これは、Elastic Cloud Enterprise（ECE）と呼ばれた。ECEは、どのようなホスティング環境においても、複数のクラスタにまたがるすべてのElastic製品の管理とオーケストレーションを容易にした。

2018年、Elasticは商用のX-Pack機能をオープンソース化し、これらをElasticsearch、Kibana、Beats、Logstashのデフォルトディストリビューションと一緒に出荷することを決めた。これにより、開発者コミュニティは、無料のコア機能と同じように、商用機能に関連するソースコードを検査し、貢献することができるようになった。これがElasticの「オープンコア」ソフトウェアライセンスモデルの基礎となった。

製品概要

Elasticの印象的な側面の1つは、ソフトウェア企業が成功するための特徴の1つとしてしばしば挙げられるもので、製品開発の動きが速いことだ。これは、買収と有機的な開発の両方によって推進されている。その証拠に、投資家はElasticのウェブサイトのプレスリリースセクションを見ると、急速なペースで発表が行われているのがわかるだろう。

Elasticは基本的に「検索」企業である。検索の範囲は、単にコンテンツサイトのフルテキスト検索ボックスを動かすだけだった初期の頃から、劇的に拡大している。ユースケースは現在、可観測性（ログ分析）やSIEM（セキュリティ情報とイベント管理）に加えて、多くのタイプのエンタープライズ検索体験にまで拡大している。Elasticは、これらすべての検索体験に対応するためにElastic Stackを作成した。具体的には、Elasticsearch、Kibana、Beats、Logstashにより、開発者はあらゆるソースからあらゆる形式のデータを取得し、それを迅速かつスケーラブルな方法で変換、インデックス化、分析、可視化することができる。観測性やセキュリティ機能の多くは、サーバーログの粒度の細かい分析を伴うため、これらは検索のための自然な拡張機能だ。

Elasticのソリューションは、顧客の好みや既存のインフラ基盤に応じて、3つの異なる構成で展開することができる。これにより、顧客はホスティングアプローチに柔軟性を持たせることができ、多くの企業がクラウドに完全に移行していない（あるいはすぐに移行する予定もない）ことを認識している。

Elastic Cloudを利用することで、顧客はホスティングをすべてElasticにアウトソースすることができる。この場合、Elasticは希望するクラウドプロバイダーでElastic Stackサービスをプロビジョニングして実行する。AWS、GCP、Azure、Alibaba Cloud、Tencent Cloud上でのデプロイがサポートされている。顧客はKibanaで基本的なElasticsearchサービスを実行できる。これは16ドル/月という低価格で提供されている。一般化されたElasticsearchサービスは、エンタープライズサーチ、可観測性、またはセキュリティなど、関連するすべてのソリューションに適用することができる。価格設定は、スタンダード、ゴールド、プラチナ、エンタープライズの4つの階層のオプションに基づいている。上位レベルのオプションには、サポートレスポンス、セキュリティ、エンドポイントプロテクション、機械学習、カスタムプラグインが含まれる。

特定の検索のユースケースに対応するための代替として、ElasticはApp Search Serviceを月額23ドルという低価格で提供している。このデプロイメントは、オブザーバビリティやSIEMではなく、ユーザーアプリケーションに関連する検索機能のためにカスタマイズされている。これは、スキーマレスのデータインジェストとカスタム管理ダッシュボードを提供し、顧客が検索体験を迅速に実現できるようにします。データのインデックス作成は、APIクライアントの1つを顧客のアプリケーションにプラグインすることで行うことができる。インデックス作成が開始されると、自動的に検索機能が利用可能になる。

すぐに使えるサイトサイト検索ソリューションを探しているユーザー企業には、ホスト型のElastic Site Search Serviceがある。これは79ドル/月からと少し高価だ。しかし、カスタム開発を必要とせずに、サイト検索機能に必要なすべての機能を実行する。顧客はウェブサイトのクロールを開始するだけで、サイト検索サービスが残りの部分を処理する。開発者は、検索ボックスを表示し、結果ページを返すために数行のコードを追加する。このサービスは、時間の経過とともにどれだけのコンテンツがインデックスされるかに関係なく、自動的にスケーリングされる。価格は、インデックスされたドキュメントの量、クロールの頻度、サポートレベル、ログの持続性、アドオン機能への要望に応じて上昇する。

Elastic Stackの製品優位性

他にも、Elastic Stackが人気を博しているのは、ログ管理と分析の分野でのニーズを満たしているからだ。最新のアプリケーションとその上に配置されたITインフラストラクチャを監視するには、エンジニアが高度に分散され、動的でノイズの多い環境を監視するという課題を克服するためのログ管理と分析のソリューションが必要だ。

Elastic Stackは、複数のデータソースからデータを収集して処理し、データの成長に合わせて拡張可能な1つの集中型データストアにデータを保存し、データを分析するための一連のツールを提供する強力なプラットフォームをユーザーに提供することで、その手助けをしてくれる。

Elastic Stackはオープンソースだ。これはエンジニア組織がオープンソース製品を好む中、この点だけでもElastic Stackの人気の理由になるでしょう。オープンソースを使用することで、企業はベンダーのロックインを回避し、新しい人材をより簡単に採用することができる。また、オープンソースとは、活発なコミュニティが常に新機能やイノベーションを推進し、必要に応じて支援してくれることを意味している。

確かに、Splunkはこの分野のマーケットリーダーとして長い間活躍してきた。しかし、Splunkの数多くの機能は、特にSaaS製品やテック系スタートアップなどの小規模企業にとっては、高価な価格に見合わないものになってきている。Splunkの顧客数は約15,000人であるのに対し、Elastic Stackは1ヶ月にダウンロードされる回数がSplunkの総顧客数の何倍にもなる。Elastic StackはSplunkのすべての機能を持っているわけではないかもしれないが、分析に必要なベルやホイッスルは必要ない。Elastic Stackはシンプルだが堅牢なログ管理・分析プラットフォームであり、価格は数分の一だ。

今日の競争の激しい世界では、組織はアプリケーションのダウンタイムやパフォーマンスの低下を1秒たりとも許されない。パフォーマンスの問題はブランドにダメージを与え、場合によっては直接的な収益の損失につながる。同じ理由で、組織も同様に妥協する余裕はなく、規制基準に準拠していない場合は、パフォーマンスの問題と同様に、多額の罰金が課せられ、ビジネスにダメージを与えることになる。

代表的なユースケースも含めて、3つの製品ソリューションをそれぞれ詳しく見ていこう。

企業向け検索

Elastic Enterprise Searchを使用すると、開発者はWebサイト、カスタムアプリ、またはEコマースストア全体で検索体験を実装することができる。また、チームのワークコラボレーションツールで生成されたドキュメント全体の検索を容易にするために、内部的に適用することもできる。コンテンツソースには、Google DriveやSalesforceが含まれる場合がある。データインポートコネクタは、多くの一般的なコラボレーションツールで利用できる。

エンタープライズ検索は、サイト検索に向けて適用することができる。これは、家庭用のソリューションやGoogleカスタム検索を置き換えることができる。サイト検索のクロール頻度は、新しいコンテンツを自動的に取り込む機能で設定可能だ。サイト検索は、検索アクティビティの分析ダッシュボードを内蔵しており、さらなる調整のためのフィードバックループを可能にする。

App Searchでは、開発者は、製品レコメンデーションやマッピング機能のように、ユーザーアプリケーションのためにカスタマイズされた検索体験を作成することができる。データのインジェストとインデックス作成の側では、ステミング、タイポトレランス、ビッグラムなど、期待されるすべての機能がサポートされている。同様に、検索クエリについても、同義語の設定、ブースト、関連性モデルの調整、個々のフィールドへの重みの割り当てなどの一般的な機能がすべて設定可能だ。これらの機能により、開発者は検索と精度を微調整することができる。

基本機能

• REST API。ElasticSearchはREST APIを介してオブジェクトを保存/取得する。便利なPUT、POST、GET、DELETE APIが提供されており、バージョンチェック(PUT時に任意)、IDの生成(POST時に任意)、独自の書き込みの読み込み(GET時)を実装している。これがキーバリューストアになっている。
• キーバリューストア。ElasticSearchでは、すべてのデータは定義されたインデックスと型を持っている。インデックスはドキュメントの集合体やデータベースのテーブルのようなものと考えることができる。しかし、ここでは、インデックスに追加されたドキュメントには、定義された構造とフィールドの型がない。オブジェクトは型を持ち、インデックスに入る。REST APIを介して実行時にインデックスと型を作成する。
• マルチテナンシー。インデックスの作成、更新、取得、削除が可能だ。インデックスごとにシャーディングやレプリケーションを設定することができます。つまり、ElasticSearchはマルチテナントで柔軟性が高いということだ。
• マッピング：動的マッピング、またはあなたが提供するマッピング（推奨）のいずれかを使用。つまり、検索APIを介してドキュメントを検索することができる。

可観測性 (Observability)

Elastic Observabilityソリューションにより、IT組織は他のシステムのサーバログやイベントを単一のビューに統合して監視とアラートを行うことができる。システムを「観察可能」にすることで、オペレータは長い応答時間やエラーなどの望ましくない動作を検出することができる。さらに、問題が検出されると、オブザーバビリティ・ツールは、根本原因を特定するための動作に関する十分なデータを提供する（イベント・ログ、アプリケーション・エラー・トレース、リソース使用率など）。

従来のDevOpsチーム（システムのアップタイムを担当するチーム）が直面していた課題の1つは、可観測性データが異なるシステムで収集され、表示されることが多いということだった。Datadogに関するブログでも触れたが、最低限、1つのシステムがサーバーログを収集し、それらを集約し、その上に検索インターフェースを提供していた（SplunkやPaperTrailなどを使って）。2つ目のシステムでは、サーバーにエージェントが埋め込まれており、アプリケーションリクエストの処理トレースを収集していた（New Relic、Dynatraceなどを使って）。顧客がWebサイトのリクエストでエラー応答を受信するなどの問題が発生した場合、DevOpsチームのメンバーは根本原因を見つけるために両方のシステムを検索しなければならない。

可観測性ソリューションの最新トレンドは、関連するすべてのデータを単一の運用データストアに統合し、アプリケーションのパフォーマンスを直感的なユーザー・インターフェースで1つのビューとして提供することだ。現在の理想的なケースは、システム・オペレータがアプリケーションのパフォーマンスに関連するすべてのデータを、サーバからのログ・エントリ、アプリケーション・リクエストを処理するためのトレース・データ、または時系列でのリソース使用率のメトリクスのいずれであっても公開することだ。そして、問題が表面化した場合、オペレータは、根本原因をトラブルシューティングするために、1つのインターフェイスですべてのソースデータを素早くドリルダウンすることができる。

これらをすべて1つの画面で見ることができるようになったことで、時間を大幅に節約することができた。しかし、これを行っているのはElasticだけではなく、データドッグも同様のアプローチで全体的な観測性を追求している。

チームがアプリケーションの典型的なパフォーマンスに慣れてくると、可観測性は将来的に問題が発生する可能性があることを「予測」するのに役立つ。これは、過去のパフォーマンスデータを調査し、正常なパフォーマンスの予想範囲を設定し、異常な動作を示すデータが入ってきた場合に警告を発するアルゴリズムや機械学習プロセスに基づくことになる。

Elastic Stackは、観測性の課題に対処するための理想的なソリューションだ。これにはいくつかの理由がある。第一に、Elasticは転置インデックスによる基本的なテキスト検索を超えた（検索ボックスに "error "と入力するだけのユースケース）。数年前には、パフォーマンスメトリクスデータの主要なフォーマットである高密度の数値時系列の書き込みと取得に最適化されたカラム型データストアを追加しました。このカラムラーデータストアは、サーバーのログから抽出したデータを、文字列トークンと数値の両方で構造化するために使用される。データの収集、抽出、およびフォーマットは、Metricbeatと呼ばれるプラグインを使用して自動化される。これらの機能強化により、多くのユーザーがElastic Stackを適用してログだけでなくメトリックデータをインジェストし、本番システムの完全なビューを作成するようになった。

その最後のピースとして、Elasticは2018年にElastic APMを導入しました。APM（アプリケーションパフォーマンスモニタリング）は、ユーザーのリクエストに対するアプリケーション処理の詳細なトレースを提供する。これにより、長いデータベースクエリ時間やサードパーティへのAPIリクエストのタイムアウトなど、分散システムのボトルネックを迅速に特定することができる。問題箇所の特定が容易になるため、これらの読み出しの視覚的な側面が鍵を握っている。データは統合され、あらかじめパッケージ化された直感的なダッシュボードに表示される。この可視化機能はKibanaによって提供されている。トレースデータは、インフラストラクチャ・ログ、サーバ・メトリクス、セキュリティ・イベントと共存しており、1つの画面ですべてを確認することができる。

ダッシュボードは現在のアクティビティをリアルタイムで見ることができますが、DevOps担当者がそれを見て一日を過ごすことはない。Elastic APMでは、主要なパフォーマンス値にしきい値を設定し、値が範囲外になるとアラート通知を生成することができる。さらに、過去のパフォーマンスデータをモデル化し、しきい値を自動的に設定する機械学習機能も利用できる。

最後に、Elastic APMは、Java、Go、Node.js、Python、Ruby、.NET、Javascript（ブラウザアプリ用）など、さまざまな開発フレームワークに対応したソフトウェアエージェントを提供する。これにより、データ収集が容易になり、他のAPMソリューションで確立された標準に準拠している。

可観測性の重要性が高まっている理由

今日の競争の激しい世界では、組織はアプリケーションのダウンタイムやパフォーマンスの低下を1秒たりとも許されない。パフォーマンスの問題はブランドにダメージを与え、場合によっては直接的な収益の損失につながります。同じ理由で、組織も同様に妥協する余裕はなく、規制基準に準拠していない場合は、パフォーマンスの問題と同様に、多額の罰金が課せられ、ビジネスにダメージを与えることになる。

アプリケーションが常に利用可能で、パフォーマンスが高く、安全であることを保証するために、エンジニアはアプリケーションとそれをサポートするインフラストラクチャによって生成されるさまざまなタイプのデータに依存している。このデータは、イベントログであれメトリクスであれ、あるいはその両方であれ、これらのシステムを監視し、問題が発生した場合に問題を特定して解決することを可能にする。

ログは常に存在しており、それを分析するためのさまざまなツールも存在している。しかし、変わったのは、これらのログを生成する環境の基礎となるアーキテクチャだ。アーキテクチャは、マイクロサービス、コンテナ、オーケストレーション・インフラストラクチャへと進化し、クラウド上、クラウド間、またはハイブリッド環境に展開されるようになった。それだけでなく、これらの環境で生成される膨大なデータ量は常に増加しており、それ自体が課題となっている。エンジニアが単にマシンにSSH接続してログファイルをgrepするだけで済む時代はとっくに終わっている。これは、1日にTBのログデータを生成する何百ものコンテナで構成される環境ではできない。

そこで、Elastic Stackのような集中型ログ管理・分析ソリューションの登場だ。この市場は以前分析したDatadogなどとの激しい競争となっている。

セキュリティ

Elastic Securityソリューションは、エンドポイントセキュリティとSIEMを組み合わせたもので、顧客はネットワークのエントリーポイントで潜在的な脅威を特定し、すべてのユーザーアクティビティを一元的に収集し、ログデータを分析して悪質なアクティビティに関連するパターンを見つけることができる。

セキュリティ分析は、大量のログデータを効率的に収集・分析する能力に基づいているため、オブザーバビリティと同様に、これはElasticにとって自然な拡張だ。必要とされる追加の洞察は、セキュリティエクスプロイトに関連したログデータの行動パターンをどのように識別するかということだった。

Elasticのセキュリティソリューションの進化について興味深いのは、顧客が最初にコアとなるElastic Stackを使用してセキュリティ監視を自分たちで構築し始めたことだ。2019年5月、Elasticは複写機メーカーのリコーが、ネットワーク上のデバイスからのログデータを集計・分析し、潜在的なセキュリティ脅威を特定するためにElastic Stackを利用していることを発表した。このケースでは、リコーはElasticソリューションエンジニアのサポートを受けてElastic Stackのコンポーネントを活用し、セキュリティ監視システムをカスタム構築した。リコーのセキュリティエンジニアが直面している脅威を理解し、それをログパターンに変換して特定することができれば、このようなポイントソリューションを構築することができたと考えられる。この実装は最終的にElasticのSIEM製品へと発展し、2019年6月に正式発表された。

SIEMの拡張はそれだけにとどまらなかった。2019年7月の7.3リリースで、ElasticはSIEMソリューションに機械学習機能を追加したことを発表した。これにより、ユーザーは特定のサイバー攻撃行動を検出するように設計された機械学習による異常検知ジョブのセットを簡単に有効化して実行できるようになった。検出ルールの作成が自動化され、手動で静的なルールを追加したり調整したりすることを超えていく。

2019年10月にリリースされた7.4では、Auditbeatが収集したネットワークおよびホストアクティビティデータ上の一般的なセキュリティ脅威を検出するための機械学習ジョブの数が拡張された。例としては、異常プロセスの検出、標準外のネットワークポートアクティビティなどが挙げられる。2020年2月にリリースされたElastic 7.6では、脅威の行動を示す戦術やアクティビティを自動的に検出するためのルールを100個追加した。これらは、新たな脅威に対応するために継続的に更新される。さらに、今回のリリースでは、Global 2000企業で一般的なユーザーデバイスOSであるWindowsのカバレッジが大幅に拡大された。

2019年6月、Elasticはエンドポイントセキュリティソリューションを提供するEndgameを買収する意向を発表した。Endgameは、エンドポイントの保護をアンチウイルスのように簡単にする。高度な機械学習技術を活用して、Endgameは、あらゆるスキルレベルのセキュリティオペレータが、ランサムウェアからフィッシング、標的型攻撃まで、あらゆるものを阻止し、完全な防御を提供することを可能にする。

この買収の意図は2つあると考えられる。第一に、Endgameの組織内のセキュリティエクスプロイトの専門知識は、Elasticの初期のSIEM機能を迅速に拡張することができる。おそらく、悪質なセキュリティ活動がどのようなものであるかについての深い専門知識とデータ履歴を提供しているのでしょう。この知識は、Elastic Stackに引き込まれる大量のログデータから潜在的な脅威を表面化させるために必要なパターン検出に組み込まれる可能性がある。

第二に、Elastic社の製品群を実際のエンドポイントセキュリティソリューションにまで拡張することができました。具体的には、EndgameはEndpoint Prevention, Detection and Response (EPP + EDR) 製品を提供していた。これらの製品により、企業は脅威の識別をデバイスのエンドポイントにまで拡張することができる。興味深いことに、Endgameはすでに内部でElastic Stackを使用してエンドポイントデータの収集と解析を行っていた。Endgameは、Beatsがすでにサポートしているエージェント展開インフラストラクチャをより広く、より深くカバーし、顧客はデータ収集のためにあらゆるタイプのユーザデバイスとネットワークエントリーポイントにElasticセキュリティエージェントを展開することができる。

Endgameのエンドポイントエージェントは、Elasticがすでに構築していたBeatsのデータ収集エージェントにセキュリティに特化したコンテキストを大幅に拡張する。さらに、各デバイスにエージェントを配備することで、脅威を検出し、インシデントを中央のElastic Stack監視システムに報告するのと並行して、いくつかのロジックをローカルに適用して予防策を適用することができるようになった。

同様に、Beatsのエージェントも以前は「サーバサイド」のアプリケーションスタックとネットワークデバイスに配置されていました。Endgameの買収により、ElasticはこれをWindows、Mac、Linux、Solarisなどのさまざまなオペレーティングシステム上の「クライアントサイド」デバイスにまで拡張することが可能になりました。Elastic Common Schema (ECS) フォーマットは、セキュリティデバイスのコンテキストに対応するように拡張され、すべてのデータタイプを出荷し、ElasticsearchによるクエリやKibanaによる表示のためにElasticの集中インデックスに集約することができるようになりました。Elastic StackのユーザーであるEndgameは、Elasticのソリューションに組み込むことができるセキュリティ指向のカスタムKibanaダッシュボードを多数構築しており、顧客にセキュリティコンテキストを備えたアウトオブボックスの機能を提供していた。

Elasticは2019年10月にEndpoint Security製品の提供を正式に開始した。このリリースにより、顧客はSIEM製品を使用してセキュリティ脅威を中央で監視することを超え、中央での脅威検知に先立って実際にエンドポイントを保護することができるようになりました。これは、Endgameの既存の脅威防止エージェント技術によって実現された。また、今回のリリースでは、使用するツールに関わらず、デバイスごとの価格設定を廃止し、リソース利用に関連付けられた同じElastic Stackの価格設定モデルを順守するように価格設定モデルを変更した。

開発者コミュニティ

開発者はウェブサイトから直接Elasticソフトウェアをダウンロードすることができる。2018年9月のIPO時点で、Elasticのソフトウェア製品は、無料製品と有料製品を含めて3億5000万回以上ダウンロードされている。

また、Elasticは、開発者が集まり、Elastic Stackとベストプラクティスを共有し、カスタムソリューションをデモするための非常に広範なローカルミートアップを主催している。2018年7月31日現在、Elasticコミュニティには、46カ国194のMeetupグループにまたがる10万人以上のMeetupメンバーが含まれています。Elasticはスワッグを提供したり、リフレッシュメントのための予算を提供したり、ローカルイベントのプロモーションを行ったりしている。

また、ElasticはElastic{ON}と呼ばれる人気のあるカンファレンスのセットを運営しており、開発者と顧客の両方をターゲットにしている。Elasticのアプローチは、これらのミニカンファレンスを世界中に分散させ、通常は1日で内容の濃いものを提供するというもの。これにより、参加者は移動時間とコミットメントを最小限に抑え、柔軟性と利便性を提供することができる。もちろん、一部のエンタープライズソフトウェア企業は、大規模な中央集権型カンファレンスで数日間にわたって顧客を「ロックダウン」することを数える。私はElasticのアプローチが好きだ。

Stack Overflowの2019年の年次開発者調査では、Elasticsearchが好成績を収めた。Stack Overflowはソフトウェアエンジニアのための最大のコミュニティサイト。彼らは毎年、ソフトウェアエンジニアリングとインフラストラクチャの動向について開発者コミュニティに世論調査を行っている。

2019年の調査（2020年の調査は今始まったばかり）では、Elasticsearchは検索技術のユーザーの割合が最も高かった。さらに「最も欲しい」技術としてさらに高い評価を得ており、Elastic Stackをまだ採用していないが、採用したいと考えているショップで働いている開発者を反映している。このデータはElasticの高い開発者マインドシェアを反映しており、私はこれがソフトウェアスタックへの投資を成功させるための重要な要素であると考えている。

参考文献

• Manda Sai Divya, Shiv Kumar Goyal. ElasticSearch An advanced and quick search technique to handle voluminous data. COMPUSOFT, An international journal of advanced computer technology, 2 (6), June-2013 (Volume-II, Issue-VI).

• Wataru Takase et al. A solution for secure use of Kibana and Elasticsearch in multi-user environment. arXiv:1706.10040 Submitted on 30 Jun 2017.

• Diana Kupfer. A brief history of Elasticsearch. November 25, 2014.

• Our Story, Elastic.

• 「リコーがセキュリティ脅威の監視と検知にElastic Stackを活用」2019年5月30日

• Elastic Stack and Product Documentation

• Luke Marsden. Flocker Tutorial: Migrating a Stateful Dockerized ElasticSearch-Logstash-Kibana Stack. InfoQ. Jun 04, 2015.

• Oliver, Andrew C. Elasticsearch buys into search as a service, rebrands as 'Elastic. InfoWorld.com. 10 March 2015 (Retrieved 1 April 2019).

• Shay Banon. You Know, for Search. 8 February 2010. Archived from the original on 16 January 2013.

• "Security for Elasticsearch is now free". Elastic Blog. 20 May 2019. Retrieved 17 June 2019.