シャードが多すぎることによるクラスターのヘルスに関する問題を認識して解決する方法を教えてください。

簡単な説明

各シャードは、維持するためにある程度の量の CPU/JVM リソースを消費します。シャードが多すぎると、クラスターのパフォーマンスが大幅に低下する可能性があります。シャードが多すぎると、クラスター全体が応答しなくなることもあります。

クラスターが正常で、想定どおりに動作することを確認するには、OpenSearch Service のベストプラクティスに従います。

シャードが多すぎる場合の症状

クラスターにおいて次の症状の 1 つ以上が発生している場合は、解決策の手順を実行します。シャードの数が多すぎることによってドメインに影響が生じるかどうかを確認するには、クラスターのヘルスメトリクスの経時的な傾向を確認します。

• ノードあたり 1,000 個を超えるシャード。
• それぞれが 10 GB 未満の小さいサイズのシャードを持つインデックス。
• 断続的なノードドロップ。
• 高い JVM/CPU リソースメトリクス。
• ブルー/グリーンデプロイの複雑化。
• クラスター状態は、選出されたマスターによる処理が極めて困難。
• T インスタンスタイプが使用中。または、より小さなインスタンスタイプが使用中。例えば、インスタンスタイプ c5.large が使用中です。

解決策

ドメインの傾向を確認する

お使いのドメインの Amazon CloudWatch メトリクスを確認するには、3/6/12/14 か月の範囲を使用します。シャードの作成が一定間隔で行われる場合は、グラフの時間枠を増やします。そうしない場合、ヘルスの傾向の全履歴を表示できません。注: より長い時間範囲でメトリクスを正しく読み込むには、メトリクスの期間を 1 時間に変更する必要があります。

シャードが多すぎるドメインで起こることは次のとおりです。

• Shards.active の数が増加します。ノードあたりの合計シャード数が 1,000 個を超えた後、クラスターのトラフィックが増加すると、クラスターのヘルスがリスクにさらされます。このリスクは、シャード数の増加に伴い、それらにわたる検索リクエストのトラフィックが発生した場合に増大します。
• ノードドロップは、クラスターのノードメトリクスが、最小/最大/平均の統計情報において実線ではない場合に発生します。JVM のメモリ制限に到達すると、OpenSearch Service プロセスがノード上で実行されなくなります。その後、マネージドサービスが自動的にプロセスを再開します。
• JVMMemoryPressure が増大します。G1 ガベージコレクション (G1GC) の頻度が高くなり、効果が低下するにつれて、最小/平均/最大値は収束します。理想的な状態では、このメトリクスは 0～75％ の間で、鋸歯状のパターンで変動します。JVMMemoryPressure が悪化したときに 75% を突破し、平均 JVMMemoryPressure が 75% を突破した場合に、初期影響が発生します。OpenSearch Service の JVM とガベージコレクションの詳細については、「JVM のメモリ高負荷がもたらす影響を把握する」を参照してください。詳細については、「OpenSearch Service クラスターの JVM メモリ負荷が高い場合のトラブルシューティング方法について教えてください。」を参照してください。
• CPUUtilization が増加します。クラスターは、維持するシャードのガベージコレクションについて、より多くのリソースと時間を費やします。

シャードが多すぎる問題をトラブルシューティングする

シャードが多すぎる問題のトラブルシューティングを行うには、次のいずれかの解決方法を選択します。

シャード数を減らす

OpenSearch のベストプラクティスは、利用可能な JVM ヒープメモリに基づいてノードあたりのシャード数を制限することです。JVM ヒープの GiB あたりのシャードが 20～25 個以下であることを確認します。OpenSearch マネージドサービスでは、JVM ヒープに 32 GiB までというサイズ制限があります。この制限により、ノードあたり最大 640〜800 個のシャードを持てることになります。クラスター設定によって変更できるシャードの数は、ノードあたり 1,000 個に制限されています。

データが不要な場合は、古いインデックスを削除します。古いインデックスデータを削除する前に、手動でスナップショットを取っておきます。

ISM でローテーションインデックスを使用する場合は、次の点に注意してください。

• お使いのシャード戦略で、インデックスがベストプラクティスのシャードサイズの範囲 (10～50 GB) に収まっていることを確認します。例えば、ISM の日次インデックスを使用し、デフォルトの 5:1 シャーディングを使用するとします。この方法では、1 日あたりのシャードが 10 個になり、1 か月あたりのシャードは最大で 300 個になります。
• インデックステンプレートを使用して、より小さい日次インデックスのシャード数を減らすことができます。詳細については、OpenSearch のウェブサイトで「Index templates」を参照してください。これはクラスター内で新しく作成されたインデックスにのみ影響し、クラスターの状態を直ちに改善するものではありません。
• 再インデックス OpenSearch API を使用して、古い日次インデックスと週次インデックスを組み合わせて月次インデックスにします。詳細については、OpenSearch のウェブサイトで「Combine one or more indexes」(1 つ以上のインデックスの結合) を参照してください。その後に、ISM インデックスのローテーション期間を変更して、小さすぎるインデックスが作成されるのを防ぎます。

インスタンスのスケーリング

次の点に注意してください。

• これは、スケールアップまたはスケールアウトするための実用的な長期ソリューションではありません。必ず OpenSearch Service のベストプラクティスに従ってください。
• インスタンスタイプをスケールアップすると、ノードごとに使用可能なリソースと、ノードが処理できるシャードの総数が増えます。
• データノード数をスケールアウトすると、ノードあたりのシャードの数が減ります。この減少により、他のノードへの影響が軽減されます。

関連情報

Optimize OpenSearch index shard sizes (インデックスのシャードサイズを最適化する)(OpenSearch ウェブサイト)