スケーラビリティ評価
本ドキュメントでは、idp-server のスケーラビリティについて評価・分析する。
評価観点
1. データスケーラビリティ
- ユーザー数増加に伴う性能変化
- テナント選択パターンによる影響
2. マルチテナントスケーラビリティ
- テナント数増加に伴う性能変化
- テナント間のリソース分離
3. 水平スケーラビリティ
- インスタンス追加時のスループット向上率
- ロードバランサ配下での負荷分散効率
テスト環境
インフラ構成
| コンポーネント | 構成 | リソース |
|---|---|---|
| idp-server | 2インスタンス | 各 CPU 2コア、メモリ 2GB |
| ロードバランサー | nginx | ラウンドロビン |
| PostgreSQL | Primary + Replica | Primary: 書き込み、Replica: 読み取り |
| Redis | 1インスタンス | キャッシュ用 |
データ規模
| 構成 | 総ユーザー数 |
|---|---|
| 1テナント×100万 + 9テナント×10万 | 190万 |
ローカル環境での制約
本テストはDocker Desktop (macOS) 上で実施。以下の制約がある：
- 全コンテナが同一ホスト のCPU/メモリ/I/Oを共有
- 仮想化オーバーヘッドが存在
- ネットワークはループバック
4インスタンス以上の構成は本番環境での検証が必要。
データスケーラビリティ
テナント選択パターン別性能比較
10テナント環境（1テナント100万ユーザー + 9テナント各10万ユーザー）での比較。
| エンドポイント | ランダムテナント | 100万固定 | 差分 | 考察 |
|---|---|---|---|---|
| Authorization | 1,803 TPS | 2,708 TPS | +50% | テナント切替オーバーヘッド削減 |
| JWKS | 2,684 TPS | 2,632 TPS | -2% | キャッシュ効果で同等 |
| Token Introspection | 2,453 TPS | 2,076 TPS | -15% | データ量の影響 |
| CIBA (device) | 1,425 TPS | 1,481 TPS | +4% | インデックス効果で同等 |
エンドポイント別特性
Authorization（認可リクエスト）
- 100万固定で50%向上: テナント切替オーバーヘッドがないためキャッシュ効率が向上
- p95: 179ms（100万固定）、189ms（ランダム）
Token Introspection（トークン検証）
- ランダムの方が15%高速: 100万ユーザーのトークン検索はデータ量の影響を受ける
- p95: 199ms（ランダム）、246ms（100万固定）
JWKS / CIBA
- ほぼ同等: Redisキャッシュとインデックスが効果的に機能
- テナント数やデータ量の影響を受けにくい
ヒント
エンドポイントの処理特性によりスケーラビリティが異なる：
- キャッシュ依存型（JWKS）: データ量の影響を受けにくい
- 検索依存型（Introspection）: データ量の影響を受けやすい
- 複合型（Authorization, CIBA）: インデックス戦略が重要
マルチテナントスケーラビリティ
テスト構成
10テナント環境でのランダムテナント選択によるストレステスト。
| パターン | 説明 |
|---|---|
| ランダムテナント | 10テナントからランダムに選択 |
| 100万固定 | 100万ユーザーのテナントのみ使用 |
結果（CIBA Full Flow）
| テナント選択 | TPS | p95 | エラー率 |
|---|---|---|---|
| ランダム（10テナント） | 1,425 | 274ms | 0.00% |
| 100万固定（1テナント） | 1,481 | 227ms | 0.00% |
考察
- 10テナント環境でも安定したパフォーマンスを維持
- テナント間のリソース競合は最小限
- Row Level Security (RLS) のオーバーヘッドは許容範囲内
- 100万ユーザーテナントでも性能劣化なし
水平スケーラビリティ
テスト構成
| 項目 | 値 |
|---|---|
| 各インスタンスCPU | 2コア |
| 各インスタンスメモリ | 2GB |
| ロードバランサー | nginx（ラウンドロビン + keepalive） |
1インスタンス vs 2インスタンス比較
| エンドポイント | 1インスタンス | 2インスタン ス | 向上率 | スケール効率 |
|---|---|---|---|---|
| Authorization | 1,717 TPS (p95: 167ms) | 2,464 TPS (p95: 145ms) | +43% | 72% |
| CIBA Full Flow | 1,083 TPS (p95: 284ms) | 1,313 TPS (p95: 294ms) | +21% | 61% |
考察
- 2インスタンスで2,400+ TPSを達成（Authorization）
- スケール効率は61-72%（ローカル環境の制約あり）
- ステートレス設計により負荷分散が可能
- Redisセッション共有によりインスタンス間の整合性を確保
注記
4インスタンス構成ではローカル環境の制約（DB/Redis共有）により性能向上が確認できなかった。 本番環境ではインフラ分離によりスケール効率の改善が期待できる。
スケーラビリティ限界
アプリケーション層
| ボトルネック | 影響 | 対策 |
|---|---|---|
| JVMヒープ | メモリ不足でOOM | ヒープサイズ増加 |
| スレッドプール | リクエスト待ち | maxThreads増加 |
| GCポーズ | レイテンシスパイク | GC戦略調整 |
データベース層
| ボトルネック | 影響 | 対策 |
|---|---|---|
| コネクションプール | 接続待ち | プールサイズ増加 |
| ロック競合 | デッドロック | トランザクション最適化 |
| I/O | クエリ遅延 | SSD、インデックス最適化 |
キャッシュ層
| ボトルネック | 影響 | 対策 |
|---|---|---|
| Redisメモリ | エビクション | メモリ増加、TTL調整 |
| ネットワーク | レイテンシ | ローカルキャッシュ併用 |
推奨スケール戦略
負荷レベル別構成
検証済み構成（2インスタンス）
services:
idp-server:
replicas: 2
resources:
limits:
cpus: '2'
memory: 2G
postgresql:
resources:
limits:
cpus: '2'
memory: 4G
redis:
resources:
limits:
memory: 1G
実測値: 2,000+ TPS、p95 < 300ms
スケールアップ構成
4インスタンス以上の構成は、本番環境にて以下を考慮した検証が必要：
- データベースの接続プール設定
- PostgreSQLのmax_connections調整
- Redisの接続数とメモリ
- ネットワーク帯域
注記
ローカル環境での4インスタンステストでは、DB/Redis/ネットワークがボトルネックとなり性能向上が確認できなかった。 本番環境では適切なインフラ分離により改善が期待できる。
スケール効率の最適化
スケール効率とは
インスタンス追加時の性能向上率を示す指標。
理想: 1インスタンス 1,000 TPS → 2インスタンス 2,000 TPS (効率100%)
実際: 1インスタンス 1,000 TPS → 2インスタンス 1,500 TPS (効率75%)
1インスタンス vs 2インスタンス比較
| エンドポイント | 1インスタンス | 2インスタンス | 向上率 | スケール効率 |
|---|---|---|---|---|
| Authorization | 1,717 TPS | 2,464 TPS | +43% | 72% |
| CIBA | 1,083 TPS | 1,313 TPS | +21% | 61% |
最適化による効果
nginx keepalive設定
upstream idp_backend {
server idp-server-1:8080;
server idp-server-2:8080;
keepalive 32;
}
location / {
proxy_http_version 1.1;
proxy_set_header Connection "";
# ...
}
| 設定 | TPS | p95 | 効果 |
|---|---|---|---|
| keepaliveなし | 2,192 | 228ms | - |
| keepaliveあり | 2,464 | 182ms | TPS +12%, p95 -20% |
DB接続プール最適化
| 設定 | TPS | p95 | 効果 |
|---|---|---|---|
| Pool 30 | 2,464 | 182ms | - |
| Pool 10 | 2,439 | 145ms | p95 -20% |
最適化の指針
- nginx keepalive: 接続再利用によりオーバーヘッド削減
- DB接続プール削減: 過剰な接続による競合を回避、レイテンシ安定化
- 推奨値: CPUコア数 × 2 程度（2コアなら10接続程度）
スケーラビリティ改善ロードマップ
短期（現状で対応可能）
- インスタンス追加によるスケールアウト
- JVM/Tomcat設定の最適化
- インデックス追加による DB最適化
中期
- リードレプリカの導入
- キャッシュ階層の強化
- 非同期処理の拡大
長期
- マイクロサービス化
- イベントソーシング導入
- グローバル分散配置
結論
idp-server は以下のスケーラビリティ特性を持つ：
| 観点 | 評価 | 実測値 |
|---|---|---|
| 水平スケール | 良好 | 1→2インスタンスでスケール効率61-72% |
| マルチテナント | 優良 | 10テナント環境でエラー率0% |
| データスケール | 優良 | 190万ユーザーでp95 < 300ms |
性能サマリー（2インスタンス構成、最適化後）
| エンドポイント | TPS | p95 |
|---|---|---|
| Authorization | 2,464 | 145ms |
| CIBA Full Flow | 1,313 | 294ms |
最適化効果
| 最適化 | 効果 |
|---|---|
| nginx keepalive | TPS +12%, p95 -20% |
| DB接続プール削減 (30→10) | p95 -20% |
総合評価: 2インスタンス構成で2,000+ req/sの本番環境に対応可能。 スケール効率はローカル環境で61-72%。本番環境での最適化により改善が期待できる。