Elasticsearchクラスタの高可用性(HA)実現ガイド

はじめに (対象読者・この記事でわかること)

この記事は、Elasticsearchを利用している開発者やインフラエンジニアを対象としています。特に、大規模なデータ検索や分析基盤を構築している方々に役立つ内容です。

本記事を読むことで、Elasticsearchクラスタの高可用性(High Availability)を実現するための具体的な設定方法やベストプラクティスを理解できます。クラスタ障害時のフェイルオーバー仕組みや、マスターノードとデータノードの冗長化設定、レプリケーションの活用方法など、実践的な知識を習得できます。また、運用上で注意すべき点やトラブルシューティングの方法についても解説します。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。 - Elasticsearchの基本的な概念(ノード、インデックス、シャードなど) - Linuxサーバーの基本的な操作 - ネットワークの基本的な知識 - YAML形式の設定ファイルの記述方法

Elasticsearchクラスタの高可用性概要

Elasticsearchは分散型の検索エンジンであり、複数のノードからなるクラスタを構築することで高可用性を実現します。高可用性とは、システムの一部に障害が発生しても、サービスを継続的に提供できる能力を指します。

Elasticsearchクラスタでは、データが複数のノードに分散して保存されるシャードという単位で管理されます。各シャードにはプライマリシャードとレプリカシャードがあり、プライマリシャードに書き込まれたデータは自動的にレプリカシャードに複製されます。これにより、特定のノードに障害が発生しても、データが失われることなくサービスを継続できます。

マスターノードはクラスタ全体の状態を管理し、データノードは実際のデータの保存と検索処理を行います。これらの役割を適切に分散させることが、クラスタの安定性と可用性を確保する上で重要です。

高可用性を実現する具体的な設定

ステップ1: マスターノードの冗長化設定

マスターノードはクラスタの状態を管理する重要な役割を担っています。マスターノードが単一障害点(SPOF)にならないように、複数のマスターノードを設定する必要があります。

まず、elasticsearch.ymlファイルに以下の設定を追加します。

Yaml

# マスターノードとして動作させる設定
node.master: true
node.data: false
node.ingest: false

# クラスタに参加するノードの選択
discovery.zen.minimum_master_nodes: 2

# マスターエレクションのタイムアウト設定
discovery.zen.master_election.filter_client: true
discovery.zen.master_election.timeout: 10s

discovery.zen.minimum_master_nodesは、クラスタを形成するために必要なマスターノードの最小数を指定します。この値は「(マスターノード数/2)+1」以上に設定することが推奨されます。例えば、3つのマスターノードを構成する場合は2、5つの場合は3とします。

また、マスターノードにはデータを保存しないようにnode.data: falseを設定し、負荷分散を図ります。これにより、マスターノードの役割に集中させることができます。

ステップ2: データノードの冗長化設定

データノードは実際のデータを保存し、検索処理を行う役割を担っています。データノードの可用性を確保するためには、レプリカシャドを適切に設定することが重要です。

まず、インデックス作成時にレプリカ数を指定します。

Json

PUT /my_index
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 2
  }
}

この例では、3つのプライマリシャドとそれぞれ2つのレプリカシャドが作成されます。合計で9つのシャドがクラスタ内に分散して配置されます。

また、インデックステンプレートを使用して、新規インデックスのデフォルト設定を指定することもできます。

Json

PUT _template/my_template
{
  "index_patterns": ["*"],
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 2
  }
}

データノードの数は、データ量と負荷に応じて適切に設定する必要があります。一般的には、レプリカシャドが配置されるだけの十分な数のデータノードを用意することが推奨されます。

ステップ3: セグメンテーション障害対策

クラスタセグメンテーションは、ネットワーク障害などによりクラスタが複数のグループに分割されてしまう状態を指します。これにより、クォーラム不足によりクラスタ全体が停止してしまう可能性があります。

この問題を防ぐため、以下の設定をelasticsearch.ymlに追加します。

Yaml

# セグメンテーション検知のタイムアウト設定
discovery.zen.ping_timeout: 10s
discovery.zen.ping_retries: 6

# クラスタ全体の状態を維持するための設定
discovery.zen.fd.ping_interval: 10s
discovery.zen.fd.ping_timeout: 30s
discovery.zen.fd.ping_retries: 3

また、discovery.zen.minimum_master_nodesの設定が適切であることも重要です。この値が低すぎると、セグメンテーション時に複数のマスターエレクションが発生してしまいます。

さらに、クラスタの安定性を確保するため、以下の設定も推奨されます。

Yaml

# クラスタの安定性確保のための設定
cluster.routing.allocation.balance.shard: 0.45
cluster.routing.allocation.balance.index: 0.45
cluster.routing.allocation.balance.total_shards_per_node: 1.0

これらの設定により、シャドが各ノードに均等に分散され、特定のノードに負荷が集中することを防ぎます。

ステップ4: ミニタリングとアラート設定

クラスタの高可用性を維持するためには、適切なモニタリングとアラート設定が不可欠です。

まず、Elasticsearchのクラスタヘルス状態を確認する方法です。

Bash

# クラスタ全体の状態を確認
GET _cluster/health

# インデックスごとの状態を確認
GET _cat/indices?v

重要なメトリクスとして、以下の項目を監視する必要があります。

クラスタステータス(yellow/red)
未割り当てシャド数
ノードの状態
ディスク使用率
JVMメモリ使用率

これらのメトリクスを監視するため、例えばPrometheusとGrafanaを組み合わせた監視環境を構築するのが一般的です。

また、アラート設定のベストプラクティスとして、以下の点が挙げられます。

クラスタステータスがredになった場合に即時通知
ディスク使用率が85%を超えた場合に警告
JVMメモリ使用率が85%を超えた場合に警告
ノードがクラスタから離脱した場合に通知

これらのアラートにより、障害が発生する前に対処することが可能になります。

ハマった点やエラー解決

マスターノードの過剰設定による問題

ある環境では、5つのマスターノードを設定したところ、クラスタの起動に時間がかかるようになりました。ログを確認すると、マスターエレクションに時間がかかっていることが判明しました。

原因は、discovery.zen.minimum_master_nodesの設定が3に設定されていたため、起動時に3つのマスターノードが揃うまで待機していたためです。

レプリカシャドの不足によるデータ損失リスク

開発環境では、レプリカシャドを1つしか設定していませんでした。ある日、データノード1台が故障したところ、一部のデータにアクセスできなくなりました。

原因は、レプリカシャドが1つしかなかったため、データノード1台が故障すると、そのノードに配置されていたレプリカシャドにアクセスできなくなったためです。

クラスタセグメンテーションによるサービス停止

本番環境でネットワーク障害が発生したところ、クラスタが2つのグループに分割されてしまいました。その結果、クォーラム不足によりクラスタ全体が停止してしまいました。

原因は、discovery.zen.minimum_master_nodesの設定が1に設定されていたため、セグメンテーション時に各グループがそれぞれマスターエレクションを実行してしまったためです。

ディスク容量不足によるノードダウン

あるデータノードのディスク容量が90%を超えたところ、そのノードがクラスタから離脱してしまいました。

原因は、ディスク容量不足により新しいデータを保存できなくなり、Elasticsearchが安全のためノードを離脱させてしまったためです。

解決策

マスターノードの過剰設定による問題の解決策

マスターノードの数とdiscovery.zen.minimum_master_nodesの設定を見直しました。マスターノードを3台に減らし、discovery.zen.minimum_master_nodesを2に設定しました。これにより、クラスタの起動時間が短縮されました。

レプリカシャドの不足によるデータ損失リスクの解決策

本番環境では、レプリカシャドを2つ以上設定するように変更しました。これにより、データノード1台が故障しても、データにアクセスできるようになりました。

クラスタセグメンテーションによるサービス停止の解決策

discovery.zen.minimum_master_nodesの設定を「(マスターノード数/2)+1」以上になるように見直しました。マスターノード3台の場合は2、5台の場合は3と設定することで、セグメンテーション時にクラスタ全体が停止するのを防ぎました。

また、discovery.zen.ping_timeoutとdiscovery.zen.ping_retriesの値を調整し、ネットワーク一時的な遅延に対してより頑健な構成にしました。

ディスク容量不足によるノードダウンの解決策

ディスク容量監視を強化し、ディスク使用率が80%を超えたら警告を送るように設定しました。また、ディスク使用率が90%を超えたら、古いインデックスを自動で削除するリtentionポリシーを導入しました。

これにより、ディスク容量不足によるノードの離脱を防ぐことができました。

まとめ

本記事では、Elasticsearchクラスタの高可用性を実現するための具体的な設定方法とベストプラクティスを解説しました。

マスターノードの冗長化設定により、単一障害点を防ぎます
データノードの冗長化設定と適切なレプリカ数の指定により、データの可用性を確保します
セグメンテーション障害対策により、ネットワーク障害時にもクラスタを安定稼働させます
モニタリングとアラート設定により、障害を早期に検知し、迅速な対応が可能になります

この記事を通して、Elasticsearchクラスタの高可用性を確保するための実践的な知識を習得できたことと思います。これにより、より安定した検索基盤を構築し、サービスの信頼性を向上させることができるでしょう。

今後は、クラスタの自動スケーリングや、より高度なフェイルオーバー戦略についても記事にする予定です。

Elasticsearchクラスタの高可用性(HA)実現ガイド🔍