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

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

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

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

シャード割り当ての失敗は、Elasticsearchが抽象的なものではなくなるところです。クラスターのヘルスが黄色または赤に変わり、検索が部分的な結果を返し始め、インデックス作成が遅くなり、チームは問題がディスク、欠落したノード、悪い割り当てルール、または破損したシャードデータのいずれであるかを判断する必要があります。

私が最も頻繁に見る間違いは、すべての未割り当てシャードを同じように扱うことです。計画的な再起動後に遅延したレプリカシャードは、メインの注文インデックスの未割り当てプライマリシャードと同じ緊急事態ではありません。まず、どのシャードが未割り当てか、それがプライマリかレプリカか、そしてElasticsearchが割り当ての決定について何を言っているかを特定することから始めます。

ヘルスシグナルを正しく読み取る

クラスターヘルスから始めます：

GET /_cluster/health?pretty

重要なフィールドは、status、active_primary_shards、active_shards、relocating_shards、initializing_shards、unassigned_shards、およびdelayed_unassigned_shardsです。

黄色は、すべてのプライマリシャードが割り当てられているが、1つ以上のレプリカが割り当てられていないことを意味します。データはまだ利用可能であるはずですが、冗長性が低下しています。

赤は、1つ以上のプライマリシャードが割り当てられていないことを意味します。Elasticsearchがレプリカを昇格させたり、シャードを持っていたノードを回復したり、スナップショットから復元したりしない限り、それらのシャードのデータは利用できません。

relocating_shardsまたはinitializing_shardsがゼロ以外の場合、クラスターはすでに回復している可能性があります。色が一時的に黄色だからといって、通常の回復を中断しないでください。

未割り当てシャードを一覧表示する

_cat/shardsを使用して正確な問題を確認します：

GET /_cat/shards?v&h=index,shard,prirep,state,node,unassigned.reason&s=state,index

UNASSIGNEDを探します。prirep列は、シャードがプライマリ（p）かレプリカ（r）かを示します。unassigned.reason列は、NODE_LEFT、INDEX_CREATED、CLUSTER_RECOVERED、ALLOCATION_FAILEDなどの短い理由を示します。

大規模なクラスターの場合は、絞り込みます：

GET /_cat/shards/logs-*?v&h=index,shard,prirep,state,node,unassigned.reason

インデックス、シャード番号、プライマリ/レプリカフラグを取得したら、Elasticsearchに実際の説明を求めます。

割り当て説明APIを使用する

現在未割り当てのシャードの場合：

GET /_cluster/allocation/explain
{}

特定のシャードの場合：

GET /_cluster/allocation/explain
{
  "index": "logs-2026.05.24",
  "shard": 0,
  "primary": false
}

can_allocate、allocate_explanation、unassigned_info、およびnode_allocation_decisionsを読み取ります。ノードの決定は、各ノードが拒否された理由を示すため、特に便利です。一般的な決定要因には、ディスクしきい値、同一シャードルール、割り当てフィルター、アウェアネスルール、およびノードあたりのシャード総数制限が含まれます。

プライマリに対して出力がno_valid_shard_copyと言っている場合は、真剣に受け止めてください。Elasticsearchは現在、そのプライマリシャードの使用可能なコピーを認識していません。

原因1：適切なノードが不足している

1つのレプリカを持つ単一ノードクラスターは、永久に黄色になります。Elasticsearchは、プライマリと同じノードにレプリカを配置しません。2つのレプリカで構成されたインデックスを持つ3ノードクラスターには、3つの適切なデータノードが必要です。割り当てアウェアネスが、コピーをゾーン全体に分散する必要があると言っている場合は、必要なゾーンに十分なノードも必要です。

レプリカ設定を確認します：

GET /my-index/_settings?filter_path=*.settings.index.number_of_replicas

これがラボまたは一時的な環境の場合は、レプリカを減らします：

PUT /my-index/_settings
{
  "index": {
    "number_of_replicas": 0
  }
}

本番環境では、通常、適切なデータノードを追加するか、非現実的なレプリカ数を調整する方が良い答えです。レプリカを減らすと冗長性が失われます。

原因2：ディスクのウォーターマーク

ディスクプレッシャーは、最も一般的な割り当てブロッカーの1つです。Elasticsearchはディスクウォーターマークを使用して、ノードがいっぱいになるのを防ぎます。ノードがしきい値を超えると、Elasticsearchはそれらへのシャードの割り当てを停止し、シャードを移動させる場合があります。

割り当てとディスク使用量を確認します：

GET /_cat/allocation?v
GET /_cat/nodes?v&h=name,ip,disk.used_percent,disk.avail,heap.percent,ram.percent,node.role

割り当て説明の出力は、ノードが低または高ディスクウォーターマークを超えていると言う場合があります。インデックスがフラッドステージ条件に達した場合、Elasticsearchは影響を受けるインデックスに書き込みブロックを設定することもあります。

適切な修正は容量修正です：スナップショットを確認した後に古いインデックスを削除し、ディスクを追加し、データノードを追加し、データを別のティアに移動するか、Index Lifecycle Managementを通じて保持期間を短縮します。

制御された緊急時にはウォーターマークを変更することは合理的ですが、それは容量計画ではありません。すべてのデータノードがほぼ満杯の場合、しきい値を上げると、クラスターが障害に近づくだけです。

フラッドステージイベントからスペースを解放した後、読み取り専用ブロックを確認します：

GET /my-index/_settings?filter_path=*.settings.index.blocks.write,*.settings.index.blocks.read_only_allow_delete

ディスクプレッシャーが解決された後にのみブロックを削除します：

PUT /my-index/_settings
{
  "index.blocks.read_only_allow_delete": null
}

原因3：メンテナンス後に割り当てが無効になっている

チームはローリングメンテナンス中に割り当てを無効にすることがよくありますが、その後元に戻すのを忘れます。

クラスター設定を確認します：

GET /_cluster/settings?include_defaults=true&pretty

cluster.routing.allocation.enableを探します。値には、all、primaries、new_primaries、およびnoneが含まれます。noneの場合、レプリカおよび場合によっては他のシャードの移動は正常に割り当てられません。

割り当てを再度有効にします：

PUT /_cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "all"
  }
}

transient設定も確認します。永続セクションが正常に見えても、一時的なメンテナンス設定がクラスターに影響を与える可能性があります。

原因4：制限的な割り当てフィルター

インデックスレベルのフィルターは、インデックスを特定のノードに固定できます：

GET /my-index/_settings?filter_path=*.settings.index.routing.allocation.*

クラスターレベルのフィルターは、ノードを割り当てから除外できます：

GET /_cluster/settings?include_defaults=true&filter_path=**.cluster.routing.allocation.*

ノード属性も重要です：

GET /_cat/nodeattrs?v

典型的な失敗は次のようになります：インデックスはbox_type: hotを必要としますが、ホットノードが置き換えられ、新しいノードにはnode.attr.box_type: hotがありません。Elasticsearchはルールを正確に守っています。ルールが間違っています。

過度に制限的なインデックスフィルターを削除するには：

PUT /my-index/_settings
{
  "index.routing.allocation.require.box_type": null,
  "index.routing.allocation.include.box_type": null,
  "index.routing.allocation.exclude.box_type": null
}

インデックスに存在する正確な設定名を使用します。実際のゾーンまたはティアの要件をエンコードする場合、割り当てルールを盲目的に削除しないでください。

原因5：ノード離脱後の遅延割り当て

ノードが離脱すると、Elasticsearchはレプリカシャードの割り当てを遅延させる場合があります。これは、ノードがすぐに戻ってくる可能性があるためです。これにより、通常の再起動中に大きなシャードをネットワーク経由でコピーするのを避けます。

遅延シャードを確認します：

GET /_cluster/health?pretty

delayed_unassigned_shardsがゼロより大きく、ノードが戻ってくると予想される場合、待機が最善のアクションである可能性があります。インデックス設定を検査することもできます：

GET /my-index/_settings?filter_path=*.settings.index.unassigned.node_left.delayed_timeout

デフォルトは通常1分ですが、常にクラスターとバージョンを確認してください。一部のチームは、大きなシャードの計画的なローリング再起動のためにそれを増やします。実際の障害でレプリカが不快な時間欠落したままになるほど長くしないでください。

原因6：ノード上のシャードが多すぎる

index.routing.allocation.total_shards_per_nodeは、1つのインデックスからのシャードが同じノードにいくつ存在できるかを制限できます。クラスターレベルのシャード制限も適用される場合があります。これらの設定は便利ですが、小規模クラスターでは割り当てをブロックする可能性があります。

インデックス設定を確認します：

GET /my-index/_settings?filter_path=*.settings.index.routing.allocation.total_shards_per_node

5つのプライマリシャード、1つのレプリカ、2つのデータノード、および低いノードあたりの制限がある場合、Elasticsearchには法的な配置がない可能性があります。制限を修正するか、ノードを追加するか、シャード数を再設計します。

原因7：プライマリの有効なコピーがない

これは恐ろしいケースです。割り当て説明は、プライマリの有効なシャードコピーがないと報告する場合があります。プライマリを持つ唯一のノードがなくなった可能性があります。ディスクが故障した可能性があります。シャードデータが破損している可能性があります。

まず、欠落したノードが戻ってくると予想される場合は、それを回復してみてください。システムログ、Elasticsearchログ、ディスクヘルス、およびネットワーク接続を確認します。有効なレプリカが存在する場合、Elasticsearchは通常それを昇格させるはずです。

有効なコピーが存在しない場合は、スナップショットから復元します：

POST /_snapshot/my_repository/snapshot_name/_restore
{
  "indices": "affected-index"
}

データをソースシステムから再構築でき、シャードの内容を失うことを受け入れる場合、allocate_empty_primaryが利用可能ですが、これはデータ損失操作です：

POST /_cluster/reroute
{
  "commands": [
    {
      "allocate_empty_primary": {
        "index": "affected-index",
        "shard": 0,
        "node": "target-node",
        "accept_data_loss": true
      }
    }
  ]
}

欠落したデータがなくなったか再構築可能であると意識的に決定しない限り、これを「クラスターを緑にする」ために使用しないでください。

回復を監視する

変更を行った後、進行状況を監視します：

GET /_cat/recovery?v&active_only=true
GET /_cat/shards?v&h=index,shard,prirep,state,node,unassigned.reason
GET /_cluster/health?pretty

大きなシャードには時間がかかります。_cat/recoveryでバイト数が移動している場合、クラスターは機能しています。何も変わらない場合は、割り当て説明を再度確認します。最初の修正後、Elasticsearchの決定が変更され、次のブロッカーが明らかになる場合があります。

実際に役立つ予防策

ウォーターマークに達する前にディスクを監視します。満杯のディスクだけでなく、傾向にアラートを設定します。

ログとメトリクスにはILMまたはデータストリームを使用して、保持が自動的に行われるようにします。

スナップショットを最新に保ち、復元をテストします。復元したことのないスナップショットは、単なる希望にすぎません。

シャードサイズとシャード数を適切に保ちます。小さすぎるシャードが多すぎると、割り当てと回復がデータ量から予想されるよりも遅くなります。

割り当てフィルターとノード属性を文書化します。6か月後、誰かがノードを交換し、インデックスを割り当て可能にした属性を忘れるでしょう。

黄色を警告として扱い、赤をインシデントとして扱います。黄色はメンテナンス中は許容できますが、背景ノイズになるべきではありません。赤は少なくとも1つのプライマリシャードが利用できないことを意味し、待つ時間が長いほど、簡単な回復オプションが少なくなる可能性があります。

インシデントのためのフィールドチェックリスト

シャード割り当てが壊れた場合、毎回同じ証拠を収集します。これにより、チームが理論間を行き来するのを防ぎます。

実行：

GET /_cluster/health?pretty
GET /_cat/nodes?v&h=name,ip,roles,master,disk.used_percent,heap.percent,ram.percent
GET /_cat/shards?v&h=index,shard,prirep,state,node,unassigned.reason&s=state,index
GET /_cat/allocation?v
GET /_cat/recovery?v&active_only=true
GET /_cluster/settings?include_defaults=true&pretty

次に、代表的な未割り当てシャードに対して割り当て説明を実行します。多数ある場合は、理由でグループ化します。ディスクウォーターマークによってブロックされた10の未割り当てレプリカは1つの問題です。no_valid_shard_copyを持つ3つのプライマリは別の問題です。

影響を受けるデータを再構築できるかどうかを書き留めます。アップストリームキューからのログ、エージェントからのメトリクス、および派生検索インデックスは、ソースシステムから回復可能な場合があります。ユーザー作成コンテンツまたはコンプライアンスレコードは回復できない場合があります。回復コマンドは、そのビジネス現実に従う必要があります。

いつ待つか、いつ行動するか

回復が積極的に進行している場合、欠落したノードがすぐに戻ってくると予想される場合、または遅延割り当てが設定したとおりに機能している場合は待機します。_cat/recoveryで進行状況を確認できます。移動するバイト数とファイル数は良い兆候です。

割り当て説明が永続的なブロッカーを示している場合に行動します：適切なノードがない、すべてのノードでディスクウォーターマーク、割り当てが無効、欠落したノード属性、または有効なシャードコピーがない。待機しても、すべてのノードを拒否するルールは修正されません。

重要なインデックスのプライマリシャードが割り当てられていない場合は、迅速にエスカレーションします。レプリカの失敗は安全性を低下させます。プライマリの失敗は可用性を低下させます。

回復を遅くしないようにする

大規模な回復は、通常の検索とインデックス作成と競合します。一度にあまりにも多くのノードを追加したり、より多くのノードを再起動したり、ディスクとネットワーク容量を確認せずに回復の同時実行性を上げたりすると、クラスターの安定性が低下する可能性があります。

回復設定を調整する場合は、意図的に行い、元の値を記録します。同時回復などの設定は、一部の環境では役立ち、他の環境では害を及ぼす可能性があります。理論上の高速な回復は、ディスクに過負荷をかけ、クエリレイテンシを十分に増加させて、ユーザーがより悪い停止を経験する可能性があります。

ホットノードに注意してください。割り当ては技術的に成功する可能性がありますが、シャードサイズ、ティアルール、または不均一なディスク使用量のために、1つのノードに過剰な作業を配置します。_cat/allocation、ノード統計、および監視システムを使用して、即時の障害が解消された後にクラスターがバランスが取れていることを確認します。

事後対応の修正

ほとんどのシャード割り当てインシデントには予防のストーリーがあります。ディスクウォーターマークのインシデントは、保持、ILM、または容量計画を指します。割り当てフィルターのインシデントは、不足しているランブックドキュメントを指します。有効なコピーがないインシデントは、スナップショットとアップストリームリプレイを指します。遅い回復は、シャードサイズとハードウェアを指します。

ヘルスが緑だからといってインシデントを閉じないでください。一時的なレプリカの変更を削除し、通常のリフレッシュ間隔を復元し、変更された場合は割り当てを再度有効にし、スナップショットを確認し、問題を早期にキャッチできたアラートを追加します。

特別なケース：クローズされたインデックスと非表示インデックス

インデックスが割り当てられていないのは、クローズされている、非表示である、または触れていることに気づかなかったシステム機能の一部である場合があります。システムインデックスが存在する場合、広範なワイルドカードコマンドには注意してください。最新のクラスターでは、セキュリティ、Kibana、トランスフォーム、およびその他のスタック機能が独自のインデックスを維持する場合があります。

狭いパターンを使用し、非表示インデックスを検査する場合にのみ含めます。システムインデックスに割り当ての問題がある場合は、Elasticsearchだけでなく、関連するスタックコンポーネントのログも確認します。たとえば、Kibanaの保存オブジェクトインデックスの問題は、Elasticsearchのシャード割り当ての問題とKibanaの起動失敗として現れる場合があります。

ルールはユーザーデータと同じです：正確なインデックスを特定し、それを所有するものを理解し、修正を選択します。製品レベルの影響を理解しない限り、赤いヘルスステータスをクリアするためだけにシステムインデックスを削除したり強制割り当てしたりしないでください。