Apache JMeter による Kibana への負荷試験を行うためのポイント

BLOG

はじめに

大規模なログ分析基盤や可視化プラットフォームの運用において、「ダッシュボードへのアクセスが集中した際、十分なパフォーマンスを維持できるか」という課題は非常に重要です。

Elasticsearch 単体への負荷テストであれば ESRally1 などの専用ツールが適していますが、実際のユーザーがWebブラウザを介して体験する「Kibanaダッシュボードの表示・検索処理」のパフォーマンスをこれだけで測定することは困難です。

Kibana は Node.js 上で動作するWebアプリケーションです。複数ユーザーによる同時アクセスやダッシュボード表示の集中に伴うボトルネックを特定するためには、Apache JMeter などのツールを用いて、HTTP(S)経由で実際の利用状況を模倣した負荷試験を行うことが不可欠となります。

しかし、Kibana に対して JMeter で作成したシナリオをそのまま実行しようとすると、Kibana 特有のセキュリティ仕様やキャッシュメカニズムによってテストが正常に動作しないケースが多発します。

本記事では、Kibana の負荷試験でハマりがちなポイントを回避し、正確で効果的なテストを実施するための5つの実践ノウハウを解説します。

注意事項

Apache JMeter は使い方によっては外部システムに過度な負荷を与える可能性があるため、本記事では JMeter の基本操作の説明は割愛し、Kibana 特有のポイント・ハマりどころの解説に絞って記述しています。

対象者

  • Apache JMeter の基本的な使用方法を理解している技術者
  • Kibana の基本的な操作方法を理解している技術者

検証環境

  • Apache JMeter v5.6.3
  • Kibana v9.5.5

ポイント1 : なぜESRallyではなくJMeterなのか？（Kibana経由の負荷計測の必要性）

Elasticsearch 単体の性能を評価する目的であれば、専用ツールである ESRally を使用して直接接続テストを行うのが最適です。一方で、ESRally では「ユーザーが Kibana 画面を開き、ダッシュボードを表示する」といったフロントエンド経由の多重アクセスを再現することは困難です。

Kibanaを含めたシステム全体を評価するためには、以下のアーキテクチャの流れに沿った負荷テストを行う必要があります。

[ JMeter ] -(HTTP/HTTPS)-> [ Kibana (Node.js) ] -(REST)-> [ Elasticsearch Cluster ]

Kibana はユーザー操作を受けると、Node.js アプリケーションとしてリクエストを処理し、バックエンドのElasticsearch へ REST API を発行します。フロントエンドである Kibana 層を含めて HTTP(S) 経由でテストを実施することで、Node.js 層での処理滞留や Webアプリケーション特有のレスポンス遅延を含めた、真のユーザー体験に近いパフォーマンス計測が可能となります。

ポイント2 : ハマりポイント最大要素！ kbn-xsrf: true ヘッダーの必須設定

JMeter のプロキシ機能（HTTP(S) Test Script Recorder）を使ってブラウザ操作を録画し、そのままシナリオを実行しても、Kibana へのリクエストはすべて拒否されてしまいます。これは、Kibana が持つ CSRF （クロスサイトリクエストフォージェリ）対策のセキュリティチェックに引っかかるためです。

この問題を回避するには、スレッドグループに 「HTTP ヘッダーマネージャ」 （追加 > 設定エレメント > HTTP ヘッダーマネージャ）を追加し、リクエストに必須のヘッダーを明示的に付与する必要があります。

設定すべき主要ヘッダー一覧

ヘッダー名設定値説明
Content-Typeapplication/jsonリクエストボディの形式
kbn-xsrftrue【必須】 CSRF対策チェックの回避（※1）
AuthorizationApiKey ${API_KEY}API Keyによるヘッダー認証（変数は外部ファイルから読み込み）

※1 注意点: kbn-xsrf: true ヘッダーの付与を忘れると、KibanaはすべてのAPIリクエストに対して 400 Bad Request や 403 Forbidden を返し、テストは即座に失敗します。

また、セッション維持やCookie管理を自動化するために 「HTTP クッキーマネージャ」 （追加 > 設定エレメント > HTTP クッキーマネージャ）も併せてスレッドグループに追加しておきます。

ポイント3 : キャッシュの罠を回避せよ！クエリ日時の動的置換（JMeter関数）

録画によって生成されたシナリオ（.jmx ファイル）内には、検索条件としての「開始日時（gte/start）」や「終了日時（lte/end）」が固定の文字列やタイムスタンプとして記録されています。

この固定値のまま負荷テストを繰り返し実行すると、Kibana や Elasticsearch 側でキャッシュが効いてしまい、常に速いレスポンスが返される「偽の高速化現象」が発生します。リアルな負荷を再現するためには、 「ユーザーパラメータ」 前処理エレメント（追加 > 前処理 > ユーザーパラメータ）とJMeter関数を活用し、リクエストを投げるタイミングに応じた動的なタイムレンジを設定する必要があります。

ユーザーパラメータの設定例（過去15分間のデータ取得例）

スレッドグループにユーザーパラメータを追加し、以下の4つの変数を定義します。（過去15分間を指定する場合、ミリ秒計算は -1000ミリ秒 * 60秒 * 15分 = -900000 となります）

変数名変数の値（JMeter関数）
START_TIME_LONG${__longSum(${__time(,)},-900000,)}
END_TIME_LONG${__time(,)}
START_TIME${__dateTimeConvert(${__longSum(${__time(,)},-900000,)},,yyyy-MM-dd'T'HH:mm:ss.SSS,)}+09:00
END_TIME${__time(yyyy-MM-dd'T'HH:mm:ss.SSS,)}+09:00

Kibana のリクエスト内では、ミリ秒単位のエポックタイム数値表記とフォーマットされた ISO日時文字列の両方が使用されるため、上記のように両パターンの変数を用意しておきます。

.jmx ファイル内のテキスト置換処理

保存した .jmx ファイルをテキストエディタで開き、リクエストボディ内の固定日時を変数へ置換します。

ここで注意が必要なのは、JMeterの .jmx ファイルはXML形式で保存されるため、内部のJSONリクエストボディに含まれるダブルクォーテーション（"）が " にXMLエスケープされている点です。エディタでの検索・置換時は以下のようにエスケープ文字を含めた形で置換を行います。

置換前（録画された固定値の例）:

"gte":"2026-10-27T06:01:02.345Z"
"start":1792743725126,
"lte":"2026-10-27T06:16:02.345Z"
"end":1792743727052,

置換後（動的変数への置換）:

"gte":"${START_TIME}"
"start":${START_TIME_LONG},
"lte":"${END_TIME}"
"end":${END_TIME_LONG},

リクエストごとに検索タイムレンジを現在時刻ベースへ動的にシフトさせることで、キャッシュの有効化を防ぎ、バックエンドの検索エンジンへ正しく負荷をかけることが可能になります。

ポイント4 : 安全かつ確実な認証設計（API KeyとCSV Data Set Configの活用）

負荷試験で認証を通す際は、画面上のログイン操作をシナリオに含めるのではなく、API Keyを用いたヘッダー認証に統一するのが安全かつ効率的です。録画シナリオ内にログイン画面へのアクセスリクエストが含まれている場合は、無効化または削除しておきます。

API Keyの発行と管理の注意点

Kibana上でテスト用の API Key を発行する際は、以下のセキュリティ運用を徹底します。

  • 有効期限の制限: API Key の有効期限は無期限にせず、負荷テストが終了するまでの必要最小限の期間に設定します。
  • 権限の最小化: テスト対象インデックスへの参照権限など、必要最低限のロールのみを付与します。

CSV Data Set Config による値の注入

発行したAPI Key（Base64文字列）を記述した api_key.csv ファイルを作成します。

API_KEY
0123456789abcdef...==

JMeter のスレッドグループに「CSV Data Set Config」（追加 > 設定エレメント > CSV Data Set Config）を追加し、以下のように設定して各スレッドに安全に ${API_KEY} 変数を渡します。

項目名設定値
Filenameapi_key.csv
Variable NamesAPI_KEY
Ignore first lineTrue
Recycle on EOF ?True
Stop thread on EOF ?False
Sharing modeAll threads

ポイント5 : 本番さながらの負荷をかけるための実行手順

シナリオ構築完了後、本番テストを実施する際の手順と運用の注意点は以下の通りです。

5.1. リスナーの追加とGUIでの事前確認（ドライラン）

本番実行前に、まずはGUIモードでテスト結果を確認するためのリスナーをスレッドグループに追加します。

  • 結果をツリーで表示: 追加 > リスナー > 結果をツリーで表示（出力例: results.csv）
  • 統計レポート: 追加 > リスナー > 統計レポート（出力例: summary.csv）

リスナー追加後、スレッド数を1に設定してテストを1回実行（ドライラン）し、以下を確認します。

  1. リクエストボディの検証: 「結果をツリーで表示」の Request タブを開き、gte や lte が現在時刻ベースの動的な日時に正しく置換されているか確認します。
  2. エラー率の確認: 「統計レポート」の Error % が 0.00% であることを確認します。

5.2. 本番試験はCLIモード（非GUIモード）で実行

事前確認が取れたら、スレッド数（同時接続数）や Ramp-Up 期間を目的の負荷レベルに設定して .jmx ファイルを保存します。

本番負荷試験はJMeter本体のリソース消費を最小化するため、必ずCLIモードで実行し、HTMLレポートを出力します。

jmeter -n -t sample.jmx -l result_jtl.csv -e -o ./result_output -j jmeter_batch.log

実行完了後、./result_output/index.html をブラウザで開き、レスポンスタイムのパーセンタイル推移やスループット（TPS）を分析します。

5.3. システム側のリソースモニタリングとチューニング

テスト実行中は、Kibana および Elasticsearch ノードの CPU 使用率、メモリ使用量、Node.js / JVM のヒープステータスを継続的に計測します。要求水準を満たさない場合は、Kibana の Node.js ヒープサイズ調整やElasticsearch のインデックスクエリ最適化などのチューニングを実施します。

5.4. 【補足】ロードバランサー（ALB等）配下での注意点

AWS ALB などのロードバランサー配下に置かれた Kibana に対して高負荷をかける場合、JMeter（Java）側でDNS解決結果がキャッシュされ、特定の Kibana ノードにアクセスが偏る現象が発生することがあります。

マルチノード環境で均等に負荷を分散させたい場合は、JMeter のスレッドグループに 「DNS Cache Manager」 を追加し、Clear cache each iteration を有効化するなどの対策を検討してください（ただし、この記事では未検証です）。

まとめ

Kibana の適切な負荷試験を実施するための要点は以下の5点に集約されます。

  1. Apache JMeter の利用: ESRally ではなく、Apache JMeter を利用する。
  2. kbn-xsrf: true ヘッダーを付与: CSRF対策チェックを回避し、400 / 403 エラーを防ぐ。
  3. API Key認証の活用: CSV Data Set Config を用いて、不要なログイン処理を排除し最小権限のヘッダー認証に統一する。
  4. タイムレンジの動的化: JMeter 関数で gte/lte 等をリクエストごとに動的置換（.jmx 内の " エスケープに注意）し、キャッシュによる偽の高速化を排除する。
  5. CLIモードでの実行とモニタリング: GUIを避けてCLIで実行し、HTMLレポート解析とインフラ側のリソースモニタリングを並行して行う。

事前準備と特有の仕様への対策をしっかりと設計しておくことで、本番稼働前に Kibana を含めたシステム全体のボトルネックを正確に洗い出し、適切なチューニングを施すことが可能になります。

  1. Elasticsearch Rally ベンチマーク入門: バージョン 8.x と 9.x の性能比較
    ↩︎