こんにちは。Data Engineer の @shase です。
みなさんは全文検索エンジンに何を使われているでしょうか？ 2020年現在では、比較的 Elasticsearchを使われている方が多いのでは無いかと思います。
Quipperでも、toC向けの検索機能をはじめとして、いくつかの社内システムでElasticsearchを使って全文検索を実現しています。
元々は別のElasticsearchマネージドサービスを使用していたのですが、昨年から各種システムをElastic CloudのElasticsearch Service（公式サイト）に移行作業を行っており、そのエッセンスについて、本記事で紹介したいと思います。
Elastic Cloud/Elasticsearch Serviceの概要
Elastic CloudのElasticsearch Serviceは、Elasticsearchの開発元であるElastic社が提供しているマネージドサービスです。
（名前が紛らわしいのですが、AWSのAmazon Elasticsearch Serviceとは別のものです）
特徴としては、AWS/GCP/Azureのメジャーなクラウドの各リージョンを選択してクラスタを立ち上げられることが挙げられます。これによって、アプリケーションが各クラウドで稼働している状態であれば、低レイテンシのElasticsearchクラスタが簡単に用意することができます。
支払いについては、GCPの請求に含める形式（GCP Marketplace）、Elastic社直接の請求書払い等々いくつかの選択肢があります。GCPを使われている場合は、GCP Marketplaceを使うほうが楽かもしれません。
プランと機能の詳細については、公式のPricingページに詳細が記載されています。
Elastic Cloud/Elasticsearch Serviceに移行するモチベーション
これまでは他社のElasticsearchマネージドサービスを使っていたのですが、わたしたちはElastic Cloudに以下のようなメリットを感じています。
- 新しいバージョンがタイムリーに提供されること
- ユーザ辞書が利用できること
- カスタムプラグインの利用が可能であること
- Elasticsearchの詳細なサポートが提供されていること
- クラスタのバージョンアップ作業が容易であること
これらは、以前使っていた他社Elasticsearchマネージドサービスでは実現が難しいものでした。
例えば、新しいバージョンがなかなか提供されないがゆえに、ベクトルフィールドタイプに基づく関連機能が使いたくても使えない、という状況が長くありました。
また、ユーザ辞書が利用できないがゆえに、前処理を行うしかなく、前処理コストが非常に高いものとなっていました。
Web Consoleを利用したクラスタ作成の例
さて、Elastic Cloudを利用されたことのない方も多いかと思いますので、Web Consoleを利用したDeployment(クラスタ)作成のイメージを紹介したいと思います。
Deployment作成画面はこのようになっており、大まかに、クラウドベンダー/リージョンを選択する、ElasticStackのバージョンを選択するだけで作成できるようになっています。
また、当然Deploymentの詳細も以下のように設定することができます。
すべては解説しませんが、Zoneの指定、キャパシティ（メモリ等）、プラグイン(kuromoji等)の設定がこのように視覚的に実行でき、1 ClickでDeploymentが作成されます。
例えば、プラグインの導入は、セルフホスティングの場合、 elasticsearch-plugin install analysis-kuromoji のようなコマンドでpluginをinstallしていたと思いますが、Elasticsearch Serviceの場合は、Web Console上から導入が可能です（当然ですが、Deploymentを作成後に後で導入することも可能です）。
Deploymentが作成されると、アカウントが発行され、接続先となるEndpointが生成されます。
上記を使って、Elasticsearch及びKibana等にアクセスすることができます。
CLI(Elastic Cloud Control)
最近、Web Console以外の操作方法としてElastic Cloud の CLIが提供されるようになりました🎉（公式サイトのリリース）
Macの場合homebrewで使うことができるので、こちらも紹介したいと思います。
CLIの導入とDeploymentの作成
brew tap elastic/tap brew install elastic/tap/ecctl
ecctl version コマンドで v1.0.0-beta3 以降であることを確認してください。
cliの設定は ecctl init のウィザードで可能です（事前にAPIキーをWeb Consoleから生成しておくと良いでしょう）
設定が完了していれば、ecctl deployment list でアクティブな Deploymentのlistが表示されるはずです。
また、先程Web Consoleを利用したクラスタ作成をご紹介しましたが、作成画面の「Equivalent API request」をクリックすると、CLIでDeploymentを作成するときに渡すJSONが生成されます。
画面を見ながらJSONを一旦生成し（仮にdeployment.jsonとしますが）、ecctl deployment create -f deployment.json このようにコマンドの引数として指定することで、Deploymentを作成することができます。
また、ecctlにはElastic CloudのWeb Consoleで使える機能に対応しており、既存のDeploymentの構成変更などもCLIから可能です。
Elastic Cloudはコードで構成を管理できないのが難点でしたが、上記API/CLIにより、これから改善されていくのではないかと思います。
Datadogを利用したクラスタの監視
Deployment作成時に、Elastic StackのAPMも導入されるので、それを使った最低限の監視は可能です。しかし、現在ではサービス側でDatadogなどを使っている方も多いのではないでしょうか。
残念ながら、Datadogには「Elastic Cloud/Elasticsearch Service」のインテグレーションは存在しませんが（サードパーティが使えるAPIが無かったせいだと思いますが）、セルフホスティングを想定した Elasticsearchのインテグレーションはあるので、これを利用しています。
今回作成した、ElasticsearchのEndpointは外部公開されているため、既存のDatadogが動いている環境から、このEndpointを指定することで、それぞれのDeploymentの監視をできるようにしています。（この仕組みはSREチームに協力していただきました！）
具体的には、KubernetesのServiceリソースを利用しています。これはannotationsにAutodiscoveryの設定を定義すると、DataDogはモニタリングの対象に含めてくれます。
設定サンプル (annotations.yaml)
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: "${SERVICE_NAME}" spec: template: metadata: annotations: ad.datadoghq.com/${SERVICE_NAME}.check_names: | ["foobar", "elastic"] ad.datadoghq.com/${SERVICE_NAME}.init_configs: | [{}, {}] ad.datadoghq.com/${SERVICE_NAME}.instances: | [ [ { "proc_name": "foobar:foobar" } ], [ { "url": "https://example.com", "cluster_stats": "true", "index_stats": "true", "auth_type": "basic", "username": "foobar", "password": "foobar" } ] ]
さいごに
Elastic CloudのElasticsearch Serviceを利用したクラスタ(Deployment)作成、監視について紹介しました。
正直、Elastic Cloudはマネージドサービスとしては、まだまだ欲しい機能はたくさんあります。
しかし、Elastic側の開発も活発で新機能も出てきているので、それに合わせて我々の運用も進化させていければ良いなと考えています。
