エンジニアリング

Elasticsearchの運用に関する典型的な4つの誤解

著者
Jun Ohtani (JP)

初のフライト変更ということで、羽田空港で5時間の待ち時間ができたのでブログを書いているところです。

皆さんの使用方法などを知りたいと思い、日本語で書かれたツイートやブログを時々みていますが、 共通で見受けられるElasticsearchに関する誤解があるようです。 よりよくElasticsearchを利用していただくために、よく陥る誤解とどうすれば良いかというのを紹介しようと思います。

誤解：2台でHA構成

「1台では、マシントラブルなどがあった場合に、Elasticsearchが利用できなくなるという心配から、2台でElasticsearchのクラスターを構成すれば1台ダウンしてもサービスを維持できるだろう。」

残念ながら2台では完全なHA構成にはならないのがElasticsearchです。2台構成のクラスターは、データの欠損という障害に対しては有効です。 が、1台故障してもクラスターが正常に動作するという意味では、HA構成とは呼べない状況になります。

Elasticsearchは分散システムです。分散システムの状態を管理するためにマスターノードと呼ばれる特殊なノードがクラスター内のノードの中から1台だけ選出されます。このマスターノードの選出において、2台構成のクラスターでは問題が発生します。Elasticsearchがマスターノードを選出するプロセスは、次のようなものになります。

  • 全てのマスター候補ノードが、マスターノードになるべきノードに対して投票する（自分自身の場合もある）
  • ただし、投票はminimum_master_nodes以上のマスター候補ノードが確認できた場合にのみ可能
  • 十分な数(minimum_master_nodes)の票を得たマスター候補ノードがマスターノードになる

minimum_master_nodesの推奨値は(master_eligible_nodes / 2) + 1になります。このため、2台しか存在しないクラスターの場合に問題が出てきます。

  • minimum_master_nodesを2に設定した場合：1台でも故障した場合はマスターノードを選び出すことができなくなり、クラスターはマスターノードが存在しない状態になります。このため、新しくインデックスを作成したり、クラスターの設定を変更することができなくなります。
  • minimum_master_nodesを1に設定した場合：ネットワーク上でお互いが見えなくなった場合にスプリットブレインという状態に陥ります。どちらもマスターノードになってしまい、クラスターとして機能しなくなってしまいます。

スプリットブレインを防ぎ、クラスターが安定して動作する状況にするためには、3台以上の構成が必要になります。 HA構成のElasticsearchクラスターを検討している場合は3台以上でクラスターを構成するようにしましょう。

誤解：全てのノードのzen.ping.unicast.hostsにはクラスターに接続するノードを「全て」記述しないといけない

「現状、3ノードでクラスターを構成しているが、2台ノードを追加しよう思う。クラスターにある全てのノードのzen.ping.unicast.hostsを書き換えて1台ずつ再起動しよう」

リファレンスに記載はあるのですが、クラスターに存在するノードの情報を全て書かないといけないと思う人が多いようです。 この値は、Elasticsearchのノードが起動した時に、「最初に」クラスターの情報を取得するための接続先として使われる情報になります。 実際には、Elasticsearchはunicastの接続先に通信を行い、自身のクラスター名と接続先のクラスター名が同じかどうかをチェックし、 値が同じ場合はそのクラスターに所属するという判断を行い、別途、現在のクラスターのマスターノードと通信を始めます。 この時、新しく起動したノードはunicastの値を基にした接続先のノードからマスターノードがどこにあるのかといった情報を取得します。 それ以降は、マスターノードが、クラスター全体の情報（クラスターに何台のノードがあるのかなどといった情報）を新しいノードに対して配布します。

ですので、リファレンスに記載があるように、マスター候補ノード（node.masterの設定がtrueのもの）を記載すれば問題ありません。 あとからノードを追加する場合、既存のクラスターに存在するノードに関しては設定を変更する必要はありません。

誤解：クライアントアプリからの接続先はマスターノード、マスター候補ノードにする

「データノードにクライアントから接続すると負荷がかかるかもしれないので、マスター候補ノードやマスターノードに接続しよう」

「データノード」という名称もあり、クライアントから接続するべきではない、接続できないと考えることがあるようです。Elasticsearchは、デフォルトでは全てのノードがクライアントからのリクエストを処理することが可能です。ですので、「マスターノード、マスター候補ノード」である必要はありません。さらに、「マスターノード」はクラスターの状態を管理する大事なノードになります。「マスターノード」には極力、クラスターの状態を管理することに専念してもらうことを進めています。ですので、クライアントから接続するのは「マスターノード」、「マスター候補ノード」以外にすることが推奨されます。「データノード」の負荷も気になる場合には、専用の「マスター候補ノード」を用意したり、専用の「コーディネーティングノード」を検討することも可能です。各ノードの役割や構成については、「Elastic Stackの標準構成（ロギング編）」をご覧ください。

誤解：基本的に1インデックスのプライマーリシャード数はデフォルトが推奨の値である

「デフォルトが5シャードだし、とりあえず考えないでデフォルトのままで行こう」

デフォルト値＝推奨と考えることも多いかと思います。ただ、シャード数に関しては、1シャードから検討していただくことを勧めています。 スモールスタートができるのがElasticsearchの利点です。1ノードのクラスターから初めて、必要に応じてクラスターのノード数を大きくしていくことができます。 シャードも同様に考えていただくのが良いかと。

シャードとは、Elasticsearchの内部でのインデックスの最小構成単位になります。Elasticsearchは、このシャードという単位でクラスター内部でデータを移動することができます。 あらかじめ、「シャード数＞ノード数」としておくことで、後からノードを増やした場合に、簡単にスケールアウトすることが可能です。ですが、シャードのデータは全てディスクに保存されています。ということは、シャード数が多いとそれだけディスクへのアクセスが多くなります。ディスクへのアクセスを減らすことが、Elasticsearchの検索レスポンスの向上にもつながります。

また、次期メジャーバージョンからは、デフォルト値は1シャードに変更になっています。ぜひ1シャードから構成を変更していくことをお勧めします。

まとめ

今回はElasticsearchに関する典型的な誤解を紹介しました。Elasticsearch独自の話もあり、慣れないところがあるかと思います。自分だけで考えず、公式リファレンスに目を通したり、フォーラムを活用していただけると正しい設定かどうかなどが確認できるかと思います。それ以外にも、公式トレーニングや、サポートを活用するためにサブスクリプションなどを活用するという方法でさらに導入や理解をスムーズに行うといったことも可能です。ビデオやウェビナーなど、様々なコンテンツも用意しております。

これらを活用して少しでもElastic Stackを快適に使っていただければと思います。