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

所要時間2分

Amazon OpenSearch Service クラスターのノードの 1 つがダウンしているので、これを防ぎたいと思っています。

簡単な説明

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

クラスターノード障害の一般的な原因は次のようなものがあります。

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

解決方法

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

1. OpenSearch Service コンソールにサインインします。

2. ナビゲーションペインの [マネージドクラスター] で、[ドメイン] を選択します。

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

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

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

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

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

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

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

JVM のメモリ負荷が高まると、次のことが起こります。

75％で: OpenSearch Service が Concurrent Mark Sweep (CMS) ガベージコレクターを開始します。CMS コレクターは、一時停止や中断を最小限に抑えるために他のプロセスと一緒に実行されます。
注: OpenSearch Service は、いくつかのガベージコレクションメトリクスを Amazon CloudWatch に発行します。これらのメトリクスは、JVM のメモリ使用量のモニタリングに役立ちます。詳細については、Amazon CloudWatch を用いた OpenSearch クラスターメトリクスのモニタリングを参照してください。
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」の項をご参照ください。
テキストフィールドで集計する必要がある場合は、マッピングタイプを [キーワード] に変更してください。JVM のメモリ負荷が高すぎる場合は、次の API 操作を使用してフィールドデータキャッシュを消去します。POST/index_name/_cache/clear (インデックスレベルのキャッシュ) および POST/_cache/clear (クラスターレベルのキャッシュ)。
注: キャッシュをクリアすると、進行中のクエリが中断される場合があります。

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

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

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