DevOpsナレッジハブ
DevOpsナレッジハブ

Elasticsearchの一般的なシャード割り当て失敗のトラブルシューティング

一般的なElasticsearchのシャード割り当ての失敗をトラブルシューティングし、解決する方法を学びます。このガイドでは、未割り当てのシャードの特定、ディスク容量エラー、ノードの利用不可、割り当てフィルタリングなどの問題の診断、および正常なElasticsearchクラスターを維持するための実用的な解決策とベストプラクティスについて解説します。

26 ビュー

Elasticsearch シャード割り当ての一般的な失敗のトラブルシューティング

強力な分散検索・分析エンジンである Elasticsearch は、シャードを使用してデータを複数のノードに分散させる能力に大きく依存しています。これらのシャードの割り当てに失敗すると、データが利用できなくなったり、検索が失敗したり、クラスタの健全性が低下したりする可能性があります。シャード割り当て失敗の一般的な原因を理解し、それらを診断・解決する方法を知ることは、安定したパフォーマンスの高い Elasticsearch 環境を維持するために不可欠です。この記事では、最も頻繁に発生する問題について説明し、シャードを割り当て済みの状態に戻すための実用的な手順を提供します。

このガイドは、本番環境の Elasticsearch における実践的なトラブルシューティングに焦点を当てています。割り当てられていないシャードの特定、ディスク容量、割り当てルール、ノードの問題など、一般的な失敗の原因の理解、そしてこれらの問題を効率的に解決するための明確な手順を説明します。これらのテクニックを習得することで、ダウンタイムを最小限に抑え、Elasticsearch クラスタの信頼性を確保できます。

割り当てられていないシャードの特定

トラブルシューティングの最初のステップは、どのシャードが割り当てられておらず、その理由を特定することです。Elasticsearch はこのためにいくつかのツールを提供しています。

Cluster Health API の使用

_cluster/health API は、クラスタのステータスに関する概要を提供します。レスポンスの unassigned_shards を確認してください。ゼロ以外の値は問題があることを示します。

GET _cluster/health

レスポンスの例:

{
  "cluster_name": "my-es-cluster",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 3,
  "number_of_data_nodes": 3,
  "active_primary_shards": 10,
  "active_shards": 20,
  "relocating_shards": 0,
  "initializing_shards": 1,
  "unassigned_shards": 1,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "max_length_search_concurrency": 1000,
  "max_length_search_size": 10000,
  "active_shards_percent_as_number": 95.45454545454545
}

この例では、"status": "yellow" と "unassigned_shards": 1 は、1つのシャードが割り当てられていないことを示しています。red ステータスは、1つ以上のプライマリシャードが割り当てられていないことを意味し、データ利用に影響します。yellow ステータスは、レプリカシャードが割り当てられていないが、プライマリシャードは割り当てられていることを意味するため、データは検索可能ですが、完全な冗長性はありません。

Allocation Explain API の使用

特定のシャードが割り当てられていない理由に関する詳細な洞察を得るには、_cluster/allocation/explain API が非常に役立ちます。シャードの詳細を指定することも、クラスタの状態を分析させることもできます。

割り当てられていない任意のシャードの説明を取得するには:

GET _cluster/allocation/explain

特定のシャードの説明を取得するには（index_name と shard_id を置き換えてください）:

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

一般的な原因と解決策

シャードが割り当てられていない状態になる原因はいくつかあります。以下に最も一般的な原因とそれらに対処する方法を示します。

1. ディスク容量不足

これは、シャード割り当て失敗の最も頻繁な原因と言えます。ノードのディスク容量がなくなると、Elasticsearch はデータ破損を防ぎ、安定性を確保するために、そこに新しいシャードが割り当てられるのを防ぎます。既存のシャードが追い出される可能性もあります。

  • 症状: Allocation Explain API は、"cannot allocate because disk usage [X%] exceeds the low watermark [Y%]" または "cannot allocate because disk usage [X%] exceeds the high watermark [Y%]" のようなメッセージを報告することがよくあります。
  • 診断: データノードのディスク使用量を確認してください。_cat/allocation API を使用すると、概要を素早く確認できます。
    bash GET _cat/allocation?v
    ディスク使用率の高いノードを探してください。
  • 解決策:
    • ディスク容量の追加: 最も簡単な解決策は、影響を受けているノードにストレージを追加するか、既存のディスクをより大きなものに交換することです。
    • 未使用インデックスの削除: ディスク容量を消費している古いまたは不要なインデックスを特定して削除します。
    • ウォーターマークの調整: elasticsearch.yml 設定ファイルまたはクラスタ設定 API を介して、ディスク使用量ウォーターマーク (cluster.routing.allocation.disk.watermark.low, cluster.routing.allocation.disk.watermark.high, cluster.routing.allocation.disk.watermark.flood_stage) を調整できます。ただし、これらの設定はクラスタを保護するために設計されているため、調整する際には注意が必要です。容量を追加せずにこれらの設定を下げると、さらなる問題が発生する可能性があります。
      json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.disk.watermark.low": "85%", "cluster.routing.allocation.disk.watermark.high": "90%", "cluster.routing.allocation.disk.watermark.flood_stage": "95%" } }
    • ノードの追加: より多くのデータノードを追加して、クラスタをスケールアウトします。これにより、データが分散され、個々のノードへの負荷が軽減されます。
    • 強制マージまたは古いデータの削除: 時系列データがある場合は、古いインデックスに対して _forcemerge API を使用してセグメント数を減らす（ディスク容量を解放できる可能性がある）か、インデックスライフサイクル管理（ILM）を使用して古いデータを自動的に削除することを検討してください。

2. ノードが利用できない、または再起動中

ノードがダウンしている、再起動中である、またはネットワークの問題を抱えている場合、そのノード上にあるシャードは割り当てられなくなります。プライマリシャードの場合、クラスタのステータスは赤になります。

  • 症状: Allocation Explain API は、ノードが利用できないため、またはダウンしているために (excluded) とマークされているため、シャードを割り当てられないことを示します。
  • 診断: _cat/nodes API を使用して、ノードのステータスを確認します。期待されるすべてのノードがリストされ、正常であることを確認してください。
    bash GET _cat/nodes?v
    影響を受けているノードの Elasticsearch ログを確認し、エラーやシャットダウンの兆候がないか調べます。
  • 解決策:
    • ノードの再起動: ノードがダウンしている場合は、Elasticsearch サービスを再起動してみてください。
    • ネットワーク問題の解決: ノードがクラスタ内の他のノードと通信できることを確認してください。
    • ログの確認: 影響を受けているノードの Elasticsearch ログを調べて、障害の根本原因（例: メモリ不足、ディスクエラー、JVM 問題）を特定してください。
    • index.unassigned.node_left.delayed_timeout の増加: ノードが頻繁にクラスタに参加したり離脱したりする場合（例: ローリング再起動中）、レプリカシャードが一時的に割り当てられなくなることがあります。index.unassigned.node_left.delayed_timeout 設定（デフォルトは 1 分）により、Elasticsearch は離脱したノード上のシャードが割り当てられなくなったとマークする前に待機するため、ノードが再参加する時間を与えます。必要に応じてこの値を増やしますが、リカバリ時間への影響に注意してください。

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

Elasticsearch では、ノード属性やアンチアフィニティなど、さまざまな割り当てルールを使用してシャードの割り当て場所を制御できます。これらのルールが割り当てを妨げると、シャードが割り当てられなくなる可能性があります。

  • 症状: Allocation Explain API は、特定の属性に対して割り当てが無効になっていること、または設定されたルールに従って適切なノードがないことを報告します。
  • 診断:
    • インデックス設定の index.routing.allocation.require.*, index.routing.allocation.include.*, index.routing.allocation.exclude.*, index.routing.allocation.total_shards_per_node を確認します。
    • クラスタレベル設定の cluster.routing.allocation.enable（例: all, primaries, new_primaries, none）を確認します。
    • GET _cat/nodeattrs?v を使用してノード属性を確認します。
  • 解決策:
    • インデックス設定の更新: 制限的なインデックスルーティングルールを削除または調整します。たとえば、任意のノードへの割り当てを許可するには:
      json PUT my-index/_settings { "index": { "routing": { "allocation": { "require": null, "include": null, "exclude": null } } } }
    • クラスタ設定の更新: 無効にされていた場合は、一時的に割り当てを有効にします:
      json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "all" } }
      この設定が一時的なものであった場合は、必ず元に戻してください。
    • ノード属性の更新: ノードが elasticsearch.yml で定義された期待される属性（例: node.attr.zone: us-east-1）を持っていること、およびこれらの属性が割り当てルールと一致していることを確認します。elasticsearch.yml を変更した後、変更を有効にするにはノードを再起動する必要があります。

4. シャードデータの破損（まれ）

まれに、シャードデータが破損し、Elasticsearch が起動できなかったり、シャードを割り当てられなかったりすることがあります。これは、基盤となるディスクの問題でより一般的です。

  • 症状: ログにシャードデータまたはインデックス破損の読み取りに関連するエラーが表示されることがあります。Allocation Explain API は明確な理由を示さないか、読み取りエラーを指摘する可能性があります。
  • 診断: シャードが配置されると予想されるノードの Elasticsearch ログを注意深く調べます。I/O エラーまたはデータ破損メッセージを探します。
  • 解決策:
    • スナップショットからの復元: 最も信頼性の高い解決策は、影響を受けたインデックス（またはクラスタ全体）を既知の良好なスナップショットから復元することです。これが、定期的なバックアップが不可欠である理由です。
    • シャードの強制削除（最終手段）: スナップショットから復元できず、データがクリティカルでないか、再インデックス可能である場合は、破損したシャードを強制的に削除する必要があるかもしれません。これは高度な操作であり、その影響を理解している場合にのみ実行する必要があります。通常、影響を受けているノードを停止し、シャードデータディレクトリを手動で削除してから、ノードを再起動する必要があります。これにより、そのシャードのデータが失われます。 Elasticsearch のドキュメントで、お使いのバージョンに固有の正確な手順を確認してください。

5. リロケーション能力不足

ノードがクラスタを離脱したり、ディスク容量の問題が発生したりすると、Elasticsearch はシャードを他のノードにリロケートしようとします。適切なノードが十分でない場合や、クラスタがすでに高負荷状態にある場合、シャードのリロケーションが停滞し、initializing_shards または unassigned_shards が発生する可能性があります。

  • 症状: シャードが長期間 initializing または relocating 状態のままになるか、新しいシャードの割り当てが失敗します。
  • 診断: _cat/shards と _cat/allocation を確認して、シャードのステータスとディスク使用量を確認します。クラスタの健全性とノードの CPU/IO 使用率を監視します。
  • 解決策:
    • ノードの追加: データノードを追加して、クラスタの容量を増やします。
    • リソースの解放: 既存のノードのパフォーマンスボトルネック（例: 高 CPU、遅いディスク I/O）を解消します。
    • シャード割り当て設定の調整: cluster.routing.allocation.node_concurrent_recoveries（ノードで同時にリカバリできるシャード数）や cluster.routing.allocation.node_concurrent_incoming_recoveries（他のノードから同時にリカバリできるシャード数）などの設定を調整できます。ただし、これらの値を増やすとクラスタにさらに負荷がかかる可能性があるため、注意してください。

予防のためのベストプラクティス

  • ディスク容量の監視: すべてのデータノードのディスク使用量を積極的に監視します。ディスク使用量が定義済みのしきい値（例: 80% または 85%）を超えた場合にアラートを設定します。
  • インデックスライフサイクル管理（ILM）の実装: 時系列データの管理を自動化します。これには、古いインデックスのロールオーバー、縮小、削除が含まれます。これにより、ディスク容量の使用量を制御できます。
  • 定期的なスナップショット: 定期的かつ自動化されたデータスナップショットによる堅牢なバックアップ戦略を確実に実施します。復元プロセスを定期的にテストします。
  • 割り当てルールの理解: ハードウェア、データ、可用性の要件に基づいて、シャード割り当てルールを慎重に計画し、設定します。
  • 十分なハードウェア: ノードが、ワークロードとシャードリカバリプロセスを処理するのに十分な CPU、RAM、および I/O 能力を備えていることを確認します。
  • クラスタヘルス監視: _cluster/health API を使用してクラスタの健全性を定期的に確認し、Kibana の Stack Monitoring などのツールで視覚化します。

結論

Elasticsearch のシャード割り当て失敗は厄介な問題ですが、Cluster Health API や Allocation Explain API などのツールを使用して体系的に問題を診断し、ディスク容量、ノードの可用性、割り当てルールなどの一般的な原因を理解することで、効果的に解決できます。定期的なバックアップや ILM などのベストプラクティスへの準拠と、プロアクティブな監視は、これらの問題を未然に防ぎ、安定した健全な Elasticsearch クラスタを確保するための鍵となります。