Performance改善案をTestして比較する

ゴール

何を証明したいか
↓
ベンチマーク
または
負荷テストを選択
↓
比較条件を固定
↓
変更前 / 変更後を測定
↓
同じメトリクスで比較
↓
改善を確認
↓
回帰を確認
↓
KPIで検証
↓
推薦

前提

ここでは、ビジネス要件のSLA / KPI化、レイテンシーやスループットの測定、正常状態のベースライン、ボトルネック特定、スケーリングや適正サイズ化などの改善案、マネージドサービスや新しい技術の候補評価は既習として扱います。

ここで新しく扱うのは、その改善策が実際に効果を持つかをどう証明するかです。

1. テストの前に「何を改善したいか」を固定する

最初にテストツールを選ぶのではありません。先に、

現在
p95レイテンシー 420 ms

目標
300 ms以下

のように何を改善する必要があるかを明確にします。

KPI
↓
証明したいこと
↓
テスト方法

の順に考えます。

2. ベンチマークは特定の技術やコンポーネントを比較する

ベンチマークは、特定のコンポーネントや技術について性能を比較するときに有効です。

候補Aのデータベース
候補Bのデータベース

同じデータ
同じクエリ
同じ同時実行数
↓
レイテンシー
スループット

ワークロード全体がまだ完成していなくても、特定の技術選択を絞り込むための性能データを得られます。

3. 一般的なベンチマークだけで判断しない

公開されている一般的な性能値だけでは、自分のワークロードに最適とは限りません。小さいランダム読み取り中心なのか、大規模な集計処理中心なのかによって結果は変わります。

可能であれば、実際に利用する処理特性を反映したベンチマークを使い、一般的に速いかではなく、自分の処理特性で要求性能を満たせるかを確認します。

4. ベンチマークは1回だけの結果で決めない

テスト結果にはばらつきがあります。

実行1 220 ms
実行2 225 ms
実行3 219 ms

のように安定している場合もあれば、

実行1 190 ms
実行2 410 ms
実行3 205 ms

のように大きくばらつくこともあります。キャッシュ状態や初期化状態などの影響を避けるため、必要に応じてテスト環境を事前にウォームアップし、複数回測定してばらつきを確認します。

5. 負荷テストはワークロード全体の挙動を見る

改善候補がアーキテクチャへ組み込まれた後は、コンポーネント単体のベンチマークだけでは不十分な場合があります。

利用者
↓
API
↓
アプリケーション
↓
キャッシュ
↓
データベース
↓
外部サービス

という実際の経路全体で性能が改善するかを確認するため、負荷テストでは本番に近いワークロード全体へ負荷を与えます。

6. 負荷テストは代表的な利用方法を再現する

単純に大量の同じリクエストを送るだけでは不十分です。実際の利用が、

商品検索 60%
商品詳細 25%
購入処理 10%
その他 5%

なら、可能な範囲で実際の利用構成を反映します。

通常負荷
↓
ピーク負荷
↓
ピークを超える負荷

まで確認すると、要求負荷を処理できるか、どこから性能が劣化するか、どの程度の余裕があるかを把握できます。

7. 本番相当の条件で負荷テストする

小さく簡略化したテスト環境で成功しても、本番規模で同じ結果になるとは限りません。データベース接続、キャッシュ、ネットワーク、ロードバランシング、分散処理などの挙動が変わる可能性があります。

性能改善を最終的に検証するときは、可能な限り本番構成・本番規模に近い条件を使います。テストデータには、必要に応じて合成データや機密情報を除去したデータを使用します。

8. 変更前後で比較条件を変えない

性能改善の効果を確認するときは、比較条件を揃えます。

変更前
5,000 req/s
p95 400 ms

変更後
2,000 req/s
p95 220 ms

では、負荷そのものが異なるため、変更によって高速化したとは判断できません。

同じ負荷、同じリクエスト構成、同じデータ条件、同じ測定時間、同じメトリクス、同じ統計方法など、結果へ影響する条件をできるだけ揃えます。

9. 変更前と変更後は同じメトリクスで比較する

変更前がp95レイテンシーなのに、変更後を平均レイテンシーで評価すると比較できません。

平均、中央値、p95、p99、最大値では意味が異なるため、KPIに使っている統計値と同じものを確認します。

10. 改善率だけでは合格にならない

変更前 p95 600 ms
変更後 p95 400 ms

KPI p95 300 ms以下

なら200 ms改善していても要求未達です。

改善した
≠
要件を満たした

どれだけ改善したかと、必要な性能を満たしたかは別に判断します。

11. 主要メトリクスだけでなく回帰も確認する

変更前
p95レイテンシー 420 ms
エラー率 0.2%

変更後
p95レイテンシー 250 ms
エラー率 3.5%

レイテンシーが改善していても、エラー率上限が1.0%なら成功とは判断できません。変更によって既存の正常な性能や品質を悪化させることを回帰として確認します。

12. 「改善対象」と「ガードレール」を分ける

改善したい指標だけでなく、悪化してはいけない指標も決めます。

13. ベンチマークと負荷テストは競合するものではない

候補技術A / B / C
↓
コンポーネントベンチマーク
↓
AとBへ絞る
↓
アーキテクチャへ組み込む
↓
負荷テスト
↓
本番相当条件で比較

ベンチマークは技術候補を効率よく比較することに向き、負荷テストはワークロード全体として要求性能を満たすか検証することに向きます。

14. テスト結果は変更内容と対応付ける

インスタンスタイプ変更、データベース設定変更、キャッシュ追加を同時に行って性能が改善しても、どの変更が効果を持ったか特定できません。

変更内容、テスト条件、テスト結果を対応付けて記録し、原因と効果を明確にしたい場合は可能な範囲で変更を分離して比較します。

15. 推薦はテスト結果から作る

要求
10,000 req/s
p95 300 ms以下
エラー率 1%以下

変更前
p95 430 ms
エラー率 0.3%

変更後
p95 270 ms
エラー率 0.4%
10,000 req/s 安定処理

同じ代表負荷
↓
対象KPI達成
↓
許容できない回帰なし
↓
改善案を推薦

推薦は機能説明ではなく、測定結果から導きます。

16. テスト結果が不十分なら推薦を保留する

1回だけ実施、比較条件が異なる、必要なKPIを測っていない、本番と大きく異なる負荷、回帰を確認していない場合は、十分な検証とはいえません。

この場合は改善案を直ちに却下するのではなく、不足している検証を追加するという判断もあります。目的は、意思決定できるだけの性能データを作ることです。

17. 判断フロー

性能改善候補
↓
何を証明する必要がある？
↓
対象KPI / メトリクスを決定
↓
テスト対象は？
├─ 特定コンポーネント / 技術比較
│   ↓
│ ベンチマーク
│
└─ ワークロード全体
    ↓
  負荷テスト
↓
比較条件を固定
↓
変更前を測定
↓
改善案を適用
↓
変更後を測定
↓
同じメトリクスで比較
↓
改善した？
├─ いいえ → 候補を見直す
└─ はい
    ↓
要求KPIを満たす？
├─ いいえ → 追加改善または別候補
└─ はい
    ↓
許容できない回帰はない？
├─ ある → 改善案を見直す
└─ ない → 推薦可能

18. 混同ポイント

19. このページで扱わないこと

ここでは、パフォーマンス問題のボトルネックを最初から特定する手順、CPU・メモリ・ストレージ・ネットワークの適正サイズ化、マネージドサービスへ置換すべきかを最初に判断する方法、個別AWSサービスのベンチマークツール操作、特定の負荷テスト製品の操作、コスト比較、信頼性やセキュリティを含む最終アーキテクチャ全体の選択は扱いません。

ここで完成させるのは、既に存在する性能改善候補を、比較可能な性能テストによって検証し、性能面から推薦できる状態へすることです。

まとめ

性能改善候補
↓
ベンチマーク / 負荷テスト
↓
比較条件を揃える
↓
変更前 / 変更後
↓
同じメトリクス
↓
改善効果
↓
回帰
↓
KPI検証
↓
推薦

ベンチマークは特定コンポーネントや技術候補の比較、負荷テストは本番に近いワークロード全体での要求性能確認に適しています。

最も重要なのは、改善したかどうかではなく、必要なKPIを満たし、許容できない回帰を発生させず、その結果を比較可能な条件で証明できたかです。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 3.3
• AWS Well-Architected フレームワーク — PERF01-BP06 ベンチマークを使用してアーキテクチャに関する意思決定を行う
• AWS Well-Architected フレームワーク — PERF05-BP04 ワークロードの負荷テストを実施する
• AWS Well-Architected フレームワーク — パフォーマンス効率 / プロセスと文化