こんにちは。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"
              }
            ]
          ]