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

最終更新日: 2021 年 7 月 30 日

Amazon OpenSearch Service (Amazon Elasticsearch Service の後継サービス) クラスター内のノードの 1 つがダウンしています。なぜノードに障害が発生したのでしょうか? また再発を防止するにはどうすればよいですか?

簡単な説明

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

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

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

解決方法

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

1.    OpenSearch Service コンソールを開きます。

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

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

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

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

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

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

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

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

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

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

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

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

ハードウェア障害がクラスターノードの可用性に影響を与える場合があります。潜在的なハードウェア障害の影響を制限するには、次の項目を実施します。

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