OpenSearch Service クラスターで CPU 使用率が増加した場合のトラブルシューティング方法を教えてください。

簡単な説明

クラスターの CPU 使用率増加をトラブルシューティングするには、次の手順を実行します。

• 自動化ランブックを実行し、CPU 使用率が増加した原因を特定します。
• 異常検出により、パターンを特定します。
• nodes hot threads API を実行し、リソース使用率を把握します。
• write 操作または bulk API スレッドプールを確認します。
• [検索] スレッドプールを確認してください。
• Apache Lucene の merge スレッドプールを確認します。
• Java 仮想マシン (JVM) のメモリ負荷を確認します。
• シャード戦略を再確認します。
• クラスターをスケーリングします。
• クエリを最適化します。

OpenSearch Service がタスクを実行できるよう、CPU 使用率を低く抑えておくことをおすすめします。クラスターの CPU 使用率が継続的に高い場合、パフォーマンスの問題が発生する可能性があります。OpenSearch Service は、過負荷のクラスターに応答できず、リクエストのタイムアウトが返されます。

解決策

自動化ランブックを実行する

前提条件: ランブックの実行に必須の AWS Identity and Access Management (IAM) 権限が付与されていることを確認します。詳細については、AWSSupport-TroubleshootOpenSearchHighCPU の「必要な IAM 権限」を参照してください。

AWS Systems Manager Automation ランブック AWSSupport-TroubleshootOpenSearchHighCPU を実行し、OpenSearch Service における CPU 使用率の増加をトラブルシューティングします。

出力には次の情報が表示されます。

• ホットスレッド
• 実行中のタスク
• ドメイン内の各ノードにおけるスレッドプールの統計情報。
• ドメイン内のノードに関する、CPU 使用率でソートされた情報。
• 各データノードとそのディスク容量へのシャード割り当て。
• OpenSearch Service ドメインのヘルスステータスおよび正常性に関する情報。

ランブックの出力を参照し、CPU 使用率が増加した原因を特定します。

異常検出によりパターンを特定する

潜在的な問題により、機能停止が引き起こされる前に問題を特定するには、OpenSearch Service で異常検出を使用し、CPU 使用率などのメトリクス内の異常なパターンを自動で検出します。詳細については、「チュートリアル: 異常検出により高い CPU 使用率を検出する」を参照してください。

Nodes hot threads API を実行する

OpenSearch Service クラスターで継続的に CPU 使用率の急増が発生している場合は、次のコマンドを実行し、クラスター内のすべてのノードに関する情報を参照します。

GET/_nodes/hot_threads

出力の長さは、OpenSearch Service クラスターで実行中のノード数に影響を受けます。node hot threads API の詳細については、OpenSearch のウェブサイトで「Nodes hot threads API」を参照してください。

出力例:

GET _nodes/hot_threads
100.0% (131ms out of 500ms) cpu usage by thread 'opensearch[abc][search][T#62]'
10/10 snapshots sharing following 10
elements sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:737)

java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:647)

java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1269)

org.opensearch.common.util.concurrent.SizeBlockingQueue.take(SizeBlockingQueue.java:162)

java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)

cat nodes API でリソース使用率に関する現在の内訳を参照することも可能です。CPU 使用率が最も高いノードを確認するには、次のコマンドを実行します。

GET _cat/nodes?v&s=cpu:desc

ノード名は、出力の最後の列に表示されます。cat nodes API の詳細については、OpenSearch のウェブサイトで「CAT nodes API」を参照してください。

次に、CPU 使用率が高いノードに対し、以下のコマンドを実行します。

GET _nodes/node_id/hot_threads

注: node_id をノード ID に置き換えてください。

出力には、CPU を最も多く使用するノードで実行される OpenSearch サービスプロセスが表示されます。出力に Apache Lucene merge スレッドが表示される場合は、Apache Lucene merge スレッドプールを確認し、トラブルシューティングします。

出力例:

percentage of cpu usage by thread 'opensearch[nodeName][thread-name]'

write 操作または bulk API スレッドプールを確認する

"429" エラーメッセージが表示される場合は、クラスターへの一括インデックスリクエスト数が過剰である可能性があります。クラスターで継続的に CPU 使用率の急増が発生している場合、OpenSearch Service は、一括インデックスリクエストを拒否します。

write スレッドプールは、インデックスリクエストを管理し、Bulk API 操作を内包します。ドメインが過剰な一括インデックスリクエストにより負荷を受けているかどうかを確認するには、Amazon CloudWatch メトリクス IndexingRate を参照します。

クラスターに対する一括インデックスリクエスト数が過剰な場合は、次の手順を実行します。

• クラスターへの一括リクエスト数を削減します。
• 各一括リクエストのサイズを縮小し、ノードの処理効率を改善します。
• Logstash を使用して OpenSearch Service クラスターにデータをアップロードする場合は、バッチサイズまたはワーカー数を減らします。
• クラスターの取り込み速度が遅くなっている場合は、そのクラスターを水平方向または垂直方向にスケーリングします。

search スレッドプールを確認する

search スレッドプールによる CPU 使用率が高い場合は、検索クエリが OpenSearch Service クラスターを圧迫していることを示しています。単一の長時間実行クエリは、クラスターの圧迫を引き起こす可能性があります。クラスターが実行するクエリが増加した場合も、search スレッドプールが影響を受ける可能性があります。

単一のクエリが原因で CPU 使用率が増加しているかどうかを確認するには、次のコマンドを実行します。

GET _tasks?actions=*search&detailed

task management API は、クラスターで実行中のすべてのアクティブな検索クエリを表示します。詳細については、OpenSearch のウェブサイトで「List tasks API」を参照してください。

出力の description フィールドを参照し、実行中のクエリを特定します。running_time_in_nanos フィールドにクエリの実行期間が表示されます。

出力例:

{    "nodes": {
        "U4M_p_x2Rg6YqLujeInPOw": {
            "name": "U4M_p_x",
            "roles": [
                "data",
                "ingest"
            ],
            "tasks": {
                "U4M_p_x2Rg6YqLujeInPOw:53506997": {
                    "node": "U4M_p_x2Rg6YqLujeInPOw",
                    "id": 53506997,
                    "type": "transport",
                    "action": "indices:data/read/search",
                    "description": """indices[*], types[], search_type[QUERY_THEN_FETCH], source[{"size":10000,"query":{"match_all":{"boost":1.0}}}]""",
                    "start_time_in_millis": 1541423217801,
                    "running_time_in_nanos": 1549433628,
                    "cancellable": true,
                    "headers": {}
                }
            }
        }
    }
}

注: 検索タスクでは、task management API の出力には、description フィールドのみが含まれます。

CPU 使用率を削減するには、次のコマンドを実行し、CPU 使用率が高い検索クエリをキャンセルします。

POST _tasks/U4M_p_x2Rg6YqLujeInPOw:53506997/_cancel

注: U4M_p_x2Rg6YqLujeInPOw:53506997 を目的のタスク ID に置き換えてください。

上記のクエリは、タスクを cancelled とマークし、依存する AWS リソースを解放します。クラスターで複数のクエリが実行中の場合は、POST コマンドを実行し、クラスターが正常状態に戻るまで各クエリをキャンセルします。

CPU 使用率の急増を防ぐには、クエリ本文にタイムアウト値を設定することをおすすめします。詳細については、OpenSearch のウェブサイトで「検索設定」を参照してください。アクティブなクエリの数が減ったかどうかを確認するには、CloudWatch メトリクス SearchRate を参照します。

注: OpenSearch Service クラスター内のアクティブな検索クエリをすべて同時にキャンセルすると、クライアントアプリケーション側でエラーが発生する可能性があります。

Apache Lucene の merge スレッドプールを確認する

OpenSearch Service は Apache Lucene を使用してクラスター上のドキュメントをインデックス化し、検索します。新しいシャードセグメントを作成する際、Apache Lucene は merge 操作を実行して各シャードの有効なセグメント数を減らし、削除されたドキュメントを除外します。詳細については、Elastic のウェブサイトで「Merge 設定」を参照してください。

Apache Lucene merge スレッドが CPU 使用率に影響している場合は、次のコマンドを実行し、インデックスの refresh_interval 設定値を増やします。

PUT /your-index-name/_settings
{
  "index": {
    "refresh_interval": "value"
  }
}

注: value を更新後のリクエスト間隔に置き換えてください。この更新では、クラスターセグメントの作成が低速化します。詳細については、OpenSearch のウェブサイトで「Refresh index API」を参照してください。

クラスターがインデックスを UltraWarm ストレージに移行する際、CPU 使用率が増加する可能性があります。UltraWarm の移行では通常、force merge API 操作が実行されるため、CPU に負荷がかかる可能性があります。詳細については、OpenSearch のウェブサイトで「Force merge API」を参照してください。

UltraWarm の移行が発生しているかどうかを確認するには、次のコマンドを実行します。

GET _ultrawarm/migration/_status?v

JVM のメモリ負荷を確認する

クラスターノードの Java ヒープで JVM memory pressure のパーセンテージを確認します。次のログ例において、JVM は推奨範囲に収まっていますが、長時間実行されるガベージコレクションがクラスターに影響しています。

[2022-06-28T10:08:12,066][WARN ][o.o.m.j.JvmGcMonitorService] [515f8f06f23327e6df3aad7b2863bb1f] [gc][6447732] overhead, spent [9.3s]collecting in the last [10.2s]

JVM のメモリ負荷に関する問題を解決する方法については、「OpenSearch Service クラスターで JVM のメモリ負荷が高い場合のトラブルシューティング方法を教えてください」を参照してください。

シャード戦略をレビューする

クラスターのサイズによっては、過剰なシャード数が原因でクラスターのパフォーマンスが低下する可能性があります。Java ヒープ 1 GiB ごとに、シャード数を 25 以内にすることをおすすめします。

デフォルトでは、OpenSearch Service のシャード戦略は 5:1 であり、各インデックスには 5 個のプライマリシャードが配置されます。インデックスごとに、各プライマリシャードには自身のレプリカが存在します。OpenSearch Service は、プライマリシャードとレプリカシャードを別々のデータノードに自動的に割り当て、障害が発生した場合に備えてバックアップを確保します。

この問題を解決するには、「OpenSearch Service クラスター内のシャード分散が均衡していない場合の、再調整方法を教えてください」を参照してください。

クラスターをスケーリングする

クラスターの CPU、メモリ、ディスク容量が要件を満たしていることを確認します。アプリケーションが大規模クエリや頻繁な書き込みを行う場合は、クラスターまたはノードをリサイズし、パフォーマンス需要を満たせるようにします。

さらに、専用マスターノードを使用すると、特に大規模デプロイにおいて、クラスターの安定性と耐障害性を改善できます。この構成では、データノードがクラスターを管理する必要がなくなります。

クエリを最適化する

大規模な集計、ワイルドカードクエリ (例: 先頭のワイルドカード)、正規表現 (regex) クエリは、CPU 使用率の急増を引き起こす可能性があります。これらのクエリを診断するには、OpenSearch のスローログを参照します。

関連情報

OpenSearch Service クラスターによるインデックス作成のパフォーマンスを改善する方法を教えてください

OpenSearch Service で検索や書き込みが拒否される場合の解決方法を教えてください

OpenSearch Service ドメインのサイズ設定