Skip to content

Commit c9a0b45

Browse files
ma91nma91n
authored
Merge pull request #1849 from future-architect/feature
はじめての性能テストを公開しました
2 parents cdce875 + 1666515 commit c9a0b45

4 files changed

Lines changed: 165 additions & 0 deletions

File tree

‎source/_posts/2026/20260610a_はじめての性能テストを公開しました.md‎

Lines changed: 165 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,165 @@
1+
---
2+
title: "はじめての性能テストを公開しました"
3+
date: 2026/06/10 00:00:00
4+
postid: a
5+
tag:
6+
- 非機能
7+
- 性能テスト
8+
- ガイドライン
9+
category:
10+
- Infrastructure
11+
thumbnail: /images/2026/20260610a/thumbnail.png
12+
author: 武田大輝
13+
lede: "はじめての性能テストという性能テストの入門ガイドラインを作成し、公開しました。"
14+
---
15+
# はじめに
16+
17+
TIG（Technology Innovation Group）の武田です。
18+
19+
はじめての性能テストという性能テストの入門ガイドラインを作成し、公開しました。
20+
<https://future-architect.github.io/arch-guidelines/documents/forPerformanceTest/performance_test.html>
21+
22+
<a href="https://future-architect.github.io/arch-guidelines/documents/forPerformanceTest/performance_test.html">
23+
<img src="/images/2026/20260610a/image.png" alt="image.png" width="1200" height="570" loading="lazy">
24+
</a>
25+
26+
本ガイドラインは、性能テストの計画から実行、分析に至るまでの実践的なプロセスを一通りまとめたものとなります。次のような方を主な読み手として想定しています。
27+
28+
- 性能テストの経験がなく、何から手をつければよいかわからない方
29+
- これまでなんとなく性能テストを実施してきたが、考え方を体系的に整理したい方
30+
31+
# ガイドライン作成のモチベーション
32+
33+
まずはじめに、性能テストは難しいです。私が難しいと考える理由は次の3点です。
34+
35+
- **技術的な視野の広さ**
36+
フロントエンドから、バックエンドアプリケーション、ミドルウェア、データベース、そしてインフラまで、システムの全体を捉えて性能を見ていく必要があります。性能目標を達成できないときに、どこにボトルネックがあるのか「あたり」をつけ、クイックに原因特定から改善まで進めるには、特定の技術領域に偏らない幅広い知識と視野が欠かせません。
37+
38+
- **業務ドメインの理解**
39+
テストシナリオやデータパターンは、技術だけで決められるものではありません。対象システムがどのように使われ、いつアクセスが集中するのかといった、ビジネスコンテキストを理解したうえで初めて定義できるものです。
40+
41+
- **多くの関係者の調整**
42+
性能テストは巻き込むべき関係者が多くなります。アプリケーションやインフラの開発者はもちろん、目標値や完了基準を合意するビジネスサイドの方々、テスト環境やクラウドの利用申請に関わる方々など、多くの人を巻き込みながら調整を進めるコミュニケーションが求められます。
43+
44+
こうした難しさゆえに、性能テストを計画段階からリードできる人は、どうしても一部のベテラン勢に限られてしまいがちです。経験則や暗黙知に支えられている部分も大きく、性能テストの経験が浅い若手やミドル層がリードするにはハードルが高いのが現状でした。
45+
46+
本ガイドラインは、こうした状況を少しでも変えたいという思いから作成しました。
47+
性能テストの考え方や進め方を体系化することで、性能テスト未経験のエンジニアでも、計画からレポーティングまでを自信を持って推進できるようになることを目指しています。
48+
49+
# ガイドラインのポイント紹介
50+
51+
全体としては、まず性能テストの前提となる知識（分類や性能指標などの考え方）を説明したうえで、**計画 → 準備 → 実行 → チューニング → レポーティング**という一連のステップに分けて論点や進め方を解説する構成になっています。
52+
53+
ここでは、その中でも特に重要なポイントをいくつか紹介します。
54+
55+
## 性能テストの分類
56+
57+
性能テストという言葉は解釈の揺れが大きく、負荷テストと同義に使われることもあれば、別物として区別されることもあります。本ガイドラインでは、性能に関するあらゆるテストを包括する概念として「性能テスト」を捉えたうえで、実施条件と目的に応じて5つに分類しています。
58+
59+
```mermaid
60+
---
61+
config:
62+
theme: neutral
63+
layout: dagre
64+
look: handDrawn
65+
flowchart:
66+
htmlLabels: true
67+
nodeSpacing: 30
68+
rankSpacing: 50
69+
---
70+
flowchart TB
71+
classDef nodeLabel min-width:240px;
72+
73+
Root["性能テスト"]
74+
75+
subgraph Layer2 [" "]
76+
direction LR
77+
Data["データ量・サイズに焦点"]
78+
Load["アクセス数に焦点"]
79+
Time["稼働時間に焦点"]
80+
end
81+
82+
subgraph Layer3 [" "]
83+
direction LR
84+
Normal["想定内（通常・ピーク）の負荷"]
85+
Over["想定以上の限界負荷"]
86+
Sudden["突発的・大規模な負荷"]
87+
end
88+
89+
subgraph Layer4 [" "]
90+
direction LR
91+
Volume["ボリュームテスト"]
92+
Rush["ラッシュテスト"]
93+
Stress["ストレステスト"]
94+
Spike["スパイクテスト"]
95+
Long["ロングランテスト"]
96+
end
97+
98+
Root --> Data
99+
Root --> Load
100+
Root --> Time
101+
102+
Data --> Volume
103+
Load --> Normal & Over & Sudden
104+
Time --> Long
105+
106+
Normal --> Rush
107+
Over --> Stress
108+
Sudden --> Spike
109+
110+
style Layer2 fill:none,stroke:none
111+
style Layer3 fill:none,stroke:none
112+
style Layer4 fill:none,stroke:none
113+
```
114+
115+
## 性能目標の定め方
116+
117+
性能テストの大前提として性能要件をどう定めるかという点が重要です。本ガイドラインでは「スループット」「処理時間」「リソース使用率」のそれぞれについて、目標値の決め方を手厚く扱いました。
118+
119+
例えば処理時間については、目標値を平均値や最大値ではなくパーセンタイル値（例. 95パーセンタイルで500ms以内）として定義する理由を説明しています。あわせて、既存システムをベースラインとするアプローチや、TTFBのような業界標準の指標、IPAの非機能要求グレードを参考にした目標値の設定例まで、現場でそのまま使える形に落とし込んでいます。
120+
121+
## 性能テストの段取り
122+
123+
複数の種別をやみくもに実施するのではなく、ボリュームテスト → ラッシュテスト → ロングランテスト → ストレステストと観点を段階的に広げていく進め方を推奨しています。
124+
125+
テストの観点を「データ量」から「データ量 × 同時アクセス数」、そして「データ量 × 同時アクセス数 × 継続稼働時間」へと段階的に変化させていくことで、効率よくテストを積み上げられます。各テストには目的に対応した完了基準を定めており、「どうなったら次に進んでよいのか」がわかるようにしています。
126+
127+
<img src="/images/2026/20260610a/image_2.png" alt="image.png" width="800" height="417" loading="lazy">
128+
129+
## テストツールの選定
130+
131+
負荷ツールやモニタリングツールの選び方も解説しています。負荷ツールについては、JMeter・k6・Gatling・Vegeta・AWS Distributed Load Testingといった代表的なツールを記述方法・実行効率・分散構成対応・習熟コストなどの観点で比較しました。
132+
133+
そのうえで、本ガイドラインでは **k6** を推奨しています。テストをJavaScriptのコードとして書けるためバージョン管理やCI/CD連携と相性がよく、Go言語製で負荷生成の効率が高いことが主な理由です。
134+
135+
136+
| | JMeter | k6 | Gatling | Vegeta | AWS DLT |
137+
| :------------- | :-------------------------------------------------- | :----------------------------------------------------------------- | :--------------------------------------------------------------- | :--------------------------------------------------------------------- | :------------------------------------------------------------------- |
138+
| 説明 | Java製OSS負荷テストツール \- 多機能で利用実績も多い | Go製OSS負荷テストツール \- 省リソース、JSで記述しCI/CD統合に優れる | Scala製OSS負荷テストツール \- コードで記述、HTMLレポートがリッチ | Go製OSS CLI負荷テストツール\- HTTP特化、シンプルで手軽だが機能は限定的 | AWSの分散負荷テストサービス \- AWS上で大規模・サーバレス実行を自動化 |
139+
| 記述方法 | XML （GUIで生成） | JavaScript | Scala/Java/JavaScriptなど | 設定ファイル/CLI引数 | JMeter/k6/Locustに対応 |
140+
| GUI | あり | なし | なし | なし | あり |
141+
| プロトコル | ✅️ HTTP/SOAP/JDBCなど多数（拡張可） | ⚠️ HTTP/WebSocket/gRPCなど（拡張可） | ⚠️HTTP/WebSocket/gRPCなど（拡張可） | ❌️ HTTP特化 | ✅️ 多くのプロトコルに対応 |
142+
| 実行効率 | ⚠️ 低（OSスレッドベース） | ✅️ 高 | ✅️ 高 | ✅️ 高 | ✅️高 |
143+
| シナリオ準備 | ✅️ GUI記録機能あり、直感的 | ✅️ コード記述、har-to-k6等あり | ✅️ コード記述、レコーダーあり | ✅️ 非常にシンプルな設定 | ✅️ JMeter・k6・Locustに対応 |
144+
| 環境準備 | ⚠️ Javaインストール・設定必要 | ✅️ 単一バイナリ配置のみ | ⚠️ Java/Scala環境設定必要 | ✅️ 単一バイナリ配置のみ | ⚠️ 環境のデプロイが必要 |
145+
| 分散構成対応 | ✅️ コントローラ/ワーカー方式 | ❌️ 手動での分散実行（k8s operatorあり） | ❌️ 手動での分散実行 | ❌️ 手動での分散実行 | ✅️AWS Fargate |
146+
| レポート | ✅️ GUI表示、HTMLレポート、CSV/XML/JTL出力 | ✅️ 標準出力、JSON出力、CloudWatch連携 | ✅️ HTMLレポート自動生成 | ⚠️ 標準出力、CSV/JSON出力 | ✅️コンソール表示、CloudWatch連携 |
147+
| 商用サービス | ✅️ あり | ✅️ あり（k6 Cloud） | ✅️ あり（Gatling Enterprise） | ❌️ なし | ✅️ |
148+
| 習熟コスト | ⚠️ 独自GUIが複雑 | ✅️ シンプルで容易 | ⚠️ 独自DLSが複雑 | ✅️ シンプルで容易 | ⚠️ AWSインフラ知識が必要 |
149+
| GitHubスター数 | 9.1k | 29.4k | 6.8k | 24.7k | \- |
150+
151+
## チューニングポイント
152+
153+
テスト実行中に特定したボトルネックをどう解消していくか、代表的なチューニング観点を「アプリケーションサーバ / ランタイム」「アプリケーションロジック」「DBサーバ」「DBスキーマ / DBクエリ」の各レイヤに分けて紹介しています。スケーリングやコネクションプール、SQLの実行計画やインデックスの最適化など、現場でよくあるポイントを一通り網羅しています。
154+
155+
## レポーティング
156+
157+
最後に、テストの結果をどう評価・報告するかをまとめています。種別（ボリューム / ラッシュ / ロングラン / ストレス）ごとに、性能指標・リソース使用状況・エラー内訳・最適なインフラ構成の検討結果といった、レポートに含めるべき観点を整理しました。性能テストは「測って終わり」ではなく、本番運用に耐えられること、そして残存リスクまでを説明できて初めて完了します。
158+
159+
このほかAPPENDIXとして、Core Web Vitalsを軸とした画面（フロントエンド）の性能テストや、計画時・実施後に使えるチェックリストも用意しています。
160+
161+
# おわりに
162+
163+
性能テストは「とりあえず負荷をかけて終わり」ではなく、目的を定め、合否を判断し、ボトルネックを潰しながら本番運用に耐えられることを示していく一連のプロセスです。本ガイドラインが、性能テストにこれから取り組む方や、自分たちの進め方を見直したい方にとっての一助となれば幸いです。
164+
165+
ガイドラインはGitHubの [future-architect/arch-guidelines](https://github.com/future-architect/arch-guidelines) で公開しており、Issueやプルリクエストでのフィードバックも歓迎しています。

‎source/images/2026/20260610a/image.png‎

243 KB
Loading

‎source/images/2026/20260610a/image_2.png‎

37.2 KB
Loading

‎source/images/2026/20260610a/thumbnail.png‎

22.9 KB
Loading

0 commit comments

Comments
 (0)