Elasticsearch:クラスターの負荷の不均衡

ディスク使用量はノード間で類似していますが、NodeCPUUtilization または NodeLoad_1m メトリックの値は、負荷の不均衡を示しています。

ディスク使用量はノード間で大きく異なり、NodeCPUUtilization または NodeLoad_1m メトリックの値は、負荷の不均衡を示しています。

シャードの割り当てが不適切です。

セグメントサイズが不均一です。

ホットデータとコールドデータがノード上で分離されていません。

SLB インスタンスとマルチゾーンアーキテクチャに永続的な接続が使用されています。この場合、トラフィックがノードに不均一に分散される可能性があります。ただし、これはめったに発生しません。詳細については、マルチゾーンアーキテクチャをご参照ください。

シナリオ

分析

1. ネットワークと Elastic Compute Service（ECS）インスタンスを確認します。ECS インスタンスが正常な場合は、ネットワーク監視データを表示します。

   ネットワーク監視データは、ネットワークリクエストの数とクエリ QPS がピーク時に増加することを示しています。さらに、関連ノードの CPU 使用率が大幅に増加します。上記の情報を基に、負荷の高いノードは主にクエリリクエストの処理に使用されていると結論付けることができます。

2. GET _cat/shards?v コマンドを実行して、インデックスのシャードをクエリします。 // シャードの情報を取得するために使用します

   コマンド出力は、シャードがノードに均等に割り当てられていないことを示しています。text インデックスのシャードは、主に負荷の高いノードに割り当てられています。さらに、ディスク使用量の監視データは、負荷の高いノードのディスク使用量が他のノードよりも大きいことを示しています。シャードの不均一な割り当てが不均一なストレージにつながると結論付けることができます。データをクエリまたは書き込む場合、ストレージ容量の大きいノードが主要なクエリおよび書き込みワークロードを処理します。

3. GET _cat/indices?v コマンドを実行して、インデックスの情報をクエリします。 // インデックスの情報を取得するために使用します

   コマンド出力は、インデックスに 5 つのプライマリシャードと各プライマリシャードに 1 つのレプリカシャードがあることを示しています。さらに、クラスター構成は、シャードが均等に割り当てられておらず、特定のドキュメントが削除されていることを示しています。Elasticsearch がデータを検索する場合、.del でマークされたドキュメントも検索およびフィルタリングします。これは追加のリソースを消費し、検索効率を大幅に低下させます。オフピーク時に force merge 操作を呼び出すことをお勧めします。

   

4. クラスターログと低速検索ログを表示します。

   ログは、クエリがすべて通常の term クエリであり、クラスターログはエラーが発生していないことを示しています。したがって、Elasticsearch クラスターは、エラーや CPU リソースを消費するクエリステートメントに遭遇していません。

まとめ

解決策

インデックスを作成する前に、シャードを適切に計画します。詳細については、シャード評価ガイドラインをご参照ください。

低スペックのノードの場合、各シャードのサイズは 30 GB 以下です。高スペックのノードの場合、各シャードのサイズは 50 GB 以下です。

ログ分析シナリオまたは非常に大きなインデックスの場合、各シャードのサイズは 100 GB 以下です。

プライマリシャードとレプリカシャードの合計数は、データノードの数と同じか、その倍数です。

単一ノードのシャード数は、メモリサイズ×30に基づいて決定することをお勧めします。多数のシャードが計画されている場合、ファイルハンドルの枯渇が発生しやすく、クラスター障害につながる可能性があります。

ノードのインデックスには最大 5 つのプライマリシャードを構成することをお勧めします。

クラスターで自動インデックス作成機能を有効にしている場合は、シナリオベースの構成機能を使用してシャード構成を変更できます。シャードが均等に割り当てられていることを確認してください。詳細については、シナリオベースのテンプレートを使用してクラスターの構成を変更するをご参照ください。

シナリオ

分析

1. クエリ本文に "profile": true を追加します。 // クエリのパフォーマンス分析を有効にするために使用します

   クエリ結果は、Elasticsearch が test インデックスのシャード 1 のクエリに他のシャードよりも長い時間がかかることを示しています。

2. preference を _primary に設定し、"profile": true をクエリ本文に追加したクエリリクエストを送信し、プライマリシャードのクエリに必要な時間を表示します。次に、preference を _replica に設定し、"profile": true をクエリ本文に追加した別のクエリリクエストを送信し、レプリカシャードのクエリに必要な時間を表示します。 // 特定のシャードをクエリするために使用します

   シャード 1（プライマリシャード）のクエリに必要な時間は、そのレプリカシャードのクエリに必要な時間よりも長くなります。これは、負荷の不均衡がシャード 1 によって引き起こされていることを示しています。

3. GET _cat/segments/index?v&h=shard,segment,size,size.momery,ip コマンドと GET _cat/shards?v コマンドを実行して、シャード 1 の情報をクエリします。 // セグメントとシャードの情報を取得するために使用します

   コマンド出力は、シャード 1 に大きなセグメントが含まれており、シャード内のドキュメント数がそのレプリカシャードのドキュメント数よりも多いことを示しています。上記の情報を基に、負荷の不均衡はセグメントサイズの不均一が原因であると判断できます。

   説明

   ドキュメント数の不一致は、さまざまな理由で発生する可能性があります。例：

   • プライマリシャードとレプリカシャード間のデータ同期に遅延が存在します。ドキュメントがプライマリシャードに継続的に書き込まれている場合、データの不整合が発生する可能性があります。ただし、ドキュメントの書き込みを停止すると、プライマリシャードとレプリカシャードの間でドキュメント数が同じになります。

   • データがプライマリシャードに書き込まれた後、システムはデータ書き込みリクエストをそのレプリカシャードに転送します。自動的に生成されたドキュメント ID を使用してプライマリシャードにドキュメントを書き込む場合、書き込み操作中にプライマリシャードで削除操作を実行することはできません。削除操作（たとえば、書き込んだばかりのドキュメントを削除するために Delete by Query リクエストを送信する）を実行すると、操作はレプリカシャードでも実行されます。次に、システムは書き込みリクエストをレプリカシャードに転送します。ドキュメント ID はシステムによって自動的に生成されるため、ドキュメントは検証なしでレプリカシャードに書き込まれます。その結果、レプリカシャードのドキュメント数がプライマリシャードのドキュメント数と異なります。さらに、プライマリシャードには docs.deleted でマークされた多数のドキュメントが含まれています。 // 削除されたドキュメントを示すために使用します

解決策

• 解決策 1：オフピーク時に、force merge 操作を呼び出して、小さなセグメントをマージし、docs.deleted でマークされたドキュメントを削除します。

• 解決策 2：プライマリシャードが存在するノードを再起動して、レプリカシャードをプライマリシャードに昇格させます。新しいプライマリシャードを使用して新しいレプリカシャードを生成します。これにより、新しいプライマリシャードとレプリカシャードのセグメントが同じになります。

シナリオ

分析

1. 過去 4 日間の 2 つのゾーンのノードの CPU 使用率を表示します。

   監視データは、ノードの CPU 使用率が大幅に変化したことを示しています。

2. ノードへの TCP 接続を表示します。

   監視データは、2 つのゾーンの TCP 接続数が大きく異なることを示しています。これは、負荷の不均衡がネットワーク接続が原因であることを示しています。

3. クライアント接続を確認します。

   クライアントは永続的な接続を使用し、少数の新しい接続を確立します。このシナリオは、マルチゾーンネットワークの独立したスケジューリングのリスクがあります。ネットワークサービスは、接続数に基づいて独立してスケジュールされます。各スケジューリングユニットは、接続を作成するための最適なノードを選択します。独立したスケジューリングは、より高いパフォーマンスを提供します。ただし、新しい接続の数が少ない場合、複数のスケジューリングユニットが同じノードを選択して接続を確立する可能性があります。Elasticsearch クラスターのクライアントノードは、最初に同じゾーンにある別のノードにリクエストを転送します。これにより、ゾーン間の負荷の不均衡が発生します。

解決策

• 解決策 1：独立したクライアントノードを使用して複雑なトラフィックを転送します。この場合、クライアントノードの負荷が高くても、データノードは影響を受けません。これにより、負荷の不均衡のリスクが軽減されます。

• 解決策 2：クライアントに 2 つの独立したドメイン名を設定して、クライアントのトラフィックのバランスを確保します。この解決策では、高可用性を確保できません。Elasticsearch クラスターの構成をアップグレードする場合、ノードが SLB インスタンスから削除されないため、アクセス障害が発生する可能性があります。