1. シャード設計

インデックス設定の際に指定する"number_of_shards"。これは重要です。
REST APIで設定するこういうやつですね。

PUT twitter{    "settings" : {        "index" : {            "number_of_shards" : 3,             "number_of_replicas" : 2         }    }}

このREST APIについては、このページに詳しく書いてあります。
www.elastic.co

えっ、そんなの知っている？

そうですよね。
ただ、ここで言いたいのは単にシャード設定をしているだけでなく、
シャード設計を行った上で、シャード設定をしているか？
です。

Elastic社のブログに記載がありますが、シャード設計には経験則があり、
ヒープサイズが30GBの場合は1ノードあたりのシャード数は600-750個程度が限界との事です。
How many shards should I have in my Elasticsearch cluster? | Elastic

シャード数が多すぎるとクラスタに負荷がかかるため、シャード設計はとても大切です。

2. X-PackのDefaultTLS/SSL Settings

elasticseachクラスタ内間の通信、elasticseachクラスタに対する通信には、SSL/TLSを使うことができます。
www.elastic.co

セキュリティは大切、、、というだけでなく、この設定は実は重要な設定です。
なぜかと言うと、Elastic Stack 6.0から
X-Pack Securityを利用する場合はSSL/TLSが必須となったからです。

以下のページにも記載があります。

Elasticsearch 6.0.0 GA released
www.elastic.co

これまで、メジャーアップグレードにはクラスタの再起動が必要でした。
クラスタを停止するとサービスに影響がある方も多いと思います。
そこで、5.6から6.0へのバージョンアップでは、ローリングアップグレード(1台ずつ停止してアップグレード)を行うことで、クラスタ全体の停止を避けることができるようになりました。

ただし、SSL/TLS化されていないクラスタの場合は、SSL/TLS化するためにクラスタの再起動が必要になります。
X-Pack Securityを使っている場合、SSL/TLS化が済んでないと、5.6から6.0にローリングアップグレードできないので注意しましょう。

3. Disk-based Shard Allocation

せっかくサイジングしても、Elasticsearchはデフォルト設定ではディスクを限界までは使いません。
詳しくはこのページに記載がありますが、

www.elastic.co

ディスク使用率が85%を越えたノードには、新規シャードを割り当てません。
また、ディスク使用率が90%を越えたノードは、保持しているシャードを別のノードに再配置しようとします。

そのため、ディスクを限界まで利用するには、次のパラメータを設定する必要があります。

• cluster.routing.allocation.disk.watermark.low
• cluster.routing.allocation.disk.watermark.high

1TBディスクの85%だとは150GBしか空いていませんが、10TBディスクの85%だと1.5TBも空いてしまうので、利用しているディスクサイズによって設定したい値が変わってくると思います。

ただ、マージ前のセグメントサイズや、シャード再配置に必要な分はディスクに余裕が必要です。
また、耐障害性を考えると、1台停止しても運用できる余裕は必要ですので、ギリギリを攻めるのは避けた方が良いと思います。

4. プロセッサ数設定

Elasticsearchはインデクシング、検索など、処理毎にスレッドプールを持っています。
このスレッドプールは、Elasticsearch起動時にCPU数を元に自動で最適なサイズに設定されます。
www.elastic.co

ただし、プロセッサ数が32を越える場合は、プロセッサ数を手動で設定する必要があります。

逆に、CPU数より小さく設定することでElasticsearchが利用するスレッドプールのサイズを小さくすることができます。
同じノードに他のプロセスが載っているケースで、利用すると良いと思います。

5. Merge scheduling

Elasticsearchで利用するディスクはSSDがオススメですが、デフォルトでSSD向けに自動でチューニングされるパラメータがあります。
Elasticsearchのデータは物理的には「セグメント」と呼ばれる単位で保存しており、ときおりセグメントをマージする処理が走ります。デフォルトの動作では、このマージ処理を行うスレッドの最大数が、SSD向けに自動でチューニングされます。もう少し言うと、CPU数によって、1-4のいずれかの値にチューニングされます。
www.elastic.co

正直言って、どの程度影響するのか、私も測定したことはありませんが、HDDを利用する場合は

index.merge.scheduler.max_thread_count

を1に設定するようマニュアルに記載されています。

以上、あなたの知らないElasticsearch設定トップ5でした。
知らないと思わぬ問題に陥ったりすることもあります。
十分条件ではありませんが、このあたりの設定を意識して、Elastic Stackを安全に運用しましょう。

それでは、また～

Acroquest Technologyでは、キャリア採用を行っています。

• ビッグデータ（Hadoop/Spark、NoSQL）、データ分析（Elasticsearch、Python関連）、Web開発（SpringCloud/SpringBoot、AngularJS）といった最新のOSSを利用する開発プロジェクトに関わりたい。
• マイクロサービス、DevOpsなどの技術を使ったり、データ分析、機械学習などのスキルを活かしたい。
• 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
データ分析基盤Elasticsearchを使い倒したいエンジニア募集！ - Acroquest Technology株式会社のエンジニア中途・インターンシップ・契約・委託の求人 - Wantedlywww.wantedly.com