Amazon Elasticsearch Service ノードがクラッシュしたのはなぜですか?

最終更新日: 2020 年 9 月 10 日

Amazon Elasticsearch Service (Amazon ES) クラスター内のノードの 1 つが停止しています。なぜノードに障害が発生したのでしょうか。また再発を防止する方法を教えてください。

簡単な説明

各 Amazon ES ノードは、別々の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上で実行されます。障害が発生したノードとは、他のノードからのハートビート信号に応答していないインスタンスのことです。ハートビート信号とは、クラスター内のデータノードの可用性をモニタリングする定期的な信号のことです。

クラスターノード障害の一般的な原因は次のとおりです。

  • Java 仮想マシン (JVM、Java Virtual Machine) の高いメモリ負荷
  • ハードウェア障害

解決方法

障害が発生したノードを確認する

1.    [Amazon ES コンソール] を開きます。

2.    Elasticsearch ドメインの名前を選択します。

3.    [クラスターの健全性] タブを選択してから、ノードメトリクスを選択します。ノード数がクラスターに設定した数より少ない場合、ノードは停止しています。

注:クラスター設定の変更中あるいはサービスの定期保守中は、 ノードメトリクスが正確ではない場合があります。これは想定された動作です。

高い JVM メモリ負荷を特定してトラブルシューティングする

JVM メモリ負荷とは、Elasticsearch クラスター内のすべてのデータノードに使用されている Java ヒープの割合を指します。JVM のメモリ負荷が高いと、CPU 使用率が高くなり、他のクラスターパフォーマンス上の問題が発生するおそれがあります。

JVM のメモリ負荷は、次の要因で決まります。

  • リソース量に比例したクラスター上のデータ量。
  • クラスター上のクエリの負荷。

JVM のメモリ負荷が増加すると、次のようになります。

  • 75%: Amazon ES が Concurrent Mark Sweep (CMS) ガベージコレクターをトリガーします。CMS コレクターは、一時停止や中断を最小限に抑えるために他のプロセスと並行して実行されます。
    注: Amazon ES は、いくつかのガベージコレクションメトリクスを Amazon CloudWatch に公開します。このメトリクスは、JVM のメモリ使用量をモニタリングするのに役立ちます。詳細については、「 Monitoring Amazon Redshift using CloudWatch metrics」をご参照ください。
  • 75% 超: CMS コレクターが十分なメモリを再利用可能にすることができず、使用量が 75% 超のままになると、Amazon ES JVM はメモリを解放しようとします。また、Amazon ES JVM は、プロセスの処理優先度を下げたり、停止することで JVM OutOfMemoryError (OOM) 例外を防ごうとします。
  • JVM が拡大し続ける一方で領域が再利用可能にならない場合、Amazon ES JVM は、メモリを割り当てようとするプロセスを強制終了します。重要なプロセスが強制終了されると、1 つ以上のクラスターノードに障害が発生する場合があります。ベストプラクティスは、CPU 使用率を 80% 未満に保つことです。

JVM のメモリ負荷が高くなることを防ぐには、以下のベストプラクティスに従います。

  • ワイルドカードクエリなど、広範囲のクエリを避けます。
  • 同時に多数のリクエストを送信しないでください。
  • 適切な数のシャードを用意します。インデックス作成戦略の詳細については、「シャード数の選択」をご覧ください。
  • シャードをノード間で均等に分散します。
  • テキストフィールドでの集計を避けます。これにより、フィールドデータの増加を防げます。フィールドデータが多いほど、より多くのヒープスペースが消費されます。フィールドデータを確認するには、GET _cluster/stats API オペレーションを使用します。フィールドデータの詳細については、Elastic ウェブサイトをご覧ください。
  • テキストフィールドで集計する必要がある場合は、マッピングタイプをキーワードに変更してください。JVM のメモリ負荷が高すぎる場合は、API オペレーションである POST /index_name/_cache/clear (インデックスレベルのキャッシュ) および POST */_cache/clear (クラスターレベルのキャッシュ) を使用してフィールドデータキャッシュをクリアします。
    注: キャッシュをクリアすると、進行中のクエリが中断される場合があります。

ハードウェア障害の問題を特定してトラブルシューティングする

Elasticsearch クラスター内のノードの可用性に影響を及ぼす障害が発生することがあります。潜在的なハードウェア障害の影響を制限するには、次の項目を実施します。

  • クラスターに 1 つ以上のノードを設定します。 単一ノードクラスターは、単一障害点です。プライマリシャードとレプリカシャードを同じノードに割り当てることはできないため、レプリカシャードを使用してデータをバックアップすることはできません。ノードが停止した場合は、スナップショットからデータを復元できます。スナップショットの詳細については、「Amazon Elasticsearch Service インデックススナップショットの使用」をご覧ください。最後のスナップショットでキャプチャされなかったデータを復旧することはできません。詳細については、「Amazon ES ドメインのサイジング」と「Creating and managing Amazon ES domains (Amazon ES ドメインの作成と管理) 」をご参照ください。
  • 少なくとも 1 つのレプリカを用意します。 マルチノードクラスターでも、レプリカシャードがない場合には、データの損失が発生することがあります。
  • ゾーン認識を有効にします。 ゾーン認識が有効になっていると、Amazon ES は複数のアベイラビリティーゾーンでデータノードを起動します。Amazon ES は、プライマリシャードとそれに対応するレプリカシャードを複数のゾーンに分散しようとします。1 つのノードまたはアベイラビリティーゾーンで障害が発生した場合にも、データは利用可能です。詳しくは、「マルチ AZ ドメインの設定」をご参照ください。