赤色クラスター状態の解決：Elasticsearchトラブルシューティングのためのステップバイステップガイド

Elasticsearchの赤色クラスター状態の解決：ステップバイステップのトラブルシューティングガイド

Elasticsearchクラスターのヘルス状態は、その運用効率とデータ可用性にとって極めて重要です。クラスターの状態が赤または黄色に変わった場合、直ちに対処が必要な根本的な問題があることを示します。red（赤色）の状態は、インデックスまたはシャードが割り当てられていないことを意味し、データにアクセスできない可能性や操作が失敗する可能性があることを示します。yellow（黄色）の状態は、プライマリシャードは割り当てられているものの、一部のレプリカシャードが割り当てられていないことを示します。赤色ほどクリティカルではありませんが、データの永続性にとって依然としてリスクがあります。本ガイドでは、これらの一般的なElasticsearchクラスターヘルス問題の診断と解決に向けた体系的なアプローチを提供します。

これらのステータス問題の根本原因を理解することが、解決への第一歩です。一般的な原因としては、ディスク容量の不足、ノードの過負荷、ネットワークの問題、またはシャード割り当てに関連する設定ミスが挙げられます。以下に示す診断手順に従うことで、正確な問題を特定し、効果的な解決策を実施して、クラスターを健全なgreen（緑色）の状態に復元することができます。

Elasticsearchクラスターヘルスについて

Elasticsearchは、クラスターの状態とシャードの割り当てのスナップショットを提供するクラスターヘルスAPIを提供しています。このAPIは、ヘルス問題の診断における主要なツールです。

GET _cluster/health

このコマンドの出力には、green、yellow、またはredのいずれかであるstatusフィールドが含まれます。また、アクティブなシャードと割り当てられていないシャードの数に関する情報も提供されます。

• Green（緑色）: すべてのプライマリシャードとレプリカシャードが割り当てられ、正しく機能しています。
• Yellow（黄色）: すべてのプライマリシャードは割り当てられていますが、一部のレプリカシャードが割り当てられていません。
• Red（赤色）: 1つ以上のプライマリシャードが割り当てられておらず、それらのシャードのデータが利用できません。

赤色/黄色のステータスに関する一般的な原因とトラブルシューティング手順

クラスターがgreenでない場合は、調査の時です。ここでは、シャードが割り当てられない最も一般的な理由とそれらに対処する方法を示します。

1. ディスク容量の不足

ディスクがいっぱいになることによるデータ破損を防ぐため、Elasticsearchには保護機能があります。ノードのディスク容量がなくなると、新しいシャードの割り当てや既存のシャードのリカバリが防止されます。

診断：

• 各ノードのディスク使用量を確認します。
• _cluster/allocation/explain APIを使用して、シャードが割り当てられていない理由を理解します。

GET _cluster/allocation/explain

このAPIは詳細な理由を提供し、多くの場合、ディスクのウォーターマークを示します。

解決策：

• ディスク容量の解放： 古いインデックスを削除する、セグメントマージを実行する、または不要なデータを削除します。
• ディスク容量の追加： ノードのストレージ容量を増やします。
• ディスクウォーターマークの設定： cluster.routing.allocation.disk.watermark.low、high、およびflood_stageの設定を調整して、Elasticsearchがディスクがフルであると見なし始めるタイミングを制御します。これらの設定は根本的な容量の問題を隠す可能性があるため、注意して扱ってください。

2. ノードのクラスター離脱（ノードの退避）

ノードは、ネットワークの問題、クラッシュ、または意図的な削除によりクラスターを離れることがあります。シャード（特にプライマリシャード）を保持していたノードが離脱すると、それらのシャードは割り当てられなくなります。

診断：

• 最近離脱したノードがないかクラスターログを確認します。
• ノード間のネットワーク接続を監視します。
• すべてのノードがお互いに検出可能であることを確認します（discovery.seed_hostsおよびcluster.initial_master_nodesの設定を確認します）。

解決策：

• ノードの再起動： ノードがクラッシュしたり応答しなくなった場合は、再起動を試みます。
• ネットワーク問題への対処： ノード間のネットワーク接続の問題を解決します。
• ノードの再追加： ノードが意図的に削除された場合は、クラスターに再参加する前に正しく設定されていることを確認します。

3. シャード割り当てフィルタリングとアウェアネス

不適切に設定されたシャード割り当てルールにより、シャードが利用可能なノードに割り当てられないことがあります。

診断：

• cluster.routing.allocation.*設定、特にcluster.routing.allocation.include、exclude、およびrequireフィルターを確認します。
• ゾーンまたはラックアウェアネスを使用している場合は、cluster.routing.allocation.awareness.attributesを確認します。

解決策：

• 割り当てフィルターの調整： フィルターを変更して、シャードが適切なノードに割り当てられるようにします。
• アウェアネス属性の修正： 使用されている場合、ノードにアウェアネス属性が正しくタグ付けされており、割り当てルールがそれらを尊重していることを確認します。

4. 割り当てのためのディスク容量不足（インデックス作成後）

ディスクが一杯でなくても、Elasticsearchは割り当て後にディスクが高水準標識を超える可能性があると予測する場合、シャードの割り当てを防ぐことがあります。これはディスクウォーターマークに関連していますが、新しい割り当てに特に関連しています。

診断：

• _cluster/allocation/explain APIが非常に役立ちます。
• 利用可能な空き容量とシャードの予想サイズを確認します。

解決策：

• 一般的なディスク容量の問題と同様：容量を解放する、ストレージを追加する、または慎重にウォーターマークを調整します。

5. シャードサイズとノードのキャパシティ

非常に大きなシャードや多数のシャードは、ノードのリソース（CPU、メモリ）に負担をかけ、割り当てに影響を与える可能性があります。また、ノードがシャード数の上限（cluster.routing.allocation.total_shards_per_node）に達している場合、新しいシャードはそのノードに割り当てられません。

診断：

• シャードサイズを確認します（GET _cat/shards?v）。
• ノードのリソース使用率（CPU、メモリ）を監視します。
• cluster.routing.allocation.total_shards_per_node設定を見直します。

解決策：

• シャードサイズの縮小： データをより少ないシャード数またはより小さいシャードサイズのインデックスに再インデックスすることを検討します。一般的なガイドラインとして、シャードサイズを10GBから50GBの間に収めることを目指します。
• ノードキャパシティの向上： より高性能なノード、またはより多くのメモリ/CPUを持つノードを追加します。
• シャード制限の調整： 必要な場合、かつ十分なリソースがある場合は、cluster.routing.allocation.total_shards_per_nodeを増やします。

6. マスターノードの問題

不安定なマスターノードは、シャード割り当ての問題につながる可能性があります。マスターが利用できない、またはその職務を遂行できない場合、シャードが割り当てられなくなる可能性があります。

診断：

• マスター関連のエラーや警告がないかクラスターログを確認します。
• スプリットブレインシナリオを避けるため、奇数（通常は3または5）のマスター適格ノードがあることを確認します。
• マスター適格ノードがマスターを選出できるか確認します。

解決策：

• マスターの安定化： マスター適格ノードが健全であり、十分なリソースを持ち、適切に接続されていることを確認します。
• initial_master_nodesの修正： クラスターの初回起動時にこの設定が正しく構成されており、安定していることを確認します。

_cluster/allocation/explainを使用した高度なトラブルシューティング

_cluster/allocation/explain APIは、特定のシャードが割り当てられていない理由を理解するための最も強力なツールです。

例：

GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": true
}

これにより、my-indexのプライマリシャード0が割り当てられない理由を説明する詳細なJSON出力が返されます。割り当て解除の理由（例：DISK_THRESHOLD、NODE_LEFT、NO_VALID_SHARD_COPY）をリストするdecidersのようなフィールドを探してください。

黄色いクラスター状態の解決

黄色いステータスは、プライマリシャードは割り当てられているが、レプリカが割り当てられていないことを意味します。これは主にデータの冗長性と耐障害性に影響します。

一般的な原因：

• ノード不足： インデックスに必要な数のレプリカを収容するのに十分なノードがありません。
• シャード割り当てフィルタリング： 赤色のステータスと同様に、フィルターがレプリカの割り当てを妨げている可能性があります。
• ディスク容量の制約： ノードにはプライマリシャードを収容するのに十分な容量があっても、特にディスクウォーターマークが有効な場合、レプリカのための容量が不足している可能性があります。

解決策：

• ノードの追加： クラスター内のノード数を増やします。
• レプリカ数の調整： 障害許容性がすべてのインデックスに対して重要でない場合は、インデックスごとのレプリカ数（index.number_of_replicas）を減らします。
• 割り当て設定の確認： レプリカシャードが利用可能なノードに割り当てられることが許可されていることを確認します。

クラスターヘルス維持のためのベストプラクティス

• ディスク使用率の監視： すべてのノードのディスク容量を事前に監視し、アラートを設定します。
• クラスターの適切なサイジング： データ量とクエリ負荷に対して、十分なノードとリソースがあることを確認します。
• シャード管理： シャードサイズを推奨範囲内に保ち、過剰なシャーディングを避けます。
• クラスターヘルスを定期的に確認： 日常的な監視の一環としてGET _cluster/healthおよびGET _cluster/allocation/explainを使用します。
• 変更のテスト： 割り当て設定やディスクウォーターマークに大きな変更を加える前に、ステージング環境でテストします。

結論

赤色または黄色のElasticsearchクラスター状態を解決するには、診断に対して体系的なアプローチが必要です。Cluster Health API、Cluster Allocation Explain APIを活用し、ディスク容量、ネットワークの問題、割り当て設定などの一般的な障害点を理解することにより、効果的にトラブルシューティングを行い、クラスターを最適なヘルス状態に復元することができます。一貫した監視とベストプラクティスの遵守は、これらの問題がそもそも発生するのを防ぐための鍵となります。