2026年7月12日

Elasticsearchのインストールと基本設定（apt導入・セキュリティ初期設定・ヒープとディスクの調整）

バックアップ・監視

Elasticsearch は、Elastic 社の公式リポジトリからパッケージで入れるのが手堅い方法です。8.0 以降は、初回起動時に TLS と認証が自動で有効になるため、インストール直後に表示される elastic ユーザーのパスワードと CA 証明書の扱いを最初に押さえることが大切です。この記事では、Ubuntu 1台に Elasticsearch を入れ、外部に公開しない形で動かし、ヒープメモリとディスクのしきい値まで調整する手順を説明します。

導入前に確認すること

版: 2026年10月現在、新規導入では 9.x 系が中心で、8.x 系もサポート期間中の版があります。サポート期間は Elastic の公式サイトにある製品のサポート表で確認できます。本記事のコマンドは 9.x のリポジトリを例にしていますが、8.x でも流れは同じです。
メモリ: Elasticsearch は Java で動き、メモリを多く使います。WordPress と同じ小さな VPS に同居させると、PHP や MySQL とメモリを取り合います。検索用途でも、できれば別のサーバーを用意します。
用途: WordPress のサイト内検索に使うなら、ElasticPress などの連携プラグインが対応している Elasticsearch の版を先に確認します。プラグインの対応状況は版ごとに変わるため、プラグインの公式ドキュメントを参照してください。ログ分析に使うなら、後から Kibana や Fluentd を組み合わせます。
ライセンス: Elasticsearch のライセンスは何度か変更されています。社内での利用は通常問題になりませんが、Elasticsearch をサービスとして他者に提供する場合などは、公式のライセンス説明を確認します。オープンソースの派生として OpenSearch もあります。

手順1: 公式リポジトリを登録してインストールする

署名鍵を登録し、リポジトリを追加してからインストールします。

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

インストールの最後に、セキュリティの自動設定の結果が表示されます。ここに elastic（組み込みの管理者ユーザー）の初期パスワードが含まれます。この画面は一度しか出ないため、パスワードマネージャーなど安全な場所に控えます。シェルの履歴やチャットに貼り付けるのは避けます。控え損ねた場合は、後で再設定できます。

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic

自動設定では、HTTP 通信用とノード間通信用の証明書が /etc/elasticsearch/certs/ に作られ、elasticsearch.yml に TLS の設定が追記されます。

手順2: 起動して接続を確かめる

パッケージ導入直後は自動起動しません。systemd で起動と自動起動を設定します。

sudo systemctl daemon-reload
sudo systemctl enable --now elasticsearch
sudo systemctl status elasticsearch

起動に1分ほどかかることがあります。起動したら、自動生成された CA 証明書を指定して HTTPS で接続します。-u elastic だけを付けるとパスワードを対話で聞かれるため、コマンドラインに平文で書かずに済みます。

sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic https://localhost:9200

クラスター名や版の情報が JSON で返れば成功です。http:// で接続してエラーになるのは、TLS が有効になっているためで、異常ではありません。

起動しない場合は、sudo journalctl -u elasticsearch と /var/log/elasticsearch/ 配下のログを確認します。メモリ不足、設定ファイルの YAML の書式誤り（インデントのずれ）、データディレクトリの権限がよくある原因です。

手順3: elasticsearch.yml の基本設定

設定ファイルは /etc/elasticsearch/elasticsearch.yml です。変更前にコピーを取っておきます。1台で動かす場合、まず見直すのは次の項目です。

# クラスターとノードの名前（後から見分けやすい名前に）
cluster.name: wp-search
node.name: es01

# データとログの保存先（パッケージの既定値のまま使う場合は変更不要）
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

# 待ち受けるアドレス。既定はローカルのみ
network.host: 127.0.0.1
http.port: 9200

network.host を 0.0.0.0 などに変えると、外部から接続できるようになります。同時に、Elasticsearch は外部公開を前提とした「本番モード」の起動前チェックを厳しく行うようになります。外部から接続する必要がある場合でも、ファイアウォールで接続元を WordPress サーバーなどに限定し、インターネットに 9200 番を開けないようにします。

1台構成で注意したいのが、ノードの発見に関する設定です。自動設定により cluster.initial_master_nodes が書き込まれている場合、そこへ discovery.type: single-node を追加すると、両方を同時には指定できないため起動に失敗します。1台構成にしたい場合は、どちらか一方だけになっているかを確認します。

手順4: ヒープメモリを調整する

Elasticsearch は、サーバーのメモリ量からヒープの大きさを自動で決めます。多くの場合は自動のままで問題ありませんが、ほかのサービスと同居させる場合などは明示的に指定します。設定は jvm.options を直接編集せず、jvm.options.d ディレクトリに別ファイルを置きます。

# /etc/elasticsearch/jvm.options.d/heap.options
-Xms2g
-Xmx2g

決め方の目安は次のとおりです。

最小値（-Xms）と最大値（-Xmx）は同じ値にする
物理メモリの半分以下にする。残りは OS のファイルキャッシュとして検索の高速化に使われる
大きなサーバーでも 30GB 前後を上限の目安にする（それを超えると、Java のメモリ効率が下がる境界があるため）

変更後は再起動し、ログに出るヒープの大きさで反映を確認します。あわせて、スワップが頻繁に使われると性能が大きく落ちるため、スワップの無効化や vm.swappiness の調整も検討します。

手順5: インデックスの状態とディスクのしきい値

1台構成でまずつまずくのが、クラスターの状態が黄色（yellow）になる現象です。

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

インデックスは初期設定でレプリカ（複製）を1つ持とうとしますが、複製は元と別のノードにしか置けません。1台しかないと複製の置き場所がなく、黄色になります。データは失われていませんが、1台構成で緑にしたい場合は、インデックスを作るときにレプリカ数を0にします。

sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic -X PUT "https://localhost:9200/wp-posts" \
  -H 'Content-Type: application/json' \
  -d '{"settings": {"number_of_shards": 1, "number_of_replicas": 0}}'

レプリカが0ということは、ディスク障害でデータを失う可能性があるということです。スナップショット（バックアップ）の設定を別途行うか、元データ（WordPress の DB など）から再構築できる用途に限定します。

もう一つの落とし穴がディスクの空き容量です。Elasticsearch には、ディスク使用率に応じて段階的にシャードの配置を止めるしきい値があり、最終段階ではインデックスが読み取り専用になり書き込みが拒否されます。既定値は低い順に 85%・90%・95% です。ログを溜める用途では急にディスクが埋まることがあるため、ディスク使用率の監視と、古いインデックスを消すライフサイクル（ILM）の設定をセットで考えます。

認証用ユーザーを分ける

elastic ユーザーは管理者権限を持つため、アプリケーションの接続には使わず、用途ごとにユーザーとロールを作ります。WordPress の検索連携やログの書き込みには、対象のインデックスに必要な権限だけを持つロールを割り当てます。ロールとユーザーは Kibana の管理画面か、セキュリティ API で作れます。接続用のパスワードや API キーは、wp-config.php の定数や環境変数で渡し、Git に含めないようにします。

まとめ

公式リポジトリから導入し、表示された elastic の初期パスワードを安全な場所に控える（再設定は elasticsearch-reset-password）
8.0 以降は TLS と認証が自動で有効。接続は https:// と http_ca.crt で確かめる
network.host は既定のローカルのまま使い、外部接続が要るときも接続元を限定する
ヒープは jvm.options.d に置き、最小と最大を同じ値で、物理メモリの半分以下にする
1台構成の黄色はレプリカの置き場がないため。ディスクのしきい値を超えると書き込みが止まるので監視する
アプリケーションには elastic を使わず、権限を絞ったユーザーで接続する