Elasticsearchの新境地: Elastic Cloud Enterprise 1.0 リリース

Elastic Cloud Enterprise (ECE) 1.0がついに一般公開されたことが嬉しすぎて、バック転して逆立ちしたいくらいです。Elasticsearch クラスタ とKibanaインスタンスを好きなように、好きな環境で、単一のコンソールから設定、監視、デプロイすることができるようになります。

(今すぐお試しいただけます。また近日公開の製品のウェビナーとデモも楽しみにしていてください。)

本日の公開にあたり、これまで 製品の構造やビジネスにおける価値、そして用途. などをお話してきました。今回はユーザーがECEのような製品を採用するに至る経緯について詳しく見ていきたいと思います。

製品採用にいたるストーリーはどのユーザーも割と似通っています。X社のある開発者はデータ関連の問題に直面した際Elasticsearchに行き当たり、ダウンロードしてテストクラスタを立ち上げ、データを入れると問題を解決することができました。この話を聞いた同僚が自分が持っているデータを追加すると、これにはより大きなクラスタが必要になりました。すぐにX社ではいくつものElasticsearchのノードが稼動し始め、ミッションクリティカルな業務を支えるようになりました。

これは物語の始まりに過ぎません。

たとえばX社は銀行だったとしましょう。彼らが今使っているマルチノードクラスタは複数のアプリケーションのロギング・ユースケースに対応していますが、今後はセキュリティ分析と金融取引解析用の新しいアプリケーションに力を入れたいと考えています。それに加えて、マーケティング、人事、SREチームもElasticの噂を嗅ぎつけ、それぞれの業務の問題を解決するのにこのツールを使ってみたい、または実際に適用したいと言い出しました。

だんだん面白くなってきましたね。様々なユースケース、マルチテナント、そして増え続けるデータ。クラスタ内の規模を管理するという、難しく、嬉しくはない状況です。

とはいえ、こういった問題にはむしろワクワクさせられます。難しいことには変わりないのですが。詳しく説明するために、(はからずも実存の)2つの質問に照準を合わせてみましょう。1)あなたは誰？2)目的は？

第1の質問：あなたは誰？

クラスタの利用者であれば, Time-To-Insight (洞察にかかる時間)、素早いレスポンス、カスタムエクスペリエンス、期待を満たせているかが興味の対象でしょう。ただし全ての利用者が似たものだと見なすのは早計です。それぞれにニーズや習慣、要件があり、その一つ一つが不和やフラストレーションの原因となり得るのです。

• それぞれのアクセスプロファイル。 利用者によりユースケースは異なります。全文検索をすることもありますし、提案が必要な場合もあります。重いデータの集計、ロギング、またはセキュリティデータのscan ＆ scrollが必要なこともあるでしょう。

• 様々なSLA。 標的型攻撃に対処しているセキュリティチームにとって、解析を行う際のレスポンスの遅延は致命的です。でもクラスタに対するデータのクエリが重いと、他の利用者が期待するSLAに悪影響を及ぼす可能性があります。

• 異なるバージョン。 すべての利用者が同じバージョンのElastic製品を走らせているとは限りません。理由があって特定のバージョンを使っているのに、新しいバージョンを無理に押し付けると不便をかけてしまうことにもなりかねません。

他にも、検討しなければならないことはたくさんあります。たとえば余計な作業やインフラの付加を招く可能性のある、異なるバックアップ方針。別の利用者が1年分のデータをクエリする重いアラートを構築して、他の利用者のクラスタを止めてしまうことも有り得ます。

Elasticの魔法を操る運用チームなら、良質なユーザーエクスペリエンス、プロジェクトや部門に追加されたROI、また火消し業務に時間をとられすぎない、というのが興味の対象でしょう。この観点から言えば、また別の問題を考える必要があります。

• メンテナンスを行う時期。 ずっと昔から変わらずある問題です。システムとユーザーに与える影響を最小限に抑える、最適なメンテナンス時期はいつか？タイムゾーンの違いや異なる使用パターンでどのように調整するか？

• アップグレード。 これも昔からある問題です。1つの利用者をアップグレードすると、アップグレードは必要ない(または出来ない)テナントにも影響を与える可能性があります。

• ひとりの利用者が全てをクラッシュ。 ひとりの利用者が大容量のクエリを実行してクラスタ全体をロックしてしまうことにより、内部顧客のアクセスに問題が起きる可能性があります。

• セキュリティコンプライアンス。 セキュリティ上の理由により、利用者によっては他の利用者と同じクラスタにデータを保持できないこともあります。

• 皆Kibanaが好き過ぎる。 現在Kibanaはマルチテナント機能に対応していませんので、ユーザーは複数のKibanaのインスタンスを立ち上げる必要があります。つまり管理の手間も増えるということです。

じゃあどうするのか？

ソフトウェアはとてもよく動き組織に多くの恩恵をもたらしてくれます。運用チームはクラスタ(あるいは彼らの心が)砕け散る前に何をすればいいのでしょう？

これが今のあなたの生活なので…

オプション(実際は起こりうる事態ですが)：クラスタを分割しましょう。細かく分ければ、上記でお話した難点をいくつかクリアすることができます。ただコストは掛かってしまいます。

設定管理や編成ツールの展開や提供、(5.Xリリース前は難しい)クラスタごとで異なるバージョンのElasticの管理、様々なSLAへの対応、ないしは異なるタイプのインフラへの対応などなど、考慮が必要です。

例外を認めてひとりの利用者にクラスタを与えたら、他の利用者も専用のクラスタを欲しがるでしょう。単純なことを小規模に管理しようとしても、数が増えれば複雑になる一方です。すぐに運用チームは当初予定していたよりも多くの時間、クラスタのサポートに時間をとられるリスクを負うことになってしまうでしょう。

そこで私たちの登場です。

こういった問題はECEの大好物。これら全てのニーズを単一のコンソールで、円滑に問題解決を図ることができます。

新しいクラスタを作成し、要求に応じて拡大と縮小を行い、複数のバージョンを使える環境を提供またはバージョンのアップグレードを行い、Kibanaを有効にし、X-Packを作動させる・・・そしてあなたがやることは唯一つ、APIコールをクリックまたは送信するだけです。デプロイ状況はパネル一枚から覗き見ることができるので、みんながハッピーかどうかは一目瞭然。自分のプロジェクトに戻って仕事を進めることに集中できるようになります。

こうなると、Elasticを使ってみたい、または徹底的に使いたいと言う人にいつでも簡単に提供できます。POCの時間をお探しですか？新しいクラスタを立ち上げましょう。一時的な環境が必要？どうぞどうぞ。セキュリティプランに適合するハードウェアをお願いするのが気まずい？心配する必要はありません。(普通は新しい仮想マシンやテスト専用のマシンを単純にお願いしません…)ECEに既に備わっています。プロジェクトでQAとステージング用の環境が複数必要ですか？お任せください。

ECEはこういった問題を解決するため、いやもっと言えば最良の結果をもって解決するためにデザインされています。ここ数年間で幾千にも上るクラスタを管理してきたElastic Cloudサービスには、ECEに装備したのと同じコードベースが使用されています。結局のところ、この製品はElasticと成長していくことを期待する人にとって理想的な製品なのです。実際、あるお客様は現在は5つのプロダクションクラスタを使用してい流のですが、今後のさらなる成長に備えてこの製品が提供する一点集中型の管理に価値を見出されています。

とにかくまず 実際に立ち上げてみて ステップバイステップの手順に従って、更なる詳細をご確認ください。