--- title: "OpenSearch Performance Analyzerとは？有効化・メトリクス取得・性能分析の手順を解説" url: "https://www.issoh.co.jp/tech/details/9506/" published: 2025-10-27 updated: 2026-09-27 categories: ["監視・オブザーバビリティ"] publisher: "株式会社一創" --- # OpenSearch Performance Analyzerとは？有効化・メトリクス取得・性能分析の手順を解説 OpenSearch Performance Analyzerは、クラスタのCPU・JVMヒープ・スレッドプール・ディスクIOといった性能メトリクスを、OpenSearch本体（JVM）の負荷とは独立したエージェントから取得するプラグインです。OpenSearch 2.0以降のtarball版・Docker版に標準同梱され、REST APIをポート9600で公開します。ただしOpenSearch 3.0では根本原因分析を担う`performance-analyzer-rca`エージェントが削除され、監視・分析の推奨はTelemetryプラグイン（OpenTelemetry）へ移りました。この記事では、Performance Analyzerの有効化からメトリクスの取得・可視化、性能ボトルネックの切り分け、3.0以降の移行方針までを一次情報に基づいて整理します。バージョンは最新の3.7.0（2026年6月）を基準にしています。 ## まとめ：Performance Analyzerの要点 - Performance Analyzerはエージェント＋REST APIの2層構成。メトリクス取得APIは**ポート9600**、有効化の操作はOpenSearch本体の**ポート9200**で行う。 - OpenSearch **2.0以降はデフォルト同梱**。使わない場合は明示的に無効化・アンインストールしてメモリを節約する。 - OpenSearch **3.0で`performance-analyzer-rca`エージェントが削除**され、公式はTelemetryプラグイン（OpenTelemetry）への移行を推奨。メトリクス取得API自体は引き続き利用できる。 - 取得できる指標は`CPU_Utilization`・`Heap_Used`・`ThreadPool_QueueSize`・`Cache_Request_Hit`・`IO_TotThroughput`など。`agg`（集約）と`dim`（ディメンション）で粒度を指定する。 - マネージドのAmazon OpenSearch Serviceは監視をCloudWatchに寄せる設計で、ポート9600を自分で叩くのはセルフマネージド構成が対象。 ## Performance Analyzerの役割とアーキテクチャ Performance Analyzerが他の監視手段と異なるのは、メトリクス収集をOpenSearchのJVMから切り離している点です。負荷が高くJVMが応答しづらい状況でも、エージェントが独立してメトリクスを書き出し続けるため、障害時こそ値が取れます。可視化ツールやアラート基盤は、このエージェントが公開するREST APIを叩いて指標を読みます。 ### エージェントとREST APIの2層構成（ポート9600・/dev/shm） 収集エージェントはクラスタの各ノードで動作し、メトリクスを共有メモリ領域`/dev/shm/performanceanalyzer/`に一時保存します。読み出しはポート9600のRESTエンドポイントで行い、認証はかかりません（後述のとおりクライアント・サーバー認証は未対応）。保存先が共有メモリのため、重い負荷では共有メモリを最大1GB程度確保します。 ### デフォルト同梱の状況とバージョン別の変化 Performance Analyzerプラグインは、OpenSearch 2.0以降のtarball／Dockerディストリビューションに含まれています。同梱されない構成で手動導入する場合は、MavenからプラグインのZIPを取得し、`bin/opensearch-plugin install`（標準のプラグインインストール手順）で各ノードに入れます。バージョン間の最大の分岐点は3.0で、根本原因分析エージェント`performance-analyzer-rca`が削除されました。RCAに依存した運用をしていた場合は、Telemetryプラグインへの置き換えが前提になります（詳細は後述）。OpenSearchの全体的な世代差やアップグレードの背景は[OpenSearch 3.0の全体像を理解するための概要と背景](/tech/details/6592/)で補足しています。 ## Performance Analyzerの有効化・設定・無効化 同梱されていても、メトリクス収集の有効／無効はクラスタ設定で切り替えます。有効化・無効化のPOSTはOpenSearch本体のポート9200に対して行い、メトリクスの読み出しだけが9600である点を混同しないでください。 ### クラスタ全体の有効化コマンド（ポート9200） 次のリクエストでクラスタ全体のPerformance Analyzerを有効化します。 ``` curl -XPOST localhost:9200/_plugins/_performanceanalyzer/cluster/config \ -H 'Content-Type: application/json' -d '{"enabled": true}' ``` ### 設定ファイルとTLS・バインドホスト 詳細設定は`config/opensearch-performance-analyzer/performance-analyzer.properties`で行います。外部の監視サーバーから9600へ接続するには、`webservice-bind-host`のコメントを外して`0.0.0.0`を指定します。通信の暗号化（TLS）は`https-enabled = true`とサーバー証明書のパス指定で有効になりますが、証明書はルート認証局ではなくサーバー用を指定します。認証（クライアント／サーバー）は未対応のため、9600はファイアウォールやセキュリティグループで監視ホストのみに限定するのが安全です。 ### Docker・コンテナ運用での注意（/dev/shmの64MB問題） Dockerの`/dev/shm`は既定で64MBしかなく、Performance Analyzerが必要とする最大1GBに届きません。ここが不足するとメトリクスが空になる典型的な原因になります。起動時にサイズを引き上げてください。 ``` docker run --shm-size 1gb ... ``` 非Docker環境では`df -h`で`/dev/shm`の容量を確認し、不足する場合は`/etc/fstab`に`tmpfs`のsizeを追記して再マウントします。 ### 無効化とアンインストール ローカル検証などでメモリを節約したい場合は、収集を止めてからプラグインを削除します。 ``` curl -XPOST localhost:9200/_plugins/_performanceanalyzer/cluster/config \ -H 'Content-Type: application/json' -d '{"enabled": false}' bin/opensearch-plugin remove opensearch-performance-analyzer ``` ## メトリクスの取得とクエリ（ポート9600 API） メトリクスはポート9600の`/_plugins/_performanceanalyzer/metrics`から取得します。`metrics`（指標）・`agg`（集約）・`dim`（ディメンション）・`nodes`を組み合わせて、必要な粒度だけを取り出せます。 ``` GET localhost:9600/_plugins/_performanceanalyzer/metrics?metrics=Latency,CPU_Utilization&agg=avg,max&dim=ShardID&nodes=all ``` この例は、シャード単位（`dim=ShardID`）のレイテンシとCPU使用率を、平均と最大（`agg=avg,max`）で全ノードから取得します。利用できる集約の単位は`/_plugins/_performanceanalyzer/metrics/units`で確認できます。 ### 主要メトリクスとディメンション 実際に指定できる指標名は多岐にわたります。ボトルネック診断でよく使うものを挙げます。 | 分類 | メトリクス名 | 見るポイント | | ---------- | ---------------------------------------------------------------------------- | ----------------- | | CPU | CPU\_Utilization | ノード／オペレーション別の負荷偏り | | JVMヒープ | Heap\_Used / Heap\_Max | 使用率とGC頻度の相関 | | スレッドプール | ThreadPool\_QueueSize / ThreadPool\_QueueLatency / ThreadPool\_ActiveThreads | 検索・書き込みの滞留と拒否 | | キャッシュ | Cache\_Request\_Hit / Cache\_Request\_Miss / Cache\_FieldData\_Eviction | ヒット率と追い出しの発生 | | サーキットブレーカー | CB\_TrippedEvents / CB\_EstimatedSize | メモリ保護の発動回数 | | ディスクIO | IO\_TotThroughput / IO\_ReadThroughput / IO\_WriteThroughput | マージやフラッシュ時の飽和 | | 基本 | Latency / Disk\_Utilization / Net\_Throughput / ShardEvents | 全体傾向の把握 | ディメンションは`ShardID`のほか`Operation`や`IndexName`などを指定でき、「どのシャード・どの操作が重いか」まで踏み込めます。単なる平均値では埋もれる偏りを、`agg=max`とディメンション分割で表面化させるのがPerformance Analyzerの使いどころです。 ## メトリクスの可視化（PerfTop・Dashboards） 9600のAPIをそのまま叩く以外に、CLIダッシュボードのPerfTopで手軽に表示できます。PerfTopはJSONで行列グリッドを定義し、テーブル・折れ線・棒グラフを配置する仕組みで、既存のJSONを複製して改変するのが早道です。テーブルはディメンション別（例：`CPU_Utilization`×`ShardID`でシャードごとに1行）、棒グラフはクラスタ集約で表示されます。継続的な監視や長期保存が必要なら、9600のメトリクスをPrometheusやGrafanaなど外部の観測基盤へ取り込む構成が現実的です。 ## 性能ボトルネックの切り分け（メトリクス相関の型） Performance Analyzerは値を出すだけで、原因は運用者が読み解きます。指標を単独で眺めず、症状と結びつけて相関を追うのが実務の要点です。以下は切り分けの型です。 ### レイテンシ悪化とスレッドプールの滞留 検索が遅いときは`Latency`だけでなく`ThreadPool_QueueSize`と`ThreadPool_QueueLatency`を同時に見ます。キューが積み上がっているなら、遅いのは個々のクエリではなく処理能力の頭打ちです。`ThreadPool_ActiveThreads`が上限に張り付いていれば、ノード追加かクエリの軽量化が先で、単純なヒープ増設では改善しません。拒否（reject）が出ているキューを特定して、そこに負荷を集めている操作を`dim=Operation`で洗い出します。 ### JVMヒープとGC `Heap_Used`が`Heap_Max`に近い水準で高止まりし、GCが頻発している場合は、集約（aggregation）やフィールドデータの多用がヒープを食っている可能性が高いです。ヒープを増やす前に、重い集約クエリや大きな`size`のスクロールを`dim`で特定します。ヒープは物理メモリの半分・32GB未満が実務上の目安で、それ以上はGC停止時間が延びて逆効果になりがちです。 ### キャッシュとサーキットブレーカー `Cache_Request_Hit`に対して`Cache_Request_Miss`が多く、`Cache_FieldData_Eviction`が頻発しているなら、キャッシュが小さいか、キャッシュに乗らないクエリ（毎回異なる時刻範囲など）が主因です。`CB_TrippedEvents`が増えているのはメモリ保護が働いている証拠で、単発のリクエストが大きすぎるサインです。ここを無視してヒープだけ増やすと、より大きなリクエストで再発します。 ### ディスク・ネットワークIO 書き込みが詰まるときは`IO_WriteThroughput`と`Disk_Utilization`を見ます。インデックスのマージやフラッシュでディスクが飽和しているなら、リフレッシュ間隔の見直しやSSD化が効きます。シャード配置の偏りは`dim=ShardID`のCPU・IOで可視化でき、ホットシャードが1ノードに集中しているならリバランスやシャード数の再設計が必要です。 ## RCA削除とTelemetryプラグインへの移行（3.0以降） OpenSearch 3.0の破壊的変更として、`performance-analyzer-rca`エージェントが削除されました。これはPerformance Analyzerのメトリクスをもとに、性能・信頼性の問題の根本原因を推定していたフレームワークです。公式は代替としてTelemetryプラグインを推奨しています。TelemetryはOpenTelemetryフレームワークを使い、軽量な既存のオープンソースエージェントと連携して、性能メトリクスを観測ストアへ送り出す設計です。 実務上の判断はこうです。9600のメトリクス取得API自体は3.x以降も残るので、生メトリクスを外部基盤へ流す使い方なら移行の緊急度は低い。一方、RCAの自動診断（例：シャードのホットスポット検知）に運用を依存していたなら、その機能はもう存在しないため、OpenTelemetryベースの監視パイプラインへ組み替える必要があります。新規に監視を設計するなら、RCAを前提にせず、最初からTelemetry／OpenTelemetry側で組むのが素直です。 ## Amazon OpenSearch Service（マネージド）での違い ここまではセルフマネージド（EC2・コンテナ・オンプレ）でOpenSearchを自分で運用する前提です。マネージドのAmazon OpenSearch Serviceでは、クラスタ指標はCloudWatchへ自動発行され、監視はCloudWatch側で完結する設計になっています。ポート9600のエージェントAPIを自分で叩く運用は基本的に想定されていません。マネージドを使う場合の監視・料金・構築の全体像は[Amazon OpenSearch Serviceとは？料金体系・構築手順・運用のポイント](/tech/details/3610/)にまとめています。 ## メトリクス取得失敗時のトラブルシュート - **9600が空・値が出ない**：多くはDockerの`/dev/shm`が64MBのままで容量不足。`--shm-size 1gb`で起動し直す。 - **収集が無効**：9200の`cluster/config`で`enabled: true`になっているか確認する。有効化は9200、読み出しは9600と宛先が異なる。 - **外部から9600に届かない**：`webservice-bind-host`が`0.0.0.0`になっているか、ファイアウォール／セキュリティグループが監視ホストを許可しているかを確認する。 - **RCAのエンドポイントが404**：OpenSearch 3.0でRCAエージェントは削除済み。Telemetry／OpenTelemetryへ切り替える。 ## よくある質問 ### Performance Analyzerはデフォルトで有効ですか？ プラグインはOpenSearch 2.0以降のtarball／Docker版に同梱されますが、メトリクス収集の有効化は9200の`_plugins/_performanceanalyzer/cluster/config`への`enabled: true`で明示的に行います。同梱＝収集が動いている、ではありません。 ### メトリクス取得はポート9600ですか、9200ですか？ メトリクスの読み出しはポート9600、有効化・無効化のPOSTはOpenSearch本体のポート9200です。宛先が分かれているため、9600でPOSTしても設定は変わりません。 ### RCA（根本原因分析）はまだ使えますか？ `performance-analyzer-rca`エージェントはOpenSearch 3.0で削除されました。公式はTelemetryプラグイン（OpenTelemetry）への移行を推奨しています。生メトリクスを取得するAPIは引き続き使えます。 ### Amazon OpenSearch Serviceでも使えますか？ マネージドのAmazon OpenSearch Serviceは監視をCloudWatchに寄せる設計で、9600のエージェントAPIを自分で操作する運用は想定されていません。Performance Analyzerを直接使うのはセルフマネージド構成が対象です。 ### TelemetryプラグインとPerformance Analyzerは何が違いますか？ Performance Analyzerは独自エージェントと9600のRESTでメトリクスを公開する仕組み、TelemetryはOpenTelemetry標準で外部の観測基盤へメトリクスを送る仕組みです。3.0でRCAが消えて以降、根本原因分析まで含む監視はTelemetry側で組むのが公式の方向です。 ## 関連記事 - [Amazon OpenSearch Serviceとは？料金体系・構築手順・運用のポイントまで徹底解説](/tech/details/3610/) - [OpenSearch 3.0の全体像を理解するための概要と背景](/tech/details/6592/) - [ハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コード](/tech/details/8014/) - [Amazon S3 Vectors APIとは？操作一覧・料金・OpenSearch比較とRAG構築を解説](/tech/details/7773/) --- 出典: [OpenSearch Performance Analyzerとは？有効化・メトリクス取得・性能分析の手順を解説]()（株式会社一創）