リフレッシュトークン負荷テスト

テスト概要

項目	詳細
テスト日	2025年12月
対象エンドポイント	`POST /token` (grant_type=refresh_token)
目的	盗難検知付きリフレッシュトークンローテーションのパフォーマンスを測定

テスト環境

インフラ構成

コンポーネント	テクノロジー	説明
Worker	Cloudflare Workers	OAuth2/OIDCエンドポイント処理
Durable Objects	Cloudflare DO	RefreshTokenRotator（トークンローテーション管理）
Database	Cloudflare D1	ユーザー情報、セッション、監査ログ
Cache	Cloudflare KV	JWKキャッシュ、RBACクレームキャッシュ、ユーザーキャッシュ

アーキテクチャ

flowchart TB
    subgraph Local["テスト環境"]
        k6["k6 OSS / K6 Cloud"]
    end

    subgraph CF["Cloudflare"]
        Edge["Cloudflare Edge"]

        subgraph Worker["ar-token Worker"]
            W["トークン処理 + JWT署名"]
        end

        subgraph Cache["キャッシュ層"]
            KV["KV: JWK / RBAC / ユーザーキャッシュ"]
        end

        subgraph DO["Durable Objects"]
            RTR["RefreshTokenRotator"]
        end

        subgraph DB["Database"]
            D1["D1: sessions / audit_logs"]
        end
    end

    k6 -->|HTTPS| Edge
    Edge --> W
    W --> KV
    W --> RTR
    W --> D1
    RTR --> D1

テスト設定

設定項目	値	本番推奨
`REFRESH_TOKEN_ROTATION_ENABLED`	true	true
`REFRESH_TOKEN_EXPIRY`	30日	30日
`ACCESS_TOKEN_EXPIRY`	1時間	1時間
`RBAC_CACHE_TTL`	5分	5分
`USER_CACHE_TTL`	1時間	1時間

テスト方法論

シナリオ: Refresh Token Storm

本番環境でのリフレッシュトークンローテーション動作をシミュレート：

項目	設定
トークンローテーション	有効（毎回新しいリフレッシュトークンを発行）
VU設計	VUごとに独立したトークンファミリー
テストパターン	正常ローテーションパスのみ（エラーケースなし）
Think Time	0ms（連続リクエスト）

TokenFamilyV2設計

バージョンベースの盗難検知：

{
  "sub": "user_id",
  "client_id": "client_id",
  "rtv": 5,              // Refresh Token Version
  "jti": "unique_id",
  "exp": 1735689600
}

rtv (Refresh Token Version): トークンファミリー内のバージョン番号
古いバージョンのトークン使用 → 盗難として全トークン無効化
状態管理はDurable Objects、監査永続化はD1

プリセット構成

プリセット	目標RPS	時間	最大VU	ユースケース
rps100	100 RPS	2分	120	本番ベースライン
rps200	200 RPS	2分	240	高トラフィックシナリオ
rps300	300 RPS	2分	360	ピーク負荷検証

結果 - 200 RPSテスト

実行日時: 2025年12月3日 09:33 JST

K6メトリクス

メトリクス	値
総リクエスト数	29,186
成功率	100%
トークンローテーション成功率	100%
エラー	0

Cloudflare Analytics

メトリクス	値	備考
Worker Duration P50	9.35 ms	Median
Worker Duration P99	816.24 ms	Tail latency
CPU Time P50	4.80 ms
CPU Time P99	14.40 ms
DO Wall Time P50	9.16 ms	Durable Objects処理時間
DO Wall Time P99	18.43 ms
D1 Reads	10,510	0.36/リクエスト
D1 Writes	23,518	0.81/リクエスト

DOとD1効率

メトリクス	計算値	説明
DOリクエスト/Workerリクエスト	3.09	サブリクエスト効率
D1 Reads/リクエスト	0.36	RBACキャッシュヒット率 > 95%
D1 Writes/リクエスト	0.81	監査ログとセッション更新

結果 - 3,000 RPSテスト（シャーディング）

シャーディングの影響

シャード数	DO P99	DOエラー	HTTP失敗
32	781ms	11,972	多数
48	43ms	0	0

劇的な改善:

DO P99: 781ms → 43ms（95%削減）
DOエラー: 11,972 → 0（100%解消）

Before vs After（3,000 RPS）

メトリクス	32シャード	48シャード	改善
Worker P50	12ms	12ms	同等
Worker P95	100ms	39ms	-61%
Worker P99	781ms	43ms	-94%
DOエラー	11,972	0	-100%
成功率	~96%	100%	✅

最適化履歴

D1読み取りクエリ削減

最適化段階	D1 Reads/リクエスト	改善
V1（キャッシュなし）	~14.6	ベースライン
V2（RBACキャッシュ前）	9.7	-34%
V2（RBACキャッシュ後）	0.36	-96%

適用した最適化

日付	最適化	効果
2025-12-01	TokenFamilyV2（バージョンベース盗難検知）	DOストレージI/O削減
2025-12-01	UserCache（KV Read-Through）	D1ユーザークエリ削減
2025-12-03	非同期監査ログ（Fire-and-Forget）	レスポンスレイテンシ削減
2025-12-03	RBACクレームキャッシュ（5分TTL）	D1 RBACクエリ96%削減

キャッシュ戦略

キャッシュ	TTL	目的
USER_CACHE	1時間	ユーザー情報（Read-Through）
REBAC_CACHE	5分	RBACクレーム（ロール、権限、グループ）
CLIENTS_CACHE	1時間	クライアント情報
KeyManager	5分	JWK署名鍵（Workerメモリ）

キャパシティ推奨

用途	推奨RPS	根拠
通常運用	≤200	P99 < 500ms維持
ピーク対応	≤2,500	48シャード使用
絶対上限	≤3,000	48シャードでゼロエラー

MAU換算

RPS	トークン発行/時間	トークン発行/日	推定MAU
100	360,000	8.6M	200K-400K
200	720,000	17.3M	500K-1M
300	1,080,000	25.9M	1M-2M

換算式:

RPS = (MAU × DAU率 × リクエスト/DAU) / (稼働時間 × 3600) × ピーク係数
    ≈ MAU / 5,000

主要な発見

1. シャーディングが不可欠

48シャードで3,000 RPSのエラーを完全解消（32シャードでは11,972件のDOエラー）。

2. RBACキャッシュでD1負荷96%削減

D1 readsが14.6/リクエスト→0.36/リクエストに減少。

3. トークンローテーションは信頼性高

200 RPSでローテーション有効で100%成功率。

4. Workerは効率的

CPU時間は負荷下でも4-15msを維持。

パフォーマンス目標

メトリクス	目標	結果	状態
成功率	> 99.9%	100%	✅
トークンローテーション	> 99%	100%	✅
Worker Duration P99	< 1000ms	816ms / 43ms	✅
DO Wall Time P99	< 100ms	18.43ms / 43ms	✅
D1 Reads/リクエスト	< 5	0.36	✅

結論

Authrimのリフレッシュトークンエンドポイント（ローテーション有効）は：

200 RPSで100%成功率
100%トークンローテーション成功
0.36 D1 reads/リクエスト（キャッシュで96%削減）
3,000 RPSでゼロエラー（48シャード使用）

重要なポイント: 適切なシャーディング（48シャード）により、システムは不安定（11,972エラー）から完全に信頼性の高い状態（0エラー）に変わります。

TokenFamilyV2設計はセキュリティ（盗難検知）とパフォーマンス（バージョンベース状態管理）の両方を提供します。