Grafana k6 を利用した負荷試験基盤の構築

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

メドピア株式会社 / mpg-daichi-kondo

メンバー / バックエンドエンジニア

最終更新日2026/01/07投稿日2026/01/09

利用プラン

利用機能

ツールの利用規模

ツールの利用開始時期

事業形態

Open Source

パフォーマンステスト機能

10名以下

2025年9月

B to B

B to C

利用プラン	Open Source
利用機能	パフォーマンステスト機能
ツールの利用規模	10名以下
ツールの利用開始時期	2025年9月
事業形態	B to B B to C

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャの意図・工夫

既存の Staging 環境を「試験中だけ本番環境相当の性能に引き上げる」というアプローチを採用しました。

また、GitHub Actionsでワークフローを整備し、複雑な実施手順やインフラの専門知識がなくても負荷試験を実施できる環境を整えています。

導入の背景・解決したかった問題

導入背景

私が所属しているサービスでは、以前までは負荷試験を実施するための基盤が整えられていませんでした。

システムが受け入れられる負荷の上限は、これまでシステムの運用から統計的に算出した値を使用しており、以下の課題がありました。

負荷上限の信頼性が不透明
- 算出した値をどこまで信頼してよいのかが不透明で、大幅に安全に倒した判断をせざるを得ない
改善施策が実施しにくい
- システムに手を加えた際のパフォーマンスへの影響を計測することができず、スペックダウン等の変更を実施しにくい

こうした状況を改善するため、実際に負荷をかけて定量的にパフォーマンスを検証できる負荷試験基盤の構築に取り組みました。

比較検討したサービス

負荷試験ツールの比較

以下のツールを候補として検討しました。

Apache JMeter
Grafana k6 (採用)

実行環境の比較

k6の実行環境として、以下を比較検討しました。

Grafana Cloud k6
- k6をSaaSとして提供しているクラウドサービス
自前のAWS環境でホスティング (採用)
- アプリケーションコードが既にAWS ECS上で動作しており、同様の仕組みでk6を実行する構成

比較した軸

負荷試験ツールの比較

負荷試験を実施するツールとしては、以下の観点で検討を行い、Grafana k6 を採用しました。

リポジトリ管理のしやすさ

過去の負荷試験の結果がどの時点のシナリオファイルによる結果なのかを参照しやすくするため、シナリオファイルをGit管理しやすいことを重視しました。

また、シナリオファイルの作成を通常の開発と同様にPRとしてレビューフローに載せたいという意図もありました。

チームの技術スタックとの親和性

チームに馴染みのあるJavaScriptでシナリオを記述できることで、シナリオのレビューが行いやすくなります。

XML等の設定ファイルではなく、プログラミング言語として記述できる点を評価しました。

複雑なロジックの記述能力

負荷試験では、時間経過に伴いリクエスト数を動的に変化させるなど、複雑なロジックが必要になります。

コードでシナリオを記述できることで、こうした要件に柔軟に対応できると考えました。

ツール自体のパフォーマンス

クラウド上で負荷試験ツールを稼働させるにあたって、ツールのパフォーマンスはインフラコストに直結します。

同一の計算リソースあたりでより多くのリクエストを送信できるツールが望ましいと判断しました。

実行環境の比較

k6の実行環境については、金銭コストが最大の決め手となりました。

Grafana Cloud k6 は従量課金制のサービスとなっており、負荷試験の実行回数や規模に応じてコストが増大します。私たちの想定する負荷試験の頻度・規模で試算したところ、相当の金額になることが分かりました。

一方で、既存のAWS ECS環境を活用すれば試験実行時のインフラコストのみで済み、大幅なコスト削減が見込めたため、こちらの方針を採用しました。

導入の成果

導入後間もない状況ですが、以下の成果が出ています。

受け入れ可能な負荷上限の引き上げ

実際に負荷試験を実施し、以下のメトリクスを中心に確認しました

アプリケーションサーバーのCPU使用率とメモリ使用量
データベースの接続数とCPU使用率
レスポンスタイム
リクエストのエラー率

負荷試験環境により、本番環境では前例が無い規模の負荷をかけることができ、以前は安全側に倒して設定していた受け入れ上限を根拠を持って引き上げることができました。

これにより、ビジネス機会の損失を防ぐ体制を整えることが出来ました。

インフラ性能の調整によるコスト削減

負荷試験の結果、データベースのCPU使用率に十分な余裕があることが判明しました。

性能を下げても負荷の観点で問題ないことが確認できたため、データベースのスケールダウンを行う計画を立案しました。

この施策により、インフラコストの削減が見込まれています。

導入時の苦労・悩み

Datadog と連携する際のひと手間

弊社ではモニタリングツールとして Datadog を採用しているのですが、k6 から Datadog へのメトリクス送信は標準ではサポートされていませんでした。

k6 には不足している機能を拡張機能として追加できる機構があり、StatsD プロトコル（Datadogが対応するメトリクス送信プロトコル）でメトリクスを送信できる拡張機能 (xk6-output-statsd) があったため、こちらを組み込んだ k6 をビルドし使用しています。

JavaScriptランタイムの制限

k6 の JavaScript 実行環境は、Promise 等の非同期処理に対応しておらず、素朴な sleep 関数のみが提供されています。

そのため例えば「ある一連のユーザー操作を模した一連のリクエスト中に、一定間隔ごとに並行して別のリクエストを送る」というシナリオを記述したいときに困ります。

私たちのケースでは、sleep や HTTP リクエストを送る副作用のある関数を独自の機構でラップするなどの工夫を加え、実用的なシナリオを無理なく記述できる環境を整えました。

導入に向けた社内への説明

上長・チームへの説明

負荷試験に期待する要件を満たすことと、実施コストの比較などを説明し、k6 を動かすサーバーを既存のAWS ECS上に構築する方針について合意を得ました。

チームへの説明に関しては、試験の実施手順については手順書資料を作成し、k6 のシナリオの書き方については別のメンバーがチームのエンジニア向けに勉強会を開催してくれました。

活用方法

定期的な負荷試験のようなことはしておらず、

インフラ環境の大幅な変更を行う場合
アプリケーションの改修のうち、負荷への影響が見込まれる箇所の改修を行う場合

に、その負荷への影響調査として、負荷試験を実施する運用をしています。

よく使う機能

k6 の設計思想として、「シナリオファイルでは一人のユーザーの挙動を模したリクエストを書く」というモデルがとられています。このモデルのおかげで、シナリオファイルを作成する際に不必要な考慮事項が減り、良い開発体験となっていたと思います。

その他、HTTPリクエストのリダイレクト制御やレイテンシ情報の収集など、負荷試験に必要な機能は一通り揃っていると思います。

例として私たちの負荷試験では、以下のようなコードを用いて負荷試験を実施しています。

// シナリオ定義
const scenario = ({ user, ... }) => {
  ...
  waitUntil(conferenceWatchTime) // sleep 関数を独自の機構でラップした便利関数
  viewConferencePage(conferenceSlug, csrfToken)
  ...
}

// シナリオの個別の操作の定義
export function login(email) {
  ...
  httpPost(`${BASE_URL}/login`, {
    email: email,
    authenticity_token: csrfToken,
    redirects: 0,
  })
}

export function viewConferencePage(conferenceSlug, csrfToken) {
  ...
  httpGet(`${BASE_URL}/...`, { redirects: 0 })
}