DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

高可用性Elasticsearchクラスタのセットアップガイド

ノードロール、ディスカバリ、レプリカ、JVMサイジング、ヘルスチェックを用いた高可用性Elasticsearchクラスタのセットアップ。

高可用性Elasticsearchクラスタのセットアップガイド

Elasticsearchはノード障害が発生しても可用性を維持できますが、マスター選出、データ配置、レプリカ、ディスカバリを正しく計画する必要があります。シングルノードクラスタは開発環境では動作するかもしれませんが、ホスト障害から検索ワークロードを保護することはできません。

このガイドでは、専用のマスター候補ノード、データノード、シャードレプリカ、および基本的な検証コマンドを使用して高可用性Elasticsearchクラスタをセットアップする方法を説明します。

Elasticsearchにおける高可用性の理解

Elasticsearchの高可用性は、いくつかの主要なメカニズムによって実現されます。

  • 分散アーキテクチャ: Elasticsearchは本質的にデータと操作を複数のノードに分散します。
  • ノードロール: 異なるノードが異なる目的を果たすことができ、リソースの割り当てと障害の分離を専門化できます。
  • シャードレプリケーション: 各インデックスはシャードに分割され、各プライマリシャードは異なるノードに保存される1つ以上のレプリカシャードを持つことができます。
  • マスターノード選出: 堅牢な選出プロセスにより、クラスタ状態を管理するマスターノードが常に利用可能であることが保証されます。
  • Zen Discovery (Zen2): このモジュールはノードのディスカバリとマスター選出を処理し、ノードが互いを見つけ、確実にクラスタを形成できるようにします。

必須ノードロール

HAセットアップでは、ノードロールを理解することが重要です。HAの主要なロールは次のとおりです。

  • マスター候補ノード: これらのノードは、インデックスの作成/削除、ノードの追跡、シャードの割り当てなど、クラスタ状態の管理を担当します。dataロールも持たない限り、データを保存したり、検索/インデックス要求を直接処理したりしません。HAのためには、クォーラムを形成するために奇数（通常は3）の専用マスター候補ノードが必要です。
  • データノード: これらのノードは、インデックス化されたデータをシャードに保存し、検索、集計、インデックス作成などのデータ関連操作を実行します。これらはクラスタの主力です。
  • コーディネート専用ノード: （オプション）これらのノードは、リクエストのルーティング、検索リデュースフェーズの処理、バルクインデックス作成の管理に使用できます。データやクラスタ状態を保持しませんが、データノードやマスターノードから作業をオフロードできます。

シャードとレプリカ

Elasticsearchはデータをシャードに保存します。各インデックスは1つ以上のプライマリシャードで構成されます。高可用性を実現するには、各プライマリシャードに1つ以上のレプリカシャードを設定する必要があります。レプリカシャードはプライマリシャードのコピーです。プライマリシャードをホストするノードが故障した場合、別のノードのレプリカシャードが新しいプライマリに昇格され、データ損失がなく、継続的な運用が保証されます。

HAクラスタセットアップの前提条件

設定に入る前に、環境が次の基本要件を満たしていることを確認してください。

  • Elasticsearchパッケージまたはアーカイブ: 公式パッケージには、最近のElasticsearchバージョンではバンドルされたJDKが含まれています。インストールで別のJDKを使用する場合は、Elasticsearchのバージョンと互換性があることを確認してください。
  • システムリソース: 各ノード、特にデータノードに十分なRAM（例：8〜32GB）、CPUコア、高速I/Oディスク容量（SSD推奨）を割り当てます。
  • ネットワーク設定: すべてのノードは、特定のポート（デフォルトではノード間通信に9300、HTTP APIに9200）を介して相互に通信できる必要があります。ファイアウォールが適切に設定されていることを確認してください。
  • オペレーティングシステム: 安定したLinuxディストリビューション（例：Ubuntu、CentOS、RHEL）が一般的に本番環境のデプロイに推奨されます。

HAクラスタセットアップのステップバイステップガイド

このセクションでは、マルチノードElasticsearchクラスタのインストールと設定のプロセスを概説します。

ステップ1：すべてのノードにElasticsearchをインストールする

クラスタの一部となる各サーバーにElasticsearchをインストールします。パッケージマネージャー（Debian/Ubuntuの場合はAPT、RHEL/CentOSの場合はYUM）を使用するか、アーカイブを直接ダウンロードできます。

例（APTを使用したDebian/Ubuntu）：

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list
sudo apt update
sudo apt install elasticsearch

インストール後、サービスを有効にして起動します（ただし、最初に設定します）。

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch

ステップ2：各ノードでelasticsearch.ymlを設定する

通常/etc/elasticsearch/にあるelasticsearch.ymlファイルで、クラスタの設定を定義します。各ノードでこのファイルを適切な設定で編集します。

すべてのノードの共通設定

  1. cluster.name: 同じクラスタに参加させたいすべてのノードで同一である必要があります。

    cluster.name: my-ha-cluster

  2. node.name: 各ノードの一意の名前。識別に役立ちます。

    node.name: node-1

  3. network.host: Elasticsearchを特定のネットワークインターフェースにバインドします。0.0.0.0を使用して利用可能なすべてのインターフェースにバインドするか、特定のIPアドレスを指定します。

    network.host: 0.0.0.0
# またはセキュリティ/マルチNIC設定のための特定のIPアドレス
# network.host: 192.168.1.101

  4. http.port: HTTPクライアント通信のポート（デフォルト9200）。

    http.port: 9200

  5. transport.port: ノード間通信のポート（デフォルト9300）。一貫している必要があります。

    transport.port: 9300

ディスカバリ設定（HAにとって重要）

これらの設定は、ノードが互いを見つけてクラスタを形成する方法を指示します。

  1. discovery.seed_hosts: クラスタ内のマスター候補ノードのアドレスのリスト。これにより、ノードは最初のマスター候補ノードを発見します。すべてのマスター候補ノードのIPアドレスまたはホスト名を指定します。

    discovery.seed_hosts: ["192.168.1.101", "192.168.1.102", "192.168.1.103"]

  2. cluster.initial_master_nodes: 真新しいクラスタを初めてブートストラップする場合にのみ使用されます。このリストには、最初のマスター選出に参加するマスター候補ノードのnode.nameを含める必要があります。クラスタが形成されると、この設定は無視されます。

    cluster.initial_master_nodes: ["node-1", "node-2", "node-3"]
    • 重要なヒント: クラスタが正常に形成された後は、cluster.initial_master_nodesを削除またはコメントアウトしてください。再起動や新しいノードの追加のために再度設定しないでください。

ノードロール設定

各ノードのロールを指定します。一般的なHAセットアップでは、3つの専用マスターノードといくつかのデータノードが含まれます。

  • マスター候補ノード（例：node-1、node-2、node-3）:
    node.roles: [master]
  • データノード（例：node-4、node-5、node-6）:
    node.roles: [data]
  • 混合ロールノード（大規模な本番HAには推奨されません）:
    node.roles: [master, data]
    • ベストプラクティス: 本番環境で真の高可用性と安定性を実現するには、マスターとデータのロールに別々のノードを専用にします。これにより、重要なマスタープロセスをリソース集約型のデータ操作から分離できます。

ステップ3：JVMヒープサイズを設定する

/etc/elasticsearch/jvm.optionsを編集してJVMヒープサイズを設定します。経験則として、利用可能なRAMの50％を割り当てますが、30〜32GBを超えないようにします。たとえば、サーバーに16GBのRAMがある場合、8GBを割り当てます。

-Xms8g
-Xmx8g

ステップ4：システム設定

本番環境では、すべてのノードでvm.max_map_countとオープンファイルのulimitを増やします。これらの行を/etc/sysctl.confに追加し、適用します（sudo sysctl -p）。

vm.max_map_count=262144

そして、/etc/security/limits.conf（または/etc/security/limits.d/99-elasticsearch.conf）で：

elasticsearch - nofile 65536
elasticsearch - memlock unlimited

ステップ5：Elasticsearchサービスを起動する

設定されたすべてのノードでElasticsearchサービスを起動します。マスター候補ノードを最初に起動することが推奨されることがよくありますが、最新のディスカバリでは、discovery.seed_hostsが正しく設定されていれば、順序はそれほど重要ではありません。

sudo systemctl start elasticsearch

サービスのステータスとログを確認してエラーがないか確認します。

sudo systemctl status elasticsearch
sudo journalctl -f -u elasticsearch

ステップ6：クラスタのヘルスを確認する

すべてのノードが実行されたら、Elasticsearch APIを使用してクラスタのヘルスを確認します。クラスタ内の任意のノードにクエリを実行できます。

curl -X GET "localhost:9200/_cat/health?v&pretty"

期待される出力：

epoch      timestamp cluster        status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1678886400 12:00:00  my-ha-cluster  green      6          3       0    0    0    0        0             0                  -                 100.0%
  • status: green（すべてのプライマリシャードとレプリカシャードが割り当てられている）またはyellow（すべてのプライマリシャードは割り当てられているが、一部のレプリカシャードがまだ割り当てられていない）である必要があります。redは深刻な問題を示します。
  • node.total: 起動したノードの総数と一致する必要があります。
  • node.data: データノードの数と一致する必要があります。

すべてのノードがクラスタに参加していることを確認します。

curl -X GET "localhost:9200/_cat/nodes?v&pretty"

期待される出力（3つのマスターノード、3つのデータノードの例）：

ip         heap.percent ram.percent cpu load_1m load_5m load_15m node.role   master name
192.168.1.101          21          87   0    0.00    0.01     0.05 m           *      node-1
192.168.1.102          20          88   0    0.00    0.01     0.05 m           -      node-2
192.168.1.103          22          86   0    0.00    0.01     0.05 m           -      node-3
192.168.1.104          35          90   1    0.10    0.12     0.11 d           -      node-4
192.168.1.105          32          89   1    0.11    0.13     0.10 d           -      node-5
192.168.1.106          30          91   1    0.12    0.10     0.09 d           -      node-6

これは、node-1が選出されたマスター（master列の*）であり、他のノードがクラスタの一部であることを示しています。

ステップ7：インデックスのシャーディングとレプリケーションを設定する

新しく作成されたインデックスの場合、Elasticsearchはデフォルトで1つのプライマリシャードと1つのレプリカ（index.number_of_shards: 1、index.number_of_replicas: 1）を使用します。HAの場合は、通常少なくとも1つのレプリカが必要です。つまり、データは少なくとも2つの異なるノードに存在します。これにより、1つのノードが故障しても、別の場所でレプリカが利用可能になります。

インデックスを作成するときは、次の設定を指定します。

curl -X PUT "localhost:9200/my_ha_index?pretty" -H 'Content-Type: application/json' -d'
{
  "settings": {
    "index": {
      "number_of_shards": 3,
      "number_of_replicas": 1
    }
  }
}'

セキュリティが有効な場合は、curlコマンドでHTTPSと資格情報またはAPIキーを使用します。例：

curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic "https://localhost:9200/_cluster/health?pretty"

運用チェック

クラスタがグリーンになったら、本番トラフィックが依存する前に障害動作を確認します。

  • 1つのデータノードを停止し、レプリカが昇格され、プライマリが利用可能なままであることを確認します。
  • 選出されたマスターノードを停止し、別のマスター候補ノードが選出されることを確認します。
  • クラスタが安定した後、_cat/shards?vで未割り当てのシャードがないか確認します。
  • クライアントが単一のHTTPエンドポイントではなく、複数のノードまたはロードバランサーを介して接続していることを確認します。

最終的なポイント

Elasticsearchの高可用性は、3つの実用的な選択から得られます。信頼性の高いマスタークォーラムを維持すること、シャードレプリカを異なるノードに配置すること、クライアントをノード損失に対して回復力を持たせることです。3つの専用マスター候補ノード、プライマリシャードとレプリカシャードを保持するのに十分なデータノード、およびノードの再起動と障害に対するテスト済みのリカバリ手順から始めてください。