性能テスト方針

本ドキュメントでは、idp-server の性能テストにおける方針、テスト条件、評価基準を定義する。

---

背景と目的

性能テストの目的

1. ベースライン確立: 標準条件下での基準性能値を測定
2. スケーラビリティ評価: ユーザー数・テナント数増加時の性能特性を把握
3. ボトルネック特定: システムの限界点と制約要因を明確化
4. 本番想定の妥当性検証: 想定負荷での安定稼働を確認

参考にした業界ベンチマーク

IdP	ベンチマーク条件	出典
Keycloak	100,000ユーザー、100,000クライアント、10分間テスト	Keycloak Performance Benchmarks
Auth0	最大2,000,000 Organizations/テナント	Auth0 Entity Limit Policy

---

テスト条件の標準化

スケール別テスト条件

性能テストは以下の3つのスケールで実施する。

条件	小規模 (S)	中規模 (M)	大規模 (L)
テナント数	1	5	10
ユーザー数/テナント	10,000	100,000	1,000,000
合計ユーザー数	10,000	500,000	10,000,000
クライアント数/テナント	5	10	20
同時VU数	50	200	500
テスト時間	5分	10分	10分
想定用途	開発・検証	中小規模本番	大規模本番

インフラ条件

ローカル検証環境（Docker Compose）

コンポーネント	スペック
idp-server	2 vCPU, 2GB RAM × 2インスタンス
PostgreSQL	標準設定
Redis	標準設定
Load Balancer	nginx

本番想定環境

スケール	idp-server	PostgreSQL	Redis
小規模	2 vCPU × 2	2 vCPU, 4GB	1 vCPU, 2GB
中規模	4 vCPU × 3	4 vCPU, 8GB	2 vCPU, 4GB
大規模	8 vCPU × 4+	8 vCPU, 16GB	4 vCPU, 8GB

---

測定観点

1. ベースライン測定

シングルテナント・少量データでの基準性能値を測定。

目的: 最小構成での理論上限を把握

条件:

• テナント: 1
• ユーザー: 1,000
• クライアント: 1

2. データスケール影響測定

ユーザー数増加時の性能劣化を測定。

目的: データ量と性能の相関を把握

条件:

ステップ	ユーザー数	測定項目
Step 1	10,000	全エンドポイント
Step 2	100,000	全エンドポイント
Step 3	1,000,000	全エンドポイント

評価ポイント:

• インデックス効果の確認
• クエリ実行時間の変化
• キャッシュヒット率

3. マルチテナント影響測定

テナント数増加時のRow Level Security (RLS) オーバーヘッドを測定。

目的: マルチテナントアーキテクチャの性能特性を把握

条件:

ステップ	テナント数	ユーザー/テナント	測定項目
Step 1	1	100,000	ベースライン
Step 2	5	100,000	RLS影響
Step 3	10	100,000	スケール確認

評価ポイント:

• テナント切り替えオーバーヘッド
• RLSポリシー評価コスト
• テナント間の性能一貫性

4. 同時負荷影響測定

同時接続数増加時の性能変化を測定。

目的: 同時実行性の限界を把握

条件:

ステップ	同時VU	リクエストレート
Step 1	50	100 req/s
Step 2	100	200 req/s
Step 3	200	400 req/s
Step 4	500	1,000 req/s

評価ポイント:

• スレッドプール飽和
• コネクションプール枯渇
• レスポンスタイム劣化曲線

5. キャッシュ効果測定

キャッシュの有無による性能差を測定。

目的: キャッシュ戦略の最適化

条件:

パターン	キャッシュ	TTL
Pattern A	無効	-
Pattern B	有効	60秒
Pattern C	有効	300秒

評価ポイント:

• キャッシュヒット率
• DB負荷軽減効果
• メモリ使用量

---

性能目標

API単体TPS（1 HTTPリクエスト）

カテゴリ	エンドポイント	TPS目標	p95目標
認可	Authorization Request	2,000+	200ms
トークン発行	Token (Client Credentials)	1,000+	250ms
トークン検証	Token Introspection	2,000+	200ms
公開鍵	JWKS	2,000+	200ms
CIBA	BC Request	1,000+	250ms

フロー完了TPS（複数HTTPリクエスト）

フロー	構成API数	完了TPS目標	p95目標
CIBA Full Flow	5	250+	300ms

CIBA Full Flowの構成:

1. POST /backchannel/authentications（BC Request）
2. GET /authentication-devices/{id}/authentications
3. POST /authentications/{id}/authentication-device-binding-message
4. POST /tokens
5. GET /jwks

参考：テスト環境での実測値

環境	構成	CIBA完了/秒	Token Introspection/秒
ローカル検証	2 vCPU × 2インスタンス	280	2,400

注記

スケールアウト時の性能は構成により異なる。本番環境では個別に性能検証を実施すること。

信頼性目標

指標	目標値	備考
エラー率	< 0.1%	5xx系エラー
成功率	> 99.9%	正常レスポンス
可用性	99.9%	ダウンタイム < 8.76時間/年

---

テスト実行計画

Phase 1: ベースライン確立

目的: 最小構成での基準値取得

手順:

1. シングルテナント、1,000ユーザーでデータ準備
2. 全ストレステストシナリオを実行
3. エンドポイント別の基準TPS/レイテンシを記録

成果物: ベースライン性能レポート

Phase 2: データスケール検証

目的: ユーザー数増加の影響を定量化

手順:

1. 10,000 → 100,000 → 1,000,000ユーザーで段階的にテスト
2. 各段階でクエリ実行時間を記録
3. 劣化曲線を作成

成果物: データスケール影響レポート

Phase 3: マルチテナント検証

目的: RLSオーバーヘッドを定量化

手順:

1. 1テナント → 5テナント → 10テナントで段階的にテスト
2. テナント別の性能差を記録
3. オーバーヘッド係数を導出

成果物: マルチテナント性能レポート

Phase 4: 負荷限界検証

目的: システムのブレークポイントを特定

手順:

1. 負荷を段階的に増加（50 → 100 → 200 → 500 VU）
2. エラー発生開始点を記録
3. 安定稼働可能な最大負荷を特定

成果物: 負荷限界レポート、サイジングガイドライン

---

テスト結果の評価基準

合格基準

項目	基準
TPS	目標値の80%以上
p95レイテンシ	目標値以下
エラー率	0.1%未満
CPU使用率	80%未満（定常時）
メモリ使用率	80%未満

警告基準

項目	基準	対応
TPS	目標値の60-80%	チューニング検討
p95レイテンシ	目標値の1.2-1.5倍	ボトルネック調査
CPU使用率	80-90%	スケールアウト検討

失敗基準

項目	基準	対応
TPS	目標値の60%未満	設計見直し
エラー率	1%以上	緊急対応
CPU使用率	90%以上	即座にスケール

---

レポート形式

テスト結果レポートの構成

1. テスト概要

   • テスト日時
   • テスト条件（スケール、データ量）
   • インフラ構成

2. 測定結果

   • エンドポイント別TPS/レイテンシ
   • リソース使用率推移
   • エラー分析

3. 考察

   • 目標との比較
   • ボトルネック分析
   • 改善提案

4. 結論

   • 合格/不合格判定
   • 次回アクション

---

関連ドキュメント

• テスト環境
• テスト実行ガイド
• チューニングガイド

---

参考文献

• Keycloak Performance Benchmarks
• Keycloak Benchmark Repository
• Auth0 Entity Limit Policy
• Okta Capacity Planning